Testing with 2.6.19-rc5

Testing with 2.6.19-rc5

[Andrew Lyon]

Andrew,

You asked me to test if the issues I reported (Re: JMicron 20360/20363
AHCI Controller much slower with 2.6.18 / Re: SATA CD/DVDRW Support in
2.6.18? / Re: Problems with Samsung SH-W163A SATA CD/DVDRW JMicron
20360/20363 2.6.18.1) were still present with 2.6.19-rc5, I tried it
today and ran into a very strange problem, the 4 400gb Samsung SATA
HDs connected to ata_piix were detected as normal but the raid that
they belong to failed to start, the raid system couldnt find any
superblock at all.

Is it possible that the addressing of the sectors has changed such
that the device data structure does not map to the on disk data in the
same way as it did with 2.6.18.x ? unfortunately they drives are not
partitioned, just added straight to the raid, otherwise checking the
partition table would be a good test.

I had a idea about taking a copy of a few kbs of data from each drive
using both kernel versions and comparing them, but if the raid is
started under 2.6.18 its possible the data would change anyway.. so I
dont think that would work.

Any suggestions? I really want to complete testing of the two issues I
reported..

Thanks
Andy

Re: Testing with 2.6.19-rc5

[Andrew Morton]

On Wed, 15 Nov 2006 14:45:27 +0000
"Andrew Lyon" <andrew.lyon@gmail.com> wrote:

> Andrew,
> 
> You asked me to test if the issues I reported (Re: JMicron 20360/20363
> AHCI Controller much slower with 2.6.18 / Re: SATA CD/DVDRW Support in
> 2.6.18? / Re: Problems with Samsung SH-W163A SATA CD/DVDRW JMicron
> 20360/20363 2.6.18.1) were still present with 2.6.19-rc5, I tried it
> today and ran into a very strange problem, the 4 400gb Samsung SATA
> HDs connected to ata_piix were detected as normal but the raid that
> they belong to failed to start, the raid system couldnt find any
> superblock at all.

You mean that the raid works in 2.6.18 but not in 2.6.19-rc5?   Ouch.

What sort of raid setup are you using?

> Is it possible that the addressing of the sectors has changed such
> that the device data structure does not map to the on disk data in the
> same way as it did with 2.6.18.x ?

Sounds unlikely.  More likely we're reading junk from the disks.

> unfortunately they drives are not
> partitioned, just added straight to the raid, otherwise checking the
> partition table would be a good test.
> 
> I had a idea about taking a copy of a few kbs of data from each drive
> using both kernel versions and comparing them,

Good idea.

> but if the raid is
> started under 2.6.18 its possible the data would change anyway.. so I
> dont think that would work.

Do you actually need to start the raid under 2.6.18?  Shut the raid down,
take a copy of the first 32k of each disk, then boto 2.6.19-rc5 and do the
same?

> Any suggestions? I really want to complete testing of the two issues I
> reported..

Thanks.

Re: Testing with 2.6.19-rc5

[Andrew Lyon]

On 11/15/06, Andrew Morton <akpm@osdl.org> wrote:
> On Wed, 15 Nov 2006 14:45:27 +0000
> "Andrew Lyon" <andrew.lyon@gmail.com> wrote:
>
> > Andrew,
> >
> > You asked me to test if the issues I reported (Re: JMicron 20360/20363
> > AHCI Controller much slower with 2.6.18 / Re: SATA CD/DVDRW Support in
> > 2.6.18? / Re: Problems with Samsung SH-W163A SATA CD/DVDRW JMicron
> > 20360/20363 2.6.18.1) were still present with 2.6.19-rc5, I tried it
> > today and ran into a very strange problem, the 4 400gb Samsung SATA
> > HDs connected to ata_piix were detected as normal but the raid that
> > they belong to failed to start, the raid system couldnt find any
> > superblock at all.
>
> You mean that the raid works in 2.6.18 but not in 2.6.19-rc5?   Ouch.

Yes, thats exactly what I mean, the disks are detected but the raid
does not start because no superblocks are found.

> What sort of raid setup are you using?

Raid 5, 4 x 400gb Samsung SATA HDs all connected to ata_piix.

> > Is it possible that the addressing of the sectors has changed such
> > that the device data structure does not map to the on disk data in the
> > same way as it did with 2.6.18.x ?
>
> Sounds unlikely.  More likely we're reading junk from the disks.
>
> > unfortunately they drives are not
> > partitioned, just added straight to the raid, otherwise checking the
> > partition table would be a good test.
> >
> > I had a idea about taking a copy of a few kbs of data from each drive
> > using both kernel versions and comparing them,
>
> Good idea.
>
> > but if the raid is
> > started under 2.6.18 its possible the data would change anyway.. so I
> > dont think that would work.
>
> Do you actually need to start the raid under 2.6.18?  Shut the raid down,
> take a copy of the first 32k of each disk, then boto 2.6.19-rc5 and do the
> same?

Actually you are right, I will disable the raid and do the 32k test as
soon as I can, hopefully tonight.

Andy

>
> > Any suggestions? I really want to complete testing of the two issues I
> > reported..
>
> Thanks.
>

Re: Testing with 2.6.19-rc5

[Andrew Morton]

On Thu, 16 Nov 2006 13:52:28 +0000
"Andrew Lyon" <andrew.lyon@gmail.com> wrote:

> 
> Comparing the first 32k of the 4 disks under 2.6.18.2 and 2.6.19-rc5
> there is no difference, so I decided to compare the bootup dmesg, the
> following text is not output with 2.6.19-rc5:
> 
> md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
> md: bitmap version 4.39
> 
> also missing from 2.6.19-rc5 dmesg:
> 
> md: raidstart(pid 3158) used deprecated START_ARRAY ioctl. This will
> not be supported beyond July 2006
> 
> Might that explain why my raid5 does not work in 2.6.19-rc5 ?

That sounds like a very good theory.

> I have
> attached the full dmesg and kernel config's from both versions, in
> case I have made a error there.
> 
> I am currnetly using raidtools 1.00.3

That appears to be something which Ingo released three and a half years ago ;)
I guess it's time to learn mdadm.