I tried Dave Jones' version of the kernel to see if it would compile, as I
haven't been able to the regular 2.5 kernel to compile since I have the
new binutils package.
It compiled fine. When I booted up everything looked normal with the
exception of a
eth1: going OOM
message that kept scrolling down the screen. My eth1 is a natsemi card.
Eventually that stopped and gdm came up. For some reason my keyboard and
mouse wouldn't work. However, I could ssh into the machine and both
ethernet cards were functional. I noticed I had left SMP support
selected in the configuration, so I turned that off and tried
recompiling. It got to check.c in fs/partitions before stopping with an
error.
So, it looks like the binutils problems are fixed, but there are some
other issues apparently. If you need configuration information or for me
try something please let me know.
Ben Pharr
> It compiled fine. When I booted up everything looked normal with the
> exception of a
> eth1: going OOM
> message that kept scrolling down the screen. My eth1 is a natsemi card.
That's interesting. Probably moreso for Manfred. I'll double check
I didn't goof merging the oom-handling patch tomorrow.
> Eventually that stopped and gdm came up. For some reason my keyboard and
> mouse wouldn't work.
-dj includes a different input layer to Linus' tree, which requires
some extra options enabled. Vojtech, this is quite a frequent
'bug report', and I think if you merged that with Linus, the number
of reports would climb. Is there a possibility of simplifying the
config.in somewhat? Or at least changing the defaults to give the
element of least surprise..
> It got to check.c in fs/partitions before stopping with an error.
That one I've not got an answer for. Can you give me more information
about your disk layout, partitions, number of disks, scsi?/ide?/lvm?
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Fri, Feb 22, 2002 at 02:21:49AM +0100, Dave Jones wrote:
> > It compiled fine. When I booted up everything looked normal with the
> > exception of a
> > eth1: going OOM
> > message that kept scrolling down the screen. My eth1 is a natsemi card.
>
> That's interesting. Probably moreso for Manfred. I'll double check
> I didn't goof merging the oom-handling patch tomorrow.
>
> > Eventually that stopped and gdm came up. For some reason my keyboard and
> > mouse wouldn't work.
>
> -dj includes a different input layer to Linus' tree, which requires
> some extra options enabled. Vojtech, this is quite a frequent
> 'bug report', and I think if you merged that with Linus, the number
> of reports would climb. Is there a possibility of simplifying the
> config.in somewhat? Or at least changing the defaults to give the
> element of least surprise..
The defaults are changed :(. However people coying their .configs over
don't use the defaults. The help files say what to do in case of doubt.
I'm not sure what more I can do.
I'll try to think about that.
> > It got to check.c in fs/partitions before stopping with an error.
>
> That one I've not got an answer for. Can you give me more information
> about your disk layout, partitions, number of disks, scsi?/ide?/lvm?
>
> --
> | Dave Jones. http://www.codemonkey.org.uk
> | SuSE Labs
--
Vojtech Pavlik
SuSE Labs
On Fri, Feb 22, 2002 at 02:21:49AM +0100, Dave Jones wrote:
> > It compiled fine. When I booted up everything looked normal with the
> > exception of a
> > eth1: going OOM
> > message that kept scrolling down the screen. My eth1 is a natsemi card.
>
> That's interesting. Probably moreso for Manfred. I'll double check
> I didn't goof merging the oom-handling patch tomorrow.
Ditto here on my natsemi. It hasn't really spit out the error since
boot, about 12 hours ago. Card has been mainly idle, only used to
connect via crossover cable to my laptop, which hasn't been used much in
that time.
--
Nathan Walp || [email protected]
GPG Fingerprint: || http://faceprint.com/
5509 6EF3 928B 2363 9B2B DA17 3E46 2CDC 492D DB7E
Hi!
> > > It compiled fine. When I booted up everything looked normal with the
> > > exception of a
> > > eth1: going OOM
> > > message that kept scrolling down the screen. My eth1 is a natsemi card.
> >
> > That's interesting. Probably moreso for Manfred. I'll double check
> > I didn't goof merging the oom-handling patch tomorrow.
> >
> > > Eventually that stopped and gdm came up. For some reason my keyboard and
> > > mouse wouldn't work.
> >
> > -dj includes a different input layer to Linus' tree, which requires
> > some extra options enabled. Vojtech, this is quite a frequent
> > 'bug report', and I think if you merged that with Linus, the number
> > of reports would climb. Is there a possibility of simplifying the
> > config.in somewhat? Or at least changing the defaults to give the
> > element of least surprise..
>
> The defaults are changed :(. However people coying their .configs over
> don't use the defaults. The help files say what to do in case of doubt.
> I'm not sure what more I can do.
Few define_bool's for transition period? That way it will get as =y to
.config, and you can present real config options after few versions
;-).
Or create
CONFIG_ADVANCED_INPUT_OPTIONS, default to N, which will make all
suitable options Y.... That's hacky, but we've got a precedents.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> > -dj includes a different input layer to Linus' tree, which requires
I've just moved from Linus 2.5.3 to 2.5.5-dj1.
I've tried the following both with modules and linked into bzImage.
I've tried pointing the software at /dev/input/mice and also at /dev/psaux
which I created as a symlink to /dev/input/mice (to maintain compatibility
with my working 2.5.3 setup)
I have a PS/2 mouse.
I've loaded mousedev.o and psmouse.o
gpm works. (**1)
cat /dev/input/mice
gives random binary spew that looks pretty much like mouse input.
When I run my Xserver, the mouse pointer doesn't move. If I then kill off
the Xserver, gpm doesn't work any more and cat/dev/input/mice doesn't
generate anything any more.
If I unload psmouse.o and then load it again, I am back to (**1) until I
load the Xserver again.
- --
Ben Clifford [email protected] GPG: 30F06950
Job Required in Los Angeles - Will do most things unix or IP for money.
http://www.hawaga.org.uk/resume/resume001.pdf
Live Ben-cam: http://barbarella.hawaga.org.uk/benc-cgi/watchers.cgi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8eVRTsYXoezDwaVARAv8nAJ4s0sH7Zh295dna6i7UI1PML0JavgCcCtS5
mrYEP5nWJ2i6eCqp4hncSG0=
=sfBd
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've just moved from 2.5.3 to 2.5.5-dj1
I have ipv6 compiled as a module.
When ipv6.o is loaded, I get:
IPv6 v0.8 for NET4.0
Failed to initialize the ICMP6 control socket (err -97)
and lsmod shows:
ipv6 147968 -1 (uninitialized)
Other than my ipv6 services not starting up, it doesn't seem to cause any
other problems.
- --
Ben Clifford [email protected] GPG: 30F06950
Job Required in Los Angeles - Will do most things unix or IP for money.
http://www.hawaga.org.uk/resume/resume001.pdf
Live Ben-cam: http://barbarella.hawaga.org.uk/benc-cgi/watchers.cgi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8eVUHsYXoezDwaVARAuNEAJ9U9Fj1UlMhk/2h82vwcu8KY6/XAACdFAfz
xxsU4t5kJGiOCqtwqZR3WVw=
=CXmF
-----END PGP SIGNATURE-----
On Sun, Feb 24, 2002 at 01:00:00PM -0800, Ben Clifford wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> > > -dj includes a different input layer to Linus' tree, which requires
>
> I've just moved from Linus 2.5.3 to 2.5.5-dj1.
>
> I've tried the following both with modules and linked into bzImage.
>
> I've tried pointing the software at /dev/input/mice and also at /dev/psaux
> which I created as a symlink to /dev/input/mice (to maintain compatibility
> with my working 2.5.3 setup)
>
> I have a PS/2 mouse.
>
> I've loaded mousedev.o and psmouse.o
>
> gpm works. (**1)
>
> cat /dev/input/mice
> gives random binary spew that looks pretty much like mouse input.
>
> When I run my Xserver, the mouse pointer doesn't move. If I then kill off
> the Xserver, gpm doesn't work any more and cat/dev/input/mice doesn't
> generate anything any more.
>
> If I unload psmouse.o and then load it again, I am back to (**1) until I
> load the Xserver again.
That's interesting. It almost looks like if the Xserver messed with the
mouse hardware somehow, which I hope it can't. Does 'dmesg' say anything
relevant?
I can help you find the cause - if you enable I8042_DEBUG_IO in
drivers/input/serio/i8042.h, you'll see all the data coming in and out
to the keyboard/aux controller.
--
Vojtech Pavlik
SuSE Labs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 24 Feb 2002, Vojtech Pavlik wrote:
> That's interesting. It almost looks like if the Xserver messed with the
> mouse hardware somehow, which I hope it can't.
> Does 'dmesg' say anything relevant?
I don't think so.
All that appears is an mtrr message about alignment, that I think I has
appeared for several kernel versions.
> I can help you find the cause - if you enable I8042_DEBUG_IO in
> drivers/input/serio/i8042.h, you'll see all the data coming in and out
> to the keyboard/aux controller.
Compiling now...
- --
Ben Clifford [email protected] GPG: 30F06950
Job Required in Los Angeles - Will do most things unix or IP for money.
http://www.hawaga.org.uk/resume/resume001.pdf
Live Ben-cam: http://barbarella.hawaga.org.uk/benc-cgi/watchers.cgi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8eV5OsYXoezDwaVARAsvZAJsGbZrxboqXmRmipPM0cScR+StzuACfVE5P
cwlgu22wLd09O8onA1iv/Dw=
=rnUz
-----END PGP SIGNATURE-----
On Sun, Feb 24, 2002 at 01:42:34PM -0800, Ben Clifford wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun, 24 Feb 2002, Vojtech Pavlik wrote:
>
> > That's interesting. It almost looks like if the Xserver messed with the
> > mouse hardware somehow, which I hope it can't.
>
> > Does 'dmesg' say anything relevant?
>
> I don't think so.
>
> All that appears is an mtrr message about alignment, that I think I has
> appeared for several kernel versions.
>
> > I can help you find the cause - if you enable I8042_DEBUG_IO in
> > drivers/input/serio/i8042.h, you'll see all the data coming in and out
> > to the keyboard/aux controller.
>
> Compiling now...
Ok, waiting ... :)
--
Vojtech Pavlik
SuSE Labs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 24 Feb 2002, Ben Clifford wrote:
> When ipv6.o is loaded, I get:
>
> IPv6 v0.8 for NET4.0
> Failed to initialize the ICMP6 control socket (err -97)
>
> and lsmod shows:
> ipv6 147968 -1 (uninitialized)
More info on this:
Looking at the code, the the ICMP6 control socket error is occurring
because sock_register isn't called for inet6 until after the ICMP6 control
socket is created (in af_inet6.c).
However, the ICMP6 control socket create calls sock_create, which requires
sock_register to have already been called.
I have made the below change, which moves the protocol family registration
higher up in the code. It seems to make ipv6 work now.
However, I'm concerned that this gives a small amount of time when the
family is registered but not fully initialised.
Is this bad?
- --- /mnt/dev/hda11/2.5.5-dj1-snark-not-changed-much/net/ipv6/af_inet6.c Tue Feb 19 18:10:53 2002
+++ 2.5.5-dj1/net/ipv6/af_inet6.c Sun Feb 24 22:13:38 2002
@@ -675,6 +675,13 @@
*/
inet6_register_protosw(&rawv6_protosw);
+ /* register the family here so that the init calls below will
+ * work. ?? is this dangerous ??
+ */
+
+ (void) sock_register(&inet6_family_ops);
+
+
/*
* ipngwg API draft makes clear that the correct semantics
* for TCP and UDP is to consider one TCP and UDP instance
@@ -719,9 +726,6 @@
udpv6_init();
tcpv6_init();
- - /* Now the userspace is allowed to create INET6 sockets. */
- - (void) sock_register(&inet6_family_ops);
- -
return 0;
#ifdef CONFIG_PROC_FS
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8eda0sYXoezDwaVARAn+uAJ4o8hCamGZzX6UnJVH8PWYfjLzBFQCeLZxw
Fofq4Yo27N2juaxaMdZ+aXw=
=so8+
-----END PGP SIGNATURE-----
On Sun, Feb 24, 2002 at 10:16:16PM -0800, Ben Clifford wrote:
> Looking at the code, the the ICMP6 control socket error is occurring
> because sock_register isn't called for inet6 until after the ICMP6 control
> socket is created (in af_inet6.c).
> However, the ICMP6 control socket create calls sock_create, which requires
> sock_register to have already been called.
This probably happened during acme's recent protocol cleanups,
and is probably a problem in mainline as well as -dj.
> I have made the below change, which moves the protocol family registration
> higher up in the code. It seems to make ipv6 work now.
>
> However, I'm concerned that this gives a small amount of time when the
> family is registered but not fully initialised.
> Is this bad?
I'll let davem/acme comment on the correctness of the fix..
Looks straightforward enough to me, but I'm not as kneedeep in
networking internals as those two 8-)
>
> - --- /mnt/dev/hda11/2.5.5-dj1-snark-not-changed-much/net/ipv6/af_inet6.c Tue Feb 19 18:10:53 2002
> +++ 2.5.5-dj1/net/ipv6/af_inet6.c Sun Feb 24 22:13:38 2002
> @@ -675,6 +675,13 @@
> */
> inet6_register_protosw(&rawv6_protosw);
>
> + /* register the family here so that the init calls below will
> + * work. ?? is this dangerous ??
> + */
> +
> + (void) sock_register(&inet6_family_ops);
> +
> +
> /*
> * ipngwg API draft makes clear that the correct semantics
> * for TCP and UDP is to consider one TCP and UDP instance
> @@ -719,9 +726,6 @@
> udpv6_init();
> tcpv6_init();
>
> - - /* Now the userspace is allowed to create INET6 sockets. */
> - - (void) sock_register(&inet6_family_ops);
> - -
> return 0;
>
> #ifdef CONFIG_PROC_FS
>
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
From: Dave Jones <[email protected]>
Date: Mon, 25 Feb 2002 22:32:03 +0100
I'll let davem/acme comment on the correctness of the fix..
Looks straightforward enough to me, but I'm not as kneedeep in
networking internals as those two 8-)
I've poked acme about it.
Em Mon, Feb 25, 2002 at 02:18:24PM -0800, David S. Miller escreveu:
> From: Dave Jones <[email protected]>
> Date: Mon, 25 Feb 2002 22:32:03 +0100
>
> I'll let davem/acme comment on the correctness of the fix..
> Looks straightforward enough to me, but I'm not as kneedeep in
> networking internals as those two 8-)
>
> I've poked acme about it.
Indeed, I'm changing oxygen cilinders while scuba diving into my mailbox 8)
- Arnaldo
Hi!
> > If I unload psmouse.o and then load it again, I am back to (**1) until I
> > load the Xserver again.
>
> That's interesting. It almost looks like if the Xserver messed with the
> mouse hardware somehow, which I hope it can't. Does 'dmesg' say anything
Of course it can, it is iopl(3) after all, but it certainly *should*
not and probably does not.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
On Fri, Feb 22, 2002 at 01:37:24AM -0500, Nathan Walp wrote:
> On Fri, Feb 22, 2002 at 02:21:49AM +0100, Dave Jones wrote:
> > > It compiled fine. When I booted up everything looked normal with the
> > > exception of a
> > > eth1: going OOM
> > > message that kept scrolling down the screen. My eth1 is a natsemi card.
> >
> > That's interesting. Probably moreso for Manfred. I'll double check
> > I didn't goof merging the oom-handling patch tomorrow.
>
> Ditto here on my natsemi. It hasn't really spit out the error since
> boot, about 12 hours ago. Card has been mainly idle, only used to
> connect via crossover cable to my laptop, which hasn't been used much in
> that time.
dj2 is showing the same behavior, but I found out that the messages
continue to be printed 100 times/second until I ping-flooded the machine
on the other end of that card. The minimal DHCP traffic prior to the
ping flood was not enough to make it stop.
Hope this helps narrow down the problem some.
Nathan
--
Nathan Walp || [email protected]
GPG Fingerprint: || http://faceprint.com/
5509 6EF3 928B 2363 9B2B DA17 3E46 2CDC 492D DB7E
> > Ditto here on my natsemi. It hasn't really spit out the error since
> > boot, about 12 hours ago. Card has been mainly idle, only used to
> > connect via crossover cable to my laptop, which hasn't been used much in
> > that time.
>
> dj2 is showing the same behavior, but I found out that the messages
> continue to be printed 100 times/second until I ping-flooded the machine
> on the other end of that card. The minimal DHCP traffic prior to the
> ping flood was not enough to make it stop.
>
> Hope this helps narrow down the problem some.
Yup, Manfred is aware of the problem, but hasn't had chance to
look into it yet.. It'll be present at least until you see
an entry in the changelog 8)
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Thu, Feb 28, 2002 at 11:59:54AM -0500, Nathan Walp wrote:
> On Fri, Feb 22, 2002 at 01:37:24AM -0500, Nathan Walp wrote:
> > On Fri, Feb 22, 2002 at 02:21:49AM +0100, Dave Jones wrote:
> > > > It compiled fine. When I booted up everything looked normal with the
> > > > exception of a
> > > > eth1: going OOM
> > > > message that kept scrolling down the screen. My eth1 is a natsemi card.
> > >
> > > That's interesting. Probably moreso for Manfred. I'll double check
> > > I didn't goof merging the oom-handling patch tomorrow.
> >
> > Ditto here on my natsemi. It hasn't really spit out the error since
> > boot, about 12 hours ago. Card has been mainly idle, only used to
> > connect via crossover cable to my laptop, which hasn't been used much in
> > that time.
>
> dj2 is showing the same behavior, but I found out that the messages
> continue to be printed 100 times/second until I ping-flooded the machine
> on the other end of that card. The minimal DHCP traffic prior to the
> ping flood was not enough to make it stop.
>
> Hope this helps narrow down the problem some.
My box continued to do it until ntpdate contacted its servers, so it
appears to be basically the same thing.
Ben Pharr
--- 2.5/drivers/net/natsemi.c Fri Mar 1 17:16:38 2002
+++ build-2.5/drivers/net/natsemi.c Fri Mar 1 19:11:52 2002
@@ -1380,7 +1380,7 @@
np->rx_ring[entry].cmd_status =
cpu_to_le32(np->rx_buf_sz);
}
- if (np->cur_rx - np->dirty_tx == RX_RING_SIZE) {
+ if (np->cur_rx - np->dirty_rx == RX_RING_SIZE) {
if (debug > 2)
printk(KERN_INFO "%s: going OOM.\n", dev->name);
np->oom = 1;