Re: Another current crash (cvs-cur.6183
[formatting recovered] On Mon, Apr 03, 2000 at 10:57:46AM +0100, Nick Hibma wrote: > On Fri, 31 Mar 2000, Paul Haddad wrote: > > On Wed, 22 Mar 2000, Christopher Masto wrote: > > > I've been playing around with one of those iopener things and got > > > myself into a state I thought I could get out of with the help of a > > > USB Zip drive. Unfortunately, upon purchasing and connecting one, > > > I discovered that I can't access it without a panic, which I > > > point out here on the chance it's also related. > > > > Boy I wish I had read this message before I went out and bought a > > USB zip drive... I'm in the exact same situation IOPENER with 4.0 > > installed and screwed up to a point where I can boot but not mount > > the sandisk drive. I figured that I would get a zip drive and > > mount it instead. Anyways if you found some way around this please > > let me know, otherwise I've got to make another trip out and get a > > SuperDisk instead... > > > > BTW What state are you in? Mine will boot, but gets to the point > > where it tries to mount the sandisk and panics with a ffs_write > > panic. Booting in single user doesn't help. > > Where are you guys now as far as USB drives are concerned? I've been > looking a lot at the driver lately and would like to hear about any > problems you have. Well, as for the i-opener, I've gotten mine working. See http://www.kenseglerdesigns.com/cgi-bin/UltraBoard/UltraBoard.pl?Action=ShowPost&Board=technical&Post=115 I did not have a problem with a panic mounting the sandisk, I just didn't have a /boot/loader on it so I couldn't load my mfsroot.gz. I was eventually able to find a Y-E Data floppy drive and use it as a root filesystem by entering "ufs:/dev/da0" at the mount root prompt. If a 4.0 kernel is on there, I don't know what to say, as I don't know what worked at that point. SuperDisk is certainly out of the question, since it's not there even now. Regarding USB drives, I have been using the Orb "2.2GB" USB-SCSI version with some success. There do seem to be some serious filesystem corruption problems, but I haven't had time to determine where they're coming from. I often get corruption-related panics while trying to install packages, and fsck always finds a number of serious problems and removes about a dozen files (from /usr/lib mostly, so I'll eventually lose something important). When I download something large, such as XFree86, the file's checksum comes out wrong and gzip fails with errors. I need to have a few hours free to try it on a different machine, with different media, etc. to try to narrow this down. I have also been getting kue lockups, so there are a lot of possibilities. I really haven't played with the thing too much, partly because it's very slow and takes a good 15 minutes to fsck every time I crash it. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another current crash (cvs-cur.6183
Where are you guys now as far as USB drives are concerned? I've been
looking a lot at the driver lately and would like to hear about any
problems you have.
Nick
On Fri, 31 Mar 2000, Paul Haddad wrote:
> Hi,
>
> Boy I wish I had read this message before I went out and bought a USB zip
> drive... I'm in the exact same situation IOPENER with 4.0 installed and
> screwed up to a point where I can boot but not mount the sandisk drive. I
> figured that I would get a zip drive and mount it instead.
>
> Anyways if you found some way around this please let me know, otherwise I've
> got to make another trip out and get a SuperDisk instead...
>
> BTW What state are you in? Mine will boot, but gets to the point where it
> tries to mount the sandisk and panics with a ffs_write panic. Booting in
> single user doesn't help.
> ---
> Paul Haddad ([EMAIL PROTECTED])
> Imagine that Cray computer decides to make a personal computer. It has
> a 150 MHz processor, 200 megabytes of RAM, 1500 megabytes of disk
> storage, a screen resolution of 4096 x 4096 pixels, relies entirely on
> voice recognition for input, fits in your shirt pocket and costs $300.
> What's the first question that the computer community asks?
>
> "Is it PC compatible?"
>
> - Original Message -
> From: "Christopher Masto" <[EMAIL PROTECTED]>
> To: "Paul Richards" <[EMAIL PROTECTED]>; "Stephen Hocking-Senior
> Programmer PGS SPS Perth" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Wednesday, March 22, 2000 12:16 AM
> Subject: Re: Another current crash (cvs-cur.6183
>
>
> > On Wed, Mar 22, 2000 at 03:02:02AM +, Paul Richards wrote:
> > > I've got a different but I think related panic.
> > >
> > > #9 0xc0143280 in panic (fmt=0xc0250460 "vm_page_wakeup: page not
> > > busy!!!")
> > > at ../../kern/kern_shutdown.c:552
> > > #10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
> > > at ../../vm/vm_page.h:346
> >
> > I've been playing around with one of those iopener things and got
> > myself into a state I thought I could get out of with the help of a
> > USB Zip drive. Unfortunately, upon purchasing and connecting one,
> > I discovered that I can't access it without a panic, which I
> > point out here on the chance it's also related.
> >
> > #7 0xc024ac2c in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
> > tf_edi = -1018879976, tf_esi = 256, tf_ebp = -919618472, tf_isp
> = -919618500,
> > tf_ebx = -1071201278, tf_edx = 0, tf_ecx = -1070746656, tf_eax = 18,
> > tf_trapno = 3, tf_err = 0, tf_eip = -1071396739, tf_cs = 8,
> tf_eflags = 582,
> > tf_esp = -1071099905, tf_ss = -1071212893}) at
> ../../i386/i386/trap.c:549
> > #8 0xc023c87d in Debugger (msg=0xc02696a3 "panic") at
> machine/cpufunc.h:64
> > #9 0xc01549e8 in panic (fmt=0xc026c402 "allocbuf: buffer too small")
> > at ../../kern/kern_shutdown.c:552
> > #10 0xc0178f5a in allocbuf (bp=0xc3452018, size=83886080) at
> ../../kern/vfs_bio.c:2346
> > #11 0xc0178f01 in geteblk (size=83886080) at ../../kern/vfs_bio.c:2315
> > #12 0xc025cb57 in dsinit (dev=0xc0be1e00, lp=0xc0c490f4, sspp=0xc0c490f0)
> > at ../../kern/subr_diskmbr.c:186
> > #13 0xc015eec6 in dsopen (dev=0xc0be1e00, mode=8192, flags=0,
> sspp=0xc0c490f0,
> > lp=0xc0c490f4) at ../../kern/subr_diskslice.c:683
> > #14 0xc015dfbf in diskopen (dev=0xc0be1e00, oflags=1, devtype=8192,
> p=0xc88be860)
> > at ../../kern/subr_disk.c:146
> > #15 0xc018ae65 in spec_open (ap=0xc92fbe10) at
> ../../miscfs/specfs/spec_vnops.c:191
> > #16 0xc018ad65 in spec_vnoperate (ap=0xc92fbe10)
> > at ../../miscfs/specfs/spec_vnops.c:117
> > #17 0xc01ff2e9 in ufs_vnoperatespec (ap=0xc92fbe10) at
> ../../ufs/ufs/ufs_vnops.c:2301
> > #18 0xc018595f in vn_open (ndp=0xc92fbedc, fmode=1, cmode=0) at
> vnode_if.h:189
> > #19 0xc0181951 in open (p=0xc88be860, uap=0xc92fbf80) at
> ../../kern/vfs_syscalls.c:994
> > #20 0xc024b4ce in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
> > tf_edi = -1077937212, tf_esi = 134894800, tf_ebp = -1077937132,
> > tf_isp = -919617580, tf_ebx = 0, tf_edx = 8, tf_ecx = 134894828,
> tf_eax = 5,
> > tf_trapno = 12, tf_err = 2, tf_eip = 672026540, tf_cs = 31,
> tf_eflags = 642,
> > tf_esp = -1077937316, tf_ss = 47}) at ../../i386/i386/trap.c:1073
> > #21 0xc023cf26 in Xint0x80_syscall ()
> >
> > I'm not intimately familiar with the function in
Re: Another current crash (cvs-cur.6183
Hi,
Boy I wish I had read this message before I went out and bought a USB zip
drive... I'm in the exact same situation IOPENER with 4.0 installed and
screwed up to a point where I can boot but not mount the sandisk drive. I
figured that I would get a zip drive and mount it instead.
Anyways if you found some way around this please let me know, otherwise I've
got to make another trip out and get a SuperDisk instead...
BTW What state are you in? Mine will boot, but gets to the point where it
tries to mount the sandisk and panics with a ffs_write panic. Booting in
single user doesn't help.
---
Paul Haddad ([EMAIL PROTECTED])
Imagine that Cray computer decides to make a personal computer. It has
a 150 MHz processor, 200 megabytes of RAM, 1500 megabytes of disk
storage, a screen resolution of 4096 x 4096 pixels, relies entirely on
voice recognition for input, fits in your shirt pocket and costs $300.
What's the first question that the computer community asks?
"Is it PC compatible?"
- Original Message -
From: "Christopher Masto" <[EMAIL PROTECTED]>
To: "Paul Richards" <[EMAIL PROTECTED]>; "Stephen Hocking-Senior
Programmer PGS SPS Perth" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, March 22, 2000 12:16 AM
Subject: Re: Another current crash (cvs-cur.6183
> On Wed, Mar 22, 2000 at 03:02:02AM +, Paul Richards wrote:
> > I've got a different but I think related panic.
> >
> > #9 0xc0143280 in panic (fmt=0xc0250460 "vm_page_wakeup: page not
> > busy!!!")
> > at ../../kern/kern_shutdown.c:552
> > #10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
> > at ../../vm/vm_page.h:346
>
> I've been playing around with one of those iopener things and got
> myself into a state I thought I could get out of with the help of a
> USB Zip drive. Unfortunately, upon purchasing and connecting one,
> I discovered that I can't access it without a panic, which I
> point out here on the chance it's also related.
>
> #7 0xc024ac2c in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
> tf_edi = -1018879976, tf_esi = 256, tf_ebp = -919618472, tf_isp
= -919618500,
> tf_ebx = -1071201278, tf_edx = 0, tf_ecx = -1070746656, tf_eax = 18,
> tf_trapno = 3, tf_err = 0, tf_eip = -1071396739, tf_cs = 8,
tf_eflags = 582,
> tf_esp = -1071099905, tf_ss = -1071212893}) at
../../i386/i386/trap.c:549
> #8 0xc023c87d in Debugger (msg=0xc02696a3 "panic") at
machine/cpufunc.h:64
> #9 0xc01549e8 in panic (fmt=0xc026c402 "allocbuf: buffer too small")
> at ../../kern/kern_shutdown.c:552
> #10 0xc0178f5a in allocbuf (bp=0xc3452018, size=83886080) at
../../kern/vfs_bio.c:2346
> #11 0xc0178f01 in geteblk (size=83886080) at ../../kern/vfs_bio.c:2315
> #12 0xc025cb57 in dsinit (dev=0xc0be1e00, lp=0xc0c490f4, sspp=0xc0c490f0)
> at ../../kern/subr_diskmbr.c:186
> #13 0xc015eec6 in dsopen (dev=0xc0be1e00, mode=8192, flags=0,
sspp=0xc0c490f0,
> lp=0xc0c490f4) at ../../kern/subr_diskslice.c:683
> #14 0xc015dfbf in diskopen (dev=0xc0be1e00, oflags=1, devtype=8192,
p=0xc88be860)
> at ../../kern/subr_disk.c:146
> #15 0xc018ae65 in spec_open (ap=0xc92fbe10) at
../../miscfs/specfs/spec_vnops.c:191
> #16 0xc018ad65 in spec_vnoperate (ap=0xc92fbe10)
> at ../../miscfs/specfs/spec_vnops.c:117
> #17 0xc01ff2e9 in ufs_vnoperatespec (ap=0xc92fbe10) at
../../ufs/ufs/ufs_vnops.c:2301
> #18 0xc018595f in vn_open (ndp=0xc92fbedc, fmode=1, cmode=0) at
vnode_if.h:189
> #19 0xc0181951 in open (p=0xc88be860, uap=0xc92fbf80) at
../../kern/vfs_syscalls.c:994
> #20 0xc024b4ce in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
> tf_edi = -1077937212, tf_esi = 134894800, tf_ebp = -1077937132,
> tf_isp = -919617580, tf_ebx = 0, tf_edx = 8, tf_ecx = 134894828,
tf_eax = 5,
> tf_trapno = 12, tf_err = 2, tf_eip = 672026540, tf_cs = 31,
tf_eflags = 642,
> tf_esp = -1077937316, tf_ss = 47}) at ../../i386/i386/trap.c:1073
> #21 0xc023cf26 in Xint0x80_syscall ()
>
> I'm not intimately familiar with the function involved, and I'm out of
> time tonight, so I'm backing up a few days to see if it goes away.
> --
> Christopher Masto Senior Network Monkey NetMonger
Communications
> [EMAIL PROTECTED][EMAIL PROTECTED]
http://www.netmonger.net
>
> Free yourself, free your machine, free the daemon --
http://www.freebsd.org/
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Another current crash (cvs-cur.6183
At 4:14 PM -0800 2000/3/22, Matthew Dillon wrote: > Frankly, I have INVARIANTS (and INVARIANT_SUPPORT) turned on by default > on all of my kernels. If it's this useful and this lightweight, may I suggest that we change the descriptive text around it in the LINT kernel, and copy that over to the GENERIC kernel (although we can turn it off by default)? I likewise made sure I turned it off when I built my new kernel, because of the descriptive text that warned me away. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another current crash (cvs-cur.6183
Doug Barton wrote: > > What kind of overhead does it add? The warning messages in LINT > look rather dire to me, but I'm interested in knowing the facts.. If you run current, by all means, use INVARIANTS. You'll find a few selected persons, some even otherwise respectable, that will tell you otherwise. Ignore them. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another current crash (cvs-cur.6183
:On Wed, 22 Mar 2000, Poul-Henning Kamp wrote: : :> But it might actually make a lot of sense to make INVARIANTS the :> default this early in the -CURRENT cycle, protests ? : : What kind of overhead does it add? The warning messages in LINT :look rather dire to me, but I'm interested in knowing the facts.. : :Doug The overhead is minimal. INVARIANTS was originally put in because DIAGNOSTIC was being too nasty to the system. So nasty, in fact, that it could crash the system all by itself in certain situations. You can think of INVARIANTS as a light-weight non-intrusive version of DIAGNOSTIC. Frankly, I have INVARIANTS (and INVARIANT_SUPPORT) turned on by default on all of my kernels. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another current crash (cvs-cur.6183
On Wed, 22 Mar 2000, Poul-Henning Kamp wrote: > But it might actually make a lot of sense to make INVARIANTS the > default this early in the -CURRENT cycle, protests ? What kind of overhead does it add? The warning messages in LINT look rather dire to me, but I'm interested in knowing the facts.. Doug -- "While the future's there for anyone to change, still you know it seems, it would be easier sometimes to change the past" - Jackson Browne, "Fountain of Sorrow" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another current crash (cvs-cur.6183
Fixed. The swap_pager "knew" that B_WRITE was zero. Not nice. In message <[EMAIL PROTECTED]>, Peter Wemm writes : >Stephen Hocking-Senior Programmer PGS SPS Perth wrote: > >This one you need to tell phk about: this is one of his sanity checks >that trapped and found an insane value. (and then crashed since you didn't >have DDB) > >> #8 0xc0255f21 in Debugger (msg=0xc027b1e8 "d_iocmd botch") >> at machine/cpufunc.h:64 >> #9 0xc017385e in spec_strategy (ap=0xc5988df8) >> at ../../miscfs/specfs/spec_vnops.c:438 >> #10 0xc0173325 in spec_vnoperate (ap=0xc5988df8) >> at ../../miscfs/specfs/spec_vnops.c:117 >> #11 0xc020c3bd in ufs_vnoperatespec (ap=0xc5988df8) >> at ../../ufs/ufs/ufs_vnops.c:2301 >> #12 0xc0219167 in swapdev_strategy (ap=0xc5988e30) at vnode_if.h:923 >> #13 0xc020d80e in swap_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0, >> count=1, sync=0, rtvals=0xc5988e74) at vnode_if.h:923 >> #14 0xc020c427 in default_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0, >> c=1, sync=0, rtvals=0xc5988e74) at ../../vm/default_pager.c:133 >> #15 0xc02175ea in vm_pageout_flush (mc=0xc5988ee0, count=1, flags=0) >> at ../../vm/vm_pager.h:145 >> #16 0xc021754d in vm_pageout_clean (m=0xc0464ae0) at ../../vm/vm_pageout.c:33 >8 >> #17 0xc0217e6e in vm_pageout_scan () at ../../vm/vm_pageout.c:914 >> #18 0xc0218764 in vm_pageout () at ../../vm/vm_pageout.c:1350 >> #19 0xc02565e0 in fork_trampoline () > > >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 > > -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another current crash (cvs-cur.6183
In message <[EMAIL PROTECTED]>, Paul Richards writes:
>Paul Richards wrote:
>>
>>
>> A few more details
>>
>> #11 0xc0167ae6 in biodone (bp=0xc3236250) at ../../kern/vfs_bio.c:2706
>> 2706(*b_iodone) (bp);
>>
>> #10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
>> at ../../vm/vm_page.h:346
>> 346 KASSERT(m->flags & PG_BUSY, ("vm_page_wakeup: page not busy!!!"));
>>
>
>I meant to add, people developing current should have INVARIANTS set and
>then they'd spot panics like these before I do :-)
Paul, what on earth makes you think we don't run with INVARIANTS ? :-)
But it might actually make a lot of sense to make INVARIANTS the
default this early in the -CURRENT cycle, protests ?
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Another current crash (cvs-cur.6183
On Wed, Mar 22, 2000 at 03:02:02AM +, Paul Richards wrote:
> I've got a different but I think related panic.
>
> #9 0xc0143280 in panic (fmt=0xc0250460 "vm_page_wakeup: page not
> busy!!!")
> at ../../kern/kern_shutdown.c:552
> #10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
> at ../../vm/vm_page.h:346
I've been playing around with one of those iopener things and got
myself into a state I thought I could get out of with the help of a
USB Zip drive. Unfortunately, upon purchasing and connecting one,
I discovered that I can't access it without a panic, which I
point out here on the chance it's also related.
#7 0xc024ac2c in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1018879976, tf_esi = 256, tf_ebp = -919618472, tf_isp = -919618500,
tf_ebx = -1071201278, tf_edx = 0, tf_ecx = -1070746656, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1071396739, tf_cs = 8, tf_eflags = 582,
tf_esp = -1071099905, tf_ss = -1071212893}) at ../../i386/i386/trap.c:549
#8 0xc023c87d in Debugger (msg=0xc02696a3 "panic") at machine/cpufunc.h:64
#9 0xc01549e8 in panic (fmt=0xc026c402 "allocbuf: buffer too small")
at ../../kern/kern_shutdown.c:552
#10 0xc0178f5a in allocbuf (bp=0xc3452018, size=83886080) at ../../kern/vfs_bio.c:2346
#11 0xc0178f01 in geteblk (size=83886080) at ../../kern/vfs_bio.c:2315
#12 0xc025cb57 in dsinit (dev=0xc0be1e00, lp=0xc0c490f4, sspp=0xc0c490f0)
at ../../kern/subr_diskmbr.c:186
#13 0xc015eec6 in dsopen (dev=0xc0be1e00, mode=8192, flags=0, sspp=0xc0c490f0,
lp=0xc0c490f4) at ../../kern/subr_diskslice.c:683
#14 0xc015dfbf in diskopen (dev=0xc0be1e00, oflags=1, devtype=8192, p=0xc88be860)
at ../../kern/subr_disk.c:146
#15 0xc018ae65 in spec_open (ap=0xc92fbe10) at ../../miscfs/specfs/spec_vnops.c:191
#16 0xc018ad65 in spec_vnoperate (ap=0xc92fbe10)
at ../../miscfs/specfs/spec_vnops.c:117
#17 0xc01ff2e9 in ufs_vnoperatespec (ap=0xc92fbe10) at ../../ufs/ufs/ufs_vnops.c:2301
#18 0xc018595f in vn_open (ndp=0xc92fbedc, fmode=1, cmode=0) at vnode_if.h:189
#19 0xc0181951 in open (p=0xc88be860, uap=0xc92fbf80) at ../../kern/vfs_syscalls.c:994
#20 0xc024b4ce in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077937212, tf_esi = 134894800, tf_ebp = -1077937132,
tf_isp = -919617580, tf_ebx = 0, tf_edx = 8, tf_ecx = 134894828, tf_eax = 5,
tf_trapno = 12, tf_err = 2, tf_eip = 672026540, tf_cs = 31, tf_eflags = 642,
tf_esp = -1077937316, tf_ss = 47}) at ../../i386/i386/trap.c:1073
#21 0xc023cf26 in Xint0x80_syscall ()
I'm not intimately familiar with the function involved, and I'm out of
time tonight, so I'm backing up a few days to see if it goes away.
--
Christopher Masto Senior Network Monkey NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Another current crash (cvs-cur.6183
Paul Richards wrote:
>
>
> A few more details
>
> #11 0xc0167ae6 in biodone (bp=0xc3236250) at ../../kern/vfs_bio.c:2706
> 2706(*b_iodone) (bp);
>
> #10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
> at ../../vm/vm_page.h:346
> 346 KASSERT(m->flags & PG_BUSY, ("vm_page_wakeup: page not busy!!!"));
>
I meant to add, people developing current should have INVARIANTS set and
then they'd spot panics like these before I do :-)
Paul.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Another current crash (cvs-cur.6183
Stephen Hocking-Senior Programmer PGS SPS Perth wrote:
>
> cvs-cur.6183 appeared to fix the crash I reported under disk activity & NFS
> but another one has reared its face, when using java with tya15 jit, running
> the Together java IDE.
>
> #0 boot (howto=256) at ../../kern/kern_shutdown.c:304
> #1 0xc013d7e5 in panic (fmt=0xc0273534 "from debugger")
> at ../../kern/kern_shutdown.c:554
> #2 0xc01265bd in db_panic (addr=-1071292639, have_addr=0, count=-1,
> modif=0xc5988c64 "") at ../../ddb/db_command.c:433
> #3 0xc012655d in db_command (last_cmdp=0xc02abc2c, cmd_table=0xc02aba8c,
> aux_cmd_tablep=0xc02e4578) at ../../ddb/db_command.c:333
> #4 0xc0126622 in db_command_loop () at ../../ddb/db_command.c:455
> #5 0xc0128733 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
> #6 0xc0255cc1 in kdb_trap (type=3, code=0, regs=0xc5988d6c)
> at ../../i386/i386/db_interface.c:158
> #7 0xc0262690 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0,
> tf_esi = -979913536, tf_ebp = -979857996, tf_isp = -979858024,
> tf_ebx = -1044942540, tf_edx = 0, tf_ecx = -1070604512, tf_eax = 26,
> tf_trapno = 3, tf_err = 0, tf_eip = -1071292639, tf_cs = 8,
> tf_eflags = 12870, tf_esp = -1070994081, tf_ss = -1071140376})
> at ../../i386/i386/trap.c:549
> #8 0xc0255f21 in Debugger (msg=0xc027b1e8 "d_iocmd botch")
I've got a different but I think related panic.
#9 0xc0143280 in panic (fmt=0xc0250460 "vm_page_wakeup: page not
busy!!!")
at ../../kern/kern_shutdown.c:552
#10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
at ../../vm/vm_page.h:346
#11 0xc0167ae6 in biodone (bp=0xc3236250) at ../../kern/vfs_bio.c:2706
#12 0xc0126b8d in dadone (periph=0xc092e380, done_ccb=0xc093f400)
at ../../cam/scsi/scsi_da.c:1230
#13 0xc0122acb in camisr (queue=0xc029def0) at ../../cam/cam_xpt.c:6298
#14 0xc01228dd in swi_cambio () at ../../cam/cam_xpt.c:6201
#15 0xc021188b in doreti_swi ()
A few more details
#11 0xc0167ae6 in biodone (bp=0xc3236250) at ../../kern/vfs_bio.c:2706
2706(*b_iodone) (bp);
#10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
at ../../vm/vm_page.h:346
346 KASSERT(m->flags & PG_BUSY, ("vm_page_wakeup: page not busy!!!"));
I've got the dump if you want more diagnostics. It's hitting the KASSERT
on the second of 16 pages in the buf but none of them have PG_BUSY set
and it's only not panicing on the first page because
bp->b_pager.pg_reqpage is 0 and the call to vm_page_wakeup is skipped.
Paul.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Another current crash (cvs-cur.6183
Stephen Hocking-Senior Programmer PGS SPS Perth wrote: This one you need to tell phk about: this is one of his sanity checks that trapped and found an insane value. (and then crashed since you didn't have DDB) > #8 0xc0255f21 in Debugger (msg=0xc027b1e8 "d_iocmd botch") > at machine/cpufunc.h:64 > #9 0xc017385e in spec_strategy (ap=0xc5988df8) > at ../../miscfs/specfs/spec_vnops.c:438 > #10 0xc0173325 in spec_vnoperate (ap=0xc5988df8) > at ../../miscfs/specfs/spec_vnops.c:117 > #11 0xc020c3bd in ufs_vnoperatespec (ap=0xc5988df8) > at ../../ufs/ufs/ufs_vnops.c:2301 > #12 0xc0219167 in swapdev_strategy (ap=0xc5988e30) at vnode_if.h:923 > #13 0xc020d80e in swap_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0, > count=1, sync=0, rtvals=0xc5988e74) at vnode_if.h:923 > #14 0xc020c427 in default_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0, > c=1, sync=0, rtvals=0xc5988e74) at ../../vm/default_pager.c:133 > #15 0xc02175ea in vm_pageout_flush (mc=0xc5988ee0, count=1, flags=0) > at ../../vm/vm_pager.h:145 > #16 0xc021754d in vm_pageout_clean (m=0xc0464ae0) at ../../vm/vm_pageout.c:33 8 > #17 0xc0217e6e in vm_pageout_scan () at ../../vm/vm_pageout.c:914 > #18 0xc0218764 in vm_pageout () at ../../vm/vm_pageout.c:1350 > #19 0xc02565e0 in fork_trampoline () 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
Another current crash (cvs-cur.6183
cvs-cur.6183 appeared to fix the crash I reported under disk activity & NFS
but another one has reared its face, when using java with tya15 jit, running
the Together java IDE.
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc013d7e5 in panic (fmt=0xc0273534 "from debugger")
at ../../kern/kern_shutdown.c:554
#2 0xc01265bd in db_panic (addr=-1071292639, have_addr=0, count=-1,
modif=0xc5988c64 "") at ../../ddb/db_command.c:433
#3 0xc012655d in db_command (last_cmdp=0xc02abc2c, cmd_table=0xc02aba8c,
aux_cmd_tablep=0xc02e4578) at ../../ddb/db_command.c:333
#4 0xc0126622 in db_command_loop () at ../../ddb/db_command.c:455
#5 0xc0128733 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6 0xc0255cc1 in kdb_trap (type=3, code=0, regs=0xc5988d6c)
at ../../i386/i386/db_interface.c:158
#7 0xc0262690 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = -979913536, tf_ebp = -979857996, tf_isp = -979858024,
tf_ebx = -1044942540, tf_edx = 0, tf_ecx = -1070604512, tf_eax = 26,
tf_trapno = 3, tf_err = 0, tf_eip = -1071292639, tf_cs = 8,
tf_eflags = 12870, tf_esp = -1070994081, tf_ss = -1071140376})
at ../../i386/i386/trap.c:549
#8 0xc0255f21 in Debugger (msg=0xc027b1e8 "d_iocmd botch")
at machine/cpufunc.h:64
#9 0xc017385e in spec_strategy (ap=0xc5988df8)
at ../../miscfs/specfs/spec_vnops.c:438
#10 0xc0173325 in spec_vnoperate (ap=0xc5988df8)
at ../../miscfs/specfs/spec_vnops.c:117
#11 0xc020c3bd in ufs_vnoperatespec (ap=0xc5988df8)
at ../../ufs/ufs/ufs_vnops.c:2301
#12 0xc0219167 in swapdev_strategy (ap=0xc5988e30) at vnode_if.h:923
#13 0xc020d80e in swap_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0,
count=1, sync=0, rtvals=0xc5988e74) at vnode_if.h:923
#14 0xc020c427 in default_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0,
c=1, sync=0, rtvals=0xc5988e74) at ../../vm/default_pager.c:133
#15 0xc02175ea in vm_pageout_flush (mc=0xc5988ee0, count=1, flags=0)
at ../../vm/vm_pager.h:145
#16 0xc021754d in vm_pageout_clean (m=0xc0464ae0) at ../../vm/vm_pageout.c:338
#17 0xc0217e6e in vm_pageout_scan () at ../../vm/vm_pageout.c:914
#18 0xc0218764 in vm_pageout () at ../../vm/vm_pageout.c:1350
#19 0xc02565e0 in fork_trampoline ()
Cannot access memory at address 0xa000.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
