[PATCH] Maxtor 6B250S0/BANC1B70 hangs with NCQ

2007-03-30 Thread Jens Axboe
Hi, I've seen this several times on this drive, completely reproducible. Once it has hung, power needs to be cut from the drive to recover it, a simple reboot is not enough. So I'd suggest disabling NCQ on this driver. Error log attached. Signed-off-by: Jens Axboe [EMAIL PROTECTED] diff --git

Re: [PATCH] Maxtor 6B250S0/BANC1B70 hangs with NCQ

2007-03-30 Thread Tejun Heo
Jens Axboe wrote: Hi, I've seen this several times on this drive, completely reproducible. Once it has hung, power needs to be cut from the drive to recover it, a simple reboot is not enough. So I'd suggest disabling NCQ on this driver. Error log attached. Signed-off-by: Jens Axboe

Libata disk corruptor paths ?

2007-03-30 Thread Alan Cox
Found these by inspection: Command issuing goes via ata_qc_reinit() which sets up the device bits for the command to include the device select bit. If we are using NCQ then the code in ata_build_rw_tf sets bit 6 directly without using |= which clears the device select bit and means any NCQ

Re: Libata disk corruptor paths ?

2007-03-30 Thread Alan Cox
There is another ugly here too ata_tf_init sets the device bits but doesn't set TFLAG_DEVICE. Scarily in fact the qc_reinit path that Argh ignore this part - I meant to delete it as the tf structure is memset to zero. The other case I believe is a genuine bug however - To unsubscribe from this

[RFD driver-core] Lifetime problems of the current driver model

2007-03-30 Thread Tejun Heo
Hello, all. This document tries to describe lifetime problems of the current device driver model primarily from the point view of device drivers and establish consensus, or at least, start discussion about how to solve these problems. This is primarily based on my experience with IDE and SCSI

Re: [RFD driver-core] Lifetime problems of the current driver model

2007-03-30 Thread James Bottomley
On Fri, 2007-03-30 at 18:43 +0900, Tejun Heo wrote: Orphaning sysfs nodes on unregistration is a big step in this direction. With sysfs reference counting out of the picture, implementing 'disconnect immediate' interface only on a few components (including request_queue) should suffice for

Re: [RFD driver-core] Lifetime problems of the current driver model

2007-03-30 Thread Dmitry Torokhov
Hi James, On 3/30/07, James Bottomley [EMAIL PROTECTED] wrote: On Fri, 2007-03-30 at 18:43 +0900, Tejun Heo wrote: Orphaning sysfs nodes on unregistration is a big step in this direction. With sysfs reference counting out of the picture, implementing 'disconnect immediate' interface only on

Re: [RFD driver-core] Lifetime problems of the current driver model

2007-03-30 Thread Cornelia Huck
On Fri, 30 Mar 2007 18:43:02 +0900, Tejun Heo [EMAIL PROTECTED] wrote: One way to solve this problem is to subordinate lifetime rule #b to rule #c. Each kobject points to its owning module such that grabbing a kobject automatically grabs the module. The problem with this approach is that it

Re: [RFD driver-core] Lifetime problems of the current driver model

2007-03-30 Thread Tejun Heo
Cornelia Huck wrote: On Fri, 30 Mar 2007 18:43:02 +0900, Tejun Heo [EMAIL PROTECTED] wrote: One way to solve this problem is to subordinate lifetime rule #b to rule #c. Each kobject points to its owning module such that grabbing a kobject automatically grabs the module. The problem with

Re: [RFD driver-core] Lifetime problems of the current driver model

