[EMAIL PROTECTED] wrote:
> There have been two changes to HSFS in b78 as far as I remember (the
> readahead speed improvements and the hardlink support), I wouldn't
> associate either with e.g. screwed vfs linkage (as two of these
> stacktraces show), but then, stranger regressions have occurred.
>
> Can you put the bzip2-compressed crashdumps into some accessible location
> so that we can have a look ?
>
> Have cc:'ed ufs-discuss, as that's often used as discussion forum for
> legacy filesystems.
I would like to see the output of
isoinfo -i /dev/dsk/c2t0d0s2 -d
> Thanks,
> FrankH.
>
>
> On Wed, 11 Jun 2008, Kyle McDonald wrote:
>
> > And Again.
> >
> > I don't know enough about the panic dumps to say if they're the same or
> > not, but I've been doing (slightly) different things st the time of each
> > panic.
> >
> > Here's the latest dump:
> >
> > # mount -o ro /dev/dsk/c2t0d0s1 /mnt1
> > Jun 11 17:02:26 Boot ufs: NOTICE: mount: not a UFS magic number (0x6c8)
> > mount: /dev/dsk/c2t0d0s1 is not this fstype
> > # mount -F hsfs /dev/dsk/c2t0d0s1 /mnt1
> > hsfs mount: /dev/dsk/c2t0d0s1 is not an hsfs file system.
> > # mount -o ro /dev/dsk/c2t0d0s2 /mnt1
> > mount: /dev/dsk/c2t0d0s2 is not this fstype
> > # bash
> > bash-3.2# mount -F hsfs -o ro /dev/dsk/c2t0d0s2 /mnt1
> > hsfs mount: /dev/dsk/c2t0d0s2 is not an hsfs file system.
> > bash-3.2# mount -F hsfs -o ro /dev/dsk/c2t0d0s3 /mnt1
> > mount: /dev/dsk/c2t0d0s3 no such device
> > bash-3.2# mount -o ro /dev/dsk/c2t0d0s3 /mnt1
> > mount: I/O error
> > mount: Cannot mount /dev/dsk/c2t0d0s3
> > bash-3.2# mount -o ro /dev/dsk/c2t0d0s4 /mnt1
> > mount: I/O error
> > mount: Cannot mount /dev/dsk/c2t0d0s4
> > bash-3.2# mount -f hsfs -o ro /dev/dsk/c2t0d0s4 /mnt1
> > mount: /dev/dsk/c2t0d0s4 no such device
> > bash-3.2# mount -f hsfs -o ro /dev/dsk/c2t0d0s5 /mnt1
> >
> > panic[cpu2]/thread=ffffff02d573d760: BAD TRAP: type=e (#pf Page fault)
> > rp=ffffff001047d9b0 addr=40 occurred in module "genunix" due to a NULL
> > pointer dereference
> >
> > mount: #pf Page fault
> > Bad kernel fault at addr=0x40
> > pid=1172, pc=0xfffffffffba81ac3, sp=0xffffff001047daa0, eflags=0x10207
> > cr0: 8005003b<pg,wp,ne,et,ts,mp,pe> cr4: 6f8<xmme,fxsr,pge,mce,pae,pse,de>
> > cr2: 40cr3: 22cbb9000cr8: c
> >
> > rdi: fffffffffbca24e0 rsi: 1 rdx: 8
> > rcx: 4 r8: fffffffffbca26b0 r9: 0
> > rax: 0 rbx: 0 rbp: ffffff001047dac0
> > r10: 2700000005 r11: 2c r12: 2700000005
> > r13: 2700000005 r14: ffffff001047db08 r15: 0
> > fsb: 0 gsb: ffffff02d50aaac0 ds: 4b
> > es: 4b fs: 0 gs: 1c3
> > trp: e err: 0 rip: fffffffffba81ac3
> > cs: 30 rfl: 10207 rsp: ffffff001047daa0
> > ss: 38
> >
> > ffffff001047d890 unix:die+c8 ()
> > ffffff001047d9a0 unix:trap+13b1 ()
> > ffffff001047d9b0 unix:cmntrap+e9 ()
> > ffffff001047dac0 genunix:vfs_devismounted+23 ()
> > ffffff001047dbd0 hsfs:hs_getmdev+12b ()
> > ffffff001047dc70 hsfs:hsfs_mount+195 ()
> > ffffff001047dca0 genunix:fsop_mount+21 ()
> > ffffff001047de00 genunix:domount+8fa ()
> > ffffff001047de80 genunix:mount+d2 ()
> > ffffff001047dec0 genunix:syscall_ap+8f ()
> > ffffff001047df10 unix:brand_sys_sysenter+1e6 ()
> >
> > syncing file systems... done
> > dumping to /dev/dsk/c1t0d0s3, offset 431030272, content: kernel
> > 100% done: 260327 pages dumped, compression ratio 5.74, dump succeeded
> > rebooting...
The panic did not directly happen in hsfs ;-)
We did add a lot of checks against into hsfs but not everything can be
100% secure..... but hs_getmdev() does not access the medium, it just
do some kernel consistency checks.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
