Re: libata/sata_sil24 cache alignment problem?
I wonder if this may be what I am seeing with the Si3124 on my Alpha based setup. I'm not sure if Alpha meets all the criteria, but the thing refuses to recognize any drivers when they are connected and I see what are supposed pci parity failures. maybe not ... ...tom Mark Mason wrote: Hi All, I've implemented the Linux PCI support for a new architecture, and have run into what appears to be a bug in libata, but I don't understand why it wouldn't have been seen on other architectures. The processor is a Tile64, which is a 64 core, 64 bit VLIW processor with non-coherent DMA - DMA transfers bypass the cache, so cache coherence must be maintained manually. I am working with libata v2.0, from Linux 2.6.18, and the sata_sil24 driver for a Silicon Images SIL3531A chip. The problem occurs when the drive's model and serial numbers are read at startup via ata_dev_read_id(). They are read once on driver startup, then when the the error handler first runs it verifies that the model and serial numbers match what was read when the driver started. The problem is with the proximity of the private_data and sector_buf members of the ata_port struct, and the sector_buf not being cache aligned. ata_qc_issue() calls dma_map_single(), which in my case flushes and invalidates the cache for the buffer it's about DMA into (ata_port-sector_buf), then calls sil24_qc_issue(). sil24_qc_issue() then dereferences ata_port-private_data, which causes the cache line containing it to be read in, bringing part of the sector_buf with it, before the DMA transfer has taken place. The Tile64 processor does not have a cache invalidate instruction, only a flush/invalidate, so dma_unmap_single() can't invalidate the portion of the sector_buf that's been inadvertently read in, and I get a serial number and/or model number mismatch, due to part of the buffer being stale. Documentation/DMA-API.txt states that addresses passed to dma_map_single() and dma_unmap_single() must be cache aligned for this reason. Both calls to ata_dev_read_id() request DMA into a non cache-aligned buffer, but only the second call - via ata_dev_same_device() - has a conflict that can cause the cache line to be read back in during the very narrow window for which this vulnerability exists. Has anyone else reported a problem like this? It requires non-coherent DMA, and a lack of a cache invalidate instruction, and one of the drivers that has this problem (it looks like sata_qstor does too, I haven't looked at others), so maybe that doesn't cover any other architectures. I can provide a patch if you're interested. - 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 - 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_sil24 / Alpha / 4726 PMP issue ..
No like with only a drive attached and no PMP. The driver is still unable to IDENTIFY the connected disk: failed to IDENTIFY (I/O error, err_mask=0x20) On Jan 28, 2008 1:51 AM, Thomas Evans [EMAIL PROTECTED] wrote: On 1/27/08, Tejun Heo [EMAIL PROTECTED] wrote: Hmmm... That's strange. If PERR makes a difference, it means PCI bus side is contributing to the problem but only when PMP is attached while directly attached drive works just fine? I need to get a esata to sata cable - i returned all my duplicate equipment, so i haven't a 3124 with internal sata ports. I will try soon. - 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_sil24 / Alpha / 4726 PMP issue ..
I've tried it in various slots on both PCI hoses - no difference. ...tom Tejun Heo wrote: Thomas Evans wrote: No like with only a drive attached and no PMP. The driver is still unable to IDENTIFY the connected disk: failed to IDENTIFY (I/O error, err_mask=0x20) So, the problem is not specific to PMP support. That makes more sense. Does moving the controller to different slot make any difference? - 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_sil24 / Alpha / 4726 PMP issue ..
I hate blasting the the list with every minute detail. On 1/27/08, Tejun Heo [EMAIL PROTECTED] wrote: Hmmm... That's strange. If PERR makes a difference, it means PCI bus side is contributing to the problem but only when PMP is attached while directly attached drive works just fine? I need to get a esata to sata cable - i returned all my duplicate equipment, so i haven't a 3124 with internal sata ports. I will try soon. Thanks but I'm as lost as you are. :-( I backed out my printk's - I must have change the flow somehow. With only bit 28 set (ignore PERRs) I see: ata1: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa irq 31 ata2: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa2000 irq 31 ata3: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa4000 irq 31 ata4: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa6000 irq 31 ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata1.15: Port Multiplier 1.1, 0x1095:0x4726 r31, 7 ports, feat 0x1/0x9 ata1.00: hard resetting link ata1.00: SATA link down (SStatus 0 SControl 10) ata1.01: hard resetting link ata1.01: SATA link down (SStatus 0 SControl 4000320) ata1.02: hard resetting link ata1.02: SATA link down (SStatus 0 SControl 4000320) ata1.03: hard resetting link ata1.03: SATA link down (SStatus 0 SControl 4000320) ata1.04: hard resetting link ata1.04: SATA link down (SStatus 0 SControl 4000320) ata1.05: hard resetting link ata1.05: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata1.06: hard resetting link ata1.06: SATA link up 1.5 Gbps (SStatus 113 SControl 4000320) ata1.05: failed to IDENTIFY (I/O error, err_mask=0x20) ata1.15: hard resetting link ata1: controller in dubious state, performing PORT_RST ata1.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0) I'm not sure why there are PCI parity errors - I went so far as to turn off pci parity from the alpha SRM console. (it used to work fine with it on). This hasn't made much diffence above, except that the err_mask=0x21 when pci parity is on...? I'll try a non-PMP connected drive hopefully tommorow evening. Thanks, ...tom - 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_sil24 / Alpha / 4726 PMP issue ..
added some more printk's based on what I saw - maybe some issue with the dma port? ...tom Thomas Evans wrote: Tejun (and all) - I've attached a log from my machine marked up with a few extra printk's. I did add the ssleep() you suggested off line - made no difference. I'll be happy to add more prinks in places that I did not ... kobject sata_sil24: registering. parent: NULL, set: module kobject holders: registering. parent: sata_sil24, set: NULL kobject_uevent_env kobject filter function caused the event to drop! kobject_uevent_env fill_kobj_path: path = '/module/sata_sil24' kobject notes: registering. parent: sata_sil24, set: NULL kobject_uevent_env kobject filter function caused the event to drop! bus pci: add driver sata_sil24 kobject sata_sil24: registering. parent: NULL, set: drivers kobject_uevent_env fill_kobj_path: path = '/bus/pci/drivers/sata_sil24' pci: Matched Device :00:07.0 with Driver sata_sil24 pci: Probing driver sata_sil24 with device :00:07.0 sata_sil24 :00:07.0: version 1.1 sata_sil24 :00:07.0: init_one -pcim_enable_device sata_sil24 :00:07.0: init_one -pcim_iomap_regions sata_sil24 :00:07.0: init_one -pcim_iomap_regions sata_sil24 :00:07.0: init_one - IRQ-loss PCI-X Errata. sata_sil24 :00:07.0: readl(iomap[SIL24_HOST_BAR] + HOST_CTRL) = 011F sata_sil24 :00:07.0: Clearing completion IRQ loss on PCI-X errata fix sata_sil24 :00:07.0: init_one - allocate and fill host ata4294967295: init_one ata4294967295: init_one ata4294967295: init_one ata4294967295: init_one sata_sil24 :00:07.0: init_one - setting 64 bit DMA sata_sil24 :00:07.0: init_one - sil24_init_controller ata4294967295: sil24_config_port - STD WOC ata4294967295: sil24_config_port - STD WOC ata4294967295: sil24_config_port - STD WOC ata4294967295: sil24_config_port - STD WOC sata_sil24 :00:07.0: init_one - setting master PCI: Enabling bus mastering for device :00:07.0 sata_sil24 :00:07.0: init_one - ata_host_activate scsi54 : sata_sil24 DEV: registering device: ID = 'host54' kobject host54: registering. parent: :00:07.0, set: devices kobject_uevent_env kobject filter function caused the event to drop! CLASS: registering class device: ID = 'host54' kobject host54: registering. parent: scsi_host, set: class_obj kobject_uevent_env fill_kobj_path: path = '/class/scsi_host/host54' class_uevent - name = host54 fill_kobj_path: path = '/devices/pci:00/:00:07.0/host54' scsi55 : sata_sil24 DEV: registering device: ID = 'host55' kobject host55: registering. parent: :00:07.0, set: devices kobject_uevent_env kobject filter function caused the event to drop! CLASS: registering class device: ID = 'host55' kobject host55: registering. parent: scsi_host, set: class_obj kobject_uevent_env fill_kobj_path: path = '/class/scsi_host/host55' class_uevent - name = host55 fill_kobj_path: path = '/devices/pci:00/:00:07.0/host55' scsi56 : sata_sil24 DEV: registering device: ID = 'host56' kobject host56: registering. parent: :00:07.0, set: devices kobject_uevent_env kobject filter function caused the event to drop! CLASS: registering class device: ID = 'host56' kobject host56: registering. parent: scsi_host, set: class_obj kobject_uevent_env fill_kobj_path: path = '/class/scsi_host/host56' class_uevent - name = host56 fill_kobj_path: path = '/devices/pci:00/:00:07.0/host56' scsi57 : sata_sil24 DEV: registering device: ID = 'host57' kobject host57: registering. parent: :00:07.0, set: devices kobject_uevent_env kobject filter function caused the event to drop! CLASS: registering class device: ID = 'host57' kobject host57: registering. parent: scsi_host, set: class_obj kobject_uevent_env fill_kobj_path: path = '/class/scsi_host/host57' class_uevent - name = host57 fill_kobj_path: path = '/devices/pci:00/:00:07.0/host57' ata5: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa irq 31 ata6: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa2000 irq 31 ata7: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa4000 irq 31 ata8: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa6000 irq 31 ata5: sil24_init_port - no PMP? ata5: ata_eh_recover - 1 ata5: ata_eh_recover - 2 re-enable link? ata5.00: ata_eh_recover - 3 ata5.00: ata_eh_recover - 5 ata5.00: ata_eh_recover - 6 ata5.00: ata_eh_recover - ata_dev_init 7 ata_eh_recover - 8 - retry ata5: ata_eh_recover - 8a prep for EH ata5: ata_eh_recover - reset ata5: ata_eh_recover - ATA_DEV_UNKNOWN ata_eh_recover - 9 - reset is true ata_eh_recover - freezing port - nr_pmp_links == 0 ata5: ata_eh_recover - ata_eh_reset ata5: hard resetting link ata5: hardreset - 1! ata5: hardreset - 2! ata5: hardreset - 3! ata5: hardreset - 4! ata5: hardreset - 4a! ata5: hardreset - 5! ata5: hardreset - 6! ata5: hardreset - 7 - ret -EAGAIN! ata5: PHYS - something is attached. ata5: sil24_init_port - no PMP? ata5: sil24_exec_polled_cmd irq_enabled = ata5: sil24_exec_polled_cmd paddr HI: LO:81A0
Re: sata_sil24 / Alpha / 4726 PMP issue ..
Saw something that caught my attention might be nothing ... When initialized, the port address is a 64 bit address: sil24_init_one init_one: port:FD00:09AA sil24_init_one init_one: port:FD00:09AA2000 sil24_init_one init_one: port:FD00:09AA4000 sil24_init_one init_one: port:FD00:09AA6000 When the description from ata_port_pbar_desc comes out, it shows: ata13: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa irq 31 ata14: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa2000 irq 31 ata15: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa4000 irq 31 ata16: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa6000 irq 31 I don't think the output is being truncated? Is there some issue with the address? ...tom Thomas Evans wrote: added some more printk's based on what I saw - maybe some issue with the dma port? ...tom - 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_sil24 / Alpha / 4726 PMP issue ..
I will work on getting that log - is there anything non-kernel that may have changed that could cause this? udev changes or something like that? Just so odd for it to start failing after having worked for so long. ...tom On Jan 23, 2008 10:52 PM, Tejun Heo [EMAIL PROTECTED] wrote: Thomas Evans wrote: Um, I can, but it's not all that different than the others - is there something I am missing that would collect more info in the logs? Well, at times, small differences can tell us more information. The best we can do here is to gather as much information as possible. Even if we fail to solve the issue now, it may come handy later when similar instances happen and more clues are gathered. -- 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_sil24 / Alpha / 4726 PMP issue ..
That's what I thought - is there another chip that support the 4726 PMP that you think I could try? ...tom On Jan 24, 2008 10:11 AM, Tejun Heo [EMAIL PROTECTED] wrote: Thomas Evans wrote: I will work on getting that log - is there anything non-kernel that may have changed that could cause this? udev changes or something like that? Just so odd for it to start failing after having worked for so long. Nope, this is way before userland has any say in it. The same kernel version which used to work doesn't work on two slightly different machines. That's just weird. :-( -- 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_sil24 / Alpha / 4726 PMP issue ..
Um, I can, but it's not all that different than the others - is there something I am missing that would collect more info in the logs? Thanks, ...tom On Jan 23, 2008 9:32 PM, Tejun Heo [EMAIL PROTECTED] wrote: Thomas Evans wrote: I hadn't tried that until just now - I have 2 3124 cards, 1 without internal connections. Just tried the 1 with internal sata ports - it fails in the same way on a single drive. There are cable which have SATA connector on one side and e-SATA on the other. You can connect harddrives directly using such cables. Can you please post the failing log? -- 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_sil24 / Alpha / 4726 PMP issue ..
On 1/21/08, Tejun Heo [EMAIL PROTECTED] wrote: Hello, Thomas. Hi - Can you install linux on a x86 machine and see whether anything is different? Did that today - it mostly works. There is some sort of conflict with the card on the PC I am using. During POST I sometimes get a Plug and Play configuration error when the PMP array is plugged into a port. If I leave it unplugged until I get to GRUB, I can boot and see the drives and mount the array. This is the same card as I have been using throughout. If I forget and get the Plug and Play error, disconnecting the drives and resetting isn't enough, nor is power cycling *or* unplugging the machine. I have to physically remove the card and restart without it, power down and then re-insert it. I could only plug the card into a 32bit slot, btw. I have trouble believing that both alpha systems are somehow faulty does it happen that BIOSs store away any information about PCI devices? Thanks, ...tom I've attached the lspci/dmesg output from teh x86 in case that helps. Linux version 2.6.24-rc8 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #2 SMP Tue Jan 22 21:04:38 EST 2008 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 2ff9e000 (usable) BIOS-e820: 2ff9e000 - 3000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 0MB HIGHMEM available. 767MB LOWMEM available. found SMP MP-table at 000fe710 Entering add_active_range(0, 0, 196510) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 196510 HighMem196510 - 196510 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 - 196510 On node 0 totalpages: 196510 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1503 pages used for memmap Normal zone: 190911 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap Movable zone: 0 pages used for memmap DMI 2.3 present. ACPI: RSDP 000FD720, 0014 (r0 DELL ) ACPI: RSDT 000FD734, 002C (r1 DELLWS 420 8 ASL61) ACPI: FACP 000FD760, 0074 (r1 DELLWS 420 8 ASL61) ACPI: DSDT FFFE5000, 1B2F (r1 DELLdt_ex 1000 MSFT 10B) ACPI: FACS 2FF9E000, 0040 ACPI: APIC 000FD7D4, 0068 (r1 DELLWS 420 8 ASL61) ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 17 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 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[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, 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 4000 (gap: 3000:cec0) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 194975 Kernel command line: root=/dev/sdf1 ro single mapped APIC to b000 (fee0) mapped IOAPIC to a000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 931.005 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 770208k/786040k available (1699k kernel code, 15136k reserved, 694k data, 220k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfff4d000 - 0xf000 ( 712 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xf080 - 0xff7fe000 ( 239 MB) lowmem : 0xc000 - 0xeff9e000 ( 767 MB) .init : 0xc035e000 - 0xc0395000 ( 220 kB) .data : 0xc02a8f50 - 0xc0356a64 ( 694 kB) .text : 0xc010 - 0xc02a8f50 (1699 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 1863.46 BogoMIPS (lpj=3726929) Security Framework 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: 256K CPU: After all inits, caps:
Re: sata_sil24 / Alpha / 4726 PMP issue ..
I should have mentioned that in 1 of the failing logs, it finds the PMP device, that is rare, it usually doesn't even see it. That happened this morning and I was hopeful that somehow it was more meaningful than the usual case where it doesn't even notice the PMP. ...tom Thomas Evans wrote: I've attached a few logs - one that references how things looked when it all worked. I've logs of both the original Norco 4618 card (lspci64.2 and dmesg.txt.2) and with the newer generic 3124 card (dmesg.txt.newcard lspci.newcard.2). I'm not so good with deciphering the PCI-isms - maybe I just need a shorter cable now!? ...tom - 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 PMP support in 2.6.24-rc3?
I stopped seeing this message when I started using rc4. I upgraded to rc7 with your patch - the dmesg is attached. The link speed seems limited to 1.5Gbps now though, which hasn't been the case in rc3-rc6. ...tom -Original Message- From: Tejun Heo [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 08, 2008 4:28 AM To: Tom Evans Cc: Gaston, Jason D; linux-ide@vger.kernel.org Subject: Re: SATA PMP support in 2.6.24-rc3? Tom Evans wrote: I'm also seeing this with 2.6.23-rc3 on my Alpha system - sata_sil24 and a SiliconImage PMP. Gaston, Tom, can you guys please apply the attached patch on top of 2.6.24-rc7 and see whether the problem goes away. Thanks. -- Tejun [4194001.852669] Linux version 2.6.24-rc7-ds20 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #7 SMP Tue Jan 8 09:56:15 EST 2008 [4194001.852669] Booting on Tsunami variation Goldrush using machine vector DP264 from SRM [4194001.852669] Major Options: SMP LEGACY_START VERBOSE_MCHECK DISCONTIGMEM MAGIC_SYSRQ [4194001.852669] Command line: root=/dev/sda3 ide=reverse [4194001.852669] Raw memory layout: [4194001.852669] memcluster 0, usage 1, start0, end 256 [4194001.852669] memcluster 1, usage 0, start 256, end 130976 [4194001.852669] memcluster 2, usage 1, start 130976, end 131072 [4194001.852669] Initializing bootmem allocator on Node ID 0 [4194001.852669] memcluster 1, usage 0, start 256, end 130976 [4194001.852669] Detected node memory: start 258, end 130976 [4194001.852669] freeing pages 256:384 [4194001.852669] freeing pages 1255:130976 [4194001.852669] reserving pages 1255:1257 [4194001.852669] 4096K Bcache detected; load hit latency 20 cycles, load miss latency 107 cycles [4194001.852669] Console graphics on hose 0 [4194001.852669] SMP: 2 CPUs probed -- cpu_present_map = 3 [4194001.852669] On node 0 totalpages: 130976 [4194001.852669] DMA zone: 895 pages used for memmap [4194001.852669] DMA zone: 0 pages reserved [4194001.852669] DMA zone: 130081 pages, LIFO batch:15 [4194001.852669] Normal zone: 0 pages used for memmap [4194001.852669] Movable zone: 0 pages used for memmap [4194001.852669] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130081 [4194001.852669] Kernel command line: root=/dev/sda3 ide=reverse [4194001.852669] PID hash table entries: 4096 (order: 12, 32768 bytes) [4194001.852669] Using epoch = 1952 [4194001.856576] Console: colour VGA+ 80x25 [4194001.856576] console [tty0] enabled [4194001.861459] Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes) [4194001.863412] Inode-cache hash table entries: 65536 (order: 6, 524288 bytes) [4194001.909310] Memory: 1027192k/1045760k available (3339k kernel code, 17936k reserved, 243k data, 192k init) [4194001.910287] Calibrating delay loop... 996.00 BogoMIPS (lpj=486400) [4194001.928841] Mount-cache hash table entries: 512 [4194001.929818] SMP starting up secondaries. [4194001.936654] Calibrating delay loop... 996.00 BogoMIPS (lpj=486400) [4194001.955208] Brought up 2 CPUs [4194001.955208] SMP: Total of 2 processors activated (1998.25 BogoMIPS). [4194001.956185] net_namespace: 120 bytes [4194001.958138] xor: automatically using best checksumming function: alpha prefetch [4194001.963021]alpha prefetch: 2064.384 MB/sec [4194001.963021] xor: using function: alpha prefetch (2064.384 MB/sec) [4194001.963021] NET: Registered protocol family 16 [4194001.968880] PCI: Bridge: :00:08.0 [4194001.968880] IO window: 8000-8fff [4194001.968880] MEM window: 0980-098f [4194001.968880] PREFETCH window: 0990-099f [4194001.968880] SMC37c669 Super I/O Controller found @ 0x3f0 [4194001.972787] Linux Plug and Play Support v0.97 (c) Adam Belay [4194001.974740] SCSI subsystem initialized [4194001.974740] libata version 3.00 loaded. [4194001.980599] NET: Registered protocol family 2 [4194001.992318] IP route cache hash table entries: 8192 (order: 3, 65536 bytes) [4194001.993294] TCP established hash table entries: 32768 (order: 6, 524288 bytes) [4194001.994271] TCP bind hash table entries: 32768 (order: 6, 524288 bytes) [4194001.995248] TCP: Hash tables configured (established 32768 bind 32768) [4194001.996224] TCP reno registered [4194002.001107] srm_env: version 0.0.6 loaded successfully [4194002.003060] async_tx: api initialized (sync-only) [4194002.003060] io scheduler noop registered [4194002.003060] io scheduler anticipatory registered (default) [4194002.003060] io scheduler deadline registered [4194002.003060] isapnp: Scanning for PnP cards... [4194002.358529] isapnp: No Plug Play device found [4194002.478646] rtc: Digital UNIX epoch (1952) detected [4194002.479622] Real Time Clock Driver v1.12ac [4194002.479622] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled [4194002.479622] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [4194002.480599] serial8250: ttyS1 at
RE: sata_sil24 with port multiplier
Applied this patch to my 2.22.1 installation (alpha w/pcix 3124 card. The patch made a huge difference whenprobing devices at start. No 10 second retries followed by resets. ...tom -Original Message- From: Tejun Heo [EMAIL PROTECTED] Sent: Friday, September 21, 2007 6:55 AM To: Jon Chelton [EMAIL PROTECTED] Cc: linux-ide@vger.kernel.org Subject: Re: sata_sil24 with port multiplier Jon Chelton wrote: Hello, I am having issues using kernel 2.6.22.1 with your latest patch applied. I am using a Addonics 4 port SATA card with an external enclosure and port multiplier connected to 4 250GB western digital SATA drives. I am receiving this error frequently (on 2 systems with identical kernels and hardware). Does the attached patch fix the problem? -- 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
