Michael Schwarz wrote:
More than ever, I am convinced that it is actually a hardware problem, but
I am curious for the opinions of both of you on whether the system
(meaning, I guess, the combination of usb-storage driver and raid) is
really doing the best with what it has.
See below, but
I'm going to hang on to the hardware. This is a pilot/demo that may lead
to development of a new device, and, if so, I'll be getting back into
device driver writing. Working this problem would be great practice for
that. So I will do it. The only problem is I don't know when!
I believe I can
On Mon, 19 Mar 2007, Michael Schwarz wrote:
I'm going to hang on to the hardware. This is a pilot/demo that may lead
to development of a new device, and, if so, I'll be getting back into
device driver writing. Working this problem would be great practice for
that. So I will do it. The only
Comments below.
--
Michael Schwarz
On Mon, 19 Mar 2007, Michael Schwarz wrote:
I'm going to hang on to the hardware. This is a pilot/demo that may lead
to development of a new device, and, if so, I'll be getting back into
device driver writing. Working this problem would be great practice
On Mon, 19 Mar 2007, Michael Schwarz wrote:
Yeah; But here was where I lacked confidence. I used to know every inch of
my kernel and my hardware, but, as previously stated, that was back in the
2.2.x days. I wasn't confident that I could run my hardware with a
plain-vanilla kernel or that I
As I suspected, majordomo doesn't like attachments.
I looked through the logs. The only odd thing I see before the read that
hangs is this message:
smartd[3069]: Device: /dev/hda, 1 Currently unreadable (pending) sectors
Which I only see in /var/log/messages because the stack dump blows
Just tried in on a stock Ubuntu Edgy install. Same thing. Locks on read.
I've got a dmesg (w/stack trace) file from the ubuntu attempt (it was
clean prior to doing the read) which I will send to Alan and Neil (any
anyone else who asks for it). There were no error messages in dmesg prior
to
On Sunday March 18, [EMAIL PROTECTED] wrote:
cp -rv /mnt/* fs2d2/
At this point, the process hangs. So I ran:
echo t /proc/sysrq-trigger
dmesg dmesg-5-hungread.log
Unfortunate (as you say) the whole trace doesn't fit.
Could you try compiling the kernel with a larger value for
More than ever, I am convinced that it is actually a hardware problem, but
I am curious for the opinions of both of you on whether the system
(meaning, I guess, the combination of usb-storage driver and raid) is
really doing the best with what it has.
My last effort was to switch to a different
Neil:
Relevant stack trace follows. Any suggestions? blk_backing_dev_unplug...
Does that mean the raid subsystem thinks one of the usb drives has been
removed? I assure you that physically this is untrue, but that doesn't
mean that some sort logical disconnect hasn't happened...
Makes me wonder
On Sat, 17 Mar 2007, Michael Schwarz wrote:
Neil:
Relevant stack trace follows. Any suggestions? blk_backing_dev_unplug...
Does that mean the raid subsystem thinks one of the usb drives has been
removed? I assure you that physically this is untrue, but that doesn't
mean that some sort
Comments/questions below...
--
Michael Schwarz
This isn't much help. The important processes here are khubd,
usb-storage, and scsi_eh_*. Possibly some raid-related processes too, but
I don't know which they would be.
I have no copy khubd running. What is the list policy on attachments?
On Sat, 17 Mar 2007, Michael Schwarz wrote:
Comments/questions below...
--
Michael Schwarz
This isn't much help. The important processes here are khubd,
usb-storage, and scsi_eh_*. Possibly some raid-related processes too, but
I don't know which they would be.
I have no copy
On Sat, 17 Mar 2007, Michael Schwarz wrote:
Nasty big stack trace set follows:
This format is kind of awkward. For one thing, a lot of lines were
wrapped by your email program.
For another, you copied the stack trace from the syslog log file. That is
not a good way to do it; syslogd is
Yeah, I understand that.
Sorry, I use squirrelmail. Pretty limited...
I'll get you a raw dmseg output when I replicate the problem.
Let me clarify on khubd: There is such an entry in my process table, but
there was no kernel thread stack trace for it when I dumped the traces. I
don't know if
I'm not a Linux newbie (I've even written a couple of books and done some
very light device driver work), but I'm completely new to the software
raid subsystem.
I'm doing something rather oddball. I'm making an array of USB flash
drives and comparing read and write rates.
Well, I've had great
On Friday March 16, [EMAIL PROTECTED] wrote:
I'm not a Linux newbie (I've even written a couple of books and done some
very light device driver work), but I'm completely new to the software
raid subsystem.
I'm doing something rather oddball. I'm making an array of USB flash
drives and
17 matches
Mail list logo
