Re: Looking for a PCI (not PCIe) card for (non-raid) SATA that is compatible with PowerMac G4

[Rick Thomas]

Or, if not with the firmware installed, where can I find instructions for 
installing the firmware?
Thanks again,
Rick

On Fri, Jul 17, 2020, at 6:11 PM, Rick Thomas wrote:
> Sounds great!
> 
> Now, where can I buy one of these cards -- hopefully with the new firmware 
> already installed.
> And where can I find instructions for including the driver module in my 
> Debian Jessie kernel?
> 
> Thanks!
> Rick
> 
> On Thu, Jul 16, 2020, at 5:23 AM, luigi burdo wrote:
>> Hello,
>>  i can say for sure this card is already compatible with linux ppc. 
>> The only thing necessary is have a kernel with the board included as a mod.
>> The card will starting work after the kernel load in yaboot or grub...  (i 
>> had been used it on amiga pci machine)
>> I have a Marvell pcie in My G5 Quad working as the same phylosophy as i 
>> described before.
>> The same is fo all card and device. GPU usb3 and so and so.
>> 
>> Ciao 
>> Gigi Burdo
>> 
>> 
>> 
>> *Da:* Romain Dolbeau 
>> *Inviato:* giovedì 16 luglio 2020 13:45
>> *A:* Rick Thomas 
>> *Cc:* PowerPC List Debian 
>> *Oggetto:* Re: Looking for a PCI (not PCIe) card for (non-raid) SATA that is 
>> compatible with PowerMac G4
>>  
>> Le mer. 15 juil. 2020 à 12:46, Romain Dolbeau  a écrit :
>> > You need to locate a SIL3112 (or in a pinch, SIL3114 can do) based PCI
>> > SATA card and flash it with a Fcode BIOS
>> 
>> Apparently, there is an ongoing effort to create a new firmware for
>> the family of chips, which should make G4 users' life easier :-)
>> 
>> <http://macos9lives.com/smforum/index.php/topic,5534.0.html>
>> 
>> Cordially,
>> 
>> -- 
>> Romain Dolbeau
>> 
> 

Re: Looking for a PCI (not PCIe) card for (non-raid) SATA that is compatible with PowerMac G4

[Rick Thomas]

Sounds great!

Now, where can I buy one of these cards -- hopefully with the new firmware 
already installed.
And where can I find instructions for including the driver module in my Debian 
Jessie kernel?

Thanks!
Rick

On Thu, Jul 16, 2020, at 5:23 AM, luigi burdo wrote:
> Hello,
>  i can say for sure this card is already compatible with linux ppc. 
> The only thing necessary is have a kernel with the board included as a mod.
> The card will starting work after the kernel load in yaboot or grub...  (i 
> had been used it on amiga pci machine)
> I have a Marvell pcie in My G5 Quad working as the same phylosophy as i 
> described before.
> The same is fo all card and device. GPU usb3 and so and so.
> 
> Ciao 
> Gigi Burdo
> 
> 
> 
> *Da:* Romain Dolbeau 
> *Inviato:* giovedì 16 luglio 2020 13:45
> *A:* Rick Thomas 
> *Cc:* PowerPC List Debian 
> *Oggetto:* Re: Looking for a PCI (not PCIe) card for (non-raid) SATA that is 
> compatible with PowerMac G4 
>  
> Le mer. 15 juil. 2020 à 12:46, Romain Dolbeau  a écrit :
>  > You need to locate a SIL3112 (or in a pinch, SIL3114 can do) based PCI
>  > SATA card and flash it with a Fcode BIOS
> 
>  Apparently, there is an ongoing effort to create a new firmware for
>  the family of chips, which should make G4 users' life easier :-)
> 
>  <http://macos9lives.com/smforum/index.php/topic,5534.0.html>
> 
>  Cordially,
> 
>  -- 
>  Romain Dolbeau
> 

R: Looking for a PCI (not PCIe) card for (non-raid) SATA that is compatible with PowerMac G4

[luigi burdo]

Hello,
 i can say for sure this card is already compatible with linux ppc.
The only thing necessary is have a kernel with the board included as a mod.
The card will starting work after the kernel load in yaboot or grub...  (i had 
been used it on amiga pci machine)
I have a Marvell pcie in My G5 Quad working as the same phylosophy as i 
described before.
The same is fo all card and device. GPU usb3 and so and so.

Ciao
Gigi Burdo


Da: Romain Dolbeau 
Inviato: giovedì 16 luglio 2020 13:45
A: Rick Thomas 
Cc: PowerPC List Debian 
Oggetto: Re: Looking for a PCI (not PCIe) card for (non-raid) SATA that is 
compatible with PowerMac G4

Le mer. 15 juil. 2020 à 12:46, Romain Dolbeau  a écrit :
> You need to locate a SIL3112 (or in a pinch, SIL3114 can do) based PCI
> SATA card and flash it with a Fcode BIOS

Apparently, there is an ongoing effort to create a new firmware for
the family of chips, which should make G4 users' life easier :-)

<http://macos9lives.com/smforum/index.php/topic,5534.0.html>

Cordially,

--
Romain Dolbeau

Re: Looking for a PCI (not PCIe) card for (non-raid) SATA that is compatible with PowerMac G4

[Romain Dolbeau]

Le mer. 15 juil. 2020 à 12:46, Romain Dolbeau  a écrit :
> You need to locate a SIL3112 (or in a pinch, SIL3114 can do) based PCI
> SATA card and flash it with a Fcode BIOS

Apparently, there is an ongoing effort to create a new firmware for
the family of chips, which should make G4 users' life easier :-)



Cordially,

-- 
Romain Dolbeau

Re: Looking for a PCI (not PCIe) card for (non-raid) SATA that is compatible with PowerMac G4

[Jeroen Diederen]

https://discussions.apple.com/thread/1928371

Re: Looking for a PCI (not PCIe) card for (non-raid) SATA that is compatible with PowerMac G4

[Romain Dolbeau]

Le mer. 15 juil. 2020 à 12:27, Rick Thomas  a écrit :
> I have an old PowerMac G4 "Silver" (PowerMac3,4 533 MHz) running Debian 
> Jessie, that I'd like to put a couple of SATA disks into.

That's a desire shared by many people, unfortunately with few good answers.

You need to locate a SIL3112 (or in a pinch, SIL3114 can do) based PCI
SATA card and flash it with a Fcode BIOS that was originally designed
for a mac-oriented card. Details and links (of questionable legitimacy
as the Fcode is probably still copyrighted) can be found on some Mac
forums - or at least in their archives. I have a SIL3114 booting 10.5
in a G4 FW800.

I've successfully made a PCIe LSI1068e boot from a SAS drive in a PCIe
G5, and a similar procedure should work for PCI-X LSI1068/1064 in a
PCI-X G5 (see 
and ).
However, those PCI-X cards are 3.3V only. Unless you can locate a 5V
PCI[-X] card with a LSI1064/1068, it won't help in a G4 as its PCI
slots are 5V only. I have _never_ seen a 5V LSI1064/1068 (and I've
looked for my G4s!), so the SIL311[24] way is the only credible
solution that I know of :-(


Cordially,

-- 
Romain Dolbeau

Re: Looking for a PCI (not PCIe) card for (non-raid) SATA that is compatible with PowerMac G4

[Jeroen Diederen]

Hi Rick,

I would ask in the PowerPC forum of MacRumors, the guys there are very 
knowledgable:

https://forums.macrumors.com/forums/powerpc-macs.145/

Regards,
Jeroen

Rick Thomas schreef op 2020-07-15 12:09:

I have an old PowerMac G4 "Silver" (PowerMac3,4 533 MHz) running
Debian Jessie, that I'd like to put a couple of SATA disks into.  That
means I need a SATA controller card that will fit in one of its PCI
(not PCIe) slots.  It also needs to be to be compatible with the
PowerMac Open Firmware BIOS.  I've tried two RAID SATA-ii cards but
they expect to have a Windows PC BIOS motherboard and refuse to even
allow the Mac to boot with them plugged in.

Anybody have a recommendation?  And where can I purchase it?

Thanks in advance!
Rick

Looking for a PCI (not PCIe) card for (non-raid) SATA that is compatible with PowerMac G4

[Rick Thomas]

I have an old PowerMac G4 "Silver" (PowerMac3,4 533 MHz) running Debian Jessie, 
that I'd like to put a couple of SATA disks into.  That means I need a SATA 
controller card that will fit in one of its PCI (not PCIe) slots.  It also 
needs to be to be compatible with the PowerMac Open Firmware BIOS.  I've tried 
two RAID SATA-ii cards but they expect to have a Windows PC BIOS motherboard 
and refuse to even allow the Mac to boot with them plugged in.

Anybody have a recommendation?  And where can I purchase it?

Thanks in advance!
Rick

Re: mdadm raid from debian 64 bit .. error on powerpc ?

[Lennart Sorensen]

On Wed, Nov 14, 2012 at 07:40:16PM +0100, Niels Schjøtt Eliasen wrote:
> Hi Len
> And .. is it possible to upgrade the superblock ? (I fear the mdadm raid was 
> created a couple of years back (in a Lenny installation))

According to
https://raid.wiki.kernel.org/index.php/RAID_superblock_formats#Converting_between_superblock_versions
if you do it right, you can convert 0.9 to 1.0 (but no1 1.1 or 1.2 since
those use a different disk location to store the superblock).

Of course it does have to be done on a system like the one that created
the raid as far as endianess is concerned.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121114190335.ge14...@csclub.uwaterloo.ca

Re: mdadm raid from debian 64 bit .. error on powerpc ?

[Niels Schjøtt Eliasen]

Hi Len
And .. is it possible to upgrade the superblock ? (I fear the mdadm raid was 
created a couple of years back (in a Lenny installation))

Den 14/11/2012 kl. 19.35 skrev Lennart Sorensen:

> On Wed, Nov 14, 2012 at 07:21:36PM +0100, Niels S. Eliasen wrote:
>> I do have a problem that I hope someone can help me with
>> 
>> My old PC(Celeron chip) gave up just the other day.. and I have been 
>> struggling ever since to get the the mdadm (raid 1) mounted on my Debian 
>> linux...(both systems were/are Squeeze)
>> It appears that whatever I do I get the following:
>> 
>> [1218442.677440] sd 1:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 
>> TB/1.81 TiB)
>> [1218442.678301] sd 1:0:0:0: [sda] Write Protect is off
>> [1218442.678316] sd 1:0:0:0: [sda] Mode Sense: 28 00 00 00
>> [1218442.678324] sd 1:0:0:0: [sda] Assuming drive cache: write through
>> [1218442.680682] sd 1:0:0:0: [sda] Assuming drive cache: write through
>> [1218442.680700]  sda: sda1
>> [1218442.700032] sd 1:0:0:0: [sda] Assuming drive cache: write through
>> [1218442.700048] sd 1:0:0:0: [sda] Attached SCSI disk
>> [1218444.214595] mdadm: sending ioctl 20001261 to a partition!
>> [1218444.214682] mdadm: sending ioctl 20001261 to a partition!
>> [1218444.219512] mdadm: sending ioctl 20001261 to a partition!
>> [1218444.219525] mdadm: sending ioctl 20001261 to a partition!
>> [1218444.219959] mdadm: sending ioctl 20001261 to a partition!
>> [1218444.219968] mdadm: sending ioctl 20001261 to a partition!
>> [1218444.220446] mdadm: sending ioctl 20001261 to a partition!
>> [1218444.220455] mdadm: sending ioctl 20001261 to a partition!
>> [1218444.220868] mdadm: sending ioctl 400c0910 to a partition!
>> [1218444.220878] mdadm: sending ioctl 400c0910 to a partition!
>> [1218600.624201] __ratelimit: 2 callbacks suppressed
>> [1218600.624214] mdadm: sending ioctl 20001261 to a partition!
>> [1218600.624223] mdadm: sending ioctl partition!
>> [1218600.626213] mdadm: sending ioctl 20001261 to a partition!
>> [1218600.626227] mdadm: sending ioctl 20001261 to a partition!
>> [1218600.626856] mdadm: sending ioctl 20001261 to a partition!
>> [1218600.626866] mdadm: sending ioctl 20001261 to a partition!
>> [1218600.627263] mdadm: sending ioctl 20001261 to a partition!
>> [1218600.627272] mdadm: sending ioctl 20001261 to a partition!
>> [1218600.627796] mdadm: sending ioctl 400c0910 to a partition!
>> [1218600.627806] mdadm: sending ioctl 400c0910 to a partition!
>> [1218853.375782] XFS: bad magic number
>> [1218853.375796] XFS: SB validate failed
>> [1218860.125688] XFS: bad magic number
>> [1218860.125703] XFS: SB validate failed
>> 
>> 
>> i have tried the "mdadm --scan --assemble" .. and a lot of othe "mdadm" 
>> commands.. but so far no luck!
>> is the "mdadm" raid from a PC not useable on a PowerPC ??
> 
> If your md raid is version 0.9 superblock, then the content is endianess
> specific.
> 
> If it is 1.x, then it should work, unless you have a version of mdadm
> with a bug (which has been the case in the past).
> 
> For example:
> 
> ~# mdadm --misc -E /dev/sda1
>  Magic : a92b4efc
>Version : 1.1
>Feature Map : 0x0
> Array UUID : 9c77b030:d95ae558:5e6b5496:7191a12b
>   Name : mythtv64:0  (local to host mythtv64)
>  Creation Time : Sat Feb 25 13:38:51 2012
> Raid Level : raid5
>   Raid Devices : 4
> 
> Avail Dev Size : 48819424 (23.28 GiB 25.00 GB)
> Array Size : 73228800 (69.84 GiB 74.99 GB)
>  Used Dev Size : 48819200 (23.28 GiB 25.00 GB)
>Data Offset : 2048 sectors
>   Super Offset : 0 sectors
>  State : clean
>Device UUID : cafa7a53:1577745a:9401f410:d8fa2bdb
> 
>Update Time : Wed Nov 14 12:29:16 2012
>   Checksum : d0709263 - correct
> Events : 91
> 
> Layout : left-symmetric
> Chunk Size : 512K
> 
>   Device Role : Active device 1
>   Array State :  ('A' == active, '.' == missing)
> 
> That shows it is an mdraid 1.1 (hence 1.x) device and hence not endian
> specific.  If it said 0.9, then it was created with an older setup
> that defaulted to the old format, and it is host endianess and can not
> be moved to a machine with the opposite endianess.  So x86 to powerpc
> won't work.
> 
> -- 
> Len Sorensen
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/20121114183542.gd14...@csclub.uwaterloo.ca
> 


niels


--
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aaa07dec-bc16-4dc1-8a27-b03bf9b5c...@delfi-konsult.com

Re: mdadm raid from debian 64 bit .. error on powerpc ?

[Lennart Sorensen]

On Wed, Nov 14, 2012 at 07:21:36PM +0100, Niels S. Eliasen wrote:
> I do have a problem that I hope someone can help me with
> 
> My old PC(Celeron chip) gave up just the other day.. and I have been 
> struggling ever since to get the the mdadm (raid 1) mounted on my Debian 
> linux...(both systems were/are Squeeze)
> It appears that whatever I do I get the following:
> 
> [1218442.677440] sd 1:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 
> TB/1.81 TiB)
> [1218442.678301] sd 1:0:0:0: [sda] Write Protect is off
> [1218442.678316] sd 1:0:0:0: [sda] Mode Sense: 28 00 00 00
> [1218442.678324] sd 1:0:0:0: [sda] Assuming drive cache: write through
> [1218442.680682] sd 1:0:0:0: [sda] Assuming drive cache: write through
> [1218442.680700]  sda: sda1
> [1218442.700032] sd 1:0:0:0: [sda] Assuming drive cache: write through
> [1218442.700048] sd 1:0:0:0: [sda] Attached SCSI disk
> [1218444.214595] mdadm: sending ioctl 20001261 to a partition!
> [1218444.214682] mdadm: sending ioctl 20001261 to a partition!
> [1218444.219512] mdadm: sending ioctl 20001261 to a partition!
> [1218444.219525] mdadm: sending ioctl 20001261 to a partition!
> [1218444.219959] mdadm: sending ioctl 20001261 to a partition!
> [1218444.219968] mdadm: sending ioctl 20001261 to a partition!
> [1218444.220446] mdadm: sending ioctl 20001261 to a partition!
> [1218444.220455] mdadm: sending ioctl 20001261 to a partition!
> [1218444.220868] mdadm: sending ioctl 400c0910 to a partition!
> [1218444.220878] mdadm: sending ioctl 400c0910 to a partition!
> [1218600.624201] __ratelimit: 2 callbacks suppressed
> [1218600.624214] mdadm: sending ioctl 20001261 to a partition!
> [1218600.624223] mdadm: sending ioctl partition!
> [1218600.626213] mdadm: sending ioctl 20001261 to a partition!
> [1218600.626227] mdadm: sending ioctl 20001261 to a partition!
> [1218600.626856] mdadm: sending ioctl 20001261 to a partition!
> [1218600.626866] mdadm: sending ioctl 20001261 to a partition!
> [1218600.627263] mdadm: sending ioctl 20001261 to a partition!
> [1218600.627272] mdadm: sending ioctl 20001261 to a partition!
> [1218600.627796] mdadm: sending ioctl 400c0910 to a partition!
> [1218600.627806] mdadm: sending ioctl 400c0910 to a partition!
> [1218853.375782] XFS: bad magic number
> [1218853.375796] XFS: SB validate failed
> [1218860.125688] XFS: bad magic number
> [1218860.125703] XFS: SB validate failed
> 
> 
> i have tried the "mdadm --scan --assemble" .. and a lot of othe "mdadm" 
> commands.. but so far no luck!
> is the "mdadm" raid from a PC not useable on a PowerPC ??

If your md raid is version 0.9 superblock, then the content is endianess
specific.

