From: Jonas M. <jo...@fr...> - 2004-08-03 11:09:38
|
On 03/08/2004 Petr Vandrovec wrote: > I did not found any bug descriptions in these articles. They are just > vaguely saying that 2.6.x is crap, without any explanation what > should be changed and why. sure, that's true, but i guess they are only from non-technical users, and thus not very usefull. > > i'll try to get an oops trace and some further debugging information. > > It would help a lot. sorry, it's harder than i even thought. as keyboard and screen are both frozen, i cannot lurk for console messages etc. and as i've no second machine, serial console is not possible. the logs are silent - they don't give any information: syslog has the boot logs, and directly afterwards the APCI button power off message, so nothing in the time where the freeze happened. XFree86.0.log.old ends with the successful startup of xdm, what finally causes the freeze. so no log information here too. and even kern.log doesn't give any information. and i don't understand ksymoops, when i execute it, it gives only: Error (regular_file): read_ksyms stat /proc/ksyms failed ksymoops: No such file or directory No modules in ksyms, skipping objects No ksyms, skipping lsmod don't know if ksymoops could help me in any way, but i've no further ideas about how to get debugging information. can you give me a hint? > > > > so you mean that you patch doesn't fix the bug? on irc in #kernelnewbies > > on irc.kernelnewbies.org i got the information, that your backport fixes > > at least this bug behaviour. but it might have been a liar, don't know. > > he also said, that matroxfb in 2.6 is very unstable while being > > distributed as stable. in 2.4 it was tagged as experimental. > > In 2.4.x it was marked as EXPERIMENTAL only because nobody cared. > As driver is more than 5 years old, I think that I can say that it > is well tested now. full ack, but in my case the driver doesn't seem to be very stable. btw. i didn't have any problems with matroxfb until the athlon64 system with 2.6 kernel (all previous machines ran 2.4 kernels). > I'm not aware about any problems with matroxfb in stock 2.6.x kernel. mh, very strange. to bear out the bug on software side, i tried out another g400, without dual head, and it shows exactly the same behaviour: system boots, xdm starts, and therefore starts xserver, login box pops up, you're able to input some chars, and then keyboard and screen are frozen. only APCI power off button still works to power off the system. another scenario that happens sometimes: system boots, xdm starts, immediately after login box popped up, i change to tty1, move between all vc's (tty1-6 and tty8-12), do what i want, and sometimes, nevermind if 5minutes or 3hours later, switch back to tty7 (with xdm running), and during this switch, directly after showing a grey screen the first time, the freeze happens. i'll try with dri enabled in kernel, maybe it changes anything on the situation. > There are four problems with matroxfb driver in 2.6.x kernel: > [...] > Neither of these bugs are in the matroxfb - they are features of fbdev/fbcon > layer. so no plans to fix them? > Only difference between matroxfb from platan.vc.cvut.cz, and one in > the kernel is that it supports text mode (-depth 0), and that some > PINS values are interpreted differently. Neither of these changes > can cause/fix crashes/lockups/... anyway i'll try with 2.7.8-rc2 to go sure. > But matroxfb from platan.vc.cvut.cz also comes with different fbcon, > which is more simillar to 2.4.x than to what 2.6.x offers (and which > fixes problems (2) and (3) above; (4) above is not kernel problem), > and while this may fix some other bugs I do not know about, it may > also introduce some other bugs you did not find yet. i'll check, and report. > But as I said, I'm not aware about any bugs in the matroxfb (last > famous words). we'll see, if this changes. bye jonas |