Jason Luo <[EMAIL PROTECTED]> wrote:
> Now, I am writing a driver, which need 200M contiguous physical
> memory? can do? how to do it?
The ftape utils have a tool called swapout which tries to 'free'
large chunks of memory which then can be allocated by the ftape
module loaded subsequently.
I
Jason Luo [EMAIL PROTECTED] wrote:
Now, I am writing a driver, which need 200M contiguous physical
memory? can do? how to do it?
The ftape utils have a tool called swapout which tries to 'free'
large chunks of memory which then can be allocated by the ftape
module loaded subsequently.
I don't
On Tue, Jan 18, 2005 at 10:07:27AM -0500, Piszcz, Justin Michael wrote:
> Not trying to spread FUD, I am just explaining I had the same issue and
> that was the resolution.
Well, *if* the reason of your issue was the same as the reason of
my issue (what could be, but must not be), you were in the
On Tue, Jan 18, 2005 at 09:24:03AM -0500, Piszcz, Justin Michael wrote:
> Is the problem with the drive on the promise board or the drive on the
> VIA chipset?
The problem is with each drive on each controller. The problem is even
with no drive on no controller - as I've shown to you with my loop
On Tue, Jan 18, 2005 at 03:17:07PM +0100, Sytse Wielinga wrote:
> Why not just use dd if=/dev/xxx `blockdev --getbsz /dev/xxx` ...?
because it doesn't work, as I've demonstrated in
Message-ID: <[EMAIL PROTECTED]>
> [EMAIL PROTECTED]:~# dd if=/dev/hdg7 of=/dev/null bs=512
> attempt to access
On Tue, Jan 18, 2005 at 09:05:05AM -0500, Piszcz, Justin Michael wrote:
> Okay but what hard drive model and IDE Chipset/Controller are you using?
VIA vt82c686b onboard
PDC20269 (Promise U133TX2) on PCI
hda: WDC WD400EB-00CPF0, ATA DISK drive
hdc: IC35L080AVVA07-0, ATA DISK drive
hdd: HL-DT-ST
On Tue, Jan 18, 2005 at 08:42:08AM -0500, Piszcz, Justin Michael wrote:
> Normally, this problem associated with drives over 32GB or 127GB on a
> controller that cannot support it. It was not discussed here, I was
> wondering if that is the problem, if it is not, what type of Hard Drive
> is
On Tue, Jan 18, 2005 at 06:45:26AM -0200, Marcelo Tosatti wrote:
> So this is either not a Linux error and not a disk error, its just that the
> "use with filesystem" then "direct access" is a unfortunate combination.
> What would be the correct fix for this for this, if any?
Well, I personally
On Tue, Jan 18, 2005 at 11:55:47AM +0100, Andries Brouwer wrote:
> I suppose that what happens is the following:
> mounting sets the blocksize to 4096.
> After reading 9992360 sectors, reading the next block means reading
> the next 8 sectors and that fails because only 6 sectors are left.
> Test
On Mon, Jan 17, 2005 at 05:46:35PM -0200, Marcelo Tosatti wrote:
> On Sun, Jan 16, 2005 at 12:35:30AM +0100, Mario Holbe wrote:
> > Could somebody please explain this to me? Is this intentional?
> No
Thanks :)
> Can you please turn readahead off (hdparm -a 0 /dev/hdg) and r
On Mon, Jan 17, 2005 at 05:46:35PM -0200, Marcelo Tosatti wrote:
On Sun, Jan 16, 2005 at 12:35:30AM +0100, Mario Holbe wrote:
Could somebody please explain this to me? Is this intentional?
No
Thanks :)
Can you please turn readahead off (hdparm -a 0 /dev/hdg) and repeat the tests
On Tue, Jan 18, 2005 at 11:55:47AM +0100, Andries Brouwer wrote:
I suppose that what happens is the following:
mounting sets the blocksize to 4096.
After reading 9992360 sectors, reading the next block means reading
the next 8 sectors and that fails because only 6 sectors are left.
Test that
On Tue, Jan 18, 2005 at 06:45:26AM -0200, Marcelo Tosatti wrote:
So this is either not a Linux error and not a disk error, its just that the
use with filesystem then direct access is a unfortunate combination.
What would be the correct fix for this for this, if any?
Well, I personally think
On Tue, Jan 18, 2005 at 08:42:08AM -0500, Piszcz, Justin Michael wrote:
Normally, this problem associated with drives over 32GB or 127GB on a
controller that cannot support it. It was not discussed here, I was
wondering if that is the problem, if it is not, what type of Hard Drive
is giving
On Tue, Jan 18, 2005 at 09:05:05AM -0500, Piszcz, Justin Michael wrote:
Okay but what hard drive model and IDE Chipset/Controller are you using?
VIA vt82c686b onboard
PDC20269 (Promise U133TX2) on PCI
hda: WDC WD400EB-00CPF0, ATA DISK drive
hdc: IC35L080AVVA07-0, ATA DISK drive
hdd: HL-DT-ST
On Tue, Jan 18, 2005 at 03:17:07PM +0100, Sytse Wielinga wrote:
Why not just use dd if=/dev/xxx `blockdev --getbsz /dev/xxx` ...?
because it doesn't work, as I've demonstrated in
Message-ID: [EMAIL PROTECTED]
[EMAIL PROTECTED]:~# dd if=/dev/hdg7 of=/dev/null bs=512
attempt to access beyond
On Tue, Jan 18, 2005 at 09:24:03AM -0500, Piszcz, Justin Michael wrote:
Is the problem with the drive on the promise board or the drive on the
VIA chipset?
The problem is with each drive on each controller. The problem is even
with no drive on no controller - as I've shown to you with my loop
On Tue, Jan 18, 2005 at 10:07:27AM -0500, Piszcz, Justin Michael wrote:
Not trying to spread FUD, I am just explaining I had the same issue and
that was the resolution.
Well, *if* the reason of your issue was the same as the reason of
my issue (what could be, but must not be), you were in the
Hello,
mounting an ext2 (ext3 as well) filesystem seems to modify the
block device's EOF behaviour: before the mount the device returned
EOF, after the mount it doesn't anymore:
[on a fresh booted system]
[EMAIL PROTECTED]:~# uname -a
Linux darkside 2.4.27 #1 Sat Jan 15 17:07:20 CET 2005 i686
Hello,
mounting an ext2 (ext3 as well) filesystem seems to modify the
block device's EOF behaviour: before the mount the device returned
EOF, after the mount it doesn't anymore:
[on a fresh booted system]
[EMAIL PROTECTED]:~# uname -a
Linux darkside 2.4.27 #1 Sat Jan 15 17:07:20 CET 2005 i686
20 matches
Mail list logo