If it is 1.x, then it should work, unless you have a version of mdadm
with a bug (which has been the case in the past).

For example:

~# mdadm --misc -E /dev/sda1
  Magic : a92b4efc
Version : 1.1
Feature Map : 0x0
 Array UUID : 9c77b030:d95ae558:5e6b5496:7191a12b
   Name : mythtv64:0  (local to host mythtv64)
  Creation Time : Sat Feb 25 13:38:51 2012
 Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 48819424 (23.28 GiB 25.00 GB)
 Array Size : 73228800 (69.84 GiB 74.99 GB)
  Used Dev Size : 48819200 (23.28 GiB 25.00 GB)
Data Offset : 2048 sectors
   Super Offset : 0 sectors
  State : clean
Device UUID : cafa7a53:1577745a:9401f410:d8fa2bdb

Update Time : Wed Nov 14 12:29:16 2012
   Checksum : d0709263 - correct
 Events : 91

 Layout : left-symmetric
 Chunk Size : 512K

   Device Role : Active device 1
   Array State :  ('A' == active, '.' == missing)

That shows it is an mdraid 1.1 (hence 1.x) device and hence not endian
specific.  If it said 0.9, then it was created with an older setup
that defaulted to the old format, and it is host endianess and can not
be moved to a machine with the opposite endianess.  So x86 to powerpc
won't work.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121114183542.gd14...@csclub.uwaterloo.ca

mdadm raid from debian 64 bit .. error on powerpc ?

[Niels S. Eliasen]

I do have a problem that I hope someone can help me with

My old PC(Celeron chip) gave up just the other day.. and I have been struggling 
ever since to get the the mdadm (raid 1) mounted on my Debian linux...(both 
systems were/are Squeeze)
It appears that whatever I do I get the following:

[1218442.677440] sd 1:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 
TB/1.81 TiB)
[1218442.678301] sd 1:0:0:0: [sda] Write Protect is off
[1218442.678316] sd 1:0:0:0: [sda] Mode Sense: 28 00 00 00
[1218442.678324] sd 1:0:0:0: [sda] Assuming drive cache: write through
[1218442.680682] sd 1:0:0:0: [sda] Assuming drive cache: write through
[1218442.680700]  sda: sda1
[1218442.700032] sd 1:0:0:0: [sda] Assuming drive cache: write through
[1218442.700048] sd 1:0:0:0: [sda] Attached SCSI disk
[1218444.214595] mdadm: sending ioctl 20001261 to a partition!
[1218444.214682] mdadm: sending ioctl 20001261 to a partition!
[1218444.219512] mdadm: sending ioctl 20001261 to a partition!
[1218444.219525] mdadm: sending ioctl 20001261 to a partition!
[1218444.219959] mdadm: sending ioctl 20001261 to a partition!
[1218444.219968] mdadm: sending ioctl 20001261 to a partition!
[1218444.220446] mdadm: sending ioctl 20001261 to a partition!
[1218444.220455] mdadm: sending ioctl 20001261 to a partition!
[1218444.220868] mdadm: sending ioctl 400c0910 to a partition!
[1218444.220878] mdadm: sending ioctl 400c0910 to a partition!
[1218600.624201] __ratelimit: 2 callbacks suppressed
[1218600.624214] mdadm: sending ioctl 20001261 to a partition!
[1218600.624223] mdadm: sending ioctl partition!
[1218600.626213] mdadm: sending ioctl 20001261 to a partition!
[1218600.626227] mdadm: sending ioctl 20001261 to a partition!
[1218600.626856] mdadm: sending ioctl 20001261 to a partition!
[1218600.626866] mdadm: sending ioctl 20001261 to a partition!
[1218600.627263] mdadm: sending ioctl 20001261 to a partition!
[1218600.627272] mdadm: sending ioctl 20001261 to a partition!
[1218600.627796] mdadm: sending ioctl 400c0910 to a partition!
[1218600.627806] mdadm: sending ioctl 400c0910 to a partition!
[1218853.375782] XFS: bad magic number
[1218853.375796] XFS: SB validate failed
[1218860.125688] XFS: bad magic number
[1218860.125703] XFS: SB validate failed


i have tried the "mdadm --scan --assemble" .. and a lot of othe "mdadm" 
commands.. but so far no luck!
is the "mdadm" raid from a PC not useable on a PowerPC ??

tia
niels



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Howto for md(raid 1) on PPC ?

[Lennart Sorensen]

