Re: aic7xxx and 2.4.3 failures - fix, it is interrupt routing
G*rard Roudier insightfully opined..
> Looks like an IRQ problem to me.
> I mean the kernel wants to change IRQ routing and just do the wrong job.
Give the man a prize!
After failing to work with 2.4.0, 2.4.1, 2.4.3, and 2.4.3-ac3 I
enabled X86_UP_IOAPIC to stir up the interrupt code and it works.
I'll keep one of these servers set aside for testing and see if I can't
figure out a little more specifically what the problem is, but IOAPIC
is fine.
Thanks for the help all!
--
Jim Studt, President
The Federated Software Group, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx and 2.4.3 failures
> > A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently
> > after emitting the scsi0 and scsi1 adapter summaries, maybe it is
> > going through the same gyrations silently.)
> >
>
Alan Cox directs...
> Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that works.
> This is important both because it might solve your problem for now but also
> because if the old driver works we can be fairly sure the bug is in the
> new adaptec driver and not elsewhere and triggered on it
Using AIC7XXX_OLD does not work either. Different output
SCSI subsystem driver Revision: 1.00
PCI: Assigned IRQ 11 for device 00:0c.0
PCI: The same IRQ used for device 00:0c.1
PCI: Found IRQ 11 for device 00:0c.1
PCI: The same IRQ used for device 00:0c.0
(scsi0) found at PCI 0/12/0
(scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 392 instructions downloaded
(scsi1) found at PCI 0/12/1
(scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs
(scsi1) Downloading sequencer code... 392 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 Inquiry
00 00 00 ff 00
SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 channel 0 reset (pid 0) timed out - trying harder
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 channel 0 reset (pid 0) timed out - trying harder
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
...
Since we are looking elsewhere now... I have tried PCI access mode
BIOS and Direct with no improvement.
There is an unrecognized PCI bridge resource in the boot messages...
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU serial number disabled.
CPU: Intel Pentium III (Coppermine) stepping 06
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
Unknown bridge resource 1: assuming transparent
Unknown bridge resource 2: assuming transparent
Unknown bridge resource 0: assuming transparent
Unknown bridge resource 1: assuming transparent
Unknown bridge resource 2: assuming transparent
PCI: Discovered primary peer bus ff [IRQ]
PCI: Using IRQ router PIIX [8086/7110] at 00:12.0
# lspci
00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge
00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge
00:0c.0 SCSI storage controller: Adaptec 7896
00:0c.1 SCSI storage controller: Adaptec 7896
00:0e.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
00:12.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:12.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:12.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:12.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:14.0 VGA compatible controller: Cirrus Logic GD 5480 (rev 23)
01:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 06)
I will go back and try 2.4.0 and 2.4.3-ac3 and see where that gets me.
--
Jim Studt, President
The Federated Software Group, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
aic7xxx and 2.4.3 failures
I've got a trio of identical PIII machines all failing with aic7xxx under
2.4.3. I've tried both aic7xxx 6.1.9 and 6.1.10 in addition to the one
in 2.4.3 (6.1.5?). These machines work fine under 2.2.18pre21.
I'm looking for any ideas or suggestions on how to fix this.
(Ok, honestly I'm hoping someone will say `you fool, read this message',
but I don't have high hopes for that.)
A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently
after emitting the scsi0 and scsi1 adapter summaries, maybe it is
going through the same gyrations silently.)
SCSI subsystem driver Revision: 1.00
request_module[scsi_hostadapter]: Root fs not mounted
request_module[scsi_hostadapter]: Root fs not mounted
PCI: Assigned IRQ 11 for device 00:0c.0
PCI: The same IRQ used for device 00:0c.1
PCI: Found IRQ 11 for device 00:0c.1
PCI: The same IRQ used for device 00:0c.0
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.9
aic7896/97: Wide Channel A, SCSI Id=7, 32/255 SCBs
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.9
aic7896/97: Wide Channel B, SCSI Id=7, 32/255 SCBs
scsi0:0:0:0: Attempting to queue an ABORT message
scsi0:0:0:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:0:0: Attempting to queue an ABORT message
scsi0:0:0:0: Device is active, asserting ATN
Recovery code sleeping
Recovery code awake
Timer Expired
aic7xxx_abort returns 8195
scsi0:0:0:0: Attempting to queue a TARGET RESET message
aic7xxx_dev_reset returns 8195
Recovery SCB completes
scsi0:0:0:0: Attempting to queue an ABORT message
ahc_intr: HOST_MSG_LOOP bad phase 0x0
scsi0:0:0:0: Cmd aborted from QINFIFO
aic7xxx_abort returns 8194
scsi: device set offline - not ready or command retry failed after bus reset: host 0
channel 0 id 0 lun 0
It repeats this for each ID for which a device exists. There actually
is a unit 0 and 1 on this bus. The error stream is slightly different
for unused IDs...
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:2:0: Attempting to queue a TARGET RESET message
scsi0:0:2:0: Is not an active device
aic7xxx_dev_reset returns 8194
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi: device set offline - not ready or command retry failed after bus reset: host 0
channel 0 id 2 lun 0
After failing on all 32 potential IDs at something like 47 seconds per
ID the boot proceeds and fails to mount the root partition which is on
these disks.
Other potentially useful information gathered from 2.2.18pre21...
/proc/pci says
00:0c.1 SCSI storage controller: Adaptec 7896
Subsystem: Adaptec: Unknown device 0053
Flags: bus master, medium devsel, latency 64, IRQ 11
BIST result: 00
I/O ports at 2800
Memory at f4102000 (64-bit, non-prefetchable)
Capabilities: [dc] Power Management version 1
dotdot-new:~# cat /proc/scsi/aic7xxx/0
Adaptec AIC7xxx driver version: 5.1.31/3.2.4
Compile Options:
TCQ Enabled By Default : Disabled
AIC7XXX_PROC_STATS : Enabled
AIC7XXX_RESET_DELAY: 15
Adapter Configuration:
SCSI Adapter: Adaptec AIC-7896/7 Ultra2 SCSI host adapter
Ultra-2 LVD/SE Wide Controller Channel A at PCI 0/12/0
PCI MMAPed I/O Base: 0xf4101000
Adapter SEEPROM Config: SEEPROM found and used.
Adaptec SCSI BIOS: Enabled
IRQ: 11
SCBs: Active 0, Max Active 2,
Allocated 15, HW 32, Page 255
Interrupts: 3366
BIOS Control Word: 0x18a6
Adapter Control Word: 0x1c5e
Extended Translation: Enabled
Disconnect Enable Flags: 0x
Ultra Enable Flags: 0x
Tag Queue Enable Flags: 0x
Ordered Queue Tag Flags: 0x
Default Tag Queue Depth: 8
Tagged Queue By Device array for aic7xxx host instance 0:
{255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255}
Actual queue depth per device for aic7xxx host instance 0:
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}
--
Jim Studt, President
The Federated Software Group, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
aic7xxx and 2.4.3 failures
I've got a trio of identical PIII machines all failing with aic7xxx under
2.4.3. I've tried both aic7xxx 6.1.9 and 6.1.10 in addition to the one
in 2.4.3 (6.1.5?). These machines work fine under 2.2.18pre21.
I'm looking for any ideas or suggestions on how to fix this.
(Ok, honestly I'm hoping someone will say `you fool, read this message',
but I don't have high hopes for that.)
A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently
after emitting the scsi0 and scsi1 adapter summaries, maybe it is
going through the same gyrations silently.)
SCSI subsystem driver Revision: 1.00
request_module[scsi_hostadapter]: Root fs not mounted
request_module[scsi_hostadapter]: Root fs not mounted
PCI: Assigned IRQ 11 for device 00:0c.0
PCI: The same IRQ used for device 00:0c.1
PCI: Found IRQ 11 for device 00:0c.1
PCI: The same IRQ used for device 00:0c.0
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.9
Adaptec aic7896/97 Ultra2 SCSI adapter
aic7896/97: Wide Channel A, SCSI Id=7, 32/255 SCBs
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.9
Adaptec aic7896/97 Ultra2 SCSI adapter
aic7896/97: Wide Channel B, SCSI Id=7, 32/255 SCBs
scsi0:0:0:0: Attempting to queue an ABORT message
scsi0:0:0:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:0:0: Attempting to queue an ABORT message
scsi0:0:0:0: Device is active, asserting ATN
Recovery code sleeping
Recovery code awake
Timer Expired
aic7xxx_abort returns 8195
scsi0:0:0:0: Attempting to queue a TARGET RESET message
aic7xxx_dev_reset returns 8195
Recovery SCB completes
scsi0:0:0:0: Attempting to queue an ABORT message
ahc_intr: HOST_MSG_LOOP bad phase 0x0
scsi0:0:0:0: Cmd aborted from QINFIFO
aic7xxx_abort returns 8194
scsi: device set offline - not ready or command retry failed after bus reset: host 0
channel 0 id 0 lun 0
It repeats this for each ID for which a device exists. There actually
is a unit 0 and 1 on this bus. The error stream is slightly different
for unused IDs...
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:2:0: Attempting to queue a TARGET RESET message
scsi0:0:2:0: Is not an active device
aic7xxx_dev_reset returns 8194
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi: device set offline - not ready or command retry failed after bus reset: host 0
channel 0 id 2 lun 0
After failing on all 32 potential IDs at something like 47 seconds per
ID the boot proceeds and fails to mount the root partition which is on
these disks.
Other potentially useful information gathered from 2.2.18pre21...
/proc/pci says
00:0c.1 SCSI storage controller: Adaptec 7896
Subsystem: Adaptec: Unknown device 0053
Flags: bus master, medium devsel, latency 64, IRQ 11
BIST result: 00
I/O ports at 2800
Memory at f4102000 (64-bit, non-prefetchable)
Capabilities: [dc] Power Management version 1
dotdot-new:~# cat /proc/scsi/aic7xxx/0
Adaptec AIC7xxx driver version: 5.1.31/3.2.4
Compile Options:
TCQ Enabled By Default : Disabled
AIC7XXX_PROC_STATS : Enabled
AIC7XXX_RESET_DELAY: 15
Adapter Configuration:
SCSI Adapter: Adaptec AIC-7896/7 Ultra2 SCSI host adapter
Ultra-2 LVD/SE Wide Controller Channel A at PCI 0/12/0
PCI MMAPed I/O Base: 0xf4101000
Adapter SEEPROM Config: SEEPROM found and used.
Adaptec SCSI BIOS: Enabled
IRQ: 11
SCBs: Active 0, Max Active 2,
Allocated 15, HW 32, Page 255
Interrupts: 3366
BIOS Control Word: 0x18a6
Adapter Control Word: 0x1c5e
Extended Translation: Enabled
Disconnect Enable Flags: 0x
Ultra Enable Flags: 0x
Tag Queue Enable Flags: 0x
Ordered Queue Tag Flags: 0x
Default Tag Queue Depth: 8
Tagged Queue By Device array for aic7xxx host instance 0:
{255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255}
Actual queue depth per device for aic7xxx host instance 0:
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}
--
Jim Studt, President
The Federated Software Group, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx and 2.4.3 failures
A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently after emitting the scsi0 and scsi1 adapter summaries, maybe it is going through the same gyrations silently.) Alan Cox directs... Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that works. This is important both because it might solve your problem for now but also because if the old driver works we can be fairly sure the bug is in the new adaptec driver and not elsewhere and triggered on it Using AIC7XXX_OLD does not work either. Different output SCSI subsystem driver Revision: 1.00 PCI: Assigned IRQ 11 for device 00:0c.0 PCI: The same IRQ used for device 00:0c.1 PCI: Found IRQ 11 for device 00:0c.1 PCI: The same IRQ used for device 00:0c.0 (scsi0) Adaptec AIC-7896/7 Ultra2 SCSI host adapter found at PCI 0/12/0 (scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs (scsi0) Downloading sequencer code... 392 instructions downloaded (scsi1) Adaptec AIC-7896/7 Ultra2 SCSI host adapter found at PCI 0/12/1 (scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs (scsi1) Downloading sequencer code... 392 instructions downloaded scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 Adaptec AIC-7896/7 Ultra2 SCSI host adapter scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 Adaptec AIC-7896/7 Ultra2 SCSI host adapter scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00 SCSI host 0 abort (pid 0) timed out - resetting SCSI bus is being reset for host 0 channel 0. SCSI host 0 channel 0 reset (pid 0) timed out - trying harder SCSI bus is being reset for host 0 channel 0. SCSI host 0 abort (pid 0) timed out - resetting SCSI bus is being reset for host 0 channel 0. SCSI host 0 channel 0 reset (pid 0) timed out - trying harder SCSI bus is being reset for host 0 channel 0. SCSI host 0 abort (pid 0) timed out - resetting SCSI bus is being reset for host 0 channel 0. ... Since we are looking elsewhere now... I have tried PCI access mode BIOS and Direct with no improvement. There is an unrecognized PCI bridge resource in the boot messages... CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU serial number disabled. CPU: Intel Pentium III (Coppermine) stepping 06 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Discovered primary peer bus ff [IRQ] PCI: Using IRQ router PIIX [8086/7110] at 00:12.0 # lspci 00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge 00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge 00:0c.0 SCSI storage controller: Adaptec 7896 00:0c.1 SCSI storage controller: Adaptec 7896 00:0e.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) 00:12.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:12.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:12.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:12.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:14.0 VGA compatible controller: Cirrus Logic GD 5480 (rev 23) 01:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 06) I will go back and try 2.4.0 and 2.4.3-ac3 and see where that gets me. -- Jim Studt, President The Federated Software Group, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx and 2.4.3 failures - fix, it is interrupt routing
G*rard Roudier insightfully opined.. Looks like an IRQ problem to me. I mean the kernel wants to change IRQ routing and just do the wrong job. Give the man a prize! After failing to work with 2.4.0, 2.4.1, 2.4.3, and 2.4.3-ac3 I enabled X86_UP_IOAPIC to stir up the interrupt code and it works. I'll keep one of these servers set aside for testing and see if I can't figure out a little more specifically what the problem is, but IOAPIC is fine. Thanks for the help all! -- Jim Studt, President The Federated Software Group, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sis5513 fatal udma problems
The sis5513 has for quite a while had fatal problems with udma on some
machines. (At least the thelinuxstore PIAs with the P6SET-ML
motherboard, I have heard other people with the same problem).
The sis5513 driver deliberatly overrides the CONFIG_IDEDMA_AUTO and
the BIOS settings that might disable UDMA and forces UDMA which works
for a while then fails, attempts to fallback to a non-DMA mode and
fails that as well.
The logs end up with something along the lines of...
hdc: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: status timeout: status=0xd8 { Busy }
hdc: DMA disabled
hdc: drive not ready for command
ide1: reset: success
hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: drive not ready for command
... but it nevers succeeds in the reset. The drive never becomes ready.
I will make a patch, but I am uncertain what the `right' policy should
be. I am inclined to first and foremost respect the CONFIG_IDEDMA_AUTO
flag, then to take the fastest mode which is both capable and enabled in
the bios.
Thoughts? Please? :-)
--
Jim Studt, President
The Federated Software Group, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
sis5513 fatal udma problems
The sis5513 has for quite a while had fatal problems with udma on some
machines. (At least the thelinuxstore PIAs with the P6SET-ML
motherboard, I have heard other people with the same problem).
The sis5513 driver deliberatly overrides the CONFIG_IDEDMA_AUTO and
the BIOS settings that might disable UDMA and forces UDMA which works
for a while then fails, attempts to fallback to a non-DMA mode and
fails that as well.
The logs end up with something along the lines of...
hdc: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: status timeout: status=0xd8 { Busy }
hdc: DMA disabled
hdc: drive not ready for command
ide1: reset: success
hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: drive not ready for command
... but it nevers succeeds in the reset. The drive never becomes ready.
I will make a patch, but I am uncertain what the `right' policy should
be. I am inclined to first and foremost respect the CONFIG_IDEDMA_AUTO
flag, then to take the fastest mode which is both capable and enabled in
the bios.
Thoughts? Please? :-)
--
Jim Studt, President
The Federated Software Group, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i810 audio fixes for 2.4.0-test13-pre5
ER_CONTROL, dacp);
}
rate = (rate * 48000) / clocking;
dmabuf->rate = rate;
@@ -507,21 +525,19 @@
extern __inline__ unsigned i810_get_dma_addr(struct i810_state *state)
{
struct dmabuf *dmabuf = >dmabuf;
- u32 offset;
+ unsigned int civ, offset;
struct i810_channel *c = dmabuf->channel;
if (!dmabuf->enable)
return 0;
- offset = inb(state->card->iobase+c->port+OFF_CIV);
- offset++;
- offset&=31;
- /* Offset has to compensate for the fact we finished the segment
- on the IRQ so we are at next_segment,0 */
-// printk("BANK%d ", offset);
- offset *= (dmabuf->dmasize/SG_LEN);
-// printk("DMASZ=%d", dmabuf->dmasize);
-// offset += 1024-(4*inw(state->card->iobase+c->port+OFF_PICB));
-// printk("OFF%d ", offset);
+ do {
+ civ = inb(state->card->iobase+c->port+OFF_CIV);
+ offset = (civ + 1) * (dmabuf->dmasize/SG_LEN) -
+ 2 * inw(state->card->iobase+c->port+OFF_PICB);
+ /* CIV changed before we read PICB (very seldom) ?
+* then PICB was rubbish, so try again */
+ } while (civ != inb(state->card->iobase+c->port+OFF_CIV));
+
return offset;
}
@@ -730,10 +746,13 @@
sg->control|=CON_IOC;
sg++;
}
+
spin_lock_irqsave(>card->lock, flags);
+ outb(2, state->card->iobase+dmabuf->channel->port + OFF_CR); /* reset DMA
+machine */
outl(virt_to_bus(>channel->sg[0]),
state->card->iobase+dmabuf->channel->port+OFF_BDBAR);
- outb(16, state->card->iobase+dmabuf->channel->port+OFF_LVI);
- outb(0, state->card->iobase+dmabuf->channel->port+OFF_CIV);
+ outb(16, state->card->iobase+dmabuf->channel->port + OFF_LVI);
+ outb(0, state->card->iobase+dmabuf->channel->port + OFF_CIV);
+
if (rec) {
i810_rec_setup(state);
} else {
@@ -753,14 +772,10 @@
return 0;
}
-
-/* we are doing quantum mechanics here, the buffer can only be empty, half or full
filled i.e.
- ||| or ||| or
|||
- but we almost always get this
- |xx--|| or ||x---|
- so we have to clear the tail space to "silence"
- |xx00|| or ||xx00|
-*/
+/*
+ * Clear the rest of the last i810 dma buffer, normally there is no rest
+ * because the OSS fragment size is the same as the size of this buffer.
+ */
static void i810_clear_tail(struct i810_state *state)
{
struct dmabuf *dmabuf = >dmabuf;
@@ -773,14 +788,8 @@
swptr = dmabuf->swptr;
spin_unlock_irqrestore(>card->lock, flags);
- if (swptr == 0 || swptr == dmabuf->dmasize / 2 || swptr == dmabuf->dmasize)
- return;
-
- if (swptr < dmabuf->dmasize/2)
- len = dmabuf->dmasize/2 - swptr;
- else
- len = dmabuf->dmasize - swptr;
-
+ len = swptr % (dmabuf->dmasize/SG_LEN);
+
memset(dmabuf->rawbuf + swptr, silence, len);
spin_lock_irqsave(>card->lock, flags);
@@ -1908,6 +1917,7 @@
MODULE_DESCRIPTION("Intel 810 audio support");
MODULE_PARM(ftsodell, "i");
MODULE_PARM(clocking, "i");
+MODULE_PARM(cycle_power,"i");
#define I810_MODULE_NAME "intel810_audio"
--
Jim Studt, President
The Federated Software Group, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i810 audio fixes for 2.4.0-test13-pre5
* 48000) / clocking;
dmabuf-rate = rate;
@@ -507,21 +525,19 @@
extern __inline__ unsigned i810_get_dma_addr(struct i810_state *state)
{
struct dmabuf *dmabuf = state-dmabuf;
- u32 offset;
+ unsigned int civ, offset;
struct i810_channel *c = dmabuf-channel;
if (!dmabuf-enable)
return 0;
- offset = inb(state-card-iobase+c-port+OFF_CIV);
- offset++;
- offset=31;
- /* Offset has to compensate for the fact we finished the segment
- on the IRQ so we are at next_segment,0 */
-// printk("BANK%d ", offset);
- offset *= (dmabuf-dmasize/SG_LEN);
-// printk("DMASZ=%d", dmabuf-dmasize);
-// offset += 1024-(4*inw(state-card-iobase+c-port+OFF_PICB));
-// printk("OFF%d ", offset);
+ do {
+ civ = inb(state-card-iobase+c-port+OFF_CIV);
+ offset = (civ + 1) * (dmabuf-dmasize/SG_LEN) -
+ 2 * inw(state-card-iobase+c-port+OFF_PICB);
+ /* CIV changed before we read PICB (very seldom) ?
+* then PICB was rubbish, so try again */
+ } while (civ != inb(state-card-iobase+c-port+OFF_CIV));
+
return offset;
}
@@ -730,10 +746,13 @@
sg-control|=CON_IOC;
sg++;
}
+
spin_lock_irqsave(state-card-lock, flags);
+ outb(2, state-card-iobase+dmabuf-channel-port + OFF_CR); /* reset DMA
+machine */
outl(virt_to_bus(dmabuf-channel-sg[0]),
state-card-iobase+dmabuf-channel-port+OFF_BDBAR);
- outb(16, state-card-iobase+dmabuf-channel-port+OFF_LVI);
- outb(0, state-card-iobase+dmabuf-channel-port+OFF_CIV);
+ outb(16, state-card-iobase+dmabuf-channel-port + OFF_LVI);
+ outb(0, state-card-iobase+dmabuf-channel-port + OFF_CIV);
+
if (rec) {
i810_rec_setup(state);
} else {
@@ -753,14 +772,10 @@
return 0;
}
-
-/* we are doing quantum mechanics here, the buffer can only be empty, half or full
filled i.e.
- ||| or ||| or
|||
- but we almost always get this
- |xx--|| or ||x---|
- so we have to clear the tail space to "silence"
- |xx00|| or ||xx00|
-*/
+/*
+ * Clear the rest of the last i810 dma buffer, normally there is no rest
+ * because the OSS fragment size is the same as the size of this buffer.
+ */
static void i810_clear_tail(struct i810_state *state)
{
struct dmabuf *dmabuf = state-dmabuf;
@@ -773,14 +788,8 @@
swptr = dmabuf-swptr;
spin_unlock_irqrestore(state-card-lock, flags);
- if (swptr == 0 || swptr == dmabuf-dmasize / 2 || swptr == dmabuf-dmasize)
- return;
-
- if (swptr dmabuf-dmasize/2)
- len = dmabuf-dmasize/2 - swptr;
- else
- len = dmabuf-dmasize - swptr;
-
+ len = swptr % (dmabuf-dmasize/SG_LEN);
+
memset(dmabuf-rawbuf + swptr, silence, len);
spin_lock_irqsave(state-card-lock, flags);
@@ -1908,6 +1917,7 @@
MODULE_DESCRIPTION("Intel 810 audio support");
MODULE_PARM(ftsodell, "i");
MODULE_PARM(clocking, "i");
+MODULE_PARM(cycle_power,"i");
#define I810_MODULE_NAME "intel810_audio"
--
Jim Studt, President
The Federated Software Group, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tulip oops for some eeproms in 2.4.0-test10
(please cc me, I follow the list on a web page)
The printk()s which enumerate media types during boot will oops
for some eeproms. They use the media type as an index into an
array of strings without doing any bounds checking.
This patch fixes it. The leaf->type is the killer for my card, I
have a descriptor where that is 128, the block_name table only has 6
entries. (The card is a Lite-On Communications Inc LNE100TX, based
on a Kingston card. Freebie from SWBell on DSL install.)
The "leaf->media & 0x0f" range check is sufficient, but not as nice
as the explicit size check on leaf->type. There are 16 entires in
medianame, but that is not known to this file during compilation.
(leaf->media could be as high as 0x3f, so some sort of check is called for.
If anyone named linus asks me to make a patch that uses the real size
of medianame I will. :-)
--- linux/drivers/net/tulip/eeprom.c.orig Wed Nov 1 14:32:18 2000
+++ linux/drivers/net/tulip/eeprom.cWed Nov 1 14:14:02 2000
@@ -236,8 +236,9 @@
}
printk(KERN_INFO "%s: Index #%d - Media %s (#%d) described "
"by a %s (%d) block.\n",
- dev->name, i, medianame[leaf->media], leaf->media,
- block_name[leaf->type], leaf->type);
+ dev->name, i, medianame[leaf->media & 0x0f],
+leaf->media,
+ ((leaf->type <
+sizeof(block_name)/sizeof(block_name[0])) ? block_name[leaf->type] : "unknown"),
+ leaf->type);
}
if (new_advertise)
tp->to_advertise = new_advertise;
--
Jim Studt, President
The Federated Software Group, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tulip oops for some eeproms in 2.4.0-test10
(please cc me, I follow the list on a web page)
The printk()s which enumerate media types during boot will oops
for some eeproms. They use the media type as an index into an
array of strings without doing any bounds checking.
This patch fixes it. The leaf-type is the killer for my card, I
have a descriptor where that is 128, the block_name table only has 6
entries. (The card is a Lite-On Communications Inc LNE100TX, based
on a Kingston card. Freebie from SWBell on DSL install.)
The "leaf-media 0x0f" range check is sufficient, but not as nice
as the explicit size check on leaf-type. There are 16 entires in
medianame, but that is not known to this file during compilation.
(leaf-media could be as high as 0x3f, so some sort of check is called for.
If anyone named linus asks me to make a patch that uses the real size
of medianame I will. :-)
--- linux/drivers/net/tulip/eeprom.c.orig Wed Nov 1 14:32:18 2000
+++ linux/drivers/net/tulip/eeprom.cWed Nov 1 14:14:02 2000
@@ -236,8 +236,9 @@
}
printk(KERN_INFO "%s: Index #%d - Media %s (#%d) described "
"by a %s (%d) block.\n",
- dev-name, i, medianame[leaf-media], leaf-media,
- block_name[leaf-type], leaf-type);
+ dev-name, i, medianame[leaf-media 0x0f],
+leaf-media,
+ ((leaf-type
+sizeof(block_name)/sizeof(block_name[0])) ? block_name[leaf-type] : "unknown"),
+ leaf-type);
}
if (new_advertise)
tp-to_advertise = new_advertise;
--
Jim Studt, President
The Federated Software Group, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
