Re: compat linux SIOCGIFCONF fix for 64bit archs

In article <20080630172052.GA300913 <at> medusa.sis.pasteur.fr>,
Nicolas Joly  <njoly <at> pasteur.fr> wrote:
>-=-=-=-=-=-
>
>
>Hi,
>
>Here follow a patch that fix SIOCGIFCONF ioctl under compat linux for
>64bits archs.
>
>The main problem, here, is that Linux `struct ifreq' is not MI, but
>our is ... By example, on Linux/x86_64 use a 40 bytes structure but
>our corresponding structure has only 32 bytes (this works on i386,
>because the Linux structure size is 32 bytes). This difference will
>lead to an alignment problem when reporting the interfaces list with
>SIOCGIFCONF ioctl.
>
>To fix it, i added a new `struct linux_ifreq' which has the expected
>size, and a new linux_getifconf() function that use it (a cleaned up
>version of compat_ifconf()).
>
>While here, the new linux_getifconf() function will only report
>interfaces of AF_INET family, like the Linux kernel does.
>
>I tested it on -current NetBSD/amd64 and NetBSD/i386 that i have
>access to.
>
>Thanks.
>
>NB: If this is ok, i'll plan to modify compat linux32 too; at least

Re: compat linux SIOCGIFCONF fix for 64bit archs

On Mon, Jun 30, 2008 at 07:20:52PM +0200, Nicolas Joly wrote:
> 
> Hi,
> 
> Here follow a patch that fix SIOCGIFCONF ioctl under compat linux for
> 64bits archs.
> 
> The main problem, here, is that Linux `struct ifreq' is not MI, but
> our is ... By example, on Linux/x86_64 use a 40 bytes structure but
> our corresponding structure has only 32 bytes (this works on i386,
> because the Linux structure size is 32 bytes). This difference will
> lead to an alignment problem when reporting the interfaces list with
> SIOCGIFCONF ioctl.
> 
> To fix it, i added a new `struct linux_ifreq' which has the expected
> size, and a new linux_getifconf() function that use it (a cleaned up
> version of compat_ifconf()).

this is mostly what FreeBSD does... I believe you can copy some more
code from us :)

btw: any progress with the futexes?

roman

Re: Nvidia MCP67 SATA controller

On Sat, Jun 28, 2008 at 12:06:21AM +0200, Manuel Bouyer wrote:
> On Fri, Jun 27, 2008 at 11:55:00AM +0200, Dieter Baron wrote:
> > hi,
> > 
> > attached is a cleaned up version of my previous patch to make MCP65
> > and MCP67 SATA controllers work: Make ahcisata match, even if the
> > controller is not in AHCI mode; increase the delay after a channel
> > reset to 500ms (from 100ms).  I've also restructured the match
> > function to only map the registers if we actually check which mode the
> > controller is in.
> 
> I think this part of the patch is wrong. We should not match if we
> can't map the AHCI registers, as it's not going to work anyway.
> The BIOS may have configured it in pciide-compatible mode, which which
> case the AHCI registers may not be mappable.

  Okay, I've reworked the patch to always map (and unmap) the register
if we are going to match the device.  New version attached.

					yours,
					dillo

Index: sys/dev/ic/ahcisata_core.c
===================================================================
RCS file: /cvsroot/src/sys/dev/ic/ahcisata_core.c,v
retrieving revision 1.15
diff -u -r1.15 ahcisata_core.c
--- sys/dev/ic/ahcisata_core.c	7 May 2008 13:52:12 -0000	1.15
+++ sys/dev/ic/ahcisata_core.c	1 Jul 2008 09:01:43 -0000

Re: compat linux SIOCGIFCONF fix for 64bit archs

On Tue, Jul 01, 2008 at 10:13:31AM +0200, Roman Divacky wrote:
> On Mon, Jun 30, 2008 at 07:20:52PM +0200, Nicolas Joly wrote:
> > 
> > Hi,
> > 
> > Here follow a patch that fix SIOCGIFCONF ioctl under compat linux for
> > 64bits archs.
> > 
> > The main problem, here, is that Linux `struct ifreq' is not MI, but
> > our is ... By example, on Linux/x86_64 use a 40 bytes structure but
> > our corresponding structure has only 32 bytes (this works on i386,
> > because the Linux structure size is 32 bytes). This difference will
> > lead to an alignment problem when reporting the interfaces list with
> > SIOCGIFCONF ioctl.
> > 
> > To fix it, i added a new `struct linux_ifreq' which has the expected
> > size, and a new linux_getifconf() function that use it (a cleaned up
> > version of compat_ifconf()).
> 
> this is mostly what FreeBSD does... I believe you can copy some more
> code from us :)

Thanks.

> btw: any progress with the futexes?

Not much ... sorry.

--

-- 
Nicolas Joly

Re: vwakeup: neg numoutput

On Mon, Jun 30, 2008 at 09:10:09PM +0200, Manuel Bouyer wrote:
> On Mon, Jun 30, 2008 at 10:27:07AM -0700, Bill Stouder-Studenmund wrote:
> > > > Would this be a good candidate for the atomic update operations? That way 
> > > > you don't need a lock.
> > > 
> > > Could be, but then it needs to be updated atomically everywhere.
> > 
> > Right.
> > 
> > But if you can't take a lock, then you need to do something.  And 
> > either cscope or eid (probably eid) can help you change the whole tree at 
> > once.
> 
> I don't know either, but I can do it with grep :)
> 
> I don't know how to translate this kind of construct then:
>                 mutex_enter(&vp->v_interlock);
> 		while (vp->v_numoutput > 0)
> 			cv_wait(&vp->v_cv, &vp->v_interlock);
> 		mutex_exit(&vp->v_interlock);

