Re: Marvell 7042 (sata_mv) fails to initialize drive
I have done some more testing, and it now looks as if this was actually a hardware fault. Reseating the PCI-E card made the problem go away (knock on wood). I am a little puzzled that it is possible for the card to show up on the PCI bus, and for the driver to be able to detect whether a disk is connected, but then for it to fail to communicate with the disk. But oh well, I guess if just some of the PCI-E signals aren't connected, strange error modes are to be expected. Sorry for the false alarm. And just for the record, if any you need any more testing done with 7042 controllers, feel free to ask me for help -- I think I read somewhere that Jeff was looking for testers that have access to this hardware. Markus - 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: Marvell 7042 (sata_mv) fails to initialize drive
Hi Markus, On 31/07/07, Markus Gutschke <[EMAIL PROTECTED]> wrote: > I just tried hooking up a Hitachi 1TB SATA-II drive to a Marvell 7042 > based controller, and the most recent Linux kernel (2.6.23-rc1) fails to > properly initialize the interface. Does 2.6.22.1 work? > Here are the relevant kernel messages: > > > kernel: [43.312417] sata_mv :06:00.0: version 0.81 > > kernel: [43.312752] ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16 > > kernel: [43.312757] ACPI: PCI Interrupt :06:00.0[A] -> Link [APC5] -> > > GSI 16 (level, low) -> IRQ 16 > > kernel: [43.312788] sata_mv :06:00.0: Applying 60X1C0 workarounds to > > unknown rev > > kernel: [43.314443] sata_mv :06:00.0: Gen-IIE 32 slots 4 ports SCSI > > mode IRQ via INTx > > kernel: [43.314535] scsi0 : sata_mv > > kernel: [43.314581] scsi1 : sata_mv > > kernel: [43.314614] scsi2 : sata_mv > > kernel: [43.314640] scsi3 : sata_mv > > kernel: [43.314660] ata1: SATA max UDMA/133 cmd 0x ctl > > 0xc20003522120 bmdma 0x irq 16 > > kernel: [43.314663] ata2: SATA max UDMA/133 cmd 0x ctl > > 0xc20003524120 bmdma 0x irq 16 > > kernel: [43.314666] ata3: SATA max UDMA/133 cmd 0x ctl > > 0xc20003526120 bmdma 0x irq 16 > > kernel: [43.314669] ata4: SATA max UDMA/133 cmd 0x ctl > > 0xc20003528120 bmdma 0x irq 16 > > kernel: [53.409086] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > > kernel: [59.741602] ata1: EH pending after completion, repeating EH (cnt=4) > > kernel: [59.777642] ata2: SATA link down (SStatus 0 SControl 300) > > kernel: [59.809752] ata3: SATA link down (SStatus 0 SControl 300) > > kernel: [59.841740] ata4: SATA link down (SStatus 0 SControl 300) > > The kernel never even registers the drive as an available disk device, > whereas everything appears to work fine, if I connect the disk to one of > the other controllers (JMicron AHCI, or NVidia sata_nv) on this motherboard. > > As I have two of those disks (in a RAID-1 array) and multiple > independent controllers, it is relatively easy for me to do some testing > here. The worst case scenario is that I need to wait a couple of hours > for the array to rebuild itself after I am done experimenting. > > Let me know, if there is anything I can do to help you diagnose the root > cause, or whether this is a known bug and you don't need any help > testing at this point. > > > Markus Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: Marvell 7042 (sata_mv) fails to initialize drive
Hi Markus, On 31/07/07, Markus Gutschke [EMAIL PROTECTED] wrote: I just tried hooking up a Hitachi 1TB SATA-II drive to a Marvell 7042 based controller, and the most recent Linux kernel (2.6.23-rc1) fails to properly initialize the interface. Does 2.6.22.1 work? Here are the relevant kernel messages: kernel: [43.312417] sata_mv :06:00.0: version 0.81 kernel: [43.312752] ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16 kernel: [43.312757] ACPI: PCI Interrupt :06:00.0[A] - Link [APC5] - GSI 16 (level, low) - IRQ 16 kernel: [43.312788] sata_mv :06:00.0: Applying 60X1C0 workarounds to unknown rev kernel: [43.314443] sata_mv :06:00.0: Gen-IIE 32 slots 4 ports SCSI mode IRQ via INTx kernel: [43.314535] scsi0 : sata_mv kernel: [43.314581] scsi1 : sata_mv kernel: [43.314614] scsi2 : sata_mv kernel: [43.314640] scsi3 : sata_mv kernel: [43.314660] ata1: SATA max UDMA/133 cmd 0x ctl 0xc20003522120 bmdma 0x irq 16 kernel: [43.314663] ata2: SATA max UDMA/133 cmd 0x ctl 0xc20003524120 bmdma 0x irq 16 kernel: [43.314666] ata3: SATA max UDMA/133 cmd 0x ctl 0xc20003526120 bmdma 0x irq 16 kernel: [43.314669] ata4: SATA max UDMA/133 cmd 0x ctl 0xc20003528120 bmdma 0x irq 16 kernel: [53.409086] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) kernel: [59.741602] ata1: EH pending after completion, repeating EH (cnt=4) kernel: [59.777642] ata2: SATA link down (SStatus 0 SControl 300) kernel: [59.809752] ata3: SATA link down (SStatus 0 SControl 300) kernel: [59.841740] ata4: SATA link down (SStatus 0 SControl 300) The kernel never even registers the drive as an available disk device, whereas everything appears to work fine, if I connect the disk to one of the other controllers (JMicron AHCI, or NVidia sata_nv) on this motherboard. As I have two of those disks (in a RAID-1 array) and multiple independent controllers, it is relatively easy for me to do some testing here. The worst case scenario is that I need to wait a couple of hours for the array to rebuild itself after I am done experimenting. Let me know, if there is anything I can do to help you diagnose the root cause, or whether this is a known bug and you don't need any help testing at this point. Markus Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: Marvell 7042 (sata_mv) fails to initialize drive
I have done some more testing, and it now looks as if this was actually a hardware fault. Reseating the PCI-E card made the problem go away (knock on wood). I am a little puzzled that it is possible for the card to show up on the PCI bus, and for the driver to be able to detect whether a disk is connected, but then for it to fail to communicate with the disk. But oh well, I guess if just some of the PCI-E signals aren't connected, strange error modes are to be expected. Sorry for the false alarm. And just for the record, if any you need any more testing done with 7042 controllers, feel free to ask me for help -- I think I read somewhere that Jeff was looking for testers that have access to this hardware. Markus - 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/
Marvell 7042 (sata_mv) fails to initialize drive
I just tried hooking up a Hitachi 1TB SATA-II drive to a Marvell 7042 based controller, and the most recent Linux kernel (2.6.23-rc1) fails to properly initialize the interface. Here are the relevant kernel messages: kernel: [43.312417] sata_mv :06:00.0: version 0.81 kernel: [43.312752] ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16 kernel: [43.312757] ACPI: PCI Interrupt :06:00.0[A] -> Link [APC5] -> GSI 16 (level, low) -> IRQ 16 kernel: [43.312788] sata_mv :06:00.0: Applying 60X1C0 workarounds to unknown rev kernel: [43.314443] sata_mv :06:00.0: Gen-IIE 32 slots 4 ports SCSI mode IRQ via INTx kernel: [43.314535] scsi0 : sata_mv kernel: [43.314581] scsi1 : sata_mv kernel: [43.314614] scsi2 : sata_mv kernel: [43.314640] scsi3 : sata_mv kernel: [43.314660] ata1: SATA max UDMA/133 cmd 0x ctl 0xc20003522120 bmdma 0x irq 16 kernel: [43.314663] ata2: SATA max UDMA/133 cmd 0x ctl 0xc20003524120 bmdma 0x irq 16 kernel: [43.314666] ata3: SATA max UDMA/133 cmd 0x ctl 0xc20003526120 bmdma 0x irq 16 kernel: [43.314669] ata4: SATA max UDMA/133 cmd 0x ctl 0xc20003528120 bmdma 0x irq 16 kernel: [53.409086] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) kernel: [59.741602] ata1: EH pending after completion, repeating EH (cnt=4) kernel: [59.777642] ata2: SATA link down (SStatus 0 SControl 300) kernel: [59.809752] ata3: SATA link down (SStatus 0 SControl 300) kernel: [59.841740] ata4: SATA link down (SStatus 0 SControl 300) The kernel never even registers the drive as an available disk device, whereas everything appears to work fine, if I connect the disk to one of the other controllers (JMicron AHCI, or NVidia sata_nv) on this motherboard. As I have two of those disks (in a RAID-1 array) and multiple independent controllers, it is relatively easy for me to do some testing here. The worst case scenario is that I need to wait a couple of hours for the array to rebuild itself after I am done experimenting. Let me know, if there is anything I can do to help you diagnose the root cause, or whether this is a known bug and you don't need any help testing at this point. Markus - 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/
Marvell 7042 (sata_mv) fails to initialize drive
I just tried hooking up a Hitachi 1TB SATA-II drive to a Marvell 7042 based controller, and the most recent Linux kernel (2.6.23-rc1) fails to properly initialize the interface. Here are the relevant kernel messages: kernel: [43.312417] sata_mv :06:00.0: version 0.81 kernel: [43.312752] ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16 kernel: [43.312757] ACPI: PCI Interrupt :06:00.0[A] - Link [APC5] - GSI 16 (level, low) - IRQ 16 kernel: [43.312788] sata_mv :06:00.0: Applying 60X1C0 workarounds to unknown rev kernel: [43.314443] sata_mv :06:00.0: Gen-IIE 32 slots 4 ports SCSI mode IRQ via INTx kernel: [43.314535] scsi0 : sata_mv kernel: [43.314581] scsi1 : sata_mv kernel: [43.314614] scsi2 : sata_mv kernel: [43.314640] scsi3 : sata_mv kernel: [43.314660] ata1: SATA max UDMA/133 cmd 0x ctl 0xc20003522120 bmdma 0x irq 16 kernel: [43.314663] ata2: SATA max UDMA/133 cmd 0x ctl 0xc20003524120 bmdma 0x irq 16 kernel: [43.314666] ata3: SATA max UDMA/133 cmd 0x ctl 0xc20003526120 bmdma 0x irq 16 kernel: [43.314669] ata4: SATA max UDMA/133 cmd 0x ctl 0xc20003528120 bmdma 0x irq 16 kernel: [53.409086] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) kernel: [59.741602] ata1: EH pending after completion, repeating EH (cnt=4) kernel: [59.777642] ata2: SATA link down (SStatus 0 SControl 300) kernel: [59.809752] ata3: SATA link down (SStatus 0 SControl 300) kernel: [59.841740] ata4: SATA link down (SStatus 0 SControl 300) The kernel never even registers the drive as an available disk device, whereas everything appears to work fine, if I connect the disk to one of the other controllers (JMicron AHCI, or NVidia sata_nv) on this motherboard. As I have two of those disks (in a RAID-1 array) and multiple independent controllers, it is relatively easy for me to do some testing here. The worst case scenario is that I need to wait a couple of hours for the array to rebuild itself after I am done experimenting. Let me know, if there is anything I can do to help you diagnose the root cause, or whether this is a known bug and you don't need any help testing at this point. Markus - 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/
