2.4.6-pre6 and ext3-2.4-0.0.8-246p5 (had to to hand patch a little).
This message popped up on an idle system -- there were no "odd" cronjobs
scheduled around this time. Nobody was logged on. System had been up for
a
little over a day...first time seeing any messages like this.
The source
2.4.6-pre6 and ext3-2.4-0.0.8-246p5 (had to to hand patch a little).
This message popped up on an idle system -- there were no odd cronjobs
scheduled around this time. Nobody was logged on. System had been up for
a
little over a day...first time seeing any messages like this.
The source
I have been running successfully with qla2x00src-4.15Beta.tgz for several
months now over several kernel versions up to 2.4.5.
When I tested 2.4.6-pre6 I decided to use the qlogicfc driver -- BAD
MISTAKE!!!
#1 - My system had crashed (for a different reason) and when the raid5 was
resyncing and
I have been running successfully with qla2x00src-4.15Beta.tgz for several
months now over several kernel versions up to 2.4.5.
When I tested 2.4.6-pre6 I decided to use the qlogicfc driver -- BAD
MISTAKE!!!
#1 - My system had crashed (for a different reason) and when the raid5 was
resyncing and
OK guys -- how much money are you willing to be that TCP is guaranteed??
Since you don't want to talk OSI that's OK -- that's just to educate some
people.
Try this: (this is what I ran into years ago and had to argue to death).
#1 Client1 has tcp connection to Server1. Both machines are setup
OK guys -- how much money are you willing to be that TCP is guaranteed??
Since you don't want to talk OSI that's OK -- that's just to educate some
people.
Try this: (this is what I ran into years ago and had to argue to death).
#1 Client1 has tcp connection to Server1. Both machines are setup
den, Folkert van" <[EMAIL PROTECTED]>
To: "Mike Black" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, June 15, 2001 8:53 AM
Subject: RE: Client receives TCP packets but does not ACK
> TCP is NOT a guaranteed protocol -- you can't just blast data from on
Here's the end of my run -- I assume this means my config works OK?
I'm on a dual PIII/600 linux-2.4.6-pre3 -- ran it all on the local host.
received msg#90, name pad1, 1 blocks, 12 total bytes
received msg#91, name pad1, 1 blocks, 12 total bytes
received msg#92, name class
Here's the end of my run -- I assume this means my config works OK?
I'm on a dual PIII/600 linux-2.4.6-pre3 -- ran it all on the local host.
received msg#90, name pad1, 1 blocks, 12 total bytes
received msg#91, name pad1, 1 blocks, 12 total bytes
received msg#92, name class
]
To: Mike Black [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, June 15, 2001 8:53 AM
Subject: RE: Client receives TCP packets but does not ACK
TCP is NOT a guaranteed protocol -- you can't just blast data from one
port
to another and expect it to work.
Isn't it? Are you really sure about
2.4.2 works fine.
2.4.5-pre5 won't get past fsck of /dev/md0 -- locks up towards the end. I'm
running the same kernel on two other machine (different motherboards though)
I'm using gcc-3.0 and glibc-2.2.3
/dev/md0 is a dual-IDE RAID1 (2nd drive is currently disabled)
md0 : active raid1 hda1[0]
2.4.2 works fine.
2.4.5-pre5 won't get past fsck of /dev/md0 -- locks up towards the end. I'm
running the same kernel on two other machine (different motherboards though)
I'm using gcc-3.0 and glibc-2.2.3
/dev/md0 is a dual-IDE RAID1 (2nd drive is currently disabled)
md0 : active raid1 hda1[0]
Looks like if you remove the "inline" from the function definition this
compiles OK.
Michael D. Black Principal Engineer
[EMAIL PROTECTED] 321-676-2923,x203
http://www.csihq.com Computer Science Innovations
http://www.csihq.com/~mike My home page
FAX
Looks like if you remove the inline from the function definition this
compiles OK.
Michael D. Black Principal Engineer
[EMAIL PROTECTED] 321-676-2923,x203
http://www.csihq.com Computer Science Innovations
http://www.csihq.com/~mike My home page
FAX
Write caching is the culprit for the performance diff:
On IDE:
time xlog /blah.dat fsync
0.000u 0.190s 0:01.72 11.0% 0+0k 0+0io 91pf+0w
# hdparm -W 0 /dev/hda
/dev/hda:
setting drive write-caching to 0 (off)
# time xlog /blah.dat fsync
0.000u 0.220s 0:50.60 0.4% 0+0k 0+0io 91pf+0w
#
Write caching is the culprit for the performance diff:
On IDE:
time xlog /blah.dat fsync
0.000u 0.190s 0:01.72 11.0% 0+0k 0+0io 91pf+0w
# hdparm -W 0 /dev/hda
/dev/hda:
setting drive write-caching to 0 (off)
# time xlog /blah.dat fsync
0.000u 0.220s 0:50.60 0.4% 0+0k 0+0io 91pf+0w
#
Happens every night on both hda and hdc -- no sure yet what triggers it but
it is repeatable. Has happened since I've installed this machine with all
the 2.4.x series.
Jan 31 00:34:16 kernel: hdc: timeout waiting for DMA
Jan 31 00:34:16 kernel: ide_dmaproc: chipset supported ide_dma_timeout
Happens every night on both hda and hdc -- no sure yet what triggers it but
it is repeatable. Has happened since I've installed this machine with all
the 2.4.x series.
Jan 31 00:34:16 kernel: hdc: timeout waiting for DMA
Jan 31 00:34:16 kernel: ide_dmaproc: chipset supported ide_dma_timeout
How do normal users get to create/maintain large files (i.e. >2G) in Linux
2.4 on i386?
The root user can make filesize unlimited but a non-root user cannot. They
come up with the same limits in both tcsh and bash (i.e. filesize
1048576 kbytes or 0x4000)
I can't seem to find where this
ac10 oopsed but now ac11 oopses in a new place at the end of a RAID1 resync
operation when I tried to "more /proc/mdstat"
Unable to handle kernel NULL pointer dereference at virtual address 0038
printing EIP:
c01ba0f
Oops:
CPU: 0
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386
How do normal users get to create/maintain large files (i.e. 2G) in Linux
2.4 on i386?
The root user can make filesize unlimited but a non-root user cannot. They
come up with the same limits in both tcsh and bash (i.e. filesize
1048576 kbytes or 0x4000)
I can't seem to find where this
ac10 oopsed but now ac11 oopses in a new place at the end of a RAID1 resync
operation when I tried to "more /proc/mdstat"
Unable to handle kernel NULL pointer dereference at virtual address 0038
printing EIP:
c01ba0f
Oops:
CPU: 0
EIP: 0010:[c01ba0af]
Using defaults from ksymoops -t
At the end of rebuilding a RAID1 mirror set:
Oops:
CPU: 0
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 0010286
eax: ebx: f7ab284c ecx: edx: 0002
esi: f7a6ef60 edi: ebp: f7a63300 esp: f7a71ed8
ds: 0018 es: 0018 ss: 0018
Process
At the end of rebuilding a RAID1 mirror set:
Oops:
CPU: 0
EIP: 0010:[c01ba01f]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 0010286
eax: ebx: f7ab284c ecx: edx: 0002
esi: f7a6ef60 edi: ebp: f7a63300 esp: f7a71ed8
ds: 0018 es: 0018 ss: 0018
Now that bigmem and bigfiles are supported in 2.4.0 what's the maximum swap
size now?
I couldn't seem to find any reference to it.
Michael D. Black Principal Engineer
[EMAIL PROTECTED] 321-676-2923,x203
http://www.csihq.com Computer Science
Now that bigmem and bigfiles are supported in 2.4.0 what's the maximum swap
size now?
I couldn't seem to find any reference to it.
Michael D. Black Principal Engineer
[EMAIL PROTECTED] 321-676-2923,x203
http://www.csihq.com Computer Science
FYI -- the epic100 SMC EtherPower II card does NOT work in SMP mode on 2.4.0
(or 2.2.18 either).
Donald Becker's most recent version hasn't been forward-ported to 2.4 and
the 2.2.17 drivers won't compile either.
The SMC card DOES work in non-SMP machines. So...I'm putting in a 3com905
until
FYI -- the epic100 SMC EtherPower II card does NOT work in SMP mode on 2.4.0
(or 2.2.18 either).
Donald Becker's most recent version hasn't been forward-ported to 2.4 and
the 2.2.17 drivers won't compile either.
The SMC card DOES work in non-SMP machines. So...I'm putting in a 3com905
until
2.4.0-prerelease-ac5
Happens during boot right after the RAID checksumming speed is calculated
I don't have CONFIG_HIGHMEM
This is booting from floppy to a RAID5 system:
md3 : active raid5 sdc1[2] sdb1[1] sda1[0] 97691008 blocks level 5, 32k
chunk, algorithm 0 [3/3] [UUU]
Compiler is:
gcc
2.4.0-prerelease-ac5
Happens during boot right after the RAID checksumming speed is calculated
I don't have CONFIG_HIGHMEM
This is booting from floppy to a RAID5 system:
md3 : active raid5 sdc1[2] sdb1[1] sda1[0] 97691008 blocks level 5, 32k
chunk, algorithm 0 [3/3] [UUU]
Compiler is:
gcc
I've got three machines -- two are identical motherboards. I've been using
the same kernel binary on all three machines for over a year thru all the
upgrades since 2.2.15 (16, 17, and now 18aa2).
Now that I've compiled 2.2.18aa2 it only works on two of the machines. Both
of these use RAID1/IDE
I've got three machines -- two are identical motherboards. I've been using
the same kernel binary on all three machines for over a year thru all the
upgrades since 2.2.15 (16, 17, and now 18aa2).
Now that I've compiled 2.2.18aa2 it only works on two of the machines. Both
of these use RAID1/IDE
include/linux/signal.h
There's a couple like this -- isn't this case statement upside down???
extern inline void siginitset(sigset_t *set, unsigned long mask)
{
set->sig[0] = mask;
switch (_NSIG_WORDS) {
default:
memset(>sig[1], 0,
include/linux/signal.h
There's a couple like this -- isn't this case statement upside down???
extern inline void siginitset(sigset_t *set, unsigned long mask)
{
set-sig[0] = mask;
switch (_NSIG_WORDS) {
default:
memset(set-sig[1], 0,
On my dual-SMP system:
cpu 15706258 0 4077925 308293017
cpu0 7877393 0 2034458 154126749
cpu1 7828865 0 2043467 154166268
On my other dual-SMP with only one CPU in it:
cpu 7364 0 5108 992193
cpu0 7364 0 5108 992193
On my non-SMP system:
cpu 16922 0 8096 968425
cpu0 16922 0 8096 968425
All
On my dual-SMP system:
cpu 15706258 0 4077925 308293017
cpu0 7877393 0 2034458 154126749
cpu1 7828865 0 2043467 154166268
On my other dual-SMP with only one CPU in it:
cpu 7364 0 5108 992193
cpu0 7364 0 5108 992193
On my non-SMP system:
cpu 16922 0 8096 968425
cpu0 16922 0 8096 968425
All
I just found out that gcc-2.96 won't compile glibc-2.1.93 or glibc-2.1.2 or
glibc-2.1.3 successfully whereas gcc-2.95.2 will. It bombs in a couple of
places.
I just downgraded my machine to 2.95.2 to prove the point. Guess I'll wait
for gcc-3.0.
Michael
I just found out that gcc-2.96 won't compile glibc-2.1.93 or glibc-2.1.2 or
glibc-2.1.3 successfully whereas gcc-2.95.2 will. It bombs in a couple of
places.
I just downgraded my machine to 2.95.2 to prove the point. Guess I'll wait
for gcc-3.0.
Michael
38 matches
Mail list logo
