Re: half-fix for stream.c

[Don Lewis]

On Jan 20,  5:41pm, Alfred Perlstein wrote:
} Subject: half-fix for stream.c
} you can find it at:
} 
} http://www.freebsd.org/~alfred/tcp_fix.diff

Don't you want to defer the checksum even further (after the bogus
packets have been dropped)?  It doesn't look like the change you
made will save any unnecessary work.

Also, it looks like you can save a few CPU cycles by only searching
for wildcard sockets if the SYN flag is set, so only set the 6th
argument to in_pcblookup_hash() if (thflags & TH_SYN) is true.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)

[Don Lewis]

On Jan 22,  5:04pm, Alex Zepeda wrote:
} Subject: Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip

} What if we began to use bzip2 instead of gzip for things like man pages,
} or releases, etc?

Doesn't bzip2 require a lot more memory for decompression?  As I
recall, someone mentioned that this would cause problems for installing
releases on machines with only a small amount of RAM.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Crashing netscape?

[Don Lewis]

On Feb 21,  7:51pm, Alex Le Heux wrote:
} Subject: Crashing netscape?
} Hi,
} 
} Am I the only one who's experiencing an amzing amount of crashes on
} Netscape?
} 
} It's been going on for quite some time now (months), upgrading Netscape or
} switching from the Linux to the FreeBSD to the BSDI version doesn't help.
} The most stable version seems to be the Linux version, but that even
} crashes 5-10 times per day. It will *always* crash when a page uses java,
} but I've not been able to find a non-java page that will always crash it.

Have you tried "netscape -sync"?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

current hangs during boot if ET/5025-16 card is installed

[Don Lewis]

I happened to try to install 4.0-CURRENT on a box that has an
Emerging Technologies ET/5025-16 ISA card installed and found that
the kernel wedges during boot.  It hangs hard and won't respond to
anything except the reset switch.  The motherboard is an Asus P3B-F
and I believe I have the BIOS propery configured with the correct
settings to match the IRQ and memory addresses used by the ET card.

I also discovered that older versions of -CURRENT will boot correctly
on this box.  I did a binary search on the -CURRENT snapshots and found
that the floppies from the January 12th and earlier snapshots boot,
while the floppies from the January 14th and later snapshots hang.

Here's the dmesg.boot file that I get by doing a "boot -v" with
using late January kernel with the offending card removed.  With
the card installed, the boot process gets as far as
Trying Read_Port at 3c3
but doesn't get to
isa_probe_children: disabling PnP devices


drtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
map[20]: type 1, range 32, base d800, size  4
found-> vendor=0x8086, dev=0x7112, revid=0x01
class=0c-03-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=d, irq=255
map[20]: type 1, range 32, base d400, size  5
found-> vendor=0x8086, dev=0x7113, revid=0x02
class=06-80-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
map[90]: type 1, range 32, base e800, size  4
found-> vendor=0x8086, dev=0x1229, revid=0x08
class=02-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=9
map[10]: type 1, range 32, base e180, size 12
map[14]: type 1, range 32, base d000, size  6
map[18]: type 1, range 32, base e100, size 20
found-> vendor=0x8086, dev=0x1229, revid=0x08
class=02-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=15
map[10]: type 1, range 32, base e080, size 12
map[14]: type 1, range 32, base b800, size  6
map[18]: type 1, range 32, base e000, size 20
found-> vendor=0x8086, dev=0x1229, revid=0x08
class=02-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=10
map[10]: type 1, range 32, base df80, size 12
map[14]: type 1, range 32, base b400, size  6
map[18]: type 1, range 32, base df00, size 20
found-> vendor=0x8086, dev=0x1229, revid=0x08
class=02-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=11
map[10]: type 1, range 32, base de80, size 12
map[14]: type 1, range 32, base b000, size  6
map[18]: type 1, range 32, base de00, size 20
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
found-> vendor=0x104c, dev=0x3d07, revid=0x01
class=03-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=11
map[10]: type 1, range 32, base e300, size 17
map[14]: type 1, range 32, base e280, size 23
map[18]: type 1, range 32, base e200, size 23
pci1:  on pcib1
vga-pci0:  mem 
0xe200-0xe27f,0xe280-0xe2ff,0xe300-0xe301 irq 11 at device 0.0 
on pci1
isab0:  at device 4.0 on pci0
isa0:  on isab0
ata-pci0:  port 0xd800-0xd80f at device 4.1 on pci0
ata-pci0: Busmastering DMA supported
ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xd800
ata0: mask=03 status0=50 status1=50
ata0: mask=03 status0=50 status1=00
ata0: devices = 0x9
ata0 at 0x01f0 irq 14 on ata-pci0
ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xd808
ata1: mask=00 status0=ff status1=ff
pci0: Intel 82371AB/EB (PIIX4) USB controller (vendor=0x8086, dev=0x7112) at 4.2
chip1:  port 0xe800-0xe80f at device 4.3 on 
pci0
fxp0:  port 0xd000-0xd03f mem 
0xe100-0xe10f,0xe180-0xe1800fff irq 9 at device 9.0 on pci0
fxp0: Ethernet address 00:90:27:c6:bb:b8
bpf: fxp0 attached
fxp1:  port 0xb800-0xb83f mem 
0xe000-0xe00f,0xe080-0xe0800fff irq 15 at device 10.0 on pci0
fxp1: Ethernet address 00:90:27:c6:bc:b9
bpf: fxp1 attached
fxp2:  port 0xb400-0xb43f mem 
0xdf00-0xdf0f,0xdf80-0xdf800fff irq 10 at device 11.0 on pci0
fxp2: Ethernet address 00:90:27:c6:bc:c0
bpf: fxp2 attached
fxp3:  port 0xb000-0xb03f mem 
0xde00-0xde0f,0xde80-0xde800fff irq 11 at device 12.0 on pci0
fxp3: Ethernet address 00:90:27:c6:a6:12
bpf: fxp3 attached
Trying Read_Port at 203
Trying Read_Port at 243
Trying Read_Port at 283
Trying Read_Port at 2c3
Trying Read_Port at 303
Trying Read_Port at 343
Trying Read_Port at 383
Trying Read_Port at 3c3
isa_probe_children: disabling PnP devices
isa_probe_children: probing non-PnP devices
fe0: not probed (disabled)
fdc0:  at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
a

4.0-CURRENT hangs in ex_isa_identify() (was: current hangs during boot if ET/5025-16 card is installed)

[Don Lewis]

On Mar 2,  4:09am, Don Lewis wrote:
} Subject: current hangs during boot if ET/5025-16 card is installed
} 
} I happened to try to install 4.0-CURRENT on a box that has an
} Emerging Technologies ET/5025-16 ISA card installed and found that
} the kernel wedges during boot.  It hangs hard and won't respond to
} anything except the reset switch.  The motherboard is an Asus P3B-F
} and I believe I have the BIOS propery configured with the correct
} settings to match the IRQ and memory addresses used by the ET card.
} 
} I also discovered that older versions of -CURRENT will boot correctly
} on this box.  I did a binary search on the -CURRENT snapshots and found
} that the floppies from the January 12th and earlier snapshots boot,
} while the floppies from the January 14th and later snapshots hang.

By adding a whole bunch of printf statements to the code, I was able
to track this problem to ex_isa_identify().  The ET card is jumpered
to I/O address 0x240, and it appears to consume 32 bytes starting at
this address.  When the ioport loop in ex_isa_identify() gets to 0x250,
look_for_card() appears to wedge.  I don't see how that can happen
unless the CPU gets stuck in inb().  I haven't looked at ISA hardware
in ages, can an ISA I/O read really hang forever?

What really sucks is that there is no way to disable the ex driver
at boot time, so the standard install floppies can no longer be used
to boot a box that contains one of these ET cards.

Should the ex driver be doing all this stuff at identify time, or was
the older method of doing this at probe time more correct?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 4.0-CURRENT hangs in ex_isa_identify() (was: current hangs during boot if ET/5025-16 card is installed)

[Don Lewis]

On Mar 3, 11:16am, "Matthew N. Dodd" wrote:
} Subject: Re: 4.0-CURRENT hangs in ex_isa_identify() (was: current hangs du
} On Fri, 3 Mar 2000, Don Lewis wrote:
} > What really sucks is that there is no way to disable the ex driver
} > at boot time, so the standard install floppies can no longer be used
} > to boot a box that contains one of these ET cards.
} > 
} > Should the ex driver be doing all this stuff at identify time, or was
} > the older method of doing this at probe time more correct?
} 
} Thats really the only place for such a routine.  What needs to happen is
} for if_ex to a little more selective about which addresses it
} probes.  While it is using a non-destructive probe (see
} look_for_card()) it should also use the resource manager to check and see
} if a port is assigned before it does anything else.

Unfortunately the GENERIC kernel doesn't have a driver that could claim
the ET card.  Also ex_isa_identify() is called before the legacy ISA
probes are done.

IMHO, the best way to fix this would be for the dual-mode PnP/legacy
drivers to identify any cards in PnP mode, then do legacy ISA probes
using the old hard-wired port numbers, where legacy ISA probes can
be controlled by userconfig.  This is really ugly, but then we all
agree that ISA sucks.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Why not gzip iso images?

[Don Lewis]

On Mar 15,  9:03am, Kris Kennaway wrote:
} Subject: Re: Why not gzip iso images?
} On Wed, 15 Mar 2000, Alfred Perlstein wrote:
} 
} > I feel pretty confident assuming that most people that burn ISOs probably
} > keep enough disk space free to hold one and not much more, going from
} > a requirement of ~650MB to ~1.2GB wouldn't be a smart move imo.
} 
} fetch -o - ftp://path/to/iso.gz | gunzip -c - > /path/to/image.iso

This doesn't allow you to restart a failed transfer, which you might
want to be able to do if it takes two or three days to transfer the
entire file.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: kern/8324

[Don Lewis]

On Mar 17,  6:27pm, Alfred Perlstein wrote:
} Subject: Re: kern/8324
} * Archie Cobbs <[EMAIL PROTECTED]> [000317 17:55] wrote:
} > This bug has been around since at least 2.2.6 and is still present
} > in RELENG_3, RELENG_4, and -current.
} > 
} >   http://www.freebsd.org/cgi/query-pr.cgi?pr=8324
} > 
} > Is anyone planning to tackle it? What would be required to fix it?
} > (it's not clear (to me anyway) from Bruce's description how hard
} > this is to fix..)

I never heard of using SIGIO for output, but section 6.4 of the daemon
book says that SIGIO is sent "when a read or write becomes possible".
On the other hand, section 10.8 (Terminal Operations) mentions SIGIO 
for input but not for output.  I also looked at rev 1.1 of kern/tty.c
and it only sends a SIGIO when input is ready, so this seems to be
the historical behaviour, so I'm suprised that this program even
worked with plain tty devices.

} I think Bruce sort of went off into a tangent with his diagnosis,
} anyhow this is untested (of course :) ), but looks like the right
} thing to do (from sys_pipe.c).
} 
} Perhaps the fcntls and ioctls aren't being propogated enough to set
} the flags properly, but if they are then it should work sort of the
} way SIGIO does, basically generating a signal for /some condition/
} on a descriptor.

This patch (vs the 3.4-STABLE version of tty.c) causes SIGIO to be
sent when a regular or pseudo tty becomes writeable.


--- tty.c.orig  Sun Aug 29 09:26:09 1999
+++ tty.c   Sat Mar 18 03:09:32 2000
@@ -2133,6 +2133,8 @@
 
if (tp->t_wsel.si_pid != 0 && tp->t_outq.c_cc <= tp->t_olowat)
selwakeup(&tp->t_wsel);
+   if (ISSET(tp->t_state, TS_ASYNC) && tp->t_sigio != NULL)
+   pgsigio(tp->t_sigio, SIGIO, (tp->t_session != NULL));
if (ISSET(tp->t_state, TS_BUSY | TS_SO_OCOMPLETE) ==
TS_SO_OCOMPLETE && tp->t_outq.c_cc == 0) {
CLR(tp->t_state, TS_SO_OCOMPLETE);


BTW, I had to add:
fcntl(1, F_SETOWN, getpid());
to the test program since there is no longer a default target to send
the signal to.  The old scheme had the defect of sending SIGIO to the
process group that owned the terminal, which implied that the terminal
had to be the controlling terminal for the process group.  This limited
a process to only receiving SIGIO from one terminal device even if it
had more than one open and it wanted to receive SIGIO from all of them.
Also, SIGIO was sent to the entire process group, but it may be desireable
to limit this to one process.  I wonder if it might make sense to go
back to the old default for tty devices so that processes only receive
SIGIO when they are in the foreground ...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: More benchmarking stuff...

[Don Lewis]

On Sep 17,  2:03pm, Brad Knowles wrote:
} Subject: Re: More benchmarking stuff...
} 
}   Sadly, when I go to the second set of tests (20,000 files and 
} 50,000 transactions), my performance goes into the crapper.  I know 
} that softupdates trades memory for speed, and I guess this PPro 200 
} w/ 128MB RAM just doesn't have enough memory to keep up.
} 
}   For this stage, I now get:
} 
}   Transactions per second:33
}   KBytes Read per second: 79.66
}   KBytes Written per second:  144.31

I'd expect a NetApp to do a lot better than UFS on FreeBSD if there are
large directories.  Directory lookups in UFS require a sequential scan
whereas the NetApp filesystem uses some sort of hashing scheme.

Also FreeBSD only caches a limited number of directory blocks.   This
was discussed on -hackers in April.  Search for the subject "Directories
not VMIO cached at all!".  Matt Dillon posted a patch to to better
cache directories (at the possible expense of wasted RAM and which breaks
NFS) in Message-ID <[EMAIL PROTECTED]>.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: sigset_t changes committed

[Don Lewis]

On Sep 30, 11:24pm, Marcel Moolenaar wrote:
} Subject: Re: HEADS UP: sigset_t changes committed

} As for me, I'm trying to define the problem as detailed and consise as
} possible. I already have some specific thoughts and ideas. I'm thinking
} large here: real cross-compilation capabilities and such (it may be
} handy for FreeBSD/IA64)...

While proper cross-compilation would be really nice to have, it won't solve
the "make world" problem.  It would get you through "make buildworld", but
"make installworld" will overwrite the system binaries with new versions that
use the new signal syscalls that the currently running kernel doesn't support.
It would even be possible to cross-compile a new kernel, but it still has
to be installed and the system rebooted before installing userland.

In this particular case, the only thing cross-compilation would buy us
is the ability to build (but not install) 4.x binaries on a machine
running 3.x.  It sounds like some folks would be satisfied just having
that.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: sigset_t changes committed

[Don Lewis]

On Sep 30,  4:14pm, John-Mark Gurney wrote:
} Subject: Re: HEADS UP: sigset_t changes committed
} > 
} > In this particular case, the only thing cross-compilation would buy us
} > is the ability to build (but not install) 4.x binaries on a machine
} > running 3.x.  It sounds like some folks would be satisfied just having
} > that.
} 
} I'm sorry, this is easy to fix... have a set of tools you copy to /ibin
} that are used for the install (all staticly compiled binaries hopefully)
} and run the install world out of /ibin...  maybe include some binaries
} for system recovery to make sure...

... but as soon as you run the stuff in /ibin to install the new userland,
you won't even be able to run a shell script, because the newly installed
/bin/sh will be using the new signal syscalls.  The install process will
have to include installing a new kernel and will have to be followed by
an immediate reboot.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: kern/8324

[Don Lewis]

On Mar 20, 11:00am, Archie Cobbs wrote:
} Subject: Re: kern/8324
} Don Lewis writes:

} > This patch (vs the 3.4-STABLE version of tty.c) causes SIGIO to be
} > sent when a regular or pseudo tty becomes writeable.
} > 
} > 
} > --- tty.c.orig  Sun Aug 29 09:26:09 1999
} > +++ tty.c   Sat Mar 18 03:09:32 2000
} > @@ -2133,6 +2133,8 @@
} >  
} > if (tp->t_wsel.si_pid != 0 && tp->t_outq.c_cc <= tp->t_olowat)
} > selwakeup(&tp->t_wsel);
} > +   if (ISSET(tp->t_state, TS_ASYNC) && tp->t_sigio != NULL)
} > +   pgsigio(tp->t_sigio, SIGIO, (tp->t_session != NULL));
} > if (ISSET(tp->t_state, TS_BUSY | TS_SO_OCOMPLETE) ==
} > TS_SO_OCOMPLETE && tp->t_outq.c_cc == 0) {
} > CLR(tp->t_state, TS_SO_OCOMPLETE);
} > 
} > 
} > BTW, I had to add:
} > fcntl(1, F_SETOWN, getpid());
} > to the test program since there is no longer a default target to send
} > the signal to.  The old scheme had the defect of sending SIGIO to the
} > process group that owned the terminal, which implied that the terminal
} > had to be the controlling terminal for the process group.  This limited
} > a process to only receiving SIGIO from one terminal device even if it
} > had more than one open and it wanted to receive SIGIO from all of them.
} > Also, SIGIO was sent to the entire process group, but it may be desireable
} > to limit this to one process.  I wonder if it might make sense to go
} > back to the old default for tty devices so that processes only receive
} > SIGIO when they are in the foreground ...
} 
} Don-
} 
} After applying your patch to kern/tty.c and adding the F_SETOWN,
} the problem indeed seems to go away..
} 
} Is this patch ready to be committed, or do we need more reviewers?

Sorry for the delay, I was out of town most of last week and sick most
of this week.

It's probably safe to commit to -current if someone can give it a quick
test there.  Unfortunately I don't have a box running -current to test
it on.

Now, on to some more of my 6280 unread email messages :-(



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cvs commit: src/sys/contrib/softupdates softdep.h ffs_softdep.c

[Don Lewis]

On Jun 22, 10:30am, Adrian Chadd wrote:
} Subject: Re: cvs commit: src/sys/contrib/softupdates softdep.h ffs_softdep
} 
} [shifting conversation to -current .. ]
} 
} On Thu, Jun 22, 2000, Anders Andersson wrote:
} > on Tor, Jun 22, 2000 at 01:46:34pm +0900, Akinori -Aki- MUSHA wrote:
} > > 
} > > Yes, it has been working quite stably here too.  Besides, one must do
} > > a "tunefs -n enable" for every partition that he or she wants to do
} > > softupdates anyway, so just adding the support for softupdates to the
} > > GENERIC kernel won't hurt anyone who don't want to turn that feature
} > > on by default, except a little code increase.
} > 
} > Please take a look at what NetBSD just recently did:
} > http://www.netbsd.org/Changes/#softdepsmount
} > 
} > These changes disables the whole 'tunefs' process, and let you control
} > softupdates state with mount, (-o softdep). So all you have to do is to
} > tune your /etc/fstab to enable softupdates. I think this will make it
} > more easy to enable SOFTUPDATES by default.
} 
} I like this. Would anyone object if this was brought over from NetBSD ?

I'm pretty sure that Kirk had some reason for using tunefs.  It might take
me a while to dig up the information, though, assuming I still have it.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cvs commit: src/sys/contrib/softupdates softdep.h ffs_softdep.c

[Don Lewis]

On Jun 22,  2:21am, Don Lewis wrote:
} Subject: Re: cvs commit: src/sys/contrib/softupdates softdep.h ffs_softdep
} On Jun 22, 10:30am, Adrian Chadd wrote:
} } Subject: Re: cvs commit: src/sys/contrib/softupdates softdep.h ffs_softdep
} } 
} } [shifting conversation to -current .. ]
} } 
} } On Thu, Jun 22, 2000, Anders Andersson wrote:

} } > Please take a look at what NetBSD just recently did:
} } > http://www.netbsd.org/Changes/#softdepsmount
} } > 
} } > These changes disables the whole 'tunefs' process, and let you control
} } > softupdates state with mount, (-o softdep). So all you have to do is to
} } > tune your /etc/fstab to enable softupdates. I think this will make it
} } > more easy to enable SOFTUPDATES by default.
} } 
} } I like this. Would anyone object if this was brought over from NetBSD ?
} 
} I'm pretty sure that Kirk had some reason for using tunefs.  It might take
} me a while to dig up the information, though, assuming I still have it.

Found it, see
<http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=106647+109142+/usr/local/www/db/text/1998/freebsd-current/19980510.freebsd-current>.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: Using serial console to debug system hangs ...

[Don Lewis]

On Mar 3,  9:20pm, John Baldwin wrote:
} Subject: RE: Using serial console to debug system hangs ...
} 
} On 04-Mar-01 The Hermit Hacker wrote:
} > 
} > Wow, that was painful ... after 2 hrs, I got as far as:
} 
} Yeah, it spews out a lot of crap. :-/  You prolly want to use a 115200 serial
} console if at all possible.  Should've mentioned that earlier..

.. so I shouldn't plan in using my ASR-33 for this, I guess.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: /usr/local/etc/rc.d and /etc/rc.d

[Don Lewis]

On Sep 9, 12:05am, Matthew Thyer wrote:
} Subject: Re: /usr/local/etc/rc.d and /etc/rc.d
} Neil Blakey-Milner wrote:

} > I'd prefer a dependency based system.  (cf. Eivind Eklund's newrc, at
} > http://people.FreeBSD.org/~eivind/newrc.tar.gz)

How does this compare with what NetBSD implemented?

} I haven't looked at this yet but off the top of my head, a dependency
} based system sounds overly complicated (consider ports authors) and
} unecessarily different from other systems.

NetBSD switched to a dependency based system a while back.  Judging by
the traffic on their mail lists, it was somewhat controversial ...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Repeated panic out of chgsbsize

[Don Lewis]

On Sep 29, 11:30am, Greg Lehey wrote:
} Subject: Repeated panic out of chgsbsize
} In the past couple of days, I've had a couple of panics out of chgsbsize:
} 
} (kgdb) bt

 [ snip ]

} #12 0xc01cbac9 in panic (fmt=0xc0356920 "reducing sbsize: lost count, uid = %d") at 
../../kern/kern_shutdown.c:553
} #13 0xc01c8d7b in chgsbsize (uid=50, diff=-17520, max=9223372036854775807) at 
../../kern/kern_proc.c:206
} #14 0xc01ee6aa in sbrelease (sb=0xcdc091f4, so=0xcdc09180) at 
../../kern/uipc_socket2.c:453
} #15 0xc01eb9fb in sofree (so=0xcdc09180) at ../../kern/uipc_socket.c:261
} #16 0xc0221e0b in in_pcbdetach (inp=0xce1c3aa0) at ../../netinet/in_pcb.c:542
} #17 0xc022c462 in tcp_close (tp=0xce1c3b60) at ../../netinet/tcp_subr.c:711
} #18 0xc0229bf6 in tcp_input (m=0xc0e96500, off0=20, proto=6) at 
../../netinet/tcp_input.c:2012
} #19 0xc02247ee in ip_input (m=0xc0e96500) at ../../netinet/ip_input.c:756
} #20 0xc022484b in ipintr () at ../../netinet/ip_input.c:784
} #21 0xc0309195 in swi_net_next ()

That version of the per-uid accounting implementation has some race
conditions between the kernel top and bottom halves.  I'd recommend
upgrading to PRE_SMPNG.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: installworld failure - libsdbm.a

[Don Lewis]

On Nov 4, 11:54am, Kent Stewart wrote:
} Subject: Re: installworld failure - libsdbm.a
} 
} 
} Steven Farmer wrote:
} > 
} > After this morning's cvsup and buildworld, installworld failed trying
} > to build libsdbm.a.  I worked around the problem by adding chmod to
} > Makefile.inc1 as shown below.  BTW - isn't it kind of wierd for a
} > library to be _built_ at installworld time?
} 
} Yes, it is. It is supposed to be build in buildworld where is also
} chmod'ed appropriately. Something triggers the build during
} installworld, which is a place they don't want to add chmod to. I have
} had it hit me once.

