Albert Lee wrote:
Hi Yarema,
Thanks for the detailed log.
It looks like the bad INQUIRY command
CDB (4:0,1,0) 12 01 00 00 fe 00 00 00 00 (INQUIRY, length=254, EVPD=1)
is coming from the user space, not the SCSI mid-layer.
I guess two problems together caused this bug:
1. Ubuntu Linux
Kristen Carlson Accardi wrote:
Hi, I upgrade a machine from 2.6.20-2.6.21-rc4 and am now having problems
with my ATAPI device getting detected properly. Back tracking to 2.6.21-rc1,
I find the problem existed there too, but not in 2.6.20.
Please post boot dmesg of 2.6.20. Is your ATAPI
We have two possible solutions here:
a. Patch Ubuntu, such that the incorrect INQUIRY is fixed.
b. Patch kernel, such that the AOpen drives are blacklisted.
Each INQUIRY is inspected for the blacklisted drives.
If the INQUIRY looks wrong, the INQUIRY is rejected.
I guess a. is the
When booting a gnu/linux distribution's install-cd i noticed that the included
[1]kernel (2.6.20.3) would not probe/find my jmicron connected sata-dvd.
My own [2]kernel-configuration finds the drive just fine but the distributor's
kernel with all sorts of drivers built-in wont. If i connect the
For drive side cable detection to work correctly, drives need to be
identified backwards such that the slave device releases PDIAG- before
the mater drive tries to detect cable type. ata_bus_probe() was fixed
by commit f31f0cc2f0b7527072d94d02da332d9bb8d7d94c but the new EH path
wasn't fixed.
On Thu, 22 Mar 2007 22:24:19 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
For drive side cable detection to work correctly, drives need to be
identified backwards such that the slave device releases PDIAG- before
the mater drive tries to detect cable type. ata_bus_probe() was fixed
by commit
Hello.
Albert Lee wrote:
Thanks for the detailed log.
It looks like the bad INQUIRY command
CDB (4:0,1,0) 12 01 00 00 fe 00 00 00 00 (INQUIRY, length=254, EVPD=1)
is coming from the user space, not the SCSI mid-layer.
I guess two problems together caused this bug:
1. Ubuntu Linux issues
Alan Cox wrote:
On Thu, 22 Mar 2007 22:24:19 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
For drive side cable detection to work correctly, drives need to be
identified backwards such that the slave device releases PDIAG- before
the mater drive tries to detect cable type. ata_bus_probe() was
Hi Tejun,
JFYI, it turns out that spurious interrupts was caused by User Scan
before drive is ready. I wait for 2 seconds after drive is powered on
which is not sufficient for some drives. Alt status should be checked
first but there's no good way to check it in user space. Does User
Scan
On Thu, Mar 22, 2007 at 03:44:58PM +0900, Tejun Heo wrote:
Lukas Hejtmanek wrote:
Subject: ata_piix: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294
Submitter : Fabio Comolli [EMAIL PROTECTED]
Status : patch exists
Does this fix your
This is a uniprocessor AMD64 system running software RAID-5 and RAID-10
over multiple PCIe SiI3132 SATA controllers. The hardware has been very
stable for a long time, but has been acting up of late since I upgraded
to 2.6.20.3. ECC memory should preclude the possibility of bit-flip
errors.
This is a uniprocessor AMD64 system running software RAID-5 and RAID-10
over multiple PCIe SiI3132 SATA controllers. The hardware has been very
stable for a long time, but has been acting up of late since I upgraded
to 2.6.20.3. ECC memory should preclude the possibility of bit-flip
errors.
On Thu, Mar 22 2007, [EMAIL PROTECTED] wrote:
This is a uniprocessor AMD64 system running software RAID-5 and RAID-10
over multiple PCIe SiI3132 SATA controllers. The hardware has been very
stable for a long time, but has been acting up of late since I upgraded
to 2.6.20.3. ECC memory should
How can this compile error be fixed properly?
request_queue_t is inside CONFIG_BLOCK,
ide_drive_s (and likely others) use it unconditionally.
CC arch/powerpc/kernel/setup_64.o
In file included from linux-2.6.21-rc4/arch/powerpc/kernel/setup_64.c:23:
On Thu, Mar 22, 2007 at 10:52:34PM +0100, Olaf Hering wrote:
How can this compile error be fixed properly?
request_queue_t is inside CONFIG_BLOCK,
ide_drive_s (and likely others) use it unconditionally.
CC arch/powerpc/kernel/setup_64.o
In file included from
Tejun Heo wrote:
Hello, Douglas.
Douglas Gilbert wrote:
Tejun,
I note at this point that the IMMED bit in the
START STOP UNIT cdb is clear. [The code might
note that as well.] All SCSI disks that I have
seen, implement the IMMED bit and according to
the SAT standard, so should SAT layers like
On Thu, 22 Mar 2007, Vladislav Bolkhovitin wrote:
Seems, there is another way of doing a bank spin up / spin down: doing
it in two passes. On the first pass START_STOP will be issued with
IMMED=1 on all devices, then on the second pass START_STOP will be
issued with IMMED=0. So the devices
Henrique de Moraes Holschuh wrote:
On Thu, 22 Mar 2007, Vladislav Bolkhovitin wrote:
Seems, there is another way of doing a bank spin up / spin down: doing
it in two passes. On the first pass START_STOP will be issued with
IMMED=1 on all devices, then on the second pass START_STOP will be
Sergei Shtylyov wrote:
Hello.
Albert Lee wrote:
Thanks for the detailed log.
It looks like the bad INQUIRY command
CDB (4:0,1,0) 12 01 00 00 fe 00 00 00 00 (INQUIRY, length=254,
EVPD=1)
is coming from the user space, not the SCSI mid-layer.
I guess two problems together caused
Alan Cox wrote:
We have two possible solutions here:
a. Patch Ubuntu, such that the incorrect INQUIRY is fixed.
b. Patch kernel, such that the AOpen drives are blacklisted.
Each INQUIRY is inspected for the blacklisted drives.
If the INQUIRY looks wrong, the INQUIRY is rejected.
I guess a.
On Thu, Mar 22, Christoph Hellwig wrote:
On Thu, Mar 22, 2007 at 10:52:34PM +0100, Olaf Hering wrote:
How can this compile error be fixed properly?
request_queue_t is inside CONFIG_BLOCK,
ide_drive_s (and likely others) use it unconditionally.
CC
21 matches
Mail list logo
