I have a Asus K7V motherboard and a SB 128 PCI soundcard.
The motherboard is vt82c686a based.
The SB is a ES1371/AC97 card, seemingly identical to the onboard sound on
this type of motherboard.
However, the sound rarely works, and there are problems with the parport
too.
Sound does not work (usually, I have had it work, but I can't reproduce
it). The parport behaves strangely.
Here is dmesg output:
Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
SMSC Super-IO detection, now testing Ports 2F0, 370 ...
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: possible IRQ conflict!
0x378: ECP port cfgA=0x10 cfgB=0x00
0x378: ECP settings irq=<none or set by other means> dma=<none or set by
other means>
parport0: PC-style at 0x378 (0x778), irq 7, dma 3
[PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3
Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
SMSC Super-IO detection, now testing Ports 2F0, 370 ...
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: possible IRQ conflict!
0x378: ECP port cfgA=0x10 cfgB=0x00
0x378: ECP settings irq=<none or set by other means> dma=<none or set by
other means>
parport0: PC-style at 0x378 (0x778), irq 7, dma 3
[PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3
lp0: using parport0 (interrupt-driven).
I don't know why it prints it twice.
When printing errors are printed (buffer overrun or something like that,
it seems RedHat only logs these damn things to console).
Also if I try to disbale interrupt driven printing I get an error:
[root@dogfox log]# /usr/sbin/tunelp /dev/printers/0 -i 0
tunelp: ioctl: Invalid argument
/dev/printers/0 using IRQ 7
With sound, I get:
es1371: version v0.27 time 00:47:56 Mar 7 2001
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
PCI: Found IRQ 10 for device 00:0b.0
es1371: found es1371 rev 8 at io 0xa400 irq 10
es1371: features: joystick 0x0
ac97_codec: AC97 codec, id: 0x0000:0x0000 (Unknown)
Where the id field obviously should not be zero.
The IRQ, DMA, I/O ports etc. are all the same as they are in Windows, but
in Linux the sound doesn't work and the printer keeps hanging.
I also get spurios interrupts on 7 when the parport is not loaded.
I know other people are seeing similar effects with sinilar hardware, but
to my knowledge there have been no solutions put forward.
If anyone has any ideas I can try to diagnose this problem more clearly
or wants any specific information, please ask.
On Thu, Mar 15, 2001 at 06:45:37PM +0000, Will Newton wrote:
> I don't know why it prints it twice.
Looks like the module is getting loaded, then unloaded, then loaded
again. Perhaps because of module autocleaning?
> When printing errors are printed (buffer overrun or something like that,
> it seems RedHat only logs these damn things to console).
Put '*.debug -/var/log/debug' in /etc/syslog.conf and SIGHUP it.
With DMA and PIO debugging messages (especially timeout messages) are
normal and expected. They are still there because DMA and PIO isn't
really widely tested yet.
If you have a Via chipset that provides a parallel port via the PCI
bus, things like IRQ and DMA get used by default. I think this is
also a bug, and shouldn't be done unless 'irq=auto dma=auto' is
supplied to the module.
> Also if I try to disbale interrupt driven printing I get an error:
>
> [root@dogfox log]# /usr/sbin/tunelp /dev/printers/0 -i 0
> tunelp: ioctl: Invalid argument
> /dev/printers/0 using IRQ 7
Yeah, tunelp doesn't work with 2.4 kernels right now. It's on my list
of things to fix. Read Documentation/parport.txt to find out about
how to adjust things like that.
Basically, if you do:
modprobe -r lp parport_pc
modprobe parport_pc irq=none
then parport won't use interrupts.
> The IRQ, DMA, I/O ports etc. are all the same as they are in Windows, but
> in Linux the sound doesn't work and the printer keeps hanging.
For the 'printer hangs' problem, try the latest pre-patch in the
testing directory and let me know if that fixes it.
> I also get spurios interrupts on 7 when the parport is not loaded.
I'm not sure what you mean here. Can you be more specific?
Tim.
*/
On Fri, 16 Mar 2001, Tim Waugh wrote:
> > I don't know why it prints it twice.
>
> Looks like the module is getting loaded, then unloaded, then loaded
> again. Perhaps because of module autocleaning?
Could be, but the final lp0 line is only printed once:
lp0: using parport0 (interrupt-driven).
> > I also get spurios interrupts on 7 when the parport is not loaded.
>
> I'm not sure what you mean here. Can you be more specific?
messages.1:Mar 8 22:49:00 dogfox kernel: spurious 8259A interrupt: IRQ7.
On Fri, 16 Mar 2001, Will Newton wrote:
> On Fri, 16 Mar 2001, Tim Waugh wrote:
>
> > > I don't know why it prints it twice.
> >
> > Looks like the module is getting loaded, then unloaded, then loaded
> > again. Perhaps because of module autocleaning?
>
> Could be, but the final lp0 line is only printed once:
> lp0: using parport0 (interrupt-driven).
>
> > > I also get spurios interrupts on 7 when the parport is not loaded.
> >
> > I'm not sure what you mean here. Can you be more specific?
>
> messages.1:Mar 8 22:49:00 dogfox kernel: spurious 8259A interrupt: IRQ7.
I see these once in a while too in 2.4.x, and only when copying largish
files between boxes. NIC is IRQ-10, but the spurious interrupt is always
IRQ-7. I'm not using the printer port for anything on this box. It only
happens here when the network is going full bore for at least a few secs.
-Mike
On Sat, 17 Mar 2001, Mike Galbraith wrote:
> > messages.1:Mar 8 22:49:00 dogfox kernel: spurious 8259A interrupt: IRQ7.
>
> I see these once in a while too in 2.4.x, and only when copying largish
> files between boxes. NIC is IRQ-10, but the spurious interrupt is always
> IRQ-7. I'm not using the printer port for anything on this box. It only
> happens here when the network is going full bore for at least a few secs.
With the VIA chipset?
There definitely seems to be something wrong in the IRQ handling on this
board. e.g. when I insmod the sound driver it just sits there on IRQ 10,
getting no interrupts. Unfortunately I don't know enough about Linux
internals to really investigate this further.
On Sat, 17 Mar 2001, Will Newton wrote:
> On Sat, 17 Mar 2001, Mike Galbraith wrote:
>
> > > messages.1:Mar 8 22:49:00 dogfox kernel: spurious 8259A interrupt: IRQ7.
> >
> > I see these once in a while too in 2.4.x, and only when copying largish
> > files between boxes. NIC is IRQ-10, but the spurious interrupt is always
> > IRQ-7. I'm not using the printer port for anything on this box. It only
> > happens here when the network is going full bore for at least a few secs.
>
> With the VIA chipset?
Yes.
> There definitely seems to be something wrong in the IRQ handling on this
> board. e.g. when I insmod the sound driver it just sits there on IRQ 10,
> getting no interrupts. Unfortunately I don't know enough about Linux
> internals to really investigate this further.
No device I'm using has irq troubles.. at least nothing obvious. I've
no idea if the spurious irq is VIA chipset related or not.. only that
it's a fairly recent arrival. All devices work fine here.
-Mike
On Mon, Mar 19, 2001 at 12:16:26AM +0000, Will Newton wrote:
> In /etc/modules.conf I have:
>
> options parport_pc irq=none
>
> but dmesg says:
>
> parport0: PC-style at 0x378 (0x778), irq 7, dma 3
> [PCSPP,TRISTATE,COMPAT,ECP,DMA]
Jeff, this is a bug with the Via code in parport_pc.c. Basically, the
problem is that the code that detects the Via doesn't know what
parameters you passed. I know about the problem, but I don't know the
fix yet.
Tim.
*/
On Sat, 17 Mar 2001, Mike Galbraith wrote:
> No device I'm using has irq troubles.. at least nothing obvious. I've
> no idea if the spurious irq is VIA chipset related or not.. only that
> it's a fairly recent arrival. All devices work fine here.
In /etc/modules.conf I have:
options parport_pc irq=none
but dmesg says:
parport0: PC-style at 0x378 (0x778), irq 7, dma 3
[PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3
lp0: using parport0 (interrupt-driven).
How do I stop the parport module from using interrupts?
Tim Waugh wrote:
>
> On Mon, Mar 19, 2001 at 12:16:26AM +0000, Will Newton wrote:
>
> > In /etc/modules.conf I have:
> >
> > options parport_pc irq=none
> >
> > but dmesg says:
> >
> > parport0: PC-style at 0x378 (0x778), irq 7, dma 3
> > [PCSPP,TRISTATE,COMPAT,ECP,DMA]
>
> Jeff, this is a bug with the Via code in parport_pc.c. Basically, the
> problem is that the code that detects the Via doesn't know what
> parameters you passed. I know about the problem, but I don't know the
> fix yet.
Will,
What are your parallel port settings in BIOS?
Do you have Plug-n-Play OS enabled in BIOS?
The current Via-specific parport_pc.c code forces on the best possible
parallel port modes the chip can handle. In retrospect, what it should
be doing is reading the configuration BIOS has set up, and not touching
it.
I am not sure that I agree, however, that an "irq=none" on the kernel
cmd line should affect the operation of the Via code. I would much
rather fix the Via code as I suggest above.
Time to look for and drag out the old Via laptop... Oh well, I needed
to debug the Via audio code some more anyway. :)
Jeff
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
On Tue, Mar 20, 2001 at 11:21:10PM -0500, Jeff Garzik wrote:
> The current Via-specific parport_pc.c code forces on the best possible
> parallel port modes the chip can handle. In retrospect, what it should
> be doing is reading the configuration BIOS has set up, and not touching
> it.
Yes, I think you are right.
> I am not sure that I agree, however, that an "irq=none" on the kernel
> cmd line should affect the operation of the Via code. I would much
> rather fix the Via code as I suggest above.
irq=none should definitely be honoured, or else the user has to reboot
in order to debug problems with printing. The user's io=, irq= and
dma= settings should always be honoured. IMHO.
When irq=auto, the BIOS settings should be used.
Case in point: until very recently there was a bad problem in the
irq-driven printing path. But only people with Via chipsets were
reporting it, and it didn't go away with 'irq=none' (which parport.txt
says to do in order to trouble-shoot). It makes Via chipsets the
exception, and it's confusing IMHO (it confused me, anyhow).
Tim.
*/
On Tue, 20 Mar 2001, Jeff Garzik wrote:
> What are your parallel port settings in BIOS?
AFAICR there is only an option for setting the I/O port. I'll check
for anything else later (the machine in question is busy right now :).
> Do you have Plug-n-Play OS enabled in BIOS?
Yes.
> I am not sure that I agree, however, that an "irq=none" on the kernel
> cmd line should affect the operation of the Via code. I would much
> rather fix the Via code as I suggest above.
irq=none seems pretty unequivocal to me, I'm not sure how easy it is to
explain to a user that irq=none doesn't do what it says.
> Time to look for and drag out the old Via laptop... Oh well, I needed
> to debug the Via audio code some more anyway. :)
I'm getting all sorts of troubles with a SB PCI 128 card (AC97 also).
If it works at all, it seems to eventually stop getting interrupts until
the module is removed and reloaded.
Which is why I suspect there may be a larger problem with the VIA
motherboards.
Will Newton wrote:
> On Tue, 20 Mar 2001, Jeff Garzik wrote:
> > I am not sure that I agree, however, that an "irq=none" on the kernel
> > cmd line should affect the operation of the Via code. I would much
> > rather fix the Via code as I suggest above.
>
> irq=none seems pretty unequivocal to me, I'm not sure how easy it is to
> explain to a user that irq=none doesn't do what it says.
For this specific case, Via motherboards, we know exactly whether or not
an interrupt was assigned to the parallel port, and whether or not the
parallel port is in an interrupt-driven mode. Attempting to pretend
that the parallel port is not in an interrupt driven mode by passing
irq=none is folly.
If irq=none is passed to tell the Via code to -force- the parallel port
into a non-irq-driven mode is one thing. If irq=none is passed to hide
a problem with spurious interrupts, we need to fix that problem, not
hide it.
So as I see it, I should fix the Via code to read (only!) the parallel
port configuration from BIOS, and set up the parallel port that way. I
still am not convinced that irq=<anything> should affect the Via code at
all. Maybe I can print out a message "irq=foo ignored".
Optionally, I could handle irq=none by force-disabling the parallel
port's interrupt driven modes, if they are active. I don't want to do
this, but may be forced to by circumstance...
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
On Wed, Mar 21, 2001 at 09:19:35AM -0500, Jeff Garzik wrote:
> Attempting to pretend that the parallel port is not in an interrupt
> driven mode by passing irq=none is folly.
No, that's not what it's for. It means 'for Christ sake don't use
interrupts, I know what I'm doing'.
> If irq=none is passed to tell the Via code to -force- the parallel
> port into a non-irq-driven mode is one thing. If irq=none is passed
> to hide a problem with spurious interrupts, we need to fix that
> problem, not hide it.
irq=none is passed in order to diagnose whether a problem happens on
only the interrupt-driven path or not. Read the trouble-shooting
section parport.txt. Understand that there are lots of printing code
paths nowadays (polling, interrupt-driven, PIO, DMA, etc).
> I still am not convinced that irq=<anything> should affect the Via
> code at all. Maybe I can print out a message "irq=foo ignored".
Jeff, it needs to. If you want to make irq=auto the default
(currently it's 'probe only'), then that is an entirely different
thing.
When the user tells you not to use interrupts, you'd better not.
> Optionally, I could handle irq=none by force-disabling the parallel
> port's interrupt driven modes, if they are active.
What the hell for? Just don't use the interrupts.
Tim.
*/
Tim Waugh wrote:
>
> On Wed, Mar 21, 2001 at 09:19:35AM -0500, Jeff Garzik wrote:
>
> > Attempting to pretend that the parallel port is not in an interrupt
> > driven mode by passing irq=none is folly.
>
> No, that's not what it's for. It means 'for Christ sake don't use
> interrupts, I know what I'm doing'.
>
> > If irq=none is passed to tell the Via code to -force- the parallel
> > port into a non-irq-driven mode is one thing. If irq=none is passed
> > to hide a problem with spurious interrupts, we need to fix that
> > problem, not hide it.
>
> irq=none is passed in order to diagnose whether a problem happens on
> only the interrupt-driven path or not. Read the trouble-shooting
> section parport.txt. Understand that there are lots of printing code
> paths nowadays (polling, interrupt-driven, PIO, DMA, etc).
>
> > I still am not convinced that irq=<anything> should affect the Via
> > code at all. Maybe I can print out a message "irq=foo ignored".
>
> Jeff, it needs to. If you want to make irq=auto the default
> (currently it's 'probe only'), then that is an entirely different
> thing.
>
> When the user tells you not to use interrupts, you'd better not.
>
> > Optionally, I could handle irq=none by force-disabling the parallel
> > port's interrupt driven modes, if they are active.
>
> What the hell for? Just don't use the interrupts.
>
> Tim.
> */
>
Hi, Tim
What is the default anyway? My BIOS is 0x378, 7, 3 and the driver
reports this:
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: possible IRQ conflict! [Don't know why it always reports
this]
0x378: ECP port cfgA=0x10 cfgB=0x00
0x378: ECP settings irq=<none or set by other means> dma=<none or set by
other means>
parport0: PC-style at 0x378 (0x778), irq 7, using FIFO
[PCSPP,TRISTATE,COMPAT,ECP]
parport0: cpp_daisy: aa5500ff(98)
parport0: assign_addrs: aa5500ff(98)
parport0: cpp_daisy: aa5500ff(98)
parport0: assign_addrs: aa5500ff(98)
With no options in modules.conf, lp0 uses polling; with irq=auto
dma=auto
it uses interrupt-driven but no dma?.
--
===============
-- Tim
On Wed, Mar 21, 2001 at 07:41:15PM -0700, TimO wrote:
> 0x378: possible IRQ conflict! [Don't know why it always reports
> this]
I've been sending Linus a patch to remove this bogus warning for the
last few pre-patches.
> 0x378: ECP settings irq=<none or set by other means> dma=<none or set by
> other means>
[...]
> With no options in modules.conf, lp0 uses polling; with irq=auto
> dma=auto
> it uses interrupt-driven but no dma?.
It does its best to figure out the IRQ, even though the chipset won't
tell us. For the DMA channel, it doesn't even try to guess.
Tim.
*/