Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-15 Thread Mike Tancsa
On 10/14/2018 2:19 PM, Mateusz Guzik wrote:
> On 10/14/18, Mike Tancsa  wrote:
>> On 10/13/2018 12:48 PM, Allan Jude wrote:
>>> Strange that your crash is in ZFS here...
>>>
>>> Can you take a crash dump?
>>>
>>> It looks like something is trying to write to uninitialized memory here.
>> I will need to pop in another drive or can I do a netdump at this point ?
>>
> This should be fixed with https://svnweb.freebsd.org/changeset/base/339355
> i.e. just update.
>
Thanks, just tried and all is good!


    ---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-14 Thread Mateusz Guzik
On 10/14/18, Mike Tancsa  wrote:
> On 10/13/2018 12:48 PM, Allan Jude wrote:
>>
>> Strange that your crash is in ZFS here...
>>
>> Can you take a crash dump?
>>
>> It looks like something is trying to write to uninitialized memory here.
>
> I will need to pop in another drive or can I do a netdump at this point ?
>

This should be fixed with https://svnweb.freebsd.org/changeset/base/339355
i.e. just update.

-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-14 Thread Mike Tancsa
On 10/13/2018 12:48 PM, Allan Jude wrote:
>
> Strange that your crash is in ZFS here...
>
> Can you take a crash dump?
>
> It looks like something is trying to write to uninitialized memory here. 

I will need to pop in another drive or can I do a netdump at this point ?

    ---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-13 Thread Cy Schubert
In message <8f033c7c-af8f-1ebc-d787-548634f10...@freebsd.org>, Allan 
Jude write
s:
> On 10/12/2018 11:52, Mike Tancsa wrote:
> > I am guessing this does not have anything to do with vmm being loaded,
> > but hardware being initialized in a particular order? If I load vmm in
> > loader.conf, the box panics at boot up.  However, manually loading it
> > all seems to work.  Hardware is PRIME X370-PRO, AMD Ryzen 5 1600X 32G
> > RAM.  FreeBSD 12.0-ALPHA9 r339328 GENERIC-NODEBUG
> > 
> > 
> > Leading up to the crash, I see
> > 
> > 
> > ugen0.1: <0x1022 XHCI root HUB> at usbus0
> > ugen1.1: <0x1b21 XHCI root HUB> at usbus1
> > Trying to mount root from zfs:zroot/ROOT/default []...
> > uhub0: ugen2.1: <0x1022 XHCI root HUB> at usbus2
> > Root mount waiting for: usbus2<0x1022 XHCI root HUB, class 9/0, rev
> > 3.00/1.00, addr 1> on usbus0
> >   usbus1 usbus0
> > uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
> > uhub2: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
> > uhub2: 4 ports with 4 removable, self powered
> > uhub1: 8 ports with 8 removable, self powered
> > uhub0: 22 ports with 22 removable, self powered
> > 
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address   = 0x398
> > fault code              = supervisor write data, page not pres
> ent
> > instruction pointer     = 0x20:0x8273d776
> > stack pointer           = 0x28:0xfe0075d55230
> > frame pointer           = 0x28:0xfe0075d55270
> > code segment            = base 0x0, limit 0xf, type 0x1b
> >                          = DPL 0, pres 1, long 1, de
> f32 0, gran 1
> > processor eflags        = interrupt enabled, resume, IOPL = 0
> > current process         = 1 (kernel)
> > [ thread pid 1 tid 12 ]
> > Stopped at      rrw_enter_read_impl+0x36:       lock cmpxchgq
> > %r14,0x18(%rbx)
> > db> bt
> > Tracing pid 1 tid 12 td 0xf8000567d580
> > rrw_enter_read_impl() at rrw_enter_read_impl+0x36/frame 0xfe0075d55270
> > zfs_mount() at zfs_mount+0x7b2/frame 0xfe0075d55400
> > vfs_domount() at vfs_domount+0x5b2/frame 0xfe0075d55630
> > vfs_donmount() at vfs_donmount+0x930/frame 0xfe0075d556d0
> > kernel_mount() at kernel_mount+0x3d/frame 0xfe0075d55720
> > parse_mount() at parse_mount+0x451/frame 0xfe0075d55860
> > vfs_mountroot() at vfs_mountroot+0x7a0/frame 0xfe0075d559f0
> > start_init() at start_init+0x27/frame 0xfe0075d55a70
> > fork_exit() at fork_exit+0x83/frame 0xfe0075d55ab0
> > fork_trampoline() at fork_trampoline+0xe/frame 0xfe0075d55ab0
> > --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > db>
>
> Strange that your crash is in ZFS here...
>
> Can you take a crash dump?
>
> It looks like something is trying to write to uninitialized memory here.
>