I had the same thing happen to me yesterday abuse six hours into
a -current "make release".  The problem didn't recur when I reran
"make release".  One possible quirk is that I am mounting the scratch
area from a 4.1-stable NFS server.  Notice that only the .a file is
getting built, and not the .o files.  I suspect that the file
timestamps are getting messed up, causing make to rebuild the .a
file.

} I added chmod to the progs line like you did and
} it did the build. I have an idea that something didn't trigger the
} build in buildworld and it was needed during the installworld. It has
} never been a problem since. I had a patch like you created and ran it
} after every cvsup but then I found out that I didn't need it. I
} capture the make output for buildworld and installworld and it hasn't
} failed since I started doing that.
} 
} Kent
} 
} > 
} > Cheers,
} > 
} > Steve
} > 
} > -
} > ===> gnu/usr.bin/perl/library/SDBM_File
} > cd /usr/obj/usr/src/gnu/usr.bin/perl/library/SDBM_File/ext/SDBM_File ; make -B 
install  INSTALLPRIVLIB=/usr/libdata/perl/5.00503  
INSTALLARCHLIB=/usr/libdata/perl/5.00503/mach
} > cd sdbm && make all
} > rm -rf libsdbm.a
} > ar cr libsdbm.a sdbm.o  pair.o  hash.o && : libsdbm.a
} > chmod 755 libsdbm.a
} > chmod:No such file or directory
} > *** Error code 1


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: keymaps

[Don Lewis]

On Jan 21,  9:40pm, Warner Losh wrote:
} Subject: Re: keymaps
} In message <199901220043.laa22...@lightning.itga.com.au> Gregory Bond writes:
} : my vote: A version of the standard keymap with CapsLock and LeftCtl
} : functions swapped so the control key is under my left finger like
} : God intended!
} 
} What's wrong with us.unix.kbd?

Two things for me:

It's not in the sysinstall menu.

I'm not sure I like the Esc <-> ~` swap.  

