Re: Subject: [PATCH] md: avoid deadlock when raid5 array has unack badblocks during md_stop_writes.

2013-09-10 Thread y b
15:16:28 localhost kernel: [ 480.854481] [] ? handle_mm_fault+0x17d/0x920 2013/9/10, NeilBrown : > On Tue, 10 Sep 2013 13:00:52 +0800 y b wrote: > >> When raid5 hit a fresh badblock, this badblock will flagged as unack >> badblock until md_update_sb is called. >> But md_

Re: Subject: [PATCH] md: avoid deadlock when raid5 array has unack badblocks during md_stop_writes.

2013-09-10 Thread y b
localhost kernel: [ 480.854479] [8153f6a9] md_ioctl+0xef9/0x15c0 Sep 10 15:16:28 localhost kernel: [ 480.854481] [8113145d] ? handle_mm_fault+0x17d/0x920 2013/9/10, NeilBrown ne...@suse.de: On Tue, 10 Sep 2013 13:00:52 +0800 y b ycbzzj...@gmail.com wrote: When raid5 hit a fresh

Subject: [PATCH] md: avoid deadlock when raid5 array has unack badblocks during md_stop_writes.

2013-09-09 Thread y b
When raid5 hit a fresh badblock, this badblock will flagged as unack badblock until md_update_sb is called. But md_stop/reboot/md_set_readonly will avoid raid5d call md_update_sb in md_check_recovery, the badblock will always be unack, so raid5d thread enter a infinite loop and never can

Subject: [PATCH] md: avoid deadlock when raid5 array has unack badblocks during md_stop_writes.

2013-09-09 Thread y b
When raid5 hit a fresh badblock, this badblock will flagged as unack badblock until md_update_sb is called. But md_stop/reboot/md_set_readonly will avoid raid5d call md_update_sb in md_check_recovery, the badblock will always be unack, so raid5d thread enter a infinite loop and never can

kernel panic when called usb_control_msg()

2012-08-02 Thread y b
Hi, kernel panic when called usb_control_msg(), like this: usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0), XR_SET_REG, USB_DIR_OUT | USB_TYPE_VENDOR, value, regnum | (block << 8), NULL, 0, 5000) The kernel's version is 2.6.33_rc4, but I think it will happen in lastest statable

kernel panic when called usb_control_msg()

2012-08-02 Thread y b
Hi, kernel panic when called usb_control_msg(), like this: usb_control_msg(serial-dev, usb_sndctrlpipe(serial-dev, 0), XR_SET_REG, USB_DIR_OUT | USB_TYPE_VENDOR, value, regnum | (block 8), NULL, 0, 5000) The kernel's version is 2.6.33_rc4, but I think it will happen in lastest statable version