Re: matroxfb, 2.6 and 2.4

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


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com