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= dma= other means>
[...]
> With no options
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
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
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
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
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
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
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
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
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
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
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
Tim Waugh wrote:
>
> On Mon, Mar 19, 2001 at 12:16:26AM +, 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
Tim Waugh wrote:
On Mon, Mar 19, 2001 at 12:16:26AM +, 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
On Mon, Mar 19, 2001 at 12:16:26AM +, 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.
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
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
On Mon, Mar 19, 2001 at 12:16:26AM +, 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,
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
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
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
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
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
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).
On Thu, Mar 15, 2001 at 06:45:37PM +, 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,
>
On Thu, Mar 15, 2001 at 06:45:37PM +, 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
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
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
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
29 matches
Mail list logo
