Re: [Bugme-new] [Bug 9674] New: Oops during rmmod'ing modeuls sdhci, sr_mod, ricoh_mmc, mmc_core
On Wednesday, 2 of January 2008, James Bottomley wrote: On Tue, 2008-01-01 at 18:10 -0800, Andrew Morton wrote: On Tue, 1 Jan 2008 14:55:45 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9674 Summary: Oops during rmmod'ing modeuls sdhci, sr_mod, ricoh_mmc, mmc_core Guys, this is a very recent regression. Could you please take a look, see if it's due to mmc, block or scsi changes? There's not a lot of information to go on. The stack trace looks bogus, so I guess the kernel is compiled without a frame pointer. The bug report has been updated with a stack trace from a kernel compiled with a frame pointer. Please have a look. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Maybe Sorry for that but where should i write .)
Actually, the correct mailing list is linux-ide. Alan Cox began working on the driver. Cc'ing both. Unless I get further info from Initio I don't expect anything to happen. They simply don't provide enough info to write a driver. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9674] New: Oops during rmmod'ing modeuls sdhci, sr_mod, ricoh_mmc, mmc_core
On Wed, 2008-01-02 at 13:21 +0100, Rafael J. Wysocki wrote: On Wednesday, 2 of January 2008, James Bottomley wrote: On Tue, 2008-01-01 at 18:10 -0800, Andrew Morton wrote: On Tue, 1 Jan 2008 14:55:45 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9674 Summary: Oops during rmmod'ing modeuls sdhci, sr_mod, ricoh_mmc, mmc_core Guys, this is a very recent regression. Could you please take a look, see if it's due to mmc, block or scsi changes? There's not a lot of information to go on. The stack trace looks bogus, so I guess the kernel is compiled without a frame pointer. The bug report has been updated with a stack trace from a kernel compiled with a frame pointer. Please have a look. Please, please don't do this. Filing something in bugzilla is tantamount to putting it in the file and forget folder. The reason I cc'd the SCSI mailing list and asked for more details is so that we get the email flow that might trigger direct interaction between the reporter and someone on the list who recognised the symptoms. Let me say again, catagorically, that if you want to give a bug the best chance of being fixed, the correct flow of information is: file a bugzilla and note the bugid. Then email a complete report to the relevant list, but add [BUG bugid] to the subject line and cc [EMAIL PROTECTED] If you do this, bugzilla will keep track of the entire discussion as it progresses and allow those who track bugs through bugzilla to get a pretty accurate idea of the status. You should never need to touch bugzilla again once the initial bug report is filed: all future information flow is via the mailing lists. Also, using urls unless for historical purposes is also a killer. Many people travel, and their MO is to download the email and read it on the plane/train/whatever. If you embed a url containing critical information, the email gets marked as read, but since I can't get to the information, nothing happens. Then it gets forgotten. This is the relevant piece of information that should have been on the mailing list: [ 101.359083] Unable to handle kernel paging request at 88021cc0 RIP: [ 101.359092] [88021cc0] [ 101.359099] PGD 203067 PUD 207063 PMD 3d34a067 PTE 0 [ 101.359108] Oops: 0010 [1] PREEMPT SMP [ 101.359115] CPU 0 [ 101.359118] Modules linked in: sr_mod tcp_westwood ipt_REJECT xt_state iptable_filter ipt_owner ipt_MASQUERADE xt_tcpudp xt_multiport iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables iwl3945 ricoh_mmc cdrom [ 101.359150] Pid: 4496, comm: modprobe Not tainted 2.6.24-rc6-git7 #5 [ 101.359154] RIP: 0010:[88021cc0] [88021cc0] [ 101.359159] RSP: 0018:81002b457970 EFLAGS: 00010086 [ 101.359163] RAX: 88021cc0 RBX: 81003f1627e0 RCX: 81003f023b38 [ 101.359167] RDX: RSI: 810030efd000 RDI: 81003f1627e0 [ 101.359171] RBP: 81002b4579b8 R08: 0001 R09: 0001 [ 101.359175] R10: R11: R12: 810030efd000 [ 101.359179] R13: 81002b457988 R14: 0010 R15: 00010010 [ 101.359185] FS: 2adcf7ea0b00() GS:80733000() knlGS: [ 101.359189] CS: 0010 DS: ES: CR0: 8005003b [ 101.359193] CR2: 88021cc0 CR3: 2b497000 CR4: 06e0 [ 101.359197] DR0: DR1: DR2: [ 101.359201] DR3: DR6: 0ff0 DR7: 0400 [ 101.359206] Process modprobe (pid: 4496, threadinfo 81002b456000, task 81003de1ef50) [ 101.359210] Stack: 80333a98 0086 81003f023af8 810030efd000 [ 101.359221] 81003f1627e0 81003f023800 81003e31c000 81003f1627e0 [ 101.359230] 81002b457a08 803fe7e1 81003f023b38 [ 101.359237] Call Trace: [ 101.359248] [80333a98] elv_next_request+0xe8/0x180 [ 101.359256] [803fe7e1] scsi_request_fn+0x71/0x380 [ 101.359264] [803375b8] __generic_unplug_device+0x28/0x30 [ 101.359270] [80337623] blk_execute_rq_nowait+0x63/0xb0 [ 101.359276] [80339113] blk_execute_rq+0x73/0xe0 [ 101.359283] [80337775] get_request_wait+0x25/0x120 [ 101.359288] [80337896] blk_get_request+0x26/0x80 [ 101.359296] [803fe5b2] scsi_execute+0xe2/0x110 [ 101.359301] [803fe661] scsi_execute_req+0x81/0xf0 [ 101.359312] [8800d713] :sr_mod:sr_probe+0x1e3/0x630 [ 101.359323] [803c8d01] driver_probe_device+0xa1/0x1c0 [ 101.359329] [803c8ff5] __driver_attach+0xe5/0xf0 [ 101.359334] [803c8f10] __driver_attach+0x0/0xf0 [ 101.359342] [803c7ee3] bus_for_each_dev+0x53/0x80 [ 101.359348] [803c8b3c] driver_attach+0x1c/0x20 [ 101.359353] [803c8305]
Re: [Bugme-new] [Bug 9674] New: Oops during rmmod'ing modeuls sdhci, sr_mod, ricoh_mmc, mmc_core
On Wed, 2008-01-02 at 10:49 -0500, Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Tue, 01 Jan 2008 21:24 -0600:
On Tue, 2008-01-01 at 18:10 -0800, Andrew Morton wrote:
On Tue, 1 Jan 2008 14:55:45 -0800 (PST) [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9674
Summary: Oops during rmmod'ing modeuls sdhci, sr_mod,
ricoh_mmc,
mmc_core
Guys, this is a very recent regression. Could you please take a look, see
if it's due to mmc, block or scsi changes?
There's not a lot of information to go on. The stack trace looks bogus,
so I guess the kernel is compiled without a frame pointer. However, it
does look like the initial insertion of sr_mod is going through and it
generates a command which gets into scsi_request_fn and then indirects
through a bogus queueucommand pointer.
Bogus prep_rq_fn actually.
What's the actual underlying device the cdrom is attached to?
There's no real changes to SCSI in this area from 2.6.24-rc4 ...
however, the reinsertion is suggestive, it's like the removal is
retriggering a module request for some reason.
Here's a guess. When sr_mod is removed, it looks like the request
queue prep_rq_fn is still pointing to the now nonexistent
sr_prep_fn. This may have been due to a commit that went in early
2.6.24:
commit 7f9a6bc4e9d59e7fcf03ed23f60cd81ca5d80b65
Author: James Bottomley [EMAIL PROTECTED]
Date: Sat Aug 4 10:06:25 2007 -0500
[SCSI] move ULD attachment into the prep function
One of the intents of the block prep function was to allow ULDs to use
it for preprocessing. The original SCSI model was to have a single prep
function and add a pointer indirect filter to build the necessary
commands. This patch reverses that, does away with the init_command
field of the scsi_driver structure and makes ULDs attach directly to the
prep function instead. The value is really that it allows us to begin
to separate the ULDs from the SCSI mid layer (as long as they don't use
any core functions---which is hard at the moment---a ULD doesn't even
need SCSI to bind).
Acked-by: Jens Axboe [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
When the module is re-inserted, it does a few SCSI commands before
setting up the new prep_rq_fn, presumably hitting this bogus
pointer.
One fix would be to have sr remember the original prep function and
restore it in sr_kref_release. Sd and a few other drivers have this
issue. Ide-cd bothers to set prep_rq_fn to NULL as it releases
the device.
Bingo .. that's why we ask the list, thanks Pete!
I don't think the fix is the correct one, but I've attached what I think
is the correct fix (basically, there's a bus callback we can use to
ensure the right thing always gets done rather than relying on drivers
doing it in their own release methods, that way they can't forget).
The reason it was showing up in -rc4 I suspect is because something was
structurally altering the module stack, and the address that sr_mod was
loaded was changed, so the prep_fn as Pete said was pointing into bogus
address space.
The way to trigger this bug 100% of the time is to rmmod sr_mod and then
send an inquiry (or another command) to the device using the sg node.
James
---
Index: BUILD-2.6/drivers/scsi/scsi_lib.c
===
--- BUILD-2.6.orig/drivers/scsi/scsi_lib.c 2008-01-01 10:13:33.0
-0600
+++ BUILD-2.6/drivers/scsi/scsi_lib.c 2008-01-02 10:17:51.0 -0600
@@ -1324,7 +1324,7 @@ int scsi_prep_return(struct request_queu
}
EXPORT_SYMBOL(scsi_prep_return);
-static int scsi_prep_fn(struct request_queue *q, struct request *req)
+int scsi_prep_fn(struct request_queue *q, struct request *req)
{
struct scsi_device *sdev = q-queuedata;
int ret = BLKPREP_KILL;
Index: BUILD-2.6/drivers/scsi/scsi_priv.h
===
--- BUILD-2.6.orig/drivers/scsi/scsi_priv.h 2007-11-03 09:08:46.0
-0500
+++ BUILD-2.6/drivers/scsi/scsi_priv.h 2008-01-02 10:20:09.0 -0600
@@ -74,6 +74,9 @@ extern struct request_queue *scsi_alloc_
extern void scsi_free_queue(struct request_queue *q);
extern int scsi_init_queue(void);
extern void scsi_exit_queue(void);
+struct request_queue;
+struct request;
+extern int scsi_prep_fn(struct request_queue *, struct request *);
/* scsi_proc.c */
#ifdef CONFIG_SCSI_PROC_FS
Index: BUILD-2.6/drivers/scsi/scsi_sysfs.c
===
--- BUILD-2.6.orig/drivers/scsi/scsi_sysfs.c2007-11-03 10:08:02.0
-0500
+++ BUILD-2.6/drivers/scsi/scsi_sysfs.c 2008-01-02 10:31:33.0 -0600
@@ -373,12 +373,24 @@ static int scsi_bus_resume(struct device
return err;
}
+static int
[PATCH] scsi_sysfs: restore prep_fn when ULD is removed
A recent bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=9674
Was caused because the ULDs now set their own prep functions, but don't
necessarily reset the prep function back to the SCSI default when they
are removed. This leads to panics if commands are sent to the device
after the module is removed because the prep_fn is still pointing to the
old module code. The fix for this is to implement a bus remove method
that resets the prep_fn pointer correctly before calling the driver
specific prep_fn.
James
P.S. The patch in the bug report is slightly wrong. It doesn't include
the piece to call the ULD specific remove function.
Index: BUILD-2.6/drivers/scsi/scsi_lib.c
===
--- BUILD-2.6.orig/drivers/scsi/scsi_lib.c 2008-01-01 10:13:33.0
-0600
+++ BUILD-2.6/drivers/scsi/scsi_lib.c 2008-01-02 10:17:51.0 -0600
@@ -1324,7 +1324,7 @@ int scsi_prep_return(struct request_queu
}
EXPORT_SYMBOL(scsi_prep_return);
-static int scsi_prep_fn(struct request_queue *q, struct request *req)
+int scsi_prep_fn(struct request_queue *q, struct request *req)
{
struct scsi_device *sdev = q-queuedata;
int ret = BLKPREP_KILL;
Index: BUILD-2.6/drivers/scsi/scsi_priv.h
===
--- BUILD-2.6.orig/drivers/scsi/scsi_priv.h 2007-11-03 09:08:46.0
-0500
+++ BUILD-2.6/drivers/scsi/scsi_priv.h 2008-01-02 10:20:09.0 -0600
@@ -74,6 +74,9 @@ extern struct request_queue *scsi_alloc_
extern void scsi_free_queue(struct request_queue *q);
extern int scsi_init_queue(void);
extern void scsi_exit_queue(void);
+struct request_queue;
+struct request;
+extern int scsi_prep_fn(struct request_queue *, struct request *);
/* scsi_proc.c */
#ifdef CONFIG_SCSI_PROC_FS
Index: BUILD-2.6/drivers/scsi/scsi_sysfs.c
===
--- BUILD-2.6.orig/drivers/scsi/scsi_sysfs.c2007-11-03 10:08:02.0
-0500
+++ BUILD-2.6/drivers/scsi/scsi_sysfs.c 2008-01-02 10:58:17.0 -0600
@@ -373,12 +373,29 @@ static int scsi_bus_resume(struct device
return err;
}
+static int scsi_bus_remove(struct device *dev)
+{
+ struct device_driver *drv = dev-driver;
+ struct scsi_device *sdev = to_scsi_device(dev);
+ int err = 0;
+
+ /* reset the prep_fn back to the default since the
+* driver may have altered it and it's being removed */
+ blk_queue_prep_rq(sdev-request_queue, scsi_prep_fn);
+
+ if (drv drv-remove)
+ err = drv-remove(dev);
+
+ return 0;
+}
+
struct bus_type scsi_bus_type = {
.name = scsi,
.match = scsi_bus_match,
.uevent = scsi_bus_uevent,
.suspend= scsi_bus_suspend,
.resume = scsi_bus_resume,
+ .remove = scsi_bus_remove,
};
int scsi_sysfs_register(void)
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
reproducible DV to the wrong device (fusion)
Hi, I complained about this before, but always got ignored. Please not this time. I can presently reliably reproduce it as often as I want. Pretty please, I can't keep this state forever, since the system is presently going into production. As far as I can remotely see, IOC0 and IOC1 are on the same dualport LSI22320 card. The device on IOC0 is probably not properly connected, probably a cable problem. When I just tried to add the device on IOC0, the device on IOC1 got a domain validation command. Presently both devices are idle otherwise. On IOC0 there is 2:0:4:0 and on IOC1 there is 3:0:13:0 and 3:0:14:0. pfs1n14-m:~# /tmp/scsiadd -a 2 0 4 0 [ 2595.405276] scsi 2:0:4:0: Activating scsi error recovery [ 2595.405711] mptbase: ioc0: LogInfo(0x11010400): F/W: bug! MID not found [ 2595.417828] Starting device recovery 5 [ 2595.668030] mptbase: ioc0: LogInfo(0x11010400): F/W: bug! MID not found [ 2595.675024] scsi 2:0:4:0: Sending BDR 0x810128195920 [ 2595.680618] scsi 2:0:4:0: trying device reset [ 2595.685230] mptscsih: ioc0: attempting target reset! (sc=810128cbc500) [ 2595.692280] scsi 2:0:4:0: CDB: Inquiry: 12 00 00 00 24 00 [ 2596.826218] mptbase: ioc0: LogInfo(0x11010400): F/W: bug! MID not found [ 2597.089427] mptscsih: ioc0: Issue of TaskMgmt failed! [ 2597.094766] mptscsih: ioc0: target reset: FAILED (sc=810128cbc500) [ 2597.101605] Sending BRST chan: 0 [ 2597.104982] scsi 2:0:4:0: trying bus reset [ 2597.109306] mptscsih: ioc0: attempting bus reset! (sc=810128cbc500) [ 2597.116271] scsi 2:0:4:0: CDB: Inquiry: 12 00 00 00 24 00 [ 2598.511931] mptscsih: ioc0: bus reset: SUCCESS (sc=810128cbc500) [ 2608.513834] scsi 2:0:4:0: trying host reset [ 2608.514187] mptbase: ioc0: LogInfo(0x11010400): F/W: bug! MID not found [ 2608.525197] mptscsih: ioc0: Attempting host reset! (sc=810128cbc500) [ 2608.532246] mptbase: Initiating ioc0 recovery [ 2620.952389] target2:0:4: asynchronous [ 2620.956405] target3:0:12: Beginning Domain Validation [ 2620.987547] target3:0:12: Ending Domain Validation [ 2620.992714] target3:0:12: FAST-160 WIDE SCSI 320.0 MB/s DT IU QAS PCOMP (6.25 ns, offset 127) [ 2621.001863] target3:0:13: Beginning Domain Validation [ 2621.032982] target3:0:13: Ending Domain Validation [ 2621.037978] target3:0:13: FAST-160 WIDE SCSI 320.0 MB/s DT IU QAS PCOMP (6.25 ns, offset 127) [ 2630.946215] scsi 2:0:4:0: scsi: Device offlined - not ready after error recovery [ 2630.946608] mptbase: ioc0: LogInfo(0x11010400): F/W: bug! MID not found I already tried echo -1 /proc/sys/dev/scsi/logging_level, but this doesn't reveal anything. Please, we really need to fix this, as this is really troublesome in production situation. Some hints for further debugging should be suffienct for now. Thanks, Bernd -- Bernd Schubert Q-Leap Networks GmbH - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: reproducible DV to the wrong device (fusion)
On Wednesday, January 02, 2008 11:54 AM, Bernd Schubert wrote: I complained about this before, but always got ignored. Please not this time. Sorry, I didn't see your email before today. On IOC0 there is 2:0:4:0 and on IOC1 there is 3:0:13:0 and 3:0:14:0. pfs1n14-m:~# /tmp/scsiadd -a 2 0 4 0 [ 2595.405276] scsi 2:0:4:0: Activating scsi error recovery [ 2595.405711] mptbase: ioc0: LogInfo(0x11010400): F/W: bug! MID not found MID = means the firmware was unable to locate the proper message id associated to some request when completing some command. Apparently the command never completed back to driver, and eh threads were woken. The MID might be fixed by a firmware upgrade. Do you know which version you have? It will be provided in the banner when the driver loads. I already tried echo -1 /proc/sys/dev/scsi/logging_level, but this doesn't reveal anything. Please, we really need to fix this, as this is really troublesome in production situation. Some hints for further debugging should be suffienct for now. If your using a linux kernel that was released since last summer, I now provide logging support in the driver which can be enabled/disabled via sysfs attributes and command line option. I will send you documentation in seperate private email. Some info of this provided in mptdebug.h in the source code. For domain validation, you need to enable the MPT_DEBUG_DV bits. Also CONFIG_FUSION_LOGGING needs to be enabled in the kernel config, and set your kernel logging level for klogd to 7 (or KERN_DEBUG). Example insmod mptbase.ko mpt_debug_level=0x200 or echo 0x200 /sys/class/scsi_host/host0/debug_level - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] scsi : convert semaphore to mutex in struct class
Use mutex instead of semaphore in struct class.
Signed-off-by: Dave Young [EMAIL PROTECTED]
---
drivers/scsi/hosts.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -upr linux/drivers/scsi/hosts.c linux.new/drivers/scsi/hosts.c
--- linux/drivers/scsi/hosts.c 2007-12-28 10:45:46.0 +0800
+++ linux.new/drivers/scsi/hosts.c 2007-12-28 10:46:19.0 +0800
@@ -441,7 +441,7 @@ struct Scsi_Host *scsi_host_lookup(unsig
struct class_device *cdev;
struct Scsi_Host *shost = ERR_PTR(-ENXIO), *p;
- down(class-sem);
+ mutex_lock(class-mutex);
list_for_each_entry(cdev, class-children, node) {
p = class_to_shost(cdev);
if (p-host_no == hostnum) {
@@ -449,7 +449,7 @@ struct Scsi_Host *scsi_host_lookup(unsig
break;
}
}
- up(class-sem);
+ mutex_unlock(class-mutex);
return shost;
}
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] sg_ring: Gentler scsi merge
OK, after wading through many scsi drivers, I decided to change tack and try
to provide a transition path. This is in two stages:
1) These two patches. sg_ring used underneath, but if any driver asks for
scsi_sglist() they get a 2.6.24-style chained sg. No other patches are
necessary.
2) Once all chained-sg-needing scsi drivers change to use cmd-sg (ie.
sg_ring) directly, and the chained sg patches can be reverted. scsi_sglist()
and scsi_sg_count() then become:
/* You should only use these if you never need chained sgs */
static inline struct scatterlist *scsi_sglist(struct scsi_cmd *cmd)
{
BUG_ON(!list_empty(cmd-sg-list));
return cmd-sg-sg[0];
}
static unsigned int scsi_sg_count(struct scsi_cmd *cmd)
{
if (!cmd-sg)
return 0;
BUG_ON(!list_empty(cmd-sg-list));
return cmd-sg-num;
}
Thanks,
Rusty.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] convert semaphore to mutex in struct class
On Thu, Jan 03, 2008 at 08:06:09AM +0100, Jarek Poplawski wrote: On Thu, Jan 03, 2008 at 01:50:20PM +0800, Dave Young wrote: Convert semaphore to mutex in struct class. ... One lockdep warning detected as following, thus use mutex_lock_nested with SINGLE_DEPTH_NESTING in class_device_add Jan 3 10:45:15 darkstar kernel: = Jan 3 10:45:15 darkstar kernel: [ INFO: possible recursive locking detected ] Jan 3 10:45:15 darkstar kernel: 2.6.24-rc6-mm1-mutex #1 Jan 3 10:45:15 darkstar kernel: - ... If there's anything missed please help to point out, thanks. Dave, IMHO it's not 'the right' way to do it: [...] OOPS! (I was sleeping...) Unless it has turned out it's not so hard here, and you are quite sure there should be no more warnings after this one nesting annotation - then of course, this is the right way! Sorry (?) Jarek P. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] convert semaphore to mutex in struct class
On Jan 3, 2008 3:24 PM, Jarek Poplawski [EMAIL PROTECTED] wrote: On Thu, Jan 03, 2008 at 08:06:09AM +0100, Jarek Poplawski wrote: On Thu, Jan 03, 2008 at 01:50:20PM +0800, Dave Young wrote: Convert semaphore to mutex in struct class. ... One lockdep warning detected as following, thus use mutex_lock_nested with SINGLE_DEPTH_NESTING in class_device_add Jan 3 10:45:15 darkstar kernel: = Jan 3 10:45:15 darkstar kernel: [ INFO: possible recursive locking detected ] Jan 3 10:45:15 darkstar kernel: 2.6.24-rc6-mm1-mutex #1 Jan 3 10:45:15 darkstar kernel: - ... If there's anything missed please help to point out, thanks. Dave, IMHO it's not 'the right' way to do it: [...] OOPS! (I was sleeping...) Unless it has turned out it's not so hard here, and you are quite sure there should be no more warnings after this one nesting annotation - then of course, this is the right way! Thanks ;) I don't know if there's other possible warning places with this mutex or not, if you have any ideas about this, please tell me. Sorry (?) Jarek P. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] convert semaphore to mutex in struct class
On Thu, Jan 03, 2008 at 03:21:36PM +0800, Dave Young wrote: ... I don't know if there's other possible warning places with this mutex or not, if you have any ideas about this, please tell me. I think lockdep is just to tell such things. So, the question is, how much it was tested already, because if there are many warnings reported e.g. after merging to -mm, then this could be better to re-do it this other way... But, I hope this will not be necessary. Jarek P. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
