Re: [PATCH 6/21] ide: move CONFIG_IDE_ETRAX to drivers/ide/Kconfig
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.
Well, then
Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>
MBR, Sergei
-
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] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v2)
Le mardi 20 novembre 2007 à 18:56 -0600, Robert Hancock a écrit : > 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]> > Would this be worth sending to stable team for 2.6.22 & 2.6.23 ? Regards, - vin - 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] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v2)
Vincent Fortier wrote: Le mardi 20 novembre 2007 à 18:56 -0600, Robert Hancock a écrit : 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]> Would this be worth sending to stable team for 2.6.22 & 2.6.23 ? Likely (after it gets merged), those versions would have the same bug.. - 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/21, Alan Cox <[EMAIL PROTECTED]>: > > 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. How can I tell if there's an inactive device? > 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. I haven't managed to trigger it again yet but at the time the CPU was heavily loaded and I was re-indexing a database which caused a lot of disk activity. I'm quite confident the network was pretty much idle at the time. -- 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
SATA PMP support in 2.6.24-rc3?
Does 2.6.24-rc3 support SATA port multipliers? I am getting "ata6.03: COMRESET failed (errno=-5)" error messages with a SiliconImage PMP connected to an Intel ICH9 SATA controller in AHCI mode. Dmesg output attached. Thanks, Jason Linux version 2.6.24-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)) #1 SMP Tue Nov 20 17:43:24 PST 2007 Command line: ro root=/dev/VolGroup00/LogVol00 pci=nommconf rhgb quiet BIOS-provided physical RAM map: BIOS-e820: - 0009c000 (usable) BIOS-e820: 0009c000 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 7d3a (usable) BIOS-e820: 7d3a - 7d3ae000 (ACPI data) BIOS-e820: 7d3ae000 - 7d3f (ACPI NVS) BIOS-e820: 7d3f - 7d70 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffa6b000 - ffa6c000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) Entering add_active_range(0, 0, 156) 0 entries of 3200 used Entering add_active_range(0, 256, 512928) 1 entries of 3200 used end_pfn_map = 1048576 DMI present. ACPI: RSDP 000F93C0, 0014 (r0 ACPIAM) ACPI: RSDT 7D3A, 0044 (r1 080107 RSDT1024 20070801 MSFT 97) ACPI: FACP 7D3A0200, 0084 (r2 080107 FACP1024 20070801 MSFT 97) ACPI: DSDT 7D3A0490, 687F (r1 VVBLI9 VVBLI958 58 INTL 20051117) ACPI: FACS 7D3AE000, 0040 ACPI: APIC 7D3A0390, 006C (r1 080107 APIC1024 20070801 MSFT 97) ACPI: MCFG 7D3A0450, 003C (r1 080107 OEMMCFG 20070801 MSFT 97) ACPI: OEMB 7D3AE040, 008A (r1 080107 OEMB1024 20070801 MSFT 97) ACPI: ASF! 7D3A6D10, 0099 (r32 LEGEND I865PASF1 INTL 20051117) ACPI: GSCI 7D3AE0D0, 2024 (r1 080107 GMCHSCI 20070801 MSFT 97) ACPI: iEIT 7D3B0100, 00B0 (r1 080107 EITTABLE 20070801 MSFT 97) ACPI: SSDT 7D3B0C90, 0877 (r1 DpgPmmCpuPm 12 INTL 20051117) No NUMA configuration found Faking a node at -7d3a Entering add_active_range(0, 0, 156) 0 entries of 3200 used Entering add_active_range(0, 256, 512928) 1 entries of 3200 used Bootmem setup node 0 -7d3a [e200-e21f] PMD ->81000120 on node 0 [e220-e23f] PMD ->81000160 on node 0 [e240-e25f] PMD ->810001a0 on node 0 [e260-e27f] PMD ->810001e0 on node 0 [e280-e29f] PMD ->81000220 on node 0 [e2a0-e2bf] PMD ->81000260 on node 0 [e2c0-e2df] PMD ->810002a0 on node 0 [e2e0-e2ff] PMD ->810002e0 on node 0 [e2000100-e200011f] PMD ->81000320 on node 0 [e2000120-e200013f] PMD ->81000360 on node 0 [e2000140-e200015f] PMD ->810003a0 on node 0 [e2000160-e200017f] PMD ->810003e0 on node 0 [e2000180-e200019f] PMD ->81000420 on node 0 [e20001a0-e20001bf] PMD ->81000460 on node 0 Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 -> 156 0: 256 -> 512928 On node 0 totalpages: 512828 DMA zone: 56 pages used for memmap DMA zone: 1952 pages reserved DMA zone: 1988 pages, LIFO batch:0 DMA32 zone: 6956 pages used for memmap DMA32 zone: 501876 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, 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. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 8000 (gap: 7d70:8170) SMP: Allowing 4 CPUs, 2 hotplug CPUs PERCPU: Allocating 63928 bytes of per cpu data Built 1 zonelists in Node order, mobility grouping on. Total pages: 503864 Policy zone: DMA32 Kernel command line: ro root=/dev/VolGroup00/LogVol00 pci=nommconf rhgb quiet Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) TSC calibrated against PM_TIMER time.c: Detected 2992.493 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Checking ap
Re: 2.6.24-rc3-mm1: I/O error, system hangs
On Wed, 21 Nov 2007 22:45:22 +0100 Laurent Riffard <[EMAIL PROTECTED]> wrote: > Le 21.11.2007 05:45, Andrew Morton a écrit : > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ > > Hello, > > My system hangs shortly after I logged in Gnome desktop. SysRq-W shows > that a bunch of task are blocked in "D" state, they seem to wait for > some I/O completion. I can try to hand-copy some data if requested. > > I found these messages in dmesg: > > ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 > EXT3-fs: mounted filesystem with ordered data mode. > sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT > driverbyte=DRIVER_OK,SUGGEST_OK > end_request: I/O error, dev sda, sector 16460 > ReiserFS: sda7: found reiserfs format "3.6" with standard journal > ReiserFS: sda7: using ordered data mode > -- > ReiserFS: sda7: Using r5 hash to sort names > sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT > driverbyte=DRIVER_OK,SUGGEST_OK > end_request: I/O error, dev sdb, sector 19632 > sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT > driverbyte=DRIVER_OK,SUGGEST_OK > end_request: I/O error, dev sdb, sector 40037363 > Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 > across:1048568k > lp0: using parport0 (interrupt-driven). > > These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible. > 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. > > Maybe something is broken in pata_via driver ? > Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch touch pata_via.c. - 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
Robert Hancock wrote: > 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).. You can test it in ->qc_issue(), no? -- tejun - 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: SATA port multiplier Identify/Fail LEDs: driver support
Jeremy Jackson wrote: > 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. Yeah, the chip has built-in enclosure controller and libata doesn't have support for it yet. One of the reasons being I can't find any hardware which uses that feature here. :-( -- tejun - 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] pata_jmicron: fix disabled port handling in jmicron_pre_reset()
Tejun Heo wrote: > There are two bugs in disabled port handling. > > * test in PORT_PATA0 is reversed > * ->prereset should return -ENOENT for disabled ports not 0 > > The first bug makes the PATA channel considered disabled but the > second bug saves the day by returning 0. The net result is that cable > is always left at ATA_CBL_UNKNOWN. This results in false 80c > configuration and thus transfer errors. > > This patch fixes both bugs. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Jeff, this wasn't pushed to Linus. Can you please put this into #upstream-fixes? Thanks. -- tejun - 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] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v2)
Hello, Robert. Robert Hancock wrote: > 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]> > > + /* 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)); [--snip--] > + pci_set_dma_mask(pdev, DMA_BIT_MASK(64)); > + pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64)); I'm probably being paranoid here but please add error checks. Just checking return value and returning error suffices. Thanks. -- tejun - 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
