[OpenIndiana-discuss] [zfs-discuss] format dumps the core

Roy Sigurd Karlsbakk roy at karlsbakk.net
Wed Nov 10 07:43:29 UTC 2010 

After making zfs filesystems on the bunch, rebooting into OI makes format no-longer dump the core - it works. Seems there might have been something on those drives after all.

roy

----- Original Message -----
> also, this last test was with two 160gig drives only, the 2TB drives
> and the SSD are all disconnected...
> 
> ----- Original Message -----
> > I somehow doubt the problem is the same - looks more like cfgadm
> > can't
> > see my devices. I first tried with directly attached storage (1 SAS
> > cable to each disk). Now, that has been replaced with a SAS expander
> > (4xSAS to the expander, 12 drives on the expander). Format still
> > dumps
> > the core, and cfgadm doesn't seem to like my drives somehow.
> >
> > Any ideas?
> >
> > root at tos-backup:~# format
> > Searching for disks...Arithmetic Exception (core dumped)
> > root at tos-backup:~# ls -l /dev/rdsk/core
> > -rw------- 1 root root 2463431 2010-11-04 17:41 /dev/rdsk/core
> > root at tos-backup:~# pstack /dev/rdsk/core
> > core '/dev/rdsk/core' of 1217: format
> > fee62e4a UDiv (4, 0, 8046c80, 80469a0, 8046a30, 8046a50) + 2a
> > 08079799 auto_sense (4, 0, 8046c80, 0) + 281
> > 080751a6 add_device_to_disklist (80479c0, 80475c0, fefd995b,
> > feffb140)
> > + 62a
> > 080746ff do_search (0, 1, 8047e28, 8066576) + 273
> > 0806658d main (1, 8047e58, 8047e60, 8047e4c) + c1
> > 0805774d _start (1, 8047f00, 0, 8047f07, 8047f0b, 8047f1f) + 7d
> > root at tos-backup:~# zpool status
> > pool: rpool
> > state: ONLINE
> > scan: none requested
> > config:
> >
> > NAME STATE READ WRITE CKSUM
> > rpool ONLINE 0 0 0
> > c4t5000C50019891202d0s0 ONLINE 0 0 0
> >
> > errors: No known data errors
> > root at tos-backup:~# cfgadm -a
> > Ap_Id Type Receptacle Occupant Condition
> > c6 scsi-sas connected configured unknown
> > c6::es/ses0 ESI connected configured unknown
> > c6::smp/expd0 smp connected configured unknown
> > c6::w5000c50019891202,0 disk-path connected configured unknown
> > c6::w5000c50019890fed,0 disk-path connected configured unknown
> > c7 scsi-sas connected unconfigured unknown
> > usb8/1 unknown empty unconfigured ok
> > usb8/2 unknown empty unconfigured ok
> > usb9/1 unknown empty unconfigured ok
> > usb9/2 usb-device connected configured ok
> > usb10/1 unknown empty unconfigured ok
> > usb10/2 unknown empty unconfigured ok
> > usb10/3 unknown empty unconfigured ok
> > usb10/4 unknown empty unconfigured ok
> > usb11/1 unknown empty unconfigured ok
> > usb11/2 unknown empty unconfigured ok
> > usb12/1 unknown empty unconfigured ok
> > usb12/2 unknown empty unconfigured ok
> > usb13/1 unknown empty unconfigured ok
> > usb13/2 unknown empty unconfigured ok
> > usb14/1 usb-hub connected configured ok
> > usb14/1.1 unknown empty unconfigured ok
> > usb14/1.2 unknown empty unconfigured ok
> > usb14/1.3 usb-hub connected configured ok
> > usb14/1.3.1 usb-device connected configured ok
> > usb14/1.3.2 unknown empty unconfigured ok
> > usb14/1.3.3 unknown empty unconfigured ok
> > usb14/1.3.4 unknown empty unconfigured ok
> > usb14/1.4 unknown empty unconfigured ok
> > usb14/2 unknown empty unconfigured ok
> > usb14/3 unknown empty unconfigured ok
> > usb14/4 unknown empty unconfigured ok
> > usb14/5 unknown empty unconfigured ok
> > usb14/6 unknown empty unconfigured ok
> > root at tos-backup:~#
> >
> >
> > ----- Original Message -----
> > > Moazam,
> > >
> > > Thanks for the update. I hope this is Roy's issue too.
> > >
> > > I can see that format would freak out over ext3, but it
> > > shouldn't core dump.
> > >
> > > Cindy
> > >
> > > On 11/02/10 17:00, Moazam Raja wrote:
> > > > Fixed!
> > > >
> > > > It turns out the problem was that we pulled these two disks from
> > > > a
> > > > Linux box and they were formatted with ext3 on partition 0 for
> > > > the
> > > > whole disk, which was somehow causing 'format' to freak out.
> > > >
> > > > So, we fdisk'ed the p0 slice to delete the Linux partition and
> > > > then
> > > > created a SOLARIS2 type partition on it. It worked and no more
> > > > crash
> > > > during format command.
> > > >
> > > > Cindy, please let the format team know about this since I'm sure
> > > > others will also run into this problem at some point if they
> > > > have
> > > > a
> > > > mixed Linux/Solaris environment.
> > > >
> > > >
> > > > -Moazam
> > > >
> > > > On Tue, Nov 2, 2010 at 3:15 PM, Cindy Swearingen
> > > > <cindy.swearingen at oracle.com> wrote:
> > > >> Hi Moazam,
> > > >>
> > > >> The initial diagnosis is that the LSI controller is reporting
> > > >> bogus
> > > >> information. It looks like Roy is using a similar controller.
> > > >>
> > > >> You might report this problem to LSI, but I will pass this
> > > >> issue
> > > >> along to the format folks.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Cindy
> > > >>
> > > >> On 11/02/10 15:26, Moazam Raja wrote:
> > > >>> I'm having the same problem after adding 2 SSD disks to my
> > > >>> machine.
> > > >>> The controller is LSI SAS9211-8i PCI Express.
> > > >>>
> > > >>> # format
> > > >>> Searching for disks...Arithmetic Exception (core dumped)
> > > >>>
> > > >>>
> > > >>>
> > > >>> # pstack core.format.1016
> > > >>> core 'core.format.1016' of 1016: format
> > > >>>  fee62e4a UDiv (4, 0, 8046bf0, 8046910, 80469a0, 80469c0) + 2a
> > > >>>  08079799 auto_sense (4, 0, 8046bf0, 1c8) + 281
> > > >>>  080751a6 add_device_to_disklist (8047930, 8047530, feffb8f4,
> > > >>>  804716c) +
> > > >>> 62a
> > > >>>  080746ff do_search (0, 1, 8047d98, 8066576) + 273
> > > >>>  0806658d main (1, 8047dd0, 8047dd8, 8047d8c) + c1
> > > >>>  0805774d _start (1, 8047e88, 0, 8047e8f, 8047e99, 8047ead) +
> > > >>>  7d
> > > >>>
> > > >>>
> > > >>> I'm on b147.
> > > >>>
> > > >>> # uname -a
> > > >>> SunOS geneva5 5.11 oi_147 i86pc i386 i86pc Solaris
> > > >>>
> > > >>>
> > > >>> On Tue, Nov 2, 2010 at 7:17 AM, Joerg Schilling
> > > >>> <Joerg.Schilling at fokus.fraunhofer.de> wrote:
> > > >>>> Roy Sigurd Karlsbakk <roy at karlsbakk.net> wrote:
> > > >>>>
> > > >>>>> Hi all
> > > >>>>>
> > > >>>>> (crossposting to zfs-discuss)
> > > >>>>>
> > > >>>>> This error also seems to occur on osol 134. Any idea what
> > > >>>>> this
> > > >>>>> might be?
> > > >>>>>
> > > >>>>>> ioctl(4, USCSICMD, 0x08046910) = 0
> > > >>>>>> ioctl(4, USCSICMD, 0x08046900) = 0
> > > >>>>>> ioctl(4, USCSICMD, 0x08046570) = 0
> > > >>>>>> ioctl(4, USCSICMD, 0x08046570) = 0
> > > >>>>>> Incurred fault #8, FLTIZDIV %pc = 0xFEE62E4A
> > > >>>>>> siginfo: SIGFPE FPE_INTDIV addr=0xFEE62E4A
> > > >>>>>> Received signal #8, SIGFPE [default]
> > > >>>>>> siginfo: SIGFPE FPE_INTDIV addr=0xFEE62E4A
> > > >>>>>> root at tos-backup:~#
> > > >>>> You need to find out at which source line the integer
> > > >>>> division
> > > >>>> by
> > > >>>> zero
> > > >>>> occurs.
> > > >>>>
> > > >>>> Jörg
> > > >>>>
> > > >>>> --
> > > >>>>  EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg
> > > >>>>  Schilling
> > > >>>>  D-13353
> > > >>>> Berlin
> > > >>>>      js at cs.tu-berlin.de (uni)
> > > >>>>      joerg.schilling at fokus.fraunhofer.de (work) Blog:
> > > >>>> http://schily.blogspot.com/
> > > >>>>  URL: http://cdrecord.berlios.de/private/
> > > >>>> ftp://ftp.berlios.de/pub/schily
> > > >>>> _______________________________________________
> > > >>>> zfs-discuss mailing list
> > > >>>> zfs-discuss at opensolaris.org
> > > >>>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> > > >>>>
> > > >>> _______________________________________________
> > > >>> zfs-discuss mailing list
> > > >>> zfs-discuss at opensolaris.org
> > > >>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> > > > _______________________________________________
> > > > zfs-discuss mailing list
> > > > zfs-discuss at opensolaris.org
> > > > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> > > _______________________________________________
> > > zfs-discuss mailing list
> > > zfs-discuss at opensolaris.org
> > > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> >
> > --
> > Vennlige hilsener / Best regards
> >
> > roy
> > --
> > Roy Sigurd Karlsbakk
> > (+47) 97542685
> > roy at karlsbakk.net
> > http://blogg.karlsbakk.net/
> > --
> > I all pedagogikk er det essensielt at pensum presenteres
> > intelligibelt. Det er et elementært imperativ for alle pedagoger å
> > unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de
> > fleste tilfeller eksisterer adekvate og relevante synonymer på
> > norsk.
> >
> > _______________________________________________
> > OpenIndiana-discuss mailing list
> > OpenIndiana-discuss at openindiana.org
> > http://openindiana.org/mailman/listinfo/openindiana-discuss
> 
> --
> Vennlige hilsener / Best regards
> 
> roy
> --
> Roy Sigurd Karlsbakk
> (+47) 97542685
> roy at karlsbakk.net
> http://blogg.karlsbakk.net/
> --
> I all pedagogikk er det essensielt at pensum presenteres
> intelligibelt. Det er et elementært imperativ for alle pedagoger å
> unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de
> fleste tilfeller eksisterer adekvate og relevante synonymer på norsk.
> 
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss

-- 
Vennlige hilsener / Best regards

roy
--
Roy Sigurd Karlsbakk
(+47) 97542685
roy at karlsbakk.net
http://blogg.karlsbakk.net/
--
I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk.

More information about the OpenIndiana-discuss mailing list