ATA update

ATA update

[Marco Gerards]

Hi,

One minute ago I committed a patch to improve ATA support.

The new stuff:

- It isn't very slow anymore
- It even works for Robert ;-)
- It works on QEmu
- The error handling significantly improved
- Added timeouts, so ata.mod does not endlessly wait for nothing
- Detected controllers are all actually used
- More random fixes

I hope that this encourages people to test ATA support again (at your
own risk) and fix things that are still broken.  An overview of which
hardware (chipsets) do and do not work will be very nice to have!

The next thing I will do now is split up ATAPI support.  I have some
code in that direction already, so you might not want to touch that
now.

--
Marco

Re: ATA update

[Felix Zielcke]

Hello,

Am Freitag, den 08.08.2008, 01:46 +0200 schrieb Marco Gerards:
> Hi,
> 
> One minute ago I committed a patch to improve ATA support.
> 
Probable better if I just send you know a mail instead of telling on
IRC:

This is shown for device 4,0 and 4,1
PCI Dev (0,8,0) compat=1 rega=0x9e0=regb=0xbe0

My first SATA RAID Disk is fully recognized i.e. it shows the
ST3808110AS name and Firmware 2AAA which I can find in dmesg.

For device 4,1 it only shows "ATA detected" but nothing more, it goes
then to device 5,0.

ls (ata8) shows partition table
ls (ata8,1) or (ata8,2) unknown filesystem

But that's probable right, if your ata.mod works more then Linux instead
of the biosdisk.mod which works more then yeah BIOS ;)

I just tried to mount /dev/sda1 which is NTFS and syslog shows $MFT
corrupted (ntfs-3g).

So I hope that GRUB will still have the biosdisk.mod for guys like me on
a dmraid (in Linux terms) or fake hardware motherboard RAID ;)

Re: ATA update

[Marco Gerards]

Hi Felix,

Felix Zielcke <fzielcke@z-51.de> writes:

>> One minute ago I committed a patch to improve ATA support.
>> 
> Probable better if I just send you know a mail instead of telling on
> IRC:
>
> This is shown for device 4,0 and 4,1
> PCI Dev (0,8,0) compat=1 rega=0x9e0=regb=0xbe0
>
> My first SATA RAID Disk is fully recognized i.e. it shows the
> ST3808110AS name and Firmware 2AAA which I can find in dmesg.
>
> For device 4,1 it only shows "ATA detected" but nothing more, it goes
> then to device 5,0.

Most likely something failed in grub_ata_identify.  you might want to
add more debugging information there.

> ls (ata8) shows partition table
> ls (ata8,1) or (ata8,2) unknown filesystem

Can grub-emu deal with these filesystems?

> But that's probable right, if your ata.mod works more then Linux instead
> of the biosdisk.mod which works more then yeah BIOS ;)

Hm?

> I just tried to mount /dev/sda1 which is NTFS and syslog shows $MFT
> corrupted (ntfs-3g).

Also on biosdisk.

> So I hope that GRUB will still have the biosdisk.mod for guys like me on
> a dmraid (in Linux terms) or fake hardware motherboard RAID ;)

Yes.

--
Marco

Re: ATA update

[Felix Zielcke]

Hello Marco,

Am Freitag, den 08.08.2008, 11:17 +0200 schrieb Marco Gerards:
> Hi Felix,

> 
> Most likely something failed in grub_ata_identify.  you might want to
> add more debugging information there.

Ok I try.

> > ls (ata8) shows partition table
> > ls (ata8,1) or (ata8,2) unknown filesystem
> 
> Can grub-emu deal with these filesystems?

No it says unknown fs, too.

> > But that's probable right, if your ata.mod works more then Linux instead
> > of the biosdisk.mod which works more then yeah BIOS ;)
> 
> Hm?
> 
> > I just tried to mount /dev/sda1 which is NTFS and syslog shows $MFT
> > corrupted (ntfs-3g).
> 
> Also on biosdisk.

I currently always boot directly from my Raid 0
GRUB + Vista bootmgr + Vista \Windows\ is on Raid 0 
my Linux / and so /boot is on my PATA disk.
This works totally fine for booting Vista and Linux.

With biosdisk.mod there's just (hd0) wich are both harddisks for the
raid0
ls (hd0,1)/ shows everything from my NTFS raid0
(hd1) is then my IDE disk.
There's no (hd2)

The BIOS itself can handle the RAID 0 for booting fine.
But as soon as you're in Linux or Windows the OS needs to care about it.
Linux still shows sda and sdb, but that doestn't work right.
I need dmraid so I have one /dev/mapper/nvidia_cediideh1 which I can
mount fine.

This is RAID 0 with chunksize 256 KB, so the first 256 KB of the
combined disks is on disk 0
But NTFS hasn't it's $MFT just on the first 256 KB
The second partition of it is a small ext3, but maybe it just begins on
the second disk.

Re: ATA update

[Felix Zielcke]

> 
> I currently always boot directly from my Raid 0
> GRUB + Vista bootmgr + Vista \Windows\ is on Raid 0 
> my Linux / and so /boot is on my PATA disk.
> This works totally fine for booting Vista and Linux.
> 

Oh and I forgot the Vista bootmgr file is 326 KB big,
so even with my (probable big) chunksize of 256 KB this file lies on
both disks.
So for booting Vista it's essential to handle the RAID 0.
I can try to copy my /boot to the ext3 partition I already have there.
Maybe with biosdisk this even works with GRUB + Linux :)

Re: ATA update

[Marco Gerards]

Felix Zielcke <fzielcke@z-51.de> writes:

>> I currently always boot directly from my Raid 0
>> GRUB + Vista bootmgr + Vista \Windows\ is on Raid 0 
>> my Linux / and so /boot is on my PATA disk.
>> This works totally fine for booting Vista and Linux.
>
> Oh and I forgot the Vista bootmgr file is 326 KB big,
> so even with my (probable big) chunksize of 256 KB this file lies on
> both disks.

Can't raid.mod be used for this, somehow?

--
Marco

Re: ATA update

[Felix Zielcke]

Am Freitag, den 08.08.2008, 11:55 +0200 schrieb Marco Gerards:

> 
> Can't raid.mod be used for this, somehow?

I had this talk already with Bean on IRC.

At least the Nvidia nForce chipsets RAIDs have stored their 512 byte
superblock in (end of disks) - 1024 bytes.
The last 512 Bytes of both disks just contain zeroes.

dmraid searches all disks for these superblocks it supports.
So it is possible to implement this.
Althoguh i don't know if raid.mod should be renamed to mdraid.mod and
there should be a new dmraid.mod

But that probable confuses people
The raid.mod needs an overhaul anyway if the super 1.x format should be
implemented, because the 1.x ones store there superblock at different
positions of the disks not always at the same position where the current
default 0.90 stores it.