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
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 pr
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
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 repli
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
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 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
CON
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 running
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
whatever
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 t
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 lia
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
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 attachment
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
14 matches
Mail list logo
