I have a rackmount server that has a dual port onboard 82546EB card.
I've googled and seen this card apparently active with other users but
I seem to only get checksum errors.
[0.194129] Intel(R) PRO/1000 Network Driver - version 7.3.15-k2-NAPI
[0.194234] Copyright (c) 1999-2006 Intel
I have a rackmount server that has a dual port onboard 82546EB card.
I've googled and seen this card apparently active with other users but
I seem to only get checksum errors.
[0.194129] Intel(R) PRO/1000 Network Driver - version 7.3.15-k2-NAPI
[0.194234] Copyright (c) 1999-2006 Intel
(please CC me when replying)
I just got a motherboard with the dual nic marvell chipset onboard.
Splendid board save for the driver issue I'm having :) I'm currently
using 2.6.19-gentoo-r4 which doesn't have any forcedeth patch applied, a
vanilla kernel seems to give the same results. This
(please CC me when replying)
I just got a motherboard with the dual nic marvell chipset onboard.
Splendid board save for the driver issue I'm having :) I'm currently
using 2.6.19-gentoo-r4 which doesn't have any forcedeth patch applied, a
vanilla kernel seems to give the same results. This
I've a quick question before I start digging through patches between .12
and .13-rc3, /dev/input/mice (usb mice) stopped yielding data. dmesg
indicates removal/re-insertion of the device but no driver registers and
nothing comes from /dev/input/mice.
I have rc-3 on other machines and the
I've a quick question before I start digging through patches between .12
and .13-rc3, /dev/input/mice (usb mice) stopped yielding data. dmesg
indicates removal/re-insertion of the device but no driver registers and
nothing comes from /dev/input/mice.
I have rc-3 on other machines and the
It seems that 2.6.12-rc1 introduced an ALSA bug generating an oops for a
null pointer.
codec_semaphore: semaphore is not ready [0x1][0x300300]
codec_read 0: semaphore is not ready for register 0x2c
Unable to handle kernel NULL pointer dereference at virtual address
printing eip:
It seems that 2.6.12-rc1 introduced an ALSA bug generating an oops for a
null pointer.
codec_semaphore: semaphore is not ready [0x1][0x300300]
codec_read 0: semaphore is not ready for register 0x2c
Unable to handle kernel NULL pointer dereference at virtual address
printing eip:
I would also appreciate the return of good resolution. Blocky mouse
startup moves make graphic editing rather difficult. No mouse movement
until I have moved my finger a significant distance then the mouse all
of a sudden jumps a dozen pixels before it "smoothly" glides along.
I would also
I would also appreciate the return of good resolution. Blocky mouse
startup moves make graphic editing rather difficult. No mouse movement
until I have moved my finger a significant distance then the mouse all
of a sudden jumps a dozen pixels before it smoothly glides along.
I would also
use a minimum resolution until you detect motion then switch to high
resolution.
-
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
Please read the FAQ at
use a minimum resolution until you detect motion then switch to high
resolution.
-
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
Please read the FAQ at
What does one need to do to:
a) put tapping back in, and
b) fix the severe jerkiness with small movements
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
What does one need to do to:
a) put tapping back in, and
b) fix the severe jerkiness with small movements
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
PMTU bug -- or better said, bad firewall admin who blocks all ICMP.
http://blue-labs.org/clue/mtu-mss.php
-david
David Brownell wrote:
I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64).
But oddly enough, only for sending mail, not reading it; and not through
other
PMTU bug -- or better said, bad firewall admin who blocks all ICMP.
http://blue-labs.org/clue/mtu-mss.php
-david
David Brownell wrote:
I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64).
But oddly enough, only for sending mail, not reading it; and not through
other
It looks like you don't have 'lo' configured, i.e. your 127.0.0.1 interface.
David
Michal Margula wrote:
>Hello!
>
>My friend told me to noticed you about problems I had with 2.4.x line of
>kernels. I started up from 2.4.3. Under heavy load I was getting
>messages from telnet, ping, nmap "No
It looks like you don't have 'lo' configured, i.e. your 127.0.0.1 interface.
David
Michal Margula wrote:
Hello!
My friend told me to noticed you about problems I had with 2.4.x line of
kernels. I started up from 2.4.3. Under heavy load I was getting
messages from telnet, ping, nmap No buffer
BTW, you ONLY need to echo 1 > /proc../sysrq if you use a distribution
that puts a 0 there on init.
By default the kernel initializes with '1'.
David
>>>I compiled it, and the sysrq is definitely in the config. No doubt at
>>>all. I also use make mrproper and config again before dep and
BTW, you ONLY need to echo 1 /proc../sysrq if you use a distribution
that puts a 0 there on init.
By default the kernel initializes with '1'.
David
I compiled it, and the sysrq is definitely in the config. No doubt at
all. I also use make mrproper and config again before dep and actual
Quite positive it's the right map file. I used -m and specified the
exact file.
David
Jeff Garzik wrote:
>David Ford wrote:
>
>> >>EIP; c01269f9<=
>>Trace; c01b1021
>>Trace; c01b1c43
>>Trace; c01b2643
>>Trace; c0137fc0 <__emul
2.4.5-ac8 has a brokenness about it.
sshd stalled in [down] with the following, subsequent sshd attempts
which needed a tty resulted in D state the same as the first:
invalid operand:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax:
2.4.5-ac8 has a brokenness about it.
sshd stalled in [down] with the following, subsequent sshd attempts
which needed a tty resulted in D state the same as the first:
invalid operand:
CPU:0
EIP:0010:[c01269f9]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
Quite positive it's the right map file. I used -m and specified the
exact file.
David
Jeff Garzik wrote:
David Ford wrote:
EIP; c01269f9 proc_getdata+4d/154 =
Trace; c01b1021 read_eeprom+131/1a8
Trace; c01b1c43 rtl8139_tx_timeout+143/148
Trace; c01b2643 rtl8139_interrupt+5f/170
Trace
Is there an example somewhere of this?
David
>You can push a BPF (LPF) filter expression onto a LISTEN socket that checks
>every incoming packet using SO_ATTACH_FILTER.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Is there an example somewhere of this?
David
You can push a BPF (LPF) filter expression onto a LISTEN socket that checks
every incoming packet using SO_ATTACH_FILTER.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Alrighty. That eliminates the patch. I'll rewrite the ixj.c according
to this. ixj.c will be a large patch due to the numerous revisions, I
don't know how well it can be broken up into small pieces. Do you want
small pieces still? The ChangeLog shows all the fixes for the
revisions.
Alrighty. That eliminates the patch. I'll rewrite the ixj.c according
to this. ixj.c will be a large patch due to the numerous revisions, I
don't know how well it can be broken up into small pieces. Do you want
small pieces still? The ChangeLog shows all the fixes for the
revisions.
works with unit!=PHONE_UNIT_ANY
+ *
+ * May 12 2001 David Ford, <[EMAIL PROTECTED]>
+ * brought kernel version up to date with CVS, minor changes
*/
+#if LINUX_VERSION_CODE < 0x020400
+#include
+#endif
#include
#include
#include
@@ -23,13 +29,16 @@
#inc
with unit!=PHONE_UNIT_ANY
+ *
+ * May 12 2001 David Ford, [EMAIL PROTECTED]
+ * brought kernel version up to date with CVS, minor changes
*/
+#if LINUX_VERSION_CODE 0x020400
+#include linux/config.h
+#endif
#include linux/version.h
#include linux/module.h
#include linux
I simply crontab an ECN off period for five minutes every hour and flush
the mail queue.
David.
Holger Lubitz wrote:
>"H. Peter Anvin" wrote:
>
>>I suspect that the main way to get this thing fixed is to make sure
>>ECN is enabled on the server side; for example, we have turned on ECN
>>on
I simply crontab an ECN off period for five minutes every hour and flush
the mail queue.
David.
Holger Lubitz wrote:
H. Peter Anvin wrote:
I suspect that the main way to get this thing fixed is to make sure
ECN is enabled on the server side; for example, we have turned on ECN
on kernel.org.
Second time around, I didn't evoke any interest the first time.
I reported it back on Mar/27. It is still an almost daily problem
requiring a reboot. Mozilla gets stuck in down_write_failed. This time
I'm sure it's not reiser's fault.
# uname -r
2.4.3-pre8
mozilla-bin D C781849C 0
Second time around, I didn't evoke any interest the first time.
I reported it back on Mar/27. It is still an almost daily problem
requiring a reboot. Mozilla gets stuck in down_write_failed. This time
I'm sure it's not reiser's fault.
# uname -r
2.4.3-pre8
mozilla-bin D C781849C 0
Ok, here's the trace, this time it didn't die on me.
mozilla-bin D CDC1779C 0 6530 1(NOTLB) 6533
Call Trace: [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] [] []
[scsi_queue_next_request+62/248] [__scsi_end_request+327/340]
Lately I've been having to reboot every few days due to D state
processes, always mozilla so far. When I exit mozilla it doesn't always
cleanly shutdown, sometimes processes are left behind. I'll post what I
have and if I'm lucky I'll follow up with a backtrace on the pids. Last
time I tried a
Lately I've been having to reboot every few days due to D state
processes, always mozilla so far. When I exit mozilla it doesn't always
cleanly shutdown, sometimes processes are left behind. I'll post what I
have and if I'm lucky I'll follow up with a backtrace on the pids. Last
time I tried a
Ok, here's the trace, this time it didn't die on me.
mozilla-bin D CDC1779C 0 6530 1(NOTLB) 6533
Call Trace: [ff00] [ff00] [ff00] [e000]
[e000] [e000] [e000]
[e000] [e000] [e000] [e000] [e000]
[e000]
Otto Wyss wrote:
> > No, the correct answer is if you want a reliable recovery then run your disks
> > in non write buffered mode. I.e. turn on sync in fstab.
> >
> You probably haven't tried to use sync or you would have noticed the
> performace penalty. I think nobody really considers sync an
Otto Wyss wrote:
No, the correct answer is if you want a reliable recovery then run your disks
in non write buffered mode. I.e. turn on sync in fstab.
You probably haven't tried to use sync or you would have noticed the
performace penalty. I think nobody really considers sync an
Otto Wyss wrote:
> > I had a similar experience:
> > X crashed , hosing the console , so I could not initiate
> > a proper shutdown.
> >
> > Here I must note that the response you got on linux-kernel is
> > shameful.
> >
> Thanks, but I expected it a little bit. All around Linux is centered
>
Otto Wyss wrote:
I had a similar experience:
X crashed , hosing the console , so I could not initiate
a proper shutdown.
Here I must note that the response you got on linux-kernel is
shameful.
Thanks, but I expected it a little bit. All around Linux is centered
around getting the
a) not all drivers are created equal
b) esd should check the return value anyway
-d
Doug Ledford wrote:
> David Ford wrote:
> >
> > Actually you probably upgraded to a non-broken version of esd. Stock esd -still-
> > writes to the socket without regard to return valu
Actually you probably upgraded to a non-broken version of esd. Stock esd -still-
writes to the socket without regard to return value. If the write only accepted
2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at
4097, not 2099. esd is incredibly bad about err
Actually you probably upgraded to a non-broken version of esd. Stock esd -still-
writes to the socket without regard to return value. If the write only accepted
2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at
4097, not 2099. esd is incredibly bad about err
a) not all drivers are created equal
b) esd should check the return value anyway
-d
Doug Ledford wrote:
David Ford wrote:
Actually you probably upgraded to a non-broken version of esd. Stock esd -still-
writes to the socket without regard to return value. If the write only accepted
2.4.2-ac4
Undo partial loss 208.179.59.2/5432 c1 l1 ss2/2 p1
Undo loss 208.179.59.2/5432 c2 l0 ss2/2 p0
Undo loss 208.179.59.2/25 c2 l0 ss2/2 p0
Undo partial loss 208.179.59.2/22 c1 l3 ss2/2 p3
Undo loss 208.179.59.2/143 c2 l0 ss2/3 p0
simple debug messages, or is someone (andy/dave) interested
2.4.3-pre3
richh12557 0.0 0.7 5096 1704 pts/10 D04:32 0:00 ./egg
idaho
richh12558 0.0 0.0 00 pts/10 Z04:32 0:00 [egg
]
richh12560 0.0 0.7 5096 1704 pts/10 S04:32 0:00 ./egg
idaho
# ps -eo args,wchan|grep egg
./egg idaho down
[egg ]
2.4.3-pre3
richh12557 0.0 0.7 5096 1704 pts/10 D04:32 0:00 ./egg
idaho
richh12558 0.0 0.0 00 pts/10 Z04:32 0:00 [egg
defunct]
richh12560 0.0 0.7 5096 1704 pts/10 S04:32 0:00 ./egg
idaho
# ps -eo args,wchan|grep egg
./egg idaho down
[egg
2.4.2-ac4
Undo partial loss 208.179.59.2/5432 c1 l1 ss2/2 p1
Undo loss 208.179.59.2/5432 c2 l0 ss2/2 p0
Undo loss 208.179.59.2/25 c2 l0 ss2/2 p0
Undo partial loss 208.179.59.2/22 c1 l3 ss2/2 p3
Undo loss 208.179.59.2/143 c2 l0 ss2/3 p0
simple debug messages, or is someone (andy/dave) interested
Alan Cox wrote:
>> I run Reiser on all but /boot, and it seems to enjoy corrupting my
>> mbox'es randomly.
>> Using the old-style Reiser FS format, 2.4.2-pre1, Evolution, on a CMD640
>> chipset with the fixes enabled.
>> This also occurs in some log files, but I put it down to syslogd
>>
Alan Cox wrote:
I run Reiser on all but /boot, and it seems to enjoy corrupting my
mbox'es randomly.
Using the old-style Reiser FS format, 2.4.2-pre1, Evolution, on a CMD640
chipset with the fixes enabled.
This also occurs in some log files, but I put it down to syslogd
crashing or
Chris Mason wrote:
>
> On Thursday, February 01, 2001 02:16:43 PM -0200 Rik van Riel
><[EMAIL PROTECTED]> wrote:
>
>> About the system hanging completely, I wonder if it goes
>> away by pressing sysrq-S (sync all disks). If it does,
>> maybe Reiserfs was blocking all the pages in the inactive
How about a simple patch to the top level makefile that checks the gcc
version then prints a distinct message ..'this compiler hasn't been approved
for compiling the kernel', sleeping for one second, then continuing on. This
solution doesn't stop compiling and makes a visible indicator without
How about a simple patch to the top level makefile that checks the gcc
version then prints a distinct message ..'this compiler hasn't been approved
for compiling the kernel', sleeping for one second, then continuing on. This
solution doesn't stop compiling and makes a visible indicator without
Chris Mason wrote:
On Thursday, February 01, 2001 02:16:43 PM -0200 Rik van Riel
[EMAIL PROTECTED] wrote:
About the system hanging completely, I wonder if it goes
away by pressing sysrq-S (sync all disks). If it does,
maybe Reiserfs was blocking all the pages in the inactive
list from
> image=/boot/bzImage
> label=linux
> append="root=/dev/ide/host0/bus0/target0/lun0/part1 vga=3845"
root=/dev/ide/host will work the same as root=/dev/hda... in pre-devfs
-d
--
There is a natural aristocracy among men. The grounds of this are virtue and
talents. Thomas Jefferson
The
image=/boot/bzImage
label=linux
append="root=/dev/ide/host0/bus0/target0/lun0/part1 vga=3845"
root=/dev/ide/host will work the same as root=/dev/hda... in pre-devfs
-d
--
There is a natural aristocracy among men. The grounds of this are virtue and
talents. Thomas Jefferson
The
My apologies...my internic data isn't updated, http://208.179.0.18/VM/
-d
--
There is a natural aristocracy among men. The grounds of this are virtue and
talents. Thomas Jefferson
The good thing about standards is that there are so many to choose from. Andrew S.
Tanenbaum
-
To
"Michael J. Dikkema" wrote:
> I went from 2.4.0 to 2.4.1 and was surprised that either the root
> filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm
> thinking there might have been a change with regards to the devfs
> tree.. is the legacy /dev/hda1 still
John Jasen wrote:
> On Thu, 1 Feb 2001, Peter Samuelson wrote:
>
> > [Michael J. Dikkema]
> > > > I went from 2.4.0 to 2.4.1 and was surprised that either the root
> > > > filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm
> > > > thinking there might have been a change
Chris Mason wrote:
> Sorry, can't seem to resolve stuph.org. What is kreiserfsd doing during when the
>system is waiting for more ram? With JOURNAL_MAX_BATCH set to 100, kreiserfsd will
>end up responsible for sending log blocks/metadata to disk and freeing the pinned
>buffers.
>
> -chris
My apologies...my internic data isn't updated, http://208.179.0.18/VM/
-d
--
There is a natural aristocracy among men. The grounds of this are virtue and
talents. Thomas Jefferson
The good thing about standards is that there are so many to choose from. Andrew S.
Tanenbaum
-
To
t; Gather this is with no swap space allocated... And the question is why does
> the oom handler not get triggered?
>
> Ed Tomlinson
>
> David Ford wrote:
>
> > (Chris, changing JOURNAL_MAX_BATCH from 900 to 100 didn't affect
> > anything).
> >
> > Ok, havi
this is with no swap space allocated... And the question is why does
the oom handler not get triggered?
Ed Tomlinson
David Ford wrote:
(Chris, changing JOURNAL_MAX_BATCH from 900 to 100 didn't affect
anything).
Ok, having approached this slightly more intelligently here are [better]
results
My apologies...my internic data isn't updated, http://208.179.0.18/VM/
-d
--
There is a natural aristocracy among men. The grounds of this are virtue and
talents. Thomas Jefferson
The good thing about standards is that there are so many to choose from. Andrew S.
Tanenbaum
-
To
Chris Mason wrote:
Sorry, can't seem to resolve stuph.org. What is kreiserfsd doing during when the
system is waiting for more ram? With JOURNAL_MAX_BATCH set to 100, kreiserfsd will
end up responsible for sending log blocks/metadata to disk and freeing the pinned
buffers.
-chris
John Jasen wrote:
On Thu, 1 Feb 2001, Peter Samuelson wrote:
[Michael J. Dikkema]
I went from 2.4.0 to 2.4.1 and was surprised that either the root
filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm
thinking there might have been a change with regards to
"Michael J. Dikkema" wrote:
I went from 2.4.0 to 2.4.1 and was surprised that either the root
filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm
thinking there might have been a change with regards to the devfs
tree.. is the legacy /dev/hda1 still
My apologies...my internic data isn't updated, http://208.179.0.18/VM/
-d
--
There is a natural aristocracy among men. The grounds of this are virtue and
talents. Thomas Jefferson
The good thing about standards is that there are so many to choose from. Andrew S.
Tanenbaum
-
To
(Chris, changing JOURNAL_MAX_BATCH from 900 to 100 didn't affect
anything).
Ok, having approached this slightly more intelligently here are [better]
results.
The dumps are large so they are located at http://stuph.org/VM/. Here's
the story. I boot and startx, I load xmms and netscape to eat
"Maciej W. Rozycki" wrote:
> On Wed, 31 Jan 2001, Alan Cox wrote:
>
> > > Does Linus or anyone object to raising the ksmg buffer from 16K to 32K?
> > > 4/5 systems I have now overflow the buffer during boot before init is
> > > even launched.
> >
> > Thats just an indication that 2.4.x is
Alan Cox wrote:
> > > AFAIK, this hasn't ever been true. I have never had to specifically
> > > enable it at run time.
> >
> > I was suspicious of that in the old doc but thought I'd leave it in...
> > Should have asked for feedback on it, but you caught it anyway, thanks!
> >
> > Here's a
Alan Cox wrote:
AFAIK, this hasn't ever been true. I have never had to specifically
enable it at run time.
I was suspicious of that in the old doc but thought I'd leave it in...
Should have asked for feedback on it, but you caught it anyway, thanks!
Here's a patch against the
"Maciej W. Rozycki" wrote:
On Wed, 31 Jan 2001, Alan Cox wrote:
Does Linus or anyone object to raising the ksmg buffer from 16K to 32K?
4/5 systems I have now overflow the buffer during boot before init is
even launched.
Thats just an indication that 2.4.x is currently printking
(Chris, changing JOURNAL_MAX_BATCH from 900 to 100 didn't affect
anything).
Ok, having approached this slightly more intelligently here are [better]
results.
The dumps are large so they are located at http://stuph.org/VM/. Here's
the story. I boot and startx, I load xmms and netscape to eat
Mhm. Is it worth the effort to make a dependancy on the CPU type for SMP?
-d
Stephen Frost wrote:
> * David Ford ([EMAIL PROTECTED]) wrote:
> > A person just brought up a problem in #kernelnewbies, building an SMP
> > kernel doesn't work very well, current is undefined. I
A person just brought up a problem in #kernelnewbies, building an SMP
kernel doesn't work very well, current is undefined. I don't have more
time to debug it but I'll strip the config and put it up at
http://stuph.org/smp-config
-d
--
There is a natural aristocracy among men. The grounds of
A person just brought up a problem in #kernelnewbies, building an SMP
kernel doesn't work very well, current is undefined. I don't have more
time to debug it but I'll strip the config and put it up at
http://stuph.org/smp-config
-d
--
There is a natural aristocracy among men. The grounds of
Mhm. Is it worth the effort to make a dependancy on the CPU type for SMP?
/idle questions
-d
Stephen Frost wrote:
* David Ford ([EMAIL PROTECTED]) wrote:
A person just brought up a problem in #kernelnewbies, building an SMP
kernel doesn't work very well, current is undefined. I don't
Jonathan Earle wrote:
> > On Sun, 28 Jan 2001 11:35:50 +, David Ford wrote:
> > > AFAIK, this hasn't ever been true. I have never had to specifically
> > > enable it at run time.
> >
> > I was suspicious of that in the old doc but thought I'd
Jonathan Earle wrote:
On Sun, 28 Jan 2001 11:35:50 +, David Ford wrote:
AFAIK, this hasn't ever been true. I have never had to specifically
enable it at run time.
I was suspicious of that in the old doc but thought I'd leave it in...
Should have asked for feedback
The one LInus posted plus his addendum for the ll_rw_blk.
http://blue-labs.org/patches/ps-hang.patch
-d
Jens Axboe wrote:
> On Mon, Jan 29 2001, David Ford wrote:
> > kernel 2.4.0-ac12
> >
> > # ps -eo user,pid,args,wchan|egrep "imap|update|procmail&qu
kernel 2.4.0-ac12
# ps -eo user,pid,args,wchan|egrep "imap|update|procmail"
root 7 [kupdate]get_request_wait
david 627 imapdget_request_wait
david 752 procmail -f linu down
david 761 procmail -f linu down
david 799 procmail -f linu down
david
"Jeremy M. Dolan" wrote:
> +Note that previous versions disabled sysrq by default, and you were required
> +to specifically enable it at run-time. That is not the case any longer.
AFAIK, this hasn't ever been true. I have never had to specifically enable it at
run time. There are certain
Ulrich Drepper wrote:
> Pierre Rousselet <[EMAIL PROTECTED]> writes:
>
> > for me :
> > make CFLAGS='-O2 -I. -D_GNU_SOURCE'
> > compiles without any patch. is it correct ?
>
> Yes. RTLD_NEXT is not in any standard, it's an extension available
> via -D_GNU_SOURCE.
Ok, how about we all tag
Ulrich Drepper wrote:
Pierre Rousselet [EMAIL PROTECTED] writes:
for me :
make CFLAGS='-O2 -I. -D_GNU_SOURCE'
compiles without any patch. is it correct ?
Yes. RTLD_NEXT is not in any standard, it's an extension available
via -D_GNU_SOURCE.
Ok, how about we all tag Richard until he
"Jeremy M. Dolan" wrote:
+Note that previous versions disabled sysrq by default, and you were required
+to specifically enable it at run-time. That is not the case any longer.
AFAIK, this hasn't ever been true. I have never had to specifically enable it at
run time. There are certain
kernel 2.4.0-ac12
# ps -eo user,pid,args,wchan|egrep "imap|update|procmail"
root 7 [kupdate]get_request_wait
david 627 imapdget_request_wait
david 752 procmail -f linu down
david 761 procmail -f linu down
david 799 procmail -f linu down
david
The one LInus posted plus his addendum for the ll_rw_blk.
http://blue-labs.org/patches/ps-hang.patch
-d
Jens Axboe wrote:
On Mon, Jan 29 2001, David Ford wrote:
kernel 2.4.0-ac12
# ps -eo user,pid,args,wchan|egrep "imap|update|procmail"
root 7 [kupdate]get_re
e(8). Fail if a configuration line has EXECUTE
modprobe.
+Updated by David Ford 27-JAN-2001: Added RTLD_NEXT define
*/
#include
@@ -221,6 +222,10 @@
#define AC_MKNEWCOMPAT 8
#define AC_RMOLDCOMPAT 9
#define AC_RMNEWCOMPAT 10
+
+#ifndef RTLD_NEXT
It is important to note that when I hit the magic key and rebooted (SUB), a
split second before it rebooted, a stalled 'lspci' snapped back to life and
printed out my expected data.
-d
--
There is a natural aristocracy among men. The grounds of this are virtue and
talents. Thomas Jefferson
have an ATI Rage LT Pro AGP-133 according to lspci.
-d
J Sloan wrote:
> Sorry, there was no xmms involved here -
>
> The behavior occurred while playing unreal tournament.
>
> But at least the sound card was in use, FWIW -
>
> jjs
>
> David Ford wrote:
>
> >
Unfortunately klogd reads /procerg.
So the following is a painstakingly slow hand translation, I'll only print
the D state entries unless someone asks otherwise.
Prior to this:
XMMS is running playing star wars mpeg. (regular user) (frozen)
TOP is running (regular user) (frozen)
Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>, David Ford <[EMAIL PROTECTED]>
> wrote:
> >
> >We've narrowed it down to "we're all running xmms" when it happend.
>
> Does anybody have a clue about what is different with xmms?
Not sure.
At the time I had temporary access to my notebook and had a mismatched System.map
file :S
-d
Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>, David Ford <[EMAIL PROTECTED]> wrote:
> >I can quickly and easily duplicate it on my notebook by playing music or
> >
We've narrowed it down to "we're all running xmms" when it happend.
-d
J Sloan wrote:
> Just for the record, the system where I saw the problem
> has only ext2 -
--
There is a natural aristocracy among men. The grounds of this are virtue and
talents. Thomas Jefferson
The good thing about
will then grind the harddrive solid for about 25-30 minutes then
everything will go silent.
The brokenness is that the OOM code never activates.
-d
Ed Tomlinson wrote:
> David Ford Wrote:
>
> >Since the testN series and up through ac12, I experience total loss of
> >control whe
Ion Badulescu wrote:
> On Sat, 27 Jan 2001 08:01:14 +0000, David Ford <[EMAIL PROTECTED]> wrote:
> > Does Linus or anyone object to raising the ksmg buffer from 16K to 32K?
> > 4/5 systems I have now overflow the buffer during boot before init is
> > even launched.
I'm looking for some authoritative comparisons and discussions of the
current network stacks in *BSD and Linux. I.e. NET4 in Linux and
whatever is most current in *BSD.
_PLEASE_ no flaming, no causing flamewar, nadda.
I am writing an article for Linux.com and I am attempting to debunk
1 - 100 of 516 matches
Mail list logo
