Those bus errors must have been going on for a long time, causing all sorts of erratic behavior, and I never knew what was happening because the error was only reported in the terminal window after issuing a number of text commands. So now I’m thinking: how can we make Linux better? If the kernel knows when bus errors occur, there should be a way for it to pass that information to the GUI, so the GUI can notify the user that the hardware is failing. Then the user will not suspect that something is wrong with the software. I have to admit that Linux in general and Ubuntu in particular is fairly impressive, from the standpoint that it kept running long enough for me to do a number of things before shutting down, despite the bus errors and core dump. But it would be even more impressive if the OS could tell the user when they have bad hardware. So I just wanted to put this out there for people to think about.

It’s obvious that Ubuntu’s developers want to rule out problems which aren’t their fault. You can easily check the installer CD for defects, and test for bad memory too. But there is no easy way to learn about other hardware failures even though the kernel knows when they occur. I had run a memory diagnostic all day on that board and the RAM was fine. But after I learned about the bad capacitor epidemic, and that my own system board was a casualty of this, it occurred to me that millions of people might be suffering from system instability problems caused by faulty hardware. Now that I have seen how the Linux kernel can detect bus errors and keep on running long enough to report them, I know this is a problem which can be resolved. I hope the Linux community will start discussing this and soon hardware fault reporting will be a common feature of the popular desktop user interfaces, not just the kernel.

I suppose that any hardware subsystem which is failing might generate a bus error because it won’t respond to data transfer requests in a timely fashion. A bus error might even be caused by a cable fault. And then there could be noise on the bus or poor signaling due to faulty capacitors. If you really need the board because of the interfacing options that it supports, you might want to find out what’s wrong and repair it. In that case, it would be nice to classify the exact nature of the error. But the present ambiguity does not have to be a disadvantage: the typical user just wants to know the board is bad, and that is what developers should address first.

Even if hardware fault detection and reporting never progresses beyond the point of saying “bus error,” I think the GUI should play some role in conveying this information to the user. You could also have an LED indicator on the front panel, similar to the “check engine” light on your car. If the OS detects bus errors, it could set a flag in CMOS/NVRAM, the same way it updates the clock. The firmware could read this register at boot time, and turn on the light if necessary. You could reset this flag if you wanted, and then wait to see how long it took before the light turned on again. That might tell you if the error was caused by some kind of rare power anomaly, or if the board is really defective.

If you are logging power faults through the sensors on the UPS, then the OS might be able to guess whether or not the bus error was due to a hardware failure. That kind of information would be very useful, not just to the end user, but also to the IT guy who has to manage a rack of servers and keep them running continuously. I think everyone would agree that the less time you spend troubleshooting defective equipment, the better. It’s well within our capability to do something about this, and it does not necessarily have to involve a radical change in hardware or software design.

All in all it looks like it will be very well done. Keep up the good work (goes for the teams as well)!
Lucas

Mark Shuttleworth says: Do you feel better now?

Good luck to implement this ! I really can’t wait to see it into action. Where could we get (or where will we get) in Launchpad the code and packages to test it ?

–kalon33.

Long live the ubuntu developers…

To that end, any way for a user or a system administrator to decide what notifications should be persistent?

hover the mouse pointer over a new notification to prevent it fading away (no click required).

with the mouse pointer hovered over the notification, use either the scroll wheel or keyb up and down arrows to scroll back through all the notifications received during the current session only, retaining any click actions for each notification if valid.

i’m sure the compiz developers could come up with some nice animations for flicking back and forward through them.

Hermes shows piled messages (some of them are clickable) whenever an important event occurs.

It is coded in python, but i18n was not a priority so I am afreid comments are still in spanish.

I didn’t know where to turn to so I ended up here. It’s nice to see some ideas and changes for the upcoming Ubuntu release but however it would be nicer to see some more hardware support. It would be great if you and the developers focus on that part a bit more.

For example some wireless cards like the Realtek RT2860 and some High Definition Audio soundcards. I have tested some other linux distro’s where the wireless card worked right out of the box (openSUSE, Mandriva for example). Installing Ndiswrapper and the Windows driver to activate the wireless card isn’t always that effective and most of the time it doesn’t work properly. It takes 10 to 15 minutes before it’s activated after the desktop is loaded.

The issues with the HDA soundcards is an overall problem in every Linux distro that’s around. So it would be nice to see Ubuntu being the first distro that solves these problems and let it work out of the box. If that is possible of course.

Overall I am satisfied Ubuntu user for a year now and i say: Keep up the great work.

With kind regards,

Maik