I was digging into this before I left on vacation. You can recreate 
this by,

mount -t zfs tank/nonexistent /mnt

A nonexistent dataset or zpool triggers the panic. I discovered it by 
chance through a typo in fstab. The panic occurs with INVARIANTS. 
Without INVARIANTS results in a hard hang.

I got as far as discovering that f_mntfromname pointed to a null string 
but ran out of time before I left.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-13 Thread Allan Jude

On 10/12/2018 11:52, Mike Tancsa wrote:

I am guessing this does not have anything to do with vmm being loaded,
but hardware being initialized in a particular order? If I load vmm in
loader.conf, the box panics at boot up.  However, manually loading it
all seems to work.  Hardware is PRIME X370-PRO, AMD Ryzen 5 1600X 32G
RAM.  FreeBSD 12.0-ALPHA9 r339328 GENERIC-NODEBUG


Leading up to the crash, I see


ugen0.1: <0x1022 XHCI root HUB> at usbus0
ugen1.1: <0x1b21 XHCI root HUB> at usbus1
Trying to mount root from zfs:zroot/ROOT/default []...
uhub0: ugen2.1: <0x1022 XHCI root HUB> at usbus2
Root mount waiting for: usbus2<0x1022 XHCI root HUB, class 9/0, rev
3.00/1.00, addr 1> on usbus0
  usbus1 usbus0
uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
uhub2: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
uhub2: 4 ports with 4 removable, self powered
uhub1: 8 ports with 8 removable, self powered
uhub0: 22 ports with 22 removable, self powered

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x398
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x8273d776
stack pointer   = 0x28:0xfe0075d55230
frame pointer   = 0x28:0xfe0075d55270
code segment    = base 0x0, limit 0xf, type 0x1b
     = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process = 1 (kernel)
[ thread pid 1 tid 12 ]
Stopped at  rrw_enter_read_impl+0x36:   lock cmpxchgq
%r14,0x18(%rbx)
db> bt
Tracing pid 1 tid 12 td 0xf8000567d580
rrw_enter_read_impl() at rrw_enter_read_impl+0x36/frame 0xfe0075d55270
zfs_mount() at zfs_mount+0x7b2/frame 0xfe0075d55400
vfs_domount() at vfs_domount+0x5b2/frame 0xfe0075d55630
vfs_donmount() at vfs_donmount+0x930/frame 0xfe0075d556d0
kernel_mount() at kernel_mount+0x3d/frame 0xfe0075d55720
parse_mount() at parse_mount+0x451/frame 0xfe0075d55860
vfs_mountroot() at vfs_mountroot+0x7a0/frame 0xfe0075d559f0
start_init() at start_init+0x27/frame 0xfe0075d55a70
fork_exit() at fork_exit+0x83/frame 0xfe0075d55ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0075d55ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
db>


Strange that your crash is in ZFS here...

Can you take a crash dump?

It looks like something is trying to write to uninitialized memory here.



On a normal boot, the next line would be atrtc0

uhub0: Root mount waiting for: usbus2ugen2.1: <0x1022 XHCI root HUB> at usbus2
<0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
  usbus1 usbus0uhub1: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> 
on usbus1

uhub2: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
uhub1: 4 ports with 4 removable, self powered
uhub2: 8 ports with 8 removable, self powered
uhub0: 22 ports with 22 removable, self powered
atrtc0: providing initial system time
start_init: trying /sbin/init
Setting hostuuid: c3297ba0-3f01-11e7-8725-6045cba08a84.
Setting hostid: 0x094fa67e.
Starting file system checks:
Mounting local filesystems:.


snip




---Mike






--
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-12 Thread Mike Tancsa
I am guessing this does not have anything to do with vmm being loaded,
but hardware being initialized in a particular order? If I load vmm in
loader.conf, the box panics at boot up.  However, manually loading it
all seems to work.  Hardware is PRIME X370-PRO, AMD Ryzen 5 1600X 32G
RAM.  FreeBSD 12.0-ALPHA9 r339328 GENERIC-NODEBUG


