Hi there,
The HPT chipset on the KR7A-RAID is not detected. It comes through with a
revision 5, which crashes the Kernel (panic) on 2.4.16. The patch below
adds the revision for the HPT372 chipset which is the relevant one,
however this will break again when a new revision comes out. I would like
to be able to print a warning if the revision is higher than the one in
the array and if it is allow a parameter to fake the chipset as being a
lower one (at the users risk), but quite frankly my Kernel programming is
not that good!!
I don't know if this has been fixed in 2.4.17/18, if it has...sorry! :-)
--- linux-2.4.16/drivers/ide/hpt366.c Wed Feb 20 10:35:25 2002
+++ linux/drivers/ide/hpt366.c Wed Feb 20 10:37:37 2002
@@ -207,7 +207,7 @@
char *p = buffer;
u32 bibma = bmide_dev->resource[4].start;
u32 bibma2 = bmide2_dev->resource[4].start;
- char *chipset_names[] = {"HPT366", "HPT366", "HPT368", "HPT370", "HPT370A"};
+ char *chipset_names[] = {"HPT366", "HPT366", "HPT368", "HPT370", "HPT370A", "HPT372"};
u8 c0 = 0, c1 = 0;
u32 class_rev;
--- linux-2.4.16/drivers/ide/ide-pci.c Wed Feb 20 10:35:25 2002
+++ linux/drivers/ide/ide-pci.c Wed Feb 20 10:37:22 2002
@@ -828,7 +828,7 @@
ide_pci_device_t *d2;
unsigned char pin1 = 0, pin2 = 0;
unsigned int class_rev;
- char *chipset_names[] = {"HPT366", "HPT366", "HPT368", "HPT370", "HPT370A"};
+ char *chipset_names[] = {"HPT366", "HPT366", "HPT368", "HPT370", "HPT370A", "HPT372"};
if (PCI_FUNC(dev->devfn) & 1)
return;
--
Andy Jeffries
Linux/PHP Programmer
- Windows Crash HOWTO: compile the code below in VC++ and run it!
main (){for(;;){printf("Hung up\t\b\b\b\b\b\b");}}
On Thu, 21 Feb 2002 04:28:31 -0500 (EST), Alec Smith <[email protected]> wrote:
> Did you check Andre Hedrick's IDE patches at http://www.linuxdiskcert.org?
> For unexplained reasons, the power penguins refuse to take Andre's work
> into the standard kernel even though he's the official IDE/ATA maintainer.
> Andre may have already solved your problem.
In Andre's 2.4.16 patch (from that website), the chipset_names array still
doesn't contain the HPT372 chipset and I'm guessing it will still panic
the kernel because at lines 1433-1437 of the patch it says:
+ pci_read_config_dword(dev, PCI_CLASS_REVISION, &class_rev);
+ class_rev &= 0xff;
+
+ p += sprintf(p, "\nController: %d\n", i);
+ p += sprintf(p, "Chipset: HPT%s\n", chipset_nums[class_rev]);
Now, if the class_rev is one higher than the number of items in the array
(which it is because chipset_names is now called chipset_nums but it just
contains slightly different strings, i.e. not starting with HPT) it will
still reference an item in the array beyond bounds. A hacky patch my boss
found on the internet (he's the one with the motherboard) did the
following:
+ if(class_rev >= (sizeof(chipset_names)/sizeof(char *))) {
+ class_rev = (sizeof(chipset_names)/sizeof(char *)) - 1;
+ }
I think this is awful, but as I said, I'm not a good enough Kernel
programmer to die gracefully or depending on a passed in parameter fake it
to be the end of the chipset array (which the dirty hack above doesn't
solve, if there are two further revisions it will break again).
Kind regards,
--
Andy Jeffries
Linux/PHP Programmer
- Windows Crash HOWTO: compile the code below in VC++ and run it!
main (){for(;;){printf("Hung up\t\b\b\b\b\b\b");}}
> I don't know if this has been fixed in 2.4.17/18, if it has...sorry! :-)
Its fixed in 2.4.18-ac at least, and I think in 2.4.18-rc2. Give that a
go and check its ok
On Thu, 21 Feb 2002 13:22:37 +0000 (GMT), Alan Cox <[email protected]> wrote:
> > I don't know if this has been fixed in 2.4.17/18, if it has...sorry! :-)
>
> Its fixed in 2.4.18-ac at least, and I think in 2.4.18-rc2. Give that a
> go and check its ok
I'll pass this on to my boss who is the one with the board.
Cheers,
--
Andy Jeffries
Linux/PHP Programmer
- Windows Crash HOWTO: compile the code below in VC++ and run it!
main (){for(;;){printf("Hung up\t\b\b\b\b\b\b");}}
On Thu, 21 Feb 2002 13:22:37 +0000 (GMT), Alan Cox
<[email protected]> wrote:
> > I don't know if this has been fixed in 2.4.17/18, if it has...sorry!
> > :-)
>
> Its fixed in 2.4.18-ac at least, and I think in 2.4.18-rc2. Give that a
> go and check its ok
Hi Alan,
It's not fixed in 2.4.18 (released version).
At least, the array of HPT chipsets doesn't have the 372 entry. Does it
fix it neatly (if the index of the revision is above the array label it as
unknown)?
It doesn't seem to as line 225 in drivers/ide/hpt366.c seems to just use
class_rev as an index in to the chipset_names array (which will bomb out
it it tries to access class_rev=5).
Any chance of getting the earlier patch submitted to the mainstream Kernel
by someone who Linus will listen to ;-) (P.S. Linus, if you're listening
sorry for the aspersion that you ignore patches from people, it's just
that I am a lowly Kernel newbie who you won't know/trust (YET!)).
Cheers,
--
Andy Jeffries
Linux/PHP Programmer
- Windows Crash HOWTO: compile the code below in VC++ and run it!
main (){for(;;){printf("Hung up\t\b\b\b\b\b\b");}}
> At least, the array of HPT chipsets doesn't have the 372 entry. Does it
> fix it neatly (if the index of the revision is above the array label it as
> unknown)?
Yep
> It doesn't seem to as line 225 in drivers/ide/hpt366.c seems to just use
> class_rev as an index in to the chipset_names array (which will bomb out
> it it tries to access class_rev=5).
I'll check that one. Arjan fixed ide-pci. There may be one that isnt fixed
in the -ac tree. I'm not suprised the base tree doesnt work tho