New SATA PCI card findings
by
zen
This will be brief... as there really isn't much to tell, but a more recent finding has changed everything for me.
About three or four years ago, I had come to the conclusion that booting from SATA PCI cards was only about 99.9% stable. This is because every so often things would just lock up system-wide, and I would be forced to do a hard boot. Not a good thing when you're smack dab in the middle of important work. After tolerating it for a couple years... I finally decided that I would stick to SATA card attached drives for storage only, and boot from IDE/PATA drives instead.
About four or five months ago, I realized that during all those system lockups I had drive sleep enabled. So I decided to try it for a while without any type of sleep enabled, other than display sleep, which has no effect whatsoever on hard drives. I never use system sleep, as my systems are always 24/7 on, but I normally use drive and display sleep on every OS.
So I have now been running a WD Caviar Black 2TB as my boot drive for about five months, with drive sleep disabled on every OS, and have never once had an issue. I have now found 100% reliability with SATA card booting!
The WD Black is the perfect drive to use in a system where drives don't sleep, because it's built for higher endurance than most drives, and has more performance to go along with that.
I had already tried every version of firmware for my FirmTek SATA cards, and nothing solved it, but disabling drive sleep did. The only real difference now in my computing habbits is that I need to unmount all the externals I'm not using, since they are typically backup drives, and don't go to sleep any longer.
Keep in mind that these finding are all based off use in two Sawtooth, along with one Gigabit Ethernet system.
Anyway, I had told some readers in the past via comments that SATA card booting wasn't 100% stable, and I just wanted to share how I did find that sweet spot on my hardware.
For the record... this is all with the FirmTek SeriTek/1S2 PCI controller; I own three. The Sonnet 2-port PCI is the same card, as they are made for Sonnet by FirmTek. By the way... the best firware to use in G4 towers is 5.1.3. You still need to disable drive sleep, but the newer firmware (5.3.x) is meant for early G5's with standard PCI, and most of these cards ship with the newer version. So if you have a G4, and you have the 5.3.x firmware, you need to downgrade to 5.1.3 for best results. You can download the 5.1.3 firmware here.
Please share any SATA PCI controller stories and findings you may have in comments.
G5: (And G4) Nouveau Modesetting Bug and Fix Explained
by
B-rock
This is an expansion of the bug report Dan linked to in the previous post here at the PowerPC Liberation blog regarding a specific PPC bug which happened to break nouveau modesetting for PPC Nvidia card users. Much of what I am about to discuss is a already covered in relevant bug report, but I thought I would put it out here with the hope that more individuals would learn about the bug, what it consisted of, the workaround, and how it was fixed. So with these goals in mind, let us move to the meat of this post.
The Bug
The same Debian user, Peter Saisanas, who reported on the page size and MSI interrupt issue with nouveau on G5 PowerMacs and supplied a working kernel for it, was also the individual who reported on the broken modesetting bug I am discussing in this post. Kernel versions starting after 3.18.16 started to showcase problems attempting to extract the FCODE ROM / DCB block for PPC machines' GPUs through the machine's Open Firmware (OF) device tree.
What are these FCODE ROMs and DCBs? FCODE ROMs are essentially Open Firmware expansion image ROMs containing bytecode as well as PPC native code that include the necessary graphics device drivers and information for both boot-up and run time. It is one of the ways Apple closely tied the hardware with its software back in the day.
On the other hand, DCB stands for Data Control Block, which is at its very core just a type of data structure that describes the dataset in a program. In the context of our situation, it is just essentially the information about the graphics card's VBIOS and how and where to load it.
This is only part of the story though. The question was why was it not extracting these two things properly? Turns out that the VBIOS within OF on PowerMacs does not contain a PCIR section (this holds information about the PCI expansion ROM), which the nouveau driver's VBIOS parser now requires by default. The actual GPU PROM contains a PCIR section, but that is still separate from the OF VBIOS.
So with a PPC system unable to load this data, the kernel has a hard time communicating properly with your graphics card. Which in turns means the Nvidia card's power and capabilities are not being fully utilized. And as a result of that, the end user ends up still using the nouveau driver, but with completely software rendered graphics. This can be and usually is quite the disappointment in terms of performance on our old PPC machines.
What are these FCODE ROMs and DCBs? FCODE ROMs are essentially Open Firmware expansion image ROMs containing bytecode as well as PPC native code that include the necessary graphics device drivers and information for both boot-up and run time. It is one of the ways Apple closely tied the hardware with its software back in the day.
On the other hand, DCB stands for Data Control Block, which is at its very core just a type of data structure that describes the dataset in a program. In the context of our situation, it is just essentially the information about the graphics card's VBIOS and how and where to load it.
This is only part of the story though. The question was why was it not extracting these two things properly? Turns out that the VBIOS within OF on PowerMacs does not contain a PCIR section (this holds information about the PCI expansion ROM), which the nouveau driver's VBIOS parser now requires by default. The actual GPU PROM contains a PCIR section, but that is still separate from the OF VBIOS.
So with a PPC system unable to load this data, the kernel has a hard time communicating properly with your graphics card. Which in turns means the Nvidia card's power and capabilities are not being fully utilized. And as a result of that, the end user ends up still using the nouveau driver, but with completely software rendered graphics. This can be and usually is quite the disappointment in terms of performance on our old PPC machines.
The Workaround
The work around is quite simple and straightforward fortunately and will likely be the means for several users to at least have the 2D driver working until the patch hits mainline nouveau and works it way down into a later release of nouveau in Debian. That is unless you want to try and install the patch of which I will discuss later.
Essentially, all that is needed is for you to download the x86 VGA BIOS ROM for your specific Nvidia card and configure (force) your system to load that firmware for your graphics card at boot up. I will break it down in a few more steps though for the sake of simplicity.
1. Shutdown your system and pull out the graphics card to see exactly what manufacturer and BIOS your card consists of so you know what version you should download.
2. Browse out to Tech Power Up's VGA BIOS database. Search for and download the appropriate firmware for your card using the info you obtained earlier from the markings on the card.
3. Once downloaded, rename it to something simple and related to your Nvidia card version. For example, I used GeForce_7800_GS.fw for my Nvidia card.
mv BFG.7800GS.256.051221.rom GeForce_7800_GS.fw
4. Copy this file to your /lib/firmware/ directory. You will need root permissions to do this.
sudo mv GeForce_7800_GS.fw /lib/firmware/
5. Add a line similar to below to your desired kernel(s) in your /etc/yaboot.conf file.
append="options nouveau config="NvBIOS=GeForce_7800_GS.fw"
6. Apply the changes per usual.
sudo ybin -v
6. Reboot and once again enjoy 2D acceleration.
The Fix
Peter Saisanas reported a few days ago that a patch was created via a cloned code repository of the existing nouveau driver that should hopefully eventually hit mainline soon. I thought it would be sort of interesting to view what changes were made in the commit to resolve the issue.
A direct link to the specific patch can be found here. From the developer Ilia Mirkin's notes, the patch essentially forces the system to always accept the OF VBIOS. The only changes made according to the commit were within the priv.h, shadow.c, and shadowof.c files. I thought it would be interesting to look and dissect some of those changes (mostly the ones I can figure out with a quick glance). Follow along with the highlighted changes you see within the link to the patch/commit above and you should be able to see some of what I am talking about. I was going to post the code, but could not make it format and display in a clean and easily readable fashion as it would just squish everything into one line.
For the header file, two easily noticeable changes are two bool (true or false) variables that were added for the nouveau driver to be aware of whether or not the VBIOS it is parsing contains a PCIR section and another indicating whether the VBIOS checksum should be ignored or not. A third size variable is declared as well that as we will see later holds the size of the OF VBIOS and image it has read. Pretty straightforward.
As for the edits in the other two files they are a bit more complex, but not much. In shadow.c, an additional if statement is added to handle the situation where a PCIR section is NOT present. Also, an if statement below that was moved so that it was nested in the else statement in the above if else logic that is there for handling different situations that would result in debugging and error reporting. After that you can see some additional logic added to an if statement to tell the nouvea driver to ignore invalid checksums.
Last, but not least, there is shadowof.c, which is probably the most difficult in terms of understanding the changes. First, a new header file (core/pci.h) was included. Based on name alone, I have a feeling this header defines the interface through which linux can communicate with the PCI bus and devices on a system. I am not entirely positive about the length calculation addition, but I do know a new of_size function has been created that simply returns the size of the data that has been extracted from OF and set inside of a size variable later on in the code. Here, the two bools referenced earlier are set to true, which again basically forces the nouveau driver to always accept the image extracted from OF. The rest is not as straightforward. It would probably help tremendously to peruse some of the other code within the driver.
According to Peter, he was able to install the patch, but not without some additional edits to shadowof.c. I have yet to attempt it myself, but will do so here in the next few days and post the required changes needed to install this latest patch.
A direct link to the specific patch can be found here. From the developer Ilia Mirkin's notes, the patch essentially forces the system to always accept the OF VBIOS. The only changes made according to the commit were within the priv.h, shadow.c, and shadowof.c files. I thought it would be interesting to look and dissect some of those changes (mostly the ones I can figure out with a quick glance). Follow along with the highlighted changes you see within the link to the patch/commit above and you should be able to see some of what I am talking about. I was going to post the code, but could not make it format and display in a clean and easily readable fashion as it would just squish everything into one line.
For the header file, two easily noticeable changes are two bool (true or false) variables that were added for the nouveau driver to be aware of whether or not the VBIOS it is parsing contains a PCIR section and another indicating whether the VBIOS checksum should be ignored or not. A third size variable is declared as well that as we will see later holds the size of the OF VBIOS and image it has read. Pretty straightforward.
As for the edits in the other two files they are a bit more complex, but not much. In shadow.c, an additional if statement is added to handle the situation where a PCIR section is NOT present. Also, an if statement below that was moved so that it was nested in the else statement in the above if else logic that is there for handling different situations that would result in debugging and error reporting. After that you can see some additional logic added to an if statement to tell the nouvea driver to ignore invalid checksums.
Last, but not least, there is shadowof.c, which is probably the most difficult in terms of understanding the changes. First, a new header file (core/pci.h) was included. Based on name alone, I have a feeling this header defines the interface through which linux can communicate with the PCI bus and devices on a system. I am not entirely positive about the length calculation addition, but I do know a new of_size function has been created that simply returns the size of the data that has been extracted from OF and set inside of a size variable later on in the code. Here, the two bools referenced earlier are set to true, which again basically forces the nouveau driver to always accept the image extracted from OF. The rest is not as straightforward. It would probably help tremendously to peruse some of the other code within the driver.
According to Peter, he was able to install the patch, but not without some additional edits to shadowof.c. I have yet to attempt it myself, but will do so here in the next few days and post the required changes needed to install this latest patch.
Hopefully, you, the readers, have read this post and are taking away some new knowledge of nouveau, loading of roms, and reading code, as well as learned some new terms related to your PPC computers. Once again, it is encouraging that these bugs are receiving attention and being fixed. I still strongly believe we can eventually reach a point where we can have 3D acceleration fully working on our Nvidia cards with the nouveau driver. It just involves us using our voice on the web, filing bug reports, testing the latest and greatest, and learning other ways we can help with and in development.
If you have any questions or additional comments about what I have covered here, I encourage you to drop a comment or email me directly. Or if I am just flat out wrong about something, tell me as well as I would hate to be spreading false information.
HTTPS is now availible here
by
zen
Recently, Google added an HTTPS option to all Blogger blogs, and I am of course choosing to enable it here. So to use this blog with a secure and encrypted connection, you can bookmark this link, or simply add an 's' manually after http in your browsers address bar.
The advantages Google gives for using this new encrypted option:
- It helps check that your visitors open the correct website and aren’t being redirected to a malicious site.
- It helps detect if an attacker tries to change any data sent from Blogger to the visitor.
- It adds security measures that make it harder for other people to listen to your visitors’ conversations, track their activities, or steal their information.
So please... use this if you feel the need, and enjoy more security and privacy here. If you link to us, please feel free to add https to the address you link to.
Let me know if you have any issues with it, or any thoughts you want to share on the matter.
Progress on Debian Bugs
by
Dan
Peter Saisanas left an update on Debian's PowerPC mailing list reporting that a patch has been created to fix a bug that broke nouveau modesetting for Nvidia GPU users (bug applies to kernels > 3.18.16). The patch hasn't been made official yet, but you can view the original bug report here.
Clementine and xfburn had nasty PowerPC bugs, or perhaps just 32-bit bugs, that have now been fixed. The fixed xfburn is in Testing and the fixed Clementine as of now is in Sid. So if you haven't gotten Clementine to play files and wanted to enjoy its Spotify, Last.fm, or Soundcloud plugins, now's your chance.
In Iceweasel news, the bookmark folder bug and customization bug are fixed in version 41.0.1 in Experimental. So now Iceweasel appears back to its normal, healthy self.
Also, there's an r128 patch in this report that I haven't gotten around to testing. It fixes some breakage in the Stretch version of the driver, so Rage 128 users may want to check it out.
I suppose it wouldn't be a Debian bug reporting party if there weren't some unacknowledged bugs, and on the front I left two kernel bug reports (an appletouch trackpad bug and an Apple Motion Sensor bug). They haven't even been tagged, though the appletouch bug might have been fixed—I'm having trouble reproducing it. Possibly related: the appletouch trackpad driver performs much smoother with the latest kernel update in Sid.
Finally, if anyone wants to test the new pbbuttonsd in Experimental, see if you can duplicate this bug report. The suggested fix didn't work for me.
And if you want to literally shoot bugs, there's always MacBugs!
Subscribe to:
Posts (Atom)