Re: ATA errors on recent -current
Giorgos Keramidas wrote: ad0: READ command timeout tag=1 serv=1 - resetting ata0: resetting devices .. ad0: invalidating queued requests done Turn off tagged queing. S?ren knows about this error and tries to reproduce it (but fails as far as I know). I've seen this quite a few times, but I can't reliably reproduce it yet. It seems to hit me a lot when the ad0 drive spins like crazy doing stuff that is heavy on disk I/O. Disabling tag queueing now to see if this fixes things. But even if it does, I think I should enable it again and help S?ren track this down, if I can. Is your drive perchance an IBM DTLA? It's known to have these problems. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Terry Lambert wrote: Giorgos Keramidas wrote: ad0: READ command timeout tag=1 serv=1 - resetting ata0: resetting devices .. ad0: invalidating queued requests done Turn off tagged queing. S?ren knows about this error and tries to reproduce it (but fails as far as I know). I've seen this quite a few times, but I can't reliably reproduce it yet. It seems to hit me a lot when the ad0 drive spins like crazy doing stuff that is heavy on disk I/O. Disabling tag queueing now to see if this fixes things. But even if it does, I think I should enable it again and help S?ren track this down, if I can. Is your drive perchance an IBM DTLA? It's known to have these problems. Cool! would you like to share where that information is available so I can possibly work around the problem ?? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
On 15 Apr, Giorgos Keramidas wrote: I updated to -current today and am now getting these errors ad0: READ command timeout tag=1 serv=1 - resetting ata0: resetting devices .. ad0: invalidating queued requests done Turn off tagged queing. S?ren knows about this error and tries to reproduce it (but fails as far as I know). I've seen this quite a few times, but I can't reliably reproduce it yet. It seems to hit me a lot when the ad0 drive spins like crazy doing stuff that is heavy on disk I/O. Disabling tag queueing now to see if this fixes things. But even if it does, I think I should enable it again and help S?ren track this down, if I can. There are a lot of people which want to help him... First I got it only once (as you in a heavy disk I/O situation). After another new world I got it at every boot... Some people see this after the mega MFC on -stable too. Bye, Alexander. -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Mouse in Xfree86 4.2.0
Hello When I start XFree86 I get the error that /dev/mouse can't be found, OK devfs seems to be installd so MAKEDEV dosn't exist anymore, is there anyway to get /dev/mouse working as in FreeBSD 4? Thanks /John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Alexander Leidinger wrote:
I've seen this quite a few times, but I can't reliably reproduce it
yet. It seems to hit me a lot when the ad0 drive spins like crazy
doing stuff that is heavy on disk I/O. Disabling tag queueing now to
see if this fixes things. But even if it does, I think I should
enable it again and help S?ren track this down, if I can.
There are a lot of people which want to help him...
First I got it only once (as you in a heavy disk I/O situation). After
another new world I got it at every boot...
Some people see this after the mega MFC on -stable too.
Could I have you guys try this simple patch ?
Index: ata-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
retrieving revision 1.149
diff -u -r1.149 ata-all.c
--- ata-all.c 10 Apr 2002 11:18:07 - 1.149
+++ ata-all.c 15 Apr 2002 08:05:49 -
@@ -1009,13 +1009,12 @@
rman_get_start(atadev-channel-r_io),
command, lba, count, feature, flags);
#endif
-
-/* select device */
-ATA_OUTB(atadev-channel-r_io, ATA_DRIVE, ATA_D_IBM | atadev-unit);
-
/* disable interrupt from device */
if (atadev-channel-flags ATA_QUEUED)
ATA_OUTB(atadev-channel-r_altio, ATA_ALTSTAT, ATA_A_IDS | ATA_A_4BIT);
+
+/* select device */
+ATA_OUTB(atadev-channel-r_io, ATA_DRIVE, ATA_D_IBM | atadev-unit);
/* ready to issue command ? */
if (ata_wait(atadev, 0) 0) {
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
On 14 Apr, Terry Lambert wrote: Turn off tagged queing. S?ren knows about this error and tries to reproduce it (but fails as far as I know). I've seen this quite a few times, but I can't reliably reproduce it yet. It seems to hit me a lot when the ad0 drive spins like crazy doing stuff that is heavy on disk I/O. Disabling tag queueing now to see if this fixes things. But even if it does, I think I should enable it again and help S?ren track this down, if I can. Is your drive perchance an IBM DTLA? It's known to have these problems. Does this also apply to other IBM drives? (7) root@ttyp2 # dmesg |grep ata Preloaded elf module /boot/kernel/accf_data.ko at 0xc04cbed8. atapci0: VIA 82C686 ATA100 controller port 0xd000-0xd00f at device 7.1 on pci0 atapci0: Correcting VIA config for southbridge data corruption bug ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 58644MB IC35L060AVER07-0 [119150/16/63] at ata0-master UDMA100 afd0: 96MB IOMEGA ZIP 100 ATAPI [32/64/96] at ata1-master PIO0 Bye, Alexander. -- Press every key to continue. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
On 15 Apr, =?x-unknown?Q?S=F8ren?= Schmidt wrote: Some people see this after the mega MFC on -stable too. Could I have you guys try this simple patch ? It failed to apply, applied it by hand. Compiling a new kernel now. Bye, Alexander. -- Where do you think you're going today? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mouse in Xfree86 4.2.0
On Mon, Apr 15, 2002 at 10:02:33AM +0200, John Angelmo wrote: Hello When I start XFree86 I get the error that /dev/mouse can't be found, OK devfs seems to be installd so MAKEDEV dosn't exist anymore, is there anyway to get /dev/mouse working as in FreeBSD 4? Thanks /John Set your mouse as being /dev/sysmouse in your XF86Config. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Alexander Leidinger wrote: On 15 Apr, Søren Schmidt wrote: Some people see this after the mega MFC on -stable too. Could I have you guys try this simple patch ? Does not work. As in: No change or breaks completely (if so how)... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
On 15 Apr, =?x-unknown?Q?S=F8ren?= Schmidt wrote: Some people see this after the mega MFC on -stable too. Could I have you guys try this simple patch ? Does not work. As in: No change or breaks completely (if so how)... Sorry: No change. Bye, Alexander. -- The best things in life are free, but the expensive ones are still worth a look. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mouse in Xfree86 4.2.0
Whats about editing /etc/rc.devfs and inserting a symlink from /dev/mouse to /dev/sysmouse ? On Mon, 2002-04-15 at 08:26, Munish Chopra wrote: On Mon, Apr 15, 2002 at 10:02:33AM +0200, John Angelmo wrote: Hello When I start XFree86 I get the error that /dev/mouse can't be found, OK devfs seems to be installd so MAKEDEV dosn't exist anymore, is there anyway to get /dev/mouse working as in FreeBSD 4? Thanks /John Set your mouse as being /dev/sysmouse in your XF86Config. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
Alexander Leidinger wrote: On 14 Apr, Terry Lambert wrote: Is your drive perchance an IBM DTLA? It's known to have these problems. Does this also apply to other IBM drives? Potentially. IBM renamed the part number when the drives got known to be dogs. I thought they also defaulted the firmware to get around the problem. You would have to check the full threads complaining about the DTLA parts to be certain; I didn't follow the problem closely enough except to recommend using the outer cylinders only for the FS and OS data for an embedded system I worked on at one time (no, not the InterJet). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
Alexander Leidinger wrote: Some people see this after the mega MFC on -stable too. Could I have you guys try this simple patch ? Does not work. No change or breaks completely (if so how)... Sorry: No change. Download the Windows executable I pointed to in a previous posting. Run it. It will create a floppy disk. Using the floppy, set the DMA transfer rate slower on the drive. STANDARD WARNINGS APPLY! MAY HOSE YOUR DISK FIRMWARE IRRETRIEVABLY IF NOT USED CORRECTLY! FOLLOW THE IBM SUPPLIED INSTRUCTIONS TO THE LETTER! I AM NOT RESPONSIBLE FOR WHA?T HAPPENS TO YOUR DISK IF YOU USE THE TOOL! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Terry Lambert wrote: Søren Schmidt wrote: Is your drive perchance an IBM DTLA? It's known to have these problems. Cool! would you like to share where that information is available so I can possibly work around the problem ?? IBM DTLA drives are known to be problematic. If you use that in a search engine, it will find numerous references to the drive electronics being too slow for sustained access to the sectors closes to the spindle. This thread is about tagged queueing problems on IBM drives since they are the only ones that supports it, it is not specific to the DTLA series at all, which this thread has already explained. So Terry, do you have anything to share, or just noise like this ? (I dont care about if the DTLA may have other problems) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
Søren Schmidt wrote: Is your drive perchance an IBM DTLA? It's known to have these problems. Cool! would you like to share where that information is available so I can possibly work around the problem ?? IBM DTLA drives are known to be problematic. If you use that in a search engine, it will find numerous references to the drive electronics being too slow for sustained access to the sectors closes to the spindle. The place I first read about the problem was Tom's hardware. The generally accepted fix is don't use the cylinders nearest the spindle and/or replace the drive. Here's the most complete (if biased) web reference I found: http://www.goldengate.net/~dlpeters/IBMSucks/ This has been discussed on the FreeBSD lists before... the supposed problem cited was the electronics could not keep up with the data rate on the interior cylinders. Supposely, one of the utilities on this page: http://www.axiontech.com/cgi-local/download.asp?product=hdibmutilhard_drives can work around the problem (depending on the drive you have) by changing some firmware settings on the drive. If you are interested, get them while you can: this is a mirror of an IBM set of downloads which are no longer available from the IBM URLs where they used to be located. The workaround works by setting a lower DMA transfer rate. Here is a PDF about the drives, which mentions the tool and its use: http://vendors.asbis.com/download/D60GXP_ht20.pdf Again, this is mirrored from an IBM URL that is no longer available, so if you intend to grab it, grab it now. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Terry Lambert wrote: IBM DTLA drives are known to be problematic. If you use that in a search engine, it will find numerous references to the drive electronics being too slow for sustained access to the sectors closes to the spindle. This thread is about tagged queueing problems on IBM drives since they are the only ones that supports it, it is not specific to the DTLA series at all, which this thread has already explained. So Terry, do you have anything to share, or just noise like this ? (I dont care about if the DTLA may have other problems) Sorry; all I can give you is hear-say, which I guess you could consider to be noise, except we confirmed that the problem disk in this case was an IBM drive, which tends to support the theory. Indeed, the problem at hand here show up on *any* tagged queueing capable drive, it is not specific to a certain model. For a more scientific test, downloading the firmware tool and setting the DMA transfer rate down, and checking for problems, would be pretty overwhelming evidence. Personally, I don't have any of the buggers lying around to test with any more. Why on earth would you do that ? (hint man atacontrol) Besides I dont see this as any evidence at all, but thats another matter... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
Søren Schmidt wrote: For a more scientific test, downloading the firmware tool and setting the DMA transfer rate down, and checking for problems, would be pretty overwhelming evidence. Personally, I don't have any of the buggers lying around to test with any more. Why on earth would you do that ? (hint man atacontrol) Besides I dont see this as any evidence at all, but thats another matter... If it fixes the problem, then the problem is most likely related to what firmware setting the tool changes. 8-). From my reading of the FreeBSD man pages, it can't blow the flash byte that controls the DMA speed, like the IBM provided utility does. Obviously, turning off tagged commands works, according to at least one person who is reporting the problem. I wonder if limiting outstanding tagged commands to less than the number advertised by the drive would also work... can't be worse than the initialization reordering patch that failed (e.g the worst case is it still has the problems). A lot safer than banging bits in the firmware, I'm sure, though... Limiting the outstanding tagged commands to less than the advertised amount would actually be my first choice of a hack for a software workaround. Can you do that with sysctl hw.ata.tags=XXX? Or is that just a 1/0 thing? A scan doesn't indicate documentation, but I'm probably just not looking very hard... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: plug aue ethernet goes to panic
jhb Can you get a backtrace in ddb? It looks like a null pointer jhb dereference, and knowing where it happened would help. Backtrace told me that the panic was occured when usbd_get_interface_descriptor() is called from aue_attach(). jhb Finding the file and line of the instruction pointer using jhb addr2line on kernel.debug would be helpful as well. But unfortunately, my kernel.debug prints uhub0: device problem, disabling port 2 and doesn't panic :-( *** I've confirmed that kernel and its module are in sync. There no /modules directory since this machine was born as 5-current box, and /boot/modules directory is empty. ident(1) output of src/sys/dev/usb is attached below. -- - Makoto `MAR' Matsushita /sys/dev/usb/dsbr100io.h: $FreeBSD: src/sys/dev/usb/dsbr100io.h,v 1.1 2002/03/04 03:51:19 alfred Exp $ /sys/dev/usb/hid.c: $NetBSD: hid.c,v 1.17 2001/11/13 06:24:53 lukem Exp $ $FreeBSD: src/sys/dev/usb/hid.c,v 1.18 2002/04/07 17:53:58 joe Exp $ /sys/dev/usb/hid.h: $NetBSD: hid.h,v 1.6 2000/06/01 14:28:57 augustss Exp $ $FreeBSD: src/sys/dev/usb/hid.h,v 1.11 2002/04/01 19:01:08 joe Exp $ /sys/dev/usb/if_aue.c: $FreeBSD: src/sys/dev/usb/if_aue.c,v 1.56 2002/04/07 12:19:50 joe Exp $ $FreeBSD: src/sys/dev/usb/if_aue.c,v 1.56 2002/04/07 12:19:50 joe Exp $ /sys/dev/usb/if_auereg.h: $FreeBSD: src/sys/dev/usb/if_auereg.h,v 1.13 2002/04/07 12:04:01 joe Exp $ /sys/dev/usb/if_cue.c: $FreeBSD: src/sys/dev/usb/if_cue.c,v 1.28 2002/04/07 12:19:50 joe Exp $ $FreeBSD: src/sys/dev/usb/if_cue.c,v 1.28 2002/04/07 12:19:50 joe Exp $ /sys/dev/usb/if_cuereg.h: $FreeBSD: src/sys/dev/usb/if_cuereg.h,v 1.10 2002/04/07 12:04:01 joe Exp $ /sys/dev/usb/if_kue.c: $FreeBSD: src/sys/dev/usb/if_kue.c,v 1.40 2002/04/07 12:19:50 joe Exp $ $FreeBSD: src/sys/dev/usb/if_kue.c,v 1.40 2002/04/07 12:19:50 joe Exp $ /sys/dev/usb/if_kuereg.h: $FreeBSD: src/sys/dev/usb/if_kuereg.h,v 1.10 2002/04/07 12:04:02 joe Exp $ /sys/dev/usb/kue_fw.h: $FreeBSD: src/sys/dev/usb/kue_fw.h,v 1.2 2000/04/03 20:58:23 n_hibma Exp $ /sys/dev/usb/ohci.c: $NetBSD: ohci.c,v 1.121 2002/03/16 16:11:18 tsutsui Exp $ $FreeBSD: src/sys/dev/usb/ohci.c,v 1.102 2002/04/07 16:36:30 joe Exp $ /sys/dev/usb/ohcireg.h: $NetBSD: ohcireg.h,v 1.17 2000/04/01 09:27:35 augustss Exp $ $FreeBSD: src/sys/dev/usb/ohcireg.h,v 1.18 2002/04/01 13:21:43 joe Exp $ /sys/dev/usb/ohcivar.h: $NetBSD: ohcivar.h,v 1.30 2001/12/31 12:20:35 augustss Exp $ $FreeBSD: src/sys/dev/usb/ohcivar.h,v 1.32 2002/04/07 15:16:31 joe Exp $ /sys/dev/usb/rio500_usb.h: $FreeBSD: src/sys/dev/usb/rio500_usb.h,v 1.1 2000/04/08 17:02:13 n_hibma Exp $ /sys/dev/usb/ucom.c: $NetBSD: ucom.c,v 1.39 2001/08/16 22:31:24 augustss Exp $ $FreeBSD: src/sys/dev/usb/ucom.c,v 1.16 2002/04/01 21:30:36 jhb Exp $ /sys/dev/usb/ucomvar.h: $NetBSD: ucomvar.h,v 1.9 2001/01/23 21:56:17 augustss Exp $ $FreeBSD: src/sys/dev/usb/ucomvar.h,v 1.1 2002/03/18 18:23:39 joe Exp $ /sys/dev/usb/udbp.c: $FreeBSD: src/sys/dev/usb/udbp.c,v 1.14 2002/04/04 21:03:17 jhb Exp $ /sys/dev/usb/udbp.h: $FreeBSD: src/sys/dev/usb/udbp.h,v 1.1 2000/05/01 22:48:22 n_hibma Exp $ /sys/dev/usb/ufm.c: $FreeBSD: src/sys/dev/usb/ufm.c,v 1.4 2002/03/11 16:38:53 imp Exp $ /sys/dev/usb/ugen.c: $NetBSD: ugen.c,v 1.51 2001/11/13 07:59:32 augustss Exp $ $FreeBSD: src/sys/dev/usb/ugen.c,v 1.59 2002/03/11 16:22:15 joe Exp $ /sys/dev/usb/ugraphire_rdesc.h: $NetBSD: usb/ugraphire_rdesc.h,v 1.1 2000/12/29 01:47:49 augustss Exp $ $FreeBSD: src/sys/dev/usb/ugraphire_rdesc.h,v 1.1 2002/04/07 17:04:01 joe Exp $ /sys/dev/usb/uhci.c: $NetBSD: uhci.c,v 1.158 2002/03/17 18:02:53 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhci.c,v 1.119 2002/04/07 18:33:12 joe Exp $ /sys/dev/usb/uhcireg.h: $NetBSD: uhcireg.h,v 1.15 2002/02/11 11:41:30 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhcireg.h,v 1.20 2002/04/07 18:06:34 joe Exp $ /sys/dev/usb/uhcivar.h: $NetBSD: uhcivar.h,v 1.33 2002/02/11 11:41:30 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhcivar.h,v 1.33 2002/04/07 18:06:34 joe Exp $ /sys/dev/usb/uhid.c: $NetBSD: uhid.c,v 1.45 2001/10/26 17:58:21 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhid.c,v 1.49 2002/04/07 17:13:00 joe Exp $ /sys/dev/usb/uhub.c: $NetBSD: uhub.c,v 1.57 2001/11/20 16:08:37 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhub.c,v 1.42 2002/04/07 11:29:31 joe Exp $ /sys/dev/usb/ukbd.c: $FreeBSD: src/sys/dev/usb/ukbd.c,v 1.37 2002/04/07 13:16:17 joe Exp $ /sys/dev/usb/ulpt.c: $NetBSD: ulpt.c,v 1.46 2001/12/31 12:15:21 augustss Exp $ $FreeBSD: src/sys/dev/usb/ulpt.c,v 1.43 2002/03/11 16:22:15 joe Exp $ /sys/dev/usb/umass.c: $FreeBSD: src/sys/dev/usb/umass.c,v 1.60 2002/04/11 21:09:41 jhb Exp $ $NetBSD: umass.c,v 1.28 2000/04/02 23:46:53 augustss Exp $ /sys/dev/usb/umodem.c: $NetBSD: umodem.c,v 1.5
Re: ATA errors on recent -current
It seems Terry Lambert wrote: Søren Schmidt wrote: For a more scientific test, downloading the firmware tool and setting the DMA transfer rate down, and checking for problems, would be pretty overwhelming evidence. Personally, I don't have any of the buggers lying around to test with any more. Why on earth would you do that ? (hint man atacontrol) Besides I dont see this as any evidence at all, but thats another matter... If it fixes the problem, then the problem is most likely related to what firmware setting the tool changes. AFAIK it only set the maximum DMA speed the drive will allow, that you can do with atacontrol as well... Obviously, turning off tagged commands works, according to at least one person who is reporting the problem. Again that has *nothing* to do with the DTLA drives and DMA speed and the phase of the moon... But it shows (as we already know) that using tags on any drive that supports it, can fail on some systems. I wonder if limiting outstanding tagged commands to less than the number advertised by the drive would also work... can't be worse than the initialization reordering patch that failed (e.g the worst case is it still has the problems). A lot safer than banging bits in the firmware, I'm sure, though... Limiting the outstanding tagged commands to less than the advertised amount would actually be my first choice of a hack for a software workaround. Thats not the problem either, the problem is that I apparently changed some subtle bits that make it fail on some systems, regardless of controller and disk type, but which is marginal enough that I cant reproduce the problem here in the lab... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
On 15 Apr, Terry Lambert wrote: Obviously, turning off tagged commands works, according to at least one person who is reporting the problem. It helps every one I know of. [...] Limiting the outstanding tagged commands to less than the advertised amount would actually be my first choice of a hack for a software workaround. Can you do that with sysctl hw.ata.tags=XXX? Or is that just a 1/0 thing? A scan doesn't indicate documentation, but I'm probably just not looking very hard... It's only a 1/0 thing (at least at the moment). Bye, Alexander. -- To boldly go where I surely don't belong. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
On 15 Apr, Søren Schmidt wrote: Again that has *nothing* to do with the DTLA drives and DMA speed and the phase of the moon... But perhaps it depends on the distance between the drive and the nordpole... the ones with the problems are all more far away from it than you... ;-) But it shows (as we already know) that using tags on any drive that supports it, can fail on some systems. More strangely: it worked for me a lot longer than for other people. The first kernel which showed the problem to me was a Apr 8(?) kernel, Martin Schündehütte complained already with a Mar xx (xx 28) kernel in de.comp.os.unix.bsd. I wonder if limiting outstanding tagged commands to less than the number advertised by the drive would also work... can't be worse than the initialization reordering patch that failed (e.g the worst case is it still has the problems). A lot safer than banging bits in the firmware, I'm sure, though... Limiting the outstanding tagged commands to less than the advertised amount would actually be my first choice of a hack for a software workaround. Thats not the problem either, the problem is that I apparently changed some subtle bits that make it fail on some systems, regardless of controller and disk type, but which is marginal enough that I cant reproduce the problem here in the lab... What about Brian's offer to give you access to his machine? Isn't this enough in this case to play a little bit? Bye, Alexander. -- The best things in life are free, but the expensive ones are still worth a look. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
This mornings world broken in libpam modules.
This could already be fixed but if not, mine broke at: /lib/libpam/modules/pam_unix/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_unix/../../libpam -Werror -Wall -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/lib/libpam/modules/pam_unix/../../../../usr.sbin/vipw/pw_util.c -o pw_util.So make: don't know how to make /usr/obj/usr/src/i386/usr/lib/libypclnt.a. Stop *** Error code 2 Stop in /usr/src/lib/libpam/modules. *** Error code 1 Stop in /usr/src/lib/libpam. *** Error code 1 ed - http://insourcery.com - Mergence of Business and Technology a Griffin Plaza Partners, LLC Company To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: This mornings world broken in libpam modules.
Le 2002-04-15, Edwin Culp écrivait : This could already be fixed but if not, mine broke at: It is fixed in Makefile.inc1 rev. 1.256. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Error on make
Good afternoon After upgrading FREEBSD to version 4.5 STABLE can't make any port. Always it's stoped with error: Error: your port uses an old layout. Please update it to match this bsd.port.mk . If you have updated your ports collection via cvsup and are still getting thi s error, see Q12 and Q13 in the cvsup FAQ on http://www.polstra.com for further information. *** Error code 1 I've downloaded new ports by CVSUP but problem remains. supfile: *default host=cvsup2.ca.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs tag=. *default delete use-rel-suffix *default compress ports-all release=cvs How can I fix this problem? -- Best regards, Vadim Zaychenko mailto:[EMAIL PROTECTED] ICQ: 92369162 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
On 15 Apr, Giorgos Keramidas wrote: Is your drive perchance an IBM DTLA? It's known to have these problems. Nay. A Western Digital disk I bought about 2.5 years ago. And it does tagged queing? I thought IBM is the only manufacturer of such IDE drives... Bye, Alexander. -- The dark ages were caused by the Y1K problem. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Giorgos Keramidas wrote: On 2002-04-14 23:46, Terry Lambert wrote: Is your drive perchance an IBM DTLA? It's known to have these problems. Nay. A Western Digital disk I bought about 2.5 years ago. Hmm, AFAIK WD newer had a disk that worked right with tags, and I've newer been able to find a workaround on those I have here in the lab -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Testers for an icc compiled kernel wanted
Hi, I've got a lot of LINT compiled with icc. If someone feels adventuresomely he may grab http://www.leidinger.net/FreeBSD/icc_20020415.diff, apply it, and do a cd /sys/i386/compile/kernel make clean make depend make -i CWARNFLAGS= NO_WARNS=YES USE_ICC=YES I'm interested in everything he may find out (no need to report things I already know: http://www.leidinger.net/FreeBSD/LINT_with_icc_20020415.log.bz2), even the good ones (e.g. a working kernel :-) ). Patches welcome, off course. If someone has some spare time he wants to spend to making the kernel compilable with icc: find places where opt_global.h is needed and add an include directive (it has to be the first one) for it. Bye, Alexander. -- It's not a bug, it's tradition! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mouse in Xfree86 4.2.0
I had this similiar problem. Sysinstall - post configure and re-do your mouse. The only workaround I have found. /ges At 10:02 AM 4/15/2002 +0200, John Angelmo wrote: Hello When I start XFree86 I get the error that /dev/mouse can't be found, OK devfs seems to be installd so MAKEDEV dosn't exist anymore, is there anyway to get /dev/mouse working as in FreeBSD 4? Thanks /John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Testers for an icc compiled kernel wanted
--- Alexander Leidinger [EMAIL PROTECTED] wrote: Hi, I've got a lot of LINT compiled with icc. If someone feels adventuresomely he may grab http://www.leidinger.net/FreeBSD/icc_20020415.diff, apply it, and do a FYI, You need to rename your online patch from icc_2020415.diff to icc_20020415.diff. ;) I accessed with the below URL: http://www.leidinger.net/FreeBSD/icc_2020415.diff Hope that helps. Regards, -- Hiten __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mouse in Xfree86 4.2.0
--- Gary Stanley [EMAIL PROTECTED] wrote: Sysinstall - post configure and re-do your mouse. The only workaround I have found. The other way, is to edit your XF86Config to point to /dev/pcm0 (if you are using a PS2 mouse), or /dev/sioN (N being the COM port number), which gives XFree86 direct access to your mouse. But remember, if you do this, you will need to disable the moused from Sysinstall. When I start XFree86 I get the error that /dev/mouse can't be found, OK devfs seems to be installd so MAKEDEV dosn't exist anymore, is there anyway to get /dev/mouse working as in FreeBSD 4? Technically the MAKEDEV script still exists in src/etc/MAKEDEV*, but it is only copied to /dev if you have disabled the DEVFS k-option, afaik. -- Hiten Pandya -- [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mouse in Xfree86 4.2.0
Hiten Pandya wrote: --- Gary Stanley [EMAIL PROTECTED] wrote: Sysinstall - post configure and re-do your mouse. The only workaround I have found. The other way, is to edit your XF86Config to point to /dev/pcm0 (if you are using a PS2 mouse), or /dev/sioN (N being the COM port number), which gives XFree86 direct access to your mouse. But remember, if you do this, you will need to disable the moused from Sysinstall. When I start XFree86 I get the error that /dev/mouse can't be found, OK devfs seems to be installd so MAKEDEV dosn't exist anymore, is there anyway to get /dev/mouse working as in FreeBSD 4? Technically the MAKEDEV script still exists in src/etc/MAKEDEV*, but it is only copied to /dev if you have disabled the DEVFS k-option, afaik. -- Hiten Pandya -- [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message /dev/sysmouse woked best for me since I have both a USB mouse and a touchpad so with /dev/sysmouse both works. /John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pcm?
I wonder how the pcm sound support is in 5.0? I didn't get it working in 4.5 but perhaps theres better support in 5.0 but I didn't find any info in NOTES /John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
On 2002-04-15 15:56, Sren Schmidt wrote: It seems Giorgos Keramidas wrote: On 2002-04-14 23:46, Terry Lambert wrote: Is your drive perchance an IBM DTLA? It's known to have these problems. Nay. A Western Digital disk I bought about 2.5 years ago. Hmm, AFAIK WD newer had a disk that worked right with tags, and I've newer been able to find a workaround on those I have here in the lab It doesn't. You're right. I had posted that message before checking with `atacontrol cap'. My problems with the disk are obviously caused by something else that's broken in my local setup. Sorry for jumping up and making noise :) The console messages I'm getting were similar: | Apr 12 00:09:27 hades kernel: ad0: READ command timeout tag=0 serv=0 - resetting | Apr 12 00:09:28 hades kernel: ata0: resetting devices .. ata0-slave: ATA identify |retries exceeded | Apr 12 00:09:28 hades kernel: done This is caused by something else, as I've found out later. Tags have nothing to do with what I'm seeing. Before saying hey, this is a bug I want to do further tests to make sure that it's not the hardware's fault. Giorgos. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pcm?
--- John Angelmo [EMAIL PROTECTED] wrote: I wonder how the pcm sound support is in 5.0? Hmm, I am using the emu10k1 aka Sound Blaster 1024 Live!, which has some locking problems, but apart from that I dont think there is any other problems AFAIK. :) I didn't get it working in 4.5 but perhaps theres better support in 5.0 but I didn't find any info in NOTES What problem did you exactly have in 4.5 with the pcm support? Regards. -- Hiten Pandya Finger [EMAIL PROTECTED] for PGP public key --- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3 --- msg37284/pgp0.pgp Description: PGP signature
Re: pcm?
Hiten Pandya wrote: --- John Angelmo [EMAIL PROTECTED] wrote: I wonder how the pcm sound support is in 5.0? Hmm, I am using the emu10k1 aka Sound Blaster 1024 Live!, which has some locking problems, but apart from that I dont think there is any other problems AFAIK. :) I didn't get it working in 4.5 but perhaps theres better support in 5.0 but I didn't find any info in NOTES What problem did you exactly have in 4.5 with the pcm support? Well I don't have any dmesg log from my old install. I use ac97 Regards. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Build busted?
In message: [EMAIL PROTECTED] Dag-Erling Smorgrav [EMAIL PROTECTED] writes: : Check that your Makefile.inc1 is up to date. ah, looks like I didn't. Will update and try again. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: plug aue ethernet goes to panic
On Mon, Apr 15, 2002 at 11:11:36AM +0200, Nick Hibma wrote: device_set_ivars is always called (in usbd_probe_and_attach) with as an argument a stack variable. Also, the ivar is not stored or anything in the if_aue.c driver. So this problem sounds like a problem in revisions of various files. Please check that your kernel modules kernel are in sync. Do this by rebuilding the kernel and the modules from scratch. Also, after you've installed your kernel check that all your kernel files have been updated. Do you by any chance have a stale /modules or /boot/modules directory lying around? You should have only kernel modules in /boot/kernel*/ and NOT in /modules* or /boot/modules*. If the problem persists, please mail me the output of ident /sys/dev/usb/*.[ch] find /modules /boot -type f -ls Nick, You really should talk to Joe Karthauser. He's already confirmed that it *is* an issue in the code (and not any kind of misconfiguration on my part). I've already spent enough time debugging the problem. I recently MFC'd the support for my device to -stable so I could use the machine on the network without it panicking on me. However, when Joe fixes the problem I will give it another shot [same machine has -CURRENT on another partition that I use for occasional hacking]. Thanks for the suggestions, though. Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: plug aue ethernet goes to panic
On Mon, Apr 15, 2002 at 12:35:46PM -0500, Will Andrews wrote: On Mon, Apr 15, 2002 at 11:11:36AM +0200, Nick Hibma wrote: device_set_ivars is always called (in usbd_probe_and_attach) with as an argument a stack variable. Also, the ivar is not stored or anything in the if_aue.c driver. So this problem sounds like a problem in revisions of various files. Please check that your kernel modules kernel are in sync. Do this by rebuilding the kernel and the modules from scratch. Also, after you've installed your kernel check that all your kernel files have been updated. Do you by any chance have a stale /modules or /boot/modules directory lying around? You should have only kernel modules in /boot/kernel*/ and NOT in /modules* or /boot/modules*. If the problem persists, please mail me the output of ident /sys/dev/usb/*.[ch] find /modules /boot -type f -ls Nick, You really should talk to Joe Karthauser. He's already confirmed that it *is* an issue in the code (and not any kind of misconfiguration on my part). I've already spent enough time debugging the problem. I recently MFC'd the support for my device to -stable so I could use the machine on the network without it panicking on me. However, when Joe fixes the problem I will give it another shot [same machine has -CURRENT on another partition that I use for occasional hacking]. Nick, I've introduced a probe and attach bug somewhere with aue, and I'm guessing with cue and kue too. I'm gradually getting to the bottom of it, but this is the first time I've gone near the attach code so it's taking me longer than it should. Joe msg37291/pgp0.pgp Description: PGP signature
Re: ATA errors on recent -current
I'm very sorry if I will be a bit unpolite, but I have to mail the following statement concerning the DTLA-Disks and FreeBSD: It may be all true and horrible, but - I still have an old FreeBSD Test-Installation (45GB are big enough :-) with a 4.4-STABLE as of Okt 23, 2001... It boots off the DTLA, uses tagged-queuing and connects using UDMA100... ... and doesn't have any problems!! So, to bring some of you down to earth again, the DTLA may be a horrible disk and I'm one of the last to praise ATA at all (My machine has two SCSI host adaptors, five SCSI-Disks and several other SCSI Devices), but it once worked! I really, really don't want to blame Søren, he's doing a great job and everybody, who makes something makes occasionally some errors, but (at least for me) it doesn't seem to be a fundamental technical problem, because *it once worked* - sorry, but it's true. And maybe it isn't related to tagged queuing and the DTLA at all - if I correctly understand Giorgos' mail... -- Ciao/BSD - Matthias Matthias Schuendehuette [EMAIL PROTECTED], Berlin (Germany) Powered by FreeBSD 4.5-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Bluetooth stack for FreeBSD
Folks, [probably should be cc'd to -mobile as well] An engineering release of Bluetooth stack for -current FreeBSD is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020415.tar.gz i'm interested to hear from people who familiar with FreeBSD kernel, Netgraph and/or Bluetooth. all your questions/comments/ suggestions are accepted and greatly appreciated. this is my first Netgraph stack, so please don't me hard :) thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Vinum problems
Bernd, This sounds very promising, but I want to make sure I do this correctly. When you say to remove the plexes, that means to use 'vinum rm' with appropriate options, correct? As far as reconfiguring, can I use the output from 'vinum printconfig' as the input configuration file? Thanks very much for your help. -Patrick Bernd Walter wrote: On Fri, Apr 12, 2002 at 05:46:29PM -0500, Patrick Hartling wrote: I suffered a system crash earlier today running -current from April 10. I have a Vinum volume set up as a mirror, and during the reboot, I had to fsck it. Everything seemed normal (at least that's what I thought), but now my volume cannot be mounted. The output from 'vinum list' is as follows: 2 drives: D a State: up /dev/da3s1e A: 0/12288 MB (0%) D b State: up /dev/da4s1e A: 0/12288 MB (0%) 1 volumes: V mirrorState: down Plexes: 2 Size: 11 GB 2 plexes: P mirror.p0 C State: faulty Subdisks: 1 Size: 11 GB P mirror.p1 C State: faulty Subdisks: 1 Size: 11 GB 2 subdisks: S mirror.p0.s0 State: crashed D: aSize: 11 GB S mirror.p1.s0 State: crashed D: bSize: 11 GB The fact that it says the drives have 0% used greatly concerns me. Before I delve into this any further, is that a sign that everything I had is just gone? Or is there some hope of recovery? There is nothing in /var/log/vinum_hitsory or /var/log/messages that gives me any insight into what went wrong. You have *both* plexes faulty which means that you either have waited too long running with only one disk left or that both failed a once. For the second point can be channel or power supply issues if they share a single resource in common. You will find it out by reading your log files. Of course you should fix the failure reason before doing anything else. I have made a bad expirience once in that if you revive one plex now you will get zeros written because there is no reference plex left. Greg: It's long ago but I forgot to tell you. Do you remember anything about such a bug got fixed? The shure way is to store the vinum printconfig output and then remove both plexes. finaly reconfigure them both beginning using the values from printconfig and start with the drive which run at last, because it has the most recent data. -- Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED] | 2624 Howe Hall -- (515)294-4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Vinum problems
On Mon, Apr 15, 2002 at 04:08:43PM -0500, Patrick Hartling wrote: Bernd, This sounds very promising, but I want to make sure I do this correctly. When you say to remove the plexes, that means to use 'vinum rm' with appropriate options, correct? As far as reconfiguring, can I use the output from 'vinum printconfig' as the input configuration file? Thanks very much for your help. You have to reduce the printconfig output to configure only the plex with the reference data first. Once it's mountable you can add the second plex as well. And don't forget to look for the reason it failed originaly. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sort and gperf
On Sat, 13 Apr 2002, Clive Lin wrote: Hi, sort and gperf was not installed after make world. I think sort is easy to deal with, but I have no idea about gperf. Does this intend to be ? (On regular i386 platform, of course) ... gperf: (Only gperf.info.gz installed !?) /usr/src/gnu/usr.bin/gperf# make install === doc install-info --quiet --defsection=Programming development tools. --defentry=* Gperf: (gperf).The GNU perfect hash function generator. gperf.info /usr/share/info/dir install -c -o root -g wheel -m 444 gperf.info.gz /usr/share/info /usr/src/gnu/usr.bin/gperf# gperf is still broken (mostly not even built). This patch has not been tested by makeworld. %%% Index: Makefile === RCS file: /home/ncvs/src/gnu/usr.bin/gperf/Makefile,v retrieving revision 1.8 diff -u -2 -r1.8 Makefile --- Makefile11 Apr 2002 11:06:06 - 1.8 +++ Makefile15 Apr 2002 21:13:30 - @@ -7,5 +7,5 @@ SUBDIR=doc -PROG_GCC= gperf +PROG_CXX= gperf SRCS= bool-array.cc gen-perf.cc hash-table.cc iterator.cc key-list.cc \ list-node.cc main.cc new.cc options.cc read-line.cc trace.cc \ %%% Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mouse in Xfree86 4.2.0
On Mon, Apr 15, 2002 at 10:02:33AM +0200, John Angelmo wrote: When I start XFree86 I get the error that /dev/mouse can't be found, OK devfs seems to be installd so MAKEDEV dosn't exist anymore, is there anyway to get /dev/mouse working as in FreeBSD 4? I have requested of both the XFree86-4 Server and of Portmgr to make the default mouse device /dev/sysmouse. But my emails have gone unanswered. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic (swp_pager_meta_ctl+0x67) in today's -CURRENT
Have had a touch more turbulence than usual in -CURRENT-land today. Finally got it built; re-booted, and got the following panic while setting up an md-resident file system (for /tmp): ... add net default: gateway 172.16.8.1 Additional routing options:. Routing daemons:. Additional daemons: syslogdApr 15 15:22:09 freebeast syslogd: kernel boot file is /boot/kernel/kernel . Doing additionalO network setup: lntpdated: time_adjtime = 0.00 0 New: time_adjtime = 0.290799 290799 ntpd rpcbind. Starting final network daemons: mountdApr 15 15:22:09 freebeast mountd[182]: bad exports list line /S1/usr Apr 15 15:22:09 freebeast mountd[182]: bad exports list line /S2/usr Apr 15 15:22:09 freebeast mountd[182]: bad exports list line /S3/usr Apr 15 15:22:09 freebeast mountd[182]: bad exports list line /S4/usr Apr 15 15:22:10 freebeast mountd[182]: could not remount /cdrom: Invalid argument Apr 15 15:22:10 freebeast mountd[182]: bad exports list line /cdrom-ro -alldirs nfsd NFS access cache time=2. ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout Starting standard daemons: inetd cron sshd sendmail-submit sendmail-clientmqueue. Recovering vi editor sessions:. Initial rc.i386 initialization:. Configuring syscons: blanktime. Additional ABI support:. Local package initiCalization:reating DISK md10 md10: invalid primary partition table: no magic md10: invalid primary partition table: no magic er inode restric group to 6. per /dev/md10c: 1048F576 sectors in 3a2 cylinders of 1t tracks, 32768 saectors l trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0283ba7 stack pointer = 0x10:0xd911cb00 frame pointer = 0x10:0xd911cb10 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 229 (newfs) kernel: type 12 trap, code=0 Stopped at swp_pager_meta_ctl+0x67:cmpl%ebx,0x4(%eax) db trace swp_pager_meta_ctl(d91363c0,1,0,ce59de70,d9120c00) at swp_pager_meta_ctl+0x67 swap_pager_strategy(d91363c0,ce59de70,d911cb60,c01492b0,d91363c0) at swap_pager_strategy+0xdf vm_pager_strategy(d91363c0,ce59de70,d911cb7c,c0149427,d9120c00) at vm_pager_strategy+0x21 mdstart_swap(d9120c00,ce59de70) at mdstart_swap+0x30 mdstrategy(ce59de70,0,ce59de70,d911cbb8,c01a2fb3) at mdstrategy+0x16f diskstrategy(ce59de70,d912bc00) at diskstrategy+0xa1 physio(d912bc00,d911cc90,1,d912bc00,d913f0f0) at physio+0x273 spec_write(d911cc24,d911cc38,c01ee513,d911cc24,1000) at spec_write+0x5d spec_vnoperate(d911cc24,1000,d911cd20,0,1) at spec_vnoperate+0x15 vn_write(d8fd2b04,d911cc90,ce51c300,0,d8fe0728) at vn_write+0x1bb dofilewrite(d8fe0728,d8fd2b04,3,808c0e0,1000) at dofilewrite+0xb6 write(d8fe0728,d911cd20,0,1000,4000) at write+0x3b syscall(2f,2f,2f,4000,1000) at syscall+0x24f syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (4, FreeBSD ELF, write), eip = 0x804cddf, esp = 0xbfbffb1c, ebp = 0xbfbffb38 --- db Context switches not allowed in the debugger. db Some notes: * I was able to bring it up in single-user mode OK. * The whines about inability to mount certain file systems are just that -- whines. I have the system set up to boot from any of several slices, and I have /etc/fstab set up as a symlink to the appropriate one for the slice in question (to make cloning a slice easier). I didn't bother also making separate /etc/exports files, figuring that the system would whine, but that the whines would be otherwise benign. So I don't advise getting too hung up on these. [Move along, now; nothing here to see] * This is my build machine, so until fairly late tonight, it doesn't have anything else to do. Thus, I can re-create the problem poke at it, try things out, * Here's the recent CVSup activity: # tail /var/log/cvsup-history.log CVSup begin from cvsup14.freebsd.org at Fri Apr 12 06:34:50 PDT 2002 CVSup ended from cvsup14.freebsd.org at Fri Apr 12 06:41:34 PDT 2002 CVSup begin from cvsup14.freebsd.org at Sat Apr 13 03:47:02 PDT 2002 CVSup ended from cvsup14.freebsd.org at Sat Apr 13 03:55:58 PDT 2002 CVSup begin from cvsup14.freebsd.org at Sun Apr 14 03:47:02 PDT 2002 CVSup ended from cvsup14.freebsd.org at Sun Apr 14 03:53:45 PDT 2002 CVSup begin from cvsup14.freebsd.org at Mon Apr 15 03:47:02 PDT 2002 CVSup ended from cvsup14.freebsd.org at Mon Apr 15 03:53:59 PDT 2002 CVSup begin from cvsup14.freebsd.org at Mon Apr 15 12:54:16 PDT 2002 CVSup ended from cvsup14.freebsd.org at Mon Apr 15 13:00:59 PDT 2002 * The laptop is still building everything as I type; I don't see much point in repeating this message for it (once -CURRENT finishes building), so
Re: Bluetooth stack for FreeBSD
Hi...
I have been reading the (well actually, looking at
may be more acurate..
some minor comments..
ng_btsocket.c: unmodified: line 674
sbappendrecord(pcb-so-so_snd, m);
m = m_dup(m, M_TRYWAIT);
if (m == NULL) {
error = ENOBUFS;
goto drop1;
}
you are m_dup'ing an mbuf you have given away to the socket layer.
on an SMP system this may already be destroyed by the time
you do the m_dup() in fact if the sbappendrecord() fails
due to a full queue, it may already be invalid...
(I think)
also all functions should be 'prototype format'
e.g.
static int
ng_btsocket_peeraddr(so, nam)
struct socket*so;
struct sockaddr **nam;
{
should be:
static int
ng_btsocket_peeraddr(struct socket *so, struct sockaddr **nam)
{
also:
__P() is now deprecated and should not be used in new code.
Your idea of making a special bluetooth socket type, implemented by
a Netgraph node is interesting. Maybe we should it easier to do this
by extending the netgraph socket type with the ability to
make sockets of arbitrary types... i.e. register a node type that acts
as a 'subtype' of the 'socket' type, and inherrits generic
socket behaviour, but allow the 'child type' to specify
other parts to replace normal behaviour.. I guess we would need to see a
few more cases of this done before we could deduce what is
likely to be a good candidate for abstraction.
you ask:
/*
* XXX FIXME/VERIFY i assume here that hook is a pointer
* to the local hook we have received message from. For
* L2CAP messages hook is required.
*/
This is true for 5.0
in 4.x there is no such thing as an arrival hook for a message.
You should however not assume that it is non-NULL. test it in
normal running code.. not in a KASSERT. There are transitional moments
(during shutdown for example) when a message may arrive without a hook,
in fact a malicious user might force that to happen at any time by
simply send ing that message directly to the ID of the node.
For messages passed by a neighbour via a hokk the hook field will be
filled in but there are other ways that you may get a message.
[out of time for now.. will read more later]
Julian
On Mon, 15 Apr 2002, Maksim Yevmenkin wrote:
Folks,
[probably should be cc'd to -mobile as well]
An engineering release of Bluetooth stack for -current FreeBSD
is available for download at
http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020415.tar.gz
i'm interested to hear from people who familiar with FreeBSD
kernel, Netgraph and/or Bluetooth. all your questions/comments/
suggestions are accepted and greatly appreciated. this is my
first Netgraph stack, so please don't me hard :)
thanks,
max
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
Matthias Schuendehuette wrote: I still have an old FreeBSD Test-Installation (45GB are big enough :-) with a 4.4-STABLE as of Okt 23, 2001... It boots off the DTLA, uses tagged-queuing and connects using UDMA100... ... and doesn't have any problems!! So, to bring some of you down to earth again, the DTLA may be a horrible disk and I'm one of the last to praise ATA at all (My machine has two SCSI host adaptors, five SCSI-Disks and several other SCSI Devices), but it once worked! I think we all already agree, though, that the tagged command queuing problem comes from a code change. That doesn't identify it very closely (or you would have included a patch ;^)). It may be that the OS is slower in older revisions (one would hope that was the case), and that now the code is faster, it's too fast for the hardware. It may also be that the switches between write caching on/off by default in various versions have remove stall points in the write code path which would have otherwise protected the drive from being overwhelmed by the host OS. There are a lot of possibilities for timing problems having been introduced, that don't require that Soren's code be wrong, and that it's impossible to blame the problem on the hardware. On the theory that it is an off-by-one error, introduced either by increased concurrency in an error path, or a direct off-by-one, I've suggested dropping the effective number of tagged commands supported by the drive. That way, if you exceed this number for whatever coding error reason, you won't exceed the capicty of the drive. Since you have one of these beasts, could you maybe try changing the number of tagged command queue entries you permit to be used at one time? I really, really don't want to blame Søren, he's doing a great job and everybody, who makes something makes occasionally some errors, but (at least for me) it doesn't seem to be a fundamental technical problem, because *it once worked* - sorry, but it's true. And maybe it isn't related to tagged queuing and the DTLA at all - if I correctly understand Giorgos' mail... As I said: it could be drive settings unrelated to the code itself being correct. I've given three suggestions to verify this, one way or the other: 1) Control the drive DMA speed down 2) Pretend the maximum tagged command queue depth is smaller than it is 3) Toggle the write caching on the drive Until you try all three of these and report back, you can't say that the problem is Soren's. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic (swp_pager_meta_ctl+0x67) in today's -CURRENT
Date: Mon, 15 Apr 2002 15:47:32 -0700 (PDT) From: David Wolfskill [EMAIL PROTECTED] Have had a touch more turbulence than usual in -CURRENT-land today. Finally got it built; re-booted, and got the following panic while setting up an md-resident file system (for /tmp): [Panic stuff elided...] I was able to rebuild a kernel after backing src/sys/kern/kern_malloc.c from rev. 1.99 to 1.98; once I did that, constructing the md-resident /tmp works fine: freebeast(5.0-C)[1] uname -a FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #51: Mon Apr 15 16:36:21 PDT 2002 [EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST i386 freebeast(5.0-C)[2] df -k Filesystem 1K-blocksUsedAvail Capacity Mounted on /dev/ad0s4a158767 920625400463%/ devfs 1 10 100%/dev /dev/ad0s4e 1872759 718180 100475942%/usr /dev/ad0s4h 27728233 9500972 1600900337%/common /dev/ad0s4g 2032839 487178 138303426%/var procfs 4 40 100%/proc /dev/md10c 492972 4 453532 0%/tmp freebeast(5.0-C)[3] Since I'm running with INVARIANTS, I suppose that this was a demonstration of the truth of: ... The intent of this code is to gather statistics for tuning the malloc bucket sizes. It is not intended to be run with INVARIANTS and it is not entirely mp safe. It can be enabled via 'options MALLOC_PROFILE' which was commited earlier. --- Hmmm Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] Based on my experience as a computing professional, I consider the use of Microsoft products as components of computing systems to be just as advisable as using green wood to frame a house... and expect similar results. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pcm?
At 04:30 PM 4/15/2002 +0100, you wrote: --- John Angelmo [EMAIL PROTECTED] wrote: I wonder how the pcm sound support is in 5.0? Hmm, I am using the emu10k1 aka Sound Blaster 1024 Live!, which has some locking problems, but apart from that I dont think there is any other problems AFAIK. :) I didn't get it working in 4.5 but perhaps theres better support in 5.0 but I didn't find any info in NOTES What problem did you exactly have in 4.5 with the pcm support? Regards. -- Hiten Pandya Finger [EMAIL PROTECTED] for PGP public key --- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3 --- I am trying to get my SB Audigy working under -CURRENT as well. Is there going to be any support for it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mouse in Xfree86 4.2.0
On Mon, Apr 15, 2002 at 03:25:12PM -0700, David O'Brien wrote: I have requested of both the XFree86-4 Server and of Portmgr to make the default mouse device /dev/sysmouse. But my emails have gone unanswered. They did not go unanswered. I said it was a good idea and that I would do it, but due to lack of time I haven't done it yet. This does not stop you from doing. -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PAM broke?
Fresh cvsup and buildworld from today's -current seems to have broken pam logins for telnet and ssh. Fresh mergemaster too. Apr 15 19:59:14 rigel telnetd[285]: in openpam_load_module(): no pam_unix.so found Apr 15 19:59:14 rigel telnetd[285]: in openpam_load_module(): no pam_unix.so found Apr 15 19:59:14 rigel telnetd[285]: pam_start: failed to load module Apr 15 19:59:17 rigel telnetd[285]: in openpam_load_module(): no pam_unix.so found Apr 15 19:59:17 rigel telnetd[285]: in openpam_load_module(): no pam_unix.so found Apr 15 19:59:17 rigel telnetd[285]: pam_start: failed to load module Apr 15 19:59:27 rigel sshd[287]: in openpam_load_module(): no pam_unix.so found Apr 15 19:59:27 rigel sshd[287]: in openpam_load_module(): no pam_unix.so found Apr 15 19:59:27 rigel sshd[287]: fatal: PAM initialisation failed[1]: failed to load module -- # No pamd.conf bash-2.02$ cat /etc/pamd.conf cat: /etc/pamd.conf: No such file or directory -- bash-2.02$ cat /etc/pam.d/sshd # # $FreeBSD: src/etc/pam.d/sshd,v 1.4 2002/04/15 02:46:24 des Exp $ # # PAM configuration for the sshd service # # auth authrequiredpam_nologin.so no_warn authrequiredpam_unix.so no_warn try_first_pass # account account requiredpam_login_access.so account requiredpam_unix.so # session session requiredpam_lastlog.so session requiredpam_permit.so # password passwordrequiredpam_permit.so -- bash-2.02$ cat /etc/pam.d/telnetd # # $FreeBSD: src/etc/pam.d/telnetd,v 1.2 2001/12/05 21:26:00 des Exp $ # # PAM configuration for the telnetd service # # auth authrequiredpam_nologin.so no_warn authrequiredpam_unix.so no_warn try_first_pass # account account requiredpam_unix.so -- bash-2.02$ ls -l /usr/lib/pam*.so.2 -r--r--r-- 1 root wheel 3180 Apr 15 19:14 /usr/lib/pam_deny.so.2 -r--r--r-- 1 root wheel 5260 Apr 15 19:14 /usr/lib/pam_ftp.so.2 -r--r--r-- 1 root wheel 4840 Apr 15 19:14 /usr/lib/pam_lastlog.so.2 -r--r--r-- 1 root wheel 6684 Apr 15 19:14 /usr/lib/pam_login_access.so.2 -r--r--r-- 1 root wheel 4436 Apr 15 19:14 /usr/lib/pam_nologin.so.2 -r--r--r-- 1 root wheel 4700 Apr 15 19:14 /usr/lib/pam_opie.so.2 -r--r--r-- 1 root wheel 3852 Apr 15 19:14 /usr/lib/pam_opieaccess.so.2 -r--r--r-- 1 root wheel 39436 Apr 15 19:14 /usr/lib/pam_passwdqc.so.2 -r--r--r-- 1 root wheel 3164 Apr 15 19:14 /usr/lib/pam_permit.so.2 -r--r--r-- 1 root wheel 7432 Apr 15 19:14 /usr/lib/pam_radius.so.2 -r--r--r-- 1 root wheel 3552 Apr 15 19:14 /usr/lib/pam_rhosts.so.2 -r--r--r-- 1 root wheel 3408 Apr 15 19:14 /usr/lib/pam_rootok.so.2 -r--r--r-- 1 root wheel 3940 Apr 15 19:14 /usr/lib/pam_securetty.so.2 -r--r--r-- 1 root wheel 3668 Apr 15 19:14 /usr/lib/pam_self.so.2 -r--r--r-- 1 root wheel 9812 Apr 15 19:14 /usr/lib/pam_ssh.so.2 -r--r--r-- 1 root wheel 7276 Apr 15 19:14 /usr/lib/pam_tacplus.so.2 -r--r--r-- 1 root wheel 14972 Apr 15 19:14 /usr/lib/pam_unix.so.2 -r--r--r-- 1 root wheel 5052 Apr 15 19:14 /usr/lib/pam_wheel.so.2 Any clues? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth stack for FreeBSD
On Mon, 15 Apr 2002, Julian Elischer wrote: [out of time for now.. will read more later] Julian ok, read a bit more: you say: 2) Locking/SMP External code now uses ng_send_fn to inject data into Netgraph, so it should be fine as long as Netgraph is SMP safe. Just need to verify it. yes this is correct While Netgraph is not completely SMP safe yet, this is only because there are several nodes that do not do what you do here. By doing it corectly here you have ensured that this will not be one of the nodes that needs to be reworked when this becomes important. (soon). Any node that changes it's internal state with reception of DATA (as opposed to control messages) should ensure that it by doing: NG_NODE_FORCE_WRITER(node); This is because in the default state, multiple data messages may (under SMP) be transitting the node at a time, as they only take out READER locks. If DATA can change some state variable or similar then this becomes unsafe, and they should be serialised. If only SOME data can do this, you have the option to takew reader-locks and only after confirming that a message is a writer, upgrade to a writer lock by 'requeueing' it as such. Alternatively teh sender can mark a packet as 'writer'. --- NG_NODE_PRIVATE(NG_HOOK_NODE(hook)) can be saved if you store information relavant to a hook in it's own private data pointer.. In some nodes I store the same data in NG_HOOK_PRIVATE(hook) as is in NG_NODE_PRIVATE(node), just to save the dereference if it's going to be done per packet. Sometimes there are better things to store there however.. --- /* Detach mbuf, discard item and process data */ NGI_GET_M(item, m); NG_FREE_ITEM(item); If there is any chance that you will need a new 'item' in a function or a child function, then it's worth keeping them around to save teh expense of re-allocating them.. I guess I shuld make a macro NG_FWD_DATA_HOOK() to make this easier to do.. -- On Mon, 15 Apr 2002, Maksim Yevmenkin wrote: Folks, [probably should be cc'd to -mobile as well] An engineering release of Bluetooth stack for -current FreeBSD is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020415.tar.gz i'm interested to hear from people who familiar with FreeBSD kernel, Netgraph and/or Bluetooth. all your questions/comments/ suggestions are accepted and greatly appreciated. this is my first Netgraph stack, so please don't me hard :) thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM broke?
On Tue, 2002-04-16 at 10:07, Dan Eischen wrote: Fresh cvsup and buildworld from today's -current seems to have broken pam logins for telnet and ssh. Fresh mergemaster too. [snip] Any clues? Remove -DYP from the CFLAGS in /usr/lib/libpam/modules/pam_unix/Makefile and rebuild/reinstall libpam. This took me about an hour to track down. =( -- Benno Rice [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: PAM broke?
On 16 Apr 2002, Benno Rice wrote: On Tue, 2002-04-16 at 10:07, Dan Eischen wrote: Fresh cvsup and buildworld from today's -current seems to have broken pam logins for telnet and ssh. Fresh mergemaster too. [snip] Any clues? Remove -DYP from the CFLAGS in /usr/lib/libpam/modules/pam_unix/Makefile and rebuild/reinstall libpam. Thanks, that did the trick. Anyone know if this is the correct fix? It shouldn't be left broken. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM broke?
On Tue, 2002-04-16 at 13:43, Daniel Eischen wrote:
On 16 Apr 2002, Benno Rice wrote:
On Tue, 2002-04-16 at 10:07, Dan Eischen wrote:
Fresh cvsup and buildworld from today's -current seems to have
broken pam logins for telnet and ssh. Fresh mergemaster too.
[snip]
Any clues?
Remove -DYP from the CFLAGS in /usr/lib/libpam/modules/pam_unix/Makefile
and rebuild/reinstall libpam.
Thanks, that did the trick.
Anyone know if this is the correct fix? It shouldn't be left
broken.
I think des's commit that removed the _use_yp variable from
usr.sbin/vipw/pw_util.c fixed it. I managed to get an unresolved symbol
error for _use_yp out of pam with the attached patch.
--
Benno Rice
[EMAIL PROTECTED]
Index: contrib/openpam/lib/openpam_dynamic.c
===
RCS file: /home/ncvs/src/contrib/openpam/lib/openpam_dynamic.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 openpam_dynamic.c
--- contrib/openpam/lib/openpam_dynamic.c 7 Mar 2002 19:24:22 - 1.1.1.2
+++ contrib/openpam/lib/openpam_dynamic.c 16 Apr 2002 03:49:27 -
@@ -67,6 +67,7 @@
*strrchr(vpath, '.') = '\0';
if ((dlh = dlopen(vpath, RTLD_NOW)) == NULL) {
free(module);
+ openpam_log(PAM_LOG_ERROR, %s, dlerror());
return (NULL);
}
}
signature.asc
Description: This is a digitally signed message part
Machine panics when mount_smb fs is run
Trying to mount a cdrom from my XP box using
mount_smbfs //jason@desktop/cdrom /cdrom
Causes my machine to panic and die. Below is hopefully some info that
will help resolve the problem
Included as an attachment in plain text format the boot sequence showing
my hardware. The motherboard itself is
An Asus CUV4X
I will keep the core file itself for a few days under the name
smbfs.smp-kernel.core (I seem to generate a boatload
Of core files, and even on a 40 gig drive I'm running outa space fast)
if anyone needs more info.
grim# gdb -k /boot/kernel/kernel.debug
af4e67719bcbc259bfe24101757d16e8.core
GNU gdb 4.18
Copyright 1998 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-unknown-freebsd...
IdlePTD at phsyical address 0x0043a000
initial pcb at physical address 0x00343ca0
panicstr: bremfree: bp 0xc85c52d8 not locked
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id =
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc01d2b00
stack pointer = 0x10:0xcfe82bbc
frame pointer = 0x10:0xcfe82bc4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 280 (smbiod0)
trap number = 12
panic: page fault
cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... panic: bremfree: bp 0xc85c52d8 not locked
cpuid = 1; lapic.id =
boot() called on cpu#1
Uptime: 1m22s
Dumping 287 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc01b9088 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:346
#2 0xc01b9299 in panic (fmt=0xc02d9e9d bremfree: bp %p not locked) at
/usr/src/sys/kern/kern_shutdown.c:490
#3 0xc01e8fa1 in bremfree (bp=0xc85c52d8) at
/usr/src/sys/kern/vfs_bio.c:619
#4 0xc01ea697 in vfs_bio_awrite (bp=0xc85c52d8) at
/usr/src/sys/kern/vfs_bio.c:1593
#5 0xc0195198 in spec_fsync (ap=0xcfe82a70) at
/usr/src/sys/fs/specfs/spec_vnops.c:403
#6 0xc0194d85 in spec_vnoperate (ap=0xcfe82a70) at
/usr/src/sys/fs/specfs/spec_vnops.c:121
#7 0xc0253c2d in ffs_sync (mp=0xcf2c6200, waitfor=2, cred=0xc8571300,
td=0xc0309220) at vnode_if.h:441
#8 0xc01f7257 in sync (td=0xc0309220, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:1217
#9 0xc01b8cda in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:254
#10 0xc01b9299 in panic (fmt=0xc02f413e %s) at
/usr/src/sys/kern/kern_shutdown.c:490
#11 0xc02a4b83 in trap_fatal (frame=0xcfe82b7c, eva=0) at
/usr/src/sys/i386/i386/trap.c:841
#12 0xc02a48a1 in trap_pfault (frame=0xcfe82b7c, usermode=0, eva=0) at
/usr/src/sys/i386/i386/trap.c:755
#13 0xc02a442b in trap (frame={tf_fs = -806485992, tf_es = -806879216,
tf_ds = -1071972336, tf_edi = 0,
tf_esi = -806910956, tf_ebp = -806868028, tf_isp = -806868056,
tf_ebx = -806466332, tf_edx = 1,
tf_ecx = -1070532736, tf_eax = 0, tf_trapno = 12, tf_err = 2,
tf_eip = -1071830272, tf_cs = 8,
tf_eflags = 66118, tf_esp = -806466432, tf_ss = 1}) at
/usr/src/sys/i386/i386/trap.c:426
#14 0xc01d2b00 in selrecord (selector=0xcfe78414, sip=0xcfee4ce4) at
/usr/src/sys/kern/sys_generic.c:1173
#15 0xc01e347b in sopoll (so=0xcfee4c80, events=1, cred=0x0,
td=0xcfe78414) at /usr/src/sys/kern/uipc_socket.c:1562
#16 0xd01c8d55 in ?? ()
#17 0xd01c919a in ?? ()
#18 0xd01c9773 in ?? ()
#19 0xd01ccc1f in ?? ()
#20 0xd01cd9dd in ?? ()
#21 0xc01aab0c in fork_exit (callout=0xd01cd934, arg=0xcfe09b00,
frame=0xcfe82d48) at /usr/src/sys/kern/kern_fork.c:808
Copyright (c) 1992-2002 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.0-CURRENT #16: Mon Apr 15 02:25:55 EDT 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GRIM
Preloaded elf kernel /boot/kernel/kernel at 0xc041b000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc041b0a8.
Timecounter i8254 frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (870.58-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x686 Stepping = 6
Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE
real memory = 301973504 (294896K bytes)
avail memory = 288686080 (281920K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 - irq 0
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): apic id: 3,
