doscall1

Jonathan de Boyne Pollard wrote:
An i8042 keyboard and mouse, UART, parallel port, infrared port, MIDI
interface, environment controller, and 82078 floppy disc controller will
be connected to a separate "Super I/O" chip that is on the LPC bus. (If
you look at your mainboard you'll see it somewhere. It's usually a
WinBond or ITE chip. I'm interested in knowing which particular one you
have.)

Forgot to answer this, it is a Winbond, W83627EHG-A
Dave

For a typical single user, multi core system, what are the possible
'combinations' of these options to use/try?

Note that your situation is different to that of M. Yeo. You're getting
different symptoms. M. Yeo's problem may well be a bona fide interrupt
delivery problem. You say that you have a working system for a while,
indicating that all of the interrupt signals that are involved in disk
I/O, keyboard I/O, mouse I/O, and the system heartbeat are being handled
and not misrouted or lost.

Don't get hung up on OS2APIC.PSD just because it is the only tunable
that is easy for you to tune.

For starters, have you tried Mike Greene's procedure from 2004?

http://mgreene.org./wikka/Os2Smp

An i8042 keyboard and mouse, UART, parallel port, infrared port, MIDI
interface, environment controller, and 82078 floppy disc controller will
be connected to a separate "Super I/O" chip that is on the LPC bus. (If
you look at your mainboard you'll see it somewhere. It's usually a
WinBond or ITE chip. I'm interested in knowing which particular one you
have.)

Forgot to answer this, it is a Winbond, W83627EHG-A

I wanted to make sure that I had the datasheet for it. Indeed I have.
Now to check the support in the bus driver. ... (-:

Your mainboard manual is misleading you somewhat. These aren't actual
PCI slots on your motherboard. All of these are internal devices that
exist on the ICH chip itself, at fixed PCI addresses.

Well, it claims to have 3 PCI buses, so perhaps slots 1 and 2 are
physically tied to #F and #G. The point of the manual was that only in
slot 3 did you have to worry about sharing interrupts.

3 *root* PCI buses? Or just 3 PCI buses connected through two
PCI-to-PCI bridges? The difference is important. Three root PCI buses
is an unusual configuration, and a fairly unnecessary one for just three
expansion slots in total. Even three buses connected via bridges is
slightly overkill (unless AGP is involved).

The one PCI card I have installed is reported by pci.exe to use PCI
bus#2, IRQ#3, INT#A

Which rather puts the kibosh on what the manual says about interrupt
sharing, doesn't it? That's sharing with what is normally an ISA
interrupt for a UART.

Jonathan de Boyne Pollard wrote:
Well, it claims to have 3 PCI buses, so perhaps slots 1 and 2 are
physically tied to #F and #G. The point of the manual was that only in
slot 3 did you have to worry about sharing interrupts.

3 *root* PCI buses? Or just 3 PCI buses connected through two
PCI-to-PCI bridges? The difference is important. Three root PCI buses
is an unusual configuration, and a fairly unnecessary one for just three
expansion slots in total. Even three buses connected via bridges is
slightly overkill (unless AGP is involved).

I can't find where I read about the 3 PCI buses, I thought it was in the
manual but now can't find it.
PCI.exe reports all the onboard stuff on PCI BUS [0], the ATI AGP card
on BUS [1] and the network card plugged in as on BUS [2]
I've had problems with this network card previously in another computer
where it stopped working shortly after boot which was fixed by moving it
to another slot.


The one PCI card I have installed is reported by pci.exe to use PCI
bus#2, IRQ#3, INT#A

Which rather puts the kibosh on what the manual says about interrupt
sharing, doesn't it? That's sharing with what is normally an ISA
interrupt for a UART.

Only one UART here which is using IRQ#4

Dave

PCI.exe reports all the onboard stuff on PCI BUS [0], the ATI AGP card
on BUS [1] and the network card plugged in as on BUS [2]

That's three buses interconnected with PCI-to-PCI and PCI-to-AGP
bridges, and is far more the usual case.

The one PCI card I have installed is reported by pci.exe to use PCI
bus#2, IRQ#3, INT#A

Which rather puts the kibosh on what the manual says about interrupt
sharing, doesn't it? That's sharing with what is normally an ISA
interrupt for a UART.

Only one UART here which is using IRQ#4

A W83627EHG has two UARTs, A and B. Unless you have gone into the
firmware SETUP utility and explicitly disabled UART B, which instructs
the firmware to set the enable bit to zero in the device's configuration
space during POST, you'll have two UARTs.

I've disabled almost all of the devices in the Super I/O chips on my
test machines. But this was not their default firmware configuration.
It's also not the power-on default for the chip itself, before the
firmware gets around to programming it. The power-on default for the
W83627EHG is for both UARTs to have the enable bit set to one. The
power-on default IRQ selection for UART B is IRQ #3.

Jonathan de Boyne Pollard wrote:
Only one UART here which is using IRQ#4

A W83627EHG has two UARTs, A and B. Unless you have gone into the
firmware SETUP utility and explicitly disabled UART B, which instructs
the firmware to set the enable bit to zero in the device's configuration
space during POST, you'll have two UARTs.

The firmware SETUP utility only shows one serial port, which besides the
disabled setting, can be set to any of the usual settings for the first
4 ports. Hardware manager only shows one port as well and there is
physically only one port at the back of the computer.
I'd guess the firmware disables it during post.
Dave

The firmware SETUP utility only shows one serial port, which besides the
disabled setting, can be set to any of the usual settings for the first
4 ports. Hardware manager only shows one port as well and there is
physically only one port at the back of the computer.
I'd guess the firmware disables it during post.

Let's hope; because the lack of a connector in the motherboard's back
panel I/O area means nothing at all with respect to I/O resource usage.
It just means that the UART B I/O pins on the chip aren't wired to a
connector. The chip hasn't changed, and UART B is still there. It's
the actual UART within the Super I/O chip that requires the port and
interrupt resources.

It's a shame in a way that your motherboard vendor has only wired up
UART A on the W83627EHG. UART B has all of the natty infra-red stuff.
(-: But then the evidence is piling up that ASUS did this motherboard
on the cheap. (You read my other message, ne?)

I'm interested to read that both UARTs can operate at various rates up
to 921 kilobits per second. However, thinking about the way that this
is programmed (according to the datasheet) it seems non-trivial to
instrument an otherwise general-purpose ISA UART device driver to know
about the vendor-specific and chip-specific configuration space
registers that enable this.

On Mon, 15 Aug 2011 15:34:55 UTC, Jonathan de Boyne Pollard
wrote:

For a typical single user, multi core system, what are the possible
'combinations' of these options to use/try?

Note that your situation is different to that of M. Yeo. You're getting
different symptoms. M. Yeo's problem may well be a bona fide interrupt
delivery problem. You say that you have a working system for a while,
indicating that all of the interrupt signals that are involved in disk
I/O, keyboard I/O, mouse I/O, and the system heartbeat are being handled
and not misrouted or lost.

Don't get hung up on OS2APIC.PSD just because it is the only tunable
that is easy for you to tune.

For starters, have you tried Mike Greene's procedure from 2004?

http://mgreene.org./wikka/Os2Smp

I have read that note before...and I think the key difference is that I was NOT
running any of the SMP aware kernels before applying the latest un-official FP6.


I am currently going through the FP in details, understanding what files go
where to determine if I need to upgrade anything in particular.