Re: oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7

2006-12-11 Thread Jiri Kosina
On Mon, 11 Dec 2006, Neil Brown wrote: this nash thing is exactly the command which triggers a bit different oops in my case. On my side, the oops is fully reproducible. If you manage to make your case also reproducible, could you please try to revert

[PATCH] md: Don't assume that READ==0 and WRITE==1 - use the names explicitly.

2006-12-11 Thread NeilBrown
### Comments for Changeset Thanks Jens for alerting me to this. Cc: Jens Axboe [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Neil Brown [EMAIL PROTECTED] ### Diffstat output ./drivers/md/faulty.c |2 +- ./drivers/md/raid1.c |2 +- ./drivers/md/raid10.c |6 +++---

Re: oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7

2006-12-11 Thread Neil Brown
On Monday December 11, [EMAIL PROTECTED] wrote: On Mon, 11 Dec 2006, Neil Brown wrote: this nash thing is exactly the command which triggers a bit different oops in my case. On my side, the oops is fully reproducible. If you manage to make your case also reproducible, could you

Does the md codes can work well under SMP?

2006-12-11 Thread liyiming
These days I devoted to reading md codes in 2.6.12_r11 I have noticed that you applied two different locking strategy in these two functions: end_read_request: if (uptodate) { set_bit(R5_UPTODATE, sh-dev[i].flags); } else {