On Sun, 4 Nov 2012, Piergiorgio Sartor wrote:

> Hi all,
> 
> I've a strange problem with the USB subsystem, under
> kernel 3.6, this was not happening under 3.5.
> The system is Fedora, so I'll use their kernel numbers,
> and the related bug report is this:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=866166
> 
> I've some USB hubs cascaded in order to have 10 ports
> available.
> Two configurations: one is with 3 hubs, 4 ports each,
> where 2 hubs are connected to the first one.
> Second configuration is similar, it only uses 1 hubs
> with 7 ports followed by a 5 ports one.
> 
> To the resulting 10 ports are connected to 10 USB hard
> disks. This is a "feasibility study" on the possibility
> to create a storage device in this condition.
> 
> The 10 HDDs are combined in RAID-6.
> 
> Now, until kernel 3.5.6, everything was working fine,
> I can achieve around 43MB/sec transfer rate (read) from
> such setup, with high reliability.
> Of course, some times one HDD would flight away, but
> nothing really serious as a problem. In fact this was
> one of the point I wanted to check.
> 
> Since kernel 3.6.x, after short time accessing the
> RAID (or in parallel the 10 HDDs, independently from
> the md layer), I get error -110 from the USB subsystem
> and everything dies.
> It seems to me, but I'm not sure, reading a single
> HDD does not lead to this problem.

> Any idea or suggestion on how to test further?

The first thing you should do is test a 3.6 kernel with 
CONFIG_USB_DEBUG enabled and post the dmesg log showing the problem.  
That will help indicate what is going wrong.

If that doesn't suggest a solution, the next thing you should do is use 
git bisect to find which change to the kernel is responsible for the 
errors.  For this to work, you have to be able to tell reliably whether 
the problem is present or not with a particular kernel, but it sounds 
like that should be easy enough.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to