multiple neighbour cache tables for AF_INET
Hi,
The kernels 2.4.28+ and 2.6.9+ with IPv4 and ATM-CLIP enabled have bugs in
the neighbour cache code. neigh_delete() and neigh_add() only work properly
if one cache table per address family exist. After ATM-CLIP installed a
second cache table for AF_INET, neigh_delete() and neigh_add() only examine
the first table (the ATM-CLIP table if IPv4 and ATM-CLIP are compiled into
the kernel). neigh_dump_info() is also affected if the neigh_dump_table()
call fails.
This bug causes "ip neigh flush dev " to run into an
infinite loop when the arp cache is already populated (debian bug #282492).
"ip neigh delete ..." commands for non ATM-CLIP entries fail with an EINVAL.
This is because of the IPv4 neighbour table that is installed in arp.c is
never examined when sending delete commands.
I have attached a minimally tested patch for 2.4.28 that fixes this problem.
Greetings,
Wilfried
--
10 GB Mailbox, 100 FreeSMS http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++--- linux-2.4.28/net/core/neighbour.c Fri Jan 28 14:26:59 2005
+++ linux-2.4.28fix/net/core/neighbour.c Fri Jan 28 13:22:06 2005
@@ -1351,7 +1351,6 @@ int neigh_delete(struct sk_buff *skb, st
if (tbl->family != ndm->ndm_family)
continue;
- read_unlock(_tbl_lock);
err = -EINVAL;
if (nda[NDA_DST-1] == NULL ||
@@ -1360,18 +1359,28 @@ int neigh_delete(struct sk_buff *skb, st
if (ndm->ndm_flags_PROXY) {
err = pneigh_delete(tbl, RTA_DATA(nda[NDA_DST-1]), dev);
- goto out;
+ if(err) {
+continue; /* maybe in another table */
+ }
+ else {
+goto out;
+ }
}
- if (dev == NULL)
- return -EINVAL;
+ if (dev == NULL) {
+ goto out;
+ }
n = neigh_lookup(tbl, RTA_DATA(nda[NDA_DST-1]), dev);
if (n) {
err = neigh_update(n, NULL, NUD_FAILED, 1, 0);
neigh_release(n);
}
+ else {
+ continue; /* maybe in another table */
+ }
out:
+ read_unlock(_tbl_lock);
if (dev)
dev_put(dev);
return err;
@@ -1390,6 +1399,8 @@ int neigh_add(struct sk_buff *skb, struc
struct rtattr **nda = arg;
struct neigh_table *tbl;
struct net_device *dev = NULL;
+ int err = -EADDRNOTAVAIL;
+ int olderr;
if (ndm->ndm_ifindex) {
if ((dev = dev_get_by_index(ndm->ndm_ifindex)) == NULL)
@@ -1398,35 +1409,47 @@ int neigh_add(struct sk_buff *skb, struc
read_lock(_tbl_lock);
for (tbl=neigh_tables; tbl; tbl = tbl->next) {
- int err = 0;
int override = 1;
struct neighbour *n;
if (tbl->family != ndm->ndm_family)
continue;
- read_unlock(_tbl_lock);
- err = -EINVAL;
if (nda[NDA_DST-1] == NULL ||
- nda[NDA_DST-1]->rta_len != RTA_LENGTH(tbl->key_len))
+ nda[NDA_DST-1]->rta_len != RTA_LENGTH(tbl->key_len)) {
+ err = -EINVAL;
goto out;
+ }
+
if (ndm->ndm_flags_PROXY) {
err = -ENOBUFS;
- if (pneigh_lookup(tbl, RTA_DATA(nda[NDA_DST-1]), dev, 1))
+ if (pneigh_lookup(tbl, RTA_DATA(nda[NDA_DST-1]), dev, 1)) {
err = 0;
+goto out;
+ }
+ else {
+continue; /* maybe in another table */
+ }
+ }
+ if (dev == NULL) {
+ err = -EINVAL;
goto out;
}
- if (dev == NULL)
- return -EINVAL;
- err = -EINVAL;
+
if (nda[NDA_LLADDR-1] != NULL &&
- nda[NDA_LLADDR-1]->rta_len != RTA_LENGTH(dev->addr_len))
+ nda[NDA_LLADDR-1]->rta_len != RTA_LENGTH(dev->addr_len)) {
+ err = -EINVAL;
goto out;
+ }
+
+ olderr=err;
err = 0;
n = neigh_lookup(tbl, RTA_DATA(nda[NDA_DST-1]), dev);
if (n) {
- if (nlh->nlmsg_flags_F_EXCL)
+ if (nlh->nlmsg_flags_F_EXCL) {
err = -EEXIST;
+goto outneigh;
+ }
override = nlh->nlmsg_flags_F_REPLACE;
} else if (!(nlh->nlmsg_flags_F_CREATE))
err = -ENOENT;
@@ -1442,9 +1465,16 @@ int neigh_add(struct sk_buff *skb, struc
ndm->ndm_state,
override, 0);
}
+ else {
+ err=olderr;
+ continue; /* maybe in another table */
+ }
+
+outneigh:
if (n)
neigh_release(n);
out:
+ read_unlock(_tbl_lock);
if (dev)
dev_put(dev);
return err;
@@ -1453,7 +1483,7 @@ out:
if (dev)
dev_put(dev);
- return -EADDRNOTAVAIL;
+ return err;
}
@@ -1547,8 +1577,7 @@ int neigh_dump_info(struct sk_buff *skb,
continue;
if (t > s_t)
memset(>args[1], 0, sizeof(cb->args)-sizeof(cb->args[0]));
- if (neigh_dump_table(tbl, skb, cb) < 0)
- break;
+ neigh_dump_table(tbl, skb, cb);
}
read_unlock(_tbl_lock);
multiple neighbour cache tables for AF_INET
Hi,
The kernels 2.4.28+ and 2.6.9+ with IPv4 and ATM-CLIP enabled have bugs in
the neighbour cache code. neigh_delete() and neigh_add() only work properly
if one cache table per address family exist. After ATM-CLIP installed a
second cache table for AF_INET, neigh_delete() and neigh_add() only examine
the first table (the ATM-CLIP table if IPv4 and ATM-CLIP are compiled into
the kernel). neigh_dump_info() is also affected if the neigh_dump_table()
call fails.
This bug causes ip neigh flush dev some ethernet device to run into an
infinite loop when the arp cache is already populated (debian bug #282492).
ip neigh delete ... commands for non ATM-CLIP entries fail with an EINVAL.
This is because of the IPv4 neighbour table that is installed in arp.c is
never examined when sending delete commands.
I have attached a minimally tested patch for 2.4.28 that fixes this problem.
Greetings,
Wilfried
--
10 GB Mailbox, 100 FreeSMS http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++--- linux-2.4.28/net/core/neighbour.c Fri Jan 28 14:26:59 2005
+++ linux-2.4.28fix/net/core/neighbour.c Fri Jan 28 13:22:06 2005
@@ -1351,7 +1351,6 @@ int neigh_delete(struct sk_buff *skb, st
if (tbl-family != ndm-ndm_family)
continue;
- read_unlock(neigh_tbl_lock);
err = -EINVAL;
if (nda[NDA_DST-1] == NULL ||
@@ -1360,18 +1359,28 @@ int neigh_delete(struct sk_buff *skb, st
if (ndm-ndm_flagsNTF_PROXY) {
err = pneigh_delete(tbl, RTA_DATA(nda[NDA_DST-1]), dev);
- goto out;
+ if(err) {
+continue; /* maybe in another table */
+ }
+ else {
+goto out;
+ }
}
- if (dev == NULL)
- return -EINVAL;
+ if (dev == NULL) {
+ goto out;
+ }
n = neigh_lookup(tbl, RTA_DATA(nda[NDA_DST-1]), dev);
if (n) {
err = neigh_update(n, NULL, NUD_FAILED, 1, 0);
neigh_release(n);
}
+ else {
+ continue; /* maybe in another table */
+ }
out:
+ read_unlock(neigh_tbl_lock);
if (dev)
dev_put(dev);
return err;
@@ -1390,6 +1399,8 @@ int neigh_add(struct sk_buff *skb, struc
struct rtattr **nda = arg;
struct neigh_table *tbl;
struct net_device *dev = NULL;
+ int err = -EADDRNOTAVAIL;
+ int olderr;
if (ndm-ndm_ifindex) {
if ((dev = dev_get_by_index(ndm-ndm_ifindex)) == NULL)
@@ -1398,35 +1409,47 @@ int neigh_add(struct sk_buff *skb, struc
read_lock(neigh_tbl_lock);
for (tbl=neigh_tables; tbl; tbl = tbl-next) {
- int err = 0;
int override = 1;
struct neighbour *n;
if (tbl-family != ndm-ndm_family)
continue;
- read_unlock(neigh_tbl_lock);
- err = -EINVAL;
if (nda[NDA_DST-1] == NULL ||
- nda[NDA_DST-1]-rta_len != RTA_LENGTH(tbl-key_len))
+ nda[NDA_DST-1]-rta_len != RTA_LENGTH(tbl-key_len)) {
+ err = -EINVAL;
goto out;
+ }
+
if (ndm-ndm_flagsNTF_PROXY) {
err = -ENOBUFS;
- if (pneigh_lookup(tbl, RTA_DATA(nda[NDA_DST-1]), dev, 1))
+ if (pneigh_lookup(tbl, RTA_DATA(nda[NDA_DST-1]), dev, 1)) {
err = 0;
+goto out;
+ }
+ else {
+continue; /* maybe in another table */
+ }
+ }
+ if (dev == NULL) {
+ err = -EINVAL;
goto out;
}
- if (dev == NULL)
- return -EINVAL;
- err = -EINVAL;
+
if (nda[NDA_LLADDR-1] != NULL
- nda[NDA_LLADDR-1]-rta_len != RTA_LENGTH(dev-addr_len))
+ nda[NDA_LLADDR-1]-rta_len != RTA_LENGTH(dev-addr_len)) {
+ err = -EINVAL;
goto out;
+ }
+
+ olderr=err;
err = 0;
n = neigh_lookup(tbl, RTA_DATA(nda[NDA_DST-1]), dev);
if (n) {
- if (nlh-nlmsg_flagsNLM_F_EXCL)
+ if (nlh-nlmsg_flagsNLM_F_EXCL) {
err = -EEXIST;
+goto outneigh;
+ }
override = nlh-nlmsg_flagsNLM_F_REPLACE;
} else if (!(nlh-nlmsg_flagsNLM_F_CREATE))
err = -ENOENT;
@@ -1442,9 +1465,16 @@ int neigh_add(struct sk_buff *skb, struc
ndm-ndm_state,
override, 0);
}
+ else {
+ err=olderr;
+ continue; /* maybe in another table */
+ }
+
+outneigh:
if (n)
neigh_release(n);
out:
+ read_unlock(neigh_tbl_lock);
if (dev)
dev_put(dev);
return err;
@@ -1453,7 +1483,7 @@ out:
if (dev)
dev_put(dev);
- return -EADDRNOTAVAIL;
+ return err;
}
@@ -1547,8 +1577,7 @@ int neigh_dump_info(struct sk_buff *skb,
continue;
if (t s_t)
memset(cb-args[1], 0, sizeof(cb-args)-sizeof(cb-args[0]));
- if (neigh_dump_table(tbl, skb, cb) 0)
- break;
+ neigh_dump_table(tbl, skb, cb);
}
read_unlock(neigh_tbl_lock);
Re: 2.4.7-pre7 natsemi network driver random pauses
"Kevin P. Fleming" wrote: > > I upgraded two machines here from 2.4.7-pre6 to 2.4.7-pre7 yesterday > afternoon. > > The first machine I upgraded, my workstation, is a 1GHz Athlon on a VIA > KT133 (not A) motherboard using a NetGear FA312TX network card. This machine > has always run Linux just fine. After this upgrade, telnetting to my other > Linux machine (not yet upgraded) and doing long directory listings (or tar > tzvf linux-2.4.0.tar) exhibits random (and long) pauses in the output. > Switching back to 2.4.7-pre6 makes the problem disappear. Note that at this > time only the _client_ end of this connection had been upgraded to -pre7. > > I then upgraded my server as well, which is a 700 MHz Coppermine Celeron on > an SIS 630 motherboard, also using a NetGear FA312TX network card. Now this > machine exhibits the same symptoms, even when the telnet client is on a > Windows machine. > > So, it appears that one of two things happened: > > a) the natsemi driver had changes merged between -pre6 and -pre7 (not listed > in the changelogs) that had negative effects on my systems > > b) something else in the kernel caused irq/softirq/whatever random latency > to appear > > Any ideas where I should start looking? Just for curiosity, do you have those messages in our logfiles: eth0: Transmit error, Tx status register 82. Flags; bus-master 1, dirty 20979238(6) current 20979242(10) Transmit list 1f659290 vs. df659260. 0: @df659200 length 85ea status 000105ea 1: @df659210 length 8296 status 00010296 2: @df659220 length 85ea status 000105ea I had those with 2.4.3-pre6. They disappeared in 2.4.4. Another user reported the same on lkml with different kernel versions. Wilfried - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.7-pre7 natsemi network driver random pauses
Kevin P. Fleming wrote: I upgraded two machines here from 2.4.7-pre6 to 2.4.7-pre7 yesterday afternoon. The first machine I upgraded, my workstation, is a 1GHz Athlon on a VIA KT133 (not A) motherboard using a NetGear FA312TX network card. This machine has always run Linux just fine. After this upgrade, telnetting to my other Linux machine (not yet upgraded) and doing long directory listings (or tar tzvf linux-2.4.0.tar) exhibits random (and long) pauses in the output. Switching back to 2.4.7-pre6 makes the problem disappear. Note that at this time only the _client_ end of this connection had been upgraded to -pre7. I then upgraded my server as well, which is a 700 MHz Coppermine Celeron on an SIS 630 motherboard, also using a NetGear FA312TX network card. Now this machine exhibits the same symptoms, even when the telnet client is on a Windows machine. So, it appears that one of two things happened: a) the natsemi driver had changes merged between -pre6 and -pre7 (not listed in the changelogs) that had negative effects on my systems b) something else in the kernel caused irq/softirq/whatever random latency to appear Any ideas where I should start looking? Just for curiosity, do you have those messages in our logfiles: eth0: Transmit error, Tx status register 82. Flags; bus-master 1, dirty 20979238(6) current 20979242(10) Transmit list 1f659290 vs. df659260. 0: @df659200 length 85ea status 000105ea 1: @df659210 length 8296 status 00010296 2: @df659220 length 85ea status 000105ea I had those with 2.4.3-pre6. They disappeared in 2.4.4. Another user reported the same on lkml with different kernel versions. Wilfried - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3c905C-TX [Fast Etherlink] problem ...
Robert Vojta wrote: > > Hi, > I have this card in intranet server and I'm very confused about very often > message in log like this: > > eth0: Transmit error, Tx status register 82. > Flags; bus-master 1, dirty 20979238(6) current 20979242(10) > Transmit list 1f659290 vs. df659260. > 0: @df659200 length 85ea status 000105ea > 1: @df659210 length 8296 status 00010296 > 2: @df659220 length 85ea status 000105ea [snip] Hi, I had the same problem with 2.4.3-pre6 (also with the 3c905C). Alle problems were gone with 2.4.4, so I stopped bothering. Hope this helps... Wilfried - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3c905C-TX [Fast Etherlink] problem ...
Robert Vojta wrote: Hi, I have this card in intranet server and I'm very confused about very often message in log like this: eth0: Transmit error, Tx status register 82. Flags; bus-master 1, dirty 20979238(6) current 20979242(10) Transmit list 1f659290 vs. df659260. 0: @df659200 length 85ea status 000105ea 1: @df659210 length 8296 status 00010296 2: @df659220 length 85ea status 000105ea [snip] Hi, I had the same problem with 2.4.3-pre6 (also with the 3c905C). Alle problems were gone with 2.4.4, so I stopped bothering. Hope this helps... Wilfried - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA/PDC/Athlon - IDE error theory
Alan Cox wrote:
> > hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
>
> CRC errors are cable errors so that bit is reasonable in itself
Could this be caused by the RAID configuration? The first sector of the
first disk holds the partition table. The other disks in the raid have
no valid partition table:
dmesg message from Jussi Laako:
hdf: unknown partition table
hdg: unknown partition table
hdh: unknown partition table
[snip]
If there is a raid (1+)0 configured you got a volume that is bigger than
the first hd. So if you have extended partitions or freebsd slices which
are located beyond the capacity of the hd, then the partition table
check would have to read datastructures which have an offset which is to
high. => read error during partition check => nasty error messages
I have the error message problem on my box. DMA is disabled because of
the error on /dev/hda. But a hdparm -d 1 /dev/hda fixes this, and I do
not get more errors regarding that. Everything works fine. (I did not
compile with Athlon optimization.)
regards,
Wilfried
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA/PDC/Athlon - IDE error theory
Alan Cox wrote:
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
CRC errors are cable errors so that bit is reasonable in itself
Could this be caused by the RAID configuration? The first sector of the
first disk holds the partition table. The other disks in the raid have
no valid partition table:
dmesg message from Jussi Laako:
hdf: unknown partition table
hdg: unknown partition table
hdh: unknown partition table
[snip]
If there is a raid (1+)0 configured you got a volume that is bigger than
the first hd. So if you have extended partitions or freebsd slices which
are located beyond the capacity of the hd, then the partition table
check would have to read datastructures which have an offset which is to
high. = read error during partition check = nasty error messages
I have the error message problem on my box. DMA is disabled because of
the error on /dev/hda. But a hdparm -d 1 /dev/hda fixes this, and I do
not get more errors regarding that. Everything works fine. (I did not
compile with Athlon optimization.)
regards,
Wilfried
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
HPT370 raid hack
Hi! I just put my highpoint-tech raid hack on a website: http://www.rug-rats.org/~wilfried/ So if you want to play around with it you can download it from there + get a mininum of documentation. Andre Hedric, Ajran van de Ven, ...: I am sorry that I did not had much time lately to get some information of the raid layout written together. But I did not forget you guys... regard, Wilfried - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
HPT370 raid hack
Hi! I just put my highpoint-tech raid hack on a website: http://www.rug-rats.org/~wilfried/ So if you want to play around with it you can download it from there + get a mininum of documentation. Andre Hedric, Ajran van de Ven, ...: I am sorry that I did not had much time lately to get some information of the raid layout written together. But I did not forget you guys... regard, Wilfried - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE Raid supported with the HPT370?
Jeroen Geusebroek wrote: > I have ordered a ABIT VP6 motherboard with the HPT370 controller > and would like to know if raid0 is supported with linux? > > If not, will i be able to work without raid then? (maybe using > software raid) The controller is working fine, but the raid functionality is not working within linux. Of course you could use the linux software raid. However in this case you cannot install another OS on the HPT if this uses the hpt raid. I have written a small module which does raid 0 in the hpt way of life. You can send me an email if you want to try it out. The future of my mod is unknown because of the IDE guys want to support the ata raids. So it might become obsolete. good luck, Wilfried -- Wilfried Weissmann ( mailto:[EMAIL PROTECTED] ) Mobile: +43 676 965 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Help with Fasttrack/100 Raid on Linux
Hello Andre, Sorry for responding a little late. I spent some time in the big blue room (not that is was that blue lately!). Andre Hedrick wrote: > > On Wed, 18 Apr 2001, Wilfried Weissmann wrote: > > > > off to the head or tail of the drive and get me that raid-voodoo-bios-os > > > communication transport layer, and do it ins DMA modes, NOW!" > > > > "voodoo" would be the sector where the raid configuration is stored > > then, right!? Maybe I did not understand you properly... > > We are on the same page, good. OK, and here it is (I extracted this out of the *BSD ata-raid.h): This is the hpt-raid config block located at offset 0x1220 (sector 9). All data is stored in little endian format. 0x0020 32 bits; magic cookie 0x5a7816f0 for good array 0x5a7816fd for bad array 0x0024 32 bits; raid volume cookie used to distinguish between raid volumes 0x0028 32 bits; raid-10 volume cookie ??? 0x002C 32 bits; order bitmask 0x04 status is OK 0x02 striping 0x01 mirroring Note: bits 0 and 1 appear to matter only in raid 10 0x0030 8 bits; disks in array 0x0031 8 bits; chunksize (1U << (*this+9)) 0x0032 8 bits; raid level 0x00 raid 0 0x01 raid 1 0x02 raid 10 & raid 0 (not supported) 0x03 span 0x04 raid 3 (not supported) 0x05 raid 5 (not supported) 0x06 single disk 0x07 raid 10 & raid 1 (not supported) Note: raid 10 is done with raid level = raid 0 and order = ( mirroring | striping ) 0x0033 8 bits; disk number in array 0x0034 32 bits; raid volume size in sectors 0x0038 32 bits; disk mode ??? 0x003C 32 bits; boot mode ??? 0x0040 8 bits; boot disk ??? 0x0041 8 bits; boot protect ??? 0x0042 8 bits; error log entries 0x0043 8 bits error log index 0x0044 32x error entries 32 bits; timestamp 8 bits; reason (0xFF=broken, 0xFE=removed) 8 bits; disk 8 bits; status 8 bits; sectors 32 bits; lba Mine looks like this: 001220 f0 16 78 5a b3 04 b3 84 00 00 00 00 04 00 00 00 001230 02 05 00 00 c0 2a 28 07 00 00 00 00 78 56 34 12 001240 a5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 001250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 This is the signature of the first disk in a raid0 with 2 30GB disks and 16k chunk size. Everything related to raid 10 is a bit weird, and I am not sure if the BSD code is 100% accurate there. I am goint to install Abit's Gentus on my system. This distro states that it supports most Abit hw quite well. Maybe there is some good sourcecode somewhere... [snip] > > > I do not have the desire to do personality tables, but I can. > > > > With about 96% of all linux boxes in the world dependent on some form of > > > ATA/ATAPI, Linus and Alan are very sensitive to even the sligthest change. > > > > I would avoid to change anything there, but do a raid personality... > > Well, we are back at our your solution vs. my raid personality > > discussion again! > > No we are back to your "raid personality", and a functional API to the > ATA driver. So you want that an ata raid level reuses the existing raid code? > This is probably the first and last time I will openly agree for someone > to tell me were to go, and do it ;-). Well, I guess that is the reason why people keep kicking and banning me from IRC channels... > You tell me what you want the driver to do, and I will make it happen. > It will be legal and technically correct. Does that sound like a good > idea? Perfect! Since FreeBSD supports that controller, do you think Highpoint would provide us "offical" documentation? Or do you already have some? Do you want to have a look at my module? As I said only raid 0 is implemented, but anyway... I try to get written down what HPT would need from the API in hard facts. bye, Wilfried -- Wilfried Weissmann ( mailto:[EMAIL PROTECTED] ) Mobile: +43 676 965 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Help with Fasttrack/100 Raid on Linux
Hello Andre, Sorry for responding a little late. I spent some time in the big blue room (not that is was that blue lately!). Andre Hedrick wrote: On Wed, 18 Apr 2001, Wilfried Weissmann wrote: off to the head or tail of the drive and get me that raid-voodoo-bios-os communication transport layer, and do it ins DMA modes, NOW! voodoo would be the sector where the raid configuration is stored then, right!? Maybe I did not understand you properly... We are on the same page, good. OK, and here it is (I extracted this out of the *BSD ata-raid.h): This is the hpt-raid config block located at offset 0x1220 (sector 9). All data is stored in little endian format. 0x0020 32 bits; magic cookie 0x5a7816f0 for good array 0x5a7816fd for bad array 0x0024 32 bits; raid volume cookie used to distinguish between raid volumes 0x0028 32 bits; raid-10 volume cookie ??? 0x002C 32 bits; order bitmask 0x04 status is OK 0x02 striping 0x01 mirroring Note: bits 0 and 1 appear to matter only in raid 10 0x0030 8 bits; disks in array 0x0031 8 bits; chunksize (1U (*this+9)) 0x0032 8 bits; raid level 0x00 raid 0 0x01 raid 1 0x02 raid 10 raid 0 (not supported) 0x03 span 0x04 raid 3 (not supported) 0x05 raid 5 (not supported) 0x06 single disk 0x07 raid 10 raid 1 (not supported) Note: raid 10 is done with raid level = raid 0 and order = ( mirroring | striping ) 0x0033 8 bits; disk number in array 0x0034 32 bits; raid volume size in sectors 0x0038 32 bits; disk mode ??? 0x003C 32 bits; boot mode ??? 0x0040 8 bits; boot disk ??? 0x0041 8 bits; boot protect ??? 0x0042 8 bits; error log entries 0x0043 8 bits error log index 0x0044 32x error entries 32 bits; timestamp 8 bits; reason (0xFF=broken, 0xFE=removed) 8 bits; disk 8 bits; status 8 bits; sectors 32 bits; lba Mine looks like this: 001220 f0 16 78 5a b3 04 b3 84 00 00 00 00 04 00 00 00 001230 02 05 00 00 c0 2a 28 07 00 00 00 00 78 56 34 12 001240 a5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 001250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 This is the signature of the first disk in a raid0 with 2 30GB disks and 16k chunk size. Everything related to raid 10 is a bit weird, and I am not sure if the BSD code is 100% accurate there. I am goint to install Abit's Gentus on my system. This distro states that it supports most Abit hw quite well. Maybe there is some good sourcecode somewhere... [snip] I do not have the desire to do personality tables, but I can. With about 96% of all linux boxes in the world dependent on some form of ATA/ATAPI, Linus and Alan are very sensitive to even the sligthest change. I would avoid to change anything there, but do a raid personality... Well, we are back at our your solution vs. my raid personality discussion again! No we are back to your raid personality, and a functional API to the ATA driver. So you want that an ata raid level reuses the existing raid code? This is probably the first and last time I will openly agree for someone to tell me were to go, and do it ;-). Well, I guess that is the reason why people keep kicking and banning me from IRC channels... You tell me what you want the driver to do, and I will make it happen. It will be legal and technically correct. Does that sound like a good idea? Perfect! Since FreeBSD supports that controller, do you think Highpoint would provide us offical documentation? Or do you already have some? Do you want to have a look at my module? As I said only raid 0 is implemented, but anyway... I try to get written down what HPT would need from the API in hard facts. bye, Wilfried -- Wilfried Weissmann ( mailto:[EMAIL PROTECTED] ) Mobile: +43 676 965 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE Raid supported with the HPT370?
Jeroen Geusebroek wrote: I have ordered a ABIT VP6 motherboard with the HPT370 controller and would like to know if raid0 is supported with linux? If not, will i be able to work without raid then? (maybe using software raid) The controller is working fine, but the raid functionality is not working within linux. Of course you could use the linux software raid. However in this case you cannot install another OS on the HPT if this uses the hpt raid. I have written a small module which does raid 0 in the hpt way of life. You can send me an email if you want to try it out. The future of my mod is unknown because of the IDE guys want to support the ata raids. So it might become obsolete. good luck, Wilfried -- Wilfried Weissmann ( mailto:[EMAIL PROTECTED] ) Mobile: +43 676 965 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Help with Fasttrack/100 Raid on Linux
Andre Hedrick wrote: > > On Tue, 17 Apr 2001, Wilfried Weissmann wrote: > > > Andre Hedrick wrote: > > > > > > Wilfried, > > > > > > Why a module? > > > > The idea behind that was that, if it is a seperate module, then it would be easier >to maintain for > > me. I am a guy that always needs the newest and greatest, so I expected that I >would have to port my > > stuff to newer kernels frequently. (I started the HPT-RAID0 alone without much >knowledge about the > > kernel.) > > > > > Why not have the detection and flags that hook the md driver for linux and > > > use linux's software raid? [snip] > > Hello Wilfried, Hello Andre, You completely confused me. Attemts to get an idea of what is going on are inline. > > The really easy thing to do is to come up with the personality rules you > want to se and let me create the API. I can make drives talk, listen, > dance, spin, flip, etc. > > Raid 0 and Raid 1 are cakewalks, if you have the right tools. > These will be around in 2.5. > > All you need to do is tell me what you want the subsystem to do. > When you want it done and the observer's view of the operations. > > I can do things like threaded-parallel PRD building for DMA with the tap > of a keystroke of two. I can commit the purfect lie in storage and > destroke a drive to the view of the OS and then do switch-buffer PRD > building. If you want it on 2,3,4,N drives I can do it with fast simple > legal trick code. > > During INIT process I can protect the drive in ways you have never > considered. I can access the whole drive even of the OS only knows only a > portion of the real capacity. And I do not need silly and foolosh means > like "bread". I tell it, "Hey dude, we are running under a lie. Go sneak > off to the head or tail of the drive and get me that raid-voodoo-bios-os > communication transport layer, and do it ins DMA modes, NOW!" "voodoo" would be the sector where the raid configuration is stored then, right!? Maybe I did not understand you properly... I am really trying to understand what you want to do. From what I have seen this would go into kernel 2.5 first. For now there appears to be no information or this-would-be-new-in-2.5 list available of new development kernel so far, so I have to use my fantasy even more. So you want to introduce a new layer between the MD driver and the ATA HDs of IDE-RAIDs. This code would be placed in the ide-chipset driver. Configuration happens at system startup after the chipset is in service. There you read the config-sector (e.g. sector 9 on HPTs) of the disks and datafill your configuration tables. Plus you start one (or more) MD device with the according raid level(s). The MD then accesses your layer instead of talking directly to the disk driver, and the requests are mapped (buffer_head->rsector+10 with the HPTs) as the bios would do it. But the raid is still handled by MD. So you can completely reuse the raid code for all that. Pardon me, but please tell me that I am wrong, because this sounds odd to me! <:( Talking about the API... These should be the basic steps that we need to do (unordered, this is just brainstorming): *) device_size_calculation() should use a callback of the raid level to get the device size. Or the code should be completly moved over to the _run()'s. *) Hide/unhide disks from the userland (this is just a cosmetic issue). *) Shift sectors and shrink capacity of disks so that the existing raid levels can access the disks according to the ata-raid layout. *) Get the configuration sector from disk. Analyse the configuration and setup disks and md-devices. *) All raid pers. must be able to handle I/O that requests sectors from more than only one disk. *) Partitioned raid devices must be handled somehow. > > I do not have the desire to do personality tables, but I can. > > We will not need any new majors because there is plenty of space in the > ones we have, and 128 minors/channel is enough to do anything. > > If you want to do your module cool, but I promise you it will break in 2.5 > and you will not know for months what hit you. I personally would like to > avoid this issue of wreckin work. Second, if you think changes to the > driver made by you have a chance in hell to make the kernel, I am not > allowed to fixed the driver today to address the needs and correct current > issues and ones coming down the pipe. > > With about 96% of all linux boxes in the world dependent on some form of > ATA/ATAPI, Linus and Alan are very sensitive to even the sligthest change. I would avoid to change anything there, but do a raid personality... Well, we are back at our your solution vs. my raid personality discussion again!
Re: Help with Fasttrack/100 Raid on Linux
Andre Hedrick wrote: On Tue, 17 Apr 2001, Wilfried Weissmann wrote: Andre Hedrick wrote: Wilfried, Why a module? The idea behind that was that, if it is a seperate module, then it would be easier to maintain for me. I am a guy that always needs the newest and greatest, so I expected that I would have to port my stuff to newer kernels frequently. (I started the HPT-RAID0 alone without much knowledge about the kernel.) Why not have the detection and flags that hook the md driver for linux and use linux's software raid? [snip] Hello Wilfried, Hello Andre, You completely confused me. Attemts to get an idea of what is going on are inline. The really easy thing to do is to come up with the personality rules you want to se and let me create the API. I can make drives talk, listen, dance, spin, flip, etc. Raid 0 and Raid 1 are cakewalks, if you have the right tools. These will be around in 2.5. All you need to do is tell me what you want the subsystem to do. When you want it done and the observer's view of the operations. I can do things like threaded-parallel PRD building for DMA with the tap of a keystroke of two. I can commit the purfect lie in storage and destroke a drive to the view of the OS and then do switch-buffer PRD building. If you want it on 2,3,4,N drives I can do it with fast simple legal trick code. During INIT process I can protect the drive in ways you have never considered. I can access the whole drive even of the OS only knows only a portion of the real capacity. And I do not need silly and foolosh means like "bread". I tell it, "Hey dude, we are running under a lie. Go sneak off to the head or tail of the drive and get me that raid-voodoo-bios-os communication transport layer, and do it ins DMA modes, NOW!" "voodoo" would be the sector where the raid configuration is stored then, right!? Maybe I did not understand you properly... I am really trying to understand what you want to do. From what I have seen this would go into kernel 2.5 first. For now there appears to be no information or this-would-be-new-in-2.5 list available of new development kernel so far, so I have to use my fantasy even more. So you want to introduce a new layer between the MD driver and the ATA HDs of IDE-RAIDs. This code would be placed in the ide-chipset driver. Configuration happens at system startup after the chipset is in service. There you read the config-sector (e.g. sector 9 on HPTs) of the disks and datafill your configuration tables. Plus you start one (or more) MD device with the according raid level(s). The MD then accesses your layer instead of talking directly to the disk driver, and the requests are mapped (buffer_head-rsector+10 with the HPTs) as the bios would do it. But the raid is still handled by MD. So you can completely reuse the raid code for all that. Pardon me, but please tell me that I am wrong, because this sounds odd to me! :( Talking about the API... These should be the basic steps that we need to do (unordered, this is just brainstorming): *) device_size_calculation() should use a callback of the raid level to get the device size. Or the code should be completly moved over to the raid level_run()'s. *) Hide/unhide disks from the userland (this is just a cosmetic issue). *) Shift sectors and shrink capacity of disks so that the existing raid levels can access the disks according to the ata-raid layout. *) Get the configuration sector from disk. Analyse the configuration and setup disks and md-devices. *) All raid pers. must be able to handle I/O that requests sectors from more than only one disk. *) Partitioned raid devices must be handled somehow. I do not have the desire to do personality tables, but I can. We will not need any new majors because there is plenty of space in the ones we have, and 128 minors/channel is enough to do anything. If you want to do your module cool, but I promise you it will break in 2.5 and you will not know for months what hit you. I personally would like to avoid this issue of wreckin work. Second, if you think changes to the driver made by you have a chance in hell to make the kernel, I am not allowed to fixed the driver today to address the needs and correct current issues and ones coming down the pipe. With about 96% of all linux boxes in the world dependent on some form of ATA/ATAPI, Linus and Alan are very sensitive to even the sligthest change. I would avoid to change anything there, but do a raid personality... Well, we are back at our your solution vs. my raid personality discussion again! Cheers, Andre Hedrick bye, Wilfried Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-40
Re: Help with Fasttrack/100 Raid on Linux
Andre Hedrick wrote: > > Wilfried, > > Why a module? The idea behind that was that, if it is a seperate module, then it would be easier to maintain for me. I am a guy that always needs the newest and greatest, so I expected that I would have to port my stuff to newer kernels frequently. (I started the HPT-RAID0 alone without much knowledge about the kernel.) > Why not have the detection and flags that hook the md driver for linux and > use linux's software raid? I could not use the disk striping, because of the raid0 code is not capable of processing a request what would span more than one disk. You also have to shift the offset of all but the first disk by 10 sectors. So I created an own personality... I also guess it would be a bit complicated if we want to create a raid10. Is this done by putting a raid1 over raid0 devices? We would have to find a way to map the sectors according to the IDE-RAID spec of the controller over several raid levels. An ataraid personality would be easier and more flexible then. regards, Wilfried > > Cheers, > > On Mon, 16 Apr 2001, Wilfried Weissmann wrote: > > > Arjan van de Ven wrote: > > > > > > In article <[EMAIL PROTECTED]> you wrote: > > > > Andre Hedrick wrote: > > > > > > > However as far as I can see everyone who has a FastTrak which is "stuck" > > > > in RAID mode[1] would be happy if it worked as a normal IDE controller > > > > in Linux, which is (usually?) not the case - eg on the MSI board where > > > > only the first channel is seen. > > > > > > I have a patch to work around that. However the better solution would be to > > > have a native driver for the raid; I plan to start working on that next > > > week... > > > > I am doing the same for the HighPoint-Tech 370 (talking about the RAID driver). >Disk-striping is > > working so far. My code is based on the kernel patches for MDs from Neil Brown. I >created an own > > RAID-personality for the module. > > When I looked at the FreeBSD implementation I had the idea of making a >"supermodule" which could > > contain serveral IDE-RAID drivers (e.g.: Proise FastTrack + HPT370). There would >be a super > > personality for ATA-RAID and several low-level drivers for the individual >controllers. > > > > Interrested? Ideas? Hints, Tips, ...? Wanna team up? <8) > > > > > > > > Greetings, > > > Arjan van de Ven > > > > regards, > > Wilfried > > > > PS: An uppercase THANX goes to Nail Brown! ^Nail^Neil > > Andre Hedrick > Linux ATA Development > ASL Kernel Development > - > ASL, Inc. Toll free: 1-877-ASL-3535 > 1757 Houret Court Fax: 1-408-941-2071 > Milpitas, CA 95035Web: www.aslab.com -- Wilfried Weissmann ( mailto:[EMAIL PROTECTED] ) Mobile: +43 676 965 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Help with Fasttrack/100 Raid on Linux
Andre Hedrick wrote: Wilfried, Why a module? The idea behind that was that, if it is a seperate module, then it would be easier to maintain for me. I am a guy that always needs the newest and greatest, so I expected that I would have to port my stuff to newer kernels frequently. (I started the HPT-RAID0 alone without much knowledge about the kernel.) Why not have the detection and flags that hook the md driver for linux and use linux's software raid? I could not use the disk striping, because of the raid0 code is not capable of processing a request what would span more than one disk. You also have to shift the offset of all but the first disk by 10 sectors. So I created an own personality... I also guess it would be a bit complicated if we want to create a raid10. Is this done by putting a raid1 over raid0 devices? We would have to find a way to map the sectors according to the IDE-RAID spec of the controller over several raid levels. An ataraid personality would be easier and more flexible then. regards, Wilfried Cheers, On Mon, 16 Apr 2001, Wilfried Weissmann wrote: Arjan van de Ven wrote: In article [EMAIL PROTECTED] you wrote: Andre Hedrick wrote: However as far as I can see everyone who has a FastTrak which is "stuck" in RAID mode[1] would be happy if it worked as a normal IDE controller in Linux, which is (usually?) not the case - eg on the MSI board where only the first channel is seen. I have a patch to work around that. However the better solution would be to have a native driver for the raid; I plan to start working on that next week... I am doing the same for the HighPoint-Tech 370 (talking about the RAID driver). Disk-striping is working so far. My code is based on the kernel patches for MDs from Neil Brown. I created an own RAID-personality for the module. When I looked at the FreeBSD implementation I had the idea of making a "supermodule" which could contain serveral IDE-RAID drivers (e.g.: Proise FastTrack + HPT370). There would be a super personality for ATA-RAID and several low-level drivers for the individual controllers. Interrested? Ideas? Hints, Tips, ...? Wanna team up? 8) Greetings, Arjan van de Ven regards, Wilfried PS: An uppercase THANX goes to Nail Brown! ^Nail^Neil Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com -- Wilfried Weissmann ( mailto:[EMAIL PROTECTED] ) Mobile: +43 676 965 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Help with Fasttrack/100 Raid on Linux
Arjan van de Ven wrote: > > In article <[EMAIL PROTECTED]> you wrote: > > Andre Hedrick wrote: > > > However as far as I can see everyone who has a FastTrak which is "stuck" > > in RAID mode[1] would be happy if it worked as a normal IDE controller > > in Linux, which is (usually?) not the case - eg on the MSI board where > > only the first channel is seen. > > I have a patch to work around that. However the better solution would be to > have a native driver for the raid; I plan to start working on that next > week... I am doing the same for the HighPoint-Tech 370 (talking about the RAID driver). Disk-striping is working so far. My code is based on the kernel patches for MDs from Neil Brown. I created an own RAID-personality for the module. When I looked at the FreeBSD implementation I had the idea of making a "supermodule" which could contain serveral IDE-RAID drivers (e.g.: Proise FastTrack + HPT370). There would be a super personality for ATA-RAID and several low-level drivers for the individual controllers. Interrested? Ideas? Hints, Tips, ...? Wanna team up? <8) > > Greetings, > Arjan van de Ven regards, Wilfried PS: An uppercase THANX goes to Nail Brown! -- Wilfried Weissmann ( mailto:[EMAIL PROTECTED] ) Mobile: +43 676 965 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Help with Fasttrack/100 Raid on Linux
Arjan van de Ven wrote: In article [EMAIL PROTECTED] you wrote: Andre Hedrick wrote: However as far as I can see everyone who has a FastTrak which is "stuck" in RAID mode[1] would be happy if it worked as a normal IDE controller in Linux, which is (usually?) not the case - eg on the MSI board where only the first channel is seen. I have a patch to work around that. However the better solution would be to have a native driver for the raid; I plan to start working on that next week... I am doing the same for the HighPoint-Tech 370 (talking about the RAID driver). Disk-striping is working so far. My code is based on the kernel patches for MDs from Neil Brown. I created an own RAID-personality for the module. When I looked at the FreeBSD implementation I had the idea of making a "supermodule" which could contain serveral IDE-RAID drivers (e.g.: Proise FastTrack + HPT370). There would be a super personality for ATA-RAID and several low-level drivers for the individual controllers. Interrested? Ideas? Hints, Tips, ...? Wanna team up? 8) Greetings, Arjan van de Ven regards, Wilfried PS: An uppercase THANX goes to Nail Brown! -- Wilfried Weissmann ( mailto:[EMAIL PROTECTED] ) Mobile: +43 676 965 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: UDMA(66) drive coming up as UDMA(33)?
"David St.Clair" wrote: > > I'm trying to get my hard drive to use UDMA/66. I'm thinking the cable > is not being detected. When the HPT366 bios is set to UDMA 4; using I think that should be UDMA 5 for 66? As far as I can remember UDMA4 is 33MHz with S.M.A.R.T. which add some reporting functionality. But I might be wrong... > hdparm -t, I get a transfer rate of 19.51 MB/s. When the HPT366 bios is > set to PIO 4 the transfer rate is the same. Is this normal for a UDMA/66 > drive? What makes me think something is wrong is that the log says > > "ide2: BM-DMA at 0xbc00-0xbc07, BIOS settings: hde:pio" <-- PIO? > > and > > "hde: 27067824 sectors (13859 MB) w/371KiB Cache, CHS=26853/16/63, > UDMA(33)" <--- UDMA(33)? shouldn't it be UDMA(66)? I got (kernel 2.2.18): HPT370: IDE controller on PCI bus 00 dev 98 HPT370: chipset revision 3 HPT370: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xe800-0xe807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xe808-0xe80f, BIOS settings: hdc:DMA, hdd:pio hda and hdc are my hd's. My mainboard is a Abit KT7-RAID. > > Any ideas what might be wrong? Possible bug? I would set the UDMA5 for the HDs in the HPT bios. good luck, Wilfried - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Promise RAID controller howto?
Andre Hedrick wrote: > > On Tue, 27 Mar 2001, Henning P. Schmiedehausen wrote: > > I know, that "input high == UltraATA core, input low = RAID core" > > according to Andre Hedrick but I really don't care about the RAID > > core. I want to use this controller to drive JBOD. > > Wrong, if Promise will opensource the signatures then we map the software > raid against that location and use Linux's soft-raid. FreeBSD supports this ATA-RAID. I have got a printout of the sources here. From where did they get the permissions/code/docs... to put it into their kernel? Currently I am working on kernel 2.4 RAID support for HPT370 (also included in FreeBSD). I hope it will work soon. I want to upgrade to debian-woody. regards, Wilfried PS: You are right, these IDE-RAID "controllers" are pain. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Promise RAID controller howto?
Andre Hedrick wrote: On Tue, 27 Mar 2001, Henning P. Schmiedehausen wrote: I know, that "input high == UltraATA core, input low = RAID core" according to Andre Hedrick but I really don't care about the RAID core. I want to use this controller to drive JBOD. Wrong, if Promise will opensource the signatures then we map the software raid against that location and use Linux's soft-raid. FreeBSD supports this ATA-RAID. I have got a printout of the sources here. From where did they get the permissions/code/docs... to put it into their kernel? Currently I am working on kernel 2.4 RAID support for HPT370 (also included in FreeBSD). I hope it will work soon. I want to upgrade to debian-woody. regards, Wilfried PS: You are right, these IDE-RAID "controllers" are pain. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: State of RAID (and the infamous FastTrak100 card)
Jakob Østergaard wrote: > > So... am I just begging for pain if I try to install, say, a stock RH7 > > on a machine with the FastTrak100 doing it's little RAID0/JBOD thing? > > If it requires this machine to always boot from a floppy because the driver > > cannot be linked into the kernel, well, I'm okay with that. > > I don't know about the state of the FastTrak100 IDE drivers - but if you can > get that running, putting software RAID on top of that should be a simple > matter. I do not think that would work. These IDE RAID use a slightly different layout that someone would expect. This means that you cannot map it 1:1 to any RAID personality, therefore you cannot boot from it. (Free)BSD supports this IDE RAID controller with the RAID functionality. Maybe you want to check it out. I want to write a kernel module for 2.4 which supports the HPT370 RAID. You can be sure that I will peek at the FreeBSD code. In fact that is the only documentation I have. Wilfried - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: State of RAID (and the infamous FastTrak100 card)
Jakob stergaard wrote: So... am I just begging for pain if I try to install, say, a stock RH7 on a machine with the FastTrak100 doing it's little RAID0/JBOD thing? If it requires this machine to always boot from a floppy because the driver cannot be linked into the kernel, well, I'm okay with that. I don't know about the state of the FastTrak100 IDE drivers - but if you can get that running, putting software RAID on top of that should be a simple matter. I do not think that would work. These IDE RAID use a slightly different layout that someone would expect. This means that you cannot map it 1:1 to any RAID personality, therefore you cannot boot from it. (Free)BSD supports this IDE RAID controller with the RAID functionality. Maybe you want to check it out. I want to write a kernel module for 2.4 which supports the HPT370 RAID. You can be sure that I will peek at the FreeBSD code. In fact that is the only documentation I have. Wilfried - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
