General "Works For Me" Post.

From: Gerard Sharp (gsharp@ihug.co.nz)
Date: Tue Jun 06 2000 - 08:41:40 EST


Hello there.

This is intended to be the opposite of the expected post to lkml - not
something protesting / identifying an error / bug; but rather something
congratulating the lack of them :)

General system specs:
Abit BP6 running 2 Celeron 466; 128Mb ram, 13.6gig IDE disk (using
ata33)
linux-2.4.0-test-ac7 smp
RedHat 6.2 + updates needed for 2.3 kernels

The two specific options in the kernel marked "EXPERIMENTAL" that I use
and have no errors with:
*1* Matrox Mystique Frame Buffer console:
===
matroxfb: Matrox Mystique (PCI) detected
matroxfb: MTRR's turned on
matroxfb: 1024x768x8bpp (virtual: 1024x2044)
matroxfb: framebuffer at 0xE5000000, mapped to 0xc8805000, size 2097152
Console: switching to colour frame buffer device 128x48
fb0: MATROX VGA frame buffer device
===
and lspci reports of it:
00:0b.0 VGA compatible controller: Matrox Graphics, Inc. MGA 1064SG
[Mystique] (rev 02)

*2* SuperIO chipset support for Parallel Ports:
===
Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
Winbond chip at EFER=0x3f0 key=0x87 devid=52 devrev=f4 oldid=ff
Winbond chip type 83977EF / SMSC 97w35x
Winbond LPT Config: cr_30=01 60,61=0378 70=07 74=03, f0=05
Winbond LPT Config: active=yes, io=0x0378 irq=7, dma=3
Winbond LPT Config: irqtype=pulsed low, high-Z, ECP fifo threshold=0
Winbond LPT Config: Port mode=EPP-1.7 and SPP
SMSC Super-IO detection, now testing Ports 2F0, 370 ...
parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
parport0: cpp_daisy: aa5500ff(98)
parport0: assign_addrs: aa5500ff(98)
parport0: cpp_daisy: aa5500ff(18)
parport0: assign_addrs: aa5500ff(18)
lp0: using parport0 (polling).
===
prints text and graphics without any worries.
Only comment is, presumably due to debugging, outputs a lot of (the
above) text to console on modprobe

APM power off on SMP also works fine; although I had trouble finding
details on how to enable this, so just hacked arch/i386/kernel/apm.c

Final note:
As a BP6 user, I note the (in)famous
===
APIC error interrupt on CPU#1, should never happen.
... APIC ESR0: 00000000
... APIC ESR1: 00000004
... bit 2: APIC Send Accept Error.
===
messages, which I understand are due to poor/marginal motherboard
design.
Can these messages lead to anything nasty happening (like missed /
spurious interrupts, degrading system stability); or are they merely
informative ?
And, as such, is it feasible to add a config option to suppress / reduce
the priority of these messages' printk; so as not to affect console with
them ?
I would/will readily spend the few minutes to dream up such an option;
but it is late and I should be asleep, not cluttering the mailing list
(too late); but if anyone thinks it a worthy expense of time, I'll code
it :)

Thank you for the beautiful operating system, and I look forward to not
having to post any more bug reports in the future

/~ Gerard Sharp ~\
\_ More BogoMips than Sense _/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:25 EST