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
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
14 matches
Mail list logo
