Re: [git patches] libata fixes
Tejun Heo wrote: These are upstream patches I collected while Jeff is away. Thanks. * workaround for ATAPI tape drives * detection/suspend workarounds for several laptops * ICH8/9 port_enable fix ata_piix controller ID reorganization is included to ease the fixes. Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/tj/libata-dev.git upstream-linus to receive the following updates: drivers/ata/ata_piix.c| 87 drivers/ata/libata-core.c | 100 +++--- drivers/ata/libata-eh.c | 95 --- drivers/ata/libata-scsi.c |3 - drivers/ata/pata_sis.c|1 include/linux/libata.h|5 -- 6 files changed, 81 insertions(+), 210 deletions(-) Adrian Bunk (1): libata: remove unused functions Albert Lee (2): libata: workaround DRQ=1 ERR=1 for ATAPI tape drives libata: use ATA_HORKAGE_STUCK_ERR for ATAPI tape drives Gabriel C (1): pata_sis.c: Add Packard Bell EasyNote K5305 to laptops Mark Lord (1): libata-scsi: be tolerant of 12-byte ATAPI commands in 16-byte CDBs Tejun Heo (3): ata_piix: add SATELLITE U205 to broken suspend list ata_piix: reorganize controller IDs ata_piix: port enable for the first SATA controller of ICH8 is 0xf not 0x3 Thomas Rohwer (1): ata_piix: only enable the first port on apple macbook pro Just to make sure, I pulled this into #upstream-fixes. If Linus already picked it up, great. Otherwise I'll make sure it goes upstream. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sata_nv: don't use legacy DMA in ADMA mode
Tejun Heo wrote: Tejun Heo wrote: If so, can you please add that switching into register mode is okay as long as there's no other ADMA commands in flight and add WARN_ON((qc->flags & ATA_QCFLAG_RESULT_TF) && link->sactive)? More accurately, link->sactive test can be substituted with (ap->qc_allocated & ~(1 << qc->tag)). Unfortunately we only get the ata_port and ata_taskfile in the tf_read callback, so I'm not sure if we can do the equivalent of the qc->flags & ATA_QCFLAG_RESULT_TF test (i.e. distinguishing between the error-handling case where we care if we abort outstanding commands and the normal case with a RESULT_TF command where we do).. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v2)
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA
mode on systems with memory located above 4GB. We need to delay setting the
64-bit DMA mask until the PRD table and padding buffer are allocated so that
they don't get allocated above 4GB and break legacy mode (which is needed for
ATAPI devices). Also, explicitly set a 32-bit DMA mask before allocating the
legacy buffers since setting the DMA mask affects both ports and we need to
ensure the second port's buffers are allocated properly (fixes a problem
with the previous version of this patch).
Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
--- linux-2.6.24-rc3-git1edit/drivers/ata/sata_nv.c.before2 2007-11-20
17:47:46.0 -0600
+++ linux-2.6.24-rc3-git1edit/drivers/ata/sata_nv.c 2007-11-20
17:50:30.0 -0600
@@ -247,6 +247,7 @@
void __iomem*ctl_block;
void __iomem*gen_block;
void __iomem*notifier_clear_block;
+ u64 adma_dma_mask;
u8 flags;
int last_issue_ncq;
};
@@ -748,7 +749,7 @@
adma_enable = 0;
nv_adma_register_mode(ap);
} else {
- bounce_limit = *ap->dev->dma_mask;
+ bounce_limit = pp->adma_dma_mask;
segment_boundary = NV_ADMA_DMA_BOUNDARY;
sg_tablesize = NV_ADMA_SGTBL_TOTAL_LEN;
adma_enable = 1;
@@ -1134,10 +1135,16 @@
void *mem;
dma_addr_t mem_dma;
void __iomem *mmio;
+ struct pci_dev *pdev = to_pci_dev(dev);
u16 tmp;
VPRINTK("ENTER\n");
+ /* Ensure DMA mask is set to 32-bit before allocating legacy PRD and
+ pad buffers */
+ pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
+ pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32));
+
rc = ata_port_start(ap);
if (rc)
return rc;
@@ -1153,6 +1160,14 @@
pp->notifier_clear_block = pp->gen_block +
NV_ADMA_NOTIFIER_CLEAR + (4 * ap->port_no);
+ /* Now that the legacy PRD and padding buffer are allocated we can
+ safely raise the DMA mask to allocate the CPB/APRD table. */
+ pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
+ pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
+ /* Store the mask that was actually used so we can restore it as
+ the bounce limit later if needed */
+ pp->adma_dma_mask = *dev->dma_mask;
+
mem = dmam_alloc_coherent(dev, NV_ADMA_PORT_PRIV_DMA_SZ,
&mem_dma, GFP_KERNEL);
if (!mem)
@@ -2408,12 +2423,6 @@
hpriv->type = type;
host->private_data = hpriv;
- /* set 64bit dma masks, may fail */
- if (type == ADMA) {
- if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
- pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
- }
-
/* request and iomap NV_MMIO_BAR */
rc = pcim_iomap_regions(pdev, 1 << NV_MMIO_BAR, DRV_NAME);
if (rc)
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possibly SATA related freeze killed networking and RAID
> I've had other freezes before but this was the first time I was able > to see what was actually going on. > IRQ 21 appears to be shared between sata_nv and ethernet. > > Does this mean my hardware/BIOS is broken somehow? Not neccessarily. It could a bug in one of the drivers using IRQ 21 (sata_nv or the nvidia ethernet), it could be another inactive device, or it could be a hardware funny. Nvidia stuff can be quite hard to diagnose as we have no documentation but we can try. The first question is whether it is network or disk triggered - seeing if heavy loads to one or the other trigger the problem might be a first plan. Alan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/21] ide: move CONFIG_IDE_ETRAX to drivers/ide/Kconfig
On Monday 19 November 2007, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
>
> > * Move ETRAX_IDE and friends from arch/cris/arch-{v10,v32}/drivers/Kconfig
> > to drivers/ide/Kconfig.
>
> > * Don't force selecting ide-disk and ide-cd device drivers
> > (please handle this through defconfig if necessary).
>
> > * Make ETRAX_IDE depend on BROKEN for the time being
> > (it doesn't even compile currently).
>
> > Cc: Mikael Starvik <[EMAIL PROTECTED]>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
>
> > Index: b/drivers/ide/Kconfig
> > ===
> > --- a/drivers/ide/Kconfig
> > +++ b/drivers/ide/Kconfig
> > @@ -870,6 +870,41 @@ config BLK_DEV_IDE_BAST
> > Say Y here if you want to support the onboard IDE channels on the
> > Simtec BAST or the Thorcom VR1000
> >
> > +config ETRAX_IDE
> > + bool "ETRAX IDE support"
> > + depends on CRIS && BROKEN
> > + select BLK_DEV_IDEDMA
>
> Shouldn't it be the other way around, i.e. BLK_DEV_IDEDMA is enabled by
> ETRAX_IDE as is the case with this option otherwise?
Well, having a simple
config BLK_DEV_IDEDMA
bool
and making the other options select it seems to be a better solution.
Thanks,
Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possibly SATA related freeze killed networking and RAID
2007/11/20, Alan Cox <[EMAIL PROTECTED]>: > > kernel: [734344.717844] irq 21: nobody cared (try booting with the > > "irqpoll" option) > > kernel: [734344.717866] > > Your machine decided to emit interrupt 21 without an apparent reason. > Whatever caused that made the kernel shut down IRQ 21 at which point the > disk drives on that IRQ were no longer being serviced. Everything on IRQ > 21 would have died - which may be why your networking failed too. > > What do you have on IRQ 21 and is this a one off ? I've had other freezes before but this was the first time I was able to see what was actually going on. IRQ 21 appears to be shared between sata_nv and ethernet. Does this mean my hardware/BIOS is broken somehow? I'm running the latest BIOS available. # cat /proc/interruptsCPU0 CPU1 0: 264973603163 IO-APIC-edge timer 1: 0 2 IO-APIC-edge i8042 8: 0 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12: 0 6 IO-APIC-edge i8042 16: 4851 669159 IO-APIC-fasteoi shpchp, libata 20: 0 0 IO-APIC-fasteoi sata_nv 21: 364434775430 IO-APIC-fasteoi sata_nv, eth0 22: 312614531218 IO-APIC-fasteoi ohci_hcd:usb1, sata_nv 23: 4 1649 IO-APIC-fasteoi HDA Intel, ehci_hcd:usb2 NMI: 0 0 LOC:36295623629543 ERR: 0 -- noah - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possibly SATA related freeze killed networking and RAID
> kernel: [734344.717844] irq 21: nobody cared (try booting with the > "irqpoll" option) > kernel: [734344.717866] Your machine decided to emit interrupt 21 without an apparent reason. Whatever caused that made the kernel shut down IRQ 21 at which point the disk drives on that IRQ were no longer being serviced. Everything on IRQ 21 would have died - which may be why your networking failed too. What do you have on IRQ 21 and is this a one off ? - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
sata_sil issue on 2.6.22
Hello, I have a Compaq Deskpro EN P3 Celeron 850, running Debian etch with a 2.6.18 kernel, which runs/boots fine. It has an add-in generic SIL3112 SATA card, which also works fine with the 2.6.18 kernel. I just tried to install a 2.6.22 kernel from www.backports.org, and that kernel will not boot correctly because of the SATA card. Here is the dmesg output: Linux version 2.6.22-3-686 (Debian 2.6.22-5~bpo.1) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Wed Oct 31 16:15:58 UTC 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 1ffd (usable) BIOS-e820: 1ffd - 1fff (ACPI NVS) BIOS-e820: 1fff - 2000 (usable) BIOS-e820: feea - 0001 (reserved) 0MB HIGHMEM available. 512MB LOWMEM available. found SMP MP-table at 000f9bf0 Entering add_active_range(0, 0, 131072) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 131072 HighMem131072 -> 131072 early_node_map[1] active PFN ranges 0:0 -> 131072 On node 0 totalpages: 131072 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 992 pages used for memmap Normal zone: 125984 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap DMI 2.3 present. ACPI: RSDP 000E0010, 0014 (r0 COMPAQ) ACPI: RSDT 000E0080, 005C (r1 COMPAQ CPQ0005 20020913 0) ACPI: FACP 000E0130, 0074 (r1 COMPAQ SOLANO 1 0) ACPI: DSDT 000E0204, 12F5 (r1 COMPAQ DSDT1 MSFT 10D) ACPI: FACS 000E0040, 0040 ACPI: SSDT 000E14F9, 0174 (r1 COMPAQ CORE_UTL1 MSFT 10D) ACPI: SSDT 000E166D, 0D1C (r1 COMPAQ VILLTBL11 MSFT 10D) ACPI: SSDT 000E33B3, 005D (r1 COMPAQ FHUB1 MSFT 10D) ACPI: APIC 000E01A4, 0060 (r1 COMPAQ SOLANO 1 0) ACPI: SSDT 000E333D, 0076 (r1 COMPAQ APIC1 MSFT 10D) ACPI: SSDT 000E2389, 06AD (r1 COMPAQ PNP_PRSS1 MSFT 10D) ACPI: SSDT 000E2A94, 01A4 (r1 COMPAQ S31 MSFT 10D) ACPI: SSDT 000E2C38, 0158 (r1 COMPAQ PIDETM1 MSFT 10D) ACPI: SSDT 000E2EED, 010B (r1 COMPAQ GTF01 MSFT 10D) ACPI: SSDT 000E2FF8, 0117 (r1 COMPAQ GTF11 MSFT 10D) ACPI: SSDT 000E2D90, 015D (r1 COMPAQ SIDETM1 MSFT 10D) ACPI: SSDT 000E310F, 0117 (r1 COMPAQ GTF21 MSFT 10D) ACPI: SSDT 000E349B, 004E (r1 COMPAQFINIS1 MSFT 10D) ACPI: PM-Timer IO Port: 0xf808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 17 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: IOAPIC (id[0x08] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 8, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:deea) Built 1 zonelists. Total pages: 130048 Kernel command line: root=/dev/hda1 ro single mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 847.431 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 510088k/524288k available (1689k kernel code, 13380k reserved, 648k data, 244k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfff4e000 - 0xf000 ( 708 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xe080 - 0xff7fe000 ( 495 MB) lowmem : 0xc000 - 0xe000 ( 512 MB) .init : 0xc034f000 - 0xc038c000 ( 244 kB) .data : 0xc02a65d7 - 0xc03487e4 ( 648 kB) .text : 0xc010 - 0xc02a65d7 (1689 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 1696.43 BogoMIPS (lpj=3392864) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383fbff CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 128K CPU: After all inits, caps: 0383fbff 0040
SATA port multiplier Identify/Fail LEDs: driver support
Hi, I have Addonics.com port multiplier which has SiI3726 chip. I'm pretty sure it has LED outputs that are software controllable, to use with RAID enclosures for Identifying drives (that have failed for example). I wonder if anyone has chipset docs that can be used to write Linux drivers for this function? A brief email to Silicon Images a while back wasn't very helpful, IIRC. Thanks, Jeremy -- Jeremy Jackson Coplanar Networks (519)489-4903 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Possibly SATA related freeze killed networking and RAID
I just had a strange freeze that killed networking and made software RAID fail two of my harddisks. There are a bunch of messages from the kernel which I extracted from the system log after reboot at the end of this mail. I hit power off in pure paranoia after the box froze, and then started to do disk I/O again just right after I noticed the messages about two of my RAID disks had failed on the console. The network didn't recover when the harddrive suddenly started working again. I managed to connect an USB keyboard and wake up the monitor from sleep so I could see some of the messages printed on the console. I looked through some other threads and found a mention of smartmontools which I too use (5.37-5ubuntu2). Kernel 2.6.22-14-generic (Ubuntu Gutsy Gibbon 7.10) Motherboard: Asus M2N32 WS Professional nForce 590 SLI MCP (MCP55) CPU: Athlon64 X2 Dual-Core 5600+ RAM: 4GB (passed memtest86 just a few minutes ago) The harddrives are four Samsung HD501LJ 500GB drives. sda and sdb have firmware CR100-10 and sdc and sdd have firmware CR100-11. The drives are just a couple of months old, well cooled and so far there's nothing interesting reported by S.M.A.R.T. Software raid is configured like this: sda1,sdc1 -> md0 (raid 1) sdb1,sdd1 -> md1 (raid 1) Both md0 and md1 are then encrypted with dm-crypt and the dm-devices are then used to form md2 (stripe). -- noah # lspci 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2) 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2) 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2) 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2) 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2) 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2) 00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:08.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1) 00:09.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2) 00:09.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2) 00:09.2 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2) 00:0a.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1) 00:0a.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2) 00:0c.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:0d.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) 00:0d.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) 00:0d.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) 00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2) 00:0e.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2) 00:10.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) 00:11.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) 00:12.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) 00:14.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) 00:15.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) 00:16.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) 00:17.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: nVidia Corporation GeForce 8400 GS (rev a1) 02:06.0 Communication controller: Tiger Jet Network Inc. Tiger3XX Modem/ISDN interface 03:00.0 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06) 03:00.1 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06) 08:00.0 RAID bus controller: Marvell Technology Group Ltd. 88SE6145 SATA II PCI-E controller (rev a1) kernel: [734344.717844] irq 21: nobody cared (try booting with the "irqpoll" option) kernel: [734344.717866] kernel: [734344.717866] Call Trace: kernel: [734344.717868][__report_bad_irq+30/128] __report_bad_irq+0x1e/0x80 mdadm: Fail event detected on md device /dev/md1, component device /dev/sdd1 kernel: [734344.717888] [note_interrupt+643/704] note_interrupt+0x283/0x2c0 kernel: [734344.717895] [handle_fasteoi_irq+221/272] handle_fasteoi_irq+0xdd/0x110 mdadm: Fail event detected on md device /dev/md0, component device /dev/sdc1 kernel: [734344.717901] [do_IRQ+123/256] do_IRQ+0x7b/0x100 kernel: [734344.717904] [default_idle+0/64] default_idle+0x0/0x40 kernel: [734344.717907] [ret_from_intr+0/10] ret_from_intr+0x0/0xa kernel: [734344.717909][tcp_poll+0/368] tcp_poll+0x0/0x170 kernel: [734344.717918]
Re: 2.6.24-rc & SB600 AHCI no go on >=4GB of RAM II
On Tue, Nov 20 2007, Andi Kleen wrote:
>
> > Which in turn enables the iommu_merge functionality in gart_map_sg().
>
> > for_each_sg(sg, s, nents, i) {
>
> Hmm, another thought. Maybe this code just has trouble with the new
> linked SG lists and it's not really a SB600 problem?
>
> I did a quick test on two ATI machines with older chipset and
> iommu=force,merge and it didn't show a problem though.
chained sg lists aren't enabled on libata, so it should not affect
libata drivers.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc & SB600 AHCI no go on >=4GB of RAM
On Tuesday 20 November 2007 19:29:56 Thomas Gleixner wrote:
> On Tue, 20 Nov 2007, Andi Kleen wrote:
>
> >
> > > This requires propably working 64bit DMA, which is not possible with
> > > the SB600 controller.
> >
> > It should not no. The remapping is done into the GART which is <4GB
> > and that is the address the SB600 sees.
>
> Hmm, I just checked the boot logs of the failing 4GB kernel:
>
> BIOS-e820: 0001 - 00012000 (usable)
> ...
> CPU 0: aperture @ c00 size 32 MB
> Aperture too small (32 MB)
> No AGP bridge found
> Your BIOS doesn't leave a aperture memory hole
> Please enable the IOMMU option in the BIOS setup
> This costs you 64 MB of RAM
> Mapping aperture over 65536 KB of RAM @ c00
The aperture is mapped at c00 and c00 + 64MB < 4GB
> Memory: 4055984k/4718592k available (2146k kernel code, 136780k reserved,
> 1273k data, 296k init)
>
> 4718592k * 1024 == 0x12000
>
> So now we have addresses > 4G and I suspect that this is somehow
> related to the problem.
Yes of course -- without >4GB the PCI-GART would not be used at all
(unless you force it) and then no merging.
>
> Also is the aperture size of 32MB somehow related to this ?
This just means the BIOS didn't initialize it properly (a lot of
BIOS don't do anymore these days because they assume it's a AGP
only feature) -- that is why the kernel allocated its own over
memory.
I think we really have to find out which request freezes it.
Can you perhaps just apply this patch and post the output?
Index: linux-2.6.24-rc1-hack/arch/x86/kernel/pci-gart_64.c
===
--- linux-2.6.24-rc1-hack.orig/arch/x86/kernel/pci-gart_64.c
+++ linux-2.6.24-rc1-hack/arch/x86/kernel/pci-gart_64.c
@@ -385,13 +385,19 @@ static int gart_map_sg(struct device *de
unsigned long pages = 0;
int need = 0, nextneed;
struct scatterlist *s, *ps, *start_sg, *sgmap;
-
+
if (nents == 0)
return 0;
if (!dev)
dev = &fallback_dev;
+ if (*dev->dma_mask <= 0x) {
+ for_each_sg(sg, s, nents, i) {
+ printk("%d: map %lx len %u dir %d\n", i, sg_phys(s),
s->length, dir);
+ }
+ }
+
out = 0;
start = 0;
start_sg = sgmap = sg;
Tejun can probably figure out from that output where it comes
from in libata :)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc & SB600 AHCI no go on >=4GB of RAM
On Tue, 20 Nov 2007, Andi Kleen wrote: > > > This requires propably working 64bit DMA, which is not possible with > > the SB600 controller. > > It should not no. The remapping is done into the GART which is <4GB > and that is the address the SB600 sees. Hmm, I just checked the boot logs of the failing 4GB kernel: BIOS-e820: 0001 - 00012000 (usable) ... CPU 0: aperture @ c00 size 32 MB Aperture too small (32 MB) No AGP bridge found Your BIOS doesn't leave a aperture memory hole Please enable the IOMMU option in the BIOS setup This costs you 64 MB of RAM Mapping aperture over 65536 KB of RAM @ c00 Memory: 4055984k/4718592k available (2146k kernel code, 136780k reserved, 1273k data, 296k init) 4718592k * 1024 == 0x12000 So now we have addresses > 4G and I suspect that this is somehow related to the problem. When mem=3500M is given on the kernel command line, we do not use this address space. Also is the aperture size of 32MB somehow related to this ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc & SB600 AHCI no go on >=4GB of RAM II
> Which in turn enables the iommu_merge functionality in gart_map_sg().
> for_each_sg(sg, s, nents, i) {
Hmm, another thought. Maybe this code just has trouble with the new
linked SG lists and it's not really a SB600 problem?
I did a quick test on two ATI machines with older chipset and iommu=force,merge
and it didn't show a problem though.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc & SB600 AHCI no go on >=4GB of RAM
> This requires propably working 64bit DMA, which is not possible with > the SB600 controller. It should not no. The remapping is done into the GART which is <4GB and that is the address the SB600 sees. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc & SB600 AHCI no go on >=4GB of RAM
On Tue, 20 Nov 2007, Tejun Heo wrote:
> Andi Kleen wrote:
> >
> >> The AHCI code falls back to 32bit DMA in that case. Which in turn
> >> causes the problem seen by Srihari. There is not much printk sticking
> >> necessary, the code is simply not handling this.
> >
> > What code is not handling what?
> >
> > IOMMU merging should be always safe. If it is not the driver should
> > not submit things in a single SG list.
>
> Yeap, a sg merged by IOMMU should be safe. It's just another contiguous
> memory area from the POV of the controller anyway. I wonder what went
> wrong here. What has exactly changed with iommu_merge patch?
Not much:
-int iommu_merge __read_mostly = 0;
+int iommu_merge __read_mostly = 1;
EXPORT_SYMBOL(iommu_merge);
Which in turn enables the iommu_merge functionality in gart_map_sg().
for_each_sg(sg, s, nents, i) {
dma_addr_t addr = sg_phys(s);
s->dma_address = addr;
BUG_ON(s->length == 0);
nextneed = need_iommu(dev, addr, s->length);
/* Handle the previous not yet processed entries */
if (i > start) {
/* Can only merge when the last chunk ends on a page
boundary and the new one doesn't have an offset. */
if (!iommu_merge || !nextneed || !need || s->offset ||
(ps->offset + ps->length) % PAGE_SIZE) {
if (dma_map_cont(start_sg, i - start, sgmap,
pages, need) < 0)
goto error;
out++;
sgmap = sg_next(sgmap);
pages = 0;
start = i;
start_sg = s;
}
}
need = nextneed;
pages += to_pages(s->offset, s->length);
ps = s;
}
if (dma_map_cont(start_sg, i - start, sgmap, pages, need) < 0)
goto error;
So with iommu_merge off we map for each entry in the sg
list. iommu_merge concatenates into larger segments.
This requires propably working 64bit DMA, which is not possible with
the SB600 controller.
Thanks,
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: laptop reboots right after hibernation
sø., 18.11.2007 kl. 21.16 +0100, skrev Tomas Carnecky: > Since this is becoming more an IDE/ATA issue, I added > linux-ide@vger.kernel.org to CC. I hope that's the right mailinglist. > > Tomas Carnecky wrote: > > (3) Once the notebook was in the docking station (whether I boot it > > while in the dock or boot it outside and then put it into the dock) and > > I take it out (press the 'undock' button on the dock, wait for the green > > led, then take out the notebook) things get interesting: > > > > (a) I initiate STR, notebook correctly goes to sleep, but it only wakes > > up if I have it in the docking station. If I try to wake it up outside > > of the docking station it will fail. > [snip str problem description] > ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04) > ata4: failed to recover some devices, retrying in 5 secs > Coming out of suspend... > [... snip ...] > ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04) > ata4.00: ACPI on devcfg failed the second time, disabling (errno=-5) > ata4.00: revalidation failed (errno=1) > ata4: failed to recover some devices, retrying in 5 secs > ata4.00: configured for UDMA/33 > I get this exact error message on a normal first time boot here. I'm using the latest fedora development kernel which is 2.6.24-rc2-git6 based. And I have the latest BIOS from HP IIRC. This is an HP nc6400 intel based laptop: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04) ata1.00: ACPI on devcfg failed the second time, disabling (errno=-5) ata1.00: revalidation failed (errno=1) ata1: failed to recover some devices, retrying in 5 secs ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: configured for UDMA/100 ata2: SATA link down (SStatus 0 SControl 0) ata3: SATA link down (SStatus 0 SControl 0) ata4: SATA link down (SStatus 0 SControl 0) scsi 0:0:0:0: Direct-Access ATA FUJITSU MHV2080B 892C PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: [sda] Attached SCSI disk insmod used greatest stack depth: 596 bytes left lspci: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 01) 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5753M Gigabit Ethernet PCI Express (rev 21) 02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) 04:06.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller 04:06.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD) 04:06.3 Generic system peripheral [0805]: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller 04:06.4 Communication controller: Texas Instruments PCIxx12 GemCore based SmartCard controller Cheers Kjartan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