You would have to hold the lock to move v_numoutput from a non-zero value to
to zero.

> they're used in several places. There are also places where it seems it's
> expected to have vp->v_numoutput stable for several lines of code:

> vfs_subr2.c:
>         mutex_enter(&vp->v_interlock);
> 		while (vp->v_numoutput != 0)

Re: vwakeup: neg numoutput

On Tue, Jul 01, 2008 at 10:16:16AM +0000, Andrew Doran wrote:
> > I don't know how to translate this kind of construct then:
> >                 mutex_enter(&vp->v_interlock);
> > 		while (vp->v_numoutput > 0)
> > 			cv_wait(&vp->v_cv, &vp->v_interlock);
> > 		mutex_exit(&vp->v_interlock);
> 
> You would have to hold the lock to move v_numoutput from a non-zero value to
> to zero.

OK, it's just a matter of keeping the mutex_* around v_numoutput--

> 
> > they're used in several places. There are also places where it seems it's
> > expected to have vp->v_numoutput stable for several lines of code:
> 
> > vfs_subr2.c:
> >         mutex_enter(&vp->v_interlock);
> > 		while (vp->v_numoutput != 0)
> > 			cv_wait(&vp->v_cv, &vp->v_interlock);
> > 	dirty = !LIST_EMPTY(&vp->v_dirtyblkhd);
> > 	mutex_exit(&vp->v_interlock);
> 
> You can't assume that with v_numoutput, it's only used to ensure that
> already in flight I/O operations have completed.

vfs_subr2.c has another place which makes me believe we can't use atomic ops
alone to incement v_numoutput:
315: KASSERT(vp->v_numoutput == 0 && LIST_EMPTY(&vp->v_dirtyblkhd));

revivesa status

I thought this would be a good time to give an update on the status of the 
wrstuden-revivesa branch.

I have been testing it on i386 inside of a VM Fusion virtual machine with 
two CPUs to the guest os.

As of this afternoon, it is passing all but one of the libpthread 
regression tests. Unfortunately the one we don't pass is resolv, the most 
complicated one. Alot of the recent code quality stems from running a 
LOCKDEBUG DEBUG DIAGNOSTIC kernel. 

Things that are needed:

1) Figure out the one remaining bug. It's manifested itself as either a 
lwp_locked(l, spc->spc_mutex) failed assertion at line 279 of kern_runq.c, 
or an attempt to deliver an upcall where both the event and interrupted 
thread are the same one.

This latter issue is REALLY weird. Threads that have blocked in the kernel
stop running when they wander into sa_unblock_userret(). They put
themselves on a sleep queue (used to hold threads that are waiting for
processing), then they should never run again until they've been reused.
To that end, the line of code after mi_switch() is lwp_exit(). "being
reused" involves a call to cpu_setfunc() which, as I understand it, resets
the whole stack. So there is no way an lwp should run while it's on the 
sleepq. Yet I occasionally see a trap getting serviced on this lwp, and 
trying to return to userland. That of course explodes.

I believe the problem is somewhere in my handling of sleep queues. I would 
appreciate suggestions.

Re: Newbie Kernel Programmer looking for first project.

I'm new to cvs, I  know I should be using cvs to modify
the kernel source but I've never used it before.
Could someone point me to a tutorial
for cvs for the way the netbsd project uses it?
I know I need to do the following
download the source (done, using anoncvs)
start modifying the source (cvs is used here somehow?)
make a diff
open a pr with the diff.

n Briggs <briggs <at> netbsd.org> wrote:
> On Mon, Jun 30, 2008 at 01:20:45PM -0700, Michael Litchard wrote:
>  > hmm, the only references I can find on how to cross-compile are
>  > daemonews ezine articles, and for whatever reason, I cannot rend those
>  > pages. Does anyone have a mirror to those files or pointers to similar
>  > docs?
>
>
> The standard build.sh build is essentially a cross-compile.  You can
>  either build for the same architecture that you're building, or you can
>  build for a different one by passing a different -m <arch>, but in
>  either case, it's set up as a cross-compile.  Just take a look at the
>  "BUILDING" file in src.
>
>  -allen
>
>
>  --
>  Allen Briggs  |  http://www.ninthwonder.com/~briggs/  |  briggs <at> ninthwonder.com
>

Re: Newbie Kernel Programmer looking for first project.

Michael Litchard wrote:
> I'm new to cvs, I  know I should be using cvs to modify
> the kernel source but I've never used it before.
> Could someone point me to a tutorial
> for cvs for the way the netbsd project uses it?
> I know I need to do the following
> download the source (done, using anoncvs)
> start modifying the source (cvs is used here somehow?)

Just modify the file, no cvs commands necessary.

> make a diff

cvs diff -u filename

> open a pr with the diff.

send-pr, use your favourite $EDITOR to import the diff into the problem 
report template.

Cheers,
Jared

Re: Newbie Kernel Programmer looking for first project.

On Tuesday, 1 Jul 2008 10:16:47
"Michael Litchard" <michael <at> schmong.org> wrote:

> I'm new to cvs [...]

If you created any new files you might also want to use the -N flag
to cvs diff in addition to -u
--

-- 
Matthew Mondor