Roy Sigurd Karlsbakk
2010-Oct-29 10:02 UTC
[zfs-discuss] [OpenIndiana-discuss] format dumps the core
Hi all (crossposting to zfs-discuss) This error also seems to occur on osol 134. Any idea what this might be? roy ----- Original Message -----> hi all > > any idea about this? it''s a new box with a Supermicro X8DTH-i/6/iF/6F > with a E5620 CPU, 24 gigs of RAM and a bunch of Black drives. The > installer found the drives, but now: > > root at tos-backup:~# format > Searching for disks...Arithmetic Exception (core dumped) > > The controllers are ''LSI SAS9211-8i SAS 2.0 8-port HBA'' > > any idea? should I try osol instead? > > == truss output (the last lines) => open("/dev/rdsk/c0t0d0s2", O_RDWR|O_NDELAY) Err#2 ENOENT > open("/dev/rdsk/c0t1d0s2", O_RDWR|O_NDELAY) Err#2 ENOENT > open("/dev/rdsk/c1t0d0s2", O_RDWR|O_NDELAY) Err#2 ENOENT > open("/dev/rdsk/c2t0d0s2", O_RDWR|O_NDELAY) Err#2 ENOENT > open("/dev/rdsk/c2t0d1s2", O_RDWR|O_NDELAY) Err#2 ENOENT > open("/dev/rdsk/c3t0d0s2", O_RDWR|O_NDELAY) Err#2 ENOENT > open("/dev/rdsk/c4t5000C50019890FEDd0s2", O_RDWR|O_NDELAY) = 4 > fstat(4, 0x08046B90) = 0 > ioctl(4, DKIOCINFO, 0x08046C20) = 0 > ioctl(4, DKIOCREMOVABLE, 0x08046B8C) = 0 > ioctl(4, DKIOCGMEDIAINFO, 0x08046C70) = 0 > stat64("/lib/libadm.so.1", 0x08045DC8) = 0 > resolvepath("/lib/libadm.so.1", "/lib/libadm.so.1", 1023) = 16 > open("/lib/libadm.so.1", O_RDONLY) = 5 > mmapobj(5, MMOBJ_INTERPRET, 0xFEE20888, 0x08045E34, 0x00000000) = 0 > close(5) = 0 > memcntl(0xFEDE0000, 16068, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 > ioctl(4, DKIOCGEXTVTOC, 0x08046850) = 0 > getcwd("/dev/rdsk", 1024) = 0 > chdir("/dev/rdsk") = 0 > stat("/dev/rdsk/c4t5000C50019890FEDd0s2", 0x080462C0) = 0 > lstat("/dev/rdsk/c4t5000C50019890FEDd0s2", 0x080462C0) = 0 > readlink("/dev/rdsk/c4t5000C50019890FEDd0s2", > "../../devices/scsi_vhci/disk at g5000c50019890fed:c,raw", 1024) = 52 > chdir("../../devices/scsi_vhci") = 0 > stat("disk at g5000c50019890fed:c,raw", 0x080462C0) = 0 > lstat("disk at g5000c50019890fed:c,raw", 0x080462C0) = 0 > getcwd("/devices/scsi_vhci", 1024) = 0 > chdir("/dev/rdsk") = 0 > ioctl(4, DKIOCGEXTVTOC, 0x080467D0) = 0 > ioctl(4, USCSICMD, 0x08046910) = 0 > 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:~# > > -- > 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.
Jürgen Keil
2010-Oct-31 11:27 UTC
[zfs-discuss] [OpenIndiana-discuss] format dumps the core
> ----- Original Message -----...> > root at tos-backup:~# format > > Searching for disks...Arithmetic Exception (core dumped)> This error also seems to occur on osol 134. Any idea > what this might be?What stack backtrace is reported for that core dump ("pstack core") ? -- This message posted from opensolaris.org
Roy Sigurd Karlsbakk
2010-Oct-31 14:52 UTC
[zfs-discuss] [OpenIndiana-discuss] format dumps the core
> > This error also seems to occur on osol 134. Any idea > > what this might be? > > What stack backtrace is reported for that core dump ("pstack core") ?I couldn''t find the core file - anyway, there was some messup with the device numbering and the box has been sent off for service (direct attached device numbering on this SAS board, with this backplane, seemed to have messed things up, so thay''re installing a SAS expander instead) 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.
Joerg Schilling
2010-Nov-02 14:17 UTC
[zfs-discuss] [OpenIndiana-discuss] format dumps the core
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
Christian Walther
2010-Nov-02 15:21 UTC
[zfs-discuss] [OpenIndiana-discuss] format dumps the core
Hi,
This may seem odd, but I had errors just like this coming from a
faulty CD ROM drive.
The drive in question was unable to read the entire media, resulting
in the following:
1. Live CD boots up fine, probably took longer than expected.
Installation appears to be successful, some drive related error
messages show up in /var/adm/messages. Several commands on the
installed machine don''t work, lots of empty or truncated files.
2. Live CD boots up fine, but several commands (including format)
crash with a variety of error messages. Running find /usr /lib -type f
-exec cat {} >/dev/null \; results in more error messages.
(1) happened with Osol134, (2) with OI. Changing the drive fixed both
issues. Yes, I meanwhile have thrown the drive question away.
HTH
Christian Walther
Moazam Raja
2010-Nov-02 21:26 UTC
[zfs-discuss] [OpenIndiana-discuss] format dumps the core
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 >
Cindy Swearingen
2010-Nov-02 22:15 UTC
[zfs-discuss] [OpenIndiana-discuss] format dumps the core
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
Moazam Raja
2010-Nov-02 23:00 UTC
[zfs-discuss] [OpenIndiana-discuss] format dumps the core
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 >
Cindy Swearingen
2010-Nov-03 14:10 UTC
[zfs-discuss] [OpenIndiana-discuss] format dumps the core
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
Roy Sigurd Karlsbakk
2010-Nov-04 16:45 UTC
[zfs-discuss] [OpenIndiana-discuss] format dumps the core
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.
Roy Sigurd Karlsbakk
2010-Nov-04 16:56 UTC
[zfs-discuss] [OpenIndiana-discuss] format dumps the core
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.
Jürgen Keil
2010-Nov-06 21:11 UTC
[zfs-discuss] [OpenIndiana-discuss] format dumps the 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 > ...Seems that one function call is missing in the back trace between auto_sense and UDiv, because UDiv does not setup a complete stack frame. Looking at the source ... http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/format/auto_sense.c#819 ... you can get some extra debug output from format when you specify the "-M" option. E.g. with an usb flash memory stick and format -eM I get # format -eM Searching for disks... c11t0d0: attempting auto configuration Inquiry: 00 80 02 02 1f 00 00 00 53 61 6e 44 69 73 6b 20 ........SanDisk 55 33 20 43 6f 6e 74 6f 75 72 20 20 20 20 20 20 U3 Contour 34 2e 30 4.0 Product id: U3 Contour Capacity: 00 7a 46 90 00 00 02 00 blocks: 8013456 (0x7a4690) blksize: 512 disk name: `r ` Request sense for command mode sense failed Sense data: f0 00 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Mode sense page 0x3 failed Request sense for command mode sense failed Sense data: f0 00 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Mode sense page 0x4 failed Geometry: pcyl: 1956 ncyl: 1954 heads: 128 nsects: 32 acyl: 2 bcyl: 0 rpm: 0 nblocks: 8013457 The current rpm value 0 is invalid, adjusting it to 3600 Geometry after adjusting for capacity: pcyl: 1956 ncyl: 1954 heads: 128 nsects: 32 acyl: 2 rpm: 3600 Partition 0: 128.00MB 64 cylinders Partition 1: 128.00MB 64 cylinders Partition 2: 3.82GB 1956 cylinders Partition 6: 3.56GB 1825 cylinders Partition 8: 2.00MB 1 cylinders Inquiry: 00 00 03 02 1f 00 00 02 41 54 41 20 20 20 20 20 ........ATA 48 69 74 61 63 68 69 20 48 54 53 37 32 33 32 33 Hitachi HTS72323 43 33 30 C30 done c11t0d0: configured with capacity of 3.82GB -- This message posted from opensolaris.org
Roy Sigurd Karlsbakk
2010-Nov-10 07:43 UTC
[zfs-discuss] [OpenIndiana-discuss] format dumps the core
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.