Does anyone know of any decent PC keyboards with a Unix-friendly layout?
I'm pretty happy with the layout on a Sun Type-5 keyboard, which puts
Esc right above Tab and to the left of 1 (where PC's generally have ~`).
The Return key is wide, but is confined to the home row, and Backspace
is also wide and is in the row immediately above it.  This leaves room
in the top row (below the function keys, where  PC's put Backspace),
for |\, which PC keyboards put in various random places, and ~`.

To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Heads up! New swapper and VM changes have been committed to -4.x

[Don Lewis]

On Jan 26, 12:20pm, Dag-Erling Smorgrav wrote:
} Subject: Re: Heads up! New swapper and VM changes have been committed to -
} Brian Feldman  writes:
} > On 24 Jan 1999, Dag-Erling Smorgrav wrote:

} > > These are dynamically linked, and will automatically pick up the new
} > > libkvm.
} > But (most) still require the structures to be the exact same way,
} > which is the reason for the recompile anyway... don't forget that!
} 
} No, because the libkvm interface has not changed, only its internals.
} libkvm must be updated to be able to talk to the kernel, and
} applications which use it must be relinked with it. In the case of
} dynamically linked applications, this is done automatically at load
} time. Or am I reading this wrong?

It depends on what has changed.  If the application asks libkvm to
fetch some structure from the kernel, and the application's idea of
what the structure looks like is different that what is compiled into
the kernel and libkvm, the application will not work correctly.  For
instance, if the layout of the proc structure changes, an application
that was compiled with the old structure definition that calls
kvm_getprocs() will get a pointer to a structure with the new layout.
When the application dereferences the pointer that kvm_getprocs() returns
at some offset into the structure, it will be looking at some other part
of the proc structure than what it wants.

To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: btokup().. patch to STYLE(9) (fwd)

[Don Lewis]

On Jan 29, 12:05pm, Sheldon Hearn wrote:
} Subject: Re: btokup().. patch to STYLE(9) (fwd)

} The reason I'm interested in this (now tiresome) thread is that I'd much
} rather have to read
} 
}   /*
}* Bail out if the time left to next transaction is less than
}* the duration of the previous transaction.
}*/
}   if (t % u - n % u < d % u) {
} 
} than
} 
}   if (((t % u) - (n % u)) < (d % u)) {
} 
} Giving folks the go-ahead to use parens as a form of documentation is
} misguided and will end in tears. MHO.

This is a fairly trivial example, but I find the second version slightly
easier to read at a glance.  I do think it's overly parenthesized, though.
I prefer

if ((t % u - n % u) < (d % u)) {

or 

if ((t % u - n % u) < d % u) {

because they are less cluttered.

To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: btokup().. patch to STYLE(9) (fwd)

[Don Lewis]

On Jan 29,  9:13am, Poul-Henning Kamp wrote:
} Subject: Re: btokup().. patch to STYLE(9) (fwd)
} 
} On the other hand style(9) should still firmly outlaw stuff like:
} 
}   /* wait 10 ms */
}   if (((error = tsleep((caddr_t)dev, PPBPRI | PCATCH,
}   "ppbpoll", hz/100)) != EWOULDBLOCK) != 0) {
}   return (error);
}   }

The "!= 0" is obviously bogus, but what about:

if ((error = tsleep((caddr_t)dev, PPBPRI | PCATCH, "ppbpoll", hz/100))
!= EWOULDBLOCK) {
return (error);
}

It would be better if the "!=" fit on the previous line.

What if the expression fit on one 80 character line?

BTW, something I like that I picked up from Paul Vixie's code is indenting
all the arguments to a function by the same amount.  Forcing an unneccesary
line wrap:

if ((error = tsleep((caddr_t)dev, PPBPRI | PCATCH,
"ppbpoll", hz/100)) != EWOULDBLOCK) {
return (error);
}

which isn't real clean because of the trailing "!= EWOULDBLOCK".  The
downside of this style is that some arguments won't fit in the available
space or the argument list will occupy quite a few lines if the arguments
start too far to the right.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: btokup().. patch to STYLE(9) (fwd)

[Don Lewis]

On Jan 29,  8:34am, Brian Somers wrote:
} Subject: Re: btokup().. patch to STYLE(9) (fwd)
} 
} My argument is that this sort of thing gets out of hand.  I've seen 
} things such as
} 
}   if (((a == b) || (c == d)))
} 
} where a, b, c & d are just simple variables - there are so many 
} redundant brackets that you have to double-check that there isn't 
} some weird grouping

You can pretty clearly dump the outer parens, since it makes no sense
to write "(expression)" instead of "expression".  In general, "a OP b"
should not be parenthesized if both "a" and "b" are atoms unless the
context requires it.

In general my preferred style doesn't use parentheses in expressions
using "+-*/" according to their naturual precedence rules.  I might
drop the whitespace around "*", just like you'd write "2n" in mathematics.
Likewise, I don't use parentheses in logical expressions or bitwise
expressions where the terms are atoms.  Expressions used as terms in
logical expressions or comparision expressions might be parenthesized
if they are complicated so I can find the extent of the expression by
using '%' in vi.  I always parenthesize the interfaces between bitwise
and other expressions, since K&R admits that C botched the precedence
of the bitwise operators and this seems to be one common place for
bugs to occur.  In general, I always parenthesize non-atomic arguments to
the shift and ternary operators.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Slow seq. write on Seagate ST36530N

[Don Lewis]

On Feb 19,  2:15pm, "Kenneth D. Merry" wrote:
} Subject: Re: Slow seq. write on Seagate ST36530N
} 
} The Write Cache Enable (WCE) bit is in mode page 8.  To check it:
} 
} camcontrol modepage -n da -u 1 -v -m 8
} 
} To edit the mode page:
} 
} camcontrol modepage -n da -u 1 -v -m 8 -e

To make this change permanent, you need to do

camcontrol modepage -n da -u 1 -v -m 8 -e -P 3


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: LOR tcp_input.c vs. tcp_usrreq.c (was: Re: 2 LORs on my NFSserver.)

[Don Lewis]

On 16 Aug, Tilman Linneweh wrote:
> * Tilman Linneweh [Fr, 15 Aug 2003 at 16:17 GMT]:
>> 
>> My CURRENT is already a bit old:
>> 
>> # uname -a
>> FreeBSD polly.arved.de 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Sun Jul 20
>> 01:00:14 CEST 2003
>> [EMAIL PROTECTED]:/usr/obj/usr/src/CURRENT/sys/POLLY  i386
> 
> I updated my CURRENT to 
> 
> polly# uname -a
> FreeBSD polly.arved.de 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Sat Aug 16
> 10:11:52 CEST 2003
> [EMAIL PROTECTED]:/usr/obj/usr/source/CURRENT/sys/POLLY  i386
> 
> and this LOR is reproducable. 
>  
>> This happend while the machine was NFS-serving around 3 clients with
>> normal udp NFS and a  fourth. client tried to mount something via
>> mount_nfs -T -a 2
> 
> The problem is the client with TCP mounts. I tried this time with a single
> NetBSD client that does a TCP mount and cd'd to the mounted directory.
> 
> lock order reversal
>  1st 0xc1a17278 inp (inp) @ /usr/source/CURRENT/sys/netinet/tcp_input.c:654
>  2nd 0xc046bd6c tcp (tcp) @ /usr/source/CURRENT/sys/netinet/tcp_usrreq.c:621
> Stack backtrace:
> backtrace(1,0,,c0445068,c04451d0) at backtrace+0x12
> witness_lock(c046bd6c,8,c03c334c,26d,0) at witness_lock+0x55e
> _mtx_lock_flags(c046bd6c,0,c03c334c,26d) at _mtx_lock_flags+0x7d
> tcp_usr_rcvd(c1ce8800,80) at tcp_usr_rcvd+0x1b
> soreceive(c1ce8800,c891ab1c,c891ab28,c891ab20,0) at soreceive+0x815
> nfsrv_rcv(c1ce8800,c1a70780,4) at nfsrv_rcv+0x75
> sowakeup(c1ce8800,c1ce884c) at sowakeup+0x7f
> tcp_input(c0b9ac00,14) at tcp_input+0x11f6
> ip_input(c0b9ac00) at ip_input+0x7c8
> swi_net(0) at swi_net+0xe6
> ithread_loop(c0b87180,c891ad48,c0b87180,c0221660,0) at ithread_loop+0x11c
> fork_exit(c0221660,c0b87180,c891ad48) at fork_exit+0xab
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0x1, eip = 0, esp = 0xc891ad7c, ebp = 0 ---
> Debugger("witness_lock")
> Stopped at  Debugger+0x45:  xchgl   %ebx,in_Debugger.0
> 

This is a known issue.

-- Forwarded message --
From: Don Lewis <[EMAIL PROTECTED]>
 Subject: Re: LOR in NFS server
Date: Thu, 24 Apr 2003 21:20:56 -0700 (PDT)
  To: [EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED]

On 24 Apr, Gordon Tetlow wrote:
> I generated it while running nessus against my local machine.
> 
> lock order reversal
>  1st 0xc9384c44 inp (inp) @ /local/usr.src/sys/netinet/tcp_input.c:649
>  2nd 0xc05aa84c tcp (tcp) @ /local/usr.src/sys/netinet/tcp_usrreq.c:621
> Stack backtrace:
> backtrace(c04e9f03,c05aa84c,c04f0770,c04f0770,c04f1ae4) at backtrace+0x17
> witness_lock(c05aa84c,8,c04f1ae4,26d,0) at witness_lock+0x692
> _mtx_lock_flags(c05aa84c,0,c04f1ae4,26d,0) at _mtx_lock_flags+0xb2
> tcp_usr_rcvd(c8a63800,80,c04ea514,df0e9a9c,3b9aca00) at tcp_usr_rcvd+0x30
> soreceive(c8a63800,df0e9ad8,df0e9ae4,df0e9adc,0) at soreceive+0x86a
> nfsrv_rcv(c8a63800,c6d4fb00,4,34,10430) at nfsrv_rcv+0x8a
> sowakeup(c8a63800,c8a6384c,c04f11d5,434,108) at sowakeup+0x97
> tcp_input(c21f5400,14,c0304f91,df0e9c5c,c02f60ba) at tcp_input+0x1341
> ip_input(c21f5400,0,c04efede,e9,c21bd280) at ip_input+0x7b0
> swi_net(0,0,c04e4eed,217,c21c73c0) at swi_net+0x111
> ithread_loop(c21c6100,df0e9d48,c04e4d5d,314,c21c8d10) at ithread_loop+0x16c
> fork_exit(c02ec2d0,c21c6100,df0e9d48) at fork_exit+0xc0
> fork_trampoline() at fork_trampoline+0x1a
> --- trap 0x1, eip = 0, esp = 0xdf0e9d7c, ebp = 0 ---


Hmn ... does NFS over TCP even work with a -current box as the server?
It looks like tcp_input() has grabbed the locks in tcbinfo and inp, and
then tcp_usr_rcvd() attempts to grab the same locks.


I can think of three possible ways of fixing this problem.

1) Drop the locks in tcp_input() before calling sorwakeup() and grab
   them again if necessary.  One has to be careful not to break
   anything by doing this.  This also adds overhead for non-NFS
   traffic.

2) Never call soreceive() from nfsrv_rcv(), always wake nfsd instead.
   This has the advantage of minimizing the amount of time that the
   locks are held, but increases overhead under lightly loaded
   conditions.

3) Somehow tell tcp_usr_rcvd() not to attempt to grab the locks in
   this specific case.

-- End forwarded message --

-- Forwarded message --
From: Jeffrey Hsu <[EMAIL PROTECTED]>
 Subject: Re: LOR in NFS server
Date: Fri, 25 Apr 2003 01:02:56 -0700
  To: [EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED]

  > 1st 0xc9384c44 inp (inp) @ /local/usr.src/sys/netinet/tcp_input.c:649
  > 2nd 0xc05aa84c tcp (tcp) @ /local/usr.src/sys/netinet/tcp_usrreq.c:621

This old nag warning has been there since last year and was first reported
by Lars Eggert <[EMAIL PROTECTED]>.  I ma

freebsd-current@freebsd.org

[Don Lewis]

On 19 Aug, Mark Sergeant wrote:
> Hi All,
> 
>   When trying to compile a kernel for my 8 cpu DELL 8450's I recieve an
> extremly puzzling error, I get a bunch of errors when compiling a kernel
> that has the following options in it...
> 
> options WITNESS
> options NETSMB
> options NETSMBCRYPTO
> options LIBMCHAIN
> options LIBICONV
> options PAE
> options SMP 
> options APIC_IO
> 
> Without  PAE SMP or APIC_IO the kernel will compile fine. With these
> options I get the following error when compiling the sym scsi driver.

Take a look at /usr/src/sys/i386/conf/PAE.  It says:

# What follows is a list of drivers that are normally in GENERIC, but either
# don't work or are untested with PAE.  Be very careful before enabling any
# of these drivers.  Drivers which use DMA and don't handle 64 bit physical
# address properly may cause data corruption when used in a machine with more
# than 4 gigabytes of memory.

and under this comment it lists the sym and usb drivers.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: make buildworld errors (libcam)

[Don Lewis]

On  3 Sep, Michael Bretterklieber wrote:
> Hi,
> 
> buildworld fails (cvsup some minutes ago):
> In file included from /usr/src/sys/cam/scsi/scsi_da.c:51:
> /usr/src/sys/sys/taskqueue.h:33:2: #error "no user-servicable parts
> inside"
> mkdep: compile failed

The following patch works for me:

Index: sys/cam/scsi/scsi_da.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.157
diff -u -r1.157 scsi_da.c
--- sys/cam/scsi/scsi_da.c  3 Sep 2003 04:46:28 -   1.157
+++ sys/cam/scsi/scsi_da.c  3 Sep 2003 07:35:54 -
@@ -48,7 +48,9 @@
 #include 
 #include 
 #include 
+#ifdef _KERNEL
 #include 
+#endif /* _KERNEL */
 
 #include 
 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

dirtybuf: 0xc643f000 interlock is not locked but should be

[Don Lewis]

I just upgraded to a fresh version of -current and started getting a lot
of these vnode lock violation messages when running with the
DEBUG_VFS_LOCKS kernel option.

I only ever saw the stack trace below, but it is not obvious to me that
other callers of getdirtybuf() would not have the same problem with the
vnode interlock.



dirtybuf: 0xc643f000 interlock is not locked but should be
Debugger("Lock violation.
")
Stopped at  Debugger+0x54:  xchgl   %ebx,in_Debugger.0
db> bt
No such command
db> tr
Debugger(c055816e,c0565751,c643f000,c05581a5,eb68) at Debugger+0x54
vfs_badlock(c05581a5,c0565751,c643f000,0,eba0) at vfs_badlock+0x45
assert_vi_locked(c643f000,c0565751,0,c61e8850,c0616f80) at assert_vi_locked+0x3a
getdirtybuf(ebb4,0,1,d2899610,1) at getdirtybuf+0xee
flush_deplist(c64532cc,1,ebdc,ebe0,0) at flush_deplist+0x43
flush_inodedep_deps(c641c000,6d45b,,c6507a44,124) at flush_inodedep_deps+0xa3
softdep_sync_metadata(eca4,0,c0565af4,124,0) at softdep_sync_metadata+0x87
ffs_fsync(eca4,c054a4a8,c0558b14,ad8,0) at ffs_fsync+0x3b9
fsync(c61e8850,ed10,c056cc5c,3eb,1) at fsync+0x1d4
syscall(2f,2f,2f,8054cdc,bfbfeda0) at syscall+0x273
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (95, FreeBSD ELF32, fsync), eip = 0x480cf38f, esp = 0xbfbfe7ec, ebp = 
0xbfbfedc8 ---

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ThinkPad R40 hangs during ACPI power down

[Don Lewis]

I've got an IBM ThinkPad R40 that hangs when I do a "shutdown -p".  It s
wedges after printing "Powering system off using ACPI".  The display
stays on, and judging by the heat, it seems that the CPU is on as well.
It doesn't respond to the keyboard, so I haven't been able to get into
DDB.  The only thing I can do at this point is to hold the power button
down to force it to power off.  The next boot is clean.

I've seen the same behaviour with September 8th and September 21st
versions of 5.1-CURRENT.

Attempting to use 'acpiconf -s" to suspend produces similar hangs.


I tried compiling a version of the kernel with the ACPI_DEBUG option
listed in NOTES, but buildkernel dies here:

cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstric
t-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fforma
t-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/src/sys -I/usr/src/sys/contri
b/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/u
sr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -
finline-limit=15000 -fno-strict-aliasing  -mno-align-long-strings -mpreferred-st
ack-boundary=2 -ffreestanding -Werror  /usr/src/sys/dev/acpica/acpi_button.c
/usr/src/sys/dev/acpica/acpi_button.c: In function `acpi_button_fixed_handler':
/usr/src/sys/dev/acpica/acpi_button.c:246: error: `_Dbg' undeclared (first use i
n this function)
/usr/src/sys/dev/acpica/acpi_button.c:246: error: (Each undeclared identifier is
 reported only once
/usr/src/sys/dev/acpica/acpi_button.c:246: error: for each function it appears i
n.)
*** Error code 1

Stop in /usr/obj/usr/src/sys/ACPI_DEBUG.
*** Error code 1

Stop in /usr/src.

NOTES says that to use this option, the Intel code must have the
USE_DEBUGGER flag set.  I didn't see references to this in the code, but
there are a bunch of #ifdefs that refer to ACPI_DEBUGGER.  I tried
adding this to my kernel configuration, but config barfs on it.

The APCI asl file is at 
and the dmesg.boot is at
.  I downloaded the
ACPI spec and attempted to use it to decipher my asl file, but I decided
it was hopeless since I didn't even know far the ACPI code was getting.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ThinkPad R40 hangs during ACPI power down

[Don Lewis]

On 25 Sep, Nate Lawson wrote:
>> I've got an IBM ThinkPad R40 that hangs when I do a "shutdown -p".  It
>> wedges after printing "Powering system off using ACPI".
>>
>> Attempting to use 'acpiconf -s" to suspend produces similar hangs.
> 
> Your system is halting correctly but powering off is failing.  A cursory
> glance at your ASL shows nothing particularly amiss.  It's very similar to
> my laptop (T23).
> 
>> I tried compiling a version of the kernel with the ACPI_DEBUG option
>> listed in NOTES, but buildkernel dies
> 
> This was fixed on Sept 21 so cvsup and recompile.  Set hw.acpi.verbose=1
> in loader.conf to get more messages.

I didn't get much more ...

acpi_cmbat1: battery initialization failed, giving up  
Waiting (max 60 seconds) for system process `vnlru' to stop...stopped  
Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped  
Waiting (max 60 seconds) for system process `syncer' to stop...stopped  
  
syncing disks, buffers remaining... 11 11   
done  
Uptime: 1m10s  
Powering system off using ACPI 


> To debug this, please boot a newer kernel with the ACPI_DEBUG option with
> the following options in loader.conf:
> 
> debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS"
> debug.acpi.level="ACPI_LV_FUNCTIONS"
> 
> You'll get spammed with way too many messages on boot but just ignore
> these.

You're not kidding.  I gave up after 2 hours and 7.5 MB of output.  It
looks like it's looping, see below ...


> Then do shutdown -p and log the printed messages (hopefully you
> have a serial console).
> 
> I'll map the debugging tunables to a sysctl since it would be better if
> you could just set this just before testing rather than for the full boot.

Yeah, that would be a lot better.



 psscope-0236 [10] PsPushScope   : Entry 0xc402e9a8
   SYNCH-0156 [11] AcpiOsWaitSemaphore   : Entry
   SYNCH-0162 [11] AcpiOsWaitSemaphore   : Exit- AE_OK
   SYNCH-0314 [11] AcpiOsSignalSemaphore : Entry
   SYNCH-0336 [11] AcpiOsSignalSemaphore : Exit- AE_OK
  utmisc-1062 [11] UtPushGenericState: Entry
  utmisc-1070 [11] UtPushGenericState: Exit-
 psscope-0271 [10] PsPushScope   : Exit- AE_OK
   SYNCH-0156 [10] AcpiOsWaitSemaphore   : Entry
   SYNCH-0162 [10] AcpiOsWaitSemaphore   : Exit- AE_OK
   SYNCH-0314 [10] AcpiOsSignalSemaphore : Entry
   SYNCH-0336 [10] AcpiOsSignalSemaphore : Exit- AE_OK
 psparse-0405 [10] PsNextParseState  : Entry 0xc403b128
 psparse-0501 [10] PsNextParseState  : Exit- AE_OK
  psargs-0489 [10] PsGetNextSimpleArg: Entry 0001
  psargs-0562 [10] PsGetNextSimpleArg: Exit-
 psparse-0405 [10] PsNextParseState  : Entry 0xc403b128
 psparse-0501 [10] PsNextParseState  : Exit- AE_OK
 psparse-0231 [10] PsCompleteThisOp  : Entry 0xc403b128
 psparse-0378 [10] PsCompleteThisOp  : Exit-
 psscope-0301 [10] PsPopScope: Entry
  utmisc-1093 [11] UtPopGenericState : Entry
  utmisc-1106 [11] UtPopGenericState : Exit- 0xc40248a8
  utmisc-1333 [11] UtDeleteGenericState  : Entry
   SYNCH-0156 [12] AcpiOsWaitSemaphore   : Entry
   SYNCH-0162 [12] AcpiOsWaitSemaphore   : Exit- AE_OK
   SYNCH-0314 [12] AcpiOsSignalSemaphore : Entry
   SYNCH-0336 [12] AcpiOsSignalSemaphore : Exit- AE_OK
  utmisc-1337 [11] UtDeleteGenericState  : Exit-
 psscope-0334 [10] PsPopScope: Exit-
 nsutils-0982 [10] NsOpensScope  : Entry Integer
 nsutils-0993 [10] NsOpensScope  : Exit-0   0
 psparse-0405 [10] PsNextParseState  : Entry 0xc402e9a8
 psparse-0501 [10] PsNextParseState  : Exit- AE_OK
 psparse-0231 [10] PsCompleteThisOp  : Entry 0xc402e9a8
  pswalk-0340 [11] PsDeleteParseTree : Entry 0xc402e9a8
  utmisc-1165 [12] UtCreateThreadState   : Entry
   SYNCH-0156 [13] AcpiOsWaitSemaphore   : Entry
   SYNCH-0162 [13] AcpiOsWaitSemaphore   : Exit- AE_OK
   SYNCH-0314 [13] AcpiOsSignalSemaphore : Entry
   SYNCH-0336 [13] AcpiOsSignalSemaphore : Exit- AE_OK
  utmisc-1181 [12] UtCreateThreadState   : Exit- 0xc40248a8
dswstate-0950 [12] DsCreateWalkState : Entry
   SYNCH-0156 [13] AcpiOsWaitSemaphore   : Entry
   SYNCH-0162 [13] AcpiOsWaitSemaphore   : Exit- AE_OK
   SYNCH-0314 [13] AcpiOsSignalSemaphore : Entry
   SYNCH-0336 [13] AcpiOsSignalSemaphore : Exit- AE_OK
dsmthdat-0158 [13] DsMethodDataInit  : Entry
dsmthdat-0186 [13] DsMethodDataInit  : Exit-
   SYNCH-0156 [13] AcpiOsWaitSemaphore   : Entry
   SYNCH-0162 [13] AcpiOsWaitSemaphore   : Exit- AE_OK
   SYNCH-0314 [13] AcpiOsSignalSemaphore : Entry
   SYNCH-0336 [13] AcpiOsSignalSemaphore : Exit- AE_OK
  utmisc-1062 [13] UtPushGenericState: Entry
  utmisc-1070 [13] UtPushGenericState: Exit-
dswstate-0872 [13] DsPushWalkState   : Entry
dswstate-0878 [13] DsPushWalkState   : 

Re: ThinkPad R40 hangs during ACPI power down

[Don Lewis]

On 26 Sep, To: [EMAIL PROTECTED] wrote:
> On 25 Sep, Nate Lawson wrote:

>> To debug this, please boot a newer kernel with the ACPI_DEBUG option with
>> the following options in loader.conf:
>> 
>> debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS"
>> debug.acpi.level="ACPI_LV_FUNCTIONS"
>> 
>> You'll get spammed with way too many messages on boot but just ignore
>> these.
> 
> You're not kidding.  I gave up after 2 hours and 7.5 MB of output.  It
> looks like it's looping, see below ...

I let it run overnight and it spewed 25 MB of output before I killed it.
It didn't get very far into the boot, just after the CPU is probed.  I
uploaded the full trace to
.

The system boots ok if I remove these two debug options.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Improvements to fsck performance in -current ...?

[Don Lewis]

On  2 Oct, Terry Lambert wrote:
> Jens Rehsack wrote:
>> Kevin Oberman wrote:
>> > Current has two major changes re speeding up fsck.
>> >
>> > The most significant is the background operation of fsck on file
>> > system with soft updates enabled. Because of the way softupdates
>> > works, you are assured of metadata consistency on reboot, so the file
>> > systems can be mounted and used immediately with fsck started up in
>> > the background about a minute after the system comes up.
>> 
>> Be careful what you promise :-)
>> Most new disks have an own disk cache and some of them have a
>> write cache enabled. In case of a hardware failure (or power
>> failure) this data may get lost and the disk's metadata isn't
>> consistent. It's only when no write cache below the system
>> is active.
> 
> Actually, write caching is not so much the problem, as the disk
> reporting that the write has completed before the contents of
> the transaction saved in the write cache have actually been
> committed to stable storage.
> 
> Unfortunately, IDE disks do not permit disconnected writes, due
> to a bug in the original IDE implementation, which has been
> carried forward for [insert no good reason here].
> 
> Therefore IDE disks almost universally lie to the driver any
> time write caching is enabled on an IDE drive.
> 
> In most cases, if you use SCSI, the problem will go away.

Nope, they "lie" as well unless you turn of the WCE bit.  Fortunately
with tagged command queuing there is very little performance penalty for
doing this in most cases.  The main exception to this is when you run
newfs which talks to the raw partition and only has one command
outstanding at a time.

Back in the days when our SCSI implementation would spam the console
whenever it reduced the number of tagged openings because the drive
indicated that its queue was full, I'd see the number of tagged openings
stay at 63 if write caching was disabled, but the number would drop
significantly under load (50%?) if write caching was enabled.  I always
suspected that the drive's cache was full of data for write commands
that it had indicated to the host as being complete even though the data
hadn't been written to stable storage.

Unfortunately SCSI drives all seem to ship with the WCE bit set,
probably for "benchmarking" reasons, so I always have to remember to
turn this bit off whenever I install a new drive.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

cardbus code still broken in current

[Don Lewis]

cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstric
t-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fforma
t-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/src/sys -I/usr/src/sys/contri
b/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/u
sr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -
finline-limit=15000 -fno-strict-aliasing  -mno-align-long-strings -mpreferred-st
ack-boundary=2 -ffreestanding -Werror  /usr/src/sys/dev/cardbus/cardbus_cis.c
/usr/src/sys/dev/cardbus/cardbus_cis.c:80: warning: `decode_tuple_copy' declared
 `static' but never defined
*** Error code 1

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Seeing system-lockups on recent current

[Don Lewis]

On 10 Oct, Dag-Erling Smørgrav wrote:
> Doug White <[EMAIL PROTECTED]> writes:
>> On Fri, 10 Oct 2003, Garance A Drosihn wrote:
>> > For the past week or so, I have been having a frustrating time
>> > with my freebsd-current/i386 system.  It is a dual Athlon
>> > system.  [...]
>> It would be useful to isolate exactly what day the problem started
>> occuring.
> 
> I experienced similar problems on a dual Athlon system (MSI K7D
> Master-L motherboard, AMD 760MPX chipset, dual Athlon MP 2200+) which
> is barely a couple of months old.  I ended up reverting to RELENG_5_1.
> With -CURRENT, both UP and SMP kernels will crash with symptoms which
> suggest hardware trouble.  With RELENG_5_1, UP is rock solid (knock on
> wood) while SMP crashes within minutes of booting.  I've run out of
> patience with this system, so I'll keep running RELENG_5_1 on it until
> someone manages to convince me that -CURRENT will run properly on AMD
> hardware (maybe around 5.3 or so...)

My Athlon XP 1900+/AMD 761 UP box is happily running a late October 6th
version of -current.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: panic: pmap_zero_page: CMAP3 busy

[Don Lewis]

On 11 Oct, Steve Kargl wrote:
> Upgrade tonight (7pm PST) and received the following
> on rebooting
> 
> panic: pmap_zero_page: CMAP3 busy
> 
> Unfortunately, this system does not have a serial
> console and the panic locked it up tight.  Only
> a hard reset brought the system back.

I was just about to type "make installworld" when I got this message

I checked the commit logs and didn't see any recent commits that looked
suspicious, and since I do have a serial console I decided to throw
caution to the wind and give the new kernel a try.

Other than an annoyingly long pause while GEOM waits for my SCSI cdrom
drive to figure out that it is empty (which has been noted in another
thread), my system booted without any problems.  My kernel has
everything commited to the present time except:

tjr 2003/10/11 21:25:26 PDT

  FreeBSD src repository

  Modified files:
sys/i386/ibcs2   ibcs2_misc.c ibcs2_signal.c
 ibcs2_socksys.c ibcs2_util.c ibcs2_util.h
 imgact_coff.c
  Log:
  Fix a multitude of security bugs in the iBCS2 emulator:
  - Return NULL instead of returning memory outside of the stackgap
in stackgap_alloc() (FreeBSD-SA-00:42.linux)
  - Check for stackgap_alloc() returning NULL in ibcs2_emul_find();
other calls to stackgap_alloc() have not been changed since they
are small fixed-size allocations.
  - Replace use of strcpy() with strlcpy() in exec_coff_imgact()
to avoid buffer overflow
  - Use strlcat() instead of strcat() to avoid a one byte buffer
overflow in ibcs2_setipdomainname()
  - Use copyinstr() instead of copyin() in ibcs2_setipdomainname()
to ensure that the string is null-terminated
  - Avoid integer overflow in ibcs2_setgroups() and ibcs2_setgroups()
by checking that gidsetsize argument is non-negative and
no larger than NGROUPS_MAX.
  - Range-check signal numbers in ibcs2_wait(), ibcs2_sigaction(),
ibcs2_sigsys() and ibcs2_kill() to avoid accessing array past
the end (or before the start)

  Revision  ChangesPath
  1.52  +21 -3 src/sys/i386/ibcs2/ibcs2_misc.c
  1.32  +7 -2  src/sys/i386/ibcs2/ibcs2_signal.c
  1.19  +5 -3  src/sys/i386/ibcs2/ibcs2_socksys.c
  1.17  +4 -2  src/sys/i386/ibcs2/ibcs2_util.c
  1.17  +4 -1  src/sys/i386/ibcs2/ibcs2_util.h
  1.61  +1 -1  src/sys/i386/ibcs2/imgact_coff.c


Maybe this problem only affects certain hardware.  Here is my dmesg.boot
for comparison:

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #28: Sat Oct 11 21:58:42 PDT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERICSMB
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a8f000.
Preloaded elf module "/boot/kernel/aout.ko" at 0xc0a8f244.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a8f2f0.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) XP 1900+ (1608.23-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x662  Stepping = 2
  
Features=0x383fbff
  AMD Features=0xc048
real memory  = 1073676288 (1023 MB)
avail memory = 1033592832 (985 MB)
Pentium Pro MTRR support enabled
npx0: [FAST]
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 11 entries at 0xc00fdc30
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
acpi_cpu0:  on acpi0
acpi_button0:  on acpi0
acpi_button1:  on acpi0
pcib0:  port 
0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib0: slot 7 INTD is routed to irq 10
pcib0: slot 7 INTD is routed to irq 10
pcib0: slot 10 INTA is routed to irq 11
pcib0: slot 12 INTA is routed to irq 15
agp0:  port 0xc000-0xc003 mem 
0xef02-0xef020fff,0xe800-0xebff at device 0.0 on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci_cfgintr: 1:5 INTA BIOS irq 15
pci1:  at device 5.0 (no driver attached)
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0xc400-0xc40f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
uhci0:  port 0xc800-0xc81f irq 10 at device 7.2 on pci0
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub0: port error, restarting port 1
uhub0: port error, giving up port 1
uhub0: port error, restarting port 2
uhub0: port error, giving up port 2
uhci1:  port 0xcc00-0xcc1f irq 10 at device 7.3 on pci0
usb1:  on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub1: port error, restarting port 1
uhub1: port error, giving up port 1
uhub1: port error, restarting port 2
uh

Re: Unable to boot cvsup 20031011

[Don Lewis]

On 12 Oct, Anish Mistry wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I finally recvsupped today as some problems with my ata stuff was 
> fixed.  Went through the normal buildworld/kernel progress and on 
> reboot of loading the new kernel, it loads the kernel and modules and 
> then as it starts booting it just causes my machine to restart.  It 
> doesn't have a serial port so I can't get any debug info that way.  I 
> can still boot in with an old kernel, so i can get debug info that 
> way if needed.  Old dmesg and pciconf attached.

What version of sys/i386/i386/pmap.c do you have?  If you are getting
the "pmap_zero_page: CMAP3 busy", it should be fixed by version 1.446,
which phk checked in 2003/10/12 10:55:45.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: samba 3 on CURRENT and net.inet.tcp.blackhole

[Don Lewis]

On 14 Oct, Michal wrote:
> Hello,
> I have a problem with samba 3.0.
> I had to reinstall FreeBSD-CURRENT after known problems with ATAng and 
> atapicam (beginning of September(?)), since then I can't set
> net.inet.tcp.blackhole=2 in /etc/sysctl.conf. If I add the option to 
> sysctl then
> samba will hung until I press ^C. If I boot without this option then samba
> starts fine. However running now
> sysctl net.inet.tcp.blackhole=2 prevent smbclient from running. I still 
> will be
> able to connect to smb shere from another computer.

How long did you wait before interrupting samba?  My suspicion is that
it is attempting to connect to a port that doesn't have a listener, and
it is relying on receiving the ICMP unreachable to cause a connect()
call to fail with ECONNREFUSED before it makes a connection attempt to
another port that succeeds.  If this is the situation, then the
connect() call should eventually fail with ETIMEDOUT if you wait long
enough.

You might try disabling net.inet.tcp.blackhole and enabling
net.inet.tcp.log_in_vain instead.  That will tell you if samba is
attempting to connect to a port without a listener when it starts up and
might give you a hint about possible configuration changes that you
could make so that you can re-enable net.inet.tcp.blackhole.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Random signals in {build,install}world recently?

[Don Lewis]

On 21 Oct, Peter Jeremy wrote:
> On Mon, Oct 20, 2003 at 11:45:21PM -0700, Terry Lambert wrote:
>>I've noticed a lot of bad problems with Hynix memory lately; your
>>mileage may vary.  At Whistle we had a problem with memory with Gold
>>contacts, and didn't have any problems with the ones with Tin.
> 
> A good rule of thumb is to make sure that the finish on the DIMM
> contacts are the same as the ones on the DIMM socket - both gold or
> both tin.  Note that whilst gold doesn't oxidise, it's fairly easy
> to make a gold coating so thin that it's gas permeable allowing the
> underlying metal to oxidise.

Mixing tin and gold can cause galvanic corrosion.  You can also have
connection problems due to the buildup of tin oxide on the gold surface.

I had memory corruption problems on my Athlon UP system that I tracked
down to a memory timing misconfiguration.  My memory was rated for a CAS
Latency of 2.5, but the motherboard BIOS in "auto" memory configuration
mode set the timing to 2.0.  When I manually configured the memory
timing, the errors went away.  The memory errors would show up as random
file corruption in "make buildworld", and I also saw errors on one of
the last tests that memtest86 performs.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

select + signal + truss => LOR

[Don Lewis]

I don't believe I've seen any reports of this particular lock order
reversal.  I got it by pointing truss at syslogd.  My kernel and world
were built from a cvsup run slightly before Fri Nov  7 14:50:18 PST
2003.


 Sleeping on "stopevent" with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc6bc0aa8) locked @ /usr/src/sys/kern/kern
_condvar.c:289
lock order reversal
 1st 0xc6bc0aa8 sigacts (sigacts) @ /usr/src/sys/kern/kern_condvar.c:289
 2nd 0xc6bbabc4 process lock (process lock) @ /usr/src/sys/kern/kern_synch.c:309
Stack backtrace:
backtrace(c08a4327,c6bbabc4,c08a0922,c08a0922,c08a1964) at backtrace+0x17
witness_lock(c6bbabc4,8,c08a1964,135,c08a05a9) at witness_lock+0x672
_mtx_lock_flags(c6bbabc4,0,c08a1964,135,) at _mtx_lock_flags+0xba
msleep(c6bbac98,c6bbabc4,5c,c08a4b24,0) at msleep+0x794
stopevent(c6bbab58,2,e,822,c096d440) at stopevent+0x85
issignal(c640,2,c08a1463,bd,c6bbab58) at issignal+0x168
cursig(c640,0,c089e483,121,0) at cursig+0xf0
cv_wait_sig(c0991f34,c0991f00,c08a492e,348,4) at cv_wait_sig+0x448
kern_select(c640,7,8055060,0,0) at kern_select+0x526
select(c640,e5f26d10,c08bea62,3ee,5) at select+0x66
syscall(2f,2f,2f,8,1) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (93), eip = 0x480d03ff, esp = 0xbfbff79c, ebp = 0xbfbffd98 ---
Sleeping on "stopevent" with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc6bc0aa8) locked @ /usr/src/sys/kern/subr
_trap.c:260
Sleeping on "stopevent" with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc6bc0aa8) locked @ /usr/src/sys/kern/subr
_trap.c:260



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

serial console oddity

[Don Lewis]

I've been seeing some wierd things for many months when using a serial
console on my -CURRENT box.  I finally had a chance to take a closer
look today.

It looks like the problem is some sort of interference between kernel
output to the console and userland writes to /dev/console.  I typically
see syslogd output to the console get corrupted.  Each message that
syslogd writes seems to get truncated or otherwise corrupted.  The most
common thing I see is that each syslog message is reduced to a space and
the first character of the month, or sometimes just a space, or
sometimes nothing at all.  This is totally consistent until I "kill
-HUP" syslogd, which I believe causes syslogd to close and open
/dev/console, after which the syslog output appears correct on the
console. When the syslogd output is being corrupted, I can cat a file to
/dev/console and the output appears to be correct.

I truss'ed syslogd, and it appears to be working normally, the writev()
call that writes the data to the console appears to be writing the
correct character count, so it would appear that the fault is in the
kernel.

The problem doesn't appear to be specific to syslogd, because I have
seen the output from the shutdown scripts that goes to the console get
truncated as well.

I have my serial console running at the default 9600 bps.

I dug around in the source in search of the problem, but I got lost in a
maze of twisty little passages.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: serial console oddity

[Don Lewis]

On  9 Nov, Bruce Evans wrote:
> On Sat, 8 Nov 2003, Don Lewis wrote:
> 
>> I've been seeing some wierd things for many months when using a serial
>> console on my -CURRENT box.  I finally had a chance to take a closer
>> look today.
>>
>> It looks like the problem is some sort of interference between kernel
>> output to the console and userland writes to /dev/console.  I typically
>> see syslogd output to the console get corrupted.  Each message that
>> syslogd writes seems to get truncated or otherwise corrupted.  The most
>> common thing I see is that each syslog message is reduced to a space and
>> the first character of the month, or sometimes just a space, or
>> sometimes nothing at all.
> 
> This is (at least primarily) a longstanding bug in ttymsg().  It uses
> nonblocking mode so that it doesn't block in write() or close().  For
> the same reason, it doesn't wait for output to drain before close().
> If the close happens to be the last one on the device, this causes any
> data buffered in the tty and lower software layers to be discarded
> cleanly and any data in lower hardware layers to by discarded in a
> driver plus hardware-dependent way (usually not so cleanly, especially
> for the character being transmitted).

I didn't think of a flush on close problem because I thought syslogd
always kept the console open.

>> This is totally consistent until I "kill
>> -HUP" syslogd, which I believe causes syslogd to close and open
>> /dev/console, after which the syslog output appears correct on the
>> console. When the syslogd output is being corrupted, I can cat a file to
>> /dev/console and the output appears to be correct.
> 
> When I debugged this, syslogd didn't seem to keep the console open,
> so the open()/close() in ttymsg() always caused the problem.  I didn't
> notice killing syslogd makes a difference.  Perhaps it helps due to a
> missing close.  Holding the console open may be a workaround or even
> the correct fix.  It's not clear where this should be done (should all
> clients of ttymsg() do it?).  Running getty on the console or on the
> underlying tty device should do it accidentally.

It looks to me like syslogd keeps the console open in addition to the
open()/close() in ttymsg().  cfline() calls open() on anything that
begins with '/' and calls isatty() to figure out whether it should set
the type to F_CONSOLE, F_TTY, or F_FILE, and init() closes the file
descriptor for all of these when syslogd is HUPed.

I wonder if the console descriptor is getting revoked ...

>> I truss'ed syslogd, and it appears to be working normally, the writev()
>> call that writes the data to the console appears to be writing the
>> correct character count, so it would appear that the fault is in the
>> kernel.
> 
> If there are any kernel bugs in this area, then they would be that
> last close of the console affects the underlying tty.  The multiple
> console changes are quite likely to have broken this if getty is run
> on the underlying tty (they silently discarded the half-close of the
> underlying tty which was needed to avoided trashing some of its state
> when only the console is closed).

I'm not running getty on my serial console.  It is running on ttyv*. I'm
only using the serial console to capture kernel stack traces, etc.

>> The problem doesn't appear to be specific to syslogd, because I have
>> seen the output from the shutdown scripts that goes to the console get
>> truncated as well.
> 
> Yes, in theory it should affect anything that uses ttymsg() or does
> direct non-blocking writes without waiting for the output to drain.

> Here are some half-baked fixes.  The part that clears O_NONBLOCK is
> wrong, and the usleep() part is obviously a hack.  ttymsg() shouldn't
> block even in close(), since if the close is in the parent ttymsg()
> might block forever and if the close() is in a forked child then
> blocking could create zillions of blocked children.
> 
> Another part of the patch is concerned with limiting forked children.
> If I were happy with that part then blocking would not be so bad.  In
> practice, I don't have enough system activity for blocked children to
> be a problem.  To see the problem with blocked children, do something
> like the following:
> - turn off clocal on the console so that the console can block better.
>   For sio consoles this often requires turning it off in the lock-state
>   device, since the driver defends against this foot shooting by locking
>   it on.
> - hold the console open or otherwise avoid the original bug in this
>   thread, else messages will just be discarded in close() faster than
>   they 

Re: serial console oddity

[Don Lewis]

On  9 Nov, Bruce Evans wrote:

> For a non-half-baked fix, do somethng like:
> - never block in ttymsg(), but always wait for output to drain using
>   tcdrain() in a single child process.  It's probably acceptable for
>   this to not report errors to ttymsg()'s caller.
> - limit children better.  I think we now fork children iff writev()
>   returns EWOULDBLOCK and this happens mainly when the tty buffers
>   fill up due to clocal being off and the external console not
>   listening.  Handling this right seems to require handing off the
>   messages to a single child process that can buffer the messages
>   in userland and can block writing and draining them.  Blocked write()s
>   and tcdrain()s are easy enough to handle in a specialized process by
>   sending signals to abort them.

Another way of handling EWOULDBLOCK would be to add the descriptor to
syslogd's select loop instead of forking a child process.  There is
still the issue of how to handle blocking trdrain()s or close()s,
perhaps a thread.  Syslogd should not attempt to re-open the device if a
tcdrain() or close() was in progress.

BTW, it sounds like the pending output should not be discarded by the
close(), the termios(4) man page says:

   Closing a Terminal Device File
 The last process to close a terminal device file causes any output to be
 sent to the device and any input to be discarded.

If output is discarded in the O_NONBLOCK case, it seems to be
undocumented.  Should close() return ENOSPC in this case?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: serial console oddity

[Don Lewis]

On  9 Nov, Don Lewis wrote:
> On  9 Nov, Bruce Evans wrote:
>> On Sat, 8 Nov 2003, Don Lewis wrote:

>>> This is totally consistent until I "kill
>>> -HUP" syslogd, which I believe causes syslogd to close and open
>>> /dev/console, after which the syslog output appears correct on the
>>> console. When the syslogd output is being corrupted, I can cat a file to
>>> /dev/console and the output appears to be correct.
>> 
>> When I debugged this, syslogd didn't seem to keep the console open,
>> so the open()/close() in ttymsg() always caused the problem.  I didn't
>> notice killing syslogd makes a difference.  Perhaps it helps due to a
>> missing close.  Holding the console open may be a workaround or even
>> the correct fix.  It's not clear where this should be done (should all
>> clients of ttymsg() do it?).  Running getty on the console or on the
>> underlying tty device should do it accidentally.
> 
> It looks to me like syslogd keeps the console open in addition to the
> open()/close() in ttymsg().  cfline() calls open() on anything that
> begins with '/' and calls isatty() to figure out whether it should set
> the type to F_CONSOLE, F_TTY, or F_FILE, and init() closes the file
> descriptor for all of these when syslogd is HUPed.
> 
> I wonder if the console descriptor is getting revoked ...

That appears to be the situation:

scratch:~ 101>cat /var/run/syslog.pid 
275
scratch:~ 102>fstat -p 275
USER CMD  PID   FD MOUNT  INUM MODE SZ|DV R/W
root syslogd  275 root / 2 drwxr-xr-x1024  r
root syslogd  275   wd / 2 drwxr-xr-x1024  r
root syslogd  275 text /575452 -r-xr-xr-x   32204  r
root syslogd  2750 /dev  8 crw-rw-rw-null rw
root syslogd  2751 /dev  8 crw-rw-rw-null rw
root syslogd  2752 /dev  8 crw-rw-rw-null rw
root syslogd  2753* local dgram c6c97000
root syslogd  2754* internet6 dgram udp c6c84ee0
root syslogd  2755* internet dgram udp c6c85000
root syslogd  2756 /dev 17 crw---klog  r
root syslogd  2758 - - bad-
root syslogd  2759 /447635 -rw-r--r--   45602  w
root syslogd  275   10 /450144 -rw---   0  w
root syslogd  275   11 /448526 -rw---   85593  w
root syslogd  275   12 /447600 -rw-r-3119  w
root syslogd  275   13 /450142 -rw-r--r--   19324  w
root syslogd  275   14 /447744 -rw-r--r-- 274  w
root syslogd  275   15 /447492 -rw---   19063  w
root syslogd  275   16 /448732 -rw---   15508  w
root syslogd  275   17 /450145 -rw-r-   0  w
root syslogd  275   18 /450146 -rw-r-   0  w

If we could somehow keep the console open, that would probably be a
sufficient fix for the problem of discarded output.  We probably don't
care in the case of messages to users' terminals, since the users
presumably have those devices open.  There's no such guarantee in the
case of the console.


BTW, here's an example where I HUPed syslogd so that it works, but the
rc script output is truncated.  I think the partial message at the
beginning of the 'vnlru' line should be "Stopping cron.".

Nov  9 12:46:54 scratch shutdown: reboot by dl: 
Stopping inetd.
Shutting down daemon processes:killall: Nov  9 12:46:56 scratch upsmon[504]: upsmon 
parent: exiting (child exited)
warning: kill -TERM 504: No such process
Nov  9 12:46:56 scratch kernel: pid 502 (upsd), uid 66: exited on signal 6
.
Stopping cWaiting (max 60 seconds) for system process `vnlru' to stop...stopped
Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
Waiting (max 60 seconds) for system process `syncer' to stop...stopped

syncing disks, buffers remaining... 12 12 
done
Uptime: 13h34m21s
Shutting down ACPI
Rebooting...


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

kernel trap 12 with interrupts disabled

[Don Lewis]

I just got one of these shortly after I rebooted my November 7th
-CURRENT box. DDB doesn't show much interesting.

 kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xbc04d753
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0685ddf
stack pointer   = 0x10:0xe5f3bca8
frame pointer   = 0x10:0xe5f3bcfc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 519 (setiathome)
kernel: type 12 trap, code=0
Stopped at  mi_switch+0xcf: cmpl0x8(%esi),%ebx
db> tr
mi_switch(c6bbc500,df,c08a3da3,f8,0) at mi_switch+0xcf
ast(e5f3bd48) at ast+0x3f2
doreti_ast() at doreti_ast+0x17

Alas, I didn't have enough free space to capture a core file B-(
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kernel trap 12 with interrupts disabled

[Don Lewis]

On  9 Nov, I wrote:
> I just got one of these shortly after I rebooted my November 7th
> -CURRENT box. DDB doesn't show much interesting.
> 
>  kernel trap 12 with interrupts disabled
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0xbc04d753
> fault code  = supervisor read, page not present
> instruction pointer = 0x8:0xc0685ddf
> stack pointer   = 0x10:0xe5f3bca8
> frame pointer   = 0x10:0xe5f3bcfc
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= resume, IOPL = 0
> current process = 519 (setiathome)
> kernel: type 12 trap, code=0
> Stopped at  mi_switch+0xcf: cmpl0x8(%esi),%ebx
> db> tr
> mi_switch(c6bbc500,df,c08a3da3,f8,0) at mi_switch+0xcf
> ast(e5f3bd48) at ast+0x3f2
> doreti_ast() at doreti_ast+0x17
> 
> Alas, I didn't have enough free space to capture a core file B-(

This problem doesn't appear to be reproduceable and doesn't seem to be
load dependent.  I had portupgrade cranking for many hours yesterday
without a hiccup.  I cleaned up a bunch of old distfiles and packages,
so I should have sufficient space to get a core dump in case this
problem happens again.

I forgot to include the vital statistics.  BTW, the RAM is ECC.

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #35: Fri Nov  7 14:50:18 PST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERICSMB
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a9e000.
Preloaded elf module "/boot/kernel/aout.ko" at 0xc0a9e244.
ACPI APIC Table: 
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) XP 1900+ (1608.23-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x662  Stepping = 2
  
Features=0x383fbff
  AMD Features=0xc048
real memory  = 1073676288 (1023 MB)
avail memory = 1033592832 (985 MB)
ioapic0  irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
acpi0:  on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 11 entries at 0xc00fdc30
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
acpi_cpu0:  on acpi0
acpi_button0:  on acpi0
acpi_button1:  on acpi0
pcib0:  port 
0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib0: slot 7 INTD is routed to irq 10
pcib0: slot 7 INTD is routed to irq 10
agp0:  port 0xc000-0xc003 mem 
0xef02-0xef020fff,0xe800-0xebff at device 0.0 on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci_cfgintr: 1:5 INTA BIOS irq 15
pci1:  at device 5.0 (no driver attached)
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0xc400-0xc40f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
uhci0:  port 0xc800-0xc81f irq 10 at device 7.2 on pci0
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub0: port error, restarting port 1
uhub0: port error, giving up port 1
uhub0: port error, restarting port 2
uhub0: port error, giving up port 2
uhci1:  port 0xcc00-0xcc1f irq 10 at device 7.3 on pci0
usb1:  on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub1: port error, restarting port 1
uhub1: port error, giving up port 1
uhub1: port error, restarting port 2
uhub1: port error, giving up port 2
viapropm0: SMBus I/O base at 0x5000
viapropm0:  port 0x5000-0x500f at device 7.4 on 
pci0
viapropm0: SMBus revision code 0x40
smbus0:  on viapropm0
smb0:  on smbus0
fxp0:  port 0xe000-0xe03f mem 
0xef00-0xef01,0xef021000-0xef021fff irq 18 at device 10.0 on pci0
fxp0: Ethernet address 00:02:b3:5c:8c:e0
miibus0:  on fxp0
inphy0:  on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ahc0:  port 0xe400-0xe4ff mem 
0xef022000-0xef022fff irq 16 at device 12.0 on pci0
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
fdc0:  port 0x3f7,0x3f0-0x3f5 
irq 6 drq 2 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A, console
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
ppbus0:  on ppc0
plip0:  on ppbus0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
atkbdc0:  port 0x64,0x60 irq 1 on acpi0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0:  irq 12 on atkbdc0
psm0: model IntelliMouse Explorer, device ID 4
npx0: [FAST]
npx0:  on moth

Re: named pipes memory leak?

[Don Lewis]

On 10 Nov, Lukas Ertl wrote:
> Hi,
> 
> is there a known problem with named pipes in -CURRENT?
> 
> The following shell script freezes a machine in several minutes and needs
> a power cycle.  You can see the increasing memory in vmstat -z (unpcb) and
> netstat -u.  The kernel is FreeBSD 5.1-CURRENT Tue Nov 4 14:08:23 CET 2003.
> 
> ---8<---
> #/bin/sh
> 
> FIFO=/tmp/foo
> 
> for i in `jot 5 1`; do
>mkfifo ${FIFO}
>echo blubb > ${FIFO} &
>kill $!
>rm ${FIFO}
> done
> ---8<---

If fifo_open() is interrupted, fifo_close() never gets called, and the
resources are not recovered.  I wish doing the resource recovery in
fifo_inactive() would have worked ...

Try this patch:

Index: sys/fs/fifofs/fifo_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v
retrieving revision 1.89
diff -u -r1.89 fifo_vnops.c
--- sys/fs/fifofs/fifo_vnops.c  16 Jun 2003 17:17:09 -  1.89
+++ sys/fs/fifofs/fifo_vnops.c  10 Nov 2003 19:11:00 -
@@ -154,6 +154,26 @@
 }
 
 /*
+ * Dispose of fifo resources.
+ * Should be called with vnode locked
+ */
+static void
+fifo_cleanup(struct vnode *vp)
+{
+   struct fifoinfo *fip = vp->v_fifoinfo;
+
+   VI_LOCK(vp);
+   if (vp->v_usecount == 1) {
+   vp->v_fifoinfo = NULL;
+   VI_UNLOCK(vp);
+   (void)soclose(fip->fi_readsock);
+   (void)soclose(fip->fi_writesock);
+   FREE(fip, M_VNODE);
+   } else
+   VI_UNLOCK(vp);
+}
+
+/*
  * Open called to set up a new instance of a fifo or
  * to find an active instance of a fifo.
  */
@@ -249,6 +269,7 @@
fip->fi_readers--;
if (fip->fi_readers == 0)
socantsendmore(fip->fi_writesock);
+   fifo_cleanup(vp);
return (error);
}
VI_LOCK(vp);
@@ -268,6 +289,7 @@
fip->fi_writers--;
if (fip->fi_writers == 0)
socantrcvmore(fip->fi_readsock);
+   fifo_cleanup(vp);
return (error);
}
/*
@@ -554,15 +576,7 @@
if (fip->fi_writers == 0)
socantrcvmore(fip->fi_readsock);
}
-   VI_LOCK(vp);
-   if (vp->v_usecount == 1) {
-   vp->v_fifoinfo = NULL;
-   VI_UNLOCK(vp);
-   (void)soclose(fip->fi_readsock);
-   (void)soclose(fip->fi_writesock);
-   FREE(fip, M_VNODE);
-   } else
-   VI_UNLOCK(vp);
+   fifo_cleanup(vp);
VOP_UNLOCK(vp, 0, td);
return (0);
 }

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: named pipes memory leak?

[Don Lewis]

On 10 Nov, Lukas Ertl wrote:
> On Mon, 10 Nov 2003, Don Lewis wrote:
> 
>> On 10 Nov, Lukas Ertl wrote:
>> >
>> > The following shell script freezes a machine in several minutes and needs
>> > a power cycle.  You can see the increasing memory in vmstat -z (unpcb) and
>> > netstat -u.  The kernel is FreeBSD 5.1-CURRENT Tue Nov 4 14:08:23 CET 2003.
>> >
>> > ---8<---
>> > #/bin/sh
>> >
>> > FIFO=/tmp/foo
>> >
>> > for i in `jot 5 1`; do
>> >mkfifo ${FIFO}
>> >echo blubb > ${FIFO} &
>> >kill $!
>> >rm ${FIFO}
>> > done
>> > ---8<---
>>
>> If fifo_open() is interrupted, fifo_close() never gets called, and the
>> resources are not recovered.  I wish doing the resource recovery in
>> fifo_inactive() would have worked ...
>>
>> Try this patch:
> 
> Thanks, your patch seems so solve this problem effectively.

The patch has been committed.  Thanks for testing it.

BTW, I encountered a process leak when running your script.  The kill
would sometimes fail to find the process, maybe about 10% of the time. I
think maybe $! hadn't yet been updated and the shell was trying to kill
the previous echo process a second time.  The mkfifo would also fail
sometimes because the file already existed.  I think what the background
shell didn't get around to opening the fifo until after rm had nuked it
causing a plain file to get created.  Hmn, these events seemed to be
associated, so maybe the shell was creating a file and the next echo
command would write to the file and exit before the kill command was
executed.  This doesn't explain all those copies of sh stuck in the
"fifow" state, though.  Adding a "sleep 1" before the kill command seems
to make things work better.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: named pipes memory leak?

[Don Lewis]

On 11 Nov, Lukas Ertl wrote:
> On Tue, 11 Nov 2003, Lukas Ertl wrote:
> 
>> Unfortunately, we are still seeing a problem here: we are running uvscan
>> (virus scanner), and while running it we are still seeing increasing unpcb
>> usage and orphaned unix domain sockets.
>>
>> We added some debug printfs to the fifo routines and found out that
>> fifo_cleanup is called from fifo_close with a vnode which has v_usecount
>> == 2 so the socket close calls aren't reached.
> 
> Sorry, I probably missed an important part: we're creating the FIFOs on
> nullfs mounts - the test script works great on plain UFS mounts, but the
> null layer seems to VREF the vnode once again, so v_usecount is 2, thus it
> is missong the check in fifo_cleanup().

Grrr ...  At least I didn't break this, our fifo implementation would
have always leaked when used this way.

Doing the cleanup in fifo_inactive() would have worked better in this
case.  I think I figured out a way to make that work properly, but I
really need to test it.

Is there any particular reason that you are nuking and re-creating the
fifo?  If you don't delete the fifo, the same sockets will get used each
time.

As a workaround could you create a little mdfs to hold the fifo?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: named pipes memory leak?

[Don Lewis]

On 11 Nov, Don Lewis wrote:
> On 11 Nov, Lukas Ertl wrote:

>> Sorry, I probably missed an important part: we're creating the FIFOs on
>> nullfs mounts - the test script works great on plain UFS mounts, but the
>> null layer seems to VREF the vnode once again, so v_usecount is 2, thus it
>> is missong the check in fifo_cleanup().
> 
> Grrr ...  At least I didn't break this, our fifo implementation would
> have always leaked when used this way.
> 
> Doing the cleanup in fifo_inactive() would have worked better in this
> case.  I think I figured out a way to make that work properly, but I
> really need to test it.
> 
> Is there any particular reason that you are nuking and re-creating the
> fifo?  If you don't delete the fifo, the same sockets will get used each
> time.

Now that I've had some time to think about it, if you reuse the same
fifo, you'll run into the same problem that caused me to abandon my
previous fifo_inactive() version of the cleanup code, which is stale
data being left in the fifo after both ends have been closed.  You may
be stuck with plan B below ...

> As a workaround could you create a little mdfs to hold the fifo?

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Still getting NFS client locking up

[Don Lewis]

On 31 Oct, Kelley Reynolds wrote:
> --- Original Message ---
> From: Matt Smith <[EMAIL PROTECTED]>
> Sent: Fri, 31 Oct 2003 08:55:49 +
> To: Robert Watson <[EMAIL PROTECTED]>
> Subject: Re: Still gettnig NFS client locking up
> 
>> Robert Watson wrote:
>> > On Tue, 28 Oct 2003, Soren Schmidt wrote:
>> > 
>> > 
>> >>>I'm now running a kernel/world of October 26th on both NFS client
>> >>>and server machines. I am still seeing NFS lockups as reported by
>> >>>several people in these threads:
>> >>
>> >>Me too!!
>> > 
>> > 
>> > Hmm.  I'm unable to reproduce this so far, and I'm pounding several
>> > 5.x NFS clients and servers.  I've been checking out using CVS over
>> > NFS, performing dd's of big files, etc.  There must be something
>> > more I'm missing in reproducing this.  What network interface cards
>> > are you using (client, server)? Are you using DHCP on the client or
>> > server?  What commands trigger it -- what part of the NFS
>> > namespace, etc?  Are you running the commands as root, or another
>> > user?
>> > 
>> > Robert N M Watson FreeBSD Core Team, TrustedBSD
>> > Projects [EMAIL PROTECTED]  Network Associates
>> > Laboratories
>> > 
> 
> I'm also experiencing lockups with NFS, but it's the server that locks
> up on mine. Both client and server are -CURRENT. Server was fresh as
> of two days ago, and the client is a week or two old. They are
> connected via bfe (server) and vr (client). The server, I've found,
> will last much longer if the mount options on the client include 'tcp'
> and 'nfsv3' (supposed to be default, but I'm just calling it like it
> is). Reading files seems to be okay, and I've managed to get as far as
> compiling a kernel on an NFS-mounted /usr, but a buildworld will hang
> in < 30 minutes. The server is running dhcp and pf. All commands are
> being run as root.

I'm not having any problems with my -CURRENT client.  My server is
running 4.9-STABLE, so I can't comment on the state of the NFS server
code in -CURRENT.  For what it's worth, my NFS usage is not very heavy,
and is mostly reading, with very little writing.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: checking stopevent 2!

[Don Lewis]

On 15 Nov, Robert Watson wrote:
> 
> On Sat, 15 Nov 2003, Andy Farkas wrote:
> 
>> These messages spew onto my console and into syslogd once every second:
> 
> Heh.  Sounds like your box is having a really bad day, we'll see if we
> can't get it fixed up over the next couple of weeks as things settle out
> :-).

Mine is worse.  If I try to boot it multiuser, it pegs its serial
console with these messages.  It seems to bring up the network to the
point where it can be pinged, but the ping latency averages about
200 ms, and even after a half an hour it still hadn't gotten sshd
started.

I can't drop back to the old kernel because I just did an installworld
with the new version of statfs.

I hope the fix isn't too extensive, since I'll probably be typing it in
by hand in single user mode ...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: named pipes memory leak?

[Don Lewis]

On 11 Nov, Lukas Ertl wrote:
> On Tue, 11 Nov 2003, Lukas Ertl wrote:
> 
>> Unfortunately, we are still seeing a problem here: we are running uvscan
>> (virus scanner), and while running it we are still seeing increasing unpcb
>> usage and orphaned unix domain sockets.
>>
>> We added some debug printfs to the fifo routines and found out that
>> fifo_cleanup is called from fifo_close with a vnode which has v_usecount
>> == 2 so the socket close calls aren't reached.
> 
> Sorry, I probably missed an important part: we're creating the FIFOs on
> nullfs mounts - the test script works great on plain UFS mounts, but the
> null layer seems to VREF the vnode once again, so v_usecount is 2, thus it
> is missong the check in fifo_cleanup().

I just committed a fix for this.  Fifo_vnops.c 1.91 should not leak
memory and sockets when used with nullfs.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

vnode lock violation in today's -CURRENT

[Don Lewis]

I just ran into this while running portupgrade.

VOP_GETATTR: 0xc741e000 is not locked but should be
Debugger("Lock violation.
")
Stopped at  Debugger+0x55:  xchgl   %ebx,in_Debugger.0
db> tr
Debugger(c08bf9aa,c9749c78,c741e000,c08bf9eb,e820c984) at Debugger+0x55
vfs_badlock(c08bf9eb,c9749c78,c741e000,c09590e0,c741e000) at vfs_badlock+0x45
assert_vop_locked(c741e000,c9749c78,e820c9dc,0,e820c9c0) at assert_vop_locked+0x62
getdents_common(c6ede500,e820cd10,1,e820cd40,c0848b70) at getdents_common+0xfa
linux_getdents64(c6ede500,e820cd10,c08d6778,3ee,3) at linux_getdents64+0x20
syscall(2f,2f,2f,5,0) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (220, Linux ELF, linux_getdents64), eip = 0x805a028, esp = 0xbfbfdc5c, ebp 
= 0xbfbfdcb8 ---


It looks to me like the call to vn_lock() in getdents_common() needs to
be moved to before the call to VOP_GETATTR().  The malloc() call should
probably be moved as well, which means that the intervening error
handling needs to be tweaked.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Updated acpi_cpu patch

[Don Lewis]

On 18 Nov, Lukas Ertl wrote:
> On Tue, 18 Nov 2003, Nate Lawson wrote:

>> This excerpt from truckman@'s asl shows that 4 Cx states are only
>> available when the AC adapter is not attached.  (The C*NA memory addresses
>> appear to be managed by the BIOS and not the AML but the PSR access is
>> clear).
> 
> This part of the ASL looks the one here - let me guess, is it a ThinkPad?
> :-)

Yup, a Thinkpad R40, which refuses to actually power down in ACPI mode
when I run "shutdown -p".
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Unfortunate dynamic linking for everything

[Don Lewis]

On 18 Nov, Garance A Drosihn wrote:
> At 8:07 AM -0500 11/18/03, [EMAIL PROTECTED] wrote:
> 
>>  If there hadn't been a noticed increase in cost by using
>>  all-shared-libs, then the measurements were done
>>  incorrectly.  If the decision is made based upon allowing
>>  for 1.5X (at least) times increase in fork/exec times, and
>>  larger memory usage (due to sparse allocations), ...
> 
> I do remember some comments about benchmarks, and it was
> true that the all-dynamic bin/sbin does come out slower.  I
> don't remember if the benchmarks were ours or from NetBSD's
> investigation.  However, I think we measured increase in
> overall time for some set of commands, instead of "increase
> in the fork() routine".  Thus, the penalty observed was much
> less than 50%.  I think it was under 2%, but I don't remember
> the exact number.  When we're dealing with a 100% increase
> in the cost of compiling something with the newer gcc, the
> increase due to this change seemed pretty insignificant...

I thought there were some NetBSD benchmark numbers posted, but after
digging through my mail archives, I now think the results that I'm
remembering were posted by Gordon and were run with rcNG, which is
somewhat more shell intensive than our previous rc system:

On  2 Jun, Gordon Tetlow wrote:
> I'm planning on making a dynamically-linked root partition by 5.2. To
> that end, I'm planning on doing to the following:
> 
> Integrate Tim Kientzle's /rescue patches into the tree
> Create /lib and populate with all the libs needed to support dynamically
>   linked binaries in /bin and /sbin
> Have a big (probably NO_DYNAMIC_ROOT) knob to switch from static to
>   dynamic.
> 
> There will be a performance hit associated with this. I did a quick
> measurement at boot and my boot time (from invocation of /etc/rc to
> the login prompt) went from 12 seconds with a static root to 15
> seconds with a dynamic root. I have yet to perform a worldstone on
> it.

I was thinking the difference was smaller than that.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Unfortunate dynamic linking for everything

[Don Lewis]

On 18 Nov, Robert Watson wrote:

> (2) Shells again, because they will be fork()d and exec()d frequently
> during heavily scripted activities, such as system boot, periodic
> events, large make jobs, etc.  And presumably the only shell of
> interest is sh, although some of the supporting non-builtin binaries
> may also be of interest. 

You left out my favorite fork()/exec() intensive exmple, our ports
system.  During portupgrade, visible activity can grind stop for quite a
while at the "Registering installation" stage, while top's "last pid"
field increases rapidly and system CPU time is an embarrassingly large
number, and this is with a static /bin and /sbin.

Rather than trying to re-"optimize" this by converting /bin/sh back to
being static, I think a got more could be gained by re-writing this part
of the ports infrastructure to be more efficient.  I'm not volunteering
...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

null_lookup() vnode locking wierdness

[Don Lewis]

I was trying to figure out why the VOP_UNLOCK() call in null_lookup()
was violating a vnode locking assertion, so I tossed a bunch of
ASSERT_VOP_LOCKED() calls into null_lookup().  I found something I don't
understand ...

ASSERT_VOP_LOCKED(dvp, "null_lookup 1");
if ((flags & ISLASTCN) && (dvp->v_mount->mnt_flag & MNT_RDONLY) &&
(cnp->cn_nameiop == DELETE || cnp->cn_nameiop == RENAME))
return (EROFS);
/*
 * Although it is possible to call null_bypass(), we'll do
 * a direct call to reduce overhead
 */
ASSERT_VOP_LOCKED(dvp, "null_lookup 2");
ldvp = NULLVPTOLOWERVP(dvp);
ASSERT_VOP_LOCKED(dvp, "null_lookup 3");
vp = lvp = NULL;  
error = VOP_LOOKUP(ldvp, &lvp, cnp);
ASSERT_VOP_LOCKED(dvp, "null_lookup 4");
if (error == EJUSTRETURN && (flags & ISLASTCN) &&
(dvp->v_mount->mnt_flag & MNT_RDONLY) &&
(cnp->cn_nameiop == CREATE || cnp->cn_nameiop == RENAME))  
error = EROFS;
   
/*
 * Rely only on the PDIRUNLOCK flag which should be carefully
 * tracked by underlying filesystem.
 */
if (cnp->cn_flags & PDIRUNLOCK)
VOP_UNLOCK(dvp, LK_THISLAYER, td);

The null_lookup {1,2,3} assertions pass, but null_lookup 4 fails.  It
appears that the VOP_LOOKUP() call to the underlying file system is
unlocking the directory vnode in the nullfs file system.  How can that
happen?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: null_lookup() vnode locking wierdness

[Don Lewis]

On 23 Nov, I wrote:
> I was trying to figure out why the VOP_UNLOCK() call in null_lookup()
> was violating a vnode locking assertion, so I tossed a bunch of
> ASSERT_VOP_LOCKED() calls into null_lookup().  I found something I don't
> understand ...
> 
> ASSERT_VOP_LOCKED(dvp, "null_lookup 1");
> if ((flags & ISLASTCN) && (dvp->v_mount->mnt_flag & MNT_RDONLY) &&
> (cnp->cn_nameiop == DELETE || cnp->cn_nameiop == RENAME))
> return (EROFS);
> /*
>  * Although it is possible to call null_bypass(), we'll do
>  * a direct call to reduce overhead
>  */
> ASSERT_VOP_LOCKED(dvp, "null_lookup 2");
> ldvp = NULLVPTOLOWERVP(dvp);
> ASSERT_VOP_LOCKED(dvp, "null_lookup 3");
> vp = lvp = NULL;  
> error = VOP_LOOKUP(ldvp, &lvp, cnp);
> ASSERT_VOP_LOCKED(dvp, "null_lookup 4");
> if (error == EJUSTRETURN && (flags & ISLASTCN) &&
> (dvp->v_mount->mnt_flag & MNT_RDONLY) &&
> (cnp->cn_nameiop == CREATE || cnp->cn_nameiop == RENAME))  
> error = EROFS;
>
> /*
>  * Rely only on the PDIRUNLOCK flag which should be carefully
>  * tracked by underlying filesystem.
>  */
> if (cnp->cn_flags & PDIRUNLOCK)
> VOP_UNLOCK(dvp, LK_THISLAYER, td);
> 
> The null_lookup {1,2,3} assertions pass, but null_lookup 4 fails.  It
> appears that the VOP_LOOKUP() call to the underlying file system is
> unlocking the directory vnode in the nullfs file system.  How can that
> happen?

I think I just answered my own question.  It appears that both vnodes
can share the same lock according to the following code fragment in
null_nodeget():

/*
 * From NetBSD:
 * Now lock the new node. We rely on the fact that we were passed
 * a locked vnode. If the lower node is exporting a struct lock
 * (v_vnlock != NULL) then we just set the upper v_vnlock to the
 * lower one, and both are now locked. If the lower node is exporting
 * NULL, then we copy that up and manually lock the new vnode.
 */

vp->v_vnlock = lowervp->v_vnlock;
error = VOP_LOCK(vp, LK_EXCLUSIVE | LK_THISLAYER, td);

It looks like the easiest fix is to skip the VOP_UNLOCK() call in
null_lookup() if dvp->v_vnlock == ldvp->v_vnlock.

Index: sys/fs/nullfs/null_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/nullfs/null_vnops.c,v
retrieving revision 1.63
diff -u -r1.63 null_vnops.c
--- sys/fs/nullfs/null_vnops.c  17 Jun 2003 08:52:45 -  1.63
+++ sys/fs/nullfs/null_vnops.c  24 Nov 2003 00:10:41 -
@@ -392,7 +392,7 @@
 * Rely only on the PDIRUNLOCK flag which should be carefully
 * tracked by underlying filesystem.
 */
-   if (cnp->cn_flags & PDIRUNLOCK)
+   if ((cnp->cn_flags & PDIRUNLOCK) && dvp->v_vnlock != ldvp->v_vnlock)
VOP_UNLOCK(dvp, LK_THISLAYER, td);
if ((error == 0 || error == EJUSTRETURN) && lvp != NULL) {
if (ldvp == lvp) {

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 40% slowdown with dynamic /bin/sh

[Don Lewis]

On 25 Nov, Daniel O'Connor wrote:
> On Tuesday 25 November 2003 11:52, Dan Nelson wrote:
>  > > I'd greatly prefer that the the dynamic root default be backed out
>> > > until a substantial amount of this performance can be recovered.
>> >
>> > What _REAL WORLD_ task does this slow down?
>>
>> Try timing "cd /usr/ports/www/mozilla-devel ; make clean" with static
>> and dynamic /bin.  bsd.port.mk spawns many many many /bin/sh processes.
> 
> OK my bad, it will probably slow down the ports building.

The ports infrastructure is horribly slow even with a static sh, though
not as glacially slow as installing and patching Solaris 9.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: pcm(4) related panic

[Don Lewis]

On 25 Nov, Artur Poplawski wrote:
> Artur Poplawski <[EMAIL PROTECTED]> wrote:
> 
>> Hello,  
>> 
>> On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic 
>> like this:

>> Sleeping on "swread" with the following non-sleepable locks held:
>> exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \   
>> /usr/src/sys/dev/sound/pcm/dsp.c:146

This enables the panic.

>> panic: sleeping thread (pid 583) owns a non-sleepable lock

Then the panic happens when another thread tries to grab the mutex.


The problem is that the pcm code attempts to hold a mutex across a call
to uiomove(), which can sleep if the userland buffer that it is trying
to access is paged out.  Either the buffer has to be pre-wired before
calling getchns(), or the mutex has to be dropped around the call to
uiomove().  The amount of memory to be wired should be limited to
'sz' as calculated by chn_read() and chn_write(), which complicates the
logic.  Dropping the mutex probably has other issues.


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: pcm(4) related panic

[Don Lewis]

On 25 Nov, Don Lewis wrote:
> On 25 Nov, Artur Poplawski wrote:
>> Artur Poplawski <[EMAIL PROTECTED]> wrote:
>> 
>>> Hello,  
>>> 
>>> On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic 
>>> like this:
> 
>>> Sleeping on "swread" with the following non-sleepable locks held:
>>> exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \   
>>> /usr/src/sys/dev/sound/pcm/dsp.c:146
> 
> This enables the panic.
> 
>>> panic: sleeping thread (pid 583) owns a non-sleepable lock
> 
> Then the panic happens when another thread tries to grab the mutex.
> 
> 
> The problem is that the pcm code attempts to hold a mutex across a call
> to uiomove(), which can sleep if the userland buffer that it is trying
> to access is paged out.  Either the buffer has to be pre-wired before
> calling getchns(), or the mutex has to be dropped around the call to
> uiomove().  The amount of memory to be wired should be limited to
> 'sz' as calculated by chn_read() and chn_write(), which complicates the
> logic.  Dropping the mutex probably has other issues.

Following up to myself ...

It might be safe to drop the mutex for the uiomove() call if the code
set flags to enforce a limit of one reader and one writer at a time to
keep the code from being re-entered.  The buffer pointer manipulations
in sndbuf_dispose() and sndbuf_acquire() would probably still have to be
protected by the mutex.  If this can be made to work, it would probably
be preferable to wiring the buffer.  It would have a lot less CPU
overhead, and would work better with large buffers, which could still be
allowed to page normally.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: panic on 5.2 BETA: blockable sleep lock

[Don Lewis]

On 26 Nov, Stefan Ehmann wrote:
> I got the following panic twice when starting xawtv using 5.2 BETA (CVS
> from Oct 23)
> panic: blockable sleep lock (sleep mutex) sellck
> @/usr/src/sys/kern/sys_generic.c:1145
> 
> I don't think it is directly related to bktr since the last commit there
> was ~3 months ago. Here is the dmesg output for completeness though.
> bktr0:  mem 0xdf103000-0xdf103fff irq 10 at device 12.0
> on pci0
> bktr0: Card has no configuration EEPROM. Cannot determine card make.
> bktr0: IMS TV Turbo, Philips FR1236 NTSC FM tuner.
> 
> 
> Here is a backtrace:
> 
> GNU gdb 5.2.1 (FreeBSD)
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "i386-undermydesk-freebsd"...
> panic: blockable sleep lock (sleep mutex) sellck @
> /usr/src/sys/kern/sys_generic.c:1145
> panic messages:
> --
> panic: blockable sleep lock (sleep mutex) sellck @
> /usr/src/sys/kern/sys_generic.c:1145
> 
> syncing disks, buffers remaining... 3023 3023 panic: mi_switch: switch
> in a critical section

> #5  0xc05153b7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
> #6  0xc053c010 in witness_lock (lock=0xc076cf40, flags=8, 
> file=0xc06d2139 "/usr/src/sys/kern/sys_generic.c", line=1145)
> at /usr/src/sys/kern/subr_witness.c:609
> #7  0xc050b57a in _mtx_lock_flags (m=0xc3a56dc0, opts=0, 
> file=0xc06ff79c "\037#nÀ\t", line=-1065955520)
> at /usr/src/sys/kern/kern_mutex.c:221
> #8  0xc0540436 in selrecord (selector=0xc076cf40, sip=0xc3a56dc0)
> at /usr/src/sys/kern/sys_generic.c:1145
> #9  0xc08509f1 in bktr_poll () from /boot/kernel/bktr.ko


The bktr_poll() implementation invokes the macros DISABLE_INTR() and
ENABLE_INTR() as a wrapper around a block of code that calls
selrecord().

DISABLE_INTR(s);
 
if (events & (POLLIN | POLLRDNORM)) {
   
switch ( FUNCTION( minor(dev) ) ) {
case VBI_DEV:
if(bktr->vbisize == 0)
selrecord(td, &bktr->vbi_select);
else
revents |= events & (POLLIN | POLLRDNORM);
break;
}
}

ENABLE_INTR(s);

The implementation of DISABLE_INTR() and ENABLE_INTR() is defined in
bktr_os.h as:

#if defined(__FreeBSD__)
#if (__FreeBSD_version >=50)
#define DECLARE_INTR_MASK(s)/* no need to declare 's' */
#define DISABLE_INTR(s) critical_enter()
#define ENABLE_INTR(s)  critical_exit()
#else


The man page for critical_enter() and friends says:

DESCRIPTION
 These functions are used to prevent preemption in a critical region of
 code.  All that is guaranteed is that the thread currently executing on a
 CPU will not be preempted.  Specifically, a thread in a critical region
 will not migrate to another CPU while it is in a critical region.  The
 current CPU may still trigger faults and exceptions during a critical
 section; however, these faults are usually fatal.

 The cpu_critical_enter() and cpu_critical_exit() functions provide the
 machine dependent disabling of preemption, normally by disabling inter-
 rupts on the local CPU.

 The critical_enter() and critical_exit() functions provide a machine
 independent wrapper around the machine dependent API.  This wrapper cur-
 rently saves state regarding nested critical sections.  Nearly all code
 should use these versions of the API.

 Note that these functions are not required to provide any inter-CPU syn-
 chronization, data protection, or memory ordering guarantees and thus
 should not be used to protect shared data structures.

 These functions should be used with care as an infinite loop within a
 critical region will deadlock the CPU.  Also, they should not be inter-
 locked with operations on mutexes, sx locks, semaphores, or other syn-
 chronization primitives.


The problem is that selrecord() wants to lock a MTX_DEF mutex, which can
cause a context switch if the mutex is already locked by another thread.
This is contrary to what bktr_poll() wants to accomplish by calling
critical_enter().

I'm guessing that bktr_poll() wants to prevent bktr->vbisize from being
updated by an interrupt while the above mentioned block of code is
executing, possibly to prevent a select wakeup from being missed.  If
this is correct, the proper fix would probably be for a mutex to be
added to the bktr structure, and the DISABLE_INTR() and ENABLE_INTR()
calls above to lock and unlock this mutex.  Other places in the code
that manipulate bktr->vbisize should grab the mutex before doing so, and
there are places in the code that are cu

Re: panic on 5.2 BETA: blockable sleep lock

[Don Lewis]

On 27 Nov, Stefan Ehmann wrote:
> On Wed, 2003-11-26 at 08:33, Don Lewis wrote:
>> The problem is that selrecord() wants to lock a MTX_DEF mutex, which can
>> cause a context switch if the mutex is already locked by another thread.
>> This is contrary to what bktr_poll() wants to accomplish by calling
>> critical_enter().
> 
> Strange enough that does not seem to happen with a kernel built without
> INVARIANTS and WITNESS. Does this make any sense or is this just by
> chance?

You might try the patch below with WITNESS enabled.  I don't have the
hardware, so I can't test it.  It compiles for me, but for all I know it
could delete all your files if you run it.

Index: sys/dev/bktr/bktr_core.c
===
RCS file: /home/ncvs/src/sys/dev/bktr/bktr_core.c,v
retrieving revision 1.131
diff -u -r1.131 bktr_core.c
--- sys/dev/bktr/bktr_core.c9 Nov 2003 09:17:21 -   1.131
+++ sys/dev/bktr/bktr_core.c27 Nov 2003 23:58:19 -
@@ -526,6 +526,9 @@
}
 #endif /* FreeBSD or BSDi */
 
+#ifdef USE_VBIMUTEX
+   mtx_init(&bktr->vbimutex, "bktr vbi lock", NULL, MTX_DEF);
+#endif
 
 /* If this is a module, save the current contiguous memory */
 #if defined(BKTR_FREEBSD_MODULE)
@@ -807,6 +810,7 @@
 * both Odd and Even VBI data is captured. Therefore we do this
 * in the Even field interrupt handler.
 */
+   LOCK_VBI(bktr);
if (  (bktr->vbiflags & VBI_CAPTURE)
&&(bktr->vbiflags & VBI_OPEN)
 &&(field==EVEN_F)) {
@@ -826,6 +830,7 @@
 
 
}
+   UNLOCK_VBI(bktr);
 
/*
 *  Register the completed field
@@ -1066,8 +1071,13 @@
 int
 vbi_open( bktr_ptr_t bktr )
 {
-   if (bktr->vbiflags & VBI_OPEN)  /* device is busy */
+
+   LOCK_VBI(bktr);
+
+   if (bktr->vbiflags & VBI_OPEN) {/* device is busy */
+   UNLOCK_VBI(bktr);
return( EBUSY );
+   }
 
bktr->vbiflags |= VBI_OPEN;
 
@@ -1081,6 +1091,8 @@
bzero((caddr_t) bktr->vbibuffer, VBI_BUFFER_SIZE);
bzero((caddr_t) bktr->vbidata,  VBI_DATA_SIZE);
 
+   UNLOCK_VBI(bktr);
+
return( 0 );
 }
 
@@ -1166,8 +1178,12 @@
 vbi_close( bktr_ptr_t bktr )
 {
 
+   LOCK_VBI(bktr);
+
bktr->vbiflags &= ~VBI_OPEN;
 
+   UNLOCK_VBI(bktr);
+
return( 0 );
 }
 
@@ -1232,19 +1248,32 @@
 int
 vbi_read(bktr_ptr_t bktr, struct uio *uio, int ioflag)
 {
-   int readsize, readsize2;
+   int readsize, readsize2, start;
int status;
 
+   /*
+* XXX - vbi_read() should be protected against being re-entered
+* while it is unlocked for the uiomove.
+*/
+   LOCK_VBI(bktr);
 
while(bktr->vbisize == 0) {
if (ioflag & IO_NDELAY) {
-   return EWOULDBLOCK;
+   status = EWOULDBLOCK;
+   goto out;
}
 
bktr->vbi_read_blocked = TRUE;
+#ifdef USE_VBIMUTEX
+   if ((status = msleep(VBI_SLEEP, &bktr->vbimutex, VBIPRI, "vbi",
+   0))) {
+   goto out;
+   }
+#else
if ((status = tsleep(VBI_SLEEP, VBIPRI, "vbi", 0))) {
-   return status;
+   goto out;
}
+#endif
}
 
/* Now we have some data to give to the user */
@@ -1262,19 +1291,28 @@
/* We need to wrap around */
 
readsize2 = VBI_BUFFER_SIZE - bktr->vbistart;
-   status = uiomove((caddr_t)bktr->vbibuffer + bktr->vbistart, 
readsize2, uio);
-   status += uiomove((caddr_t)bktr->vbibuffer, (readsize - readsize2), 
uio);
+   start =  bktr->vbistart;
+   UNLOCK_VBI(bktr);
+   status = uiomove((caddr_t)bktr->vbibuffer + start, readsize2, 
uio);
+   if (status == 0)
+   status = uiomove((caddr_t)bktr->vbibuffer, (readsize - 
readsize2), uio);
} else {
+   UNLOCK_VBI(bktr);
/* We do not need to wrap around */
status = uiomove((caddr_t)bktr->vbibuffer + bktr->vbistart, readsize, 
uio);
}
 
+   LOCK_VBI(bktr);
+
/* Update the number of bytes left to read */
bktr->vbisize -= readsize;
 
/* Update vbistart */
bktr->vbistart += readsize;
bktr->vbistart = bktr->vbistart % VBI_BUFFER_SIZE; /* wrap around if needed */
+
+out:
+   UNLOCK_VBI(bktr);
 
return( status );
 
Index: sys/dev/bktr/bktr_os.c
===
RCS file: /home/ncvs/src/sys/dev/bktr/bktr

[patch] mtx_init() API violations

[Don Lewis]

It's a good thing that the value of MTX_DEF is 0 ;-)

This isn't a critical fix, but it probably should be done soon after the
code freeze is lifted to prevent the spread if infection via cut and
paste programming.

Index: dev/ata/ata-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
retrieving revision 1.197
diff -u -r1.197 ata-all.c
--- dev/ata/ata-all.c   11 Nov 2003 14:55:35 -  1.197
+++ dev/ata/ata-all.c   28 Nov 2003 01:34:26 -
@@ -120,7 +120,7 @@
 ch->dev = dev;
 ch->state = ATA_IDLE;
 bzero(&ch->queue_mtx, sizeof(struct mtx));
-mtx_init(&ch->queue_mtx, "ATA queue lock", MTX_DEF, 0);
+mtx_init(&ch->queue_mtx, "ATA queue lock", NULL, MTX_DEF);
 TAILQ_INIT(&ch->ata_queue);
 
 /* initialise device(s) on this channel */
Index: dev/ata/ata-disk.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v
retrieving revision 1.164
diff -u -r1.164 ata-disk.c
--- dev/ata/ata-disk.c  11 Nov 2003 14:55:35 -  1.164
+++ dev/ata/ata-disk.c  28 Nov 2003 01:35:05 -
@@ -94,7 +94,7 @@
adp->sectors = 17;
adp->heads = 8;
 }
-mtx_init(&adp->queue_mtx, "ATA disk bioqueue lock", MTX_DEF, 0);
+mtx_init(&adp->queue_mtx, "ATA disk bioqueue lock", NULL, MTX_DEF);
 bioq_init(&adp->queue);
 
 lbasize = (u_int32_t)atadev->param->lba_size_1 |
Index: dev/ata/atapi-cd.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-cd.c,v
retrieving revision 1.156
diff -u -r1.156 atapi-cd.c
--- dev/ata/atapi-cd.c  24 Nov 2003 14:20:19 -  1.156
+++ dev/ata/atapi-cd.c  28 Nov 2003 01:35:18 -
@@ -222,7 +222,7 @@
 if (!(cdp = malloc(sizeof(struct acd_softc), M_ACD, M_NOWAIT | M_ZERO)))
return NULL;
 bioq_init(&cdp->queue);
-mtx_init(&cdp->queue_mtx, "ATAPI CD bioqueue lock", MTX_DEF, 0);
+mtx_init(&cdp->queue_mtx, "ATAPI CD bioqueue lock", NULL, MTX_DEF);
 cdp->device = atadev;
 cdp->lun = ata_get_lun(&acd_lun_map);
 cdp->block_size = 2048;
Index: dev/ata/atapi-fd.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-fd.c,v
retrieving revision 1.89
diff -u -r1.89 atapi-fd.c
--- dev/ata/atapi-fd.c  11 Nov 2003 14:55:35 -  1.89
+++ dev/ata/atapi-fd.c  28 Nov 2003 01:35:28 -
@@ -80,7 +80,7 @@
 fdp->lun = ata_get_lun(&afd_lun_map);
 ata_set_name(atadev, "afd", fdp->lun);
 bioq_init(&fdp->queue);
-mtx_init(&fdp->queue_mtx, "ATAPI FD bioqueue lock", MTX_DEF, 0);  
+mtx_init(&fdp->queue_mtx, "ATAPI FD bioqueue lock", NULL, MTX_DEF);  
 
 if (afd_sense(fdp)) {
free(fdp, M_AFD);
Index: dev/ata/atapi-tape.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-tape.c,v
retrieving revision 1.84
diff -u -r1.84 atapi-tape.c
--- dev/ata/atapi-tape.c11 Nov 2003 14:55:36 -  1.84
+++ dev/ata/atapi-tape.c28 Nov 2003 01:35:46 -
@@ -103,7 +103,7 @@
 stp->lun = ata_get_lun(&ast_lun_map);
 ata_set_name(atadev, "ast", stp->lun);
 bioq_init(&stp->queue);
-mtx_init(&stp->queue_mtx, "ATAPI TAPE bioqueue lock", MTX_DEF, 0);
+mtx_init(&stp->queue_mtx, "ATAPI TAPE bioqueue lock", NULL, MTX_DEF);
 
 if (ast_sense(stp)) {
free(stp, M_AST);
Index: dev/led/led.c
===
RCS file: /home/ncvs/src/sys/dev/led/led.c,v
retrieving revision 1.3
diff -u -r1.3 led.c
--- dev/led/led.c   23 Nov 2003 10:22:51 -  1.3
+++ dev/led/led.c   28 Nov 2003 01:35:59 -
@@ -216,7 +216,7 @@
struct sbuf *sb;
 
if (next_minor == 0) {
-   mtx_init(&led_mtx, "LED mtx", MTX_DEF, 0);
+   mtx_init(&led_mtx, "LED mtx", NULL, MTX_DEF);
timeout(led_timeout, NULL, hz / 10);
}
 
Index: dev/pst/pst-pci.c
===
RCS file: /home/ncvs/src/sys/dev/pst/pst-pci.c,v
retrieving revision 1.5
diff -u -r1.5 pst-pci.c
--- dev/pst/pst-pci.c   24 Aug 2003 17:54:17 -  1.5
+++ dev/pst/pst-pci.c   28 Nov 2003 01:36:09 -
@@ -96,7 +96,7 @@
 sc->phys_ibase = vtophys(sc->ibase);
 sc->reg = (struct i2o_registers *)sc->ibase;
 sc->dev = dev;
-mtx_init(&sc->mtx, "pst lock", MTX_DEF, 0);
+mtx_init(&sc->mtx, "pst lock", NULL, MTX_DEF);
 
 if (!iop_init(sc))
return 0;
Index: dev/sound/pcm/sndstat.c
===
RCS file: /home/ncvs/src/sys/dev/sound/pcm/sndstat.c,v
retrieving revision 1.14
diff -u -r1.14 sndstat.c
--- dev/sound/pcm/sndstat.c 7 Sep 2003 16:28:03 -   1.14
+++ dev/sound/pcm/sndstat.c 28 Nov 2003 01:36:21 -
@@ -340,7 +340,7 @@
 static int
 sndstat_init(void)
 {
-   mtx_i

Re: panic inserting CF card.

[Don Lewis]

On 27 Nov, masta wrote:
> I'm able to reproduce a panic on demand. I simply insert my IBM Microdrive
> CF card into the PCM/CIA slot of the laptop, which is a Dell CPi, and
> panic! I build a kernel.debug in the hope somebody can help me analyze the
> back-trace.
> 
> Oh by the way, the sources from this backtrace are from 11/27/2003, and
> inserting the CF card used to be functional in early November. I have no
> begun the process of targeting various dates/time to find when
> functionality was lost.

> (kgdb) where
> #10 0xc06995d8 in calltrap () at {standard input}:94
> #11 0xc06be8de in __udivdi3 (a=0, b=0) at ../../../libkern/udivdi3.c:51
> #12 0xc044ac53 in ad_print (adp=0x0) at ../../../dev/ata/ata-disk.c:384
> #13 0xc044a3fb in ad_attach (atadev=0xc243d4a4) at
> ../../../dev/ata/ata-disk.c:162
> #14 0xc0435e99 in ata_attach (dev=0x0) at ../../../dev/ata/ata-all.c:165
> #15 0xc04752f5 in pccard_compat_do_attach (bus=0xc13a6b00, dev=0xc243d400)
> at card_if.h:120
> #16 0xc043c927 in pccard_compat_attach (dev=0xc243d400) at card_if.h:138
> #17 0xc052fdf9 in device_probe_and_attach (dev=0xc243d400) at device_if.h:39
> #18 0xc0473fa8 in pccard_attach_card (dev=0xc13a6b00) at
> ../../../dev/pccard/pccard.c:262
> #19 0xc04628c8 in exca_insert (exca=0xc138d204) at card_if.h:66
> #20 0xc047c4f3 in cbb_insert (sc=0xc138d204) at
> ../../../dev/pccbb/pccbb.c:1078
> #21 0xc047c30b in cbb_event_thread (arg=0xc138d200) at
> ../../../dev/pccbb/pccbb.c:1028
> #22 0xc0502b84 in fork_exit (callout=0xc047c1d0 ,
> arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:793
> (kgdb) q

In ad_print() there is the following statement:

ata_prtdev(adp->device,"%lluMB <%.40s> [%lld/%d/%d] at ata%d-%s %s%s\n",
   (unsigned long long)(adp->total_secs /
((1024L * 1024L) / DEV_BSIZE)),
   adp->device->param->model,
   (unsigned long long)(adp->total_secs /
(adp->heads * adp->sectors)),
   adp->heads, adp->sectors,
   device_get_unit(adp->device->channel->dev),
   (adp->device->unit == ATA_MASTER) ? "master" : "slave",
   (adp->flags & AD_F_TAG_ENABLED) ? "tagged " : "",
   ata_mode2str(adp->device->mode));   

Offhand I'd guess that adp->heads and/or adp->sectors is zero.  If
you've got a core file, try backtracking from there with gdb, otherwise
sprinkle some printf's around.  Either this calculation is new, or some
recent change is causing the heads and sectors to be initialized to
zero.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: panic on 5.2 BETA: blockable sleep lock

[Don Lewis]

On 30 Nov, Stefan Ehmann wrote:
> On Fri, 2003-11-28 at 01:02, Don Lewis wrote:
>> On 27 Nov, Stefan Ehmann wrote:
>> > On Wed, 2003-11-26 at 08:33, Don Lewis wrote:
>> >> The problem is that selrecord() wants to lock a MTX_DEF mutex, which can
>> >> cause a context switch if the mutex is already locked by another thread.
>> >> This is contrary to what bktr_poll() wants to accomplish by calling
>> >> critical_enter().
>> > 
>> > Strange enough that does not seem to happen with a kernel built without
>> > INVARIANTS and WITNESS. Does this make any sense or is this just by
>> > chance?
>> 
>> You might try the patch below with WITNESS enabled.  I don't have the
>> hardware, so I can't test it.  It compiles for me, but for all I know it
>> could delete all your files if you run it.
> 
> Any chance for getting this committed?

I've been forwarding these messages to the bktr maintainer listed in
/usr/src/MAINTAINERS, in case he isn't subscribed to [EMAIL PROTECTED]  I'm not
suprised that I haven't heard from him because this issue came up at the
start of the Thanksgiving holiday weekend.  Commiting the patch will
also require re approval because of the code freeze in preparation for
5.2-RELEASE.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.2-BETA panic: page fault

[Don Lewis]

On 30 Nov, Stefan Ehmann wrote:
> On Sun, 2003-11-30 at 11:13, Stefan Ehmann wrote:
>> This happens to me several times a day (cvsup from yesterday didn't
>> change anything). The panic message is always the same, the backtrace is
>> different though (but always seems to be file system related in some
>> way)
>> 
>> Here's one from today:
> 
> As per request I made a (hopefully more useful) backtrace with a patched
> gdb version:
> 
> (kgdb) bt

> #12 0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
> #13 0xc068248c in trap_fatal (frame=0xd7f2ea48, eva=0)
> at /usr/src/sys/i386/i386/trap.c:821
> #14 0xc0682152 in trap_pfault (frame=0xd7f2ea48, usermode=0, eva=0)
> at /usr/src/sys/i386/i386/trap.c:735
> #15 0xc0681d63 in trap (frame=
>   {tf_fs = -672006120, tf_es = -672006128, tf_ds = -1068105712,
> tf_edi = -104931, tf_esi = 228, tf_ebp = -671946076, tf_isp =
> -671946124, tf_ebx = 0, tf_edx = 16777217, tf_ecx = -1011687424, tf_eax
> = -1011660928, tf_trapno = 12, tf_err = 0, tf_eip = -1068475565, tf_cs =
> 8, tf_eflags = 66178, tf_esp = 2, tf_ss = -1011660928}) at
> /usr/src/sys/i386/i386/trap.c:420
> #16 0xc06743d8 in calltrap () at {standard input}:94
> #17 0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0, 
> file=0xc06bfc1d "/usr/src/sys/kern/kern_lock.c", line=228)
> at /usr/src/sys/kern/kern_mutex.c:214
> #18 0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4, 
> td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
> #19 0xc0566d87 in vfs_busy (mp=0x0, flags=0, interlkp=0x0, td=0x0)
> at /usr/src/sys/kern/vfs_subr.c:527
> #20 0xc056374c in lookup (ndp=0xd7f2ec00) at
> /usr/src/sys/kern/vfs_lookup.c:559

It seems pretty clear that the panic is caused by passing a null pointer
to mtx_lock().  That is pretty clear from the eva=0 argument to
trap_pfault() and the m=0x0 argument to _mtx_lock_flags().  If you have
INVARIANTS defined, the first thing that _mtx_lock_flags() does is to
dereference m->mtx_object, which is at beginning of struct mtx.

There appears to be some stack spammage happening, and it is pretty much
consistent between this stack trace and the previous one displayed by
the unpatched version of gdb.  Notice how all the arguments to
vfs_busy() are NULL/0, but td and interlkp are passed directly to
lockmgr(), which has a non-NULL td and interlkp arguments, though the
interlkp argument looks seriously bogus.  Looking at the lockmgr() call
in vfs_busy(), I don't see how the flags argument to lockmgr() could be
0.  If the mp argument to vfs_busy() were really NULL, vfs_busy() would
have paniced before calling lockmgr().

I wonder if an interrupt handler is stomping on the stack ...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.2-BETA panic: page fault

[Don Lewis]

Can you reproduce this problem without bktr?

> #6  0xc06743d8 in calltrap () at {standard input}:94
> #7  0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0, 
> file=0xc06bfc1d "/usr/src/sys/kern/kern_lock.c", line=228)
> at /usr/src/sys/kern/kern_mutex.c:214
> #8  0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4, 
> td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
> #9  0xc0566d87 in vfs_busy (mp=0x0, flags=16, interlkp=0xc075d0e0,
> td=0x0)
> at /usr/src/sys/kern/vfs_subr.c:527
> #10 0xc056cfff in sync (td=0xc0730dc0, uap=0x0)

> #16 0xc06743d8 in calltrap () at {standard input}:94
> #17 0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0, 
> file=0xc06bfc1d "/usr/src/sys/kern/kern_lock.c", line=228)
> at /usr/src/sys/kern/kern_mutex.c:214
> #18 0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4, 
> td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
> #19 0xc0566d87 in vfs_busy (mp=0x0, flags=0, interlkp=0x0, td=0x0)
> at /usr/src/sys/kern/vfs_subr.c:527
> #20 0xc056374c in lookup (ndp=0xd7f2ec00) at
> /usr/src/sys/kern/vfs_lookup.c:559

You are getting a double panic, with the second happening during the
file system sync.  The code seems to be be tripping over the same mount
list entry each time.  Maybe the mount list is getting corrupted.  Are
you using amd?  Print *lkp in the lockmgr() stack frame.


You might want to add
KASSERT(mp->mnt_lock.lk_interlock !=NULL, "vfs_busy: NULL mount
pointer interlock");
at the top of vfs_busy() and right before the lockmgr() call.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.2-BETA panic: page fault

[Don Lewis]

On  1 Dec, Stefan Ehmann wrote:
> On Mon, 2003-12-01 at 01:10, Don Lewis wrote:
>> Can you reproduce this problem without bktr?
>> 
> 
>> You are getting a double panic, with the second happening during the
>> file system sync.  The code seems to be be tripping over the same mount
>> list entry each time.  Maybe the mount list is getting corrupted.  Are
>> you using amd?  Print *lkp in the lockmgr() stack frame.
>> 
>> 
>> You might want to add
>>  KASSERT(mp->mnt_lock.lk_interlock !=NULL, "vfs_busy: NULL mount
>> pointer interlock");
>> at the top of vfs_busy() and right before the lockmgr() call.
> 
> No, I'm not using amd.
> 
> (kgdb) print *lkp
> $1 = {lk_interlock = 0x0, lk_flags = 0, lk_sharecount = 0, lk_waitcount
> = 0, 
>   lk_exclusivecount = 0, lk_prio = 0, lk_wmesg = 0x0, lk_timo = 0, 
>   lk_lockholder = 0x0, lk_newlock = 0x0}
> 
> This is indeed just NULLs.

Not good.  Nothing should be writing to lk_interlock once it has been
initialized.  Either something is stomping on an active struct mount,
we're still using it after it has been put on the free list, or
dp->v_mountedhere is pointing somewhere bogus.  I don't suspect the
latter because the second panic() in the sync() code doesn't follow this
path to get to the struct mount.

> I haven't tried without bktr yet but I hope I'll have time for that (and
> the KASSERT) tomorrow.
> 
> The panic only seems to happen when accessing my read-only mounted ext2
> partition. Today I tried not to access any data there and uptime is
> 14h30min now. The panic always happened after a few hours. So this is
> probably the core of the problem.

That sounds like a possibility.  I might be able to try that here when I
have some idle time on my -CURRENT box.

Can you print *dp->v_mountedhere in the lookup() frame?  That should
show the mount point information and might show if anything else in
struct mount is damaged.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: panic on 5.2 BETA: blockable sleep lock

[Don Lewis]

On  1 Dec, Roger Hardiman wrote:
> Hi
> 
> Please can someone commit the bktr patch for me to fix 5.2-BETA
> (as long as re@ approve). I don't have the resources.

If you're happy with the patch, I'll pursue re@ approval for the commit.

>> I'm not suprised that I haven't heard from him because this issue came up
> at the
>> start of the Thanksgiving holiday weekend.
> 
> If only it were that simple. Actually I'm English and we don't have
> Thanksgiving.

Sorry, I guess I should have fired up xearth ;-)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: panic on 5.2 BETA: blockable sleep lock

[Don Lewis]

On  1 Dec, Roger Hardiman wrote:
> Hi
> 
> Please can someone commit the bktr patch for me to fix 5.2-BETA
> (as long as re@ approve). I don't have the resources.

The patch has been committed with re@ approval.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.2-BETA panic: page fault

[Don Lewis]

On  1 Dec, Stefan Ehmann wrote:
> On Mon, 2003-12-01 at 01:10, Don Lewis wrote:
>> Can you reproduce this problem without bktr?
>> 
> 
>> You are getting a double panic, with the second happening during the
>> file system sync.  The code seems to be be tripping over the same mount
>> list entry each time.  Maybe the mount list is getting corrupted.  Are
>> you using amd?  Print *lkp in the lockmgr() stack frame.
>> 
>> 
>> You might want to add
>>  KASSERT(mp->mnt_lock.lk_interlock !=NULL, "vfs_busy: NULL mount
>> pointer interlock");
>> at the top of vfs_busy() and right before the lockmgr() call.
> 
> No, I'm not using amd.
> 
> (kgdb) print *lkp
> $1 = {lk_interlock = 0x0, lk_flags = 0, lk_sharecount = 0, lk_waitcount
> = 0, 
>   lk_exclusivecount = 0, lk_prio = 0, lk_wmesg = 0x0, lk_timo = 0, 
>   lk_lockholder = 0x0, lk_newlock = 0x0}
> 
> This is indeed just NULLs.
> 
> I haven't tried without bktr yet but I hope I'll have time for that (and
> the KASSERT) tomorrow.
> 
> The panic only seems to happen when accessing my read-only mounted ext2
> partition. Today I tried not to access any data there and uptime is
> 14h30min now. The panic always happened after a few hours. So this is
> probably the core of the problem.

What about ther file system types, like nullfs, unionfs, cd9660?  I
created an ext2 partition, filled it with data, and mounted it
read-only.  So far I am unable to reproduce this problem.

I'm also running with the DEBUG_VFS_LOCKS and the following patch in an
attempt to catch the bug closer to its origin.  Be forwarned that
DEBUG_VFS_LOCKS sometimes gets triggered by procfs and linprocfs, but
you can just continue in DDB.

Index: sys/kern/vfs_subr.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.472
diff -u -r1.472 vfs_subr.c
--- sys/kern/vfs_subr.c 9 Nov 2003 09:17:24 -   1.472
+++ sys/kern/vfs_subr.c 1 Dec 2003 13:34:23 -
@@ -282,6 +282,9 @@
 void
 assert_vop_locked(struct vnode *vp, const char *str)
 {
+   if (vp && vp->v_mount)
+   KASSERT(vp->v_mount->mnt_lock.lk_interlock != NULL,
+   ("assert_vop_locked: vnode mount entry interlock is null"));
if (vp && !IGNORE_LOCK(vp) && !VOP_ISLOCKED(vp, NULL))
vfs_badlock("is not locked but should be", str, vp);
 }
@@ -289,6 +292,9 @@
 void
 assert_vop_unlocked(struct vnode *vp, const char *str)
 {
+   if (vp && vp->v_mount)
+   KASSERT(vp->v_mount->mnt_lock.lk_interlock != NULL,
+   ("assert_vop_unlocked: vnode mount entry interlock is null"));
if (vp && !IGNORE_LOCK(vp) &&
VOP_ISLOCKED(vp, curthread) == LK_EXCLUSIVE)
vfs_badlock("is locked but should not be", str, vp);



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: BTX halts installing 5.x

[Don Lewis]

On  2 Dec, Josh Paetzel wrote:
> I'm trying to install FreeBSD on a Dual Pentium Pro 200mhz 512K cache system and I 
> am getting the 
> following error:
> 
> CD Loader 1.01
> 
> Building the boot loader arguements
> Looking up /BOOT/LOADER... Found
> Relocating the loader and the BTX
> Starting the BTX loader
> 
> BTX loader 1.00  BTX version is 1.01
> 
> int=0005  err=  efl=00019286  eip=0001c8a4
> eax=00a3  ebx=  ecx=  edx=
> esi=cce65d00  edi=  ebp=  esp=0009407c
> cs=002b  ds=0033  es=0033fs=0033  gs=0033 ss=0033
> cs:eip=62 6f 6f 74 2e 6e 65 74-69 66 2e 69 70 00 62 6f
>6f 74 2e 6e 65 74 69 66-2e 6e 65 74 6d 61 73 6b
> ss:esp=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
>00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
> BTX halted
> 
> I've tried warm booting after this and I get the same results.  I've tried 
> 5.0-RELEASE, 5.0-DP1, 
> 5.1-RELEASE, and three different snapshots, all of which work fine on my other 
> machines, including one 
> other SMP box.  It's also worth noting that 4.8-RELEASE and 4.9-RELEASE install fine 
> on this box.
> 
> I can boot 4.9 and post a dmesg if that would help, but to briefly describe the 
> hardware:
> 
> Intel PR440FX Mainboard
> Dual Pentium Pro 200mhz 512K Cache CPUs
> Adaptec 7880 SCSI controller
> 4.3 gig IBM Wide SCSI-2 Disks
> Intel EtherExpress Pro LAN adapter
> I've tried a couple different video cards, Cirrus Logis and SIS PCI
> 320 Megs of Registered ECC SDRAM

Could this be a result of the switch from emulated floppy bootable CDs
to 'no emulation' bootable CDs that happened with between the 4.x and
5.x branches?

If you can do a "make release" to create you own .iso images, try doing
it with the EMUL_BOOT variable defined, which will generate the .iso
images with the emulated-floppy boot code.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: swap-related problems

[Don Lewis]

On Apr 15, 12:14pm, Peter Jeremy wrote:
} Subject: Re: swap-related problems
} Mikhail Teterin  wrote:
} > Worse then that,
} >it may be possible to use it at malloc time, but unless your program
} >runs and touches every page, the memory may not be available later.
} 
} If you run and touch every page, you are guaranteed to have the
} memory available, but you also increase the chances of you being the
} largest process when the system runs out of swap - in which case you
} get killed.

This could also has a pretty severe runtime performance penalty.  An
implementation that just reserves space would not.

} >If we are up to discussing the possible implementations, I'd suggest
} >that the system uses something other then SIGKILL to notify the
} >program it's time to pay for the over-commit speed and convenience.
} >I think, SIGBUS is appropriate, but I'm not sure.
} 
} I'm not sure this will gain a great deal.  Currently, if the kernel
} runs out of swap, it kills the largest runnable process.  For your
} proposal to work, it would need to kill the process that is requesting
} the space.  This raises a number of issues:
} 1) The problem is detected in vm_pageout_scan().  There's no obvious
}(to me anyway) way to locate the process that is triggering the
}space request.
} 2) The current approach kills the process hogging the greatest amount
}of memory.  This minimises the likelihood that you'll run out of
}swap again, quickly.
} 3) The process that triggered the request could potentially be in a
}non-runnable state.  In this case, the signal would be lost (or
}indefinitely delayed).
} 4) Since you're proposing a trap-able signal, the process may chose
}to ignore it and attempt to continue on.
} 5) The process would require additional stack space to process the
}signal (the signal handler frame and space for system calls to
}free memory as a minimum).
} 
} The last three issues could result in system deadlock.

Yes.  On the other hand, with an implemntation where malloc() returns
NULL, a carefully application could log a message and wait for more swap
to become available, or checkpoint itself.

} Having said all that, I agree that it would be useful if FreeBSD had a
} knob to disable overcommit - either on a system-wide, or per-process
} basis.  I don't feel sufficiently strongly about it to actually do
} something about it.  (From a quick look at the current code in
} vm_pageout_scan(), it would be fairly easy to add a per-process flag
} to prevent the process being a candidate for killing.  ptrace(2) or
} setrlimit(2) seem the most obvious ways to control the flag.  This
} would seem to allieviate the most common problem - one or two large,
} critical processes (eg the Xserver) getting killed, but probably has
} some nasty downside that I've overlooked).

Like if the Xserver has a memory leak, it will keep growing until most
of the other processes on the machine are killed of, maybe even important
ones, like the process that manipulates the control rods in the nuclear
reactor ;-)

Actually, that brings up a good point.  It is generally considered bad
practice for safety critical programs to use dynamic memory allocation
since it is so hard to guarantee that there won't be a memory allocation
failure.  With memory overcommit, it is possible that a process that
doesn't dynamically allocate memory to be killed because a fault could
happen when accessing BSS.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: swap-related problems

[Don Lewis]

On Apr 14,  4:40pm, Chuck Robey wrote:
} Subject: Re: swap-related problems
} On Wed, 14 Apr 1999, Anthony Kimball wrote:

} > Well, it's only needed if you want to be able to reliably execute ANSI 
} > C code according to spec.  I personally don't care.  I'd be surprised
} > if core didn't though.  I would suspect that it would be deemed worthy
} > of someone's p2 queue, at least.
} 
} I can't understand this.  Make software that causes a major performance
} loss, and loses *bigtime* in memory allocation, just so the one guy to
} complain *at all* can not lose sleep over something that has causes no
} problems at all with any ANSI code in a properly sized system.

SunOS 4 doesn't do memory overcommit.  I've been running large processes
for years on SunOS 4 machines and haven't noticed any performance problems
due to lack of memory overcommit.  You just need to configure plenty of
swap.  I've found the old 3x RAM rule works fine, and it's really cheap
these days.  This could be shaved down a bit if SunOS didn't require
(swap > total VM) instead of (swap + RAM > total VM).

If you want to talk about slow, there are those crufty old implementations
that don't have COW fork().  If a large process forks, its entire memory
space needs to be duplicated, which is *really slow* if the process was
too big to fit in RAM to begin with.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: ppbus causes hangs?

[Don Lewis]

On Apr 29,  7:41pm, Mike Smith wrote:
} Subject: Re: ppbus causes hangs?
} 
} Try setting the flags on the 'ppc' device to 0x40 and _please_ report 
} the results.

I also ran into this problem with a 4/30/1999 version of 3.1-stable
on a Dell Dimension XPS R400.  The 0x40 flag fixed the problem.

BTW, the UPDATING file on the RELENG_3 branch hasn't been updated
since the branch point, so there is no info on the ppbus stuff and
the post-branch enhancements to the loader.  Also, src/sys/boot/README
hasn't been added to the RELENG_3 branch.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: ppbus causes hangs?

[Don Lewis]

On May 2, 11:58pm, Don Lewis wrote:
} Subject: Re: ppbus causes hangs?
} On Apr 29,  7:41pm, Mike Smith wrote:
} } Subject: Re: ppbus causes hangs?
} } 
} } Try setting the flags on the 'ppc' device to 0x40 and _please_ report 
} } the results.
} 
} I also ran into this problem with a 4/30/1999 version of 3.1-stable
} on a Dell Dimension XPS R400.  The 0x40 flag fixed the problem.

I forgot to include /var/run/dmesg.boot.

Copyright (c) 1992-1999 FreeBSD Inc.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 3.1-STABLE #1: Fri Apr 30 22:18:51 PDT 1999
gd...@gvpc85.gv.tsc.tdk.com:/usr/src/sys/compile/TSC_INTERNAL
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium II/Xeon/Celeron (398.27-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x652  Stepping=2
  
Features=0x183f9ff>
real memory  = 67108864 (65536K bytes)
config> di wt0
config> di mcd0
config> di matcdc0
config> di scd0
config> di ie0
config> di aha0
avail memory = 62017536 (60564K bytes)
Preloaded elf kernel "kernel" at 0xc031c000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc031c09c.
Probing for devices on PCI bus 0:
chip0:  rev 0x03 on pci0.0.0
chip1:  rev 0x03 on pci0.1.0
chip2:  rev 0x02 on pci0.7.0
ide_pci0:  rev 0x01 on pci0.7.1
chip3:  rev 0x02 on pci0.7.3
fxp0:  rev 0x02 int a irq 11 on 
pci0.13.0
fxp0: Ethernet address 00:a0:c9:75:7c:8f
fxp1:  rev 0x02 int a irq 15 on 
pci0.15.0
fxp1: Ethernet address 00:a0:c9:75:7b:99
ahc0:  rev 0x00 int a irq 9 on pci0.16.0
ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs
Probing for devices on PCI bus 1:
vga0:  rev 0x21 int a irq 11 on pci1.0.0
Probing for devices on the ISA bus:
sc0 on isa
sc0: VGA color <16 virtual consoles, flags=0x0>
ed0 not found at 0x280
atkbdc0 at 0x60-0x6f on motherboard
atkbd0 irq 1 on isa
psm0 not found
sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa
sio0: type 16550A
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1 not found at 0x2f8
ppc0 at 0x378 irq 7 flags 0x40 on isa
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
lpt0:  on ppbus 0
lpt0: Interrupt-driven port
ppi0:  on ppbus 0
plip0:  on ppbus 0
lpt0:  on ppbus 0
lpt0: Interrupt-driven port
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1.44MB 3.5in
wdc0 not found at 0x1f0
wdc1 not found at 0x170
vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa
npx0 on motherboard
npx0: INT 16 interface
Waiting 2 seconds for SCSI devices to settle
changing root device to da0s1a
da1 at ahc0 bus 0 target 1 lun 0
da1:  Fixed Direct Access SCSI-2 device 
da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled
da1: 8709MB (17836668 512 byte sectors: 255H 63S/T 1110C)
da0 at ahc0 bus 0 target 0 lun 0
da0:  Fixed Direct Access SCSI-2 device 
da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
da0: 2049MB (4197405 512 byte sectors: 255H 63S/T 261C)
ffs_mountfs: superblock updated for soft updates


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

patch for descriptor leak caused by KKIS.05051999.003b exploit

[Don Lewis]

Could someone give the attached patch a try in -current?  It fixes the
file descriptor leak that the KKIS.05051999.003b exploit causes.  This
fix seems to work fine in -stable.  I'd like to commit it to the current
tree and merge it into -stable before the 3.2 code freeze.


Index: uipc_usrreq.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_usrreq.c,v
retrieving revision 1.43
diff -u -u -r1.43 uipc_usrreq.c
--- uipc_usrreq.c   1999/04/28 11:37:07 1.43
+++ uipc_usrreq.c   1999/05/09 23:50:45
@@ -367,6 +367,9 @@
unp_shutdown(unp);
}
 
+   if (control && error != 0)
+   unp_dispose(control);
+
 release:
if (control)
m_freem(control);


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Don Lewis]

On Jun 5,  5:43pm, John-Mark Gurney wrote:
} Subject: Re: RE: net.inet.tcp.always_keepalive on as default ?
} Garrett Wollman scribbled this message on Jun 5:
} > < said:
} > 
} > > FWIW, I think only a fool would want a computer to NOT drop dead 
connections.
} > > Any "connection" that doesn't respond after 8 $^&! tries spaced FAR apart 
does
} > > NOT deserve to stay.
} > 
} > If they are spaced too far apart, it is possible for perfectly
} > legitimate connections to get shot down as a result of external
} > periodicities.  (Does somebody's router reset every day at 2:45?  If
} > so, better hope no keepalives are scheduled for then!)
} 
} yes, but are routers normally down for a couple hours??  if they are,
} you have other problems than worring about connections...

We've lost our T1 to the world for up to twelve hours.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: policy on GPL'd drivers?

[Don Lewis]

On 28 May, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> "Daniel O'Connor" <[EMAIL PROTECTED]> writes:

> : 2) You can't control where the module gets put - arguably this isn't a 
> : calamity, but I think it makes more sense for the modules to end up in 
> : /boot/modules, or some analog to it that is in $PREFIX.
> 
> It should go in /boot/kernel, and not into $PREFIX, but that's a
> philisophical problem I have with ports.  ALL modules should be in /,
> imho, since you don't know if the module is required to mount /.

Another really good reason is that this is more likely to do the correct
thing if you do a major system upgrade, like jumping from 4.x to 5.x,
which are very likely to require different versions of the module, and
discover some sort of problem when you boot the new kernel to test it
before proceeding to the installworld step.  The right thing should
happen when you fall back to /boot/kernel.old, or
/boot/kernel.itusedtowork, etc.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

vnode locking problem in pseudofs/procfs

[Don Lewis]

I just stumbled across this vnode locking problem in procfs()

db> tr
Debugger(c05215d4,c0520b94,c669b000,c0521615,e6d77764) at Debugger+0x54
vfs_badlock(c0521615,c0520b94,c669b000,c05b4340,c669b000) at vfs_badlock+0x45
assert_vop_locked(c669b000,c0520b94,c0520adf,358,c6a35400) at assert_vop_locked+
0x62
vn_fullpath(c66ce390,c669b000,e6d777a8,e6d777ac,c04ea6fb) at vn_fullpath+0xbc
procfs_doprocfile(c66ce390,c61c2960,c6272000,e6d777d4,0) at procfs_doprocfile+0x
3a
pfs_readlink(e6d77c10,c05210fd,c05b49c0,c6b2e920,e6d77c94) at pfs_readlink+0x116
VOP_READLINK(c6b2e920,e6d77c94,c6911d80,bfbed240,400) at VOP_READLINK+0x59
kern_readlink(c66ce390,bfbed650,0,bfbed240,0) at kern_readlink+0xc1
readlink(c66ce390,e6d77d10,c0535a6a,3fb,3) at readlink+0x38
syscall(2f,2f,2f,8134400,bfbedfd0) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (58, FreeBSD ELF32, readlink), eip = 0x8058a73, esp = 0xbfbed21c, eb
p = 0xbfbeda68 ---


when I ran
find / -print0 | xargs -0 ls -l
with the DEBUG_VFS_LOCKS kernel option.

The obvious part of the fix is to lock the vnode in procfs_doprocfile()
before calling vn_fullpath().  The more interesting question is if this
means that all callers of (pn->pn_func)() need to drop their vnode locks
in order to prevent a potential deadlock.  It looks to me like this is
necessary ...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade

[Don Lewis]

On 16 Jun, Thorsten Schroeder wrote:
> Hi,
> 
> On Mon, 15 Jun 2003, Chris Shenton wrote:
> 
>> [...] qmail is run under daemontools and all work fine (the configuration
>> is 2 years old!), but when I delivery the first mail (localy or remote)
>> the qmail-send process fire up to 100% of CPU infinitely
>>
>> All other mail are right delivery, and the CPU use is the only problem, I
>> see in qmail-send.c that select() function, after the first message,
>> allways return 1
> 
> same here too.
> I don't know what it could be - perhaps a problem with named pipes
> ("lock/trigger")?
> 
> You can find my ktrace output here: http://cs.so36.net/~ths/kdump.txt
> 
> Would be nice if anyone have an idea :)
> 
>> A truss shows me it's running in a tight loop over this code:
>> close(9) = 0 (0x0)
>> select(0x9,0xbfbffcbc,0xbfbffc3c,0x0,0xbfbffc24) = 1 (0x1)
> 
>> Anyone else seen this or know what in FreeBSD-5.1 might have changed to cause
>> this?  Any thoughts on how I might go about diagnosing this any better?

Which version of fifo_vnops.c?  If the problem is present in
5.1-RELEASE, then the problem is likely to be the change made in 1.79
and 1.85.  If the problem didn't show up until after the 5.1-RELEASE,
then the problem could be the changes in 1.87 or 1.88.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade

[Don Lewis]

On 16 Jun, Tim Robbins wrote:
> On Mon, Jun 16, 2003 at 04:09:51PM +1000, Tim Robbins wrote:
> 
>> On Sun, Jun 15, 2003 at 08:43:15PM -0400, Chris Shenton wrote:
>> 
>> > I've been running qmail for years and like it, installed pretty much
>> > per www.LifeWithQmail.org.  My main system was running FreeBSD
>> > 5.0-RELEASE and -CURRENT and qmail was fine.  When I just upgraded to
>> > 5.1-CURRENT a couple days back, the qmail-send process started using
>> > all CPU.
>> 
>> This looks like a bug in the named pipe code. Reverting
>> sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go
>> away. I haven't tracked down exactly what change between RELENG_5_0 and
>> RELENG_5_1 caused the problem.
> 
> Looks like revision 1.86 works, but it stops working with 1.87. Moving the
> soclose() calls to fifo_inactive() may have caused it.

This is an interesting observation, but I'm not sure why it would make a
difference.  I haven't looked at the qmail source, but it looks like it
is doing a non-blocking open on the fifo, calling select() on the fd,
and hoping that select() waits for a writer to open the fifo before
returning with an indication that the descriptor is readable.

It looks like the select code is calling the soreadable() macro to
determine if the fifo descriptor is readable, and the soreadable() macro
returns a true value if the SS_CANTRCVMORE socket flag is set, which
would indicate an EOF condition.

I might believe that I accidentally changed the setting of this flag,
but I just compared fifo_vnops.c rev 1.78 with 1.87 and I believe this
flag should be set the same way in both versions.

In both versions, fifo_close() always calls socantrcvmore(), which sets
SS_CANTRCVMORE when the writer count drops to zero.  Prior to 1.87,
fifo_close() also destroyed the sockets when the reference count dropped
to zero, which caused fifo_open() to recreate the sockets when the fifo
was opened again, and when it did, fifo_open() set the SS_CANTRCVMORE
flag again.

The posted qmail syscall trace looks like what I would expect to see in
the present implementation.  I can't explain why it would behave any
differently prior to 1.87 ...

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade

[Don Lewis]

On 16 Jun, I wrote:
> On 16 Jun, Tim Robbins wrote:

>>> This looks like a bug in the named pipe code. Reverting
>>> sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go
>>> away. I haven't tracked down exactly what change between RELENG_5_0 and
>>> RELENG_5_1 caused the problem.
>> 
>> Looks like revision 1.86 works, but it stops working with 1.87. Moving the
>> soclose() calls to fifo_inactive() may have caused it.
> 
> This is an interesting observation, but I'm not sure why it would make a
> difference.  I haven't looked at the qmail source, but it looks like it
> is doing a non-blocking open on the fifo, calling select() on the fd,
> and hoping that select() waits for a writer to open the fifo before
> returning with an indication that the descriptor is readable.
> 
> It looks like the select code is calling the soreadable() macro to
> determine if the fifo descriptor is readable, and the soreadable() macro
> returns a true value if the SS_CANTRCVMORE socket flag is set, which
> would indicate an EOF condition.
> 
> I might believe that I accidentally changed the setting of this flag,
> but I just compared fifo_vnops.c rev 1.78 with 1.87 and I believe this
> flag should be set the same way in both versions.
> 
> In both versions, fifo_close() always calls socantrcvmore(), which sets
> SS_CANTRCVMORE when the writer count drops to zero.  Prior to 1.87,
> fifo_close() also destroyed the sockets when the reference count dropped
> to zero, which caused fifo_open() to recreate the sockets when the fifo
> was opened again, and when it did, fifo_open() set the SS_CANTRCVMORE
> flag again.
> 
> The posted qmail syscall trace looks like what I would expect to see in
> the present implementation.  I can't explain why it would behave any
> differently prior to 1.87 ...

The plot thickens ...

I ran this bit of code on both 5.1 current with version 1.88 of
fifo_vnops.c, and 4.8-stable:

#include 
#include 
#include 
#include 
main()
{
int fd;
fd_set readfds;

fd = open("myfifo", O_RDONLY | O_NONBLOCK);

printf("before the loop\n");
while (1) {
FD_ZERO(&readfds);
FD_SET(fd, &readfds);
printf("%d %d\n", fd, select(20, &readfds, NULL, NULL, NULL));
}
exit(0);
}

On 4.8-stable, select() immediately returns a "1", whether or not the
fifo has ever been opened for writing.

On 5.1-current, select() waits forever, even if the fifo has been opened
for writing by another process.  Select() only returns when something
has actually been written to the fifo, and since this process doesn't
read anything from the fifo, it spins on select() forever.

If some data is getting written to the fifo, it doesn't look like qmail
consumes it, and since fifo_close in 1.87 doesn't destroy the sockets,
it looks like the data is hanging around in the fifo while neither end
is open, and qmail stumbles across this data when it calls select()
after re-opening the fifo.

Now there are two questions that I can't answer:

Why is my analysis of select() and the SS_CANTRCVMORE flag
incorrect in 5.1-current with version 1.87 or 1.88 of
fifo_vnops.c.

Why doesn't qmail get stuck in a similar loop in 4.8-stable,
since select always returns true for reading on a fifo with no
writers?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade

[Don Lewis]

On 16 Jun, Bruce Evans wrote:
> On Mon, 16 Jun 2003, Don Lewis wrote:
> 
>> On 16 Jun, I wrote:
>> > On 16 Jun, Tim Robbins wrote:
>>
>> >>> This looks like a bug in the named pipe code. Reverting
>> >>> sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go
>> >>> away. I haven't tracked down exactly what change between RELENG_5_0 and
>> >>> RELENG_5_1 caused the problem.
>> >>
>> >> Looks like revision 1.86 works, but it stops working with 1.87. Moving the
>> >> soclose() calls to fifo_inactive() may have caused it.
>> >
>> > This is an interesting observation, but I'm not sure why it would make a
>> > difference.  I haven't looked at the qmail source, but it looks like it
>> > is doing a non-blocking open on the fifo, calling select() on the fd,
>> > and hoping that select() waits for a writer to open the fifo before
>> > returning with an indication that the descriptor is readable.
> 
> In my review of 1.87, I forgot to ask you how atomic the close is with part
> of it moved out to fifo_inactive().  I think it's important that all
> traces of the old open have gone away (as far as applications can tell)
> when the last close returns.

I hadn't taken queued data into consideration.  Now that I've looked at
this more closely, there are other problems in both the old and new
code.  If a process calls fcntl(fd, F_SETOWN, ...) on one end of the
fifo, that should be undone when that end of the fifo is closed.  In the
old implementation, that only happens when both ends of the fifo are
closed and the sockets are deleted.


>> On 5.1-current, select() waits forever, even if the fifo has been opened
>> for writing by another process.  Select() only returns when something
>> has actually been written to the fifo, and since this process doesn't
>> read anything from the fifo, it spins on select() forever.
>>
>> If some data is getting written to the fifo, it doesn't look like qmail
>> consumes it, and since fifo_close in 1.87 doesn't destroy the sockets,
>> it looks like the data is hanging around in the fifo while neither end
>> is open, and qmail stumbles across this data when it calls select()
>> after re-opening the fifo.
>>
>> Now there are two questions that I can't answer:
>>
>>  Why is my analysis of select() and the SS_CANTRCVMORE flag
>> incorrect in 5.1-current with version 1.87 or 1.88 of
>> fifo_vnops.c.
> 
> I think it is correct, assuming that something writes to the fifo.
> Writing might be part of synchronization but actually reading the
> data should not be necessary since the last close must discard the
> data (POSIX spec).

It sure looks to me like SS_CANTRCVMORE is always set when the write end
of the fifo is closed, no matter whether the the sockets were freshly
allocated by a fifo_open() call on the read end of the fifo, or because
the the last writer closed the write end of the fifo.  It sure looks
like select() should immediately return if this flag is set, but it is
not returning ...

Actually, something seems broken.  I modified my little test program to
actually read the data, which works just fine, but select() still blocks
when the writer closes the fifo, so there doesn't seem to be a way to
detect the EOF.

>>  Why doesn't qmail get stuck in a similar loop in 4.8-stable,
>> since select always returns true for reading on a fifo with no
>> writers?
> 
> Don't know.  Maybe it uses autoconfig to handle the 4.8 behaviour.
> The 4.8 behaviour is normal compared with the buggy behaviour of
> not discarding data on last close, so applications should handle it
> better :-).  Maybe qmain spins under 4.8 too, but only until
> synchronization is achieved.
> 
> Bruce

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade

[Don Lewis]

On 16 Jun, Thorsten Schroeder wrote:
> Hi,
> 
> On Sun, 15 Jun 2003, Don Lewis wrote:
> 
>> > I don't know what it could be - perhaps a problem with named pipes
>> > ("lock/trigger")?
>> >
>> > You can find my ktrace output here: http://cs.so36.net/~ths/kdump.txt
> 
>> Which version of fifo_vnops.c?  If the problem is present in
>> 5.1-RELEASE, then the problem is likely to be the change made in 1.79
>> and 1.85.  If the problem didn't show up until after the 5.1-RELEASE,
>> then the problem could be the changes in 1.87 or 1.88.
> 
> FreeBSD 5.1-CURRENT #1: Thu Jun  5 19:29:29 CEST 2003
> 
> fifo_vnops.c:
> 
> $FreeBSD: src/sys/fs/fifofs/fifo_vnops.c,v 1.87 2003/06/01 06:24:32 truckman Exp $


Try upgrading to 1.88 and applying this patch:

Index: sys/fs/fifofs/fifo_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v
retrieving revision 1.88
diff -u -r1.88 fifo_vnops.c
--- sys/fs/fifofs/fifo_vnops.c  13 Jun 2003 06:58:11 -  1.88
+++ sys/fs/fifofs/fifo_vnops.c  16 Jun 2003 08:44:20 -
@@ -70,7 +70,6 @@
 static int fifo_lookup(struct vop_lookup_args *);
 static int fifo_open(struct vop_open_args *);
 static int fifo_close(struct vop_close_args *);
-static int fifo_inactive(struct vop_inactive_args *);
 static int fifo_read(struct vop_read_args *);
 static int fifo_write(struct vop_write_args *);
 static int fifo_ioctl(struct vop_ioctl_args *);
@@ -98,7 +97,6 @@
{ &vop_create_desc, (vop_t *) vop_panic },
{ &vop_getattr_desc,(vop_t *) vop_ebadf },
{ &vop_getwritemount_desc,  (vop_t *) vop_stdgetwritemount },
-   { &vop_inactive_desc,   (vop_t *) fifo_inactive },
{ &vop_ioctl_desc,  (vop_t *) fifo_ioctl },
{ &vop_kqfilter_desc,   (vop_t *) fifo_kqfilter },
{ &vop_lease_desc,  (vop_t *) vop_null },
@@ -556,32 +554,18 @@
if (fip->fi_writers == 0)
socantrcvmore(fip->fi_readsock);
}
-   VOP_UNLOCK(vp, 0, td);
-   return (0);
-}
-
-static int
-fifo_inactive(ap)
-   struct vop_inactive_args /* {
-   struct vnode *a_vp;
-   struct thread *a_td;
-   } */ *ap;
-{
-   struct vnode *vp = ap->a_vp;
-   struct fifoinfo *fip = vp->v_fifoinfo;
-
VI_LOCK(vp);
-   if (fip != NULL && vp->v_usecount == 0) {
+   if (vp->v_usecount == 1) {
vp->v_fifoinfo = NULL;
VI_UNLOCK(vp);
(void)soclose(fip->fi_readsock);
(void)soclose(fip->fi_writesock);
FREE(fip, M_VNODE);
-   }
-   VOP_UNLOCK(vp, 0, ap->a_td);
+   } else
+   VI_UNLOCK(vp);
+   VOP_UNLOCK(vp, 0, td);
return (0);
 }
-
 
 /*
  * Print out internal contents of a fifo vnode.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade

[Don Lewis]

On 16 Jun, Thorsten Schroeder wrote:
> Hi,
> 
> On Mon, 16 Jun 2003, Don Lewis wrote:
> 
>> > FreeBSD 5.1-CURRENT #1: Thu Jun  5 19:29:29 CEST 2003
>> >
>> > fifo_vnops.c:
>> >
>> > $FreeBSD: src/sys/fs/fifofs/fifo_vnops.c,v 1.87 2003/06/01 06:24:32 truckman Exp $
> 
>> Try upgrading to 1.88 and applying this patch:
>>
>> Index: sys/fs/fifofs/fifo_vnops.c
>> ===
>> RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v
>> retrieving revision 1.88
>> diff -u -r1.88 fifo_vnops.c
>> --- sys/fs/fifofs/fifo_vnops.c   13 Jun 2003 06:58:11 -  1.88
>> +++ sys/fs/fifofs/fifo_vnops.c   16 Jun 2003 08:44:20 -
> [...]
> 
> Yes! This seems to work fine :)
> 
> qmail-send doesn't increase cpu usage after the first mail anymore.
> 
> Thanks a lot,

Thanks for doing the testing.  I just committed this patch.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade

[Don Lewis]

On 16 Jun, Jesse Guardiani wrote:

> I run qmail on my 4.8 servers.
> 
> For my sanity, is this a problem in 5.1-RELEASE, or in code after 5.1-RELEASE?
> We haven't upgraded to 5.1 yet (and don't intend to for a while), but I thought
> I'd ask since this bug would cripple our mail server.

It was broken in 5.1-CURRENT shortly after 5.1-RELEASE, until I
committed a patch a few minutes ago.  5.1-RELEASE is fine.  The
problematic versions of fifo_vnops.c are 1.87 and 1.88.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade

[Don Lewis]

On 16 Jun, Bruce Evans wrote:
> On Mon, 16 Jun 2003, Don Lewis wrote:
> 
>> On 16 Jun, Bruce Evans wrote:
>> > In my review of 1.87, I forgot to ask you how atomic the close is with part
>> > of it moved out to fifo_inactive().  I think it's important that all
>> > traces of the old open have gone away (as far as applications can tell)
>> > when the last close returns.
>>
>> I hadn't taken queued data into consideration.  Now that I've looked at
>> this more closely, there are other problems in both the old and new
>> code.  If a process calls fcntl(fd, F_SETOWN, ...) on one end of the
>> fifo, that should be undone when that end of the fifo is closed.  In the
>> old implementation, that only happens when both ends of the fifo are
>> closed and the sockets are deleted.
> 
> F_SETOWN (and associated signal delivery) is even more broken than that :-].
> This fcntl() should applied to the file (though not just the file descriptor),
> so its effect should be limited to fd's open in the file instance and go
> away when all thse are closed.  However, F_SETOWN (and associated signal
> delivery) actually applies to the socket for fifos.  It doesn't work quite
> right for ttys either.  F_SETOWN apparently isn't used in ways complicated
> enough to require it to work right.

There is a fundamental architectural problem -- devices and files don't
have a list of the descriptors that have them open.  That would require
putting descriptors on another list (and dealing with the necessary
locking), which would also bloat the size of the descriptor structure.
Storing the F_SETOWN info there would bloat all descriptors even more
rather than the relative handful of device structures that support this
feature.

>> >> Now there are two questions that I can't answer:
>> >>
>> >>   Why is my analysis of select() and the SS_CANTRCVMORE flag
>> >> incorrect in 5.1-current with version 1.87 or 1.88 of
>> >> fifo_vnops.c.
>> >
>> > I think it is correct, assuming that something writes to the fifo.
>> > Writing might be part of synchronization but actually reading the
>> > data should not be necessary since the last close must discard the
>> > data (POSIX spec).
>>
>> It sure looks to me like SS_CANTRCVMORE is always set when the write end
>> of the fifo is closed, no matter whether the the sockets were freshly
>> allocated by a fifo_open() call on the read end of the fifo, or because
>> the the last writer closed the write end of the fifo.  It sure looks
>> like select() should immediately return if this flag is set, but it is
>> not returning ...
> 
> Alfred changed the semantics for 5.x.  I thought that you knew this.
> I finally gave up resisting this change after a lot of email :-).  In
> 5.x, SS_CANTRCVMORE often has no effect for fifos (it still works
> normally for sockets).  fifo_poll() normally calls soo_poll() with
> POLLIN converted to POLLINIGNEOF.  This causes soo_poll() (sopoll())
> to skip the usual SS_CANTRCVMORE check (which is inside soreadable())
> and check the watermark instead, so that select() on a fifo normally
> waits for data even when the fifo is open in nonblocking mode and
> SS_CANTRCVMORE is set.

Nope, I didn't know this, and I missed the POLLIN->POLLINIGNEOF
conversion when I was tracing the code.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user()non-sleepable locks

[Don Lewis]

On 16 Jun, Chris Shenton wrote:
> (I don't know if this has any relation to the problems I reported
> yesterday with qmail-send consuming 100% cpu after 5.0 to 5.1 upgrade.)

I doubt it.  I checked in a fix for this problem today so you should get
the fix when you next cvsup.

> After booting 5.1-CURRENT the system runs fine for a while.  Then
> later most disk i/o related actions seem to hang.  E.g., system works
> but when cron kicks off a glimpseindex in the middle of the night, the
> system is useless by the morning.  If I login on the console as me, it
> takes my username and password then hangs (trying to run
> /usr/local/bin/bash?). If I do this as root, I do get a shell
> (/bin/csh).  After a point, asking for "top" will hang, even as root.
> Even a "reboot" hung this morning with nothing in the logs.

Can you break into ddb and do a ps to find out what state all the
processes are in?  You might want to try adding the DEBUG_VFS_LOCKS
options to your kernel config to see if that turns up anything.  There
is also ddb command to list the locked vnodes "show lockedvnods".

Are you using nullfs or unionfs which are a bit fragile?

> The system has become almost unusable because of this, requiring
> frequent reboots or hardware resets.
> 
> Sometimes when I do something as simple as "ps" I see this ominous
> message on the console:
> 
>   sysctl_old_user() with the following non-sleepablelocks held:
>   exclusive sleep mutex process lock r = 0 (0xc50bc9e0) locked @ 
> /usr/src/sys/kern/kern_proc.c:258
> 
> which gets into /var/log/messages as:
> 
>   Jun 16 08:33:48 PECTOPAH kernel: exclusive sleep mutex process lock r = 0 
> (0xc50c7618) locked @ /usr/src/sys/kern/kern_proc.c:258
> 
> There are a bunch of these.

I've been seeing this for about the last week, I think.  It seems to be
harmless and nothing bad has happened to my -current box.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

fdrop_locked() and FILE_LOCK() vs. Giant

[Don Lewis]

The FILE_LOCK() implementation uses "pool mutex" under the hood, which
means it should only be used as a leaf level mutex.  The fdrop_locked()
code wants to be called with FILE_LOCK() held, but the fdrop_locked()
implementation calls mtx_lock(&Giant) before calling FILE_UNLOCK().  In
addition to violating the proper usage of the "pool mutex", there is
also the potential for a lock order violation.  The close()
implementation grabs Giant and eventually calls fdrop(), which calls
FILE_LOCK() immediately before calling fdrop_locked().  If another
caller of fdrop_locked() calls FILE_LOCK() without grabbing Giant first,
then the lock order will be reversed when fdrop_locked() grabs Giant.

It looks like fdrop_locked() should require that Giant be grabbed by the
caller before fdrop_locked() is called.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Giant pushdown in kern_descrip.c rev 1.128

[Don Lewis]

On 17 Jun, Alfred Perlstein wrote:
> * Don Lewis <[EMAIL PROTECTED]> [030617 12:00] wrote:
>> It's not legal to attempt to aquire Giant in fdrop_locked(), while
>> FILE_LOCK() is held.  The problem is that FILE_LOCK uses the mutex pool,
>> which should only be used for leaf mutexes.
>> 
>> It also looks like there is a potential for a lock order reversal if
>> some callers aquire Giant before FILE_LOCK() and fdrop_locked() does the
>> opposite.
>> 
>> It also appears that witness ignores the mutex pool ...
> 
> Yes, but I think the fix is as simple as just dropping the FILE_LOCK
> after the decrement as we're the last holders of it, can you try
> this:

I like simple fixes, especially when the code shrinks ;-)

Unfortunately, I think your point about this only happening because this
process is the last holder of the file means that this doesn't explain
Peter's deadlock.

> Index: kern_descrip.c
> ===
> RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
> retrieving revision 1.199
> diff -u -r1.199 kern_descrip.c
> --- kern_descrip.c11 Jun 2003 00:56:55 -  1.199
> +++ kern_descrip.c17 Jun 2003 19:07:01 -
> @@ -2003,6 +2003,7 @@
>   FILE_UNLOCK(fp);
>   return (0);
>   }
> + FILE_UNLOCK(fp);
>   mtx_lock(&Giant);
>   if (fp->f_count < 0)
>   panic("fdrop: count < 0");
> @@ -2012,10 +2013,8 @@
>   lf.l_len = 0;
>   lf.l_type = F_UNLCK;
>   vp = fp->f_data;
> - FILE_UNLOCK(fp);
>   (void) VOP_ADVLOCK(vp, (caddr_t)fp, F_UNLCK, &lf, F_FLOCK);
> - } else
> - FILE_UNLOCK(fp);
> + }
>   if (fp->f_ops != &badfileops)
>   error = fo_close(fp, td);
>   else
> 
> 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: fdrop_locked() and FILE_LOCK() vs. Giant

[Don Lewis]

On 17 Jun, Robert Watson wrote:
> 
> On Tue, 17 Jun 2003, Don Lewis wrote:
> 
>> The FILE_LOCK() implementation uses "pool mutex" under the hood, which
>> means it should only be used as a leaf level mutex.  The fdrop_locked() 
>> code wants to be called with FILE_LOCK() held, but the fdrop_locked() 
>> implementation calls mtx_lock(&Giant) before calling FILE_UNLOCK().  In
>> addition to violating the proper usage of the "pool mutex", there is
>> also the potential for a lock order violation.  The close() 
>> implementation grabs Giant and eventually calls fdrop(), which calls
>> FILE_LOCK() immediately before calling fdrop_locked().  If another
>> caller of fdrop_locked() calls FILE_LOCK() without grabbing Giant first,
>> then the lock order will be reversed when fdrop_locked() grabs Giant. 
>> 
>> It looks like fdrop_locked() should require that Giant be grabbed by the
>> caller before fdrop_locked() is called. 
> 
> I've also noticed that the file descriptor lock is held over per-object
> calls to fo_poll(), which currently isn't a big deal for most objects, but
> may be in the future if we have to grab other locks in order to test the
> poll status inside the object.  I run into this problem with the MAC work
> because the vnode label is protected by the vnode lock, which is a
> sleepable lock.  We may want to change label locking in the future to
> avoid this, but in the mean time I get a lot of witness warnings, and
> using a pool mutex for the fd lock may cause lock order problems if there
> is more complex locking.

Does witness even keep track of the pool mutex stuff?  It doesn't seem
to report any lock order problems in the fdrop_locked() case.  I'm
attempting to debug a deadlock problem for someone, and one process is
hung on FILE_LOCK() in fdrop(), but "show witness" in ddb doesn't
mention any "pool mutex" holders.  The process hung in fdrop() got there
by calling close(), which grabs Giant.  Once it wedge, then everything
else on the system stacked up waiting for Giant.

Alfred mentioned that fdrop_locked() can be easily fixed by dropping the
file lock a bit sooner.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepablelocks

[Don Lewis]

On 17 Jun, Chris Shenton wrote:
> Don Lewis <[EMAIL PROTECTED]> writes:
> 
>> I doubt it.  I checked in a fix for this problem today so you should get
>> the fix when you next cvsup.
> 
> Yup, many thanks.
> 
>> Can you break into ddb and do a ps to find out what state all the
>> processes are in?
> 
> I'm a newbie to ddb.  Was able to get a ps from a hung system but
> didn't know how to capture it to send to you.  Any hints?

If you have another machine and a null modem cable you can redirect the
system console of the machine to be debugged to a serial port and run
some comm software on the other machine so that you can capture all the
output from ddb.

Lacking that, there's the pencil and paper method that I used for far
too long.

> 
>> You might want to try adding the DEBUG_VFS_LOCKS options to your
>> kernel config to see if that turns up anything.
> 
> Oh, man, I'm getting killed here now. Rebuilt the kernel with that
> option (not found in GENERIC or other examples in /usr/src/sys/i386/conf/).
> 
> Now the system is dropping into ddb ever minute or so with complaints
> like the following on the screen, and in /var/log/messages:
> 
> Jun 17 21:06:08 PECTOPAH kernel: VOP_GETVOBJECT: 0xc584eb68 is not locked but should 
> be
> Jun 17 21:08:04 PECTOPAH last message repeated 3 times
> ...
> Jun 17 21:18:55 PECTOPAH kernel: VOP_GETVOBJECT: 0xc59346d8 is not locked but should 
> be
> Jun 17 21:18:59 PECTOPAH last message repeated 5 times
> 
> Lots 'n' lots of 'em, with a few of the same hex value then another
> set for a different hex value.

Been there, but that was quite a while ago.  I run this way all the time
and hardly ever see problems these days.  You must be exercising some
file system code that I don't.  At the ddb prompt, you can do a "tr"
command to get a stack trace, which is likely to be very helpful in
pointing out the offending code.

If you're getting a lot of VFS lock violation reports, the underlying
locking violations could be the reason that your machine deadlocks.

Post some representative stack traces.  These problems are generally
easy to fix.

>> There is also ddb command to list the locked vnodes "show
>> lockedvnods".
> 
> After I type "cont" at ddb a few times the system runs for a while
> again, only to repeat.  When it drops to ddb again that show command
> doesn't list anything. 
> 
> I may have to remove that option from my kernel just to get to run a
> bit, even tho eventually the system will hang.  It's (of course) my
> main box which the other systems NFS off, mail server, etc. :-(

At the ddb prompt you should be able to use the write command tweak a
couple of variables to modify this behavior.  If you set the
vfs_badlock_panic variable to zero, the kernel will no longer drop into
DDB when one of these lock violations occurs.  If you set the
vfs_badlock_print variable to zero, the kernel will stop printing the
warnings.

If you are running the NFS *client* code on this machine, there is one
lock assertion that is easy to trigger.  The stack trace will show the
nfsiod process calling nfssvc_iod(), which calls nfs_doio(), which
complains about a lock not being held.  If you run into that problem,
just comment out the line:
 ASSERT_VOP_LOCKED(vp, "nfs_doio");
in nfs_doio(), in the file sys/nfsclient/nfs_bio.c.  I haven't been able
to figure out the correct fix for this problem, and so far I haven't
encountered any problems with the problem being unfixed.

> 
>> Are you using nullfs or unionfs which are a bit fragile?
> 
> Nope.  I'd be happy to mail you my kernel config if you want. I've
> posted it to http://chris.shenton.org/PECTOPAH but if the system's
> hung again, naturally it won't be available :-(
> 
> 
> Thanks for your help.  Any other things I might try?
> 
> Dunno if this matters, but I'm using an DELL CERC ATA RAID card with
> disks showing up as amrd* if that matters.  Was flawless at
> 5.0-{CURRENT,RELEASE}.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Giant pushdown in kern_descrip.c rev 1.128

[Don Lewis]

On 17 Jun, Alfred Perlstein wrote:
> * Don Lewis <[EMAIL PROTECTED]> [030617 13:06] wrote:
>> On 17 Jun, Alfred Perlstein wrote:
>> > * Don Lewis <[EMAIL PROTECTED]> [030617 12:00] wrote:
>> >> It's not legal to attempt to aquire Giant in fdrop_locked(), while
>> >> FILE_LOCK() is held.  The problem is that FILE_LOCK uses the mutex pool,
>> >> which should only be used for leaf mutexes.
>> >> 
>> >> It also looks like there is a potential for a lock order reversal if
>> >> some callers aquire Giant before FILE_LOCK() and fdrop_locked() does the
>> >> opposite.
>> >> 
>> >> It also appears that witness ignores the mutex pool ...
>> > 
>> > Yes, but I think the fix is as simple as just dropping the FILE_LOCK
>> > after the decrement as we're the last holders of it, can you try
>> > this:
>> 
>> I like simple fixes, especially when the code shrinks ;-)
>> 
>> Unfortunately, I think your point about this only happening because this
>> process is the last holder of the file means that this doesn't explain
>> Peter's deadlock.
> 
> You can still deadlock because another file's mutex may hash to the same
> location.

... or some other user of the mutex pool that happens to hold Giant.

I'm in favor of committing your patch, though I think it should be
commented to indicate why it is safe to play with fp after the mutex has
been unlocked.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepablelocks

[Don Lewis]

On 17 Jun, Chris Shenton wrote:
> Don Lewis <[EMAIL PROTECTED]> writes:
> 
>> If you have another machine and a null modem cable you can redirect the
>> system console of the machine to be debugged to a serial port and run
>> some comm software on the other machine so that you can capture all the
>> output from ddb.
> 
> OK, I'll give that a shot, probably tomorrow.
> 
> 
>> At the ddb prompt, you can do a "tr" command to get a stack trace,
>> which is likely to be very helpful in pointing out the offending
>> code.
> 
> Just saw it again, did a tr.  From chicken-scratch notes, the last
> bits are:
> 
>   VOP_GETVOBJECT(...)
>   do_sendfile(...)
>   sendfile(...)
>   syscall(...)
>   Xint0x80_syscall...
>   --- syscall( 393, FreeBSD ELF32, sendfile) ...
> 
> The next time it dropped into ddb, same "sendfile" thing.

Try the very untested patch below ...

> The main services I'm running are qmail, apache, and NFS.  Also 
> tftp, rarpd, lpd, sshd, bootparamd ...  oh, well, I guess I'm running
> a bunch of stuff here. :-(  Not sure which one, if any, this would be.
> 
> Unless sendfile() is something in the OS?

It's a system call, and I believe apache uses it.

> 
> I'll have to dig up a nullmodem and grab console output.  I realise
> I'm not giving enough detailed info to be very helpful here.

It's good enough to squash one bug.  I don't know if it will solve your
problem, though.


>> If you are running the NFS *client* code on this machine, there is one
>> lock assertion that is easy to trigger. 
> 
> In my kernel config I have this, because a diskless box uses the same
> kernel, but my /etc/fstab doesn't mount anyone else's NFS exports.

You won't trigger the the lock violation in the NFS client code unless
you actually mount a file system from another machine using NFS and
actually do some I/O on it.

Here's the patch:

Index: uipc_syscalls.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_syscalls.c,v
retrieving revision 1.150
diff -u -r1.150 uipc_syscalls.c
--- uipc_syscalls.c 12 Jun 2003 05:52:09 -  1.150
+++ uipc_syscalls.c 18 Jun 2003 03:14:42 -
@@ -1775,10 +1775,13 @@
 */
if ((error = fgetvp_read(td, uap->fd, &vp)) != 0)
goto done;
+   vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
if (vp->v_type != VREG || VOP_GETVOBJECT(vp, &obj) != 0) {
error = EINVAL;
+   VOP_UNLOCK(vp, 0, td);
goto done;
}
+   VOP_UNLOCK(vp, 0, td);
if ((error = fgetsock(td, uap->s, &so, NULL)) != 0)
goto done;
if (so->so_type != SOCK_STREAM) {

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

fun with WITNESS and "pool mutex"

[Don Lewis]

When I was attempting to debug a system deadlock problem where the
culprit process was sleeping on a "pool mutex", I noticed that "show
witness" in ddb doesn't report anything about this particular mutex
flavor.  I discovered that witness doesn't monitor these mutexes because
mtx_pool_setup() calls mtx_init with the MTX_NOWITNESS flag.

These are a mutexes bit special, because they are supposed to be leaf
mutexes and no other mutexes should be grabbed after them.  The deadlock
in question caused me to discover a violation of this restriction, so I
wondered if there were more problems of this type in the code.  I
suspected there would be, since there haven't been any automatic checks
of to verify that these mutexes are being used correctly.

Just for grins, I removed the MTX_NOWITNESS flag from mtx_pool_setup()
and quickly found the first violation during the boot sequence:

Mounting root from ufs:/dev/da0s1a
acquiring duplicate lock of same type: "pool mutex"
 1st pool mutex @ /usr/src/sys/kern/vfs_syscalls.c:736
 2nd pool mutex @ /usr/src/sys/kern/kern_lock.c:598
Stack backtrace:
backtrace(c051f4df,c051c041,c051adcc,256,c05e4808) at backtrace+0x17
witness_lock(c05e0cf0,8,c051adcc,256,c05e2ae0) at witness_lock+0x697
_mtx_lock_flags(c05e0cf0,0,c051adcc,256,c641a248) at _mtx_lock_flags+0xb1
lockstatus(c641a304,0,e4b1ab24,c036f2e8,e4b1ab44) at lockstatus+0x3c
vop_stdislocked(e4b1ab44,e4b1ab30,c0464f78,e4b1ab44,e4b1ab58) at vop_stdislocked
+0x21
vop_defaultop(e4b1ab44,e4b1ab58,c0375a67,e4b1ab44,c05e4808) at vop_defaultop+0x1
8
ufs_vnoperate(e4b1ab44,c05e4808,c05740ac,c05b67e0,c641a248) at ufs_vnoperate+0x1
8
assert_vop_locked(c641a248,c05197fc,c05b74e0,c641a248,0) at assert_vop_locked+0x
47
VOP_GETVOBJECT(c641a248,0,c0524224,2e0,c05740ac) at VOP_GETVOBJECT+0x3f
kern_open(c61c64c0,bfbff6b0,0,1,0) at kern_open+0x44f
open(c61c64c0,e4b1ad10,c0537dc3,3fd,3) at open+0x30
syscall(2f,2f,2f,1,0) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (5), eip = 0x80529ef, esp = 0xbfbff16c, ebp = 0xbfbff208 ---


The code in question:

FILEDESC_LOCK(fdp);
FILE_LOCK(fp);
if (fp->f_count == 1) {
KASSERT(fdp->fd_ofiles[indx] != fp,
("Open file descriptor lost all refs"));
FILEDESC_UNLOCK(fdp);
FILE_UNLOCK(fp);
VOP_UNLOCK(vp, 0, td);
vn_close(vp, flags & FMASK, fp->f_cred, td);   
fdrop(fp, td);
td->td_retval[0] = indx;
return 0;
}
  
/* assert that vn_open created a backing object if one is needed */
KASSERT(!vn_canvmio(vp) || VOP_GETVOBJECT(vp, NULL) == 0,
("open: vmio vnode has no backing object after vn_open"));

fp->f_data = vp;
fp->f_flag = flags & FMASK;
fp->f_ops = &vnops;
fp->f_type = (vp->v_type == VFIFO ? DTYPE_FIFO : DTYPE_VNODE);
FILEDESC_UNLOCK(fdp);
FILE_UNLOCK(fp);

This one appears to be easily fixable by moving the second KASSERT down
a few lines to below the FILE_UNLOCK() call.

Any bets on how many other potential deadlock problems there are in the
tree?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepablelocks

[Don Lewis]

On 18 Jun, Chris Shenton wrote:
> Don Lewis <[EMAIL PROTECTED]> writes:
> 
>> Try the very untested patch below ...
> 
>> RCS file: /home/ncvs/src/sys/kern/uipc_syscalls.c,v
> 
> When I do the patch, how much of the OS do I need to rebuild, just do
> a "make install" in the ".../src/sys/kern" dir?  Rebuild the OS from
> the top dir? Rebuild the kernel?  I want to make sure I'm giving this
> a proper test.

If the only changes since the last buildworld have been in src/sys, then
the slow but safe way is:
make buildkernel
make installkernel
The quicker way is:
cd /usr/obj/usr/src/sys/KERNELCONFNAME
make
make install
You can do "make reinstall" instead of "make install" if you don't want
/boot/kernel.old to be nuked and boot/kernel to be renamed to
/boot/kernel.old before the new kernel is installed.

You'll have to do it the slow way if you've changed your kernel
configuration.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepablelocks

[Don Lewis]

On 18 Jun, Chris Shenton wrote:
> Don Lewis <[EMAIL PROTECTED]> writes:
> 
>> Try the very untested patch below ...
> 
>> RCS file: /home/ncvs/src/sys/kern/uipc_syscalls.c,v
>> retrieving revision 1.150
>> Try the very untested patch below ...
>> diff -u -r1.150 uipc_syscalls.c
>> --- uipc_syscalls.c  12 Jun 2003 05:52:09 -  1.150
>> +++ uipc_syscalls.c  18 Jun 2003 03:14:42 -
>> @@ -1775,10 +1775,13 @@
>>   */
>>  if ((error = fgetvp_read(td, uap->fd, &vp)) != 0)
>>  goto done;
>> +vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
>>  if (vp->v_type != VREG || VOP_GETVOBJECT(vp, &obj) != 0) {
>>  error = EINVAL;
>> +VOP_UNLOCK(vp, 0, td);
>>  goto done;
>>  }
>> +VOP_UNLOCK(vp, 0, td);
> 
> Tried it, rebuilt kernel, rebooted, no affect :-(
> 
> You were correct about apache using it.  Doing a simple
> 
>   fetch http://pectopah/
> 
> causes the error, dropping me into ddb if panic enabled. A "tr" shows
> the same trace as I submitted yesterday :-(

Wierd ... I just tested the patch with ftpd which also uses sendfile()
and didn't get any complaints from DEBUG_VFS_LOCKS.

I'm going to go ahead and commit this patch.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: fun with WITNESS and "pool mutex"

[Don Lewis]

On 18 Jun, I wrote:
> When I was attempting to debug a system deadlock problem where the
> culprit process was sleeping on a "pool mutex", I noticed that "show
> witness" in ddb doesn't report anything about this particular mutex
> flavor.  I discovered that witness doesn't monitor these mutexes because
> mtx_pool_setup() calls mtx_init with the MTX_NOWITNESS flag.
> 
> These are a mutexes bit special, because they are supposed to be leaf
> mutexes and no other mutexes should be grabbed after them.  The deadlock
> in question caused me to discover a violation of this restriction, so I
> wondered if there were more problems of this type in the code.  I
> suspected there would be, since there haven't been any automatic checks
> of to verify that these mutexes are being used correctly.
> 
> Just for grins, I removed the MTX_NOWITNESS flag from mtx_pool_setup()
> and quickly found the first violation during the boot sequence:

[ snip - I committed a patch ]

> Any bets on how many other potential deadlock problems there are in the
> tree?

The only problems I've found so far are in fdrop_locked() and
kern_open(), so things might not be as bleak as I initially feared.

I also got this LOR message from witness about the sx lock code:

lock order reversal
 1st 0xc05e1020 pool mutex (pool mutex) @ /usr/src/sys/kern/kern_sx.c:111
 2nd 0xc05dfa00 module subsystem sx lock (module subsystem sx lock) @ /usr/src/s
ys/kern/kern_module.c:126

I *think* this is actually a safe use of pool mutex.  What would be the
best way to quite the complaint?  The two possibilities that I can think
of are to handle this as a special case in the witness code or to
slightly rearrange the code in sx_lock.c to swap the order of the
WITNESS_LOCK() and mtx_unlock() calls in _sx*_lock().


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"