Re: The cbus driver for pc98
In article <[EMAIL PROTECTED]> "M. Warner Losh" <[EMAIL PROTECTED]> writes: > Cbus is to ISA as CardBus is to PCI in many ways. Cbus is very much > like ISA in all but a few details. CardBus is pci with a few twists > and turns that differ. If you look at how we've implemented cardbus, > you'll see that we've tried to do it as a 'subclass' of the pci bus. > We implement the PCI interfaces in the cardbus bus code, even though > it is not really a pci bus. I'd propose that cbus implements the ISA > interfaces in a similar manner. If my understanding is not a mistake, the CardBus specifications is derived from the PCI. Therefore, I can understand that the cardbus driver depend on the pci driver. But, the Cbus is NOT derived from the ISA. So, I think that the cbus driver should not depend on the isa driver. --- TAKAHASHI Yoshihiro <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
LOR in pcn driver (and pcn driver may be broken)
Hi I got this yesterday on my SMP system current as of yesterday: pcn0: port 0xe800-0xe81f mem 0xea001000-0xea00101f irq 16 at device 9.0 on pci0 ../../../vm/uma_core.c:1330: could sleep with "pcn0" locked from ../../../pci/if_pcn.c:524 ../../../vm/uma_core.c:1330: could sleep with "pcn0" locked from ../../../pci/if_pcn.c:524 lock order reversal 1st 0xc3860e88 pcn0 (network driver) @ ../../../pci/if_pcn.c:524 2nd 0xc0343660 allproc (allproc) @ ../../../kern/kern_fork.c:328 Stack backtrace: backtrace(c031afb6,c0343660,c0317d4f,c0317d4f,c031615f) at backtrace+0x17 witness_lock(c0343660,8,c031615f,148,0) at witness_lock+0x660 _sx_xlock(c0343660,c031615f,148,fa,0) at _sx_xlock+0xb2 fork1(c033eae0,60034,0,c043d994,c0d16f6b) at fork1+0x23d kthread_create(c01c5210,c0d16f00,c043d9c4,6,0) at kthread_create+0x48 ithread_create(c043d9f8,10,0,c02e0410,c02e03a0) at ithread_create+0xda inthand_add(c0d00dc0,10,c0263da0,c3860800,4) at inthand_add+0x9e nexus_setup_intr(c0d15880,c385f300,c38671c0,4,c0263da0) at nexus_setup_intr+0x85 bus_generic_setup_intr(c0d15800,c385f300,c38671c0,4,c0263da0) at bus_generic_setup_intr+0xa2 bus_generic_setup_intr(c0d15700,c385f300,c38671c0,4,c0263da0) at bus_generic_setup_intr+0xa2 bus_generic_setup_intr(c0d15680,c385f300,c38671c0,4,c0263da0) at bus_generic_setup_intr+0xa2 bus_setup_intr(c385f300,c38671c0,4,c0263da0,c3860800) at bus_setup_intr+0xa5 pcn_attach(c385f300,c380f098,c0335270,c0186b5e,c385f500) at pcn_attach+0x69b device_probe_and_attach(c385f300,0,c043dc0c,c0186ce6,c0d15680) at device_probe_and_attach+0xb0 bus_generic_attach(c0d15680,0,58,c043dbfc,c0d15680,0) at bus_generic_attach+0x28 pci_attach(c0d15680,c380a098,c0335270,c0328e72,0) at pci_attach+0xa6 device_probe_and_attach(c0d15680,c382f070,c043dc78,c02e398f,c0d15700) at device_probe_and_attach+0xb0 bus_generic_attach(c0d15700,c0328e72,0,c043dc68,c0d15700) at bus_generic_attach+0x28 nexus_pcib_attach(c0d15700,c3834098,c0335270,c035ce00,c0d00290) at nexus_pcib_attach+0x8f device_probe_and_attach(c0d15700,c0d15800,c043dcdc,c02ce29c,c0d15800) at device_probe_and_attach+0xb0 bus_generic_attach(c0d15800,0,c0d003a0,c0d0d280,c0d15800) at bus_generic_attach+0x28 legacy_attach(c0d15800,c382f098,c0335270,c3837170,c035cbe0) at legacy_attach+0x1c device_probe_and_attach(c0d15800,c0d15880,c043dd2c,c02d5edc,c0d15880) at device_probe_and_attach+0xb0 bus_generic_attach(c0d15880,c0d15880,c043dd5c,c01ec8b0,c0d15880) at bus_generic_attach+0x28 nexus_attach(c0d15880,c3829098,c0335270,c032a7ac,0) at nexus_attach+0x1c device_probe_and_attach(c0d15880,c033018c,c043dd80,c02c04ce,c0d15c00) at device_probe_and_attach+0xb0 root_bus_configure(c0d15c00,c032a7ac,0,c043dd98,c01b3225) at root_bus_configure+0x28 configure(0,43a000,43ac00,43a000,0) at configure+0x2e mi_startup() at mi_startup+0xb5 begin() at begin+0x2c ../../../vm/uma_core.c:1330: could sleep with "pcn0" locked from ../../../pci/if_pcn.c:524 ../../../vm/uma_core.c:1330: could sleep with "pcn0" locked from ../../../pci/if_pcn.c:524 ../../../vm/uma_core.c:1330: could sleep with "pcn0" locked from ../../../pci/if_pcn.c:524 pcn0: Ethernet address: 00:60:b0:b6:d9:ee miibus1: on pcn0 lxtphy0: on miibus1 lxtphy0: 100baseFX, 100baseFX-FDX, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ../../../vm/uma_core.c:1330: could sleep with "pcn0" locked from ../../../pci/if_pcn.c:524 Also, the card sees link and correctly autodetects the link speed, but the driver does not seem to be able to get packets onto the wire, or read packets from the wire. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic induced by background fsck.
Hi
Several seconds into background fsck, this happens. It's easily
repeatable by enabling background fsck and booting after an unclean
shutdown.
Kernel is 2003-02-19 from source checked out on that day (SMP).
The filesystems are UFS1 with softupdates.
panic: vm_fault: fault on nofault entry, addr: c7c65000
cpuid = 0; lapic.id =
Stack backtrace:
backtrace(c03185a5,0,c0325e37,d280258c,1) at backtrace+0x17
panic(c0325e37,c7c65000,2,d2802638,d2802628) at panic+0x10a
vm_fault(c082f000,c7c65000,2,0,c3908690) at vm_fault+0x1073
trap_pfault(d2802724,0,c7c65000,1db,c7c65000) at trap_pfault+0x161
trap(d2800018,d2800010,c3920010,c7c65000,0) at trap+0x3cd
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc02da907, esp = 0xd2802764, ebp = 0xd2802a3c ---
generic_bzero(c38f7000,80be140,70,1000,3e5428db) at generic_bzero+0xf
ffs_mount(c38f7000,c3a4c800,bfbffcc0,d2802bec,c3908690) at ffs_mount+0x638
vfs_mount(c3908690,c385e230,c3a4c800,1211000,bfbffcc0) at vfs_mount+0x83a
mount(c3908690,d2802d10,c032ba37,407,4) at mount+0xb8
syscall(2f,2f,2f,0,bfbffdc0) at syscall+0x28e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (21), eip = 0x805636b, esp = 0xbfbffc0c, ebp = 0xbfbffd48 ---
Debugger("panic")
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db> call boot
panic: bremfree: bp 0xc75ab978 not locked
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 2m43s
Dumping 191 MB
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: Unable to do a clean reboot
Hey There.. I would guess you're using SCHED_ULE in your Kernel config? It seems to cause shutdown problems that haven't been addressed yet.. Tony -Original Message- From: David Kleiner [mailto:[EMAIL PROTECTED]] Sent: 20 February 2003 05:45 To: [EMAIL PROTECTED] Subject: Unable to do a clean reboot Hi, Since I went to -current by way of 5.0-Rel, I was unable to do a clean shutdown or reboot. No matter how I tried it, 2-8 buffers always remain there during sync'ing. It goes like this: 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... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 giving up on 2 buffers wallaby# uname -a FreeBSD wallaby.pacbell.net 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Tue Feb 18 21:06:18 PST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/W i386 It's a PCGR505-TE Sony Vaio laptop with this disk: ad0: 38154MB [77520/16/63] at ata0-master UDMA100 Any suggestions? Thank you, David 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: 5.0R - panic: bwrite: buffer is not busy
In message <[EMAIL PROTECTED]>, Patric Mrawek writes: >I am seeing a reproducible panic with > >FreeBSD talisker 5.0-RELEASE FreeBSD 5.0-RELEASE #5: Wed Jan 29 10:49:32 CET 2003 >root@talisker:/usr/src/sys/i386/compile/TALISKER i386 > >What I've done is: >- kldload uvisor.ko >- running »/usr/sbin/usbd -d -v« >- running »jpilot-sync -d -l -p /dev/ucom0« >- hitting the sync-button from my visor several times > >After hitting the sync-button 5 to 10 times my box panics. it looks like a device disappeared while you had it open. I'll commit a workaround for this later today. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cardbus-attached USB controller
In message: <[EMAIL PROTECTED]> Bob Bishop <[EMAIL PROTECTED]> writes: : Would someone like to give me a clue how to plumb this thing in? TIA Index: ohci_pci.c === RCS file: /cache/ncvs/src/sys/dev/usb/ohci_pci.c,v retrieving revision 1.29 diff -u -r1.29 ohci_pci.c --- ohci_pci.c 29 Jan 2003 00:13:29 - 1.29 +++ ohci_pci.c 20 Feb 2003 06:09:32 - @@ -314,3 +314,4 @@ static devclass_t ohci_devclass; DRIVER_MODULE(ohci, pci, ohci_driver, ohci_devclass, 0, 0); +DRIVER_MODULE(ohci, cardbus, ohci_driver, ohci_devclass, 0, 0); Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Realtek 8139B detected
Well, um, if you look for messages from me last June and then again several times recently you'll find we are a club of three, at least. I can't actually manually ifconfig it either, it comes up the first time fine, but I can wedge my machine with a few large transfers. I got a couple of hints via email about crappy RealTek errata and I spent an hour squinting at the diffs between -stable where it works flawlessly, and -current, but could not see anything that was related. But I'm lousy at drivers. I was actually pondering whether to ditch the idea of using the on-board rl, and switch to a wifi card or something else, since it's back in -stable now, and this is an acpi only laptop. Best, Russell : +---[ Martin Minkus ]-- : | During boot, i get the following: : | : : [snip] : : | I really want to start upgrading to 5.0 (There are no other issues, and : | some people i know have been running 5.0-CURRENT ever since work on 5.0 : | began). : : I found that if I tried to specify any media or mediaopt options to ifconfig : that the RL's would refuse to find carrier (das blinkenlights on the switch). : : Lines like the following simply don't work; : : ifconfig_rl0="inet 10.10.10.10 netmask 255.255.255.0 media auto mediaopt full-duplex" : ifconfig_rl0="inet 10.10.10.10 netmask 255.255.255.0 media 100BaseTX mediaopt :full-duplex" : : whether you specify auto or specify a media. : : However, if I just leave the card alone; : : ifconfig_rl0="inet 10.10.10.10 netmask 255.255.255.0" : : It will come up by itself in 100BaseTX full-duplex on its own first time : every time. : : It's something to try at least I suppose. : : -- : Totally Holistic Enterprises Internet| | Andrew Milton : The Internet (Aust) Pty Ltd | M:+61 416 022 411 | : ACN: 082 081 472 ABN: 83 082 081 472 |[EMAIL PROTECTED]| Carpe Daemon : : 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
îÅÚÁÂÙ×ÁÅÍÙÅ ÔÕÒÙ × úÁÐÏÌÑÒØÅ
îÅÚÁÂÙ×ÁÅÍÙÅ ÔÕÒÙ × úÁÐÏÌÑÒØÅ - http://koresh.ru/terra/tour.shtml éÚ×ÉÎÑÅÍÓÑ ÚÁ ×ÏÚÍÏÖÎÙÅ ÐÒÅÄÏÓÔÁ×ÌÅÎÎÙÅ ÎÅÕÄÏÂÓÔ×Á. åÓÌÉ ÷Ù ÈÏÔÉÔÅ ÉÓËÌÀÞÉÔØ Ó×ÏÊ e-mail ÁÄÒÅÓ ÉÚ ÒÁÓÓÙÌËÉ, ÐÏÖÁÌÕÊÓÔÁ, ÕÄÁÌÉÔÅ ÅÇÏ ÚÄÅÓØ: To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Page fault on disk-less machine
On 2/19/2003 8:23 PM, Scott Long wrote: Guys, this problem has already been identified. I posted a patch last night to cvs-all@ that fixes this, although it's still not totally correct so I haven't committed it yet. Great, thanks! Though it might have been a good idea to CC current@ - I'd have seen it there. (I filter cvs-all@ for pieces of the tree I'm interested in, and your mail must have been nuked.) Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Page fault on disk-less machine
Scott Long wrote: > Guys, this problem has already been identified. I posted a > patch last night to cvs-all@ that fixes this, although it's > still not totally correct so I haven't committed it yet. This one, I imagine. Thanks! http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1225336+0+current/cvs-all It wasn't clear that this was the same problem, with the other recent potentially destabilizing commits. I guess PHK, Lars, and Craig should try applying this, and seeing if it fixes things for them... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Page fault on disk-less machine
Craig Boston wrote: > > On Wed, 2003-02-19 at 21:48, Terry Lambert wrote: > > Lars Eggert wrote: > > > Poul-Henning Kamp wrote: > > > > Fatal trap 12: page fault while in kernel mode > > > > > > FWIW, Craig Boston and me see the same panics (threads on -current: > > > "panic starting gnome" and "VFS panic (possibly NFS-locking related?)"). > > > > Have you "gdb -k" list'ed the namei code in question yet? > > > > Per my last posting on this subject, note that Poul's offset into > > namei is different than the one you gave. > > Mine is different as well: 0x12c, and on a cmpxchgl instruction (I know > that doesn't help any ;) > > But: > (kgdb) list namei+0x12c > Junk at end of line specification. > (kgdb) > > Am I doing something wrong? My bad: list *namei+0x12c Note the asterisk to dereference before the add. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic starting gnome
Craig Boston wrote: > Well, I haven't had much luck tracking down the exact cause. For some > reason I haven't been able to figure out, all of my crash dumps jump > directly from vn_open_cred (line 185 of vfs_vnops.c) to calltrap(). The > namei call doesn't show up in the stack at all, almost like the function > is being inlined. I'm only using -O, which shouldn't inline anything > not explicitly declared as such. Nope. The problem is a NULL pointer dereference, apparently into the proc structure, which is a NULL proc pointer. > Anyway, using a cvsup binary search I've managed to narrow it down > some. The problem did not exist before midnight UTC on 2003-04-15. It > does exist on midnight UTC 2003-04-16. I've been digging through the > commit logs for that day, but it seems it was a busy day for the VFS > code with lots of commits. Since it always happens after an fdfree(), > I'm leaning toward a large (number of files) commit by alfred@ having to > do with a lock order reversal and adding a mutex associated with freeing > filedesc structures. Just a guess, though. FWIW, I arrived at the same place, given Lars' debugging information, though it was only my most likely suspect. There are some changes that went in for KSE, as well, but I'm pretty sure they were after last Wednesday. > Reproducing the problem seems to be as simple as killing any process > that has an open, locked file on an NFS volume. A simple > > gconfd-1 & > sleep 5; killall -9 gconfd-1 > > does it every time for me. I assume this would also happen if a process > calls exit() without closing all of it's fds first; probably why > starting GNOME or booting diskless is enough to tickle it. Yes, this is most likely. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Realtek 8139B detected
+---[ Martin Minkus ]-- | During boot, i get the following: | [snip] | I really want to start upgrading to 5.0 (There are no other issues, and | some people i know have been running 5.0-CURRENT ever since work on 5.0 | began). I found that if I tried to specify any media or mediaopt options to ifconfig that the RL's would refuse to find carrier (das blinkenlights on the switch). Lines like the following simply don't work; ifconfig_rl0="inet 10.10.10.10 netmask 255.255.255.0 media auto mediaopt full-duplex" ifconfig_rl0="inet 10.10.10.10 netmask 255.255.255.0 media 100BaseTX mediaopt full-duplex" whether you specify auto or specify a media. However, if I just leave the card alone; ifconfig_rl0="inet 10.10.10.10 netmask 255.255.255.0" It will come up by itself in 100BaseTX full-duplex on its own first time every time. It's something to try at least I suppose. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | M:+61 416 022 411 | ACN: 082 081 472 ABN: 83 082 081 472 |[EMAIL PROTECTED]| Carpe Daemon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Page fault on disk-less machine
Guys, this problem has already been identified. I posted a patch last night to cvs-all@ that fixes this, although it's still not totally correct so I haven't committed it yet. Scott Craig Boston wrote: On Wed, 2003-02-19 at 21:48, Terry Lambert wrote: Lars Eggert wrote: Poul-Henning Kamp wrote: Fatal trap 12: page fault while in kernel mode FWIW, Craig Boston and me see the same panics (threads on -current: "panic starting gnome" and "VFS panic (possibly NFS-locking related?)"). Have you "gdb -k" list'ed the namei code in question yet? Per my last posting on this subject, note that Poul's offset into namei is different than the one you gave. Mine is different as well: 0x12c, and on a cmpxchgl instruction (I know that doesn't help any ;) But: (kgdb) list namei+0x12c Junk at end of line specification. (kgdb) Am I doing something wrong? Craig 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: Page fault on disk-less machine
On Wed, 2003-02-19 at 21:48, Terry Lambert wrote: > Lars Eggert wrote: > > Poul-Henning Kamp wrote: > > > Fatal trap 12: page fault while in kernel mode > > > > FWIW, Craig Boston and me see the same panics (threads on -current: > > "panic starting gnome" and "VFS panic (possibly NFS-locking related?)"). > > Have you "gdb -k" list'ed the namei code in question yet? > > Per my last posting on this subject, note that Poul's offset into > namei is different than the one you gave. Mine is different as well: 0x12c, and on a cmpxchgl instruction (I know that doesn't help any ;) But: (kgdb) list namei+0x12c Junk at end of line specification. (kgdb) Am I doing something wrong? Craig To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic starting gnome
Lars Eggert wrote:
> Terry Lambert wrote:
> > Debug:
> >
> [excellent kernel-debugging recipe snipped]
>
> Here's a backtrace of a crashdump that should be more helpful:
[ ... ]
> (kgdb) up 12
> #12 0xc02098a4 in namei (ndp=0x9e) at /usr/src/sys/kern/vfs_lookup.c:158
> 158 FILEDESC_LOCK(fdp);
> (kgdb) list
> 153 #endif
> 154
> 155 /*
> 156 * Get starting point for the translation.
> 157 */
> 158 FILEDESC_LOCK(fdp);
> 159 ndp->ni_rootdir = fdp->fd_rdir;
> 160 ndp->ni_topdir = fdp->fd_jdir;
> 161
> 162 dp = fdp->fd_cdir;
>
> (kgdb) print ndp
> $2 = (struct nameidata *) 0x9e
>
> (kgdb) print fdp
> $1 = (struct filedesc *) 0x34
> (kgdb)
>
> (kgdb) print p
> $3 = (struct proc *) 0x0
>
> (kgdb) print td
> $5 = (struct thread *) 0xc662d1e0
>
> (kgdb) print *td
> $7 = {td_proc = 0xc66307f0,
> [...]
>
> Very strange. namei() does essentially the following:
>
> p = td->td_proc;
> fdp = p->p_fd;
>
> td->td_proc seems reasonable, but p is 0. No idea how this could happen,
> any guesses?
Cool.
This is not where I was guessing it was at, at all. 8-) 8-).
There's a commit that Alfred made last Friday night that might
have something to do with it. It was an attempt to fix a lock
order reversal between "PROC/filedesc", according to the commit,
and it introduced "fdesc_mtx".
If you grep for that everywhere, and then annotate the involved
files, it should be pretty obvious which changes to revert to see
if this is the case (1.50->1.49 of /sys/sys/filedesc.h, etc.).
It may also be an issue with some of the recent KSE commits
over the last weekend missing an assignment on a context switch.
Probably the easiest thing to do, if you can repeat the problem
reliably, is to bsearch, starting 8 days days ago, for the commit
that broke the camel's back.
It's really tempting to make a script that's capable of carrying
out a /usr/src/sys bsearch semi-automatically, because people are
really hesistant to use this approach for solving problems, even
though it only requires O(log2(N)) reboots to find it...
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic starting gnome
On Wed, 2003-02-19 at 16:44, Lars Eggert wrote:
> #11 0xc0302ff8 in calltrap () at {standard input}:97
> #12 0xc02098a4 in namei (ndp=0x9e) at /usr/src/sys/kern/vfs_lookup.c:158
> #13 0xc021bcfc in vn_open_cred (ndp=0xeb3b1a44, flagp=0xeb3b1a0c, cmode=0,
> cred=0xc2195e80) at /usr/src/sys/kern/vfs_vnops.c:185
> #14 0xc6acffb4 in ?? ()
> #15 0xc01a06b3 in closef (fp=0x2, td=0x0) at vnode_if.h:1225
> #16 0xc01a0054 in fdfree (td=0xc662d1e0)
> at /usr/src/sys/kern/kern_descrip.c:1433
> #17 0xc01a5da2 in exit1 (td=0xc662d1e0) at /usr/src/sys/kern/kern_exit.c:254
Well, I haven't had much luck tracking down the exact cause. For some
reason I haven't been able to figure out, all of my crash dumps jump
directly from vn_open_cred (line 185 of vfs_vnops.c) to calltrap(). The
namei call doesn't show up in the stack at all, almost like the function
is being inlined. I'm only using -O, which shouldn't inline anything
not explicitly declared as such.
Anyway, using a cvsup binary search I've managed to narrow it down
some. The problem did not exist before midnight UTC on 2003-04-15. It
does exist on midnight UTC 2003-04-16. I've been digging through the
commit logs for that day, but it seems it was a busy day for the VFS
code with lots of commits. Since it always happens after an fdfree(),
I'm leaning toward a large (number of files) commit by alfred@ having to
do with a lock order reversal and adding a mutex associated with freeing
filedesc structures. Just a guess, though.
Reproducing the problem seems to be as simple as killing any process
that has an open, locked file on an NFS volume. A simple
gconfd-1 &
sleep 5; killall -9 gconfd-1
does it every time for me. I assume this would also happen if a process
calls exit() without closing all of it's fds first; probably why
starting GNOME or booting diskless is enough to tickle it.
Craig
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Page fault on disk-less machine
Lars Eggert wrote: > Poul-Henning Kamp wrote: > > Fatal trap 12: page fault while in kernel mode > > FWIW, Craig Boston and me see the same panics (threads on -current: > "panic starting gnome" and "VFS panic (possibly NFS-locking related?)"). Have you "gdb -k" list'ed the namei code in question yet? Per my last posting on this subject, note that Poul's offset into namei is different than the one you gave. If you could both provide this information, it would probably triangulate the problem immediately. Thanks, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Page fault on disk-less machine
Poul-Henning Kamp wrote: > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x34 This is the same problem that the other people were complaining about the other day. It's interesting to note the third argument to namei() is not zero in your case. > _mtx_lock_flags(34,0,c02a5f56,9e,c0d9e1e0) at 0xc018fd20 = _mtx_lock_flags+0x40 > namei(c5fd29b8,c5fd2c34,c044,c0570d00,c0d9e1e0) at 0xc01de06d = namei+0x16d Any chance of a "gdb -k" and a "list namei+0x16d"? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Unable to do a clean reboot
Hi, Since I went to -current by way of 5.0-Rel, I was unable to do a clean shutdown or reboot. No matter how I tried it, 2-8 buffers always remain there during sync'ing. It goes like this: 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... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 giving up on 2 buffers wallaby# uname -a FreeBSD wallaby.pacbell.net 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Tue Feb 18 21:06:18 PST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/W i386 It's a PCGR505-TE Sony Vaio laptop with this disk: ad0: 38154MB [77520/16/63] at ata0-master UDMA100 Any suggestions? Thank you, David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: top-of-tree alpha kernel panics during boot
On Wed, Feb 19, 2003 at 08:42:40PM +0100, Dag-Erling Smorgrav wrote: > 3) a fresh kernel without pcm boots but exhibits the same symptoms > kris reported, i.e. programs segfaulting for no apparent reason; > if / when they produce a core file, it is corrupted and useless > for debugging. I suspect a problem in the I/O system, possibly > similar to the one tegge discovered and fixed last week. My problem (seen on the alpha package cluster in the chroots used to build packages) may have been a bad userland. I used a snapshot from snapshots.jp.freebsd.org to populate the chroots and saw tons of sig11s during the package builds, but when I built a world myself and used that the problems seem to have ceased. I haven't updated the kernel on those machines. Kris msg52746/pgp0.pgp Description: PGP signature
Re: UFS/SOFTUPDATE inconsistency
[... snip ...] PP> UNEXPECTED SOFT UPDATE INCONSISTENCY PP> CANNOT FIX, FIRST ENTRY IN DIRECTORY CONTAINS files [... snip ...] PP> any on how to fix it? I got the same bug. Machine got grozen without panic (it didn't restarted itself :-( ). Of course, there was no crash dump. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UFS2 regression tests?
John De Boskey <[EMAIL PROTECTED]> writes: > Hi Folks, > >I've just put together a 1.7TB filesystem and was looking for some > regression tests to run against it. Looking through the mailing lists > doesn't turn up anything, nor does a websearch (at least for the keywords > I tried). > >So, does anyone have any comments/ideas on a good way to test the > new system? src/tools/regression/fsx Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UFS2 regression tests?
- Brad Knowles's Original Message - > Yeah, especially if it's UFS2, you're doing softupdates with > background fsck, and you've used vinum to build the large logical > volume. ;-) Actually, I didn't say how the volume was put together :-) It is currently a Raid50 consisting of 3 Raid5 sets. It is hanging off of an Adaptec 5400S controller. I realize I can probably "break" the system doing abnormal things to it, but I'm more interested (at least for now) in regression style testing. -John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: top-of-tree alpha kernel panics during boot
Dag-Erling Smorgrav writes: > #options CD9660 #kld Do you preload any/all of the things you've marked as klds? I've tried to duplicate your crash on my xp1000. I've used your kernel config file. I've reduced my memory size to 254MB. I've got roughly similar hardware (w/the exception of the chipset and cpu). The only thing I've not done is to preload any klds. I don't doubt there's a problem, but I'm having a hell of a time finding it :-( Drew 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.0-CURRENT #2: Wed Feb 19 20:34:33 EST 2003 gallatin@monet:/usr/tmp/sys/alpha/compile/DES Preloaded elf kernel "/kernel.test" at 0xfc762000. ST6600 COMPAQ Professional Workstation XP1000, 500MHz 8192 byte page size, 1 processor. CPU: EV6 (21264) major=8 minor=3 extensions=0x303 OSF PAL rev: 0x1001600020153 real memory = 266338304 (254 MB) avail memory = 251936768 (240 MB) tsunami0: <21271 Core Logic chipset> pcib0: <21271 PCI host bus adapter> on tsunami0 pci0: on pcib0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1-0x1000f,0x3f4-0x3f7,0x1f0-0x1f7 irq 238 at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: interrupting at ISA irq 14 ata1: at 0x170 irq 15 on atapci0 ata1: interrupting at ISA irq 15 atapci1: port 0x374-0x377,0x170-0x177 mem 0x108-0x108 irq 239 at device 7.2 on pci0 atapci1: Busmastering DMA not configured ohci0: mem 0x109-0x1090fff irq 234 at device 7.3 on pci0 ohci0: interrupting at ISA irq 10 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1080) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 13.0 (no driver attached) pcib1: <21271 PCI host bus adapter> on tsunami0 pci1: on pcib1 dc0: port 0x1-0x1007f mem 0x1051000-0x10513ff irq 45 at device 3.0 on pci1 dc0: Ethernet address: 00:00:f8:71:ae:00 miibus0: on dc0 dcphy0: on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: interrupting at TSUNAMI irq 45 isp0: port 0x1000-0x10ff mem 0x105-0x1050fff irq 47 at device 6.0 on pci1 isp0: interrupting at TSUNAMI irq 47 pcib2: at device 8.0 on pci1 pci2: on pcib2 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 atkbd0: interrupting at ISA irq 1 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: interrupting at ISA irq 6 mcclock0: at port 0x70-0x71 on isa0 ppc0: at port 0x3bc-0x3c3 irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 ppc0: interrupting at ISA irq 7 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A, console sio0: interrupting at ISA irq 4 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio1: interrupting at ISA irq 3 sbc0: at port 0x220-0x22f irq 5 drq 1 on isa0 sbc0: interrupting at ISA irq 5 pcm0: on sbc0 Timecounter "i8254" frequency 1193182 Hz Timecounter "alpha" frequency 53025 Hz Timecounters tick every 0.976 msec ad0: 9787MB [19885/16/63] at ata0-slave WDMA2 acd0: CDROM at ata0-master PIO4 Waiting 2 seconds for SCSI devices to settle da0 at isp0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da1 at isp0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) da2 at isp0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 8678MB (17773524 512 byte sectors: 255H 63S/T 1106C) Mounting root from ufs:/dev/da1a To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UFS2 regression tests?
At 7:58 PM -0500 2003/02/19, Wesley Morgan wrote: How about getting some tarballs full of tons of files, extracting them, deleting and randomly powering down forcing an fsck... :p Better yet, get that sample 1.7KB zip file that extracts out to hundreds of GB, and really thrash the system by doing parallel extracts of multiple copies of it, and make sure that you've got enough going at the same time that the result would be far larger than your available disk space. That should be fun! Not sure how much "regression" this provides but you're fairly likely to break something! Yeah, especially if it's UFS2, you're doing softupdates with background fsck, and you've used vinum to build the large logical volume. ;-) -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UFS2 regression tests?
On Wed, 19 Feb 2003, John De Boskey wrote: > Hi Folks, > >I've just put together a 1.7TB filesystem and was looking for some > regression tests to run against it. Looking through the mailing lists > doesn't turn up anything, nor does a websearch (at least for the keywords > I tried). > >So, does anyone have any comments/ideas on a good way to test the > new system? How about getting some tarballs full of tons of files, extracting them, deleting and randomly powering down forcing an fsck... :p Not sure how much "regression" this provides but you're fairly likely to break something! -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI thermal panics ThinkPad 600X
> Date: Mon, 17 Feb 2003 23:22:28 +0100 (MET) > From: [EMAIL PROTECTED] (Joerg Wunsch) > Sender: [EMAIL PROTECTED] > > "Matthew N. Dodd" <[EMAIL PROTECTED]> wrote: > > > My only outstanding issue is that I can't suspend if an application > > is holding /dev/dsp or /dev/audio open. > > Can you suspend from within graphics mode? I can't seem to do that, > neither with APM nor with ACPI. In some case, i've seen four > horizontal lines upon wakeup, in other cases, the graphics display > gets restored correctly, but the machine still locks up (probably in > APM BIOS, not even the lock key LEDs react, but Fn works). > > Suspending from within text mode always works. The graphics mode > problem is particularly annoying if the system enters auto-suspend > on a low battery condition... Have you tried using APMD to put the display into text mode when suspending? This si not my favorite way to do things, but it should work a lot better than nothing. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UFS2 regression tests?
At 7:17 PM -0500 2003/02/19, John De Boskey wrote: So, does anyone have any comments/ideas on a good way to test the new system? You could always set it up as a full-feed USENET news server. Should be able to fill that sucker up in two or three days. ;-) Perhaps a freenet or other p2p filesharing server? You could also set it up as a freely available anonymous ftp read/write server. Or maybe a mirror of the various popular anonymous ftp sites out there? At least that'd give you a lot of data to write Perhaps you want to give Bonnie++, IOZone, IOBench, etc... a really big test set? Perhaps even set them up to run in continuous mode, so as to really thrash your disks as much as possible as quickly as possible? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Realtek 8139B detected
During boot, i get the following: rl0: port 0x6100-0x61ff mem 0xe1001000-0xe10010ff ir q 10 at device 14.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:00:21:f2:a5:47 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: port 0x6200-0x62ff mem 0xe100-0xe1ff ir q 12 at device 15.0 on pci0 rl1: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl1: Ethernet address: 00:00:21:f4:d8:7d miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ed0: port 0x6300-0x631f irq 5 at device 16. 0 on pci0 ed0: address 00:40:05:3b:eb:c9, type NE2000 (16 bit) And i basically find that my realtek network cards are useless. I can manually set them using ifconfig to use 100baseTX, etc, but they are NOT very happy in 100mbit mode, nor will they work in full duplex. (This evidence is supported by me looking at the LEDs that are illuminated on the switch). In FreeBSD 4.0 to 4.7-STABLE this has never been a problem. Why is the driver broken in 5.0? We are going backwards now? ;) I simply cannot make any realtek cards work. My only other cards are crappy old NE2000 compatibles (ISA's!) that are laying around, and haven't been used in a few years. And yeah, they are only 10mbit :/ What is going on? I really want to start upgrading to 5.0 (There are no other issues, and some people i know have been running 5.0-CURRENT ever since work on 5.0 began). Martin. Martin Minkus Geac Enterprise Solutions 208 Greenhill Road, Eastwood 5063, South Australia Tel: +61 8 8372 6111 / Fax: +61 8 8372 6196 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
UFS2 regression tests?
Hi Folks, I've just put together a 1.7TB filesystem and was looking for some regression tests to run against it. Looking through the mailing lists doesn't turn up anything, nor does a websearch (at least for the keywords I tried). So, does anyone have any comments/ideas on a good way to test the new system? Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
modern (usb) webcam support?
My searches for information on webcam have not found much, except for some sites which say FreeBSD does not support USB web cameras. Is anyone currently working on support for this? Does anyone have any ideas about where one could go to get information about where to start if one was to start writing a driver? (I am about to buy a webcam for use in windows, it would be nice if I could choose a webcam which someone is either writing a driver for or knows where i coudl get information on them so that I could try and write one). Any info appreciated! - jacob ___ Jacob RhodenPhone: +61 3 9844 6102 ITS DivisionEmail: [EMAIL PROTECTED] Melbourne University Mobile: +61 403 788 386 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: background fsck deadlocks with ufs2 and big disk
Brad Knowles <[EMAIL PROTECTED]> wrote: > You know, vinum & softupdates have had bad interactions with each > other for as long as I can remember. Has this truly been a > consistent thing (as I seem to recall), or has this been an > on-again/off-again situation? Ah, yaaah. Hmm This is the first I've heard of that, but I can see how that could be. Could vinum be considered to be a form of (unintentional) write-caching? That might explain how the filesystem got terribly hosed, but it doesn't help with the panic. Foo. [ This is on a system that's been running in the current state for around a month. So far, it's panic'd once (a week or so ago), and so I don't have any feel for long-term stability. We'll see how it goes. ] -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic starting gnome
Terry Lambert wrote:
Debug:
>
[excellent kernel-debugging recipe snipped]
Here's a backtrace of a crashdump that should be more helpful:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x34
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01b28c6
stack pointer = 0x10:0xeb3b17c0
frame pointer = 0x10:0xeb3b17e0
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 = 2104 (gconf-sanity-check-)
panic: from debugger
cpuid = 0; lapic.id =
Fatal trap 3: breakpoint instruction fault while in kernel mode
cpuid = 0; lapic.id =
instruction pointer = 0x8:0xc03019ea
stack pointer = 0x10:0xeb3b1534
frame pointer = 0x10:0xeb3b1540
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 2104 (gconf-sanity-check-)
panic: from debugger
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 4m49s
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592
608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880
896 912 928 944 960 976 992 1008
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumpsys(&dumper);
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc01bc00e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01bc627 in panic (fmt=0xc0349b8d "from debugger")
at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc0148192 in db_panic () at /usr/src/sys/ddb/db_command.c:448
#4 0xc0147fcc in db_command (last_cmdp=0xc037f9a0, cmd_table=0x0,
aux_cmd_tablep=0xc0376fb8, aux_cmd_tablep_end=0xc0376fbc)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc014820a in db_command_loop () at /usr/src/sys/ddb/db_command.c:470
#6 0xc014af96 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc0301697 in kdb_trap (type=12, code=0, regs=0xeb3b1780)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc031a590 in trap_fatal (frame=0xeb3b1780, eva=0)
at /usr/src/sys/i386/i386/trap.c:839
#9 0xc031a2da in trap_pfault (frame=0xeb3b1780, usermode=0, eva=52)
at /usr/src/sys/i386/i386/trap.c:758
#10 0xc0319e95 in trap (frame=
{tf_fs = -1038483432, tf_es = 16, tf_ds = -1070202864, tf_edi =
158, tf_esi = 52, tf_ebp = -348448800, tf_isp = -348448852, tf_ebx = 0,
tf_edx = -966573056, tf_ecx = -966602272, tf_eax = -966602272, tf_trapno
= 12, tf_err = 0, tf_eip
= -1071961914, tf_cs = 8, tf_eflags = 66178, tf_esp = 0, tf_ss =
-1070141731})
at /usr/src/sys/i386/i386/trap.c:445
#11 0xc0302ff8 in calltrap () at {standard input}:97
#12 0xc02098a4 in namei (ndp=0x9e) at /usr/src/sys/kern/vfs_lookup.c:158
#13 0xc021bcfc in vn_open_cred (ndp=0xeb3b1a44, flagp=0xeb3b1a0c, cmode=0,
cred=0xc2195e80) at /usr/src/sys/kern/vfs_vnops.c:185
#14 0xc6acffb4 in ?? ()
#15 0xc01a06b3 in closef (fp=0x2, td=0x0) at vnode_if.h:1225
#16 0xc01a0054 in fdfree (td=0xc662d1e0)
at /usr/src/sys/kern/kern_descrip.c:1433
#17 0xc01a5da2 in exit1 (td=0xc662d1e0) at /usr/src/sys/kern/kern_exit.c:254
#18 0xc01a5b11 in sys_exit () at /usr/src/sys/kern/kern_exit.c:116
#19 0xc031ab56 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 11095,
tf_ebp =
-1077937128, tf_isp = -348447372, tf_ebx = 679838148, tf_edx =
679837268, tf_ecx = 19, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip =
680166719, tf_cs = 31, tf_eflags = 582, tf_esp = -1077937172, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#20 0xc030304d in Xint0x80_syscall () at {standard input}:139
---Can't read userspace from dump, or kernel process---
(kgdb) up 12
#12 0xc02098a4 in namei (ndp=0x9e) at /usr/src/sys/kern/vfs_lookup.c:158
158 FILEDESC_LOCK(fdp);
(kgdb) list
153 #endif
154
155 /*
156 * Get starting point for the translation.
157 */
158 FILEDESC_LOCK(fdp);
159 ndp->ni_rootdir = fdp->fd_rdir;
160 ndp->ni_topdir = fdp->fd_jdir;
161
162 dp = fdp->fd_cdir;
(kgdb) print ndp
$2 = (struct nameidata *) 0x9e
(kgdb) print fdp
$1 = (struct filedesc *) 0x34
(kgdb)
(kgdb) print p
$3 = (struct proc *) 0x0
(kgdb) print td
$5 = (struct thread *) 0xc662d1e0
(kgdb) print *td
$7 = {td_proc = 0xc66307f0,
[...]
Very strange. namei() does essentially the following:
p = td->td_proc;
fdp = p->p_fd;
td->td_proc seems reasonable, but p is 0. No idea how this could happen,
any guesses?
Thanks,
Lars
--
Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signat
5.0R - panic: bwrite: buffer is not busy
I am seeing a reproducible panic with
FreeBSD talisker 5.0-RELEASE FreeBSD 5.0-RELEASE #5: Wed Jan 29 10:49:32 CET 2003
root@talisker:/usr/src/sys/i386/compile/TALISKER i386
What I've done is:
- kldload uvisor.ko
- running »/usr/sbin/usbd -d -v«
- running »jpilot-sync -d -l -p /dev/ucom0«
- hitting the sync-button from my visor several times
After hitting the sync-button 5 to 10 times my box panics.
I've some coredumps handy, so I can dig (with some help) deeper into
this.
Script started on Wed Feb 19 22:16:30 2003
patric@talisker:/home/patric$ gdb -k /sys/i386/compile/TALISKER/kernel.debug
/var/crash/vmcore.1
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: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x32
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc020c793
stack pointer = 0x10:0xd8db7ad8
frame pointer = 0x10:0xd8db7b0c
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 = 68897 (jpilot-sync)
trap number = 12
panic: page fault
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
Uptime: 11h14m26s
Dumping 511 MB
ata0: resetting devices ..
done
[CTRL-C to abort] 16[CTRL-C to abort] 32 48 64 80 96 112 128 144 160 176 192 208 224
240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496
---
#0 doadump () at ../../../kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc024abd9 in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc024ae23 in panic () at ../../../kern/kern_shutdown.c:517
#3 0xc0290bd2 in bwrite (bp=0xce6aa2f0) at ../../../kern/vfs_bio.c:796
#4 0xc02922b5 in vfs_bio_awrite (bp=0xce6aa2f0) at ../../../kern/vfs_bio.c:1643
#5 0xc03183ba in ffs_fsync (ap=0xd8db78e0) at ../../../ufs/ffs/ffs_vnops.c:258
#6 0xc0317517 in ffs_sync (mp=0xc4206200, waitfor=2, cred=0xc1541e80, td=0xc03f6ee0)
at vnode_if.h:612
#7 0xc02a5e2b in sync (td=0xc03f6ee0, uap=0x0) at ../../../kern/vfs_syscalls.c:138
#8 0xc024a7bc in boot (howto=256) at ../../../kern/kern_shutdown.c:273
#9 0xc024ae23 in panic () at ../../../kern/kern_shutdown.c:517
#10 0xc03717a2 in trap_fatal (frame=0xd8db7a98, eva=0) at ../../../i386/i386/trap.c:844
#11 0xc0371482 in trap_pfault (frame=0xd8db7a98, usermode=0, eva=50) at
../../../i386/i386/trap.c:758
#12 0xc0370f70 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -656704716, tf_esi = -2144570347,
tf_ebp = -656704756, tf_isp = -656704828, tf_ebx = -994069960, tf_edx = -656704716,
tf_ecx = 21, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071593581, tf_cs = 8,
tf_eflags = 66050, tf_esp = -997247744, tf_ss = -2144570347}) at
../../../i386/i386/trap.c:445
#13 0xc0361778 in calltrap () at {standard input}:98
#14 0xc020c058 in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:126
#15 0xc02ae671 in vn_ioctl (fp=0xc4244bf4, com=2150396949, data=0xd8db7c48,
active_cred=0xd8db7b34, td=0xc4264b60)
at vnode_if.h:488
#16 0xc026f8b3 in ioctl (td=0xc4264b60, uap=0xd8db7d10) at file.h:227
#17 0xc0371aca in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 24, tf_esi = 134691616, tf_ebp =
-1077944152, tf_isp = -656704140, tf_ebx = 1213062036, tf_edx = 24, tf_ecx = 24,
tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 1212593395, tf_cs = 31, tf_eflags =
582, tf_esp = -1077944244, tf_ss = 47}) at ../../../i386/i386/trap.c:1033
#18 0xc03617cd in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
(kgdb) l *0xc020c793
0xc020c793 is in spec_ioctl (../../../fs/specfs/spec_vnops.c:346).
341 int error;
342 struct cdevsw *dsw;
343
344 dev = ap->a_vp->v_rdev;
345 dsw = devsw(dev);
346 if (dsw->d_flags & D_NOGIANT) {
347 DROP_GIANT();
348 error = dsw->d_ioctl(dev, ap->a_command,
349 ap->a_data, ap->a_fflag, ap->a_td);
350 PICKUP_GIANT();
(kgdb)
$FreeBSD: src/sys/fs/specfs/spec_vnops.c,v 1.186 2002/11/04 07:29:20 mckusick Exp $
Patric
--
The problem with troubleshooting is that trouble shoots back.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/alpha/alpha busdma_machdep.c src/sys/alpha/osf1 imgact_osf1.c osf1_misc.c src/sys/cam cam_periph.c cam_sim.c cam_xpt.c src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_low.c scsi_sa.c scsi_target.c src/sys/coda cnode.h ...
On 2003-02-19 09:14, [EMAIL PROTECTED] wrote:
> The attached patch will print a backtrace if any calls to malloc
> fail to have either M_WAITOK or M_NOWAIT. [...]
> --- kern/kern_malloc.c19 Feb 2003 05:47:25 - 1.116
> +++ kern/kern_malloc.c19 Feb 2003 07:55:19 -
> @@ -167,11 +167,21 @@
> #endif
> register struct malloc_type *ksp = type;
>
> + indx = flags & (M_WAITOK | M_NOWAIT);
> + if (indx == M_NOWAIT) {
> + /* OK */
> + } else if (indx == M_WAITOK) {
> + /* OK */
> + } else {
Or, a simpler version:
/* Either M_NOWAIT or M_WAITOK must be set. */
if (indx != M_NOWAIT && indx != M_WAITOK) {
printf("Missing M_WAITOK flag\n");
backtrace();
flags |= M_WAITOK;
}
:=)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Page fault on disk-less machine
On Wed, 2003-02-19 at 15:12, Lars Eggert wrote: > Poul-Henning Kamp wrote: > > Fatal trap 12: page fault while in kernel mode > > FWIW, Craig Boston and me see the same panics (threads on -current: > "panic starting gnome" and "VFS panic (possibly NFS-locking related?)"). When I get home tonight I'll try staticly compiling in the NFS client code and see if I can get a better crash dump to work with. I'm not too familiar with this part of the source tree, so no guarantees about my debugging skills ;) Craig To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Page fault on disk-less machine
Poul-Henning Kamp wrote: Fatal trap 12: page fault while in kernel mode FWIW, Craig Boston and me see the same panics (threads on -current: "panic starting gnome" and "VFS panic (possibly NFS-locking related?)"). fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x8:0xc018fd20 stack pointer = 0x10:0xc5fd27a4 frame pointer = 0x10:0xc5fd27c0 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 = 414 (cron) kernel: type 12 trap, code=0 Stopped at 0xc018fd20 = _mtx_lock_flags+0x40: cmpl$0xc02c1160,0(%ecx) db> trace _mtx_lock_flags(34,0,c02a5f56,9e,c0d9e1e0) at 0xc018fd20 = _mtx_lock_flags+0x40 namei(c5fd29b8,c5fd2c34,c044,c0570d00,c0d9e1e0) at 0xc01de06d = namei+0x16d vn_open_cred(c5fd29b8,c5fd2980,0,c0554e00,c02167cf) at 0xc01efce8 = vn_open_cred+0x258 nfs_dolock(c5fd2b98,758,c0e066a8,c0db3e10,c0e066a8) at 0xc02230f5 = nfs_dolock+0x2c5 nfs_advlock(c5fd2b98,0,c029ee60,761,c02b6800) at 0xc0222578 = nfs_advlock+0x58 fdrop_locked(c0db3e10,c0d9e1e0,c029ee60,69e,6002) at 0xc017fa28 = fdrop_locked+0x138 fdrop(c0db3e10,c0d9e1e0,c018fe06,c03b3e58,6002) at 0xc017f50e = fdrop+0x3e closef(c0db3e10,c0d9e1e0,c029ee60,595,0) at 0xc017f4bc = closef+0x12c fdfree(c0d9e1e0,0,c029f2f4,f2,1) at 0xc017ed46 = fdfree+0x116 exit1(c0d9e1e0,100,c029f2f4,73,c5fd2d40) at 0xc0184bc7 = exit1+0x3b7 sys_exit(c0d9e1e0,c5fd2d10,c02b0451,407,1) at 0xc0184801 = sys_exit+0x41 syscall(2f,2f,2f,0,) at 0xc027dc07 = syscall+0x257 Xint0x80_syscall() at 0xc026dabd = Xint0x80_syscall+0x1d --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280c36bf, esp = 0xbfbffbec, ebp = 0xbfbffc08 --- db> Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: background fsck deadlocks with ufs2 and big disk
At 9:15 AM -0800 2003/02/19, Darryl Okahata wrote: * The UFS1 filesystem in question (and I assume that it was UFS1, as I did not specify a filesystem type to newfs) is located on a RAID5 vinum volume, consisting of five 80GB disks. * Softupdates is enabled. You know, vinum & softupdates have had bad interactions with each other for as long as I can remember. Has this truly been a consistent thing (as I seem to recall), or has this been an on-again/off-again situation? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S
:OK, I'll change this to "tag=." and recvsup, try again. A big "doh!" : :Many thanks. Yup, the 5.0 release tag was messing up your cvsup. Keep at it! Once you get the diskless stuff working with the more recent sources it will become a whole lot easier to maintain it. For one thing, you won't have to maintain a complete copy of /etc any more :-), just overrides for particular files. I'm not sure what is going on with your NFS issues, but hopefully you will be able to solve it with a fully updated system. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S
Matthew Dillon <[EMAIL PROTECTED]> writes: > Are you sure you have done a recent buildworld/installworld? It > sounds like you haven't. In -current kenv is in /bin (i.e. > the source is in /usr/src/bin/kenv on -current) as of the 15th of > this month. Well, I'll be danged. I installed 5.0R on Saturday via FTP from ftp*.freebsd.org, did a "cvsup ... /usr/share/examples/cvsup/standard-supfile" then make world. But I see it in /usr/src/bin/kenv now, cvsupped last night. Rebuilding now. Then need to redo clone_root to populate my diskless root hierarchy. Thanks for the kick in the butt. > You must be working off an out of date source tree. Weird, perhaps I fat fingered and cvsupped "stable" and built that -- installing onto a Current system. That would explain a lot of this ugliness. > I have included -current's current /usr/src/etc/rc.d/initdiskless script Thank you. > If your sources are out of date you should update them... As > you can see, the initidiskless script is full of references to > md_size :-) > > # Copyright (c) 1999 Matt Dillion Ah hah... :-) > # $FreeBSD: src/etc/rc.d/initdiskless,v 1.23 2003/02/15 16:29:20 jhay Exp $ OK, this is weird; I cvsup daily but am two versions behind you: Pectopah# cvsup -l 1 -g -h cvsup2.freebsd.org /usr/share/examples/cvsup/standard-supfile Connected to cvsup2.freebsd.org Updating collection src-all/cvs Finished successfully Pectopah# grep '$FreeBSD' /usr/src/etc/rc.d/initdiskless # $FreeBSD: src/etc/rc.d/initdiskless,v 1.21 2002/10/12 10:31:31 schweikh Exp $ Being out of sync would explain a lot. Looks like the tag in "standard-supfile" points to the wrong thing, rather than the source for CURRENT: # $FreeBSD: src/share/examples/cvsup/standard-supfile,v 1.21.2.1 2003/01/16 05:59:14 scottl Exp $ # # This file contains all of the "CVSup collections" that make up the # FreeBSD-current source tree. ... *default release=cvs tag=RELENG_5_0 OK, I'll change this to "tag=." and recvsup, try again. A big "doh!" Many thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Page fault on disk-less machine
Fatal trap 12: page fault while in kernel mode fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x8:0xc018fd20 stack pointer = 0x10:0xc5fd27a4 frame pointer = 0x10:0xc5fd27c0 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 = 414 (cron) kernel: type 12 trap, code=0 Stopped at 0xc018fd20 = _mtx_lock_flags+0x40: cmpl$0xc02c1160,0(%ecx) db> trace _mtx_lock_flags(34,0,c02a5f56,9e,c0d9e1e0) at 0xc018fd20 = _mtx_lock_flags+0x40 namei(c5fd29b8,c5fd2c34,c044,c0570d00,c0d9e1e0) at 0xc01de06d = namei+0x16d vn_open_cred(c5fd29b8,c5fd2980,0,c0554e00,c02167cf) at 0xc01efce8 = vn_open_cred+0x258 nfs_dolock(c5fd2b98,758,c0e066a8,c0db3e10,c0e066a8) at 0xc02230f5 = nfs_dolock+0x2c5 nfs_advlock(c5fd2b98,0,c029ee60,761,c02b6800) at 0xc0222578 = nfs_advlock+0x58 fdrop_locked(c0db3e10,c0d9e1e0,c029ee60,69e,6002) at 0xc017fa28 = fdrop_locked+0x138 fdrop(c0db3e10,c0d9e1e0,c018fe06,c03b3e58,6002) at 0xc017f50e = fdrop+0x3e closef(c0db3e10,c0d9e1e0,c029ee60,595,0) at 0xc017f4bc = closef+0x12c fdfree(c0d9e1e0,0,c029f2f4,f2,1) at 0xc017ed46 = fdfree+0x116 exit1(c0d9e1e0,100,c029f2f4,73,c5fd2d40) at 0xc0184bc7 = exit1+0x3b7 sys_exit(c0d9e1e0,c5fd2d10,c02b0451,407,1) at 0xc0184801 = sys_exit+0x41 syscall(2f,2f,2f,0,) at 0xc027dc07 = syscall+0x257 Xint0x80_syscall() at 0xc026dabd = Xint0x80_syscall+0x1d --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280c36bf, esp = 0xbfbffbec, ebp = 0xbfbffc08 --- db> -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: top-of-tree alpha kernel panics during boot
Andrew Gallatin <[EMAIL PROTECTED]> writes: > Can you post your kernel config please, along with with, if any, > CPUTYPE you have set in make.conf and a description of your machine > (mem size in particular)? Digital Personal WorkStation 600au, 598MHz 8192 byte page size, 1 processor. CPU: EV56 (21164A) major=7 minor=0 extensions=0x1 OSF PAL rev: 0x100020116 real memory = 266493952 (254 MB) avail memory = 251985920 (240 MB) des@dsa ~% grep CPU /etc/make.conf CPUTYPE ?= ev56 Full dmesg (from a working kernel built from Jan 9th sources) and kernel config attached. Note that: 1) the problem disappears if I remove the pcm driver from the kernel (yet I don't think it's directly at fault since the panic happens when the ess driver is about to be initialized) 2) the problem also disappears if I enable KTR (see commented-out entries in config file) 3) a fresh kernel without pcm boots but exhibits the same symptoms kris reported, i.e. programs segfaulting for no apparent reason; if / when they produce a core file, it is corrupted and useless for debugging. I suspect a problem in the I/O system, possibly similar to the one tegge discovered and fixed last week. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] 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.0-CURRENT #30: Thu Jan 9 13:58:33 CET 2003 [EMAIL PROTECTED]:/usr/src/sys/alpha/compile/DSA Preloaded elf kernel "/boot/kernel.ok/kernel" at 0xfc77. Digital Personal Workstation (Miata) Digital Personal WorkStation 600au, 598MHz 8192 byte page size, 1 processor. CPU: EV56 (21164A) major=7 minor=0 extensions=0x1 OSF PAL rev: 0x100020116 real memory = 266493952 (254 MB) avail memory = 251985920 (240 MB) Initializing GEOMetry subsystem cia0: <2117x Core Logic chipset> cia0: Pyxis, pass 1 cia0: extended capabilities: 1 pcib0: <2117x PCI host bus adapter> on cia0 pci0: on pcib0 dc0: port 0x9000-0x907f mem 0x80151000-0x8015107f irq 0 at device 3.0 on pci0 dc0: interrupting at CIA irq 0 dc0: Ethernet address: 08:00:2b:86:88:55 miibus0: on dc0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x90a0-0x90af,0x3f4-0x3f7,0x1f0-0x1f7 irq 238 at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: interrupting at ISA irq 14 ata1: at 0x170 irq 15 on atapci0 ata1: interrupting at ISA irq 15 atapci1: port 0x374-0x377,0x170-0x177 mem 0x8014-0x8014 irq 239 at device 7.2 on pci0 atapci1: Busmastering DMA not configured ohci0: mem 0x8015-0x80150fff irq 234 at device 7.3 on pci0 ohci0: interrupting at ISA irq 10 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1080) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pcib1: at device 20.0 on pci0 pci1: on pcib1 isp0: port 0x8000-0x80ff mem 0x8001-0x80010fff irq 3 at device 4.0 on pci1 isp0: interrupting at CIA irq 3 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 atkbd0: interrupting at ISA irq 1 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: interrupting at ISA irq 6 mcclock0: at port 0x70-0x71 on isa0 ppc0: at port 0x3bc-0x3c3 irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 ppc0: interrupting at ISA irq 7 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A, console sio0: interrupting at ISA irq 4 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio1: interrupting at ISA irq 3 sbc0: at port 0x220-0x22f irq 5 drq 1 on isa0 sbc0: interrupting at ISA irq 5 pcm0: on sbc0 Timecounter "i8254" frequency 1193182 Hz Timecounter "alpha" frequency 599860139 Hz Timecounters tick every 0.976 msec Waiting 2 seconds for SCSI devices to settle cd0 at isp0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.237MB/s transfers (4.237MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present da1 at isp0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C) da0 at isp0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Mounting root from ufs:/dev/da0a # Kernel configuration for dsa.thinksec.com machine alpha cpu EV5 options DEC_ST550 ident DSA maxusers0 makeoptions DEBUG=-g options DDB #optionsDEBUG_VFS_LOCKS options INVARIANT_SUPPORT, INVARIANTS #optionsWITNESS, WITNESS_SKIPSPIN #option
Re: strange dump/restore behaviour
To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: strange dump/restore behaviour From: Dag-Erling Smorgrav <[EMAIL PROTECTED]> Date: Thu, 09 Jan 2003 16:41:10 +0100 This happened while copying data over to a new disk (mounted on /mnt and /mnt/usr; the original disk has only one partition). The machine was in single-user mode, but / was mounted read-write due to restore's insistance on placing temporary files in /tmp (I found out later that it respects TMPDIR, though the man page doesn't mention it). root@dsa /mnt# dump -0Laf- / | restore -rf- DUMP: Date of this level 0 dump: Thu Jan 9 16:11:42 2003 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/da0a (/) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 1838856 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] warning: ./usr: File exists expected next file 4, got 3 [...] I can imagine that the file that caused the warning message was one of restore's temporary files, but a) I've never seen this before, and b) isn't -L supposed to prevent just that? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] Sorry for the slow response. I tend to get behind on my freebsd.org email. The warning comes about because you had already created /mnt/usr. Since you were doing a full restore, you are getting a warning that the usr directory already exists when restore tries to create it. It complains again about finding an already existing inode (3 which was presumably the usr directory in the original dump). Neither of these are problematic or affected your restore. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S
Matthew Dillon <[EMAIL PROTECTED]> writes:
> Make sure your NFS server is exporting to your subnet and that
> it is running the necessary services, (portmap, mountd, nfsd -t
> -u -n 4).
My boot server is 5.0, so that's the kernel my diskless box gets. My
other boxes are 4.x boxes but I'll try.
4.x's portmap is now 5.x's rpcbind; other processes seem fine too:
41 ?? IL 0:00.00 (nfsiod 0)
42 ?? IL 0:00.00 (nfsiod 1)
43 ?? IL 0:00.00 (nfsiod 2)
44 ?? IL 0:00.00 (nfsiod 3)
276 ?? Ss 0:00.08 /usr/sbin/rpcbind
339 ?? Is 0:00.08 /usr/sbin/mountd -r
345 ?? Is 0:00.02 nfsd: master (nfsd)
347 ?? I 2:03.22 nfsd: server (nfsd)
348 ?? I 0:12.20 nfsd: server (nfsd)
349 ?? I 0:06.56 nfsd: server (nfsd)
350 ?? I 0:02.03 nfsd: server (nfsd)
> If you have another box that you can boot normally (not netboot),
> test the NFS server from that box by mounting / and /usr:
>
> other# mount 192.168.255.185:/usr /mnt
I believe I tried mounting a 4.x volume onto the diskless 5.0 box and
it failed in the same way. I didn't take careful notes so I'll
repeat.
I can mount the 5.0 boot server's /usr onto a 4.7S client with no
problem:
thanatos(4.7S)# mount 192.168.255.185:/usr /mnt
thanatos(4.7S)# mount
/dev/da0s1a on / (ufs, local)
/dev/da0s1e on /tmp (ufs, local)
/dev/da0s1g on /usr (ufs, NFS exported, local)
/dev/da0s1d on /usr/local (ufs, NFS exported, local)
/dev/da0s1f on /var (ufs, local)
procfs on /proc (procfs, local)
linprocfs on /usr/compat/linux/proc (linprocfs, local)
/dev/da0s1h on /home.THANATOS (ufs, local)
pectopah:/home on /home (nfs)
pectopah:/usr/local on /usr/localnew (nfs)
pectopah:/usr/X11R6 on /usr/local/X11R6 (nfs)
192.168.255.185:/usr on /mnt (nfs)
The name pectopah is the addr 192.168.255.185 and is the 5.0 NFS
server.
So, it seems it's something broken on my 5.0 NFS client's side. But I
can mount a 4.7S-exported filesystem onto my 5.0 boot-server so at
least its mount_nfs is OK:
/sbin/mount_nfs 192.168.255.180:/usr /mnt
> It is also possible that someone has broken something in NFS
> recently. The -current I am running (which works fine as
> a server for my EPIA 5000 and EPIA M 9000) is several weeks
> old.
Hmmm, how could I check this out? I'm happy to do testing and provide
feedback.
> If your /usr partition is on / on your server (i.e. not
> its own partition), then remember to use the -alldirs option
> in /etc/exports for / and /usr. If /usr is on its own
> partition you don't need -alldirs unless you are trying to
> mount a subdirectory in / or /usr. You *might* need -alldirs
> on your / export. In anycase, I always set -alldirs on all
> my read-only exports and that is what I would recommend you
> do too.
I've removed the readonly flags until I get this working. I have
separate / and /usr partitions; here's my 5.0 boot-server's
/etc/exports file (Kitchen is the diskless box :-)
/usr/local -alldirs -maproot=root Sisyphus Thanatos Beatnik Kitchen
/usr-alldirs -maproot=root Sisyphus Thanatos Beatnik Kitchen
/home-maproot=root Sisyphus Thanatos Beatnik Kitchen
And the dhcpd.conf which told the diskless client where to get it's
"/" partition from (and that is successful):
host Kitchen.shenton.org {
hardware ethernet 00:40:63:c3:89:bb;
fixed-address kitchen.shenton.org;
filename"pxeboot";
option root-path"192.168.255.185:/usr/local/diskless";
}
Am I correct that I only need to have "mount_nfs" on the diskless
client, that I do NOT need an rpcbind running on the diskless client
before issuing the mount? Since pxeboot (?) mounts / via NFS, I'm not
understanding why mount_nfs can't.
Thanks again.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S
:Matthew Dillon <[EMAIL PROTECTED]> writes:
:
:> 4.x and -current use the same mechanism, except 4.x uses MFS and
:> -current uses MD.
:
:4.x uses /etc/diskless[12] while 5.x (by default) uses
:/etc/rc.d/(init)?diskless. The latter is works very differently than
:the former.
4.x uses /etc/rc.diskless[12]. I synchronized most of -current and
-stable's rc.diskless scripts a month or two ago so even though parts
of the scripts are different (like the use of MFS instead of MD),
they should operate according to the same /conf rules.
:> kenv is only used in current's rc.diskless scripts, and it
:> resides in /bin on -current.
:
:Not on mine:
:
: chris@Pectopah<103> whereis kenv
: kenv: /usr/bin/kenv /usr/share/man/man1/kenv.1.gz /usr/src/bin/kenv
: chris@Pectopah<104> ls /bin/kenv
: ls: /bin/kenv: No such file or directory
Are you sure you have done a recent buildworld/installworld? It
sounds like you haven't. In -current kenv is in /bin (i.e.
the source is in /usr/src/bin/kenv on -current) as of the 15th of
this month. But it still should have worked because /usr should
have been mounted by then.
:> Basically what you do is create a files and directories in
:> /conf/base and /conf/default which are used to populate the
:> MFS/MD root and other directories. I have included my setup
:> at the end.
:
:Which startup scripts are you running, old diskless[12] or new
:rc.d/(init)?diskless ?
Both should work the same. The new rc.d/initdiskless and rc.d/diskless
run the same rules that rc.diskless1 and rc.diskless2 do.
:Thanks for your examples, I'll plow through them tonight. But -- more
:below -- these sure look like 4.x-compatible stuff, not 5.0.
4.x and 5.x work the same. That is, -stable and -current work the same.
If you are running an older 4.x (possibly even the last 4.x release)
it may not have the new scripts.
:Actually, I don't see any code to look for that md_size or
:diskless_remount in either of 5.0's rc.diskless[12] or
:rc.d/(init)?diskless. I do know that what you're describing is in
:4.x's rc.diskless[12], and I did have that working on a 4.7S system.
:That's why I'm having so much trouble with the 5.0 diskless boot --
:everything's changed.
:..
:Thanks a bunch!
You must be working off an out of date source tree.
I have included -current's current /usr/src/etc/rc.d/initdiskless script
below for you to compare against your sources. If your sources are out
of date you should update them (e.g. via cvsup or whatever you use to
get the sources). As you can see, the initidiskless script is full
of references to md_size :-)
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
#!/bin/sh
#
# Copyright (c) 1999 Matt Dillion
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
# $FreeBSD: src/etc/rc.d/initdiskless,v 1.23 2003/02/15 16:29:20 jhay Exp $
#
# PROVIDE: initdiskless
# KEYWORD: FreeBSD
# On entry to this script the entire system consists of a read-only root
# mounted via NFS. We use the contents of /conf to create and populate
# memory filesystems. The kernel has run BOOTP and configured an interface
# (otherwise it would not have been able to mount the NFS root!)
#
# The following directories are scanned. Each sucessive directory overrides
# (is merged into) the previous one.
#
# /conf/base universal base
# /conf/default modified by a secondary universal base
# /conf/${ipba} modified based on the assigned broadcast IP
# /conf/${ip} modified based on the machine's
Re: cvs commit: src/sys/alpha/alpha busdma_machdep.c src/sys/alpha/osf1 imgact_osf1.c osf1_misc.c src/sys/cam cam_periph.c cam_sim.c cam_xpt.c src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_low.c scsi_sa.c scsi_target.c src/sys/coda cnode.h ...
In message <[EMAIL PROTECTED]>, Peter Wemm writes: >[EMAIL PROTECTED] wrote: > >> The attached patch will print a backtrace if any calls to malloc >> fail to have either M_WAITOK or M_NOWAIT. > >Please do not commit this as-is.. There is a DoS here if a user figures >out how to provoke this. This is exactly the situation that Alfred was >worried about. I have no intention of committing this. The email from the TRB@ indicated that a plan exists, this patch was merely meant as an aid to people to find any issues up front. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UFS/SOFTUPDATE inconsistency
Paolo Pisati schrieb: [root@southcross root]# fsck /dev/ad0s1e ** /dev/ad0s1e (NO WRITE) ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames MISSING '.' I=667872 OWNER=root MODE=40755 SIZE=512 MTIME=Feb 10 16:54 2003 DIR=/ports/cad/gwave UNEXPECTED SOFT UPDATE INCONSISTENCY CANNOT FIX, FIRST ENTRY IN DIRECTORY CONTAINS files UNEXPECTED SOFT UPDATE INCONSISTENCY ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? no SUMMARY INFORMATION BAD SALVAGE? no BLK(S) MISSING IN BIT MAPS SALVAGE? no 209599 files, 1970937 used, 2594963 free (52235 frags, 317841 blocks, 1.1% fragm entation) [root@southcross root]# any on how to fix it? Best way: boot with CD 2 of FreeBSD 5.0 and go to Fixit -> CD-ROM. Then in console (ALT + F4) run: fsck -y /dev/ad0s1e You can also try "boot -s" at boot prompt and then run fsck. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S
Matthew Dillon <[EMAIL PROTECTED]> writes: > 4.x and -current use the same mechanism, except 4.x uses MFS and > -current uses MD. 4.x uses /etc/diskless[12] while 5.x (by default) uses /etc/rc.d/(init)?diskless. The latter is works very differently than the former. > Ignore the handbook. Try 'man diskless'. Ouch, will try the man. > kenv is only used in current's rc.diskless scripts, and it > resides in /bin on -current. Not on mine: chris@Pectopah<103> whereis kenv kenv: /usr/bin/kenv /usr/share/man/man1/kenv.1.gz /usr/src/bin/kenv chris@Pectopah<104> ls /bin/kenv ls: /bin/kenv: No such file or directory chris@Pectopah<105> uname -a FreeBSD Pectopah.shenton.org 5.0-RELEASE-p1 FreeBSD 5.0-RELEASE-p1 #0: Sun Feb 16 16:10:36 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/Pectopah i386 And the /usr/bin/kenv needs the elf libraries to run, it's not static, so shouldn't live in /sbin and can't run on a diskless box until /usr is mounted. > Basically what you do is create a files and directories in > /conf/base and /conf/default which are used to populate the > MFS/MD root and other directories. I have included my setup > at the end. Which startup scripts are you running, old diskless[12] or new rc.d/(init)?diskless ? Thanks for your examples, I'll plow through them tonight. But -- more below -- these sure look like 4.x-compatible stuff, not 5.0. > /conf/base: > total 5 > drwxr-xr-x 2 root wheel 512 Dec 21 10:37 dev > drwxr-xr-x 2 root wheel 512 Dec 19 22:22 etc > -rw-r--r-- 1 root wheel 11 Dec 20 15:38 etc.remove > drwxr-xr-x 2 root wheel 512 Dec 20 14:31 root > -rw-r--r-- 1 root wheel 12 Dec 20 15:38 root.remove > > /conf/base/dev: > total 2 > -rw-r--r-- 1 root wheel 18 Dec 21 10:37 diskless_remount > -rw-r--r-- 1 root wheel 6 Dec 19 22:22 md_size The etc.remove and md_size are used by 4.x's diskless[12] but NOT by the 5.x /etc/rc.d/(init?)diskless scripts. Are you using the old startup rc stuff, possibly changing the default value in /etc/defaults/rc.conf: rc_ng="YES" # Set to NO to disable new-style rc scripts. If so and it works for you, I can certainly do the same. But I'd still like to figure how to get the 5.x rc.d/* scripts to do their thing. Actually, I don't see any code to look for that md_size or diskless_remount in either of 5.0's rc.diskless[12] or rc.d/(init)?diskless. I do know that what you're describing is in 4.x's rc.diskless[12], and I did have that working on a 4.7S system. That's why I'm having so much trouble with the 5.0 diskless boot -- everything's changed. Lemme know if I'm way off base but it sounds like you're describing a 4.x diskless boot and my problem's with 5.0. Thanks a bunch! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S
I'm not sure what is occuring here but it sounds like cockpit trouble somewhere. Make sure your NFS server is exporting to your subnet and that it is running the necessary services, (portmap, mountd, nfsd -t -u -n 4). If you have another box that you can boot normally (not netboot), test the NFS server from that box by mounting / and /usr: other# mount 192.168.255.185:/usr /mnt Or, if you have no other box, make sure you can mount the server onto the server itself as a test: nfsserver# mount localhost:/usr /mnt nfsserver# mount myaddress:/usr /mnt(aka 192.168.255.185) If you are running a firewire on the server, make sure it is letting NFS through to your LAN. It is also possible that someone has broken something in NFS recently. The -current I am running (which works fine as a server for my EPIA 5000 and EPIA M 9000) is several weeks old. If your /usr partition is on / on your server (i.e. not its own partition), then remember to use the -alldirs option in /etc/exports for / and /usr. If /usr is on its own partition you don't need -alldirs unless you are trying to mount a subdirectory in / or /usr. You *might* need -alldirs on your / export. In anycase, I always set -alldirs on all my read-only exports and that is what I would recommend you do too. -Matt :Chris Shenton <[EMAIL PROTECTED]> writes: : :> I've moved the "mount -a" near the top of rc.d/diskless since it :> runs commands which are and not available until /usr is mounted :> (e.g., mtree). The NFS mount fails with a message I don't :> understand: :> :> [udp] pectopah.shenton.org:/usr: RPCPROG_NFS: RPC: Unknown host : :Tasteless self-followup: : :I get the same error when the boot process fails and drops me to a :shell; I can get it with UDP or TCP mounts. For example: : : mount_nfs -U -2 192.168.255.185:/usr /mnt : mount_nfs -U -3 192.168.255.185:/usr /mnt : mount_nfs -T -2 192.168.255.185:/usr /mnt : mount_nfs -T -3 192.168.255.185:/usr /mnt : :The only difference is the [udp] vs [tcp] in the error msg: : : [tcp] 192.168.255.185:/usr: RPCPROG_NFS: RPC: Unknown host : :I sniffed traffic with tcpdump and ethereal: the diskless client is :contacting the server so it's not having problems resolving that IP :addr. :... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S
4.x and -current use the same mechanism, except 4.x uses MFS and -current uses MD. Ignore the handbook. Try 'man diskless'. kenv is only used in current's rc.diskless scripts, and it resides in /bin on -current. kenv is not used in 4.x's diskless scripts. Basically what you do is create a files and directories in /conf/base and /conf/default which are used to populate the MFS/MD root and other directories. I have included my setup at the end. :I was running a VIA Mini-ITX diskless box off a 4.7-STABLE box for a :while using a root fs created by the clone_root discussed in the :handbook, then some tweaks. I'm having a heck of a time trying to get :this running under 5.0-RELEASE, now sync'd to 5.0-CURRENT as of :yesterday, then mergemastered. : :If someone can provide some clues or pointers, I'd be happy to doc how :I get it to work (for the Handbook?) and could take a stab at updating :clone_root for 5.x if it's needed. : : :Background: : :Been using FreeBSD since 2.2.x. I can code. I can RTFM. :-) : :I've read the 5.0 Release Notes and Early Adopters docs. :... : :Upon boot, after kernel loaded, console shows a bunch of rc.conf-style :vars being set, then spews some debugging which I put in :$DISKLESSROOT/conf/default/etc/rc.d/diskless, so it's running that :rather than the old /etc/rc.diskless* files. I've moved the "mount -a" :near the top of rc.d/diskless since it runs commands which are and not :available until /usr is mounted (e.g., mtree). The NFS mount fails :with a message I don't understand: : :Can someone point me in the right direction ? Thanks! I'm not sure what you are doing here. You don't want to override any rc.d files in /conf. That will blow things up for sure. Ok, here is an ls -lR of my setup: # ls -lR /conf total 2 drwxr-xr-x 5 root wheel 512 Dec 21 10:37 base drwxr-xr-x 3 root wheel 512 Dec 19 21:56 default /conf/base: total 5 drwxr-xr-x 2 root wheel 512 Dec 21 10:37 dev drwxr-xr-x 2 root wheel 512 Dec 19 22:22 etc -rw-r--r-- 1 root wheel 11 Dec 20 15:38 etc.remove drwxr-xr-x 2 root wheel 512 Dec 20 14:31 root -rw-r--r-- 1 root wheel 12 Dec 20 15:38 root.remove /conf/base/dev: total 2 -rw-r--r-- 1 root wheel 18 Dec 21 10:37 diskless_remount -rw-r--r-- 1 root wheel 6 Dec 19 22:22 md_size /conf/base/etc: total 2 -rw-r--r-- 1 root wheel 18 Dec 19 22:10 diskless_remount -rw-r--r-- 1 root wheel 6 Dec 19 22:22 md_size /conf/base/root: total 2 -rw-r--r-- 1 root wheel 19 Dec 20 14:31 diskless_remount -rw-r--r-- 1 root wheel 5 Dec 20 14:31 md_size /conf/default: total 1 drwxr-xr-x 3 root wheel 512 Dec 20 11:18 etc /conf/default/etc: total 4 -rw-r--r-- 1 root wheel 184 Feb 18 18:16 fstab -rw-r--r-- 1 root wheel 867 Dec 21 00:04 rc.conf -rw-r--r-- 1 root wheel 197 Feb 18 18:19 rc.local And some cats: apollo:/conf# cat /conf/base/dev/diskless_remount 216.240.41.2:/dev apollo:/conf# cat /conf/base/dev/md_size 16384 apollo:/conf# cat /conf/base/etc/diskless_remount 216.240.41.2:/etc apollo:/conf# cat /conf/base/etc/md_size 16384 apollo:/conf# cat /conf/base/root/diskless_remount 216.240.41.2:/root apollo:/conf# cat /conf/base/root/md_size 8192 apollo:/conf# cat /conf/default/etc/rc.conf hostname="mobile.backplane.com" nfs_client_enable="YES" local_startup="" ip_portrange_first=4000 ip_portrange_last=8192 syslogd_enable="NO" firewall_enable="YES" firewall_type="/etc/ipfw.conf" ntpdate_enable="YES" ntpdate_flags="apollo.backplane.com" xntpd_enable="YES" sshd_enable="YES" sendmail_enable="NO" linux_enable="NO" apollo:/conf# cat /conf/default/etc/fstab # DeviceMountpoint FStype Options DumpPass# apollo:/usr /usrnfs ro 0 0 apollo:/FreeBSD /FreeBSDnfs ro 0 0 apollo:/backup1 /usr/objnfs rw 0 0 proc/proc procfs rw 0 0 That's basically it. You can also use /conf/base/.remove and /conf/default/.remove files to list files to remove from the clone. You don't have to specify a network config in your /conf/default/etc/rc.conf because the network will have already been setup. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/alpha/alpha busdma_machdep.c src/sys/alpha/osf1 imgact_osf1.c osf1_misc.c src/sys/cam cam_periph.c cam_sim.c cam_xpt.c src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_low.c scsi_sa.c scsi_target.c src/sys/coda cnode.h ...
[EMAIL PROTECTED] wrote:
> The attached patch will print a backtrace if any calls to malloc
> fail to have either M_WAITOK or M_NOWAIT.
Please do not commit this as-is.. There is a DoS here if a user figures
out how to provoke this. This is exactly the situation that Alfred was
worried about.
> + indx = flags & (M_WAITOK | M_NOWAIT);
> + if (indx == M_NOWAIT) {
> + /* OK */
> + } else if (indx == M_WAITOK) {
> + /* OK */
> + } else {
> + printf("Missing M_WAITOK flag\n");
> + backtrace();
> + flags |= M_WAITOK;
> + }
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Simply impossible to format disk under current.
> "phk" == phk <[EMAIL PROTECTED]> writes: phk> /dev/da2 is always writable unless you have any of the partitions phk> open. The error was that /dev/da2 didn't exist. I was confused too. fdisk da2 # worked, displyed one slice (3) that was NetBSD fdisk -I da2 # error, /dev/da2 doesn't exist ... it seemed like anything that wrote to da2 would fail, but read worked. phk> I guess you have whacked the disk now, so I won't be able to get phk> any debugging information. In the process of determining that it worked with 4.7-RELEASE I did format the disk, so I'm not sure that the disk itself is useful. phk> In case of disk/GEOM related problems, I need the output from phk> dmesg sysctl -b kern.geom.confxml or I won't really be able to do phk> debugging... I would bet that any NetBSD root disk installed by the NetBSD installer would exhibit the same problems. It should be easy to duplicate. I don't have a spare disk handy right now... but I might be able to do this in a week or two. I would expect that you can do this on your bench, tho. There wasn't anything special about the NetBSD disks ... they had just been formatted through the install process that NetBSD does. 1.5.2, I think. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Simply impossible to format disk under current.
In message <[EMAIL PROTECTED]>, David Gilbert writes: >I ran into an interesting problem last night ... that was very >frustrating. I was recycling SCSI drives from some NetBSD machines >(that were client boxes) to add to a RAID server running >FreeBSD-5.0-RELEASE. > >It's simply impossible to format NetBSD drives under current. > >Let me expand on that. /dev/da2 exists, but you can't say 'fdisk -I >da2' ... fdisk says that /dev/da2 doesn't exist. /dev/da2 (and >/dev/da2c) isn't writable, so I can't blank the first few sectors. I >even tried this in single user mode. /dev/da2 is always writable unless you have any of the partitions open. I guess you have whacked the disk now, so I won't be able to get any debugging information. In case of disk/GEOM related problems, I need the output from dmesg sysctl -b kern.geom.confxml or I won't really be able to do debugging... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: top-of-tree alpha kernel panics during boot
Can you post your kernel config please, along with with, if any, CPUTYPE you have set in make.conf and a description of your machine (mem size in particular)? I'm unable to reproduce the boot panic with a GENERIC as of today. (rest of machine is from Nov 1st). Rebuilding without CPUTYPE now.. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: background fsck deadlocks with ufs2 and big disk
David Schultz <[EMAIL PROTECTED]> wrote: > IIRC, Kirk was trying to reproduce this a little while ago in > response to similar reports. He would probably be interested > in any new information. I don't have any useful information, but I do have a data point: My 5.0-RELEASE system recently mysteriously panic'd, which resulted in a partially trashed UFS1 filesystem, which caused bg fsck to hang. Details: * The panic was weird, in that only the first 4-6 characters of the first function (in the panic stacktrace) was displayed on the console (sorry, forgot what it was). Nothing else past that point was shown, and the console was locked up. Ddb was compiled into the kernel, but ctrl-esc did nothing. * The UFS1 filesystem in question (and I assume that it was UFS1, as I did not specify a filesystem type to newfs) is located on a RAID5 vinum volume, consisting of five 80GB disks. * Softupdates is enabled. * When bg fsck hung (w/no disk activity), I could break into the ddb. Unfortunately, I don't know how to use ddb, aside from "ps". * Disabling bg fsck allowed the system to boot. However, fg fsck failed, and I had to do a manual fsck, which spewed lots of nasty "SOFTUPDATE INCONSISTENCY" errors. * Disturbingly (but fortunately), I then unmounted the filesystem (in multi-user mode) and re-ran fsck, and fsck still found errors. There should not have been any errors, as fg fsck just finished running. [ Unfortunately, I've forgotten what they were, and an umount/fsck done right now shows no problems. I think the errors were one of the "incorrect block count" errors. ] * After the fsck, some files were partially truncated (& corrupted?). After investigating, I believe these truncated files (which were NOT recently modified) were in a directory in which other files were being created/written at the time of the panic. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Cardbus-attached USB controller
Hi, I've got a Sitecom cardbus USB controller here, probes as: found-> vendor=0x1033, dev=0x0035, revid=0x41 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns) intpin=a, irq=255 cardbus0: Resource not specified in CIS: id=10, size=1000 cardbus0: (vendor=0x1033, dev=0x0035) at 0.0 irq 10 found-> vendor=0x1033, dev=0x0035, revid=0x41 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns) intpin=b, irq=255 cardbus0: Resource not specified in CIS: id=10, size=1000 cardbus0: (vendor=0x1033, dev=0x0035) at 0.1 irq 10 found-> vendor=0x1033, dev=0x00e0, revid=0x02 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x10 (4000 ns), maxlat=0x22 (8500 ns) intpin=c, irq=255 cardbus0: Resource not specified in CIS: id=10, size=100 cardbus0: (vendor=0x1033, dev=0x00e0) at 0.2 irq 10 That's 2 ohci and an ehci (which I realise isn't supported (yet)). Would someone like to give me a clue how to plumb this thing in? TIA -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Simply impossible to format disk under current.
I ran into an interesting problem last night ... that was very frustrating. I was recycling SCSI drives from some NetBSD machines (that were client boxes) to add to a RAID server running FreeBSD-5.0-RELEASE. It's simply impossible to format NetBSD drives under current. Let me expand on that. /dev/da2 exists, but you can't say 'fdisk -I da2' ... fdisk says that /dev/da2 doesn't exist. /dev/da2 (and /dev/da2c) isn't writable, so I can't blank the first few sectors. I even tried this in single user mode. The problem appears to be that the FreeBSD-5.0 system sees the NetBSD label ... so things like da2s1 don't exist. da2a, da2b, da2c and da2g do. These are the NetBSD partitions. Writing to them is verboten. I was hoping that da2c would allow me to blank the boot sector, but it doesn't allow me to write. ... under FreeBSD-5.0, fdisk won't write to the disk and disklabel won't change the NetBSD label, either. I had to boot with my FreeBSD-4.7 recovery CD ... which would fdisk and disklabel the disk (note that fdisking wasn't enough ... FreeBSD still accepted the NetBSD label over the fdisk data) just fine. ... although I then ran into the issue that disklabel -e had /mnt2/stand/vi hardcoded into it ... which is wrong. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
reproducable kernel crash
OK, I can 100% let SMP kernel crash here. Turn on cpu hlt sysctl, %sysctl -w machdep.cpu_idle_hlt=1 then copy a large file to my home directory %cp /boot/kernel . Press ctl+alt+del immediately after copy. When in reboot state, kernel crashed when trying to shutdown bufdaemon. backtrace shows the trap is at cpu_idle+0x1e, the fault is page fault referencing zero address. if I set machdep.cpu_idle_hlt to 0, I can not reproduce the bug. %dmesg 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.0-CURRENT #7: Wed Feb 19 22:22:27 CST 2003 [EMAIL PROTECTED]:/home/davidxu/src/sys/i386/compile/xu2 Preloaded elf kernel "/boot/kernel/kernel" at 0xc04cc000. Preloaded elf module "/boot/kernel/vesa.ko" at 0xc04cc0a8. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04cc154. Timecounter "i8254" frequency 1193182 Hz CPU: Intel Pentium III (999.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x387fbff real memory = 268369920 (255 MB) avail memory = 255410176 (243 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 Pentium Pro MTRR support enabled VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc047fca2 (122) VESA: NVidia npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fdd20 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf000-0xf3ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xe000-0xe00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xe400-0xe41f irq 5 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 0xe800-0xe81f irq 5 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 pci0: at device 7.4 (no driver attached) ed0: port 0xec00-0xec1f irq 11 at device 9.0 on pci0 ed0: address 52:54:ab:52:53:8f, type NE2000 (16 bit) fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode 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, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xc-0xcb7ff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% ad0: 57241MB [116301/16/63] at ata0-master UDMA100 acd0: CDROM at ata1-slave PIO4 SMP: AP CPU #1 Launched! MBREXT Slice 5 on ad0s2: [0] f:00 typ:7 s(CHS):5/1/65 e(CHS):255/254/255 s:63 l:20964762 [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:20964825 l:20964825 MBREXT Slice 6 on ad0s2: [0] f:00 typ:7 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:20964762 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Mounting root from ufs:/dev/ad0s3a --- David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
could sleep with "buf queue lock" in -current
../../../kern/kern_lock.c:239: could sleep with "buf queue lock" locked from
../../../kern/vfs_bio.c:2143
Debugger("witness_sleep")
Stopped at 0xc0409aae = Debugger+0x7e: xchgl %ebx,0xc05b37e0 = in_Debugger.0
db> trace
Debugger(c04530c8,c0469eb9,ef,c046e636,c0470d54) at 0xc0409aae = Debugger+0x7e
witness_sleep(1,c419ad50,c0469eb9,ef,c1501e10) at 0xc026ad3c = witness_sleep+0x21c
lockmgr(c419ae04,10001,c419ad50,c1501e10,12) at 0xc021deee = lockmgr+0xce
vop_sharedlock(d68b6c94,0,c0472bac,35c,c02233aa) at 0xc02ae440 = vop_sharedlock+0xd0
vn_lock(c419ad50,12,c1501e10,85f,c02160d5) at 0xc02cfdf0 = vn_lock+0x140
flushbufqueues(c3f637f0,0,c0470d2f,81f,64) at 0xc02a43e7 = flushbufqueues+0x1f7
buf_daemon(0,d68b6d48,c04695c0,366,0) at 0xc02a3f13 = buf_daemon+0x133
fork_exit(c02a3de0,0,d68b6d48) at 0xc0213215 = fork_exit+0x135
fork_trampoline() at 0xc040c29e = fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xd68b6d7c, ebp = 0 ---
db>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/alpha/alpha busdma_machdep.c src/sys/alpha/osf1 imgact_osf1.c osf1_misc.c src/sys/cam cam_periph.c cam_sim.c cam_xpt.c src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_low.c scsi_sa.c scsi_target.c src/sys/coda cnode.h ...
In message <[EMAIL PROTECTED]>, Warner Losh write
s:
>imp 2003/02/18 21:47:47 PST
>
> Modified files:
>[... everything ...]
> uma_core.c vm_map.c vm_object.c
> Log:
> Back out M_* changes, per decision of the TRB.
>
> Approved by: trb
The attached patch will print a backtrace if any calls to malloc
fail to have either M_WAITOK or M_NOWAIT.
Please put this patch in your tree and help fix any issues.
So far (10 minutes) my disk-less testbox has found no issues.
Poul-Henning
Index: kern/kern_malloc.c
===
RCS file: /home/ncvs/src/sys/kern/kern_malloc.c,v
retrieving revision 1.116
diff -u -r1.116 kern_malloc.c
--- kern/kern_malloc.c 19 Feb 2003 05:47:25 - 1.116
+++ kern/kern_malloc.c 19 Feb 2003 07:55:19 -
@@ -167,11 +167,21 @@
#endif
register struct malloc_type *ksp = type;
+ indx = flags & (M_WAITOK | M_NOWAIT);
+ if (indx == M_NOWAIT) {
+ /* OK */
+ } else if (indx == M_WAITOK) {
+ /* OK */
+ } else {
+ printf("Missing M_WAITOK flag\n");
+ backtrace();
+ flags |= M_WAITOK;
+ }
#if 0
if (size == 0)
Debugger("zero size malloc");
#endif
- if (!(flags & M_NOWAIT))
+ if (flags & M_WAITOK)
KASSERT(curthread->td_intr_nesting_level == 0,
("malloc(M_WAITOK) in interrupt context"));
if (size <= KMEM_ZMAX) {
Index: sys/malloc.h
===
RCS file: /home/ncvs/src/sys/sys/malloc.h,v
retrieving revision 1.70
diff -u -r1.70 malloc.h
--- sys/malloc.h19 Feb 2003 05:47:45 - 1.70
+++ sys/malloc.h19 Feb 2003 07:58:41 -
@@ -46,11 +46,11 @@
/*
* flags to malloc.
*/
-#defineM_WAITOK0x
#defineM_NOWAIT0x0001 /* do not block */
-#defineM_USE_RESERVE 0x0002 /* can alloc out of reserve memory */
-#defineM_ZERO 0x0004 /* bzero the allocation */
-#defineM_NOVM 0x0008 /* don't ask VM for pages */
+#defineM_WAITOK0x0002 /* do not block */
+#defineM_ZERO 0x0100 /* bzero the allocation */
+#defineM_NOVM 0x0200 /* don't ask VM for pages */
+#defineM_USE_RESERVE 0x0400 /* can alloc out of reserve memory */
#defineM_MAGIC 877983977 /* time when first defined :-) */
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_intr.c src/sys/dev/ata ata-all.c
On Wed, Feb 19, 2003 at 10:20:12AM +1100, Bruce Evans wrote:
> On Tue, 18 Feb 2003, Ruslan Ermilov wrote:
>
> > On Fri, Feb 14, 2003 at 05:10:40AM -0800, Alfred Perlstein wrote:
> > > alfred 2003/02/14 05:10:40 PST
> > >
> > > Modified files:
> > > sys/kern kern_intr.c
> > > sys/dev/ata ata-all.c
> > > Log:
> > > Fix crash dumps on ata and scsi.
> > >
> > [...]
> > > To fix ata, use what appears to be a polling method if we're dumping,
> > > I stole this from tmm but added code to ensure that this change is
> > > only in effect while dumping.
> > >
> > > Tested by: des
> > >
> > FWIW, if I propagate this change to the !dumping case, it also
> > fixes the ``resume stucks in "ata1: resetting devices .."'' bug
> > I was having with my ThinkPad 600X:
> >
> > %%%
> > Index: ata-all.c
> > ===
> > RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
> > retrieving revision 1.165
> > diff -u -p -r1.165 ata-all.c
> > --- ata-all.c 14 Feb 2003 13:10:40 - 1.165
> > +++ ata-all.c 18 Feb 2003 10:08:22 -
> > @@ -486,8 +486,7 @@ ata_getparam(struct ata_device *atadev,
> >
> > /* apparently some devices needs this repeated */
> > do {
> > - if (ata_command(atadev, command, 0, 0, 0,
> > - dumping ? ATA_WAIT_READY : ATA_WAIT_INTR)) {
> > + if (ata_command(atadev, command, 0, 0, 0, ATA_WAIT_READY)) {
> > ata_prtdev(atadev, "%s identify failed\n",
> >command == ATA_C_ATAPI_IDENTIFY ? "ATAPI" : "ATA");
> > free(ata_parm, M_ATA);
> > %%%
>
> There is, or was, something near here that made the whole system go
> unresponsive (as seen by nfs clients) for several seconds. I guess
> the main problem was just using polled mode in all cases here. In
> RELENG_4, polling is done at splbio() so normally only disk devices
> are blocked, but under -current almost everything is blocked by Giant.
>
The symptoms were as following. The console is blocked, and if I type
something, I don't see it unless I enter into the DDB -- then what I
have typed is displayed.
> > The resume session (with apm(4)) now looks like this:
> >
> > : cbb0: PCI Memory allocated: 50103000
> > : cbb1: PCI Memory allocated: 50102000
> > : pcm0: detached
> > : csa: card is Thinkpad 600X/A20/T20
> > : pcm0: on csa0
> > : pcm0:
> > : wakeup from sleeping state (slept 00:00:10)
> > : ata0: resetting devices ..
> > : done
> > : ata1: resetting devices ..
> > : ata1-slave: timeout waiting for cmd=ec s=01 e=24
> > : ata1-slave: ATA identify failed
> > : done
>
> Apparently the timeout is too short or the interrupt got lost. The
> timeout seems to be too short. It is 10 seconds, but IIRC the spec
> is says 30 seconds for reset of the master and a bit more for the
> slave. Since things work with polling, we know that the device state
> changed properly. We could test for this state change instead of
> always aborting after the timeout, and do finer grained and more sleeps
> to determine the precise timeout required.
>
I recall seeing the ``stray irq 15'' too, so yes, that may likely
be the case here. I will try bumping up the ATA_WAIT_INTR timeout
later today and let you know the results.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg52695/pgp0.pgp
Description: PGP signature
