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
On Thu, May 08, 2003 at 01:51:04AM +0200, Felix von Leitner wrote:
> 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.
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/
> 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.
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.
On Thu, May 08, 2003 at 01:51:04AM +0200, Felix von Leitner wrote:
> 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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
For the vesafb just remove the EDID ifdef in drivers/video/vesafb.c,
line 303 to 308.
--
In stuga.ml.linux.kernel, you wrote:
> ipv6 is still broken because running npush and then starting npoll on
> another virtual terminal will hang the kernel hard instantaneously.
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.