2007-03-30 Thread Tejun Heo
James Bottomley wrote: On Fri, 2007-03-30 at 18:43 +0900, Tejun Heo wrote: Orphaning sysfs nodes on unregistration is a big step in this direction. With sysfs reference counting out of the picture, implementing 'disconnect immediate' interface only on a few components (including

Re: [RFD driver-core] Lifetime problems of the current driver model

2007-03-30 Thread Tejun Heo
Cornelia Huck wrote: On Fri, 30 Mar 2007 22:19:52 +0900, Tejun Heo [EMAIL PROTECTED] wrote: Shouldn't getting/putting the module refcount be solely done in kobject.c? Grab the module reference when the kobject is created and release the module reference in kobject_cleanup() after the

Re: [RFD driver-core] Lifetime problems of the current driver model

2007-03-30 Thread Cornelia Huck
On Fri, 30 Mar 2007 22:58:39 +0900, Tejun Heo [EMAIL PROTECTED] wrote: It's a little bit more convoluted than that. Module reference count of zero doesn't indicate that there is no one referencing the module. It just means that the module can be unloaded. ie. There still can be any number

Re: [RFD driver-core] Lifetime problems of the current driver model

2007-03-30 Thread Tejun Heo
Cornelia Huck wrote: On Fri, 30 Mar 2007 22:58:39 +0900, Tejun Heo [EMAIL PROTECTED] wrote: It's a little bit more convoluted than that. Module reference count of zero doesn't indicate that there is no one referencing the module. It just means that the module can be unloaded. ie. There

Re: [RFD driver-core] Lifetime problems of the current driver model

2007-03-30 Thread Dmitry Torokhov
On 3/30/07, James Bottomley [EMAIL PROTECTED] wrote: On Fri, 2007-03-30 at 09:15 -0400, Dmitry Torokhov wrote: If you want to manage lifetime rules independently you might want to not embed struct device into you subsystems objects but attach them via pointers and use device_create(). Now

Re: [RFD driver-core] Lifetime problems of the current driver model

2007-03-30 Thread James Bottomley
On Fri, 2007-03-30 at 22:38 +0900, Tejun Heo wrote: My plan was to make sysfs more independent from struct device/kobject. e.g. Something like the following. That's sort of what I was reaching for too ... it just looks to me that all the sysfs glue is in kobject, so they make a good candidate

Re: [RFD driver-core] Lifetime problems of the current driver model

2007-03-30 Thread Cornelia Huck
On Sat, 31 Mar 2007 00:08:19 +0900, Tejun Heo [EMAIL PROTECTED] wrote: (3) make sure all existing kobjects are released by module exit function. For example, let's say there is a hypothetical disk device /dev/dk0 driven by a hypothetical driver mydrv. /dev/dk0 is represented like the

Re: [1/4] 2.6.21-rc5: known regressions (v2)

2007-03-30 Thread Greg KH
On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote: Subject: hung bootup in various drivers References : http://lkml.org/lkml/2007/3/30/68 Submitter : Ingo Molnar [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Greg KH [EMAIL PROTECTED]

[3/4] 2.6.21-rc5: known regressions (v2)

2007-03-30 Thread Adrian Bunk
This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly

Re: [1/4] 2.6.21-rc5: known regressions (v2)

2007-03-30 Thread Michal Jaegermann
On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote: Subject: kernels fail to boot with drives on ATIIXP controller (ACPI/IRQ related) References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 http://lkml.org/lkml/2007/3/4/257 Submitter

Re: [RFD driver-core] Lifetime problems of the current driver model

2007-03-30 Thread Tejun Heo
Cornelia Huck wrote: On Sat, 31 Mar 2007 00:08:19 +0900, Tejun Heo [EMAIL PROTECTED] wrote: (3) make sure all existing kobjects are released by module exit function. For example, let's say there is a hypothetical disk device /dev/dk0 driven by a hypothetical driver mydrv. /dev/dk0 is

Re: [3/4] 2.6.21-rc5: known regressions (v2)

2007-03-30 Thread Jeff Chua
On 3/31/07, Adrian Bunk [EMAIL PROTECTED] wrote: Subject: ThinkPad doesn't resume from suspend to RAM References : http://lkml.org/lkml/2007/2/27/80 http://lkml.org/lkml/2007/2/28/348 Submitter : Jens Axboe [EMAIL PROTECTED] Jeff Chua [EMAIL PROTECTED] Status

Re: [RFD driver-core] Lifetime problems of the current driver model

2007-03-30 Thread Tejun Heo
Tejun Heo wrote: Cornelia Huck wrote: On Sat, 31 Mar 2007 00:08:19 +0900, Tejun Heo [EMAIL PROTECTED] wrote: (3) make sure all existing kobjects are released by module exit function. For example, let's say there is a hypothetical disk device /dev/dk0 driven by a hypothetical driver mydrv.

Re: libata bugfix: preserve LBA bit for HDIO_DRIVE_TASK

2007-03-30 Thread Tejun Heo
Mark Lord wrote: Ideally, this would go into linux-2.6.21. Preserve the LBA bit in the DevSel/Head register for HDIO_DRIVE_TASK. Signed-off-by: Mark Lord [EMAIL PROTECTED] --- --- linux/drivers/ata/libata-scsi.c.orig2007-03-21 13:35:02.0 -0400 +++