sata_nv times out for BD-ROM iHOS104-08
in [Kernel]
|
Prev: block: add a new flag to make request complete on submitted cpu
Next: [PATCH 01/25] x86: fix size for ex trampoline with 32bit
From: Ozan Çağlayan on 17 Jan 2010 10:30 Cengiz Günay wrote: > 2009/12/24 Tejun Heo <tj(a)kernel.org>: >> I don't think the controller has anything to do with the issue but >> just in case can you please try it with a different controller? > > I tried the iHOS BD-ROM with a VIA VT6412 SATA controller today and it worked: > I don't have the possibility to try with another controller but exactly the same issue with PIONEER DVD-RW DVRKD08RS: [ 4.618380] ata1.00: ATAPI: PIONEER DVD-RW DVRKD08RS, 1.02, max UDMA/33 [ 4.618447] ata1: nv_mode_filter: 0x739f&0x739f->0x739f, BIOS=0x7000 (0xc000c700) ACPI=0x701f (60:600:0x13) [ 4.625131] ata1.00: configured for UDMA/33 [ 4.625214] ata1.00: TEST_UNIT_READY failed (err_mask=0x2) [ 4.838039] usb 3-2: new low speed USB device using ohci_hcd and address 2 [ 4.909709] input: PS/2 Mouse as /devices/platform/i8042/serio1/input/input6 [ 4.944821] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input7 [ 5.000029] Clocksource tsc unstable (delta = -254057140 ns) [ 5.027063] usb 3-2: New USB device found, idVendor=05e3, idProduct=1205 [ 5.027071] usb 3-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 5.027078] usb 3-2: Product: USB Mouse [ 5.027199] usb 3-2: configuration #1 chosen from 1 choice [ 5.037758] input: USB Mouse as /devices/pci0000:00/0000:00:02.0/usb3/3-2/3-2:1.0/input/input8 [ 5.037936] generic-usb 0003:05E3:1205.0001: input,hidraw0: USB HID v1.10 Mouse [USB Mouse ] on usb-0000:00:02.0-2/input0 [ 5.708253] ieee1394: Host added: ID:BUS[0-00:1023] GUID[00023f7cba403d32] [ 9.769407] ata1: nv_mode_filter: 0x739f&0x739f->0x739f, BIOS=0x7000 (0xc000c700) ACPI=0x701f (60:600:0x13) [ 9.775326] ata1.00: configured for UDMA/33 [ 9.775408] ata1.00: TEST_UNIT_READY failed (err_mask=0x2) [ 9.775417] ata1.00: limiting speed to UDMA/33:PIO3 [ 14.920401] ata1: nv_mode_filter: 0x738f&0x739f->0x738f, BIOS=0x7000 (0xc000c700) ACPI=0x701f (60:600:0x13) [ 14.926332] ata1.00: configured for UDMA/33 [ 14.926412] ata1.00: TEST_UNIT_READY failed (err_mask=0x2) [ 14.926418] ata1.00: disabled [ 14.926452] ata1: soft resetting link [ 15.077100] ata1: EH complete [ 15.077155] ata2: port disabled. ignoring. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 19 Jan 2010 04:10 Hello, On 01/18/2010 12:28 AM, Ozan Çağlayan wrote: > [ 9.769407] ata1: nv_mode_filter: 0x739f&0x739f->0x739f, BIOS=0x7000 (0xc000c700) ACPI=0x701f (60:600:0x13) > [ 9.775326] ata1.00: configured for UDMA/33 > [ 9.775408] ata1.00: TEST_UNIT_READY failed (err_mask=0x2) Hmmm... err_mask=0x2 is HSM error. Strange. Does the attached patch make any difference? Thanks. -- tejun
From: Ozan Çağlayan on 19 Jan 2010 04:40 Tejun Heo wrote: > Hello, > > On 01/18/2010 12:28 AM, Ozan Çağlayan wrote: >> [ 9.769407] ata1: nv_mode_filter: 0x739f&0x739f->0x739f, BIOS=0x7000 (0xc000c700) ACPI=0x701f (60:600:0x13) >> [ 9.775326] ata1.00: configured for UDMA/33 >> [ 9.775408] ata1.00: TEST_UNIT_READY failed (err_mask=0x2) > > Hmmm... err_mask=0x2 is HSM error. Strange. Does the attached patch > make any difference? Hi, He reported back that after a few reboots its now working correctly. Actually the behaviour is a little bit random as he succesfully installed the OS from a CD without losing its DVD drive. I'll keep a patched kernel and send to him for testing if the bug reappears. Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 19 Jan 2010 21:10 Hello, Cengiz. On 01/17/2010 06:34 AM, Cengiz Günay wrote: > 2009/12/24 Tejun Heo <tj(a)kernel.org>: >> I don't think the controller has anything to do with the issue but >> just in case can you please try it with a different controller? > > I tried the iHOS BD-ROM with a VIA VT6412 SATA controller today and it worked: Hmm.... it worked? Does kernel parameter sata_nv.adma_enabled=0 make any difference? Can you please attach boot log with the kernel parameter specified? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 19 Jan 2010 22:00
2010/1/19 Tejun Heo <tj(a)kernel.org>: > Hello, Cengiz. > > On 01/17/2010 06:34 AM, Cengiz G�nay wrote: >> 2009/12/24 Tejun Heo <tj(a)kernel.org>: >>> I don't think the controller has anything to do with the issue but >>> just in case can you please try it with a different controller? >> >> I tried the iHOS BD-ROM with a VIA VT6412 SATA controller today and it worked: > > Hmm.... it worked? �Does kernel parameter sata_nv.adma_enabled=0 make > any difference? �Can you please attach boot log with the kernel > parameter specified? Think you meant maybe sata_nv.swncq=0 instead - this is an MCP51 controller so it doesn't support ADMA. I don't imagine SWNCQ would make any difference with an ATAPI device, but wouldn't hurt to try. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |