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

Reply via email to