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 i
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 w
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 m
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
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 t
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
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. Basic
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_p
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 s
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 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
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,
> it
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 (usu
15 matches
Mail list logo