hello,

I trie dto install fedora 7 on Pegasos and after choosing language, keyboard and that it will be installed from local disk I was prompted with message saying that there is no driver available for device it should be installed from.
Does anyone have similar experience and how to solve it?

thanks,


veki

AFAIK, Fedora is changed to use libata, just as most recent distributions. 'pata_via', the libata version of the VIA IDE driver, which is needed for Pegasos, is pretty much broken. The old, working version is not included. This practically means, that not even the CD is seen by the installer, once it's booted...

Once upon a time, I reported it without any response. As I prefer openSUSE, Gentoo, Ubuntu (in the order of appearance :-) ) I did not care any more...

Ubuntu keeps using the working driver, openSUSE-factory can be forced to ignore 'pata_via' with the 'brokenmodules=pata_via' boot parameter.

_________________
CzP
http://czanik.blogs.balabit.com/

Hello,

Does it mean that Fedora 7 will hardly seat on Pegasos2 ?

Thanks,

veki

Yes, unless someone makes an installer which supports the old VIA IDE driver.

_________________
CzP
http://czanik.blogs.balabit.com/

I have an idea.

Peter, anyone, can you do the following in firmware;
And tell me if pata_via starts working? lspci -nnvvvxxx output while the installer is running would be awesome too.

If it works I'll give you a Forth script you can place on a USB key and boot to boot the Fedora CD..

For those who want to debug some untested Forth scripts NOW:

http://mithrandir.softwarenexus.net/nek ... -fix.forth

Simply plonk it on a disk (usb, ata, whatever) and boot it. You can modify the script to boot (at the end) the operating system in question. It may break! I couldn't test it properly since I don't have a Pegasos nearby.

_________________
Matt Sealey

Yes, libata doesn't work normaly on Peggy and I reported this already http://bugzilla.kernel.org/show_bug.cgi?id=8649

I will give a try to this script in a few mins and report the result here.

Okay. What this should do is encourage libata to probe for two interrupts by looking at the IRQ steering register in the ISA bridge;

http://bugzilla.kernel.org/show_bug.cgi?id=8649#c11

Which should fix the report at Comment 11 (both IRQ are 14) so that you get two IRQs.

Any further quirks, we will have to look into.

_________________
Matt Sealey

It seems 0x8a 0x00006124 config-b! makes no diffrence at last here. DVD is still not recognized and both channels works at irq 14.

I wonder how safe is to test this forth script. I have no second machine to test and it would be catastrophic for me to lose data from hd in case of mistake/problem.

All it does is change a byte in the configuration area. The functions do not make any crazy changes. Peter Czanik already tested lightly and found it still doesn't work, but.. it should be totally, totally safe. libata has a billion checks against standards.

Try uncommenting the .cregs parts above and below the config-b! in the script, to see if the configuration registers change (8f 01 01 should change to 8a 01 01) too. It may not even be DOING anything for all I know; I have no way of checking if the value changes in the register. Just run the script and check the config register output from firmware, then turn off and turn back on again. We will take it slowly :D

There are all kinds of cool things you can do in the firmware using Forth, some dangerous, some not, but you can fix up a lot of the "bugs" in the firmware without waiting for bplan (I am not entirely sure I want to write an ext2fs driver in Forth though)

_________________
Matt Sealey

I tired this script, but as a result it prints only a few pages of spaces on the screen and I rebooted the machine.

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 ?

BTW You send e-mail to box43.pl account ? This e-mail is dead like hell. Can you resend it to morgoth6 (a t) gmail . com ?

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 :)
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;

http://marc.info/?l=linux-ide&m=117612521603733&w=1

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.

http://marc.info/?l=linux-ide&m=118257261207300&w=1

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

http://www.powerdeveloper.org/files/Pegasos/ide_fixup.c

Here's the "Linux kernel fixup" version. It goes at the bottom of arch/powerpc/platforms/chrp/pci.c in your Linux kernel. I based it on 2.6.22-rc7.

I am not confident that we can make these tweaks in a Forth script without breaking IDE booting, or causing weird lockups or hacking the PCI bus manually.

So, here is the path of least resistance, a kernel patch which hopefully configures the IRQ steering so that the device really does act as a PCI native device.

Testers would be much appreciated. I'd like this to get into SuSE if possible, Peter :)

_________________
Matt Sealey

I hope this will be all fixed with Fedora 8 again.

_________________
..:: www.djbase.de ::..

There is ')' missing around if() in this file. Anyway tested with finak 2.6.22 and as expected both irq's are set to 14, but I am affraid this doesn't help with my problem with ATAPI device and I still can see timeout errors on boot :( Same as previous.

Oh well, I happen to work for suse. Just open a bugzilla entry at bugzilla.novell.com and assign it to teheo@novell.com after the fixup is verified and combined with IDE un-quirking.

_________________
tejun