Leading up to the crash, I see


ugen0.1: <0x1022 XHCI root HUB> at usbus0
ugen1.1: <0x1b21 XHCI root HUB> at usbus1
Trying to mount root from zfs:zroot/ROOT/default []...
uhub0: ugen2.1: <0x1022 XHCI root HUB> at usbus2
Root mount waiting for: usbus2<0x1022 XHCI root HUB, class 9/0, rev
3.00/1.00, addr 1> on usbus0
 usbus1 usbus0
uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
uhub2: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
uhub2: 4 ports with 4 removable, self powered
uhub1: 8 ports with 8 removable, self powered
uhub0: 22 ports with 22 removable, self powered

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x398
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x8273d776
stack pointer   = 0x28:0xfe0075d55230
frame pointer   = 0x28:0xfe0075d55270
code segment    = base 0x0, limit 0xf, type 0x1b
    = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process = 1 (kernel)
[ thread pid 1 tid 12 ]
Stopped at  rrw_enter_read_impl+0x36:   lock cmpxchgq  
%r14,0x18(%rbx)
db> bt
Tracing pid 1 tid 12 td 0xf8000567d580
rrw_enter_read_impl() at rrw_enter_read_impl+0x36/frame 0xfe0075d55270
zfs_mount() at zfs_mount+0x7b2/frame 0xfe0075d55400
vfs_domount() at vfs_domount+0x5b2/frame 0xfe0075d55630
vfs_donmount() at vfs_donmount+0x930/frame 0xfe0075d556d0
kernel_mount() at kernel_mount+0x3d/frame 0xfe0075d55720
parse_mount() at parse_mount+0x451/frame 0xfe0075d55860
vfs_mountroot() at vfs_mountroot+0x7a0/frame 0xfe0075d559f0
start_init() at start_init+0x27/frame 0xfe0075d55a70
fork_exit() at fork_exit+0x83/frame 0xfe0075d55ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0075d55ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
db>

On a normal boot, the next line would be atrtc0

uhub0: Root mount waiting for: usbus2ugen2.1: <0x1022 XHCI root HUB> at usbus2
<0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
 usbus1 usbus0uhub1: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> 
on usbus1

uhub2: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
uhub1: 4 ports with 4 removable, self powered
uhub2: 8 ports with 8 removable, self powered
uhub0: 22 ports with 22 removable, self powered
atrtc0: providing initial system time
start_init: trying /sbin/init
Setting hostuuid: c3297ba0-3f01-11e7-8725-6045cba08a84.
Setting hostid: 0x094fa67e.
Starting file system checks:
Mounting local filesystems:.
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib 
/usr/local/lib/perl5/5.26/mach/CORE
32-bit compatibility ldconfig path: /usr/lib32
Setting hostname: ryzenbsd12.sentex.ca.

Manually loading it, dmesg shows

AMD-Vi: IVRS Info VAsize = 64 PAsize = 48 GVAsize = 2 flags:0
driver bug: Unable to set devclass (class: ppc devname: (unknown))
ivhd0:  on acpi0
ivhd0: Flag:b0
ivhd0: Features(type:0x11) MsiNumPPR = 0 PNBanks= 2 PNCounters= 0
ivhd0: Extended features[31:0]:22294ada HATS = 0x2 
GATS = 0x0 GLXSup = 0x1 SmiFSup = 0x1 SmiFRC = 0x2 GAMSup = 0x1 DualPortLogSup 
= 0x2 DualEventLogSup = 0x2
ivhd0: Extended features[62:32]:f77ef Max PASID: 0x2f DevTblSegSup = 0x3 
MarcSup = 0x1
ivhd0: supported paging level:7, will use only: 4
ivhd0: device range: 0x0 - 0x
ivhd0: PCI cap 0x190b640f@0x40 feature:19

and loading it manually with boot.verbose set

