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? > > > > r...@tos-backup:~# format > > Searching for disks...Arithmetic Exception (core dumped) > > r...@tos-backup:~# ls -l /dev/rdsk/core > > -rw------- 1 root root 2463431 2010-11-04 17:41 /dev/rdsk/core > > r...@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 > > r...@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 > > r...@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 > > r...@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.swearin...@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.schill...@fokus.fraunhofer.de> wrote: > > > >>>> Roy Sigurd Karlsbakk <r...@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 > > > >>>>>> r...@tos-backup:~# > > > >>>> You need to find out at which source line the integer > > > >>>> division > > > >>>> by > > > >>>> zero > > > >>>> occurs. > > > >>>> > > > >>>> Jörg > > > >>>> > > > >>>> -- > > > >>>> EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg > > > >>>> Schilling > > > >>>> D-13353 > > > >>>> Berlin > > > >>>> j...@cs.tu-berlin.de (uni) > > > >>>> joerg.schill...@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@opensolaris.org > > > >>>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > > >>>> > > > >>> _______________________________________________ > > > >>> zfs-discuss mailing list > > > >>> zfs-discuss@opensolaris.org > > > >>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > > > _______________________________________________ > > > > zfs-discuss mailing list > > > > zfs-discuss@opensolaris.org > > > > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > > _______________________________________________ > > > zfs-discuss mailing list > > > zfs-discuss@opensolaris.org > > > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > > > -- > > Vennlige hilsener / Best regards > > > > roy > > -- > > Roy Sigurd Karlsbakk > > (+47) 97542685 > > r...@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-disc...@openindiana.org > > http://openindiana.org/mailman/listinfo/openindiana-discuss > > -- > Vennlige hilsener / Best regards > > roy > -- > Roy Sigurd Karlsbakk > (+47) 97542685 > r...@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-disc...@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss -- Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 r...@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. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
