Fajun Chen wrote:
On 8/25/06, Tejun Heo <htejun@xxxxxxxxx> wrote:
Fajun Chen wrote:
> Hi Tejun,
>
> Below are the tests I performed:
> Test1:
> a) Power off the drive
> b) echo "scsi remove-single-device h b t l" > /proc/scsi/scsi
> or delete using sysfs
> c) Power on the drive
> d) echo "scsi add-single-device h b t l" > /proc/scsi/scsi
> or scan using sysfs
> The kernel error in my first email is induced in this test but not
> consistently reproducible. In most of the case, no kernel error but sg
> was not reattached when adding device.
>
> Test2:
> Ignore step c) in test1. Basically, try to add device while the device
> is still powered off.
>
> Hope this helps.
Was the drive loaded with commands issued via /dev/sgX when you did
above operation?
No. One note: the kernel error I reported in my first email
happened in ARM XSCale IOP80321 platform.
I could regenerate an oops while the drive was loaded w/ command from
sg. Mine occurs earlier than yours because kmalloc debug is turned on
(the memory is poisoned on free and the the next access oopses). It
seems that sg has refcounting bug.
You can issue all raw commands via high level device node - e.g.
/dev/sdX or /dev/srX, so you don't really need to use sg devices in many
cases.
Other than sg related, I couldn't find any problem with hot/warm/pervert
plugging. Can you please try without any sg use? If you need loaded
test, just load them with regular IO or use /dev/sdX to issue raw
commands. I'm not sure I'll track down the sg problem.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
