I tired this script, but as a result it prints only a few pages of spaces on the screen and I rebooted the machine.
Well, I didn't test it AT ALL. I just wrote it and threw it up there. In theory it shouldn't even get past the first line (it's broken :)
Hmmm, I wonder can same fix may be done inside kernel ? maybe a kernel patch with some fixups for pegasos would be better idea. What do you think ?
Firstly, the fix that was in the old block layer (a check for a Pegasos and a silly hwif->channel ? 15 : 14 switch) was stupid and wrong anyway. The correct procedure is to check the IRQ steering register in the southbridge if the chip is in native mode, and see if it is handling two interrupts instead of just one. I wrote a patch for it once;
Secondly, libata handles this particular configuration but you're meant to have set up the Southbridge properly in the first place (by changing the programming interface class code) in the firmware/BIOS.
Pegasos doesn't because the Linux block layer never wanted it that way and at the time, libata did not exist in the mainline kernel let alone have a Via PATA driver.
It just goes to show that crappy Linux driver code makes it's way into fixes in firmware operation way too easily. Since Linux driver quality is fairly low (in my opinion), it forced the IDE chipset to be set up in a certain way. Now Linux has changed to be better, Firmware needs fixing to return to correct operation.
This is not how firmware development should be! :)
Thirdly, Alan Cox and Jeff Garzik (Linux IDE/libata guys) has stated that this should be done in Firmware. A Forth script or nvramrc entry is the best way to do this without waiting for the Firmware bugfix.
They did suggest a PCI platform code quirk (this can be done in the chrp code..) the same way, however I do NOT think making 5 distributions patch their kernels in an emergency for testing and vetting them for code freezes in a couple weeks is a good idea. We would have to have found the bug a month or 5 ago and worked out a solution then, and gone through an arduous process of putting the patch into mainline (it wouldn't even make 2.6.23-final by now).
I am trying my hardest to keep patches for "Broken Firmware" out of the Linux kernel. They are unmaintainable. For every Linux kernel that has a new fix, you need to update your kernel. It doesn't help us or the distributions to play this moving target game. It also doesn't help every other OS to have to integrate those same fixes or be forced to use a special boot loader patch (GRUB, yaboot, whatever).
The more changes can be handled by simply running a Forth script or a small program before the Linux kernel loads, the better. Fixes can be rolled out independantly of Firmware and independantly of Operating System.
So, no, C code, binary boot loaders, kernel patches are not an option. None of us at Genesi or bplan want to waste valuable time fixing the firmware (especially when it is so minor as a string) so that Linux developers are happy, and none of the Linux developers want it integrated into their kernel.
I'll be happy to work on this script with others, and see if it works in the end. My goal is to provide a superfantastic Forth script library which performs any and all the fixes any Pegasos or Efika user might want, before Linux loads, and in the even that the Linux driver sucks, fix the Linux driver to standards, and in the event that the Firmware has a bug, work around it with the script.
My current attempt for a boot loader doesn't work properly (I just had a data loss event too) but it will make the basis of a competant, seperate-initrd loader script, which can be attached to a boot menu, further fixes, pretty shinies and anything you care to mention. At a few kilobytes there would be no space issues and it's easily updated to run from a USB key (and boot a CD or network kernel) or whatever you like.
Matt Sealey, Genesi USA Inc.
Product Development Analyst