Building 2.6.21-rc2 on a PowerMac, I get:
drivers/ide/ppc/pmac.c: In function 'pmac_ide_setup_dma':
drivers/ide/ppc/pmac.c:2042: warning: assignment from incompatible pointer type
drivers/ide/ppc/pmac.c: In function 'pmac_ide_dma_host_on':
drivers/ide/ppc/pmac.c:1988: warning: control reaches end
Linux 2.6.20
x86_64
nforce 410 chipset
ST3160811AS (Seagate 160GB SATA 2)
sata_nv :00:0e.0: version 3.2
ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23
ACPI: PCI Interrupt :00:0e.0[A] - Link [LSA0] - GSI 23 (level, low) -
IRQ 23
PCI: Setting latency timer of device :00:0e.0 to 64
Hello.
Mikael Pettersson wrote:
Building 2.6.21-rc2 on a PowerMac, I get:
drivers/ide/ppc/pmac.c: In function 'pmac_ide_setup_dma':
drivers/ide/ppc/pmac.c:2042: warning: assignment from incompatible pointer type
drivers/ide/ppc/pmac.c: In function 'pmac_ide_dma_host_on':
pata_legacy fails to detect the disk on my old ISA/VLB 486:
it starts to probe io=0x1f0 ctr=0x3f6 irq=15, complains
loudly about IDENTIFYs timing out, and finally fails.
(Sorry I couldn't capture the kernel's boot messages.)
It turns out that the driver's mapping from io to irq in
legacy_irq[] is
[PATCH] cmd64x: fix recovery time calculation
The driver wrongly takes the address setup time into account when calculating
the PIO recovery time -- this leads to slight overclocking of the PIO modes 0
and 1 (so, the prayers failed to help, as usual :-). Rework the code to be
calculating
On Sat, Mar 03, 2007 at 08:57:44PM +0100, Mikael Pettersson wrote:
pata_legacy fails to detect the disk on my old ISA/VLB 486:
it starts to probe io=0x1f0 ctr=0x3f6 irq=15, complains
loudly about IDENTIFYs timing out, and finally fails.
(Sorry I couldn't capture the kernel's boot messages.)
linux-2.6.21-rc2-git3/drivers/ata/pata_jmicron.c has an extra
#endif. The 2.6.21-rc2-git2 version compiled fine. Here is a patch
that removes the offending line.
I do not have hardware to test this change. I can verify that
the resulting driver compiles to a binary that
pata_legacy probes 6 io/ctr/irq combinations for devices.
Or rather, it loops, claims an io/ctr/irq combination, does
an ata_device_add(), and libata then does the probing.
However, the io/ctr/irq resource combinations aren't released
after failed probes (as in: no devices found). The result is
A merge mistake slipped upstream.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/pata_jmicron.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
Jeff Garzik
Hello.
Jeff Garzik wrote:
+/* The second channel has shared timings and the setup timing is
+ messy to switch to merge it for worst case */
+if (ap-port_no pair) {
+struct ata_timing p;
+ata_timing_compute(pair, pair-pio_mode, p, T, 1);
+
Bunch of fixes all over the map:
* Tejun's fix for incorrect drive side cable detection (before the fix
UDMA3-6 could be enabled on hosts lacking host side cable detection
resulting in error recovery code triggering up)
* workaround for older X servers having problems because of incoherency
Hello,
Applied this on top of 2.6.21-rc1, and I now have the following in my
logs :
ahci :00:1f.2: version 2.0
ACPI: PCI Interrupt :00:1f.2[B] - GSI 23 (level, low) - IRQ 23
PCI: Setting latency timer of device :00:1f.2 to 64
ahci :00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps
+if (t.active 16)
+t.active = 16;
Erm, clamping active time is not a right thing to do. Right thing to do
was to bail out. I didn't do it in the legacy driver rewrite though...
As far as I can work out its a can't happen
+pci_read_config_byte(pdev, ARTIM23,
Hello,
Tried this (as well as the next one to activate the cable_detect),
but it doesn't help my DVD-RW detection problem on pata_jmicron :
PCI: Enabling device :02:00.1 ( - 0001)
ACPI: PCI Interrupt :02:00.1[B] - GSI 16 (level, low) - IRQ 16
PCI: Setting latency timer of device
Alan Cox wrote:
+if (t.active 16)
+t.active = 16;
Erm, clamping active time is not a right thing to do. Right thing to do
was to bail out. I didn't do it in the legacy driver rewrite though...
As far as I can work out its a can't happen
+
Alan Cox wrote:
it seems broken to manipulate xfer_mask after returning from the
driver's -mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I actually suggested that order because the only way the printk can be
done correctly is for it to be the very last
[PATCH] pdc202xx_old: rewrite mode programming code
This patch is based on the documentation (I would like to thank Promise
for it) and also partially on the older vendor driver.
Rewrite mode programming code:
* disable 66MHz clock in pdc202xx_tune_chipset() so it is correctly disabled
even
[PATCH] pata_pdc202xx_old: fix data corruption and other problems
Fix wrong port calculations in pdc202xx_configure_piomode()
and pdc202xx_set_dmamode(), it was horribly broken which resulted
in major havoc on all configurations except one (master device on
primary channel, no other devices) as
Hi,
This version has improved patch description
(on the second thought the original patch description was too vague).
Bart
[PATCH] pata_pdc202xx_old: fix possible data corruption and other problems
Fix wrong port calculations in pdc202xx_{configure_piomode,set_dmamode}()
They were broken for
19 matches
Mail list logo
