2.5: ieee1394 still broken, vesafb still broken, ipv6 still broken

I am surprised that Linus thinks now is the time to move towards a stable 1.6 release, I don't see any sign for increased stability in 2.5.59. I am still forced to use 2.5.53 because that is the last kernel that has working ieee1394.

To reiterate the problems:

ohci1394 detects my controller, sbp2 gets the same unsolicited packets
from my Maxtor firewire hard disk as 2.5.53, but no sign of a detected SCSI device.

vesafb is told to go to 1024x768-32, does so, but then reads from my
TFT display that 1600x1200 is the native resolution and then thinks that is the resolution it is using (even fbset says so). The result is that I can only see the upper half of my screen, and the display is garbled to boot because the line length is too large, meaning writing something in the right half of the 1600x1200 screen results in overwriting something on the left of my real 1024x768 screen.

ipv6 is still broken because running npush and then starting npoll on
another virtual terminal will hang the kernel hard instantaneously. So hard, in fact, that I don't have a trace I could give you. Since vesafb is broken (hint, hint), I only see the last lines, which say something about a fatal error in an interrupt routine and a callback where the last lines are call_socketcall and call_syscall (IIRC). npush and npoll are from the ncp package, which you can find at
http://www.fefe.de/ncp/

We should not make any wind about even mentioning 2.6 to the press until we at least reach the basic functionality requirements, let alone stability of 2.4. I find the situation pretty embarassing considering that I am running around and telling customers to install Linux (come see me at LinuxTag, by the way, I'm talking about scalable network programming on Linux there. It would be really embarassing if I couldn't present the slides about the cool 2.5 features because 2.5 just happens to still suck then.

And if you are right now considering to tell me that I should go to nvidia tech support, please limit yourself to private email as to reduce the embarrassment and damage you are causing to the rest of this list with Theo DeRaadt style user alienation. And unless you are going to investigate these, don't even bother with private email as well. Bullshit like that makes Windows look like the better option. The FreeBSD people are probably having a field day with this nvidia episode here.

Felix

Hey, maybe emailing the linux1394-devel list would help a bit with this one.

I assume you mean 2.5.69 and not 2.5.59. Does it work in 2.5.54? If so, did you diff 2.5.53 and 2.5.54 and see if you could pinpoint what caused it to stop working?

Since this is the first I've heard of your report (just checked recent linux1394-devel messages and I don't see your name), we'll have to start from scratch on your problem. Since I have been using 2.5.x for a long time with ohci1394 and sbp2, and I've heard no other reports of this kind, I can honestly say that your report is not the norm. In fact, current 2.4/2.5 is the most stable ieee1394 code there is.

Just to put it into perspective I currently have an i386 running 2.5.69 with ohci1394/sbp2 for burning DVD's, and my ultrasparc has a 200gig LaCie drive attached to an S800 card that handles backups from all my systems on a nightly basis. I haven't even seen the first notion of a problem for quite some time (all the ones I did see are fixed).

Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

The EDID blocks often return the wrong data. The fix for now is to remove the edid code. I will passing it to Linus soon.

For the vesafb just remove the EDID ifdef in drivers/video/vesafb.c, line 303 to 308.

I can confirm that. I ran into the same problem so weeks ago, but lacked the time for a proper bugreport. I just did so (#692), and instead of writing a weepy 50-lines-rant you should have done the same.