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
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 ar
> 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
> ...
Seems that one function call is missing in the back trace
between auto_sense and UDiv, because U
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
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 cfg
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
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 par
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 h
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
Roy Sigurd Karlsbakk 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, 0x08046
> > 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 att
> - Original Message -
...
> > r...@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
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
13 matches
Mail list logo
