Hi,
I have an ancient i586 UP machine that happily runs vanilla Linux
6.4.16, but which locks up shortly after booting vanilla 6.5.0. The
kernel *seems* to run into trouble as soon as the networking layer
becomes busy. However, its SysRq-S/U/B sequence still seems to work as
expected and so obviously *something* is still responding somewhere.
This problem still exists in vanilla 6.6.8.
FWIW I have raised this bug in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=218296
Thanks for any help here,
Cheers,
Chris
[also Cc: netdev folks and get_maintainer output for include/net/neighbour.h]
On Thu, Dec 21, 2023 at 11:12:34PM +0000, Chris Rankin wrote:
> Hi,
>
> I have an ancient i586 UP machine that happily runs vanilla Linux
> 6.4.16, but which locks up shortly after booting vanilla 6.5.0. The
> kernel *seems* to run into trouble as soon as the networking layer
> becomes busy. However, its SysRq-S/U/B sequence still seems to work as
> expected and so obviously *something* is still responding somewhere.
>
> This problem still exists in vanilla 6.6.8.
>
> FWIW I have raised this bug in bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=218296
>
To be honest, you need to bisect. For reference, see
Documentation/admin-guide/bug-bisect.rst in the kernel sources.
Since you have problem with your old machine, you may want to compile
the kernel (which is a prerequisite for bisection) on faster machine,
then transfer the kernel image + modules into your old machine to
be installed there. Without bisection, no one will look into this
regression.
Thanks.
--
An old man doll... just what I always wanted! - Clara
Hi!
> I have an ancient i586 UP machine that happily runs vanilla Linux
> 6.4.16, but which locks up shortly after booting vanilla 6.5.0. The
> kernel *seems* to run into trouble as soon as the networking layer
> becomes busy. However, its SysRq-S/U/B sequence still seems to work as
> expected and so obviously *something* is still responding somewhere.
>
> This problem still exists in vanilla 6.6.8.
>
> FWIW I have raised this bug in bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=218296
Yes, UP should still work. I'm using such machine and intend to
continue with that. But it seems more testing would be welcome.
And yes, you'll likely need to bisect.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
Hi,
I have already attached as much information as I am *ever* likely to
be able to extract about this problem to the Bugzilla ticket.
Cheers,
Chris
On Fri, 29 Dec 2023 at 15:41, Pavel Machek <[email protected]> wrote:
>
> Hi!
>
> > I have an ancient i586 UP machine that happily runs vanilla Linux
> > 6.4.16, but which locks up shortly after booting vanilla 6.5.0. The
> > kernel *seems* to run into trouble as soon as the networking layer
> > becomes busy. However, its SysRq-S/U/B sequence still seems to work as
> > expected and so obviously *something* is still responding somewhere.
> >
> > This problem still exists in vanilla 6.6.8.
> >
> > FWIW I have raised this bug in bugzilla:
> > https://bugzilla.kernel.org/show_bug.cgi?id=218296
>
> Yes, UP should still work. I'm using such machine and intend to
> continue with that. But it seems more testing would be welcome.
>
> And yes, you'll likely need to bisect.
>
> Best regards,
> Pavel
>
> --
> People of Russia, stop Putin before his war on Ukraine escalates.
On Fri, Dec 29, 2023 at 04:03:56PM +0000, Chris Rankin wrote:
>
> I have already attached as much information as I am *ever* likely to
> be able to extract about this problem to the Bugzilla ticket.
In addition to doing a bisection, something else you might want to
try, since in the bugzilla you have hypothesized that it might be a
bug in the e100 driver, is to try building a kernel without the driver
configured, and see if that makes the kernel not hang. If it does,
then it's likely that the problem is either in the e100 driver, or
maybe somewhere in the networking stack --- although in that case it's
more likely someone else would have noticed.
Something else you might try is to connect up a serial console, so you
can get the full output from sysrq output. The other advantage of
using a serial console is people are much more likely to scan a text
file with the consoles, as opposed to downloading and trying to make
sense of the screen snapshots. (BTW, was the flash enabled on your
cell phone? The bright white spot in the middle of the screen makes
it very hard to read.)
I'd also try sysrq-l (show backtrace for all active CPU's), so you can
see where the kernel is actually hanging.
For better or for worse, support for old hardware is a volunteer
effort, so owners of the said old hardware need to do a bunch of the
leg work. Or if you can have a paid support contract, maybe you can
pay someone to gather the detail, but when you say "is feature X
supported" in an open source project, that has a different meaning
from a commercial software product.
- Ted
Yes, the bright spots are my phone's flash. But I did check the images
to ensure that their information was still legible before posting
them.
Image resolution is 4128x2322, which should be more than adequate for
zooming in.
On Fri, 29 Dec 2023 at 17:28, Theodore Ts'o <[email protected]> wrote:
>
> On Fri, Dec 29, 2023 at 04:03:56PM +0000, Chris Rankin wrote:
> >
> > I have already attached as much information as I am *ever* likely to
> > be able to extract about this problem to the Bugzilla ticket.
>
> In addition to doing a bisection, something else you might want to
> try, since in the bugzilla you have hypothesized that it might be a
> bug in the e100 driver, is to try building a kernel without the driver
> configured, and see if that makes the kernel not hang. If it does,
> then it's likely that the problem is either in the e100 driver, or
> maybe somewhere in the networking stack --- although in that case it's
> more likely someone else would have noticed.
>
> Something else you might try is to connect up a serial console, so you
> can get the full output from sysrq output. The other advantage of
> using a serial console is people are much more likely to scan a text
> file with the consoles, as opposed to downloading and trying to make
> sense of the screen snapshots. (BTW, was the flash enabled on your
> cell phone? The bright white spot in the middle of the screen makes
> it very hard to read.)
>
> I'd also try sysrq-l (show backtrace for all active CPU's), so you can
> see where the kernel is actually hanging.
>
> For better or for worse, support for old hardware is a volunteer
> effort, so owners of the said old hardware need to do a bunch of the
> leg work. Or if you can have a paid support contract, maybe you can
> pay someone to gather the detail, but when you say "is feature X
> supported" in an open source project, that has a different meaning
> from a commercial software product.
>
> - Ted