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.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
