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
+
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-devices=2
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
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 reason not
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
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
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
+ tristate
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
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
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
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 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 you
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
16 matches
Mail list logo
