Re: Why add the general notification queue and its sources
Hi, On Thu, Sep 5, 2019 at 2:37 PM Steven Whitehouse wrote: > The original reason for the mount notification mechanism was so that we > are able to provide information to GUIs and similar filesystem and > storage management tools, matching the state of the filesystem with the > state of the underlying devices. This is part of a larger project > entitled "Project Springfield" to try and provide better management > tools for storage and filesystems. I've copied David Lehman in, since he > can provide a wider view on this topic. So one problem that I've heard discussed before is what happens in a thinp setup when the disk space is overallocated and gets used up. IIRC, the volumes just sort of eat themselves? Getting proper notification of looming catastrophic failure to the workstation user before it's too late would be useful, indeed. I don't know if this new mechanism dhowells has development can help with that, and/or if solving that problem is part of the Project Springfield initiative or not. Do you know off hand? --Ray
Re: [RFC PATCH v2 00/13] Kernel based bootsplash
Hi, On Wed, Dec 20, 2017 at 11:44 AM Max Staudt wrote: > It'd be nice to see this bug fixed, as it happens only occasionally (as is > the nature of a > race condition), and was thus really hard to debug. I'm sure it can drive > people insane, > as they try to find out whether they've disabled Ctrl-Alt-Fx in their > xorg.conf, but really > it's Plymouth getting the system into a bad state. I probably owe a bald > patch on my > head to this bug. Okay, reading through the code I do see how what you're describing could happen. I sketched out a patch here: https://cgit.freedesktop.org/plymouth/commit/?h=fix-vt-management-on-deactivate&id=0b5b790d628f4c96e3ab9fbc0daba67a29b850da that I think should fix it. I need to do some testing with it (ideally rig up a reproducer) before I push it. > This is exactly where the kernel bootsplash is useful. Since it starts even > before any > userspace program is loaded, it can close this gap. > > I've even tried it in combination with Plymouth: Plymouth is just another > graphical > application, so it simply pops up "on top", just like X would. The two > splashes > integrate flawlessly. I just wish it used our modern graphics platform instead of the deprecated subsystem. > One could argue that one could put all DRM drivers into the initrd. Ubuntu > does this, > and the initrd is ~40 MB in size. Not nice. well, that 40mb isn't just graphics drivers... ╎❯ du -sh /lib/modules/`uname -r`/kernel/drivers/gpu 2.7M /lib/modules/4.14.6-300.fc27.x86_64/kernel/drivers/gpu 3M isn't too awful. But really you have two choices as I see it: 1) make the initrd support new hardware 2) make the initrd be taylored to a specific configuration. I actually think ubuntu has it right by doing 1. it's going to give the best user experience. (not just with graphics but other new hardware too). But if you do 2) then it's not unreasonable if things break with new hardware. Now ideally, the breakage would be as isolated as possible. I mean maybe it's okay if the boot splash breaks (or shows a text splash), but it's not okay if the bootsplash sort of works using /dev/fb, but then causes Xorg to break. So we should probably change plymouth to avoid falling back to /dev/fb in the case where new hardware got added. Could probably fix this by detecting if kms is around when the initrd is generated, and adding a config option to skip fb renderer in that case. or something like that. But the easy answer is to just fix the initrd to have the graphics drivers. > And even then, the initrd could be outdated for some reason. Maybe it's a > developer > machine. Nobody would expect the boot to hang/fail because of this problem. Right, ideally boot splash problems should never stop boot from proceeding. > So let's take SUSE. They don't have a finishing transition, the splash simply > stops > and is hidden at once. Such a splash makes sense to be shown instantly, right? I don't think it makes sense for animations to lack transitions. animations without transitions look buggy or unfinished. they should fade out or finish the loop, or whatever. If it's a static image it should fade to black or the background color. (going to be away from the computer for a few days after this message so probably won't reply for a while to further discussion) --Ray
Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing
Hi, > Actually, I don't want that :) > > This was a design decision that I've made to keep the code small and simple > to audit. > As it is, the simple bootsplash code will make 99% of people happy. You think only 1% of linux users have more than one monitor or a 4k screen? > I've made this decision from the point of view of someone who wants to ship a > general > purpose distribution. If you have a look around and compare this to e.g. the > Windows or > Mac OS X bootsplashes, the possibilities that my kernel code provides already > surpasses them. I haven't looked specifically, but I don't believe you :-) You're telling me the apple boot splash isn't scaled up on machines with retina displays? I don't use OSX (or windows), so I don't know, but I'd be really surprised. > If you really want such sophisticated features, supplanting the initial > bootsplash with > Plymouth (or not using it at all) is a better solution. In my opinion, it is > overengineering, > at least for kernel code. disagree..it's support for basic, commodity hardware these days. > As for HiDPI, if you're working on an embedded device with a fixed screen > size - > say a phone - you can easily include a huge picture the size of the screen in > the > bootsplash. I'm talking about a situation where you have a dell xps or whatever with an external monitor attached. Each monitor should be able to show the splash without deforming it, and without making it huge or microscopic. pretty basic stuff... --Ray
Re: [RFC PATCH v2 00/13] Kernel based bootsplash
Hi, > The problem that I am stumbling upon is different: > - the system starts with an FB driver > - after the ShowDelay time, Plymouth opens /dev/fb0 > - the system finally loads the DRM driver, which tries to kick the previous > FB driver > - loading the DRM driver fails because Plymouth still has the previous > /dev/fb0 open So the thing to realize is, that using /dev/fb is a last ditch effort by plymouth to make things work. It's basically a compat hack to keep vga=0x318 working and also a nod to embedded systems that just have /dev/fb and don't have a kms driver. If we fall back to /dev/fb we lose, as mentioned before, multi-monitor support. And it's a legacy, deprecated api. If we've reached the scenario you're discussing above, the real failure is that the KMS driver took too long to load. DRM is the platform graphics api. If it's not loading timely enough to show graphics then that's the problem! It sounds like maybe in the above bug, you're just failing to load the drm driver in the initrd ? > If you have a better way of calling it, I'd be glad to learn. > Maybe "grabbing the VT", "taking ownership of the VT", ...? I don't care what we call it, I just didn't understand what you were saying before. I think i'd say "manages vt switching", but whatever. > And then, if something causes Plymouth to sense a new device (such as Plymouth > thinking that udev coldplug is complete), it will open the device, and as > part of that, > call VT_SETMODE. This is unexpected, since "plymouth deactivate" should keep > it > from doing this. And Plymouth's code architecture is such that this bug is > hard to fix. If what you're describing is happening, this does sound like a bug. I don't think it should be hard to fix, if it's a problem. I'll look into it. > [I] have decided to write a kernel-based replacement to simplify things and > to show a > splash as early as possible. It just avoids all of this complexity. So, for the record, I don't actually have a problem with you doing a kernel based splash. (though it should use drm subsystem apis not graphics subsystem apis, /dev/fb is going the way of the dodo) > This is the sleep that I mean. > > On the one hand, it is this delay that makes most users not notice the > "busy VRAM bug". If the DRM driver that replaces the FB driver is included in > the > initramfs, then in most cases, it will be loaded before the 5 seconds are up. > However, > if the driver is loaded after these 5 seconds have elapsed, then Plymouth > will have > opened /dev/fb0 and the modprobe fails. Think of this from a user perspective. If the screen is black for 15 seconds (or something) before a splash is shown, then we've already hit a problem! That's like 15 seconds of time where the user is wondering if their system is broken. But I don't think that actually happens in practice. I think (maybe?) the situation you're hitting is your drm driver isn't starting to get loaded until N seconds after boot has started, because it's not in the initrd. So the fix is to put it in the initrd. > On the other hand, what is the motivation for this delay? As I said earlier, the motivation for the delay is to avoid showing a splash for systems that boot in 4 seconds or something. At that point a splash is just getting in the way. > If Plymouth were to display the splash instantly on a system that needs 0.5 > seconds to > boot, then the splash would flash for 0.5 seconds. No, flashing a splash for half a second would be a bug. (again think of things from a user perpective). Plymouth splashes have animations at the end to transition the user to the login screen. Normally those animations don't contribute to boot time, because we know when boot will finish from prior boot data. But if boot were 0.5 seconds long, then those animations would contribute 2 to 3 seconds to boot time, and if boot is 0.5 seconds long showing a splash is pointless. > But with the delay, a system that needs 5.5 seconds to boot will also flash > it for 0.5 seconds. > Either way, the splash will just flash for a moment. again, we don't blink the splash on and off. we have transition animations. > The delay only changes which systems are affected. However, if you set the > delay to 0, > you'll run into the bug I described above. Then put the drm driver in the initramfs so you fix your bug ! > This is a design problem, hidden by a needless delay. really don't see how it is. --Ray
Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing
Hi, On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt wrote: > I'm hooking into the in-kernel terminal emulator, because the bootsplash is a > functional extension of that. It just happens that fbcon sits on top of FB, > so I > work with what I get. > > And the console in turn happens to work on all FB and KMS drivers, so it > makes users of all kinds of drivers happy. In fact, that's why the FB > emulation > in KMS drivers came to be in the first place, if I remember right - to ensure > fbcon continues to work. But what about multi-monitor? what about hidpi screens? Ideally you want each monitor to show the splash in a way that best fits that monitor. You can't do that if you're drawing all over fbcon... and it's not like multiple monitors and 4k screens are niche these days. --Ray
Re: [RFC PATCH v2 00/13] Kernel based bootsplash
Hi, > For example, having a userspace splash that starts as early as it can > (thus on vesafb/efifb on a PC) will cause the KMS driver to fail > reserving the entirety of video RAM, and thus fail loading. This cannot be > fixed. well the fix there is to use drm devices... like this: https://cgit.freedesktop.org/plymouth/commit/?id=97f02ee959374afb1b8a78dc67116cd880cf2d23 > Furthermore, Plymouth is quite broken. For example, it may lock > (via VT_SETMODE) the VT even though Plymouth is in "disabled" > state and X has already taken control of the VT. What do you mean by "disabled" (plymouth.enable=0?) ? if it's disabled, it's not going to call VT_SETMODE ... Why do you refer to VT_SETMODE as locking ? VT_SETMODE sets whether a process handles VT changes or the kernel does. There is a long standing kernel issue where a mode of VT_AUTO (kernel handles vt switching) + KDGRAPHICS means VTs can't be changed. is that what you're talking about? Anyway plymouth is only going to step on X's toes, if the distro erroneously asks it to. Normally, a distro would run "plymouth deactivate" before starting X, instead of trying to run them at the same time... > This causes the kernel to throw away X's PID as the VT owner, and thus > chvt and Ctrl-Alt-Fx no longer work because X can neither release the > console (VT_RELDISP fails), nor does the kernel send it the signal to do > so. This is hard to impossible to fix. Unless i'm missing something, this is totally just a problem with startup scripts not doing the right thing? Plymouth shouldn't be doing anything once X is started. If it is, that's either a plymouth bug (or more likely a distro integration problem) > A third reason is that in practice, Plymouth's start is delayed for reasons > such as the above. Yes, race conditions are being worked around with > sleeps. ??? that's not true. We don't have any sleep statements in the code to work around race conditions with X. We do have two configurable delays in the code, are you talking about one of them? 1) The first is a ShowDelay option. The point of this option is, "If boot takes 5 seconds or less, it's essentially instant and we shouldn't show a splash at all". Nothing to do with race conditions. You can set it to 0 if you want. 2) The second is DeviceTimeout option. The point of this option is to decide how long to wait for udev coldplug to finish. It's mostly relevant for systems that don't have kms drivers. The point is at somepoint during boot we need to decide to stop waiting for a drm device to show up and just fallback to showing graphics using legacy interfaces (like /dev/fb). We used to wait until the udev queue went empty, but that's error prone since it gets cleared when the root is switched. See https://lists.freedesktop.org/archives/systemd-devel/2015-March/029184.html > So some issues are hard to fix, others are impossible to fix in userspace. I'm not convinced there are any insurmountable problems here... One thing i'd like to do is change boot to not map fbcon at first, and only map it in on the fly when the user hits escape, or after boot finishes. like, for instance, try booting with fbcon=vc:2 or fbcon=map:9 to see how it improves the boot experience. --Ray
Re: [PATCH 3.13 35/99] tty: Set correct tty name in active sysfs attribute
Hi, On Sat, Feb 22, 2014 at 10:16 AM, Hannes Reinecke wrote: > And of course, checking for "!tty0" is the proper check for serial console. > Which, of course, means we have to stay with a broken kernel interface for > ever and ever. > > Innovation, here we come. So just so we're clear: 1) you have every right to try to make s390 work better 2) You have every right to make mistakes in that venture as well (we all make mistakes after all) 3) You can even unapologetically break userspace and then be snarky about it 4) And, like the above message, you can also ridicule the code using the kernel interface you broke Of those things I'd certainly prefer if you stuck to the first two and skipped the last two. For bonus points, you could: 5) Reply to Kay, Greg, and David when they ask questions about the patch you wrote 6) Offer a follow up patch that acheives your initial objective without the ensuing breakage 7) Offer any insight you might have on better ways for plymouth to achieve what it wants to do going forward that would be less objectionable --Ray -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 35/99] tty: Set correct tty name in active sysfs attribute
Hi,
(resending because my phone tried to send the reply as html mail and
it got rejected)
On Sat, Feb 22, 2014 at 9:27 AM, David Herrmann wrote:
> > How about this:
>
> + driver = cs[i]->device(cs[i], &index);
> +/* special case for tty0 which must not be resolved */
> + if (driver && (index > 0 || cs[i]->major != TTY_MAJOR)) {
> + count += tty_line_name(driver, index, buf + count);
> + count += sprintf(buf + count, "%c", i ? ' ':'\n');
> + } else
> + count += sprintf(buf + count, "%s%d%c",
> +name, index, i ? ' ':'\n');
Assuming I'm reading the code correctly, I don't think that will work.
Index will be rewritten from 0 to fg_console (which I suppose is
going to be 1) after the device vfunc is called.
--Ray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 35/99] tty: Set correct tty name in active sysfs attribute
Hi,
On Fri, Feb 21, 2014 at 11:01 AM, Kay Sievers wrote:
> Why did the tty0 change to tty1 now? That doesn't look like a "driver
> name" vs. "device name" issue?
I don't know if it's intentional, but the patch does:
+ int index = cs[i]->index;
...
+ driver = cs[i]->device(cs[i], &index);
which will presumably change the index from 0 to 1 because of this code:
static struct tty_driver *vt_console_device(struct console *c, int *index)
{
*index = c->index ? c->index-1 : fg_console;
return console_driver;
}
At least that's what it looks like is causing the problem from
browsing through the source a bit.
--Ray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 35/99] tty: Set correct tty name in active sysfs attribute
Hi,
On Fri, Feb 21, 2014 at 3:21 PM, Greg Kroah-Hartman
wrote:
> Ray, Josh, can I get some more information about this? Is this broken
> in Linus's tree? Or did I get the backport wrong here?
I don't think it's a problem with the backport specifically. To be
honest, i'm not even 100% sure it is that patch. It was just the only
patch that touched that code recently so it seemed likely. I didn't
do builds to check for sure.
> What is the value of the file before and after this patch?
"tty0" in the past and "tty1" now
> And what is plymouth doing with this file value, it was incorrect
> before, what was it using the value for?
See the other (3.11) thread for my initial message, but basically
plymouth had code something like this pseudocode:
/* disable splash if there are serial consoles */
if (!contents_of_file_equals("/sys/class/tty/console/active", "tty0")) {
disable_splash_and_force_verbose_messages();
}
since the file started saying tty1 that code started disabling the
splash for everyone in rawhide.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11 085/121] tty: Set correct tty name in 'active' sysfs attribute
Hi,
This broke plymouth, i think. Plymouth used the herustic:
"/sys/class/tty/console/active contains something other than tty0" to
mean "probably has serial consoles, force verbose messages instead of
a splash screen". Now on a normal system it contains tty1.
I pushed a commit to plymouth that gets it working again, but it could
cause compatiblity concerns if new kernels are pushed to old releases.
--Ray
On Fri, Feb 21, 2014 at 7:48 AM, Luis Henriques
wrote:
> 3.11.10.5 -stable review patch. If anyone has any objections, please let me
> know.
>
> --
>
> From: Hannes Reinecke
>
> commit d8a5dc3033af2fd6d16030d2ee4fbd073460fe54 upstream.
>
> The 'active' sysfs attribute should refer to the currently active tty
> devices the console is running on, not the currently active console.
>
> The console structure doesn't refer to any device in sysfs, only the tty
> the console is running on has. So we need to print out the tty names in
> 'active', not the console names.
>
> This resolves an issue on s390 platforms in determining the correct
> console device to use.
>
> Cc: Lennart Poettering
> Cc: Kay Sievers
> Cc: Jiri Slaby
> Cc: David Herrmann
> Signed-off-by: Werner Fink
> Signed-off-by: Hannes Reinecke
> Signed-off-by: Greg Kroah-Hartman
> Signed-off-by: Luis Henriques
> ---
> Documentation/ABI/testing/sysfs-tty | 3 ++-
> drivers/tty/tty_io.c| 25 ++---
> 2 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-tty
> b/Documentation/ABI/testing/sysfs-tty
> index ad22fb0..a2ccec3 100644
> --- a/Documentation/ABI/testing/sysfs-tty
> +++ b/Documentation/ABI/testing/sysfs-tty
> @@ -3,7 +3,8 @@ Date: Nov 2010
> Contact: Kay Sievers
> Description:
> Shows the list of currently configured
> -console devices, like 'tty1 ttyS0'.
> +tty devices used for the console,
> +like 'tty1 ttyS0'.
> The last entry in the file is the active
> device connected to /dev/console.
> The file supports poll() to detect virtual
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 20689b9..ced6b3e 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -1263,16 +1263,17 @@ static void pty_line_name(struct tty_driver *driver,
> int index, char *p)
> * @p: output buffer of at least 7 bytes
> *
> * Generate a name from a driver reference and write it to the output
> - * buffer.
> + * buffer. Return the number of bytes written.
> *
> * Locking: None
> */
> -static void tty_line_name(struct tty_driver *driver, int index, char *p)
> +static ssize_t tty_line_name(struct tty_driver *driver, int index, char *p)
> {
> if (driver->flags & TTY_DRIVER_UNNUMBERED_NODE)
> - strcpy(p, driver->name);
> + return sprintf(p, "%s", driver->name);
> else
> - sprintf(p, "%s%d", driver->name, index + driver->name_base);
> + return sprintf(p, "%s%d", driver->name,
> + index + driver->name_base);
> }
>
> /**
> @@ -3539,9 +3540,19 @@ static ssize_t show_cons_active(struct device *dev,
> if (i >= ARRAY_SIZE(cs))
> break;
> }
> - while (i--)
> - count += sprintf(buf + count, "%s%d%c",
> -cs[i]->name, cs[i]->index, i ? ' ':'\n');
> + while (i--) {
> + struct tty_driver *driver;
> + const char *name = cs[i]->name;
> + int index = cs[i]->index;
> +
> + driver = cs[i]->device(cs[i], &index);
> + if (driver) {
> + count += tty_line_name(driver, index, buf + count);
> + count += sprintf(buf + count, "%c", i ? ' ':'\n');
> + } else
> + count += sprintf(buf + count, "%s%d%c",
> +name, index, i ? ' ':'\n');
> + }
> console_unlock();
>
> return count;
> --
> 1.9.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: freshmeat editorial on journaling filesystems
>We'd like to run an editorial this coming Saturday about the >journaling filesystems available for Linux. We'd like an author who >isn't a developer on any of them so he/she can give an object analysis >of the pros and cons of each and share thoughts on his/her opinions >about which should be eventually be supported by the kernel. I disagree. I think you should ask someone who works on more than one of the filesystems. That person will know the pros and cons of all of them, and surely will be objective. --Ray Strode - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Additional info. for PCI VIA IDE crazyness. Please read.
Is this problem possibly related to my issues on alpha? (when compiling for PC164 optimizations instead of generic alphaI get a lost interrupt message as well ) --Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Happy new year^H^H^H^Hkernel..
Eric W. Biederman writes, >Some arches have separate maintenance but I don't believe alpha is. >Though I do believe it has a separate mailing list for alpha specific things, >to get better signal to noise ratio. Great! Do you know where I can find more info about it? --Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Happy new year^H^H^H^Hkernel..
>I want people to test it for a while, and I want to give other architectures >the chance to catch up with some of the changes Does that mean that other architectures have separate mailing lists and kernel source trees? Is that why i've been getting ignored =)? If so, what are they? I'd really like to get the bugs I've been experiencing on alpha figured out. --Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre7...
>The LDT fixes in particular fix some potentially random strange behaviour. >And the alpha memmove() thing was a showstopper bug on alphas. And the network lockup bug... --Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] in 2.4.0test12 and earlier
>the kernel locks up on my Alpha PC164 when network load is >high. It does it with several different NICs. >Also, If I try to compile the kernel for PC164 instead of generic, >then the computer gets irq probe errors for the hard drive, and >the computer doesn't boot. I hate to respond to my own mail, but does anyone here run linux on an Alpha? Is there a better place to ask these questions? --Ray Strode - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again
> I don't want to have any more network card problems. > I'm tired of this crappy 8139. hmmm... The only cards I'll buy are 8139 based (SMC EZNet 10/100). They have worked great on every OS i've tried and only cost 14 bucks at my local CompUSA. I love em to pieces... The newer ones are only like an inch tall too.. very slick. --Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[BUG] in 2.4.0test12 and earlier
I've posted these problems several times before, but I've never received any response, and I'd really like this problems worked out. I'd be happy to try anything that I can to assist in the bug tracking process. Basically, the kernel locks up on my Alpha PC164 when network load is high. It does it with several different NICs. Any ideas? Also, If I try to compile the kernel for PC164 instead of generic, then the computer gets irq probe errors for the hard drive, and the computer doesn't boot. Any ideas? I would really appreciate help in solving these problems. --Ray Strode - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
hard lockups
I have a PC164 Alpha (500Mhz) and I get hard lock ups randomly when accessing the internet. It happens very frequently (like within a few minutes) with 2.4 kernels, but happens much more infrequently with 2.2 kernels. Also, I have to compile the kernel for generic alpha (NOT PC164) otherwise I get ide-probe errors on bootup. My network card is a 3com boomerang (I think? it uses 3c59x.o and it's PCI). Any ideas? --Ray Strode _ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
