I don't know. Can you describe how your driver implements the remapping?
I have tested with ext2. I get double faults when trying to sync.
What are those? (By the look of the error message, I can see they are
not something I want to have :-)
I'm at loss how all of this can happend. All I do is
I don't know. Can you describe how your driver implements the remapping?
I have tested with ext2. I get double faults when trying to sync.
What are those? (By the look of the error message, I can see they are
not something I want to have :-)
I'm at loss how all of this can happend. All I do is
Something has caused the page at offset 51 (block 102) to have buffer_heads
for blocks 128 and 129 attached to it.
Ok.
I'd be suspecting that the sector remapping is the cause of the problem.
How is it implemented?
Quite simple actually. You're most welcome to see the code, but I have
just done
> OK, so we're looking for the buffer_head for block 101 and the first
> buffer_head which is attached to the page represents block 100. So the
> next buffer_head _should_ represent block 101. Please print it out:
Not quite the same, but simelar:
Feb 23 14:50:24 localhost kernel:
> > dd if=/dev/zero of=/mnt/testfile count=N, N>6
It turns out N>6 is variable. But large enough and it will hang. Sugests
some kind of race I am afraid.
> > I get into an endless loop in __find_get_block_slow.
>
> The only way in which __find_get_block_slow() can loop is if something
>
dd if=/dev/zero of=/mnt/testfile count=N, N6
It turns out N6 is variable. But large enough and it will hang. Sugests
some kind of race I am afraid.
I get into an endless loop in __find_get_block_slow.
The only way in which __find_get_block_slow() can loop is if something
wrecked the
OK, so we're looking for the buffer_head for block 101 and the first
buffer_head which is attached to the page represents block 100. So the
next buffer_head _should_ represent block 101. Please print it out:
Not quite the same, but simelar:
Feb 23 14:50:24 localhost kernel:
Something has caused the page at offset 51 (block 102) to have buffer_heads
for blocks 128 and 129 attached to it.
Ok.
I'd be suspecting that the sector remapping is the cause of the problem.
How is it implemented?
Quite simple actually. You're most welcome to see the code, but I have
just done
Hi There
I am trying to develop a device mapper plugin which does transparent
block encryption and sector shuffling in the style freebsd does it (GBDE)
Reads are support and working, but have trouble getting writes to work
properly.
If I do a simple:
echo "test" > /mnt/test (where /mnt is
Hi There
I am trying to develop a device mapper plugin which does transparent
block encryption and sector shuffling in the style freebsd does it (GBDE)
Reads are support and working, but have trouble getting writes to work
properly.
If I do a simple:
echo test /mnt/test (where /mnt is
> "accelerator"? it's just another ide controller.
I know, but as you wrote, the marketing department and so forth.
> or the piix driver doesn't recognize the pci vid/did for this
> particular chip. both are easy to fix.
I figured out it had to be something along those lines, but I'm not
Hi
I was just wondering if there is any support for the 82371mx accelerator
in the IDE driver. It doesn't appear that way to me, but that can be my
fault :)
Just to be precise. I'm talking about this chip:
ftp://download.intel.com/support/chipsets/430mx/290525.pdf
I have tried stock debian
Hi
I was just wondering if there is any support for the 82371mx accelerator
in the IDE driver. It doesn't appear that way to me, but that can be my
fault :)
Just to be precise. I'm talking about this chip:
ftp://download.intel.com/support/chipsets/430mx/290525.pdf
I have tried stock debian
accelerator? it's just another ide controller.
I know, but as you wrote, the marketing department and so forth.
or the piix driver doesn't recognize the pci vid/did for this
particular chip. both are easy to fix.
I figured out it had to be something along those lines, but I'm not sure
14 matches
Mail list logo