pci0: driver added
found-> vendor=0x1022, dev=0x1451, revid=0x00
domain=0, bus=0, slot=0, func=2
class=08-06-00, hdrtype=0x00, mfdev=1
cmdreg=0x0004, statreg=0x0010, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
MSI supports 4 messages, 64 bit
pci0:0:0:2: reprobing on driver added
found-> vendor=0x1022, dev=0x790b, revid=0x59
domain=0, bus=0, slot=20, func=0
class=0c-05-00, hdrtype=0x00, mfdev=1
cmdreg=0x0403, statreg=0x0220, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
pci0:0:20:0: reprobing on driver added
pci1: driver added
pci2: driver added
pci3: driver added
pci4: driver added
pci5: driver added
pci6: driver added
pci7: driver added
pci8: driver added
pci9: driver added
found-> vendor=0x1425, dev=0x5501, revid=0x00
domain=0, bus=9, slot=0, func=5
class=01-00-00, hdrtype=0x00, mfdev=1
cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
 

Strange panic

2002-10-29 Thread Warner Losh

I'm installing on a pc98 machine (The NEC PC-9821 Nr Lavie).

About 40% into the base install, I got the following panic:

kernel: trap 12 trap, code=0
Stopped at ufs_ihashget+0x70: cmpl 0x30(%eax),%ebx
db tr
ufs_ihashget(c1ee6000,2128,2,c8957854,c4ddc0ae) at ufs_ihashget_0x70
ffs_vget(...) at ffs_vget+0x44
ffs_valloc(...) at ffs_valloc+0x100
ufs_makeinde(...) at ufs_makeinode+0x69
ufs_vnoperate(...) at ufs_vnoperate
vn_open_cred(...) at vn_open_cred+0x19f
vn_open(...) at vn_open+0x29
kern_open(...) at kern_open+0x183
open(...) at open+0x30
syscall

I'm typing this by hand.  This is with -current as of about 8 hours
ago.

Warner

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



Strange panic while dumping userspace core file

2002-05-17 Thread Gavin Atkinson


Hi,

On this machine i'm running -CURRENT from around the end of april, so
apologies if this has already been corrected, however i haven't seen
anything similar reported before. Panic while writing a core file for a
program that died on signal 11. Toshiba laptop, usually perfectly stable,
resumed from suspend about two minutes before and was in the process of
loading KDE... This panic has only ever happened once. there were lots of
errors about calcru being negetive on the console and ATA interrupts
arriving early, immediately before the panic. There was also a brief
arcing type sound from the speakers as KDE loaded, 10 seconds before the
panic. Console log, dmesg and backtrace attached. I'll keep the core file
if anyone wants to see it or wants any information from it.

Gavin


/var/log/messages

May 17 10:16:25 epsilon kernel: wakeup from sleeping state (slept 12:37:54)
May 17 10:16:25 epsilon kernel: ata0: resetting devices .. done
May 17 10:16:25 epsilon kernel: ata1: resetting devices .. done
May 17 10:16:25 epsilon kernel: system power profile changed to 'economy'
May 17 10:16:40 epsilon kernel: ep0: 3Com 3c589 10Mbps Ethernet at port 0x100-0x10f 
irq 11 function 0 config 1 on pccard0
May 17 10:16:40 epsilon kernel: ep0: Ethernet address 00:a0:24:e3:3c:c6
May 17 10:17:21 epsilon kernel: system power profile changed to 'performance'
May 17 10:18:28 epsilon kernel: lock order reversal
May 17 10:18:28 epsilon kernel: 1st 0xc8e08580 pcm0 (sound softc)  
/usr/src/sys/modules/sound/pcm/../../../dev/sound/pcm/sound.c:134
May 17 10:18:28 epsilon kernel: 2nd 0xc8e510c0 pcm0:play:0 (pcm channel)  
/usr/src/sys/modules/sound/pcm/../../../dev/sound/pcm/channel.c:441
May 17 10:18:31 epsilon kernel: calcru: negative time of -388077 usec for pid 2498 
(artsd)
May 17 10:19:37 epsilon kernel: calcru: negative time of -376553 usec for pid 2498 
(artsd)
May 17 10:19:39 epsilon kernel: calcru: negative time of -1491358277 usec for pid 245 
(dnetc)
May 17 10:19:40 epsilon kernel: calcru: negative time of -1491302617 usec for pid 245 
(dnetc)
May 17 10:19:40 epsilon kernel: calcru: negative time of -1491290967 usec for pid 245 
(dnetc)
May 17 10:19:40 epsilon kernel: calcru: negative time of -1491842832 usec for pid 245 
(dnetc)
May 17 10:20:20 epsilon kernel: calcru: negative time of -1492962087 usec for pid 245 
(dnetc)
May 17 10:20:54 epsilon kernel: calcru: negative time of -1492922647 usec for pid 245 
(dnetc)
May 17 10:20:54 epsilon kernel: calcru: negative time of -1493441241 usec for pid 245 
(dnetc)
May 17 10:20:54 epsilon kernel: calcru: negative time of -1493462215 usec for pid 245 
(dnetc)
May 17 10:20:54 epsilon kernel: calcru: negative time of -1493403019 usec for pid 245 
(dnetc)
May 17 10:21:41 epsilon syslogd: kernel boot file is /boot/kernel/kernel
May 17 10:21:41 epsilon kernel: 534 usec for pid 245 (dnetc)
May 17 10:21:41 epsilon kernel: calcru: negative time of -1705561199 usec for pid 245 
(dnetc)
[~100 similar lines snipped]
May 17 10:21:41 epsilon kernel: ad0: READ command timeout tag=0 serv=0 - resetting
May 17 10:21:41 epsilon kernel: ata0: resetting devices .. done
May 17 10:21:41 epsilon kernel: ad0: read interrupt arrived earlyad0: read error 
detected (too) latespec_getpages:(ad0s1g) I/O read failure: (error=5) bp 0xc3ffce70 vp 
0xc939ca50
May 17 10:21:41 epsilon kernel: size: 40960, resid: 16384, a_count: 40960, valid: 0x0
May 17 10:21:41 epsilon kernel: nread: 24576, reqpage: 7, pindex: 79, pcount: 10
May 17 10:21:41 epsilon kernel: vm_fault: pager read error, pid 2503 (kdeinit)
May 17 10:21:41 epsilon kernel: calcru: negative time of -1750099965 usec for pid 245 
(dnetc)
May 17 10:21:41 epsilon kernel: calcru: negative time of -1750645169 usec for pid 245 
(dnetc)
May 17 10:21:41 epsilon kernel: calcru: negative time of -1752260850 usec for pid 245 
(dnetc)
May 17 10:21:41 epsilon kernel: calcru: negative time of -1752238389 usec for pid 245 
(dnetc)
May 17 10:21:41 epsilon kernel: calcru: negative time of -1752822526 usec for pid 245 
(dnetc)
May 17 10:21:41 epsilon kernel: calcru: negative time of -1752717624 usec for pid 245 
(dnetc)
May 17 10:21:41 epsilon kernel: calcru: negative time of -1244498 usec for pid 2498 
(artsd)
May 17 10:21:41 epsilon kernel: calcru: negative time of -1235784 usec for pid 2498 
(artsd)
May 17 10:21:41 epsilon kernel: calcru: negative time of -1753302582 usec for pid 245 
(dnetc)
May 17 10:21:41 epsilon kernel: calcru: negative time of -1753272571 usec for pid 245 
(dnetc)
[~100 similar lines snipped]
May 17 10:21:42 epsilon kernel: ad0: WRITE command timeout tag=0 serv=0 - resetting
May 17 10:21:42 epsilon kernel: ata0: resetting devices .. done
May 17 10:21:42 epsilon kernel: calcru: negative time of -1193253 usec for pid 2498 
(artsd)
May 17 10:21:42 epsilon kernel: calcru: negative time of -1187881 usec for pid 2498 
(artsd)
May 17 10:21:42 epsilon kernel: panic: ffs_clusteralloc: map mismatch
May 17 

Re: Strange panic while dumping userspace core file

2002-05-17 Thread Gavin Atkinson

On Fri, 17 May 2002, Gavin Atkinson wrote:
 Panic while writing a core file for a
 program that died on signal 11. Toshiba laptop, usually perfectly stable,
 resumed from suspend about two minutes before and was in the process of
 loading KDE... This panic has only ever happened once. there were lots of
 errors about calcru being negetive on the console and ATA interrupts
 arriving early, immediately before the panic.

I should probablt also point out that the messages about being unable to
read the hard drive were a one-off. I suspect that they were a symptom of
the overall problems (whatever it is), rather than a cause, although I
realise that ultimately they could be responsible for the panic.

Gavin


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