On Sun, 21 Jan 2007, [EMAIL PROTECTED] wrote:
> From: Justin Piszcz <[EMAIL PROTECTED]>
> Date: Sat, Jan 20, 2007 at 04:03:42PM -0500
> >
> >
> > My swap is on, 2GB ram and 2GB of swap on this machine. I can't go back
> > to 2.6.17.13 as it does
2.6.19.2:
# hddtemp /dev/sda
/dev/sda: WDC WD740GD-00FLC0: 27C
2.6.20-rc5:
# hddtemp /dev/sda
/dev/sda: ATA WDC WD740GD-00FL: S.M.A.R.T. not available
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
2.6.19.2:
# hddtemp /dev/sda
/dev/sda: WDC WD740GD-00FLC0: 27C
2.6.20-rc5:
# hddtemp /dev/sda
/dev/sda: ATA WDC WD740GD-00FL: S.M.A.R.T. not available
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Sun, 21 Jan 2007, [EMAIL PROTECTED] wrote:
From: Justin Piszcz [EMAIL PROTECTED]
Date: Sat, Jan 20, 2007 at 04:03:42PM -0500
My swap is on, 2GB ram and 2GB of swap on this machine. I can't go back
to 2.6.17.13 as it does not recognize the NICs in my machine correctly
On Sun, 21 Jan 2007, [EMAIL PROTECTED] wrote:
From: Justin Piszcz [EMAIL PROTECTED]
Date: Sat, Jan 20, 2007 at 04:03:42PM -0500
My swap is on, 2GB ram and 2GB of swap on this machine. I can't go back
to 2.6.17.13 as it does not recognize the NICs in my machine correctly
On Sun, 21 Jan 2007, [EMAIL PROTECTED] wrote:
From: Justin Piszcz [EMAIL PROTECTED]
Date: Sun, Jan 21, 2007 at 11:48:07AM -0500
What about all of the changes with NAT? I see that it operates on
level-3/network wise, I enabled that and backward compatiblity support as
well
On Sun, 21 Jan 2007, Justin Piszcz wrote:
Good luck,
Jurriaan
--
What does ELF stand for (in respect to Linux?)
ELF is the first rock group that Ronnie James Dio performed with back in
the early 1970's. In constrast, a.out is a misspelling of the French
word
Why does copying an 18GB on a 74GB raptor raid1 cause the kernel to invoke
the OOM killer and kill all of my processes?
Doing this on a single disk 2.6.19.2 is OK, no issues. However, this
happens every time!
Anything to try? Any other output needed? Can someone shed some light on
this
On Sat, 20 Jan 2007, Justin Piszcz wrote:
>
>
> On Sat, 20 Jan 2007, Avuton Olrich wrote:
>
> > On 1/20/07, Justin Piszcz <[EMAIL PROTECTED]> wrote:
> > > Perhaps its time to back to a stable (2.6.17.13 kernel)?
> > >
> > > Anyway, when I
On Sat, 20 Jan 2007, Avuton Olrich wrote:
> On 1/20/07, Justin Piszcz <[EMAIL PROTECTED]> wrote:
> > Perhaps its time to back to a stable (2.6.17.13 kernel)?
> >
> > Anyway, when I run a cp 18gb_file 18gb_file.2 on a dual raptor sw raid1
> > partition, the OOM
Perhaps its time to back to a stable (2.6.17.13 kernel)?
Anyway, when I run a cp 18gb_file 18gb_file.2 on a dual raptor sw raid1
partition, the OOM killer goes into effect and kills almost all my
processes.
Completely 100% reproducible.
Does 2.6.19.2 have some of memory allocation bug as
On Sat, 20 Jan 2007, Justin Piszcz wrote:
> My .config is attached, please let me know if any other information is
> needed and please CC (lkml) as I am not on the list, thanks!
>
> Running Kernel 2.6.19.2 on a MD RAID5 volume. Copying files over Samba to
> the RAID5 runnin
My .config is attached, please let me know if any other information is
needed and please CC (lkml) as I am not on the list, thanks!
Running Kernel 2.6.19.2 on a MD RAID5 volume. Copying files over Samba to
the RAID5 running XFS.
Any idea what happened here?
[473795.214705] BUG: unable to
My .config is attached, please let me know if any other information is
needed and please CC (lkml) as I am not on the list, thanks!
Running Kernel 2.6.19.2 on a MD RAID5 volume. Copying files over Samba to
the RAID5 running XFS.
Any idea what happened here?
[473795.214705] BUG: unable to
On Sat, 20 Jan 2007, Justin Piszcz wrote:
My .config is attached, please let me know if any other information is
needed and please CC (lkml) as I am not on the list, thanks!
Running Kernel 2.6.19.2 on a MD RAID5 volume. Copying files over Samba to
the RAID5 running XFS.
Any idea
Perhaps its time to back to a stable (2.6.17.13 kernel)?
Anyway, when I run a cp 18gb_file 18gb_file.2 on a dual raptor sw raid1
partition, the OOM killer goes into effect and kills almost all my
processes.
Completely 100% reproducible.
Does 2.6.19.2 have some of memory allocation bug as
On Sat, 20 Jan 2007, Avuton Olrich wrote:
On 1/20/07, Justin Piszcz [EMAIL PROTECTED] wrote:
Perhaps its time to back to a stable (2.6.17.13 kernel)?
Anyway, when I run a cp 18gb_file 18gb_file.2 on a dual raptor sw raid1
partition, the OOM killer goes into effect and kills almost all
On Sat, 20 Jan 2007, Justin Piszcz wrote:
On Sat, 20 Jan 2007, Avuton Olrich wrote:
On 1/20/07, Justin Piszcz [EMAIL PROTECTED] wrote:
Perhaps its time to back to a stable (2.6.17.13 kernel)?
Anyway, when I run a cp 18gb_file 18gb_file.2 on a dual raptor sw raid1
partition
On Sat, 13 Jan 2007, Al Boldi wrote:
> Justin Piszcz wrote:
> > On Sat, 13 Jan 2007, Al Boldi wrote:
> > > Justin Piszcz wrote:
> > > > Btw, max sectors did improve my performance a little bit but
> > > > stripe_cache+read_ahead were the main optimizati
On Sat, 13 Jan 2007, Al Boldi wrote:
Justin Piszcz wrote:
On Sat, 13 Jan 2007, Al Boldi wrote:
Justin Piszcz wrote:
Btw, max sectors did improve my performance a little bit but
stripe_cache+read_ahead were the main optimizations that made
everything go faster by about ~1.5x
On Sat, 13 Jan 2007, Al Boldi wrote:
> Justin Piszcz wrote:
> > Btw, max sectors did improve my performance a little bit but
> > stripe_cache+read_ahead were the main optimizations that made everything
> > go faster by about ~1.5x. I have individual bonnie++ be
ev/md3 of=/dev/null bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 398.069 seconds, 27.0 MB/s
Awful performance with your numbers/drop_caches settings.. !
What were your tests designed to show?
Justin.
On Fri, 12 Jan 2007, Justin Piszcz wrote:
>
>
On Fri, 12 Jan 2007, Al Boldi wrote:
> Justin Piszcz wrote:
> > RAID 5 TWEAKED: 1:06.41 elapsed @ 60% CPU
> >
> > This should be 1:14 not 1:06(was with a similarly sized file but not the
> > same) the 1:14 is the same file as used with the other benchmarks. and t
chunk size)
On Fri, 12 Jan 2007, Justin Piszcz wrote:
>
>
> On Fri, 12 Jan 2007, Michael Tokarev wrote:
>
> > Justin Piszcz wrote:
> > > Using 4 raptor 150s:
> > >
> > > Without the tweaks, I get 111MB/s write and 87MB/s read.
> >
On Fri, 12 Jan 2007, Michael Tokarev wrote:
> Justin Piszcz wrote:
> > Using 4 raptor 150s:
> >
> > Without the tweaks, I get 111MB/s write and 87MB/s read.
> > With the tweaks, 195MB/s write and 211MB/s read.
> >
> > Using kernel 2.6.19.1.
> >
On Fri, 12 Jan 2007, Michael Tokarev wrote:
Justin Piszcz wrote:
Using 4 raptor 150s:
Without the tweaks, I get 111MB/s write and 87MB/s read.
With the tweaks, 195MB/s write and 211MB/s read.
Using kernel 2.6.19.1.
Without the tweaks and with the tweaks:
# Stripe tests
chunk size)
On Fri, 12 Jan 2007, Justin Piszcz wrote:
On Fri, 12 Jan 2007, Michael Tokarev wrote:
Justin Piszcz wrote:
Using 4 raptor 150s:
Without the tweaks, I get 111MB/s write and 87MB/s read.
With the tweaks, 195MB/s write and 211MB/s read.
Using kernel 2.6.19.1
On Fri, 12 Jan 2007, Al Boldi wrote:
Justin Piszcz wrote:
RAID 5 TWEAKED: 1:06.41 elapsed @ 60% CPU
This should be 1:14 not 1:06(was with a similarly sized file but not the
same) the 1:14 is the same file as used with the other benchmarks. and to
get that I used 256mb read-ahead
out
10737418240 bytes (11 GB) copied, 398.069 seconds, 27.0 MB/s
Awful performance with your numbers/drop_caches settings.. !
What were your tests designed to show?
Justin.
On Fri, 12 Jan 2007, Justin Piszcz wrote:
On Fri, 12 Jan 2007, Al Boldi wrote:
Justin Piszcz wrote:
RAID 5
On Sat, 13 Jan 2007, Al Boldi wrote:
Justin Piszcz wrote:
Btw, max sectors did improve my performance a little bit but
stripe_cache+read_ahead were the main optimizations that made everything
go faster by about ~1.5x. I have individual bonnie++ benchmarks of
[only] the max_sector_kb
Using 4 raptor 150s:
Without the tweaks, I get 111MB/s write and 87MB/s read.
With the tweaks, 195MB/s write and 211MB/s read.
Using kernel 2.6.19.1.
Without the tweaks and with the tweaks:
# Stripe tests:
echo 8192 > /sys/block/md3/md/stripe_cache_size
# DD TESTS [WRITE]
DEFAULT: (512K)
$
Using 4 raptor 150s:
Without the tweaks, I get 111MB/s write and 87MB/s read.
With the tweaks, 195MB/s write and 211MB/s read.
Using kernel 2.6.19.1.
Without the tweaks and with the tweaks:
# Stripe tests:
echo 8192 /sys/block/md3/md/stripe_cache_size
# DD TESTS [WRITE]
DEFAULT: (512K)
$ dd
I had the same problem you did when I put 3 identical controllers
together. To get around that problem I used 2 TX133s and 1 TX100x2. I
believe this is the root cause of your problems.
Justin.
On Tue, 26 Dec 2006, Erik Ohrnberger wrote:
> First off, Merry Christmas, Seasons Greetings and
On Mon, 25 Dec 2006, Robert Hancock wrote:
> Justin Piszcz wrote:
> > I am using a dual port Intel NIC on an A-Bit IC7-G; any reason why I get
> > these?
> >
> > [4298634.444000] eth2: TX underrun, threshold adjusted.
> > [4299146.645000] eth2
On Mon, 25 Dec 2006, Robert Hancock wrote:
Justin Piszcz wrote:
I am using a dual port Intel NIC on an A-Bit IC7-G; any reason why I get
these?
[4298634.444000] eth2: TX underrun, threshold adjusted.
[4299146.645000] eth2: TX underrun, threshold adjusted.
...
I am using
I had the same problem you did when I put 3 identical controllers
together. To get around that problem I used 2 TX133s and 1 TX100x2. I
believe this is the root cause of your problems.
Justin.
On Tue, 26 Dec 2006, Erik Ohrnberger wrote:
First off, Merry Christmas, Seasons Greetings and
I am using a dual port Intel NIC on an A-Bit IC7-G; any reason why I get
these?
[4298634.444000] eth2: TX underrun, threshold adjusted.
[4299146.645000] eth2: TX underrun, threshold adjusted.
[4299146.645000] eth2: TX underrun, threshold adjusted.
[4299147.437000] eth2: TX underrun, threshold
I am using a dual port Intel NIC on an A-Bit IC7-G; any reason why I get
these?
[4298634.444000] eth2: TX underrun, threshold adjusted.
[4299146.645000] eth2: TX underrun, threshold adjusted.
[4299146.645000] eth2: TX underrun, threshold adjusted.
[4299147.437000] eth2: TX underrun, threshold
Thanks for the info!
On Mon, 18 Dec 2006, Trond Myklebust wrote:
> On Mon, 2006-12-18 at 14:21 -0500, Justin Piszcz wrote:
> > I have a question I could not quickly find on Google/mailing lists--
> >
> > Say I have some sort of global filesystem or NFS which is 200TB.
>
I have a question I could not quickly find on Google/mailing lists--
Say I have some sort of global filesystem or NFS which is 200TB.
Is there a limit either:
A) In the Linux kernel
or
B) In the NFS spec
That would limit the client as to what it could see via NFS or global
filesystem?
Or
I have a question I could not quickly find on Google/mailing lists--
Say I have some sort of global filesystem or NFS which is 200TB.
Is there a limit either:
A) In the Linux kernel
or
B) In the NFS spec
That would limit the client as to what it could see via NFS or global
filesystem?
Or
Thanks for the info!
On Mon, 18 Dec 2006, Trond Myklebust wrote:
On Mon, 2006-12-18 at 14:21 -0500, Justin Piszcz wrote:
I have a question I could not quickly find on Google/mailing lists--
Say I have some sort of global filesystem or NFS which is 200TB.
Is there a limit either
I'm not sure what is causing this problem but I was curious is this on a
32bit or 64bit platform?
Justin.
On Tue, 12 Dec 2006, Haar János wrote:
> Hello, list,
>
> I am the "big red button men" with the one big 14TB xfs, if somebody can
> remember me. :-)
>
> Now i found something in the
I'm not sure what is causing this problem but I was curious is this on a
32bit or 64bit platform?
Justin.
On Tue, 12 Dec 2006, Haar János wrote:
Hello, list,
I am the big red button men with the one big 14TB xfs, if somebody can
remember me. :-)
Now i found something in the 2.6.16.18,
Also,
Part of the problem may be that I have two ATA/133 Promise cards in one
box and only one ATA/133 in the other box.
Kernel 2.6.13 has fixed the problem with one ATA/133 card in the box.
Kernel 2.6.13 has not fixed the problem with two ATA/133 cards in the box.
FYI
Justin.
On Mon, 5
I have a box where I keep getting this in dmesg:
ACPI: PCI Interrupt :01:00.0[A] -> Link [LNKD] -> GSI 5 (level, low)
-> IRQ 5
ACPI: PCI Interrupt :01:00.0[A] -> Link [LNKD] -> GSI 5 (level, low)
-> IRQ 5
ACPI: PCI Interrupt :01:00.0[A] -> Link [LNKD] -> GSI 5 (level, low)
-> IRQ
I have a box where I keep getting this in dmesg:
ACPI: PCI Interrupt :01:00.0[A] - Link [LNKD] - GSI 5 (level, low)
- IRQ 5
ACPI: PCI Interrupt :01:00.0[A] - Link [LNKD] - GSI 5 (level, low)
- IRQ 5
ACPI: PCI Interrupt :01:00.0[A] - Link [LNKD] - GSI 5 (level, low)
- IRQ 5
ACPI:
Also,
Part of the problem may be that I have two ATA/133 Promise cards in one
box and only one ATA/133 in the other box.
Kernel 2.6.13 has fixed the problem with one ATA/133 card in the box.
Kernel 2.6.13 has not fixed the problem with two ATA/133 cards in the box.
FYI
Justin.
On Mon, 5
On 2.6.13, I have a simple script that tars the data from the root
filesystem to a 400GB disk, when this started, I got the following errors
and then the machine locked up:
Again, 400GB/Seagate+ATA/133, someone should add to the CONFIG_OPTION that
400GB drives are NOT supported w/ the Promise
On 2.6.13, I have a simple script that tars the data from the root
filesystem to a 400GB disk, when this started, I got the following errors
and then the machine locked up:
Again, 400GB/Seagate+ATA/133, someone should add to the CONFIG_OPTION that
400GB drives are NOT supported w/ the Promise
I still get this error when the drive is on a Promise ATA/133 card.
I have the same setup in two separate machines, the results are the same
with kernel 2.6.13, ideas?
Should I just get more ATA/100 cards and stop trying to figure out what
the bug is? Keep in mind the Promise ATA/100 cards
I still get this error when the drive is on a Promise ATA/133 card.
I have the same setup in two separate machines, the results are the same
with kernel 2.6.13, ideas?
Should I just get more ATA/100 cards and stop trying to figure out what
the bug is? Keep in mind the Promise ATA/100 cards
LL support qqqk
x x[ ] IDE Taskfile Access
Anyone have any suggestions how I can solve this problem?
On Wed, 31 Aug 2005, Justin Piszcz wrote:
All,
I am trying to get everyone together on this to hopefully solve a serious bug
that I have seen on multiple machines with:
a)
All,
I am trying to get everyone together on this to hopefully solve a serious
bug that I have seen on multiple machines with:
a) A Promise ATA/133 controller (ATA/100 works OK)
b) Kernel 2.6.12 or 2.6.13 (2.6.13-rc7 appears to be OK)
The drive is a Seagate 7200.8 400GB 7200RPM 8MB cache
All,
I am trying to get everyone together on this to hopefully solve a serious
bug that I have seen on multiple machines with:
a) A Promise ATA/133 controller (ATA/100 works OK)
b) Kernel 2.6.12 or 2.6.13 (2.6.13-rc7 appears to be OK)
The drive is a Seagate 7200.8 400GB 7200RPM 8MB cache
qqqk
x x[ ] IDE Taskfile Access
Anyone have any suggestions how I can solve this problem?
On Wed, 31 Aug 2005, Justin Piszcz wrote:
All,
I am trying to get everyone together on this to hopefully solve a serious bug
that I have seen on multiple machines with:
a) A Promise
Yes, I have two separate machines with the same controller and HDD.
As soon as I found out it fixed the bug on one of them, I changed it on
the other, neither machine has crashed since.
On Fri, 26 Aug 2005, Patrick McFarland wrote:
On Friday 26 August 2005 05:36 pm, Justin Piszcz wrote:
2
Yes, I have two separate machines with the same controller and HDD.
As soon as I found out it fixed the bug on one of them, I changed it on
the other, neither machine has crashed since.
On Fri, 26 Aug 2005, Patrick McFarland wrote:
On Friday 26 August 2005 05:36 pm, Justin Piszcz wrote:
2
These options are self-explanatory:
x x ( ) No Forced Preemption (Server) x
xx x ( ) Voluntary Kernel Preemption (Desktop) x
xx x (X) Preemptible Kernel (Low-Latency Desktop) x x
It says 100 HZ or 250 HZ is
These options are self-explanatory:
x x ( ) No Forced Preemption (Server) x
xx x ( ) Voluntary Kernel Preemption (Desktop) x
xx x (X) Preemptible Kernel (Low-Latency Desktop) x x
It says 100 HZ or 250 HZ is
It appears that 2.6.13-rc7 has fixed the bug.
I would like to know *What* changed, but I'll probably never find out :(
On Thu, 28 Jul 2005, Andrew Morton wrote:
Justin Piszcz <[EMAIL PROTECTED]> wrote:
I have two different machines with the 7200.8 Seagate 8MB 400GB drives.
Both have A
I have three different Maxtor (promise) ATA/133 controllers, it happens
with all three.
On Fri, 26 Aug 2005, Patrick McFarland wrote:
On Friday 26 August 2005 05:36 pm, Justin Piszcz wrote:
2- ATA/133 Maxtor (ATA/Promise Controller)
Make sure its actually the kernel
Kernel 2.6.12.5:
1- 400GB Seagate 8MB cache, 7200RPM, ATA/100 drive.
2- ATA/133 Maxtor (ATA/Promise Controller)
1) Attached 400GB to Seagate 400GB drive.
2) (Not mounted yet)
3) See below
hde: 781422768 sectors (400088 MB) w/8192KiB Cache, CHS=48641/255/63,
UDMA(100)
4) Partition with fdisk
Kernel 2.6.12.5:
1- 400GB Seagate 8MB cache, 7200RPM, ATA/100 drive.
2- ATA/133 Maxtor (ATA/Promise Controller)
1) Attached 400GB to Seagate 400GB drive.
2) (Not mounted yet)
3) See below
hde: 781422768 sectors (400088 MB) w/8192KiB Cache, CHS=48641/255/63,
UDMA(100)
4) Partition with fdisk
I have three different Maxtor (promise) ATA/133 controllers, it happens
with all three.
On Fri, 26 Aug 2005, Patrick McFarland wrote:
On Friday 26 August 2005 05:36 pm, Justin Piszcz wrote:
2- ATA/133 Maxtor (ATA/Promise Controller)
Make sure its actually the kernel
It appears that 2.6.13-rc7 has fixed the bug.
I would like to know *What* changed, but I'll probably never find out :(
On Thu, 28 Jul 2005, Andrew Morton wrote:
Justin Piszcz [EMAIL PROTECTED] wrote:
I have two different machines with the 7200.8 Seagate 8MB 400GB drives.
Both have ATA/133
[*] HPET Timer Support
[*] Provide RTC interrupt
[*] HPET - High Precision Event Timer
[*] Allow mmap of HPET
http://tlug.up.ac.za/guides/lkcg/arch_i386.html
HPET Timer Support HPET_TIMER
This enables the use of the HPET for the kernel's internal timer. HPET is
the next generation
[*] HPET Timer Support
[*] Provide RTC interrupt
[*] HPET - High Precision Event Timer
[*] Allow mmap of HPET
http://tlug.up.ac.za/guides/lkcg/arch_i386.html
HPET Timer Support HPET_TIMER
This enables the use of the HPET for the kernel's internal timer. HPET is
the next generation
I have three machines with the same motherboard and gigabit ethernet, ABIT
IC7-G.
Two are Linux (Debian)
One is Windows 2000.
When I copy 100 gigabytes from a Windows 2000 PC to either one of my Linux
machines, I get a *SUSTAINED* transfer rate of 40-50MB/s over gigabit.
Sustained meaning,
I have three machines with the same motherboard and gigabit ethernet, ABIT
IC7-G.
Two are Linux (Debian)
One is Windows 2000.
When I copy 100 gigabytes from a Windows 2000 PC to either one of my Linux
machines, I get a *SUSTAINED* transfer rate of 40-50MB/s over gigabit.
Sustained meaning,
After a couple hours of use, I get this error on a linear RAID under
2.6.12.2 using loop-AES w/AES-256 encrypted filesystem.
Anyone know what is wrong?
Filesystem "loop1": XFS internal error xfs_da_do_buf(2) at line 2271 of
file fs/xfs/xfs_da_btree.c. Caller 0xc025e807
[]
After a couple hours of use, I get this error on a linear RAID under
2.6.12.2 using loop-AES w/AES-256 encrypted filesystem.
Anyone know what is wrong?
Filesystem loop1: XFS internal error xfs_da_do_buf(2) at line 2271 of
file fs/xfs/xfs_da_btree.c. Caller 0xc025e807
[c025e3f0]
General Question:
Would a desktop or server benefit more from SMT?
For a Pentium 4 w/HT, we use SMP.
What are the advantages/disadvantages of using SMT in the kernel?
Thanks,
Justin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
General Question:
Would a desktop or server benefit more from SMT?
For a Pentium 4 w/HT, we use SMP.
What are the advantages/disadvantages of using SMT in the kernel?
Thanks,
Justin.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
What is this e-mail about?
Something in the kernel changed regarding the Intel e1000 driver from
2.6.5 to 2.6.10. The change resulted in thousands of errors when the NIC
is receiving data. For the past two weeks I have thought about this and
tried everything I could think of, it had really been
What is this e-mail about?
Something in the kernel changed regarding the Intel e1000 driver from
2.6.5 to 2.6.10. The change resulted in thousands of errors when the NIC
is receiving data. For the past two weeks I have thought about this and
tried everything I could think of, it had really been
[BoxB]RX packets:446380046 errors:1276833 dropped:1276833
overruns:1276833 frame:0
TX packets:572550636 errors:0 dropped:0 overruns:0 carrier:0
Justin Piszcz wrote:
I have two identical machines [mobo/hardware wise]:
Each machine is a Dell GX1p (500MHZ).
I have two
:446380046 errors:1276833 dropped:1276833
overruns:1276833 frame:0
TX packets:572550636 errors:0 dropped:0 overruns:0 carrier:0
Justin Piszcz wrote:
I have two identical machines [mobo/hardware wise]:
Each machine is a Dell GX1p (500MHZ).
I have two Intel Gigabit NICs, one in each box
I have two identical machines [mobo/hardware wise]:
Each machine is a Dell GX1p (500MHZ).
I have two Intel Gigabit NICs, one in each box, hooked up to a GigE
switch.
Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller
Ethernet controller: Intel Corp. 82541GI/PI Gigabit
I have two identical machines [mobo/hardware wise]:
Each machine is a Dell GX1p (500MHZ).
I have two Intel Gigabit NICs, one in each box, hooked up to a GigE
switch.
Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller
Ethernet controller: Intel Corp. 82541GI/PI Gigabit
Yeah, I can try 2.4.29 later tonight; also, the DVD is not scratched, just
formatted with Joilet/ISO instead of UDF (which is what should be used on
DVDs).
However, dd if=/dev/hdh of=file.img
Even with bs=1 for 1 byte at a time, there seems to be no way to
get the data off,
I have a DVD where I have three files on it, (1.7gb,1.7gb,900mb).
On W2K, when I try to copy the second file, I get a BadCRC error message.
Under Linux, I copy up to about 860MB (watched via pipebench) and then it
freezes the machine, I cannot ping or get to it or do anything on the
console;
I have a DVD where I have three files on it, (1.7gb,1.7gb,900mb).
On W2K, when I try to copy the second file, I get a BadCRC error message.
Under Linux, I copy up to about 860MB (watched via pipebench) and then it
freezes the machine, I cannot ping or get to it or do anything on the
console;
Yeah, I can try 2.4.29 later tonight; also, the DVD is not scratched, just
formatted with Joilet/ISO instead of UDF (which is what should be used on
DVDs).
However, dd if=/dev/hdh of=file.img
Even with bs=1 for 1 byte at a time, there seems to be no way to
get the data off,
Ahh, very nice, thanks!
On Sat, 5 Feb 2005, Randy.Dunlap wrote:
Justin Piszcz wrote:
Why are there only 7-8 loop devices available?
What options do I have if I want to mount, say, 100 isos?
Documentation/kernel-parameters.txt say:
max_loop= [LOOP] Maximum number of loopback devices that can
Why are there only 7-8 loop devices available?
What options do I have if I want to mount, say, 100 isos?
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Why are there only 7-8 loop devices available?
What options do I have if I want to mount, say, 100 isos?
Thanks.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ahh, very nice, thanks!
On Sat, 5 Feb 2005, Randy.Dunlap wrote:
Justin Piszcz wrote:
Why are there only 7-8 loop devices available?
What options do I have if I want to mount, say, 100 isos?
Documentation/kernel-parameters.txt say:
max_loop= [LOOP] Maximum number of loopback devices that can
Yes, only with NFS.
On Mon, 17 Jan 2005, Norbert van Nobelen wrote:
Only with NFS? I have a raid array of the same discs and the system just
sometimes seems to hang completely (for a second or less) and then to go on
again at a normal speed (110MB/s).
I am running a SuSE 9.1 stock kernel
When writing to or from the drive via NFS, after 1GB or 2GB, it "feels"
like the system slows to a crawl, the mouse gets very slow, almost like
one is burning a CD at 52X under PIO mode. I originally had this disk in
my main system with an Intel ICH5 chipset (ABIT IC7-G mobo) and a Pentium
4
When writing to or from the drive via NFS, after 1GB or 2GB, it feels
like the system slows to a crawl, the mouse gets very slow, almost like
one is burning a CD at 52X under PIO mode. I originally had this disk in
my main system with an Intel ICH5 chipset (ABIT IC7-G mobo) and a Pentium
4
Yes, only with NFS.
On Mon, 17 Jan 2005, Norbert van Nobelen wrote:
Only with NFS? I have a raid array of the same discs and the system just
sometimes seems to hang completely (for a second or less) and then to go on
again at a normal speed (110MB/s).
I am running a SuSE 9.1 stock kernel
601 - 692 of 692 matches
Mail list logo
