Hi,
I have a really weird problem on some amd64 machines running LinuxBIOS (agami/aruma). The serial port doesn't seem to get initialized correctly.
LB seems to report it correctly in debug output (4 and 3 are normal):
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq PNP: 002e.3 60 <- [0x00000002f8 - 0x00000002ff] io PNP: 002e.3 70 <- [0x0000000003 - 0x0000000003] irq
but Linux doesn't set it up right - in fact, Linux sets it up *differently* on occasion...
# grep ttyS.*irq messages Feb 28 15:11:36 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A Feb 28 15:11:36 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 0) is a 16550A Feb 28 15:14:53 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A Feb 28 15:14:53 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A Feb 28 15:23:24 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A Feb 28 15:23:24 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A Feb 28 15:38:58 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A Feb 28 15:38:58 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A Feb 28 15:47:21 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A Feb 28 15:47:21 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 0) is a 16550A Feb 28 16:29:34 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A Feb 28 16:29:34 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A Feb 28 16:37:18 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A Feb 28 16:37:18 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A Feb 28 17:11:02 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A Feb 28 17:11:02 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A Feb 28 18:14:49 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A Feb 28 18:14:49 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
AMIBIOS:
Jan 3 14:34:39 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Jan 3 14:34:39 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A Jan 3 16:18:45 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Jan 3 16:18:45 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A Jan 3 18:22:20 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Jan 3 18:22:20 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A Jan 3 18:29:46 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Jan 3 18:29:46 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A Jan 4 00:11:21 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Jan 4 00:11:21 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Any idea why and how that could happen?
Stefan
* Stefan Reinauer stepan@openbios.org [060302 17:23]:
# grep ttyS.*irq messages Feb 28 15:11:36 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A Feb 28 15:11:36 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 0) is a 16550A Feb 28 18:14:49 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A Feb 28 18:14:49 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
AMIBIOS:
Jan 3 14:34:39 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Jan 3 14:34:39 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A Jan 3 18:29:46 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Jan 3 18:29:46 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Any idea why and how that could happen?
Ok, here's some details:
The systems which are causing problems all have a
W83627HF revision ID = 0x17
The OK systems with linuxbios all have:
W83627HF revision ID = 0x41
Unfortunately there does not seem to be a revision guide on the winbond website. Any ideas anyone?
Stefan
* Stefan Reinauer stepan@openbios.org [060305 19:43]:
The systems which are causing problems all have a
W83627HF revision ID = 0x17
The OK systems with linuxbios all have:
W83627HF revision ID = 0x41
Unfortunately there does not seem to be a revision guide on the winbond website. Any ideas anyone?
The only information I could find: the W83627HF data sheet says:
Version | Device Rev --------+----------- G | 17 J | 3A UD-A | 41
(http://www.winbond.com/e-winbondhtm/partner/PDFResult.asp?Pname=182)
Stefan
Stefan Reinauer wrote:
- Stefan Reinauer stepan@openbios.org [060305 19:43]:
The systems which are causing problems all have a
W83627HF revision ID = 0x17
The OK systems with linuxbios all have:
W83627HF revision ID = 0x41
Unfortunately there does not seem to be a revision guide on the winbond website. Any ideas anyone?
The only information I could find: the W83627HF data sheet says:
Version | Device Rev --------+----------- G | 17 J | 3A UD-A | 41
(http://www.winbond.com/e-winbondhtm/partner/PDFResult.asp?Pname=182)
Stefan
sorry, I have not been following this one closely. Given that you can differentiate the chips, is there some workaround you can force in at bios time? How does one fix this?
ron
* Ronald G Minnich rminnich@lanl.gov [060305 20:54]:
The only information I could find: the W83627HF data sheet says:
Version | Device Rev --------+----------- G | 17 J | 3A UD-A | 41
(http://www.winbond.com/e-winbondhtm/partner/PDFResult.asp?Pname=182)
sorry, I have not been following this one closely. Given that you can differentiate the chips, is there some workaround you can force in at bios time? How does one fix this?
I have no idea whether it can be fixed at bios time. I think it worked after running setserial on the device at linux runtime, but it did not seem to need that running AMI bios, so it'd be nice to find some sort of bios workaround here. I asked Winbond for a revision guide, but I doubt I ever get an answer.
Stefan
On Sun, Mar 05, 2006 at 09:17:13PM +0100, Stefan Reinauer wrote:
I have no idea whether it can be fixed at bios time. I think it worked after running setserial on the device at linux runtime, but it did not seem to need that running AMI bios, so it'd be nice to find some sort of bios workaround here. I asked Winbond for a revision guide, but I doubt I ever get an answer.
What about chipset erratas? Sometimes they document really interesting hardware bugs.
//Peter
* Ronald G Minnich rminnich@lanl.gov [060305 20:54]:
Stefan Reinauer wrote:
The systems which are causing problems all have a
W83627HF revision ID = 0x17
The OK systems with linuxbios all have:
W83627HF revision ID = 0x41
Unfortunately there does not seem to be a revision guide on the winbond website. Any ideas anyone?
The only information I could find: the W83627HF data sheet says:
Version | Device Rev --------+----------- G | 17 J | 3A UD-A | 41
(http://www.winbond.com/e-winbondhtm/partner/PDFResult.asp?Pname=182)
sorry, I have not been following this one closely. Given that you can differentiate the chips, is there some workaround you can force in at bios time? How does one fix this?
As a workaround/solution it is possible to add
pci_write_config8(PCI_DEV(0, 0x04, 3), 0x4a, 0x50);
right after console_init() in auto.c.
This switches the 8111 serial irq logic from quiet mode to continuous mode:
CONTMD. Continuous mode selected versus quiet mode. 1=The serial IRQ logic is in continuous mode. 0=The serial IRQ logic is in quiet mode. In continuous mode, the start frame is initiated by the IC immediately following each stop frame. In quiet mode, start frames are initiated by external slave devices.
I wonder whether this is generally a good idea and should go to 8111 setup for all boards?
Winbond has been very helpful in this issue. They've been answering all my questions almost immediately.
Stefan
can you do that on amd8111_lpc.c?
YH
________________________________
From: linuxbios-bounces@linuxbios.org on behalf of Stefan Reinauer Sent: Tue 3/7/2006 5:17 AM To: Ronald G Minnich Cc: linuxbios@linuxbios.org Subject: Re: [LinuxBIOS] AMD64 serial setup
* Ronald G Minnich rminnich@lanl.gov [060305 20:54]:
Stefan Reinauer wrote:
The systems which are causing problems all have a
W83627HF revision ID = 0x17
The OK systems with linuxbios all have:
W83627HF revision ID = 0x41
Unfortunately there does not seem to be a revision guide on the winbond website. Any ideas anyone?
The only information I could find: the W83627HF data sheet says:
Version | Device Rev --------+----------- G | 17 J | 3A UD-A | 41
(http://www.winbond.com/e-winbondhtm/partner/PDFResult.asp?Pname=182)
sorry, I have not been following this one closely. Given that you can differentiate the chips, is there some workaround you can force in at bios time? How does one fix this?
As a workaround/solution it is possible to add
pci_write_config8(PCI_DEV(0, 0x04, 3), 0x4a, 0x50);
right after console_init() in auto.c.
This switches the 8111 serial irq logic from quiet mode to continuous mode:
CONTMD. Continuous mode selected versus quiet mode. 1=The serial IRQ logic is in continuous mode. 0=The serial IRQ logic is in quiet mode. In continuous mode, the start frame is initiated by the IC immediately following each stop frame. In quiet mode, start frames are initiated by external slave devices.
I wonder whether this is generally a good idea and should go to 8111 setup for all boards?
Winbond has been very helpful in this issue. They've been answering all my questions almost immediately.
Stefan
-- coresystems GmbH · Brahmsstr. 16 · D-79104 Freiburg i. Br. Tel.: +49 761 7668825 · Fax: +49 761 7664613 Email: info@coresystems.de · http://www.coresystems.de/
-- linuxbios mailing list linuxbios@linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios
* Lu, Yinghai yinghai.lu@amd.com [060307 20:02]:
can you do that on amd8111_lpc.c?
it belongs to amd8111_acpi.c, nor?
pci_write_config8(PCI_DEV(0, 0x04, 3), 0x4a, 0x50);
I propose the following generic patch. (attachment)
Stefan
Do you want this controlled by an option in the chip struct for that part? You're sure it does no harm to turn it on? it looks fine to me.
ron
* Ronald G Minnich rminnich@lanl.gov [060307 23:41]:
Do you want this controlled by an option in the chip struct for that part? You're sure it does no harm to turn it on? it looks fine to me.
It does not harm on any of the agami boards we've tried, no matter what Winbond revision was used. On the 0x17 parts the problem went away.
From what I can tell it looks quite safe generally.
How would such an option in the chip struct look like? Should we have the revision and vendor of the SuperIO chip stored in the device tree's superio entry and enable the workaround if we find an adequate device in the tree?
Yinghai, can we switch this on unconditionally or might that hurt some motherboards?
Stefan
let me try it tomorrow. Maybe this one solve the bug that 8132/8111 serial port can not get irq.
YH
On 3/7/06, Stefan Reinauer stepan@coresystems.de wrote:
Yinghai, can we switch this on unconditionally or might that hurt some motherboards?
OK to me.
YH
-
Lu, Yinghai -
Peter Stuge -
Ronald G Minnich -
Stefan Reinauer -
Stefan Reinauer -
yhlu