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
On 17 Mar 2007, Chris Lindley told this:
> What I think the OP is getting at is that MDADM will create an array
> with partitions whose type is not set to FD (Linux Raid Auto), but are
> perhaps 83.
>
> The issue with that is that upon a reboot mdadm will not be able to
> start the array.
I think
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
Update:
(For those who've been waiting breathlessly). It hangs at a particular
point in a particular file. In other words, it doesn't depend on the total
number of bytes transfered. Rather, when it reaches a particular point in
a particular file (12267520 bytes into a file that is 1073709056 bytes
I'll try playing around with IO sizes with dd.
What I'm finding so far is ABSOLUTE consistency on where it locks. If it
were a race condition with kernel locks I guess I would expect it to be
more indeterminate (in my limited experience) unless it is due to specific
"deadly embrace" condition betw
The current implementation builds on my embedded PPC4xx system without any
disks the objects async_tx.o and xor.o into the kernel which I definitely
don't need and want. And I get something like:
async_tx: api initialized (sync-only)
xor: measuring software checksumming speed
8regs : 145
On Sat, 2007-03-17 at 13:10 -0500, Bill Davidsen wrote:
>
> First, please learn the difference between file system type (user data
> ON the device), and partition type (a byte in the partition table).
Which it's technical name would be a partition system ID. However older
versions of fdisk did re
On Saturday 17 March 2007 19:17, Dan Williams wrote:
> Yes, defaulting to 'y' is not necessary, but ASYNC_TX_DMA=y &&
> DMA_ENGINE=n is an explicit feature of the interface. When DMA_ENGINE
> is not selected all the asynchronous paths in the API are compiled
> out. This allows subsytems, like md-
On 3/17/07, Stefan Roese <[EMAIL PROTECTED]> wrote:
Dan,
I just noticed that your patch "dmaengine: add the async_tx api":
@@ -22,6 +22,17 @@ config NET_DMA
Since this is the main user of the DMA engine, it should be enabled;
say Y here.
+config ASYNC_TX_DMA
+ tristat
William L. Thomson Jr. wrote:
On Sat, 2007-03-17 at 12:30 +1100, Neil Brown wrote:
It would be very awkward for mdadm to get at the partition type
information.
And there is very little software that actually cares. mdadm
certainly doesn't care what the partition type is.
I got it re
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 i
Hi Dan,
On Friday 16 March 2007 21:00, you wrote:
> Here are some additional comments/nits:
> > +/*
> > + * Init DMA0/1 and XOR engines; allocate memory for DMAx FIFOs; set
> > platform_device + * memory resources addresses
> > + */
> > +static void ppc440spe_configure_raid_devices(void)
>
> Any
What I think the OP is getting at is that MDADM will create an array
with partitions whose type is not set to FD (Linux Raid Auto), but are
perhaps 83.
The issue with that is that upon a reboot mdadm will not be able to
start the array. If you use MDADM to manually reassemble the array then
it wi
On Sat, 2007-03-17 at 16:40 +1100, Neil Brown wrote:
> On Friday March 16, [EMAIL PROTECTED] wrote:
> >
> > Instead of passing along an interpretation, here are some IRC log
> > snippets that pertain from #gentoo-dev @ freenode.net
> >
> > kingtaco|work: livecd ~ # mdadm --create --level=1 --raid
Dan,
I just noticed that your patch "dmaengine: add the async_tx api":
@@ -22,6 +22,17 @@ config NET_DMA
Since this is the main user of the DMA engine, it should be enabled;
say Y here.
+config ASYNC_TX_DMA
+ tristate "Asynchronous Bulk Memory Transfers/Transforms API"
18 matches
Mail list logo