On Mon, Apr 02, 2012 at 12:18:50PM -0400, Lennart Sorensen wrote:
> Well I can tell you what my setup is.
> 
> I am using an IBM p710 (and I also have a p520 with a very similar setup
> although currently using a somewhat patched and manually installed via
> dd and other hacks that you wouldn't want to know about).
> 
> I currently have:
> 
> sda1: about 8MB, type PReP boot, flagged as bootable
> sda2: 1GB, type linux raid
> sda3: 140GB, type linux raid
> 
> sdb and sdc are exactly the same.
> 
> sda2, sdb2 and sdc2 are raid1 (I have 3 disks and I want all of them to
> be able to boot, so raid1 over 3 disks seemed fine).
> 
> sda3, sdb3 and sdc3 are in raid5 and is currently / but I will change
> that to LVM when I reinstall the machine later this week.
> 
> I am using grub from git checked out 20120320.  I am also using the
> 3.2.0 backport kernel since it appears there is a problem with 2.6.32
> and software raid.  grub-probe would often get garbage trying to read the
> raid superblocks, and even using dd to read them and having them checked
> by someone that knwos the format of them, they were in fact garbage,
> but only sometimes.  Other times it worked.  3.2.0 on the other hand
> has never returned invalid superblock data for the raid.
> 
> So using 3.2.0 backport kernel and grub compiled from git from a couple of 
> weeks ago I can then do:
> 
> grub-install /dev/sda1
> 
> And after that, it boots fine and works as expected.  Well on the serial
> console, the boot menu doesn't actually display quite right, so perhaps
> that could use some work still.
> 
> For redundancy I actually do:
> 
> grub-install /dev/sdc1
> grub-install /dev/sdb1
> grub-install /dev/sda1
> 
> and then update the boot disk order with:
> 
> nvsetenv boot-device "/pci@800200a/pci1014,0339@0/sas/disk@0 
> /pci@800200a/pci1014,0339@0/sas/disk@1 
> /pci@800200a/pci1014,0339@0/sas/disk@2"
> 
> Since grub only sets it to the device you specified, and I want fall back
> to any of the 3 disks if needed.  I haven't convinced the grub developers
> to allow multiple devices to be passed to grub-install at the same time.
> Perhaps later I will succeed in that.
> 
> Anyhow, that works for me.
> 
> If you are not using an IBM, then of course you won't be using a PReP
> partition for booting, and probably won't be using a DOS partition
> table either, which would change things a bit.  grub-install does know
> about a few other types of powerpc machines, so it still ought to work
> in pretty much the same way.
> 
> The actual setup of the raid was done through the debian installer the
> normal way, although I only thought of adding sdc2 to the raid1 later,
> so I did that manually.

Oh and if you want, I can put my debian source package for the git
checkout of grub up on my website.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120402162025.gm10...@caffeine.csclub.uwaterloo.ca

Re: Howto for md(raid 1) on PPC ?

[Lennart Sorensen]

On Mon, Apr 02, 2012 at 05:19:34PM +0200, Niels S. Eliasen wrote:
> Dó you have a cookbook for getting grub2 working(with the raid of course) ?

Well I can tell you what my setup is.

I am using an IBM p710 (and I also have a p520 with a very similar setup
although currently using a somewhat patched and manually installed via
dd and other hacks that you wouldn't want to know about).

I currently have:

sda1: about 8MB, type PReP boot, flagged as bootable
sda2: 1GB, type linux raid
sda3: 140GB, type linux raid

sdb and sdc are exactly the same.

sda2, sdb2 and sdc2 are raid1 (I have 3 disks and I want all of them to
be able to boot, so raid1 over 3 disks seemed fine).

sda3, sdb3 and sdc3 are in raid5 and is currently / but I will change
that to LVM when I reinstall the machine later this week.

I am using grub from git checked out 20120320.  I am also using the
3.2.0 backport kernel since it appears there is a problem with 2.6.32
and software raid.  grub-probe would often get garbage trying to read the
raid superblocks, and even using dd to read them and having them checked
by someone that knwos the format of them, they were in fact garbage,
but only sometimes.  Other times it worked.  3.2.0 on the other hand
has never returned invalid superblock data for the raid.

So using 3.2.0 backport kernel and grub compiled from git from a couple of 
weeks ago I can then do:

grub-install /dev/sda1

And after that, it boots fine and works as expected.  Well on the serial
console, the boot menu doesn't actually display quite right, so perhaps
that could use some work still.

For redundancy I actually do:

grub-install /dev/sdc1
grub-install /dev/sdb1
grub-install /dev/sda1

and then update the boot disk order with:

nvsetenv boot-device "/pci@800200a/pci1014,0339@0/sas/disk@0 
/pci@800200a/pci1014,0339@0/sas/disk@1 
/pci@800200a/pci1014,0339@0/sas/disk@2"

Since grub only sets it to the device you specified, and I want fall back
to any of the 3 disks if needed.  I haven't convinced the grub developers
to allow multiple devices to be passed to grub-install at the same time.
Perhaps later I will succeed in that.

Anyhow, that works for me.

If you are not using an IBM, then of course you won't be using a PReP
partition for booting, and probably won't be using a DOS partition
table either, which would change things a bit.  grub-install does know
about a few other types of powerpc machines, so it still ought to work
in pretty much the same way.

The actual setup of the raid was done through the debian installer the
normal way, although I only thought of adding sdc2 to the raid1 later,
so I did that manually.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120402161850.gl10...@caffeine.csclub.uwaterloo.ca

Re: Howto for md(raid 1) on PPC ?

[Niels S. Eliasen]

Hi 
Dó you have a cookbook for getting grub2 working(with the raid of course) ?

Sent from my iPhone

Den 02/04/2012 kl. 16.24 skrev lsore...@csclub.uwaterloo.ca (Lennart Sorensen):

> On Mon, Apr 02, 2012 at 01:07:05PM +0100, Raf Czlonka wrote:
>> Any mdadm one should apply.
>> Your /boot might need to be outside of RAID though. AFAIK yaboot doesn't
>> support booting of md RAID and I haven't tried GRUB on PPC.
> 
> Grub works fine on raid, although you will need a git checkout, not the
> current debian version.  Looks like grub 2.00 will finally work well on
> ppc though.
> 
> I have been using grub on ppc for almost 3 years now on raid1 quite
> happily.
> 
> -- 
> Len Sorensen
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/20120402142403.gk10...@caffeine.csclub.uwaterloo.ca
> 


--
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/9da1cef3-8934-4041-98be-40ca606a0...@delfi-konsult.com

Re: Howto for md(raid 1) on PPC ?

[Lennart Sorensen]

On Mon, Apr 02, 2012 at 01:07:05PM +0100, Raf Czlonka wrote:
> Any mdadm one should apply.
> Your /boot might need to be outside of RAID though. AFAIK yaboot doesn't
> support booting of md RAID and I haven't tried GRUB on PPC.

Grub works fine on raid, although you will need a git checkout, not the
current debian version.  Looks like grub 2.00 will finally work well on
ppc though.

I have been using grub on ppc for almost 3 years now on raid1 quite
happily.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120402142403.gk10...@caffeine.csclub.uwaterloo.ca

Re: Howto for md(raid 1) on PPC ?

[David Ricar]

Hi,
booting linux on PPC in any other than default scenario is a bit tricky. 
It is possible to have separate /boot and it is possible to have it on 
mirrored disk (or have whole / partition inside the mirror). yaboot 
would not care of the mirror, so you have to configure it to use a 
physical drive's partition.
But, all these things are tricky and I would recommend to spend those 
few hours of bad guesses to be able to deal with any trouble that could 
appear afterwards - again, the installer would not help you repairing 
such scenario if it breaks for any reason.


Another option should be grub2, which should be able to handle all this 
on it's own. But as many others, I have never seen it on other than x86 
platform.
Because of this lack of experience, I would again recommend to fidle 
most of it yourself to realy know your environment and be able to fix it 
because you would know how it was constructed.


Cheers
David

On 04/02/2012 02:11 PM, Niels S. Eliasen wrote:

is'nt possible to get yaboot to boot regardless of what disk is available ?

Den 02/04/2012 kl. 14.07 skrev Raf Czlonka:


On Mon, Apr 02, 2012 at 12:14:38PM BST, Niels S. Eliasen wrote:

hi guys
I am looking for some howto on using/doing a setup of a raid 1 on a PPC 
Anyone ?


Any mdadm one should apply.
Your /boot might need to be outside of RAID though. AFAIK yaboot doesn't
support booting of md RAID and I haven't tried GRUB on PPC.

Regards,
--
Raf


--
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120402120704.ga23...@linuxstuff.pl



mvh/kind regards
Niels S. Eliasen
Hørhavevej 1
DK-4250, Fuglebjerg
Dansk Tel: +45 21 77 95 90
Fransk Tel: +33 647042103
mailto:nse_remove_t...@delfi-konsult.com






--
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f79b0aa.6060...@dejf.org

Re: Howto for md(raid 1) on PPC ?

[Raf Czlonka]

On Mon, Apr 02, 2012 at 01:11:38PM BST, Niels S. Eliasen wrote:
> is'nt possible to get yaboot to boot regardless of what disk is available ?
  ^
I'm afraid I don't understand the question.

-- 
Raf


-- 
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120402131110.ga23...@linuxstuff.pl

Re: Howto for md(raid 1) on PPC ?

[Niels S. Eliasen]

is'nt possible to get yaboot to boot regardless of what disk is available ?

Den 02/04/2012 kl. 14.07 skrev Raf Czlonka:

> On Mon, Apr 02, 2012 at 12:14:38PM BST, Niels S. Eliasen wrote:
>> hi guys
>> I am looking for some howto on using/doing a setup of a raid 1 on a PPC 
>> Anyone ?
> 
> Any mdadm one should apply.
> Your /boot might need to be outside of RAID though. AFAIK yaboot doesn't
> support booting of md RAID and I haven't tried GRUB on PPC.
> 
> Regards,
> -- 
> Raf
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/20120402120704.ga23...@linuxstuff.pl
> 

mvh/kind regards
Niels S. Eliasen
Hørhavevej 1
DK-4250, Fuglebjerg
Dansk Tel: +45 21 77 95 90
Fransk Tel: +33 647042103
mailto:nse_remove_t...@delfi-konsult.com





smime.p7s
Description: S/MIME cryptographic signature

Re: Howto for md(raid 1) on PPC ?

[Raf Czlonka]

On Mon, Apr 02, 2012 at 12:14:38PM BST, Niels S. Eliasen wrote:
> hi guys
> I am looking for some howto on using/doing a setup of a raid 1 on a PPC 
> Anyone ?

Any mdadm one should apply.
Your /boot might need to be outside of RAID though. AFAIK yaboot doesn't
support booting of md RAID and I haven't tried GRUB on PPC.

Regards,
-- 
Raf


-- 
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120402120704.ga23...@linuxstuff.pl

Howto for md(raid 1) on PPC ?

[Niels S. Eliasen]

hi guys
I am looking for some howto on using/doing a setup of a raid 1 on a PPC 
Anyone ?




smime.p7s
Description: S/MIME cryptographic signature

Re: RAID Controller to enable SATA HDD Hard Drive

[Gaudenz Steinlin]

Hi Stephan

On Wed, Feb 25, 2009 at 01:18:30AM -0800, Stephan wrote:
> Hi folks,
>
> I've installed a Silicone Imaged based RAID controller with one Maxtor  
> 250 gig SATA hard drive and no other drives.  Installation of Etch ran  
> smoothly, the hard drive was identified, configured, and the base system  
> & packages installed fine, but until the yaboot  
> installation/configuration failed.

The easiest way to fix this is probably to reinstall and partition like
outlined below. Then the installer should automatically choose the right
yaboot configuration.


>
> Clearly, I need to configure yaboot but I'm having trouble finding  
> resources to point me in the right direction.  I'm neither a RAID nor a  
> Linux guru, but if anyone can offer some examples or suggestions, I  
> won't need to be spoon fed either ;)  If absolutely necessary, I'm even  
> willing to configure the initial kernal loading to run from either a  
> floppy or a CD, but that sounds a bit extreme for what should be a  
> simple problem.

I don't know if your RAID controller is supported by the Mac
OpenFirmware. Probably not. So your easiest option is to have the /boot
and Yaboot partitions on the original EIDE drive. As these are only
needed for booting, they won't slow down your system. The root partition
can stay on the RAID as it is only needed after the linux kernel is
loaded. 

You can find detailed information on how to configure yaboot in the
yaboot.conf manpage. If you encounter specific problems you can always
ask specific questions.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

RAID Controller to enable SATA HDD Hard Drive

[Stephan]

Hi folks,

I've established a small web hosting service, and have acquired four 
G4's that run great.  Unfortunately, the old hard drives in my Macs just 
aren't cutting it, and EIDE hard drives are getting more and more expensive.


I've installed a Silicone Imaged based RAID controller with one Maxtor 
250 gig SATA hard drive and no other drives.  Installation of Etch ran 
smoothly, the hard drive was identified, configured, and the base system 
& packages installed fine, but until the yaboot 
installation/configuration failed.


Clearly, I need to configure yaboot but I'm having trouble finding 
resources to point me in the right direction.  I'm neither a RAID nor a 
Linux guru, but if anyone can offer some examples or suggestions, I 
won't need to be spoon fed either ;)  If absolutely necessary, I'm even 
willing to configure the initial kernal loading to run from either a 
floppy or a CD, but that sounds a bit extreme for what should be a 
simple problem.


Thanks,

Stephan


--
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

PCI RAID card recognised but disks don't show - G4

[Clive Menzies]

Hi

I've got a PowerMac G4 QuickSilver (OpenFirmware 3) which I'm setting up 
as a file server.  Etch is installed on /dev/hda and is working fine.  I 
bought a PCI IDE2 card to add two additional 750Gb ide drives which I 
propose to configure as RAID1 using mdadm for /home.


However, the card is fairly cheap (fake raid) and whilst the the card 
appears to be recognised, the disks aren't.  I've tried different jumper 
settings on the disks (master/slave, cable select, master/master on 
different ide cables).


From lshw:

*-pci:1
 description: Host bridge
 product: UniNorth 1.5 PCI
 vendor: Apple Computer Inc.
 physical id: 101
 bus info: p...@10:0b.0
 version: 00
 width: 32 bits
 clock: 66MHz
 configuration: latency=16
   *-storage
    description: RAID bus controller
product: IT/ITE8212 Dual channel ATA RAID controller (PCI 
version s

eems to be IT8212, embedded seems to be ITE8212)
vendor: Integrated Technology Express, Inc.
physical id: 13
bus info: p...@10:13.0
version: 13
width: 32 bits
clock: 66MHz
capabilities: storage bus_master cap_list
configuration: driver=ITE821x IDE latency=16 maxlatency=8 
mingnt=8
resources: ioport:f2000440-f2000447 
ioport:f2000430-f2000433 ioport

:f2000420-f2000427 ioport:f2000410-f2000413 ioport:f2000400-f200040f irq:53


From lspci -vv:

0001:10:13.0 RAID bus controller:  
(rev 13)
   Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
   Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
   Latency: 16 (2000ns min, 2000ns max)
   Interrupt: pin A routed to IRQ 53
   Region 0: I/O ports at f2000440 [size=8]
   Region 1: I/O ports at f2000430 [size=4]
   Region 2: I/O ports at f2000420 [size=8]
   Region 3: I/O ports at f2000410 [size=4]
   Region 4: I/O ports at f2000400 [size=16]
   Expansion ROM at 800a [disabled] [size=128K]
   Capabilities: 


From dmesg:

IT8212: IDE controller at PCI slot 0001:10:13.0
IT8212: chipset revision 19
it821x: controller in smart mode.
IT8212: 100% native mode on irq 53
   ide3: BM-DMA at 0x0400-0x0407, BIOS settings: hdg:pio, hdh:pio
   ide4: BM-DMA at 0x0408-0x040f, BIOS settings: hdi:pio, hdj:pio
Probing IDE interface ide3...
IN from bad port 447 at c01bd9f8
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
IN from bad port 446 at c01bd9f8
ieee1394: Initialized config rom entry `ip1394'
IN from bad port 446 at c01bd9f8
IN from bad port 446 at c01bd9f8
hda: max request size: 128KiB
hda: 120103200 sectors (61492 MB) w/1916KiB Cache, CHS=65535/16/63, UDMA(66)
hda: cache flushes not supported
hda: [mac] hda1 hda2 hda3 hda4 hda5 hda6 hda7 hda8
hdc: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache, DMA
Uniform CD-ROM driver Revision: 3.20
IN from bad port 446 at c01bd9f8
Probing IDE interface ide4...
IN from bad port 427 at c01bd9f8
IN from bad port 426 at c01bd9f8
IN from bad port 426 at c01bd9f8
IN from bad port 426 at c01bd9f8
IN from bad port 426 at c01bd9f8

The card is made by Star Tech
2 port PCI ATA-133 IDE Adapter Card

I'd be grateful for any useful pointers.

Thanks

Clive



--
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Happy success with LVM and RAID

[Sven Luther]

On Sun, Dec 03, 2006 at 06:03:44PM -0500, Douglas Tutty wrote:
> On Sun, Dec 03, 2006 at 10:27:27AM -0500, Gregory Seidman wrote:
> > Buried in this is a little bit of grumpiness, but only a little. See if you
> > can find it. Mainly, this is about a success that I thought was worth
> > sharing.
>  
> > In summary, I've been having success managing my home digital storage with
> > Debian GNU/Linux on PPC since around 1999, and the only hiccups have been
> > broken hardware (dead motherboard, non-compliant firewire enclosures) and
> > endianness issues. Not bad.
> > 
> > --Greg
> 
> This juggling to keep all the balls (disks) in the air sounds familiar.
> Non-partisan caution: before you settle on Reiserfs, read some recent
> threads about Reiserfsck and Reiserfs vs JFS.  I went to JFS when
> Reiserfsck fscked up my drives.  Never had a problem with JFS despite
> many power failures.

We made the choice for EXT3 ourselves, since it is the only filesystemm which
can be grown online and shrinked offline, and reiserfs is not really a
solution.

JFS/XFS can be grown online, but not shrinked, so they are problematic.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Happy success with LVM and RAID

[Gregory Seidman]

On Sun, Dec 03, 2006 at 06:03:44PM -0500, Douglas Tutty wrote:
} On Sun, Dec 03, 2006 at 10:27:27AM -0500, Gregory Seidman wrote:
} > Buried in this is a little bit of grumpiness, but only a little. See if you
} > can find it. Mainly, this is about a success that I thought was worth
} > sharing.
}  
} > In summary, I've been having success managing my home digital storage with
} > Debian GNU/Linux on PPC since around 1999, and the only hiccups have been
} > broken hardware (dead motherboard, non-compliant firewire enclosures) and
} > endianness issues. Not bad.
} > 
} > --Greg
} 
} This juggling to keep all the balls (disks) in the air sounds familiar.
} Non-partisan caution: before you settle on Reiserfs, read some recent
} threads about Reiserfsck and Reiserfs vs JFS.  I went to JFS when
} Reiserfsck fscked up my drives.  Never had a problem with JFS despite
} many power failures.

As long as ext3 serves my purposes (and so far it has), I'll stick with it.
I have no present need for reiserfs or JFS or XFS.

} Doug.
--Greg


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Happy success with LVM and RAID

[Douglas Tutty]

On Sun, Dec 03, 2006 at 10:27:27AM -0500, Gregory Seidman wrote:
> Buried in this is a little bit of grumpiness, but only a little. See if you
> can find it. Mainly, this is about a success that I thought was worth
> sharing.
 
> In summary, I've been having success managing my home digital storage with
> Debian GNU/Linux on PPC since around 1999, and the only hiccups have been
> broken hardware (dead motherboard, non-compliant firewire enclosures) and
> endianness issues. Not bad.
> 
> --Greg

This juggling to keep all the balls (disks) in the air sounds familiar.
Non-partisan caution: before you settle on Reiserfs, read some recent
threads about Reiserfsck and Reiserfs vs JFS.  I went to JFS when
Reiserfsck fscked up my drives.  Never had a problem with JFS despite
many power failures.

Doug.

 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Happy success with LVM and RAID

[Gregory Seidman]

Buried in this is a little bit of grumpiness, but only a little. See if you
can find it. Mainly, this is about a success that I thought was worth
sharing.

Starting in 1999 or so I had Debian running on a PowerCenter Pro 180 (PPC
604 180MHz, 1997 vintage Mac clone) maxed out to 512MB of memory. I ran an
8-drive RAID5 on an Adaptec SCSI card in an HP RAID rack with 18GB 10K RPM
disks, for a total of a (loud) 118GB of disk space. Just for fun, I also
ran a cryptoloop on top of it. On top of that, of course, I had LVM (1.0,
since 2 wasn't out yet and neither was the 2.6 kernel) and ext3. I even
threw in a Tulip-based "fast" (100baseT) ethernet card.

This machine served files via NFS (fast enough to play audio and video from
it directly, which meant it was plenty fast for my purposes), served IMAP,
ran spam filtering, retrieved email from a number of remote accounts, ran a
web server (with very minimal traffic, but also webmail), and basically
chugged along like a good little server.

Then, some time in 2003 or 2004, the motherboard fried. No idea what
happened, exactly, but it was toast. I had a Celeron box lying around
(already running Debian, even, though it had started out running Knoppix),
so I tried to get everything working on it. Moving the PCI cards was
trivial, but the RAID array wasn't recognized. It turns out that Linux
software RAID was endian-specific until kernel 2.6.13, so I couldn't use an
Intel box to run my existing array. Fortunately, I had a 2000-era dual G4
800 I'd been using as my primary machine, and I got Linux installed on it
with tolerable ease and that became my server. I even gave it the same name
and IP address, so it wound up being a drop-in replacement from the
perspective of the other machines depending on it.

Eventually, in 2005, I got tired of the noise and heat of 8 10K RPM drives.
If I'd been smart, I would have gotten tired of it before moving them 400
miles, but hindsight is 20/20. So I went and bought a couple of 250GB
Firewire drives, planning on setting them up in a RAID1. When I plugged one
in, it was noticed immediately by the kernel. When I plugged the other one
in, however, the kernel thought the serial number had changed on the first
one and was still convinced that there was only one drive. It didn't matter
which I plugged in first. It turns out that the firewire enclosures were
cheap, non-compliant pieces of crap and were indistinguishable. One
firewire enclosure and some unscrewing and rescrewing later, and I had a
workable pair. Setting up the RAID1 was trivial, and this time it shouldn't
be endian-specific. Creating a dm-crypt loop instead of the legacy
cryptoloop was almost trivial. Setting up LVM2 was trivial. Copying the
volumes from the old RAID to the new one was tedious, but not as slow as I
would have expected. Thus I doubled my capacity, cut my heat and power
consumption by 3/4, and reduced the noise level to a bare minimum.

Recently, I started running low on space on a couple of volumes. Since I'd
copied them from the old RAID, I'd left them the same size they'd been
there. This meant that I had some 130GB of unused disk space that I could
allocate to them. Two lvextend commands later (one for each volume) and I
had enough space. One ext2resize command later, and I was pissed:

ext2resize v1.1.19 - 2001/03/18 for EXT2FS 0.5b
Can't resize on big endian yet!

If ext2resize is its own package, and it doesn't work on big endian, why is
it even available for the ppc architecture? I then dug around and looked for
e2fsadm. Turns out it's in the lvm10 package, which I didn't have
installed because I am using lvm2. Installed it, looked at the e2fsadm man
page, and see that it can use resize2fs, which I already have installed.
I looked at the resize2fs man page, uninstalled lvm10, and resized my
filesystems to fill the newly extended volumes.

In summary, I've been having success managing my home digital storage with
Debian GNU/Linux on PPC since around 1999, and the only hiccups have been
broken hardware (dead motherboard, non-compliant firewire enclosures) and
endianness issues. Not bad.

--Greg


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Ata Raid HD

[Lee Braiden]

On Friday 13 May 2005 19:48, João Gabriel Sapucahy Chiste wrote:
> I can't install debian in my ibook g4 because the sistem don't
> recognize my Hard Disk. What can i do. I saw in the debian site that
> have a floopy with the drivers that are missing. boot I dont have
> floopy drive

Look for another CD image with the right drivers, I guess.  Sorry I can't help 
more on this.

> And Debian has support for Airport Express?

As Johannes just said, they haven't released details on how this works, so 
don't hope for a driver any time soon :(   Most people use USB wifi adapters 
instead.

-- 
Lee.

Please send replies to the list, not to my email address.

Re: Ata Raid HD

[Johannes Berg]

On Fri, 2005-05-13 at 15:48 -0300, JoÃo Gabriel Sapucahy Chiste wrote:

> And Debian has support for Airport Express?

Linux currently does not support AE because it is a closed-source
closed-specs Broadcom BCM4306 (or 7?) chipset.

johannes


signature.asc
Description: This is a digitally signed message part

Ata Raid HD

[João Gabriel Sapucahy Chiste]

I can't install debian in my ibook g4 because the sistem don't 
recognize my Hard Disk. What can i do. I saw in the debian site that 
have a floopy with the drivers that are missing. boot I dont have 
floopy drive

And Debian has support for Airport Express?
Thanks!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

URGENT: endianness of RAID, blowfish loopback, LVM, and ext3

[Gregory Seidman]

I have a PowerComputing Mac clone from 1997 acting as my file server (among
other things). It appears to be having hardware problems, and is
spontaneously rebooting from time to time. It seems to be getting more
frequent. I have a Celeron box I can replace it with, but that won't work
if there are endian problems. I need to know if I can use the Celeron box,
or if I need to replace the hardware. (I have several good options for
replacement, all of which involve roughly the same cost; that isn't the
question.)

I have an Adaptec SCSI card connected to a SCSI SCA hotswap rack with eight
drives. I am using the Linux kernel RAID to join them in a RAID5. I am
running cryptoloop on top of that, and LVM on top of that. The partitions
are ext3. The question is whether any of that functionality is
endian-specific. I am unwilling to risk all my data by just trying it out.

System info:

custom compiled 2.4.21 kernel
cryptoapi-core and cryptoloop modules (0.1.0-2)
RAID
    raid-level  5
    nr-raid-disks   8
nr-spare-disks  0
chunk-size  256
persistent-superblock   1
parity-algorithmleft-symmetric
blowfish loopback encryption
LVM
ext3fs

--Greg


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RAID

[Shyamal Prasad]

"Arnór" == Arnór Kristjánsson <[EMAIL PROTECTED]> writes:

Arnór> On 21.2.2005, at 15:07, Shyamal Prasad wrote:

>> It is probably possible to set up your RAID partitions manually
>> by using the command line on the installers virtual
>> terminal. On returning to the menu they should be found. This
>> trick works for LVM setup (I've never tried to set up a RAID
>> system).

Arnór> Can you provide more info on this 'trick'?  A.

The work around for LVM is documented in the sarge install manual for
powerpc. See the note in section 6.3.3.2 at 

http://d-i.alioth.debian.org/manual/en.powerpc/ch06s03.html#di-partition

Of course you will need to use the command line tools to set up your
raid partitions at the virtual terminal. Unfortunately I don't know
how to do this or I would attempt to write some instructions for raid
too.

Cheers!
Shyamal


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RAID

[Arnór Kristjánsson]

Can you provide more info on this 'trick'?
A.
On 21.2.2005, at 15:07, Shyamal Prasad wrote:
It is probably possible to set up your RAID partitions manually by
using the command line on the installers virtual terminal. On
returning to the menu they should be found. This trick works for LVM
setup (I've never tried to set up a RAID system).

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RAID

[Arnór Kristjánsson]

I've had progress: I can select the raid option from the use as menu in 
the partitioner _if_ I select the device (not free space) and select 
gpt.
I have problems after this step: I either can't select the raid volumes 
if I get the devices formatted (no raid volumes found) _or_ I can't 
format because of failure to partition the root filesystem.

The installer seems to be a bit buggy to me...
Has anyone had any progress doing this?
On 21.2.2005, at 13:31, Arnór Kristjánsson wrote:
Hi,
I'm trying to install debian (sarge) from a sid ISO I downloaded to a 
brand new XServe G5. The box has two identical hard disks I would like 
to set up as a software raid. The problem is that when selecting the 
raid tool it complains that there are no linux raid autodetect volumes 
found...and I cant select that from the Use as menu in the 
partitioner.

Please advise
A.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact 
[EMAIL PROTECTED]

Re: RAID

[Shyamal Prasad]

"Arnór" == Arnór Kristjánsson <[EMAIL PROTECTED]> writes:

Arnór> The problem is that when selecting the raid tool it
Arnór> complains that there are no linux raid autodetect volumes
Arnór> found...and I cant select that from the Use as menu in the
Arnór> partitioner.

My understanding is that RAID and LVM set up will not work via the
installer menus on Apple systems. This is because there are no
standard conventions for setting partition types in Apple partition
tables.

It is probably possible to set up your RAID partitions manually by
using the command line on the installers virtual terminal. On
returning to the menu they should be found. This trick works for LVM
setup (I've never tried to set up a RAID system).

Cheers!
Shyamal


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RAID

[Arnór Kristjánsson]

Hi,
I'm trying to install debian (sarge) from a sid ISO I downloaded to a 
brand new XServe G5. The box has two identical hard disks I would like 
to set up as a software raid. The problem is that when selecting the 
raid tool it complains that there are no linux raid autodetect volumes 
found...and I cant select that from the Use as menu in the partitioner.

Please advise
A.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RAID on PPC was: 64bit PPC and Debian

[Gregory Seidman]

On Fri, Nov 05, 2004 at 06:54:24PM +0100, Gunnar von Boehn wrote:
} >Well, i am having some trouble getting a DPT (now adaptec) smartraid V
} >scsi controller seeing my disks on pegasos, but i guess a OF-supported
} >pmac scsi card would have both less trouble, and be way more expensive.
} 
} Me thinks the question is if there is ANY SCSI Raid which is known to
} work on PowerPC ?
} 
} Does someone know a working SCSI Raid card?

I have a RAID working nicely on my ancient PPC 604 @ 180MHz, but I am using
Linux's software RAID, an Adaptec SCSI card, and an external RAID rack. I
am also not booting from the RAID. This may sound like an inefficient
setup, but even with an encryption loop on top of the RAID I can serve a
filesystem on the RAID over NFS and be able to play MPEGs from it on my
other computers without any skipping or stalling.

I've never much cared for the idea of root on RAID anyway, nor RAID on
internal disks, so this system is ideal for me. YMMV.

} Cheers
} Gunnar
--Greg

Re: RAID on PPC was: 64bit PPC and Debian

[Sven Luther]

On Fri, Nov 05, 2004 at 06:54:24PM +0100, Gunnar von Boehn wrote:
> Hi,
> 
> >Well, i am having some trouble getting a DPT (now adaptec) smartraid V 
> >scsi
> >controller seeing my disks on pegasos, but i guess a OF-supported pmac 
> >scsi
> >card would have both less trouble, and be way more expensive.
> 
> Me thinks the question is if there is ANY SCSI Raid which is known to 
> work on PowerPC ?

pmac ones should have nice forth drivers, which should work fine.

BTW, i was mentioned to use the i2o_block (for raid) or i2o_scsi (for single
disks) drivers instead of the dpt_i2o one, and it doesn't kill the box
anymore. I don't see the disks yet though, but it is an improvement.

Friendly,

Sven Luther

RAID on PPC was: 64bit PPC and Debian

[Gunnar von Boehn]

Hi,

Well, i am having some trouble getting a DPT (now adaptec) smartraid V 
scsi
controller seeing my disks on pegasos, but i guess a OF-supported pmac 
scsi

card would have both less trouble, and be way more expensive.


Me thinks the question is if there is ANY SCSI Raid which is known to 
work on PowerPC ?


Does someone know a working SCSI Raid card?


Cheers
Gunnar

Which Hardware-Raid work on PowerPC ?

[Gunnar von Boehn]

Hello List,

I'm looking for a Hardware-Raid which works on PowerPC Linux.

I tried the following SCSI Raid-controller but had some problems:

DPT SmartRaid V Millennium
AMI MegaRaid 500 Express
ICP GDT 6118 RP


Could you please recommend me some working Raid-controllers ?


Cheers
Gunnar

debian testing with hardware raid (ide) on powermac g3?

[Dirk H. Schulz]

Hi folks,

I run a lot of debian boxes, but all of them are x86. That sure is a pity.

So I tried installing debian testing on a Powermac G3 (blue & white), 300 
MHz. And it worked! Sorry for the astonishment, but I never tried before.


Next thing I tried: Plugging in a 3ware 7000 into the mac and installing 
again. The sarge installer even tried loading the 3ware module but then 
claimed "modprobe -v 3ware..." to have failed.


Is there anything I can do about that? I think if there is a module for 
3ware controllers in the powerpc distri it must make sense running these 
cards on a powerpc, or not? I was not sure if they run inside a mac at all.


Okay, if it does not work with 3ware, are there any experiences out there 
with other hardware raid cards (like acard or whatever) that work in a 
G3/300 that is running debian?


I would LOVE to hear something like that, because then there would be a 
great new job for quite some of these machines here!


Thanks for any hint or help.

Dirk

PS: I googled around a lot for these three key words (3ware, powermac g3, 
debian), but did not find anything that contained all of them in a related 
manner. Is it that new an idea to try?

Re: Problem raid IBM RS6000 B50

[Sven Luther]

On Fri, Jan 23, 2004 at 12:52:32AM -0800, nikp wrote:
> Hi Thorsten and Sven.
> 
> Just to complete the draw, right now my situation is this one.
> On my machine with the kernel 2.4.24 compiled with the config that i
> given to you.
> I've got on disk0 a primary partition sda2 formatted ext3 with the
> entire os later i,ve created other primary partitions sda4 and sdb4
> and after a raid1 partition with these 2 (md0) formatted the raid
> partition ext3 and copied all the files from sda2.
> 
> Now,if i put as root in my boot files (fstab yaboot.conf) sda2,
> everything is ok the machine boot and i have access to md0 also
> ,instead if i select as root md0, i obtain the error that i shown you
> in the first post.
> 
> Obviously ,if i try to boot from openfirmware with a diskette or from
> the disk i have the same result.
> 
> Thanks again for your help, hoping to reach the solutions cause i
> can't complete the installation and put the machine online without the
> raid.

This could be a symptom of the raid drivers compiled as module (same
happens with my syjet scsi removable drive, the scsi driver is a module,
so root cannot be on it).

We need to look into building kenrels with builtin initrd containing
modules for this, i think.

Friendly,

Sven Luther

Re: Problem raid IBM RS6000 B50

[Thorsten Sauter]

Hi,

* nikp <[EMAIL PROTECTED]> [2004-01-23 09:52]:
| Just to complete the draw, right now my situation is this one.
| On my machine with the kernel 2.4.24 compiled with the config that i
| given to you.
| I've got on disk0 a primary partition sda2 formatted ext3 with the
| entire os later i,ve created other primary partitions sda4 and sdb4
| and after a raid1 partition with these 2 (md0) formatted the raid
| partition ext3 and copied all the files from sda2.

is it possible to send me your vmlinuz kernel image? I have currently no
way to compile it myself with your .config file.

So I could simply try to boot your kernel.

Thanks a lot
Thorsten

-- 
Thorsten Sauter
<[EMAIL PROTECTED]>

(Is there life after /sbin/halt -p?)



signature.asc
Description: Digital signature

Re: Problem raid IBM RS6000 B50

[nikp]

Hi Thorsten and Sven.

Just to complete the draw, right now my situation is this one.
On my machine with the kernel 2.4.24 compiled with the config that i
given to you.
I've got on disk0 a primary partition sda2 formatted ext3 with the
entire os later i,ve created other primary partitions sda4 and sdb4
and after a raid1 partition with these 2 (md0) formatted the raid
partition ext3 and copied all the files from sda2.

Now,if i put as root in my boot files (fstab yaboot.conf) sda2,
everything is ok the machine boot and i have access to md0 also
,instead if i select as root md0, i obtain the error that i shown you
in the first post.

Obviously ,if i try to boot from openfirmware with a diskette or from
the disk i have the same result.

Thanks again for your help, hoping to reach the solutions cause i
can't complete the installation and put the machine online without the
raid.

[EMAIL PROTECTED]

Bye 

Nicola Paltani

Re: Problem raid IBM RS6000 B50

[Thorsten Sauter]

* Sven Luther <[EMAIL PROTECTED]> [2004-01-22 11:49]:
| On Thu, Jan 22, 2004 at 11:43:24AM +0100, Nik(uff) wrote:
| > Hi Sven Luther ,thank you very much for your reply.
| > 
| > > I believe that you are not running the debian powerpc kernel on that
| > > box. I would be very interested in getting access to both your kernel
| > > source tree, (or info on where you got it from and what patch you did
| > > apply, if any) as well as the config file used, so as to make the debian
| > > -powerpc kernels build on those.
| > 
| >  i've used for the the installation  a kernel downloaded through google
| > (release 2.4.2) and later i've downloaded the kernel file directly from
| > kernel.org and compiled it on the machine, with the standard procedure not
| > the Debian one , cause this one was not working good.
| > my configuration file is this one.
| 
| Ok, thanks. I will see if we can look over it, and adapt the debian
| .config for it.
| 
| Thorsten, could you have a look at it, since you have access to such
| hardware ?

hmm. yes. I try to compile such a kernel and boot it.

Bye
Thorsten

-- 
Thorsten Sauter
<[EMAIL PROTECTED]>

(Is there life after /sbin/halt -p?)



signature.asc
Description: Digital signature

Re: Problem raid IBM RS6000 B50

[nikp]

Hi, Thorsten

i,ve used for the installation a kernel image 2.4.2 downloaded through
google , and after i've downloaded the kernel file 2.4.24 directly
from kernel.org and compiled it on my machine ,with the standard
procedur not the debian ones cause with this i had some problems.

 
Thanks

Nicola

Re: Problem raid IBM RS6000 B50

[Sven Luther]

On Thu, Jan 22, 2004 at 11:43:24AM +0100, Nik(uff) wrote:
> Hi Sven Luther ,thank you very much for your reply.
> 
> > I believe that you are not running the debian powerpc kernel on that
> > box. I would be very interested in getting access to both your kernel
> > source tree, (or info on where you got it from and what patch you did
> > apply, if any) as well as the config file used, so as to make the debian
> > -powerpc kernels build on those.
> 
>  i've used for the the installation  a kernel downloaded through google
> (release 2.4.2) and later i've downloaded the kernel file directly from
> kernel.org and compiled it on the machine, with the standard procedure not
> the Debian one , cause this one was not working good.
> my configuration file is this one.

Ok, thanks. I will see if we can look over it, and adapt the debian
.config for it.

Thorsten, could you have a look at it, since you have access to such
hardware ?

Friendly,

Sven Luther

Re: Problem raid IBM RS6000 B50

[Nik(uff)]

Hi Sven Luther ,thank you very much for your reply.

> I believe that you are not running the debian powerpc kernel on that
> box. I would be very interested in getting access to both your kernel
> source tree, (or info on where you got it from and what patch you did
> apply, if any) as well as the config file used, so as to make the debian
> -powerpc kernels build on those.

 i've used for the the installation  a kernel downloaded through google
(release 2.4.2) and later i've downloaded the kernel file directly from
kernel.org and compiled it on the machine, with the standard procedure not
the Debian one , cause this one was not working good.
my configuration file is this one.

thank's again

Nicola Paltani


config
Description: Binary data

Re: Problem raid IBM RS6000 B50

[Sven Luther]

On Tue, Jan 20, 2004 at 05:06:35AM -0800, nikp wrote:
> I've installed debian 3.0 ppc on my IBM b50 machine , and everything
> is working fine.

Cool.

> My last step is to implement a software raid drive on root partition.
> i'm running a 2.4.24 kernel compiled whith lvm and raid support.

I believe that you are not running the debian powerpc kernel on that
box. I would be very interested in getting access to both your kernel
source tree, (or info on where you got it from and what patch you did
apply, if any) as well as the config file used, so as to make the debian
-powerpc kernels build on those.

Friendly,

Sven Luther

Re: Problem raid IBM RS6000 B50

[Thorsten Sauter]

Hi,

* nikp <[EMAIL PROTECTED]> [2004-01-20 14:06]:
| I've installed debian 3.0 ppc on my IBM b50 machine , and everything
| is working fine.

could you please told me, which kernel you have been used for
installation? (URL)

Thanks
Thorsten

-- 
Thorsten Sauter
<[EMAIL PROTECTED]>

(Is there life after /sbin/halt -p?)



signature.asc
Description: Digital signature

Problem raid IBM RS6000 B50

[nikp]

I've installed debian 3.0 ppc on my IBM b50 machine , and everything
is working fine.
My last step is to implement a software raid drive on root partition.
i'm running a 2.4.24 kernel compiled whith lvm and raid support.
I've configured /etc/raidtab create the raid with mkraid,formatted and
mounted /dev/md0 copied all the os files in there ,configured yaboot
and fstab to start with root=/dev/md0 and make mkofboot -v .
But when i try to reboot the machine hung up , and even if i try to
boot from openfirmware with my zimage on a diskette generated always
whit kernel 2.4.24 with raid support (>0 boot floppy:,zimage
root=/dev/md0 console=ttyS0) i got this message in console:
obviously if i boot from another partition not in raid, everything is
working fine.

Attached scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0
sym0:3: FAST-10 SCSI 10.0 MB/s ST (100.0 ns, offset 15)
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.12
Macintosh non-volatile memory driver v1.0
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid5 personality registered as nr 4
raid5: measuring checksumming speed
   8regs :   436.800 MB/sec
   32regs:   378.800 MB/sec
raid5: using function: 8regs (436.800 MB/sec)
md: multipath personality registered as nr 7
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
LVM version 1.0.7(28/03/2003)
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
EXT3-fs: unable to read superblock
EXT2-fs: unable to read superblock
FAT: unable to read boot sector
UMSDOS: msdos_read_super failed, mount aborted.
FAT: unable to read boot sector
FAT: unable to read boot sector
isofs_read_super: bread failed, dev=09:00, iso_blknum=16, block=32
Mount JFS Failure: -5
Kernel panic: VFS: Unable to mount root fs on 09:00

does any one know what to do ?, cause i can not figure it out, i've
made several attempt changing the parameter of yaboot.conf recompiling
kernel...


thanks.
[EMAIL PROTECTED]

Re: 2 issues Raid, Netatalk

[David Tisdell]

Hi all, 
Gary Sardine has been most helpful with the RAID
issue. When I replied to him after his first post, I
forgot to say reply all and the subsequent
conversation has been between him and me. I thought I
would post the information he has shared for
everyone's benefit. I may not get to attempting to set
it up for a couple of weeks. Here are his helpful
notes:
>On Sun, 2002-12-15 at 05:46, David Tisdell wrote:
> Thanks Gary.

No problem.

> Two points of clarification:
> 1) I would go ahead and install and create mount
> points etc on a single drive (or multiple drives if
I
> wanted /home on a separate drive) and then add raid
> support after the fact yes?

Since you are interested in RAID1, this might work,
but
I have never tried it.  I do want to mention before I
forget that you really should try to have each drive
on
its own IDE channel for software RAID.  With RAID1
it's
not as big a deal as with R0 or R5, though.

I expect it might work to install in a single drive,
duplicate the partition scheme in a second (mirror)
drive, then create /etc/raidtab and use mkraid to make
the RAID1 devices.  I don't know.

What I do with Debian is kind of cheating (becaused I
work at a GNU/Linux PC shop, and we have lots of
hardware
at our disposal), but it might give you ideas.

We have an IDE drive that holds a good Debian
installation.
It boots a kernel that will drive any piece of
hardware
we offer.  We boot a new system (getting Debian) off
of
this hard drive, hanging the hard drive off of a
Promise
PCI IDE card, so it is out of the way of the real
system
drives.  We then partition and format the real system
drives.  In the case of a system entirely on RAID1:

o make partition schemes for each of two hard drives
  identical (software RAID mirrors partitions, not
drives)
o create entries in /etc/raidtab (using an example
copy
  we keep around for reference, changing only things
like
  raid-level and device)
o use mkraid to make the /dev/mdN software RAID
devices.
o formate the software RAID devices /dev/mdN:

  + use mkreiserfs /dev/mdN for ReiserFS.
  + use mke2fs /dev/mdN for ext2
  + use mke2fs -j /dev/mdN for ext3
  + use mkfs.xfs /dev/mdN for SGI's XFS file system.

o Mount the new system inside of /mnt.  e.g., If / is
  RAID1 using /dev/md0 and /home is separate, RAID1
using
  /dev/md1, do:

# mount /dev/md0 /mnt
# mkdir /mnt/home
# mount /dev/hd1 /mnt/home

  The purpose is to _copy_ the running file system
(off of
  our stock Debian drive) into the new devices.  We
drop to
  run level 1 and use cp with certain flags to do this
properly.
  Next, we create directories in /mnt that we will not
cp:

# cd /mnt ; mkdir cdrom floppy proc mnt

o Finally, be sure to be in run level 1 (we do all of
the above
  in run level 1), and do:

# cd / ; cp -a dir1 dir2 ... mnt

  dir1 dir2 ... ranges over every top level directory
(e.g. usr
  home lib ...) except for cdrom floppy proc and mnt,
which we
  do _not_ want to cp).

If I did not have a stock Debian hard drive and a PCI
IDE card
available for this, I would switch to a shell early in
a Debian
installation and create software RAID devices by hand,
format
them (mke2fs -j or whatever), and mount them.

Don't forget, you will need software RAID support
available in
the kernel.  If you will be booting off of a RAID1
array, it's
easiest to compile RAID1 support in rather than using
a module
(else you'll need to use initrd, which Red Hat sets up
behind
the scenes, and Debian does not).

My Debian PPC system has mac-fdisk and not pfdisk;
mac-fdisk is
a lot like fdisk for i386.

Regards,
Gary.


__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: 2 issues Raid, Netatalk

[Gary Sandine]

On Sat, 2002-12-14 at 04:45, David Tisdell wrote:
> The server has dual ultra 3 scsi drives mirrored to
> each other with soft raid (Raid 1). It also has 2
> firewire drives which I would like to mirror in raid
> 1. How do I set up Raid in software? It is very easy
> to do in Red Hat. Can I easily do it in PPC Debian?
> Will my firewire drives work and if so can they do
> Raid 1 as well?

raidtools2 (or raidtools) or mdadm can be used for software
RAID in Debian PPC.  If you are familiar with setting up
software RAID in Red Hat, it will be identical in Debian ppc
using raidtools or raidtools2 (except you will have to write
the config file, which will be easy if you nab a similar one
from your Red Hat system to start with).  You'll have to
use mkraid to make the RAID devices (e.g. /dev/md0), and you'll
have to make a file system in the resulting software RAID
devices.  I know one can specify devices for software RAID
arrays in the Red Hat installer, and the installer does the
work.  But there's not much to it (with raidtools[2], make
/etc/raidtab, run mkraid, format the devices, done).

You will need compiled in or modular RAID support in your
kernel.

I've used firewire hard drives in a Linux PC, and I access
them just as I access any SCSI hard drive (they appear as
SCSI devices, /dev/sda, etc.).  I haven't yet attempted to
use the firewire port in my Mac (it's an iBook2, which I now
like using after blowing away OS X ;).

Re: 2 issues Raid, Netatalk

[simonraven]

On Sat, Dec 14, 2002 at 03:45:18 -0800, David Tisdell composed:

i cant really say about your first issue.

> Hi all,
> Raid 1 as well? I posted this question last summer in
> the Linux PPC newsgroup and never got an answer. That
> was before I knew about this list which is far
> superior to what goes on in the usenet forum.
> One other question regarding Netatalk. I have had
> issues with version 1.5 on Intel hardware and OS X but
> have had no issues with 1.4.x+asun (Adrian Sun's
> version). Are other folks experiencing the same thing.
> Will I have issues with Woody in trying to go back to
> 1.4? Thanks.
> Dave

though about your second issue, i have some experience with, and
netatalk 1.5 is a charm for me. it runs (almost) perfectly - the almost
perfect setup is more an issue with DHCP and if i need to re-connect to
the router (which has the static IP) it doesn't re-allocate an
appleshare address. which i can probably fix with a little ifup/ifdown
script :). 1.4+asun was nice too. i don't know exactly what issue you
have with the intel/os x and netatalk (mac-only LAN as of yet, and the
other mac runs 8.1 - an m68k). but the other box sees the afpd atalkd
daemons just fine (tho i wish linux could mount appleshare volumes, :/).

/end rambling

simon
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

2 issues Raid, Netatalk

[David Tisdell]

Hi all,
I have a blue and white G3 server running Appleshare
IP and I am thinking of converting it to Linux. I want
to understand a few things before undertaking this.
This is a production environment and I can't afford a
long down time for the conversion. It was serving Mac
OS 9 clients and earlier. Those machine have been
upgraded to Mac OS X. A few strange things have been
going on between Appleshare IP and OS X. Apple says
there are issues between the 2 that can't be fixed. 
I have a fair amount of experience with Red Hat on
intel hardware and some experience with Yellow Dog on
PowerPC. I was never able to get an answer from
Yellowdog on how I could make things work the way I
needed them to, so, its Debian, or not converting this
server to Linux.
The server has dual ultra 3 scsi drives mirrored to
each other with soft raid (Raid 1). It also has 2
firewire drives which I would like to mirror in raid
1. How do I set up Raid in software? It is very easy
to do in Red Hat. Can I easily do it in PPC Debian?
Will my firewire drives work and if so can they do
Raid 1 as well? I posted this question last summer in
the Linux PPC newsgroup and never got an answer. That
was before I knew about this list which is far
superior to what goes on in the usenet forum.
One other question regarding Netatalk. I have had
issues with version 1.5 on Intel hardware and OS X but
have had no issues with 1.4.x+asun (Adrian Sun's
version). Are other folks experiencing the same thing.
Will I have issues with Woody in trying to go back to
1.4? Thanks.
Dave

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

RE: eata.c module and PCI setup problem (RAID SCSI card)

[Ballabio_Dario]

Now I understand the problem much better. I plan to redraw the info
structure in full big endian and to perform the correct translation
(both 16 bit word  byte swap and 32 bit word full swap) one for
all in read_pio. 
I'll have a patched version in the next few days.
Cheers,

-db


-Original Message-
From: Antoine Delvaux [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 15, 2002 4:23 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; debian-powerpc@lists.debian.org
Subject: RE: eata.c module and PCI setup problem (RAID SCSI card)


Hello all,


Thank you for your feedback and sorry for being late.  I was the whole
week in a Juniper training in Holland and had not been able to test this
new driver.  I just done it today.

Here is the syslog output I've got when doing 'insmod eata.o' or 'insmod
eata.o io_port=0x1410' :

Jun 15 14:43:50 brocoli kernel: PCI: Enabling device 00:0f.0 (0014 ->
0015)
Jun 15 14:43:50 brocoli kernel: EATA: detect, seq. 0, bus 0, devfn 0x78,
addr 0x1400.
Jun 15 14:43:50 brocoli kernel: EATA0: warning, weird ISA board not
using DMA.
Jun 15 14:43:50 brocoli kernel: EATA0: warning, DMA protocol support not
asserted.
Jun 15 14:43:50 brocoli kernel: EATA0: warning, LEVEL triggering is
suggested for IRQ 3.
Jun 15 14:43:50 brocoli kernel: EATA0: unable to allocate IRQ 3,
detaching.

The module does not load and the card hangs (the two extreme leds lid
up).  For reference the lspci -vv output after that is :

00:0f.0 SCSI storage controller: Distributed Processing Technology
SmartCache/Raid I-IV Controller (rev 02)
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- 
0015)
Jun 15 16:12:14 brocoli kernel: EATA0: warning, weird ISA board not
using DMA.
Jun 15 16:12:14 brocoli kernel: EATA0: warning, DMA protocol support not
asserted.
Jun 15 16:12:14 brocoli kernel: EATA0: warning, LEVEL triggering is
suggested for IRQ 25.
Jun 15 16:12:14 brocoli kernel: EATA/DMA 2.0x: Copyright (C) 1994-2002
Dario Ballabio.
Jun 15 16:12:14 brocoli kernel: EATA config options -> tc:n, lc:n,
mq:16, rs:y, et:n, ip:n, ep:n, pp:y.
Jun 15 16:12:14 brocoli kernel: EATA0: 2.0C, ISA 0x1410, IRQ 25, BMST,
SG 64, MB 64.
Jun 15 16:12:14 brocoli kernel: EATA0: SCSI channel 0 enabled, host
target ID 7.
Jun 15 16:12:14 brocoli kernel: EATA0: Vers. 0x0, ocs 1, tar 0, trnxfr
0, more 1, SYNC 0x19, sec. 0, infol 34, cpl 44 spl 24.
Jun 15 16:12:14 brocoli kernel: EATA0: isaena 0, forcaddr 0, max_id 1,
max_chan 7, large_sg 0, res1 0.
Jun 15 16:12:14 brocoli kernel: EATA0: max_lun 7, m1 1, idquest 0, pci
0, eisa 0, raidnum 0.
Jun 15 16:12:14 brocoli kernel: scsi3 : EATA/DMA 2.0x rev. 6.60.00 
Jun 15 16:12:30 brocoli kernel: EATA0: abort, mbox 1, target 0.0:0, pid
5905.
Jun 15 16:12:30 brocoli kernel: EATA0: abort, mbox 1 is in use.
Jun 15 16:12:30 brocoli kernel: EATA0: reset, enter, target 0.0:0, pid
5905.
Jun 15 16:12:30 brocoli kernel: EATA0: reset, mbox 1 in reset, pid 5905.
Jun 15 16:12:30 brocoli kernel: EATA0: reset, board reset done, enabling
interrupts.
Jun 15 16:12:30 brocoli kernel: EATA0: reset, interrupts disabled, loops
100474.
Jun 15 16:12:30 brocoli kernel: EATA0, reset, mbox 1 locked, DID_RESET,
pid 5905 done.
Jun 15 16:12:30 brocoli kernel: EATA0: reset, exit, pid 5905 done.
Jun 15 16:12:41 brocoli kernel: EATA0: ihdlr, spp->eoc == FALSE, irq 25,
reg 0x51, count 2.
Jun 15 16:12:50 brocoli kernel: EATA0: abort, mbox 2, target 0.0:0, pid
5905.
Jun 15 16:12:50 brocoli kernel: EATA0: abort, mbox 2 is in use.
Jun 15 16:12:50 brocoli kernel: EATA0, abort, mbox 2, eh_state timeout,
pid 5905.
Jun 15 16:12:50 brocoli kernel: scsi: device set offline - not ready or
command retry failed after host reset: host 3 channel 0 id 0 lun 0
Jun 15 16:13:06 brocoli kernel: EATA0: abort, mbox 3, target 0.1:0, pid
5929.
Jun 15 16:13:06 brocoli kernel: EATA0: abort, mbox 3 is in use.
Jun 15 16:13:06 brocoli kernel: EATA0: reset, enter, target 0.1:0, pid
5929.
Jun 15 16:13:06 brocoli kernel: EATA0: reset, locked mbox 1 forced free.
Jun 15 16:13:06 brocoli kernel: EATA0: reset, mbox 3 in reset, pid 5929.
Jun 15 16:13:06 brocoli kernel: EATA0: reset, board reset done, enabling
interrupts.
Jun 15 16:13:06 brocoli kernel: EATA0: reset, interrupts disabled, loops
100469.
Jun 15 16:13:06 brocoli kernel: EATA0, reset, mbox 3 locked, DID_RESET,
pid 5929 done.
Jun 15 16:13:06 brocoli kernel: EATA0: reset, exit, pid 5929 done.
Jun 15 16:13:18 brocoli kernel: EATA0: qcomm, target 0.1:0, pid 5929,
adapter busy.
Jun 15 16:13:26 brocoli kernel: EATA0: abort, target 0.1:0, pid 5929
inactive.
Jun 15 16:13:26 brocoli kernel: scsi: device set offline - not ready or
command retry failed after host reset: host 3 channel 0 id 1 lun 0
Jun 15 16:13:28 brocoli kernel: EATA0: qcomm, target 0.2:0, pid 5950,
adapter busy.

And then insmod and the card are hanging... with no o

RE: eata.c module and PCI setup problem (RAID SCSI card)

[Antoine Delvaux]

Hello all,


Thank you for your feedback and sorry for being late.  I was the whole
week in a Juniper training in Holland and had not been able to test this
new driver.  I just done it today.

Here is the syslog output I've got when doing 'insmod eata.o' or 'insmod
eata.o io_port=0x1410' :

Jun 15 14:43:50 brocoli kernel: PCI: Enabling device 00:0f.0 (0014 ->
0015)
Jun 15 14:43:50 brocoli kernel: EATA: detect, seq. 0, bus 0, devfn 0x78,
addr 0x1400.
Jun 15 14:43:50 brocoli kernel: EATA0: warning, weird ISA board not
using DMA.
Jun 15 14:43:50 brocoli kernel: EATA0: warning, DMA protocol support not
asserted.
Jun 15 14:43:50 brocoli kernel: EATA0: warning, LEVEL triggering is
suggested for IRQ 3.
Jun 15 14:43:50 brocoli kernel: EATA0: unable to allocate IRQ 3,
detaching.

The module does not load and the card hangs (the two extreme leds lid
up).  For reference the lspci -vv output after that is :

00:0f.0 SCSI storage controller: Distributed Processing Technology
SmartCache/Raid I-IV Controller (rev 02)
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- 
0015)
Jun 15 16:12:14 brocoli kernel: EATA0: warning, weird ISA board not
using DMA.
Jun 15 16:12:14 brocoli kernel: EATA0: warning, DMA protocol support not
asserted.
Jun 15 16:12:14 brocoli kernel: EATA0: warning, LEVEL triggering is
suggested for IRQ 25.
Jun 15 16:12:14 brocoli kernel: EATA/DMA 2.0x: Copyright (C) 1994-2002
Dario Ballabio.
Jun 15 16:12:14 brocoli kernel: EATA config options -> tc:n, lc:n,
mq:16, rs:y, et:n, ip:n, ep:n, pp:y.
Jun 15 16:12:14 brocoli kernel: EATA0: 2.0C, ISA 0x1410, IRQ 25, BMST,
SG 64, MB 64.
Jun 15 16:12:14 brocoli kernel: EATA0: SCSI channel 0 enabled, host
target ID 7.
Jun 15 16:12:14 brocoli kernel: EATA0: Vers. 0x0, ocs 1, tar 0, trnxfr
0, more 1, SYNC 0x19, sec. 0, infol 34, cpl 44 spl 24.
Jun 15 16:12:14 brocoli kernel: EATA0: isaena 0, forcaddr 0, max_id 1,
max_chan 7, large_sg 0, res1 0.
Jun 15 16:12:14 brocoli kernel: EATA0: max_lun 7, m1 1, idquest 0, pci
0, eisa 0, raidnum 0.
Jun 15 16:12:14 brocoli kernel: scsi3 : EATA/DMA 2.0x rev. 6.60.00 
Jun 15 16:12:30 brocoli kernel: EATA0: abort, mbox 1, target 0.0:0, pid
5905.
Jun 15 16:12:30 brocoli kernel: EATA0: abort, mbox 1 is in use.
Jun 15 16:12:30 brocoli kernel: EATA0: reset, enter, target 0.0:0, pid
5905.
Jun 15 16:12:30 brocoli kernel: EATA0: reset, mbox 1 in reset, pid 5905.
Jun 15 16:12:30 brocoli kernel: EATA0: reset, board reset done, enabling
interrupts.
Jun 15 16:12:30 brocoli kernel: EATA0: reset, interrupts disabled, loops
100474.
Jun 15 16:12:30 brocoli kernel: EATA0, reset, mbox 1 locked, DID_RESET,
pid 5905 done.
Jun 15 16:12:30 brocoli kernel: EATA0: reset, exit, pid 5905 done.
Jun 15 16:12:41 brocoli kernel: EATA0: ihdlr, spp->eoc == FALSE, irq 25,
reg 0x51, count 2.
Jun 15 16:12:50 brocoli kernel: EATA0: abort, mbox 2, target 0.0:0, pid
5905.
Jun 15 16:12:50 brocoli kernel: EATA0: abort, mbox 2 is in use.
Jun 15 16:12:50 brocoli kernel: EATA0, abort, mbox 2, eh_state timeout,
pid 5905.
Jun 15 16:12:50 brocoli kernel: scsi: device set offline - not ready or
command retry failed after host reset: host 3 channel 0 id 0 lun 0
Jun 15 16:13:06 brocoli kernel: EATA0: abort, mbox 3, target 0.1:0, pid
5929.
Jun 15 16:13:06 brocoli kernel: EATA0: abort, mbox 3 is in use.
Jun 15 16:13:06 brocoli kernel: EATA0: reset, enter, target 0.1:0, pid
5929.
Jun 15 16:13:06 brocoli kernel: EATA0: reset, locked mbox 1 forced free.
Jun 15 16:13:06 brocoli kernel: EATA0: reset, mbox 3 in reset, pid 5929.
Jun 15 16:13:06 brocoli kernel: EATA0: reset, board reset done, enabling
interrupts.
Jun 15 16:13:06 brocoli kernel: EATA0: reset, interrupts disabled, loops
100469.
Jun 15 16:13:06 brocoli kernel: EATA0, reset, mbox 3 locked, DID_RESET,
pid 5929 done.
Jun 15 16:13:06 brocoli kernel: EATA0: reset, exit, pid 5929 done.
Jun 15 16:13:18 brocoli kernel: EATA0: qcomm, target 0.1:0, pid 5929,
adapter busy.
Jun 15 16:13:26 brocoli kernel: EATA0: abort, target 0.1:0, pid 5929
inactive.
Jun 15 16:13:26 brocoli kernel: scsi: device set offline - not ready or
command retry failed after host reset: host 3 channel 0 id 1 lun 0
Jun 15 16:13:28 brocoli kernel: EATA0: qcomm, target 0.2:0, pid 5950,
adapter busy.

And then insmod and the card are hanging... with no other possibility
than a reboot.  I suppose the 4 bits in eata_info for the IRQ should be
translated to something else ... but in what ?  I also suppose there are
other thing in this struct that have to be translated.  I'll try to
print the whole eata_info struct if I have time tomorrow or monday.

If you have other suggestions or improvements, they are welcomed.

Have a nice week-end !

Antoine.

Le lundi 10 juin 2002 vers 7:50, [EMAIL PROTECTED] écrivait :

> I put all the recent findings and suggestions in the enclosed source.
> It is tested on

RE: eata.c module and PCI setup problem (RAID SCSI card)

[Geert Uytterhoeven]

On Mon, 10 Jun 2002 [EMAIL PROTECTED] wrote:
> Unfortunately the EATA PIO protocol just works for 16 bits transfers,
> so inw is the only option. 
> le16_to_cpu(inw()) should give the expected result for both BE and LE.
> Since the detection routine checks for both "EATA" and "ATAE" signatures,
> all should be fine if immediately after the test
> if (info.sign == EATA_SIG_LE)
> is dropped.

I see.

> I'll add a new boot option which skips ISA and EISA probing  in order
> to make the detection more flexible across architectures.

Perhaps you can just protect it by #ifdef CONFIG_ISA and #ifdef CONFIG_EISA?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: eata.c module and PCI setup problem (RAID SCSI card)

[Ballabio_Dario]

Unfortunately the EATA PIO protocol just works for 16 bits transfers,
so inw is the only option. 
le16_to_cpu(inw()) should give the expected result for both BE and LE.
Since the detection routine checks for both "EATA" and "ATAE" signatures,
all should be fine if immediately after the test
if (info.sign == EATA_SIG_LE)
is dropped.
 
I'll add a new boot option which skips ISA and EISA probing  in order
to make the detection more flexible across architectures.

We made one more step, let's see what config data is on the board now.
On i386 the bios put the board in a minimal usable state, on ppc some
other step might be required.


Ph.D. Dario Ballabio
EMC Computer Systems Italia spa
Mobile phone +393487978851
Office phone +390244571315
Mobile fax   +393487951622

Se un uomo non è disposto a rischiare per le proprie idee,
o le sue idee non valgono niente o non vale niente lui.
---
From: Geert Uytterhoeven [mailto:[EMAIL PROTECTED]
Sent: Monday, June 10, 2002 9:53 AM
To: Michel Lanners
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Debian GNU/Linux PPC
Subject: Re: eata.c module and PCI setup problem (RAID SCSI card)


On Sun, 9 Jun 2002, Michel Lanners wrote:
> On   9 Jun, this message from [EMAIL PROTECTED] echoed through
cyberspace:
> > With this value both the auto detection and the io_port option
> > would give the same (good) behavior.
> > The real problem is that the driver expects the "EATA" signature
> > (big endian) while you get "AEAT". It looks like you have a 16 bit
> > system.
> 
> No, no, this is not about a 16- or 32-bit-system. This is about the way
> the data is read from the device.
> 
> Looking at the struct eata_info that you are reading from the device,
> this looks to me like a stream of bytes of varying size. But you are
> reading it in 16-bit quantities over a byte-swapping barrier: PCI is
> little-endian, powerpc is big-endian. Therefore all data transfers going
> to/coming from the PCI bus are byte-swapped.
> 
> The solution here is to not byteswap the data that you are reading from
> the device, so that the byte stream that you are reading keeps the right
> byte alignment.

If it's a struct, you should read the individual fields using in[bwl](),
depending on their size. Then they will be correctly swapped, and you'll
have
portable code.

> To the debian-powerpc list: what is the correct replacement for inw()
> that doesn't do byteswap?

But that wouldn't be portable across architectures.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
[EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like
that.
-- Linus
Torvalds


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: eata.c module and PCI setup problem (RAID SCSI card)

[Geert Uytterhoeven]

On Sun, 9 Jun 2002, Michel Lanners wrote:
> On   9 Jun, this message from [EMAIL PROTECTED] echoed through cyberspace:
> > With this value both the auto detection and the io_port option
> > would give the same (good) behavior.
> > The real problem is that the driver expects the "EATA" signature
> > (big endian) while you get "AEAT". It looks like you have a 16 bit
> > system.
> 
> No, no, this is not about a 16- or 32-bit-system. This is about the way
> the data is read from the device.
> 
> Looking at the struct eata_info that you are reading from the device,
> this looks to me like a stream of bytes of varying size. But you are
> reading it in 16-bit quantities over a byte-swapping barrier: PCI is
> little-endian, powerpc is big-endian. Therefore all data transfers going
> to/coming from the PCI bus are byte-swapped.
> 
> The solution here is to not byteswap the data that you are reading from
> the device, so that the byte stream that you are reading keeps the right
> byte alignment.

If it's a struct, you should read the individual fields using in[bwl](),
depending on their size. Then they will be correctly swapped, and you'll have
portable code.

> To the debian-powerpc list: what is the correct replacement for inw()
> that doesn't do byteswap?

But that wouldn't be portable across architectures.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: eata.c module and PCI setup problem (RAID SCSI card)

[Ballabio_Dario]

Inside the driver I consistently use the address 
from pci_resource_start(dev, 0) + PCI_BASE_ADDRESS_0.
That's the origin of the 0x10 offset in the io_port compared to 
the resource start value.

Apart from this I see your point and it is basically correct.
 I'm thinking about using inb() in read_pio as an 
alternative to the
*p = le16_to_cpu(inw(iobase));
which would be a nop on i386 and byte swap halfwords
on PPC.
Once the config structure is read consistently (i.e. cleaned
from the endianess problem introduced by inw)
the H2DEV, DEV2H etc take care ov the endianess in a
portable way. Let's see if the driver works first.

-db

-Original Message-
From: Michel Lanners
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; debian-powerpc@lists.debian.org
Sent: 09/06/02 17.16
Subject: Re: eata.c module and PCI setup problem (RAID SCSI card)

Hi Ballabio,

On   9 Jun, this message from [EMAIL PROTECTED] echoed through
cyberspace:
>  If lspci reports I/O address 0x1400 you must use io_port=0x1410,
> the additional 0x10 is the io_base_address_0 offset.

Are you sure that this is the reason for the offset? io_base_address_0
is at offset 0x10 _in_config_space_, while we're talking here of
_io_space_. I'd rather think this is a (device-spcific) offset in the
device's IO region that happens to be 0x10 in this case.

> With this value both the auto detection and the io_port option
> would give the same (good) behavior.
> The real problem is that the driver expects the "EATA" signature
> (big endian) while you get "AEAT". It looks like you have a 16 bit
> system.

No, no, this is not about a 16- or 32-bit-system. This is about the way
the data is read from the device.

Looking at the struct eata_info that you are reading from the device,
this looks to me like a stream of bytes of varying size. But you are
reading it in 16-bit quantities over a byte-swapping barrier: PCI is
little-endian, powerpc is big-endian. Therefore all data transfers going
to/coming from the PCI bus are byte-swapped.

The solution here is to not byteswap the data that you are reading from
the device, so that the byte stream that you are reading keeps the right
byte alignment.

To the debian-powerpc list: what is the correct replacement for inw()
that doesn't do byteswap?

> The driver knows that the EATA protocol mandates big endian
> and uses the cpu_to_be32 and cpu_to_be16 for host to dev conversion.
> It uses be32_to_cpu and be16_to_cpu for device to host conversion.

Not for reading the signature. That uses read_pio() which calls inw().
Therefore, your swapped signature for big-endian is not working: we're
not in the presence of a byte-swapped 32-bit quantity (your
EATA_SIG_BE), but a concatenation of two byte-swapped 16-bit quantities
(because you're reading with inw, which reads 16 bits at a time).

> You can try to use the correct conversion routines for your system
> by setting correctly the H2DEV, H2DEVS, DEV2H, DEV2HS macros
> (refer to the last source I sent).

They are probably OK (though I could be wrong...). Antoine should try
the hack I sent him for changing read_pio, and we should work on from
these results.

Cheers

Michel

> -Original Message-
> From: Antoine Delvaux
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Sent: 09/06/02 8.20
> Subject: Re: eata.c module and PCI setup problem (RAID SCSI card)
> 
> Hello Michel and Ballabio,
> 
> I've integrated the few debug changes from Michel and new Ballabio's
> code.  Here are a few answers and description of what is happening
now. 
> But I want to already thank you for your support so far.
> 
>>> And here is the output when doing 'insmod eata.o' alone :
> 
> I now have the following :
> 
> Jun  9 13:10:21 brocoli kernel: eata.c: checking PCI ports.
> Jun  9 13:10:21 brocoli kernel: EATA: detect, seq. 0, bus 0, devfn
0x78,
> addr 0x1400.
> Jun  9 13:10:21 brocoli kernel: eata.c: no more matching PCI device.
> Jun  9 13:10:21 brocoli kernel: EATA0: signature 0x41454154 discarded.
> 
> And then nothing more, no bad IN's (should this be consider good or
> strange ?) and the card hangs with the two exterior leds lit up.  When
> doing lspci -vv I still have
> 
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> 
> So the card is well enabled.
> 
> The last log line is coming from the port_detect function when
checking
> the EATA signature.  What is this signature and why is it wrong ?
> 
> And with 'insmod eata.o io_port=0x1400' :
> 
> Jun  9 13:41:00 brocoli kernel: eata.c: io_port modified by module
> options.
> Jun  9 13:41:00 brocoli kernel: eata.c: setup_done is set; skipping
PCI
> probe.
> Jun  9 13:41:00 brocoli kernel: EATA: enable_pci_ports, bus 0, d

Re: eata.c module and PCI setup problem (RAID SCSI card)

[Michel Lanners]

Hi Ballabio,

On   9 Jun, this message from [EMAIL PROTECTED] echoed through cyberspace:
>  If lspci reports I/O address 0x1400 you must use io_port=0x1410,
> the additional 0x10 is the io_base_address_0 offset.

Are you sure that this is the reason for the offset? io_base_address_0
is at offset 0x10 _in_config_space_, while we're talking here of
_io_space_. I'd rather think this is a (device-spcific) offset in the
device's IO region that happens to be 0x10 in this case.

> With this value both the auto detection and the io_port option
> would give the same (good) behavior.
> The real problem is that the driver expects the "EATA" signature
> (big endian) while you get "AEAT". It looks like you have a 16 bit
> system.

No, no, this is not about a 16- or 32-bit-system. This is about the way
the data is read from the device.

Looking at the struct eata_info that you are reading from the device,
this looks to me like a stream of bytes of varying size. But you are
reading it in 16-bit quantities over a byte-swapping barrier: PCI is
little-endian, powerpc is big-endian. Therefore all data transfers going
to/coming from the PCI bus are byte-swapped.

The solution here is to not byteswap the data that you are reading from
the device, so that the byte stream that you are reading keeps the right
byte alignment.

To the debian-powerpc list: what is the correct replacement for inw()
that doesn't do byteswap?

> The driver knows that the EATA protocol mandates big endian
> and uses the cpu_to_be32 and cpu_to_be16 for host to dev conversion.
> It uses be32_to_cpu and be16_to_cpu for device to host conversion.

Not for reading the signature. That uses read_pio() which calls inw().
Therefore, your swapped signature for big-endian is not working: we're
not in the presence of a byte-swapped 32-bit quantity (your
EATA_SIG_BE), but a concatenation of two byte-swapped 16-bit quantities
(because you're reading with inw, which reads 16 bits at a time).

> You can try to use the correct conversion routines for your system
> by setting correctly the H2DEV, H2DEVS, DEV2H, DEV2HS macros
> (refer to the last source I sent).

They are probably OK (though I could be wrong...). Antoine should try
the hack I sent him for changing read_pio, and we should work on from
these results.

Cheers

Michel

> -Original Message-
> From: Antoine Delvaux
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Sent: 09/06/02 8.20
> Subject: Re: eata.c module and PCI setup problem (RAID SCSI card)
> 
> Hello Michel and Ballabio,
> 
> I've integrated the few debug changes from Michel and new Ballabio's
> code.  Here are a few answers and description of what is happening now. 
> But I want to already thank you for your support so far.
> 
>>> And here is the output when doing 'insmod eata.o' alone :
> 
> I now have the following :
> 
> Jun  9 13:10:21 brocoli kernel: eata.c: checking PCI ports.
> Jun  9 13:10:21 brocoli kernel: EATA: detect, seq. 0, bus 0, devfn 0x78,
> addr 0x1400.
> Jun  9 13:10:21 brocoli kernel: eata.c: no more matching PCI device.
> Jun  9 13:10:21 brocoli kernel: EATA0: signature 0x41454154 discarded.
> 
> And then nothing more, no bad IN's (should this be consider good or
> strange ?) and the card hangs with the two exterior leds lit up.  When
> doing lspci -vv I still have
> 
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> 
> So the card is well enabled.
> 
> The last log line is coming from the port_detect function when checking
> the EATA signature.  What is this signature and why is it wrong ?
> 
> And with 'insmod eata.o io_port=0x1400' :
> 
> Jun  9 13:41:00 brocoli kernel: eata.c: io_port modified by module
> options.
> Jun  9 13:41:00 brocoli kernel: eata.c: setup_done is set; skipping PCI
> probe.
> Jun  9 13:41:00 brocoli kernel: EATA: enable_pci_ports, bus 0, devfn
> 0x78.
> Jun  9 13:41:00 brocoli kernel: PCI: Enabling device 00:0f.0 (0014 ->
> 0015)
> 
> lspci -vv shows the same (I/O ports enabled) but the card does not seems
> to hang this time, the leds are still flashing endlessly in a round
> robin fashion.  I don't know why this time I don't have the signature
> error... but the module is not loaded anyway.  If I launch the command
> again I have the same output except for the last line.
> 
> FYI, I have incorporated Michel's changes at the for loop in
> eata2x_detect.  I now have :
> 
>//   for (k = 0; io_port[k]; k++) {
>for (k = 11; k < 27; k++) {
> 
> BTW, what is this change supposed to do ?
> 
> Something else, what is the 'FORCE_CONFIG' option for ?  I've tried
> using it but it doesn'

RE: eata.c module and PCI setup problem (RAID SCSI card)

[Ballabio_Dario]

I only agree on the fact that if the io_port is specified as a parameter or
boot option pci_enable_device in not called.
This is easily fixed by adding this fragment of code at the
beginning of port_detect:

   return FALSE;
   }
 
+   pdev = get_pci_dev(port_base);
+
+   if (pdev && !pci_enable_device(pdev)) {
+  printk("%s: detect, pci_enable_device failed at 0x%03lx.\n",
+ name, port_base);
+  return FALSE;
+  }
+
if (do_dma(port_base, 0, READ_CONFIG_PIO)) {
 #if defined(DEBUG_DETECT)
   printk("%s: detect, do_dma failed at 0x%03lx.\n", name, port_base);

Anyway this is not sufficient to fix the problem, since the port has failed
to work even when pci_enable_device was called.

-db



-Original Message-
From: Michel Lanners [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 06, 2002 9:16 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; debian-powerpc@lists.debian.org
Subject: Re: eata.c module and PCI setup problem (RAID SCSI card)


Hi,

On   6 Jun, this message from [EMAIL PROTECTED] echoed through
cyberspace:
> The eata driver really does not care whether it is using an ISA, EISA or
PCI
> board

It should, though. On most (all?) platforms besides i386, there are huge
differences between ISA/EISA and PCI. You can't just assume that IO
ports work the i386 way on all platforms. But there are ways to code it
so that it does work everywhere.

> as long as it has identified the I/O address where the EATA registers are
> available.
> The PCI detection routine find out an I/O address, nothing else. If you do
> not
> specify the io_port=0x1400 parameter at module load, it looks for all the
> possible addresses in a static list (well known ISA and EISA addresses)
> enlarged with the detected PCI addresses. Then it uses wait_on_busy
polling
> the board until it is free or a max number of polls is reached before
giving
> up
> (this overflows syslog buffer of messages from traps.c),
> for every address in the list. 0x330 happens to be the last address on the
> list.
> If you specify io_port=0x1400 this is the only address probed.

Well, on platforms other than i386 you can't assume that the device has
been enabled by the BIOS. The minimum you need to do is enable the
device via pci_enable_device(). You're doing that only if no io_port=
option has been specified. Problem.

> AFAIK this MAC does not respond at all to I/O port 0x1400, the inb()
fails,

Yes, because the device is not enabled. inb() does work in general (it
may not for _other_ reasons in this specific case).

> There is nothing I can do to fix the problem until inb()
> is able to read one byte from the board registers.

OK, agreed. But we may need your help to find out why the PCI device is
not enabled...
 
> End of story.

No, beginning of the story :)

Cheers

Michel

-
Michel Lanners |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes|Ask Questions.  Make Mistakes.
L-1710 Luxembourg  |
email   [EMAIL PROTECTED]|
http://www.cpu.lu/~mlan| Learn Always. "


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: eata.c module and PCI setup problem (RAID SCSI card)

[Michel Lanners]

Hi,

On   6 Jun, this message from [EMAIL PROTECTED] echoed through cyberspace:
> The eata driver really does not care whether it is using an ISA, EISA or PCI
> board

It should, though. On most (all?) platforms besides i386, there are huge
differences between ISA/EISA and PCI. You can't just assume that IO
ports work the i386 way on all platforms. But there are ways to code it
so that it does work everywhere.

> as long as it has identified the I/O address where the EATA registers are
> available.
> The PCI detection routine find out an I/O address, nothing else. If you do
> not
> specify the io_port=0x1400 parameter at module load, it looks for all the
> possible addresses in a static list (well known ISA and EISA addresses)
> enlarged with the detected PCI addresses. Then it uses wait_on_busy polling
> the board until it is free or a max number of polls is reached before giving
> up
> (this overflows syslog buffer of messages from traps.c),
> for every address in the list. 0x330 happens to be the last address on the
> list.
> If you specify io_port=0x1400 this is the only address probed.

Well, on platforms other than i386 you can't assume that the device has
been enabled by the BIOS. The minimum you need to do is enable the
device via pci_enable_device(). You're doing that only if no io_port=
option has been specified. Problem.

> AFAIK this MAC does not respond at all to I/O port 0x1400, the inb() fails,

Yes, because the device is not enabled. inb() does work in general (it
may not for _other_ reasons in this specific case).

> There is nothing I can do to fix the problem until inb()
> is able to read one byte from the board registers.

OK, agreed. But we may need your help to find out why the PCI device is
not enabled...
 
> End of story.

No, beginning of the story :)

Cheers

Michel

-
Michel Lanners |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes|Ask Questions.  Make Mistakes.
L-1710 Luxembourg  |
email   [EMAIL PROTECTED]|
http://www.cpu.lu/~mlan| Learn Always. "


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: eata.c module and PCI setup problem (RAID SCSI card)

[Ballabio_Dario]

The eata driver really does not care whether it is using an ISA, EISA or PCI
board
as long as it has identified the I/O address where the EATA registers are
available.
The PCI detection routine find out an I/O address, nothing else. If you do
not
specify the io_port=0x1400 parameter at module load, it looks for all the
possible addresses in a static list (well known ISA and EISA addresses)
enlarged with the detected PCI addresses. Then it uses wait_on_busy polling
the board until it is free or a max number of polls is reached before giving
up
(this overflows syslog buffer of messages from traps.c),
for every address in the list. 0x330 happens to be the last address on the
list.
If you specify io_port=0x1400 this is the only address probed.

AFAIK this MAC does not respond at all to I/O port 0x1400, the inb() fails,
There is nothing I can do to fix the problem until inb()
is able to read one byte from the board registers. 
End of story.


Ph.D. Dario Ballabio
EMC Computer Systems Italia spa
Mobile phone +393487978851
Office phone +390244571315
Mobile fax   +393487951622

Se un uomo non è disposto a rischiare per le proprie idee,
o le sue idee non valgono niente o non vale niente lui.


-Original Message-
From: Michel Lanners [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 06, 2002 8:09 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; debian-powerpc@lists.debian.org
Subject: Re: eata.c module and PCI setup problem (RAID SCSI card)


On   6 Jun, this message from Antoine Delvaux echoed through cyberspace:
>> > in the module source.  That doesn't output much though... 
>> > 
>> > Jun  5 09:23:22 brocoli kernel: >IN from bad port 338 at d006092c
>> > Jun  5 09:23:22 brocoli kernel: IN from bad port 338 at d006092c
>> > Jun  5 09:23:22 brocoli last message repeated 452 times
>> > Jun  5 09:23:22 brocoli kernel: EATA0: detect, do_dma failed at
> 0x330.
>> 
>> Is there any particular reason why you have different IO ports now?
> 
> Yes, I've tried the card in another PCI port...  And, as you told, that
> didn't helped.

Sorry, I meant why in the above log output you have an IN from port 338
and not port 1408 as in some of your other traces.

[snip]
>> But it's easier to debug after seing the logs produced without io=
>> options. You should definitely get some more debug output.
> 
> I've done it with io= option as well as without.  That didn't changed
> much.  But maybe there's something else in the way preventing me from
> seeing the logs.  Sometimes the logs seems to be truncated in some way. 
> For example :
> 
> Jun  6 00:44:57 brocoli uptimed: moving up to position 36: 0 days,
> 02:29:22
> Jun  6 00:50:39 brocoli kernel: 928
> Jun  6 00:50:39 brocoli kernel: IN from bad port 338 at d0060928
> Jun  6 00:50:39 brocoli last message repeated 454 times
> 
> The first error line is cropped.  Is syslogd (or klogd) not catching
> everything ?

syslog should definitely catch everything. What is amazing is the number
of IN's reported in the logs: 454 reads from a port is a lot for the
detection of a device...

I'd suggest looking through the output of dmesg, but that only prints
the kernel's circular message buffer, which is limited in size. So you
might not get enough old messages that way...

> Something else that can be worthy, after I've tried to load the module,
> the PCI card seems to be hanged.  There are some leds on it, that are
> flashing in cycle after the card is initialized at bootup.  After an
> insmod, the two most external ones light up and stays in this state.  If
> I remember correctly, a few seconds after an insmod on the i386 box, all
> the leds where again flashing in cycle.

That can happen while you poke at it. On thing I'd do in the driver is
remove the ISA and EISA detection routines on PowerMacs (at least for
you as a test); no Mac ever had these busses. Some CHRP machines do; so
that would need some advanced ifdef'ing :).

Cheers

Michel

-
Michel Lanners |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes|Ask Questions.  Make Mistakes.
L-1710 Luxembourg  |
email   [EMAIL PROTECTED]|
http://www.cpu.lu/~mlan| Learn Always. "


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: eata.c module and PCI setup problem (RAID SCSI card)

[Michel Lanners]

On   6 Jun, this message from Antoine Delvaux echoed through cyberspace:
>> > in the module source.  That doesn't output much though... 
>> > 
>> > Jun  5 09:23:22 brocoli kernel: >IN from bad port 338 at d006092c
>> > Jun  5 09:23:22 brocoli kernel: IN from bad port 338 at d006092c
>> > Jun  5 09:23:22 brocoli last message repeated 452 times
>> > Jun  5 09:23:22 brocoli kernel: EATA0: detect, do_dma failed at
> 0x330.
>> 
>> Is there any particular reason why you have different IO ports now?
> 
> Yes, I've tried the card in another PCI port...  And, as you told, that
> didn't helped.

Sorry, I meant why in the above log output you have an IN from port 338
and not port 1408 as in some of your other traces.

[snip]
>> But it's easier to debug after seing the logs produced without io=
>> options. You should definitely get some more debug output.
> 
> I've done it with io= option as well as without.  That didn't changed
> much.  But maybe there's something else in the way preventing me from
> seeing the logs.  Sometimes the logs seems to be truncated in some way. 
> For example :
> 
> Jun  6 00:44:57 brocoli uptimed: moving up to position 36: 0 days,
> 02:29:22
> Jun  6 00:50:39 brocoli kernel: 928
> Jun  6 00:50:39 brocoli kernel: IN from bad port 338 at d0060928
> Jun  6 00:50:39 brocoli last message repeated 454 times
> 
> The first error line is cropped.  Is syslogd (or klogd) not catching
> everything ?

syslog should definitely catch everything. What is amazing is the number
of IN's reported in the logs: 454 reads from a port is a lot for the
detection of a device...

I'd suggest looking through the output of dmesg, but that only prints
the kernel's circular message buffer, which is limited in size. So you
might not get enough old messages that way...

> Something else that can be worthy, after I've tried to load the module,
> the PCI card seems to be hanged.  There are some leds on it, that are
> flashing in cycle after the card is initialized at bootup.  After an
> insmod, the two most external ones light up and stays in this state.  If
> I remember correctly, a few seconds after an insmod on the i386 box, all
> the leds where again flashing in cycle.

That can happen while you poke at it. On thing I'd do in the driver is
remove the ISA and EISA detection routines on PowerMacs (at least for
you as a test); no Mac ever had these busses. Some CHRP machines do; so
that would need some advanced ifdef'ing :).

Cheers

Michel

-
Michel Lanners |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes|Ask Questions.  Make Mistakes.
L-1710 Luxembourg  |
email   [EMAIL PROTECTED]|
http://www.cpu.lu/~mlan| Learn Always. "


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: eata.c module and PCI setup problem (RAID SCSI card)

[Antoine Delvaux]

> > in the module source.  That doesn't output much though... 
> > 
> > Jun  5 09:23:22 brocoli kernel: >IN from bad port 338 at d006092c
> > Jun  5 09:23:22 brocoli kernel: IN from bad port 338 at d006092c
> > Jun  5 09:23:22 brocoli last message repeated 452 times
> > Jun  5 09:23:22 brocoli kernel: EATA0: detect, do_dma failed at
0x330.
> 
> Is there any particular reason why you have different IO ports now?

Yes, I've tried the card in another PCI port...  And, as you told, that
didn't helped.

> Antoine, why are you not getting any output from this code:
> 
> static void add_pci_ports(void) {
> #if defined(CONFIG_PCI)
>unsigned int addr, k;
>struct pci_dev *dev = NULL;
>if (!pci_present()) return;
>for (k = 0; k < MAX_PCI; k++) {
>   if (!(dev = pci_find_class(PCI_CLASS_STORAGE_SCSI << 8, dev)))
break;
>   if (pci_enable_device (dev)) {
> #if defined(DEBUG_PCI_DETECT)
>  printk("%s: detect, bus %d, devfn 0x%x, pci_enable_device
failed.\n",
> driver_name, dev->bus->number, dev->devfn);
> #endif
>  continue;
>  }
>   addr = pci_resource_start (dev, 0);
> #if defined(DEBUG_PCI_DETECT)
>   printk("%s: detect, seq. %d, bus %d, devfn 0x%x, addr 0x%x.\n",
>  driver_name, k, dev->bus->number, dev->devfn, addr);
> #endif
> ^^^
> This here above should print something, shouldn't it? Are you sure you
> have nothing in your logs?
> 
>   /* Order addresses according to rev_scan value */
>   io_port[MAX_INT_PARAM + (rev_scan ? (MAX_PCI - k) : (1 + k))] =
>  addr + PCI_BASE_ADDRESS_0;
>   }
> #endif /* end CONFIG_PCI */
>return;
> }
> 
> 
> Hm, also in eata2x_detect:
> 
> #if defined(MODULE)
>/* io_port could have been modified when loading as a module */
>if(io_port[0] != SKIP) {
>   setup_done = TRUE;
>   io_port[MAX_INT_PARAM] = 0;
>   }
> #endif
> .
>if (!setup_done) add_pci_ports();
> 
> Which means that if you give it an io= option as a module, then
> the PCI bus will not be probed, and the device will not be
> enabled. So, make sure to remove any io= options when doing an
> insmod.

(...)

> But it's easier to debug after seing the logs produced without io=
> options. You should definitely get some more debug output.

I've done it with io= option as well as without.  That didn't changed
much.  But maybe there's something else in the way preventing me from
seeing the logs.  Sometimes the logs seems to be truncated in some way. 
For example :

Jun  6 00:44:57 brocoli uptimed: moving up to position 36: 0 days,
02:29:22
Jun  6 00:50:39 brocoli kernel: 928
Jun  6 00:50:39 brocoli kernel: IN from bad port 338 at d0060928
Jun  6 00:50:39 brocoli last message repeated 454 times

The first error line is cropped.  Is syslogd (or klogd) not catching
everything ?

Something else that can be worthy, after I've tried to load the module,
the PCI card seems to be hanged.  There are some leds on it, that are
flashing in cycle after the card is initialized at bootup.  After an
insmod, the two most external ones light up and stays in this state.  If
I remember correctly, a few seconds after an insmod on the i386 box, all
the leds where again flashing in cycle.

Goodnight,

Antoine.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: eata.c module and PCI setup problem (RAID SCSI card)

[Michel Lanners]

On   5 Jun, this message from Antoine Delvaux echoed through cyberspace:
> Le mercredi 5 juin 2002 vers 8:19, Michel Lanners écrivait :
>>> # insmod eata.o io_port=0x1400
>>   ^^
>> Where are you getting this value from?
>
> I'm getting this addresse from lspci and from previous tries with
> modprobe eata.o (which gives exactly the same results as insmod BTW)

Mmmhh...

> Here is the lspci -vv output regarding this card :
> 
> 00:0f.0 SCSI storage controller: Distributed Processing Technology
> SmartCache/Raid I-IV Controller (rev 02)
> Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop-
   
Here is one of your problems: IO port response is disabled.

> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> SERR-  Latency: 32 (1000ns min, 2000ns max), cache line size 08
> Interrupt: pin A routed to IRQ 25
> BIST result: 00
> Region 0: I/O ports at 1400 [disabled] [size=32]
  ^^
This has the same meaning as 'I/O-' above: the device will not answer
PCI bus IO cycles for its address. That's like talking to a wall, really
:). On PowerMacs (at least), doing this kind of things results in a
Machine Check exception (meaning literally: 'Your computer is broken.
Fix it' :)

> Expansion ROM at 80908000 [disabled] [size=32K]
> 
>>> # tail /var/log/syslog Jun  4 13:52:38 brocoli kernel: IN from bad
>>> port 1408 at d005392c

Luckily, accesses to IO ports where no device answers are caught by the
exception handler and reported like you have seen above.

>> I've looked at the code a bit; can you try to recompile the eata
>> module with DEBUG_PCI_DETECT defined, and send the kernel's log
>> output? Also, try an insmod without the io= option.
> 
> I already have 
> 
> #define  DEBUG_DETECT
> #define  DEBUG_PCI_DETECT
> 
> in the module source.  That doesn't output much though... 
> 
> Jun  5 09:23:22 brocoli kernel: >IN from bad port 338 at d006092c
> Jun  5 09:23:22 brocoli kernel: IN from bad port 338 at d006092c
> Jun  5 09:23:22 brocoli last message repeated 452 times
> Jun  5 09:23:22 brocoli kernel: EATA0: detect, do_dma failed at 0x330.

Is there any particular reason why you have different IO ports now?

> I also tried to put the card in another PCI slot (already in use before,
> I swaped two cards) and I've got the same result (when doing a
> modprobe)...

That won't help in a 7500; the three PCI slots are 100% identical.

On   5 Jun, this message from Geert Uytterhoeven echoed through cyberspace:
> Apparently your PowerMac doesn't support PCI I/O??

Na, nonsense. For once Apple respected some standards and made the PCI
bus really do IO cycles :)

Antoine, why are you not getting any output from this code:

static void add_pci_ports(void) {
#if defined(CONFIG_PCI)
   unsigned int addr, k;
   struct pci_dev *dev = NULL;
   if (!pci_present()) return;
   for (k = 0; k < MAX_PCI; k++) {
  if (!(dev = pci_find_class(PCI_CLASS_STORAGE_SCSI << 8, dev))) break;
  if (pci_enable_device (dev)) {
#if defined(DEBUG_PCI_DETECT)
 printk("%s: detect, bus %d, devfn 0x%x, pci_enable_device failed.\n",
driver_name, dev->bus->number, dev->devfn);
#endif
 continue;
 }
  addr = pci_resource_start (dev, 0);
#if defined(DEBUG_PCI_DETECT)
  printk("%s: detect, seq. %d, bus %d, devfn 0x%x, addr 0x%x.\n",
 driver_name, k, dev->bus->number, dev->devfn, addr);
#endif
^^^
This here above should print something, shouldn't it? Are you sure you
have nothing in your logs?

  /* Order addresses according to rev_scan value */
  io_port[MAX_INT_PARAM + (rev_scan ? (MAX_PCI - k) : (1 + k))] =
 addr + PCI_BASE_ADDRESS_0;
  }
#endif /* end CONFIG_PCI */
   return;
}


Hm, also in eata2x_detect:

#if defined(MODULE)
   /* io_port could have been modified when loading as a module */
   if(io_port[0] != SKIP) {
  setup_done = TRUE;
  io_port[MAX_INT_PARAM] = 0;
  }
#endif

   if (!setup_done) add_pci_ports();

Which means that if you give it an io= option as a module, then the PCI
bus will not be probed, and the device will not be enabled. So, make
sure to remove any io= options when doing an insmod.

Here's something else I don't understand:

  /* Order addresses according to rev_scan value */
  io_port[MAX_INT_PARAM + (rev_scan ? (MAX_PCI - k) : (1 + k))] =
 addr + PCI_BASE_ADDRESS_0;
  }

addr + PCI_BASE_ADDRESS_0??

Later, while probing deivce type, the driver tries to do DMA with the
newly found device. Th

Re: eata.c module and PCI setup problem (RAID SCSI card)

[Geert Uytterhoeven]

On Wed, 5 Jun 2002, Antoine Delvaux wrote:
> > > >> # insmod eata.o io_port=0x1400
> > > >   ^^
> > > > Where are you getting this value from? I'm sure it is wrong... Have
> > > > a look at the boot messages of your kernel, and also send along the
> > > > output of 'lspci -vv'.
> > >
> > > I'm getting this addresse from lspci and from previous tries with
> > > modprobe eata.o (which gives exactly the same results as insmod BTW)
> > > Here is the lspci -vv output regarding this card :
> > >
> > > 00:0f.0 SCSI storage controller: Distributed Processing Technology
> > > SmartCache/Raid I-IV Controller (rev 02)
> > > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> > > ParErr- Stepping- SERR- FastB2B-
> > > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> > > SERR-  > > Latency: 32 (1000ns min, 2000ns max), cache line size 08
> > > Interrupt: pin A routed to IRQ 25
> > > BIST result: 00
> > > Region 0: I/O ports at 1400 [disabled] [size=32]
> > > Expansion ROM at 80908000 [disabled] [size=32K]
> > >
> > > >> # tail /var/log/syslog Jun  4 13:52:38 brocoli kernel: IN from bad
> > > >> port 1408 at d005392c
> > > >
> > > > This message means you are trying to read from an address where no
> > > > device is listening. Either the IO port (0x1408) is wrong, or the
> > > > device isn't configured to reply to IO accesses on the PCI bus.
> > >
> > > Why could the device not be configured to reply to IO accesses on the
> > > PCI bus ?
> > 
> > Because no one enabled it?
> > 
> > Apparently the eata driver doesn't call pci_enable_device().
> 
> No, I think it does it, as I can see from the source, but does it does it 
> at the good time ? :

  [...]

> The driver code is working very fine with the same card on i386 box...  
> What are the differences regarding PCI bus between i386 and ppc ?

I guess the card has a PC BIOS? Then on ia32 it will be enabled during BIOS
init.

> BTW, what doean mean the 'disabled' in the lspci output, just not enabled 
> ?  Should the call to pci_enable_device() change this status ? :

Yes. Yes.

> > > Region 0: I/O ports at 1400 [disabled] [size=32]
> > > Expansion ROM at 80908000 [disabled] [size=32K]

Does it change after the call to pci_enable_device()?

> Also, the syslog extract :
> 
> > > >> # tail /var/log/syslog Jun  4 13:52:38 brocoli kernel: IN from bad
> > > >> port 1408 at d005392c
> 
> is apparantly comming from arch/ppc/kernel/traps.c  When could this trap 
> be reached ?

Apparently your PowerMac doesn't support PCI I/O??

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: eata.c module and PCI setup problem (RAID SCSI card)

[Antoine Delvaux]

> >> # insmod eata.o io_port=0x1400
> >   ^^
> > Where are you getting this value from? I'm sure it is wrong... Have
> > a look at the boot messages of your kernel, and also send along the
> > output of 'lspci -vv'.
>
> I'm getting this addresse from lspci and from previous tries with
> modprobe eata.o (which gives exactly the same results as insmod BTW)
> Here is the lspci -vv output regarding this card :
>
> 00:0f.0 SCSI storage controller: Distributed Processing Technology
> SmartCache/Raid I-IV Controller (rev 02)
> Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> SERR-  Latency: 32 (1000ns min, 2000ns max), cache line size 08
> Interrupt: pin A routed to IRQ 25
> BIST result: 00
> Region 0: I/O ports at 1400 [disabled] [size=32]
> Expansion ROM at 80908000 [disabled] [size=32K]
>
> >> # tail /var/log/syslog Jun  4 13:52:38 brocoli kernel: IN from bad
> >> port 1408 at d005392c
> >
> > This message means you are trying to read from an address where no
> > device is listening. Either the IO port (0x1408) is wrong, or the
> > device isn't configured to reply to IO accesses on the PCI bus.
>
> Why could the device not be configured to reply to IO accesses on the
> PCI bus ?

Because no one enabled it?

Apparently the eata driver doesn't call pci_enable_device().


No, I think it does it, as I can see from the source, but does it does it 
at the good time ? :


---

static void add_pci_ports(void) {

#if defined(CONFIG_PCI)

   unsigned int addr, k;

   struct pci_dev *dev = NULL;

   if (!pci_present()) return;

   for (k = 0; k < MAX_PCI; k++) {

  if (!(dev = pci_find_class(PCI_CLASS_STORAGE_SCSI << 8, dev))) 
break;


  if (pci_enable_device (dev)) {

#if defined(DEBUG_PCI_DETECT)
 printk("%s: detect, bus %d, devfn 0x%x, pci_enable_device 
failed.\n",

driver_name, dev->bus->number, dev->devfn);
#endif

 continue;
 }

  addr = pci_resource_start (dev, 0);

---

The driver code is working very fine with the same card on i386 box...  
What are the differences regarding PCI bus between i386 and ppc ?


BTW, what doean mean the 'disabled' in the lspci output, just not enabled 
?  Should the call to pci_enable_device() change this status ? :



> Region 0: I/O ports at 1400 [disabled] [size=32]
> Expansion ROM at 80908000 [disabled] [size=32K]


Also, the syslog extract :


> >> # tail /var/log/syslog Jun  4 13:52:38 brocoli kernel: IN from bad
> >> port 1408 at d005392c


is apparantly comming from arch/ppc/kernel/traps.c  When could this trap 
be reached ?


Antoine.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: eata.c module and PCI setup problem (RAID SCSI card)

[Geert Uytterhoeven]

On Wed, 5 Jun 2002, Antoine Delvaux wrote:
> Le mercredi 5 juin 2002 vers 8:19, Michel Lanners écrivait :
> > On   4 Jun, this message from Antoine Delvaux echoed through
> > cyberspace:
> >> Since two days I've been in touch with the developper of the eata.c
> >> driver (Ballabio Dario) and he gave me a few debug version of that
> >> driver to play with.  Unfortunately we have come to a point where he
> >> can't do more since the problem seems to come from PCI code of the
> >> ppc kernel tree.
> >> 
> >> If anyone here have experience in this field, I welcome his advices
> >> as do not know where to start to search.  With the latest debugging
> >> enabled eata.c module given by Ballabio, I've got the following
> >> output :
> > 
> > I had some similar problems when trying to make a Promise IDE card
> > work in my Mac... but that was a few years ago.
> > 
> >> # insmod eata.o io_port=0x1400
> >   ^^
> > Where are you getting this value from? I'm sure it is wrong... Have a
> > look at the boot messages of your kernel, and also send along the
> > output of 'lspci -vv'.
> 
> I'm getting this addresse from lspci and from previous tries with
> modprobe eata.o (which gives exactly the same results as insmod BTW)
> Here is the lspci -vv output regarding this card :
> 
> 00:0f.0 SCSI storage controller: Distributed Processing Technology
> SmartCache/Raid I-IV Controller (rev 02)
> Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> SERR-  Latency: 32 (1000ns min, 2000ns max), cache line size 08
> Interrupt: pin A routed to IRQ 25
> BIST result: 00
> Region 0: I/O ports at 1400 [disabled] [size=32]
> Expansion ROM at 80908000 [disabled] [size=32K]
> 
> >> # tail /var/log/syslog Jun  4 13:52:38 brocoli kernel: IN from bad
> >> port 1408 at d005392c
> > 
> > This message means you are trying to read from an address where no
> > device is listening. Either the IO port (0x1408) is wrong, or the
> > device isn't configured to reply to IO accesses on the PCI bus.
> 
> Why could the device not be configured to reply to IO accesses on the
> PCI bus ?

Because no one enabled it?

Apparently the eata driver doesn't call pci_enable_device().

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: eata.c module and PCI setup problem (RAID SCSI card)

[Antoine Delvaux]

Le mercredi 5 juin 2002 vers 8:19, Michel Lanners écrivait :

> On   4 Jun, this message from Antoine Delvaux echoed through
> cyberspace:
>> Since two days I've been in touch with the developper of the eata.c
>> driver (Ballabio Dario) and he gave me a few debug version of that
>> driver to play with.  Unfortunately we have come to a point where he
>> can't do more since the problem seems to come from PCI code of the
>> ppc kernel tree.
>> 
>> If anyone here have experience in this field, I welcome his advices
>> as do not know where to start to search.  With the latest debugging
>> enabled eata.c module given by Ballabio, I've got the following
>> output :
> 
> I had some similar problems when trying to make a Promise IDE card
> work in my Mac... but that was a few years ago.
> 
>> # insmod eata.o io_port=0x1400
>   ^^
> Where are you getting this value from? I'm sure it is wrong... Have a
> look at the boot messages of your kernel, and also send along the
> output of 'lspci -vv'.

I'm getting this addresse from lspci and from previous tries with
modprobe eata.o (which gives exactly the same results as insmod BTW)
Here is the lspci -vv output regarding this card :

00:0f.0 SCSI storage controller: Distributed Processing Technology
SmartCache/Raid I-IV Controller (rev 02)
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- > # tail /var/log/syslog Jun  4 13:52:38 brocoli kernel: IN from bad
>> port 1408 at d005392c
> 
> This message means you are trying to read from an address where no
> device is listening. Either the IO port (0x1408) is wrong, or the
> device isn't configured to reply to IO accesses on the PCI bus.

Why could the device not be configured to reply to IO accesses on the
PCI bus ?

>> And here is his answer :
>> 
>>  The message IN from bad port 1408 at d005392c comes from
>> linux/arch/ppc/kernel/traps.c (about line 162, inside #ifdef
>> CONFIG_ALL_PPC) It looks like your setup is not able to read a single
>> byte from location 0x1408. This is what I'm trying to do to see if
>> the board is there (inb(0x1400 + eata_reg_offset). So either you can
>> fix your hw/kernel parameters in order to allow inb() from a legal
>> I/O port address,
> 
> There's no such thing as legal I/O port address on powerpc. I/O ports
> are just another memory-mapped device; and accessing non-existing
> memory dosn't work on any machine ;-).
> 
>> otherwise there is nothing I can do for you. I had a look to the
>> sources of the other 2 scsi drivers you use (mesh and mac53C94) and
>> they use an approach to I/O very specific to the MAC architecture.
>> Nothing that can be implemented in the EATA driver without a full
>> rewrite. -
>> 
>> I do not know where to start, is the inb() function supposed to do
>> exactly the same on i386 and ppc ?  Where could the problem come from
>> ?
> 
> inb() works as expected as long as you feed it the right port value.
> 
> I've looked at the code a bit; can you try to recompile the eata
> module with DEBUG_PCI_DETECT defined, and send the kernel's log
> output? Also, try an insmod without the io= option.

I already have 

#define  DEBUG_DETECT
#define  DEBUG_PCI_DETECT

in the module source.  That doesn't output much though... 

Jun  5 09:23:22 brocoli kernel: >IN from bad port 338 at d006092c
Jun  5 09:23:22 brocoli kernel: IN from bad port 338 at d006092c
Jun  5 09:23:22 brocoli last message repeated 452 times
Jun  5 09:23:22 brocoli kernel: EATA0: detect, do_dma failed at 0x330.

I also tried to put the card in another PCI slot (already in use before,
I swaped two cards) and I've got the same result (when doing a
modprobe)...

Antoine.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: eata.c module and PCI setup problem (RAID SCSI card)

[Michel Lanners]

On   4 Jun, this message from Antoine Delvaux echoed through cyberspace:
> I'm currently trying to make a DPT PM2144UW PCI card with a
> SmartCache IV and 64 MB working.  It's a UW SCSI raid controller.  The
> card is working fine in an Intel based box with the eata driver.  But in
> my PowerMac 7500 G3, I can't make it work.

7600 here...

> Since two days I've been in touch with the developper of the eata.c
> driver (Ballabio Dario) and he gave me a few debug version of that
> driver to play with.  Unfortunately we have come to a point where he
> can't do more since the problem seems to come from PCI code of the ppc
> kernel tree.
> 
> If anyone here have experience in this field, I welcome his advices as
> do not know where to start to search.  With the latest debugging enabled
> eata.c module given by Ballabio, I've got the following output :

I had some similar problems when trying to make a Promise IDE card work
in my Mac... but that was a few years ago.

> # insmod eata.o io_port=0x1400
  ^^
Where are you getting this value from? I'm sure it is wrong... Have a
look at the boot messages of your kernel, and also send along the output
of 'lspci -vv'.

> # tail /var/log/syslog
> Jun  4 13:52:38 brocoli kernel: IN from bad port 1408 at d005392c

This message means you are trying to read from an address where no
device is listening. Either the IO port (0x1408) is wrong, or the device
isn't configured to reply to IO accesses on the PCI bus.

> And here is his answer :
> 
> 
> The message
>  IN from bad port 1408 at d005392c
> comes from linux/arch/ppc/kernel/traps.c 
> (about line 162, inside #ifdef CONFIG_ALL_PPC)
> It looks like your setup is not able to read a single byte from location
> 0x1408.
> This is what I'm trying to do to see if the board is there (inb(0x1400 +
> eata_reg_offset).
> So either you can fix your hw/kernel parameters in order to allow inb()
> from a legal I/O port address,

There's no such thing as legal I/O port address on powerpc. I/O ports
are just another memory-mapped device; and accessing non-existing memory
dosn't work on any machine ;-).

> otherwise there is nothing I can do for
> you. I had a look to the sources of the other 2 scsi drivers you use
> (mesh and mac53C94) and they use an approach to I/O very specific to the
> MAC architecture. Nothing that can be implemented in the EATA driver
> without a full rewrite.
> -
> 
> I do not know where to start, is the inb() function supposed to do
> exactly the same on i386 and ppc ?  Where could the problem come from ?

inb() works as expected as long as you feed it the right port value.

I've looked at the code a bit; can you try to recompile the eata module
with DEBUG_PCI_DETECT defined, and send the kernel's log output? Also,
try an insmod without the io= option.

Cheers

Michel

-
Michel Lanners |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes|Ask Questions.  Make Mistakes.
L-1710 Luxembourg  |
email   [EMAIL PROTECTED]|
http://www.cpu.lu/~mlan| Learn Always. "


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

eata.c module and PCI setup problem (RAID SCSI card)

[Antoine Delvaux]

Hello all,


I'm currently trying to make a DPT PM2144UW PCI card with a
SmartCache IV and 64 MB working.  It's a UW SCSI raid controller.  The
card is working fine in an Intel based box with the eata driver.  But in
my PowerMac 7500 G3, I can't make it work.

Since two days I've been in touch with the developper of the eata.c
driver (Ballabio Dario) and he gave me a few debug version of that
driver to play with.  Unfortunately we have come to a point where he
can't do more since the problem seems to come from PCI code of the ppc
kernel tree.

If anyone here have experience in this field, I welcome his advices as
do not know where to start to search.  With the latest debugging enabled
eata.c module given by Ballabio, I've got the following output :

# insmod eata.o io_port=0x1400
eata.o: init_module: No such device
Hint: insmod errors can be caused by incorrect module parameters,
including invalid IO or IRQ parameters
# tail /var/log/syslog
Jun  4 13:52:38 brocoli kernel: IN from bad port 1408 at d005392c
Jun  4 13:52:38 brocoli kernel: IN from bad port 1408 at d005392c
Jun  4 13:52:38 brocoli last message repeated 440 times
Jun  4 13:52:38 brocoli kernel: EATA0: detect, do_dma failed at 0x1400.
drivers/scsi# 


And here is his answer :


The message
 IN from bad port 1408 at d005392c
comes from linux/arch/ppc/kernel/traps.c 
(about line 162, inside #ifdef CONFIG_ALL_PPC)
It looks like your setup is not able to read a single byte from location
0x1408.
This is what I'm trying to do to see if the board is there (inb(0x1400 +
eata_reg_offset).
So either you can fix your hw/kernel parameters in order to allow inb()
from a legal I/O port address, otherwise there is nothing I can do for
you. I had a look to the sources of the other 2 scsi drivers you use
(mesh and mac53C94) and they use an approach to I/O very specific to the
MAC architecture. Nothing that can be implemented in the EATA driver
without a full rewrite.
-

I do not know where to start, is the inb() function supposed to do
exactly the same on i386 and ppc ?  Where could the problem come from ?

I've forgotten to tell I'm running Debian Woody with a 2.4.18 kernel
from the main tree.

Thanks for any pointer,

Antoine.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Autodetected raid on PPC (root-raid)

[Mike Fedyk]

Hi,

I'm trying to get a raid setup on my ppc 7200/120.  I've been able to
put two 1.2gb drives inside, I've patched my 2.2.19 kernel, and I've
made a raid1 device.

The problem is that it won't autodetect the raid devices.  Is it
possible to have root-raid on ppc?  I'd guess I need to change
something in my partition map.  Anyone know?

Mike

Re: Raid on Debian PPC

[Jeremiah Merkl]

FWIW, I'm running a new style RAID0 with raidtools2 on a powerpc box. Took some
question-asking, and some other work, but it's runnung fine now. Used the
kernel-source-2.2.17.deb, applied the patch from ingo's site, ran the standard 
make
menuconfig,, make-kpkg, etc, and had no problems.

So it does work on a G3-all-in-one with a pair of 4-gig drives raided together.

-JM

Adam C Powell IV wrote:

> "Shawn J. Wallace" wrote:
>
> > Has anyone successfully used the software RAID on PPC?
> >
> > I've done it numerous times on i386 systems without problems, but when I
> > compiled the modules and tried to install it I ran into problems:
> > - Module loads fine
> > - mkraid runs fine, creates the array
> > - mdadd bails horribly complaining about "Zero-length" drives/partitions
> > when I try mdadd /dev/md0 /dev/sda1 /dev/sdb1 etc
> >
> > Anyone has similar experiences?
>
> Are you using old-style RAID in the stock kernel, or new-style with raidtools2
> and Ingo's patches (at http://people.redhat.com/mingo/raid-patches/)?  If the
> former, try the latter, the stock kernel RAID is not being maintained and is
> known to fail under some circumstances.
>
> 
> So why is there not even any mention of this in kernel documentation?  You 
> tell
> me, I've submitted patches to at least document the problem three times now...
> after spending three weeks last Fall sweating over problems in a 50 GB
> RAID partition that brought my server down about 5 times for several hours
> each!!  The reply from L-K: "This mailing list's archives are really the only
> reliable documentation."  Great, so you can't use a "stable" kernel without
> being on a list with hundreds of posts a week!
>
> (Can you tell I'm still bitter about it?  I'm embarassed to say how close I 
> came
> to switching to NT...)
> 
>
> Glad that's over.  Anyway, if you are using the new-style RAID, I'm afraid
> I can't help you, I've only tried it on i386...
>
> HTH,
>
> -Adam P.
>
>   Welcome to the best software in the world today cafe!
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Raid on Debian PPC

[Adam C Powell IV]

"Shawn J. Wallace" wrote:

> Has anyone successfully used the software RAID on PPC?
>
> I've done it numerous times on i386 systems without problems, but when I
> compiled the modules and tried to install it I ran into problems:
> - Module loads fine
> - mkraid runs fine, creates the array
> - mdadd bails horribly complaining about "Zero-length" drives/partitions
> when I try mdadd /dev/md0 /dev/sda1 /dev/sdb1 etc
>
> Anyone has similar experiences?

Are you using old-style RAID in the stock kernel, or new-style with raidtools2
and Ingo's patches (at http://people.redhat.com/mingo/raid-patches/)?  If the
former, try the latter, the stock kernel RAID is not being maintained and is
known to fail under some circumstances.


So why is there not even any mention of this in kernel documentation?  You tell
me, I've submitted patches to at least document the problem three times now...
after spending three weeks last Fall sweating over problems in a 50 GB
RAID partition that brought my server down about 5 times for several hours
each!!  The reply from L-K: "This mailing list's archives are really the only
reliable documentation."  Great, so you can't use a "stable" kernel without
being on a list with hundreds of posts a week!

(Can you tell I'm still bitter about it?  I'm embarassed to say how close I came
to switching to NT...)


Glad that's over.  Anyway, if you are using the new-style RAID, I'm afraid
I can't help you, I've only tried it on i386...

HTH,

-Adam P.

  Welcome to the best software in the world today cafe!

Raid on Debian PPC

[Shawn J. Wallace]

Has anyone successfully used the software RAID on PPC?

I've done it numerous times on i386 systems without problems, but when I 
compiled the modules and tried to install it I ran into problems:

- Module loads fine
- mkraid runs fine, creates the array
- mdadd bails horribly complaining about "Zero-length" drives/partitions 
when I try mdadd /dev/md0 /dev/sda1 /dev/sdb1 etc


Anyone has similar experiences?

Shawn

Re: raid troubles

[Adam C Powell IV]

Jeremiah Merkl wrote:

> well, people.redhat.com doesn't seem to want to respond today.

Oh dear, it does seem to be down.  Good thing I kept a copy!  Try
http://lyre.mit.edu/~powell/debs/raid-2.2.17-A0.bz2 .  That's against stock 
2.2.17.

> Are there any other mirrors available I can look at? I checked the comments 
> on the
> raidtools2 package, and it says to go to an ftp://./alpha location, or 
> use the
> kernel-patch-raid packages. Both only go up to kernel 2.2.10

That's no good!  Maybe you should bug report... (against kernel-patch-raid and
against raidtools2 for pointing to an obsolete location).

Zeen,

-Adam P.

Welcome to the best software in the world today cafe!

Re: raid troubles

[Jeremiah Merkl]

well, people.redhat.com doesn't seem to want to respond today.

Are there any other mirrors available I can look at? I checked the comments on 
the
raidtools2 package, and it says to go to an ftp://./alpha location, or use 
the
kernel-patch-raid packages. Both only go up to kernel 2.2.10

Anyone know of another mirror I can go to? Or should I downgrade to 2.2.10?

-JM

Adam C Powell IV wrote:

> Jeremiah Merkl wrote:
>
> > has anyone else gotten a raid0 drive set up and moutned successfully?
> > I'm having  difficulties with raidtools 0.42-22 from woody. Should I be
> > using raidtools2? If so, I need to patch my kernel source (2.2.17),
> > right?
>
> I've had raid0 and raid5 set up using old raidtools and 2.2.14 kernel on i386,
> but when I tried to build and use an SMP kernel, it would hang the machine 
> when
> I went to mount it.  Old raid has not been maintained for well over a year, 
> and
> it wouldn't surprise me if it's broken on PPC.
>
> So try the new raid, patches at http://people.redhat.com/mingo/raid-patches/ ,
> with raidtools2.
>
> -Adam P.
>
>   Welcome to the best software in the world today cafe!

Re: raid troubles

[Adam C Powell IV]

Jeremiah Merkl wrote:

> has anyone else gotten a raid0 drive set up and moutned successfully?
> I'm having  difficulties with raidtools 0.42-22 from woody. Should I be
> using raidtools2? If so, I need to patch my kernel source (2.2.17),
> right?

I've had raid0 and raid5 set up using old raidtools and 2.2.14 kernel on i386,
but when I tried to build and use an SMP kernel, it would hang the machine when
I went to mount it.  Old raid has not been maintained for well over a year, and
it wouldn't surprise me if it's broken on PPC.

So try the new raid, patches at http://people.redhat.com/mingo/raid-patches/ ,
with raidtools2.

-Adam P.

  Welcome to the best software in the world today cafe!

raid troubles

[Jeremiah Merkl]

has anyone else gotten a raid0 drive set up and moutned successfully?
I'm having  difficulties with raidtools 0.42-22 from woody. Should I be
using raidtools2? If so, I need to patch my kernel source (2.2.17),
right?

mdadd is giving me:

# mdadd -a
md_add(): zero device size, huh, bailing out.
/dev/hda7: Invalid argument
md_add(): zero device size, huh, bailing out.
/dev/hdc7: Invalid argument

where /etc/mdtab contains:

# mdtab entry for /dev/md0
/dev/md0raid0,4k,0,08a07cef /dev/hda7 /dev/hdc7

which was generated with mdcreate.

both hdc7 and hda7 are valid partitions, and mount fine on their own.
the "md_add(): zero device size, huh, bailing out." line is actually a
kernel message, and is dumped to /var/log/messages as well.

Anyone have any suggestions? I set one up on a PC, and it seems to be
running fine...

-JM