Re: PATCH: drivers/char/vt.c allows virtually locking up nonnetworkedmachine
On Sat, 30 Jun 2001, Rudolf Polzer wrote: > There is a problem concerning chvt. A normal user can run a > > bash$ while [ 1 ]; do chvt 11; done > > which cannot be killed using the console (only remotely, virtually never > on a nonnetworked multiuser machine). So I changed the kernel source code > so that only the superuser may change terminals. Ok, lemme see if I got this right. What exactly do you mean by 'a normal user' or a 'nonnetworked machine'. If the machine is non-networked, then it must be sort of single user. Oh yea, and if someone logs on from your console, smack them and don't patch the kernel. Oh yeah, I can imagine a few situations in which this would be necessary. But if someone you don't trust logs on from your (non-networked) console and has time to play with it, you're screwed anyway. Dan. - 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 http://www.tux.org/lkml/
Re: PATCH: drivers/char/vt.c allows virtually locking up nonnetworkedmachine
On Sat, 30 Jun 2001, Rudolf Polzer wrote: There is a problem concerning chvt. A normal user can run a bash$ while [ 1 ]; do chvt 11; done which cannot be killed using the console (only remotely, virtually never on a nonnetworked multiuser machine). So I changed the kernel source code so that only the superuser may change terminals. Ok, lemme see if I got this right. What exactly do you mean by 'a normal user' or a 'nonnetworked machine'. If the machine is non-networked, then it must be sort of single user. Oh yea, and if someone logs on from your console, smack them and don't patch the kernel. Oh yeah, I can imagine a few situations in which this would be necessary. But if someone you don't trust logs on from your (non-networked) console and has time to play with it, you're screwed anyway. Dan. - 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 http://www.tux.org/lkml/
Re: A Possible 2.5 Idea, maybe?
On Fri, 29 Jun 2001, Brent D. Norris wrote: > Recently one more than one subject there have been comments along the > lines of, "Do x, y and z because it would be great on desktops" and then > someone else will say "NO! becausing doing x, y, and z will make servers > run slow." Then as a final note someone else will say "Do y and z, but > not x, because that will make my handheld linux project a lot better." > Now whatever is eventually decided in each discusion, normally one > group/user walks away feeling they are getting the shortend of the stick. Ok, this is a problem. Though it was sort of discussed before when someone came with the idea of creating a 'home' linux-kernel edition (yuck!). > Now many of these things are configurable. If it is the amount of > messages that the boot of the kernel makes or even the "motivation" and > actions that the VM takes. It seems possible to configure the kernel so > that it would work optimally for each of the groups. The problem is that > the code in these sections is having to work in too different of > situations. Example : The VM is now somewhat more tweaked for servers > than it was previously. Many people were concerned about the > "interactivity" of it. Now it seems that it would be possible to change > the vm code so that it worked better for desktop users, but the > maintainers are not eager to do that because it would slow linux down in > the server market. Thats why we have /proc/... To echo things into it. > This all stems from one problem, which is a really great problem to have > if you must have a problem. Linux is spreading to largely different > kinds of machines with many different purposes. Microsoft solved this > problem by having several different kernels (NT code base for servers, 9x > code base for desktops, CE code base for handhelds), and this is somewhat > like what the "forking is a good thing" messge recommended for linux. I > disagree with that concept though. It is easy to see the trouble > microsoft is having with that and now they are trying to slowly merge the > two (NT,9x) together. Several kernel threads are hard to maintain, hard to evolve, hard to bugfix, modify patches, etc. Mainly, we should have a single kernel that can be tuned to fit people's needs. > Instead of forking the kernel or catering only to one group, instead why > not try this: Using the new CML2 tools and rulesets, make it possible to > have the kernel configured for the type of job it will be doing? Just > like CML2 asks our CPU type (i386, alpha, althon ...) and then goes out > and configures options for that, have it ask people "Is your machine a > server, workstation, embedded/handheld?" and configure things in the > kernel like the VM, bootup and others to optimize it for that job type? IMO, the Linux distributions out there should configure the kernel based on the type of system the (l[inux])user wants. Those who have the balls to compile their own system should know such things anyway. The rest, better rely on the distribution default and/or ask around and get some more info [the kernel configuration help is explicit enough anyway, given a decent level of common sense is used]. Dan. - 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 http://www.tux.org/lkml/
Re: A Possible 2.5 Idea, maybe?
On Fri, 29 Jun 2001, Brent D. Norris wrote: Recently one more than one subject there have been comments along the lines of, Do x, y and z because it would be great on desktops and then someone else will say NO! becausing doing x, y, and z will make servers run slow. Then as a final note someone else will say Do y and z, but not x, because that will make my handheld linux project a lot better. Now whatever is eventually decided in each discusion, normally one group/user walks away feeling they are getting the shortend of the stick. Ok, this is a problem. Though it was sort of discussed before when someone came with the idea of creating a 'home' linux-kernel edition (yuck!). Now many of these things are configurable. If it is the amount of messages that the boot of the kernel makes or even the motivation and actions that the VM takes. It seems possible to configure the kernel so that it would work optimally for each of the groups. The problem is that the code in these sections is having to work in too different of situations. Example : The VM is now somewhat more tweaked for servers than it was previously. Many people were concerned about the interactivity of it. Now it seems that it would be possible to change the vm code so that it worked better for desktop users, but the maintainers are not eager to do that because it would slow linux down in the server market. Thats why we have /proc/... To echo things into it. This all stems from one problem, which is a really great problem to have if you must have a problem. Linux is spreading to largely different kinds of machines with many different purposes. Microsoft solved this problem by having several different kernels (NT code base for servers, 9x code base for desktops, CE code base for handhelds), and this is somewhat like what the forking is a good thing messge recommended for linux. I disagree with that concept though. It is easy to see the trouble microsoft is having with that and now they are trying to slowly merge the two (NT,9x) together. Several kernel threads are hard to maintain, hard to evolve, hard to bugfix, modify patches, etc. Mainly, we should have a single kernel that can be tuned to fit people's needs. Instead of forking the kernel or catering only to one group, instead why not try this: Using the new CML2 tools and rulesets, make it possible to have the kernel configured for the type of job it will be doing? Just like CML2 asks our CPU type (i386, alpha, althon ...) and then goes out and configures options for that, have it ask people Is your machine a server, workstation, embedded/handheld? and configure things in the kernel like the VM, bootup and others to optimize it for that job type? IMO, the Linux distributions out there should configure the kernel based on the type of system the (l[inux])user wants. Those who have the balls to compile their own system should know such things anyway. The rest, better rely on the distribution default and/or ask around and get some more info [the kernel configuration help is explicit enough anyway, given a decent level of common sense is used]. Dan. - 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 http://www.tux.org/lkml/
Re: 2.4.5-ac20, make menuconfig problem
On Thu, 28 Jun 2001, f5ibh wrote: > make[4]: Entre dans le répertoire > `/usr/src/kernel-sources-2.4.5-ac20/drivers/pnp' > gcc -D__KERNEL__ -I/usr/src/kernel-sources-2.4.5-ac20/include -Wall > -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer > -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=k6 > -DEXPORT_SYMTAB -c pnp_bios.c > pnp_bios.c:252: warning: static declaration for `pnp_bios_dock_station_info' > follows non-static > pnp_bios.c:432: warning: no semicolon at end of struct or union gcc -v? - 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 http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Ok, my two cents. Print all copyright, config, etc. as KERN_DEBUG. Then use a 'verbose' or similar parameter to lilo/kernel to enable console printing of KERN_DEBUG, to be used when the system fails to boot, etc. Dan. - 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 http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Ok, my two cents. Print all copyright, config, etc. as KERN_DEBUG. Then use a 'verbose' or similar parameter to lilo/kernel to enable console printing of KERN_DEBUG, to be used when the system fails to boot, etc. Dan. - 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 http://www.tux.org/lkml/
Re: 2.4.5-ac20, make menuconfig problem
On Thu, 28 Jun 2001, f5ibh wrote: make[4]: Entre dans le répertoire `/usr/src/kernel-sources-2.4.5-ac20/drivers/pnp' gcc -D__KERNEL__ -I/usr/src/kernel-sources-2.4.5-ac20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=k6 -DEXPORT_SYMTAB -c pnp_bios.c pnp_bios.c:252: warning: static declaration for `pnp_bios_dock_station_info' follows non-static pnp_bios.c:432: warning: no semicolon at end of struct or union gcc -v? - 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 http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
export IFS=$'\n'
> lines=`ls -l | awk '{print "\""$0"\""}'`
> for i in $lines
> do
> echo line:$i
> done
-
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 http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
export IFS=$'\n'
lines=`ls -l | awk '{print \$0\}'`
for i in $lines
do
echo line:$i
done
-
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 http://www.tux.org/lkml/
Re: Client receives TCP packets but does not ACK
On Sun, Jun 17, 2001 at 05:13:43PM -0400, Albert D. Cahalan wrote: > > Is there any logical reason why if, given fd is a connected, AF_INET, > > SOCK_STREAM socket, and one does a write(fd, buffer, len); close(fd); > > to the peer, over a rather slow network (read modem, satelite link, etc), > > the data gets lost (the remote receives the disconnect before the last > > packet). According to socket(7), even if SO_LINGER is not set, the data > > is flushed in the background. > > > > Is it Linux or TCP specific? Or some obvious techincal detail I'm missing? > > The UNIX API (Linux, BSD, Solaris, OSF/1...) requires that you > put that write() call in a loop, because you can get partial > writes. Repeat until done... the OS might do 1 byte at a time. Not so true. The write is completed successfuly, ie. size == write(fd, buf, size); so the data actually gets to the kernel's network buffer, only the background polling is not done properly, in the way I see things. - 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 http://www.tux.org/lkml/
Re: Client receives TCP packets but does not ACK
On Sun, Jun 17, 2001 at 08:17:27PM +0200, Pavel Machek wrote: > > 2. There is a flaw in the TCP protocol itself that is extremely unlikely > > to bite people but can in theory cause wrong data in some unusual > > circumstances that Ian Heavans found and has yet to be fixed by > > the keepers of the protocol. Bit offtopic. Is there any logical reason why if, given fd is a connected, AF_INET, SOCK_STREAM socket, and one does a write(fd, buffer, len); close(fd); to the peer, over a rather slow network (read modem, satelite link, etc), the data gets lost (the remote receives the disconnect before the last packet). According to socket(7), even if SO_LINGER is not set, the data is flushed in the background. Is it Linux or TCP specific? Or some obvious techincal detail I'm missing? Thanks, Dan. - 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 http://www.tux.org/lkml/
Re: 2.4 VM & swap question
> Yes, I know there's no hard and fast rule for the exact ammount of ram/swap one > needs that will always work. However, in 2.2 for a 'workstation' one could > usually quite happily get away with having 128:128 and never have much of a > problem. with 2.4.0 and up this isn't the case. This has been the cause > of many people complaining quite loudly about 2.4 VM sucking and having > lots of OOM kills going about. It's also been called an 'aritificial limit' > since one of the VM people had a patch to 'fix' this. What I'm trying to > figure out is if this problem exists linearly or just with 'lower' ammounts > of total physical ram. ie if I jump up to 512mb and don't have a webserver > or database (ie I've got 512mb so I end up with a big disk cache) will I need > to have 1gb of swap just to keep the VM happy? Will 256 be enough? Could I > even live w/o swap? Probably you'd live with 512MB of swap. As for w/o swap? You need it atleast to hear the disks trashing and know you have to ctrl-c the damn process, if not anything else. I have: spiral:~# free total used free sharedbuffers cached Mem:254572 89936 164636 0 4352 48016 -/+ buffers/cache: 37568 217004 Swap: 530136 0 530136 With X, netscape and a gcc running and doing quite fine. - 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 http://www.tux.org/lkml/
Re: 2.4 VM & swap question
On Sun, Jun 17, 2001 at 10:48:36AM -0700, Tom Rini wrote: > 'lo all. I've got a question about swap and RAM requirements in 2.4. Now, > when 2.4.0 was kicked out, the fact that you need swap=2xRAM was mentioned. > But what I'm wondering is what exactly are the limits on this. Right now > I've got an x86 box w/ 128ram and currently 256swap. When I had 128, I'd get > low on ram/swap after some time in X, and doing this seems to 'fix' it, in > 2.4.4. However, I've also got 2 PPC boxes, both with 256:256 in 2.4. One > of which never has X up, but lots of other activity, and swap usage seems > to be about the same as 2.2.x (right now 'free' says i'm ~40MB into swap, > 18day+ uptime). The other box is a laptop and has X up when it's awake and > that too doesn't seem to have any problem. So what exactly is the real > minium swap ammount? I doubt there is a limit. I think 'it depends on what you're planning to do' is the correct answer. For a blank router, 32mb ram/64 swap can be enough, for a web/database server, you need more, etc. - 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 http://www.tux.org/lkml/
Re: 2.4 VM swap question
On Sun, Jun 17, 2001 at 10:48:36AM -0700, Tom Rini wrote: 'lo all. I've got a question about swap and RAM requirements in 2.4. Now, when 2.4.0 was kicked out, the fact that you need swap=2xRAM was mentioned. But what I'm wondering is what exactly are the limits on this. Right now I've got an x86 box w/ 128ram and currently 256swap. When I had 128, I'd get low on ram/swap after some time in X, and doing this seems to 'fix' it, in 2.4.4. However, I've also got 2 PPC boxes, both with 256:256 in 2.4. One of which never has X up, but lots of other activity, and swap usage seems to be about the same as 2.2.x (right now 'free' says i'm ~40MB into swap, 18day+ uptime). The other box is a laptop and has X up when it's awake and that too doesn't seem to have any problem. So what exactly is the real minium swap ammount? I doubt there is a limit. I think 'it depends on what you're planning to do' is the correct answer. For a blank router, 32mb ram/64 swap can be enough, for a web/database server, you need more, etc. - 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 http://www.tux.org/lkml/
Re: 2.4 VM swap question
Yes, I know there's no hard and fast rule for the exact ammount of ram/swap one needs that will always work. However, in 2.2 for a 'workstation' one could usually quite happily get away with having 128:128 and never have much of a problem. with 2.4.0 and up this isn't the case. This has been the cause of many people complaining quite loudly about 2.4 VM sucking and having lots of OOM kills going about. It's also been called an 'aritificial limit' since one of the VM people had a patch to 'fix' this. What I'm trying to figure out is if this problem exists linearly or just with 'lower' ammounts of total physical ram. ie if I jump up to 512mb and don't have a webserver or database (ie I've got 512mb so I end up with a big disk cache) will I need to have 1gb of swap just to keep the VM happy? Will 256 be enough? Could I even live w/o swap? Probably you'd live with 512MB of swap. As for w/o swap? You need it atleast to hear the disks trashing and know you have to ctrl-c the damn process, if not anything else. I have: spiral:~# free total used free sharedbuffers cached Mem:254572 89936 164636 0 4352 48016 -/+ buffers/cache: 37568 217004 Swap: 530136 0 530136 With X, netscape and a gcc running and doing quite fine. - 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 http://www.tux.org/lkml/
Re: Client receives TCP packets but does not ACK
On Sun, Jun 17, 2001 at 08:17:27PM +0200, Pavel Machek wrote: 2. There is a flaw in the TCP protocol itself that is extremely unlikely to bite people but can in theory cause wrong data in some unusual circumstances that Ian Heavans found and has yet to be fixed by the keepers of the protocol. Bit offtopic. Is there any logical reason why if, given fd is a connected, AF_INET, SOCK_STREAM socket, and one does a write(fd, buffer, len); close(fd); to the peer, over a rather slow network (read modem, satelite link, etc), the data gets lost (the remote receives the disconnect before the last packet). According to socket(7), even if SO_LINGER is not set, the data is flushed in the background. Is it Linux or TCP specific? Or some obvious techincal detail I'm missing? Thanks, Dan. - 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 http://www.tux.org/lkml/
Re: Client receives TCP packets but does not ACK
On Sun, Jun 17, 2001 at 05:13:43PM -0400, Albert D. Cahalan wrote: Is there any logical reason why if, given fd is a connected, AF_INET, SOCK_STREAM socket, and one does a write(fd, buffer, len); close(fd); to the peer, over a rather slow network (read modem, satelite link, etc), the data gets lost (the remote receives the disconnect before the last packet). According to socket(7), even if SO_LINGER is not set, the data is flushed in the background. Is it Linux or TCP specific? Or some obvious techincal detail I'm missing? The UNIX API (Linux, BSD, Solaris, OSF/1...) requires that you put that write() call in a loop, because you can get partial writes. Repeat until done... the OS might do 1 byte at a time. Not so true. The write is completed successfuly, ie. size == write(fd, buf, size); so the data actually gets to the kernel's network buffer, only the background polling is not done properly, in the way I see things. - 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 http://www.tux.org/lkml/
Re: Linux 2.4.4-ac6
On Wed, 9 May 2001, Alan Cox wrote: ... > 2.4.4-ac6 ... To be sincere I was expecting the Athlone pre-pre-pre-patch/fix to be included. - 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 http://www.tux.org/lkml/
Re: Linux 2.4.4-ac6
On Wed, 9 May 2001, Alan Cox wrote: ... 2.4.4-ac6 ... To be sincere I was expecting the Athlone pre-pre-pre-patch/fix to be included. - 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 http://www.tux.org/lkml/
Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability
> No matter if I use the mandrake 8 gcc 2.96 or a self compiled gcc 2.95.3. Mandrake 8's kernel comes with i586 CPU support, it is alredy known it works. Remember that the instability occurs only when Athlon optimizations are used. - 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 http://www.tux.org/lkml/
Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability
No matter if I use the mandrake 8 gcc 2.96 or a self compiled gcc 2.95.3. Mandrake 8's kernel comes with i586 CPU support, it is alredy known it works. Remember that the instability occurs only when Athlon optimizations are used. - 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 http://www.tux.org/lkml/
Re: Current status of NTFS support
On Fri, 20 Apr 2001 [EMAIL PROTECTED] wrote: > > So how risky is this? Risky enough. I had to chkdsk once for half an hour after copying on an NTFS 5. Of course, I'm not familiar with the internals of it. > > Also, I'll have to recreate my Linux partitions after the upgrade. Does anyone > know if FIPS can split a partition safely that was created under Windows > NT? As far as I know, it doesn't know about NTFS. I might be wrong though. Get some Partition Magic that is bit wiser. - 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 http://www.tux.org/lkml/
Re: Current status of NTFS support
On Fri, 20 Apr 2001 [EMAIL PROTECTED] wrote: So how risky is this? Risky enough. I had to chkdsk once for half an hour after copying on an NTFS 5. Of course, I'm not familiar with the internals of it. Also, I'll have to recreate my Linux partitions after the upgrade. Does anyone know if FIPS can split a partition safely that was created under Windows NT? As far as I know, it doesn't know about NTFS. I might be wrong though. Get some Partition Magic that is bit wiser. - 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 http://www.tux.org/lkml/
Re: Data-corruption bug in VIA chipsets
On 13 Apr 2001, Doug McNaught wrote: > Alan Cox <[EMAIL PROTECTED]> writes: > > > > Here might be one of the resons for the trouble with VIA chipsets: > > > > > > http://www.theregister.co.uk/content/3/18267.html > > > > > > Some DMA error corrupting data, sounds like a really nasty bug. The > > > information is minimal on that page. > > > > What annoys me is that we've known about the problem for _ages_. If you look > > the 2.4 kernel has experimental workarounds for this problem. VIA never once > > even returned an email to say 'we are looking into this'. Instead people sat > > there flashing multiple BIOS images and seeing what made the difference. > > Is this problem likely to affect 2.2.X? I have a VIA-based board on > order (Tyan Trinity) and I don't plan to run 2.4 on it anytime soon > (it's upgrading a stock RH6.2 box). > We've had HUGE problems with 2.4.x kernels and VIA based boards. We have here 3 VIA boards with Athlon/850 and Duron/900 CPUs. The problem goes like this: Compile 2.4.3 with VIA and Athlon support. Reboot. Ooopses (between 1 and continuously scrolling of them) occur at random periods of time, between mounting the root filesystem and 2-3 minutes of functionality. Note that the problem occurs with all versions of 2.4 but not with 2.2.17-2.2.19. Also, enabling or disabling DMA doesn't help fix the problem. After several compiles, it appears that compiling with 586 cpu support instead of Athlon resulted in a working, stable kernel (which is rather strange imo, given there are different CPUs but the same board model). However, compiling with 386 support didn't (which was my first guess of a stable system). I was a bit lazy and didn't save/ksymoops any of the oopses, but will do if this is not a well-known problem (and it appears that more or less it is). My lspci: 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03) 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 40) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16) 00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super AC97/Audio] (rev 50) 00:0b.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) (although the cards stuck in the PCIs aren't the same for all three systems) and /proc/cpuinfo (from the kernel with 586 support): processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 851.961 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips: 1697.38 I know that all in all this is rather irrelevant, but if further information is needed, drop me a line and I'll try be a good boy (tm) :) Yours, Dan. - 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 http://www.tux.org/lkml/
Re: Data-corruption bug in VIA chipsets
On 13 Apr 2001, Doug McNaught wrote: Alan Cox [EMAIL PROTECTED] writes: Here might be one of the resons for the trouble with VIA chipsets: http://www.theregister.co.uk/content/3/18267.html Some DMA error corrupting data, sounds like a really nasty bug. The information is minimal on that page. What annoys me is that we've known about the problem for _ages_. If you look the 2.4 kernel has experimental workarounds for this problem. VIA never once even returned an email to say 'we are looking into this'. Instead people sat there flashing multiple BIOS images and seeing what made the difference. Is this problem likely to affect 2.2.X? I have a VIA-based board on order (Tyan Trinity) and I don't plan to run 2.4 on it anytime soon (it's upgrading a stock RH6.2 box). We've had HUGE problems with 2.4.x kernels and VIA based boards. We have here 3 VIA boards with Athlon/850 and Duron/900 CPUs. The problem goes like this: Compile 2.4.3 with VIA and Athlon support. Reboot. Ooopses (between 1 and continuously scrolling of them) occur at random periods of time, between mounting the root filesystem and 2-3 minutes of functionality. Note that the problem occurs with all versions of 2.4 but not with 2.2.17-2.2.19. Also, enabling or disabling DMA doesn't help fix the problem. After several compiles, it appears that compiling with 586 cpu support instead of Athlon resulted in a working, stable kernel (which is rather strange imo, given there are different CPUs but the same board model). However, compiling with 386 support didn't (which was my first guess of a stable system). I was a bit lazy and didn't save/ksymoops any of the oopses, but will do if this is not a well-known problem (and it appears that more or less it is). My lspci: 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03) 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 40) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16) 00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super AC97/Audio] (rev 50) 00:0b.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) (although the cards stuck in the PCIs aren't the same for all three systems) and /proc/cpuinfo (from the kernel with 586 support): processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 851.961 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips: 1697.38 I know that all in all this is rather irrelevant, but if further information is needed, drop me a line and I'll try be a good boy (tm) :) Yours, Dan. - 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 http://www.tux.org/lkml/
linux-2.4.0-test11-pre6 fails to compile
Hello everybody,
When attempting to compile test11-pre6 it crashes out with:
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686
-DNTFS_IN_LINUX_KERNEL -DNTFS_VERSION=\"000607\" -c -o inode.o inode.c
inode.c:1054: conflicting types for `new_inode'
/usr/src/linux/include/linux/fs.h:1153: previous declaration of
`new_inode'
make[3]: *** [inode.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.0-test11-pre6/fs/ntfs'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.0-test11-pre6/fs/ntfs'
make[1]: *** [_subdir_ntfs] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.0-test11-pre6/fs'
make: *** [_dir_fs] Error 2
Indeed, in fs/ntfs/inode.c we have a
static int new_inode (ntfs_volume* vol,int* result) { ... }
while in include/linux/fs.h an
static inline struct inode * new_inode(struct super_block *sb) { ... }
It appears that simply renaming new_inode to, for instance, ntfs_new_inode
makes it compile cleanly
--- fs/ntfs/inode.c.origFri Nov 17 19:40:43 2000
+++ fs/ntfs/inode.c Fri Nov 17 19:41:49 2000
@@ -1050,7 +1050,7 @@
/* We have to skip the 16 metafiles and the 8 reserved entries */
static int
-new_inode (ntfs_volume* vol,int* result)
+ntfs_new_inode (ntfs_volume* vol,int* result)
{
int byte,error;
int bit;
@@ -1236,11 +1236,11 @@
ntfs_volume* vol=dir->vol;
int byte,bit;
- error=new_inode (vol,&(result->i_number));
+ error=ntfs_new_inode (vol,&(result->i_number));
if(error==ENOSPC){
error=ntfs_extend_mft(vol);
if(error)return error;
- error=new_inode(vol,&(result->i_number));
+ error=ntfs_new_inode(vol,&(result->i_number));
}
if(error){
ntfs_error ("ntfs_get_empty_inode: no free inodes\n");
Compiling also breaks at net/core/dev.c
make[3]: Entering directory `/usr/src/linux-2.4.0-test11-pre6/net/core'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o
dev.o dev.c
dev.c: In function `run_sbin_hotplug':
dev.c:2736: `hotplug_path' undeclared (first use in this function)
dev.c:2736: (Each undeclared identifier is reported only once
dev.c:2736: for each function it appears in.)
make[3]: *** [dev.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.0-test11-pre6/net/core'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.0-test11-pre6/net/core'
make[1]: *** [_subdir_core] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.0-test11-pre6/net'
make: *** [_dir_net] Error 2
After a bit of digging, it appears to me that the whole bottom part of
net/core/dev.c should be wrapped in an #ifdef CONFIG_HOTPLUG, like in:
--- net/core/dev.c.orig Fri Nov 17 19:55:25 2000
+++ net/core/dev.c Fri Nov 17 20:04:02 2000
@@ -2712,6 +2712,7 @@
* Currently reported events are listed in netdev_event_names[].
*/
+#ifdef CONFIG_HOTPLUG
/* /sbin/hotplug ONLY executes for events named here */
static char *netdev_event_names[] = {
[NETDEV_REGISTER] = "register",
@@ -2765,3 +2766,4 @@
printk (KERN_WARNING "unable to register netdev
notifier\n"
KERN_WARNING "/sbin/hotplug will not be run.\n");
}
+#endif
... and init/main.c
--- init/main.c.origFri Nov 17 20:15:39 2000
+++ init/main.c Fri Nov 17 20:13:52 2000
@@ -712,11 +712,13 @@
init_pcmcia_ds(); /* Do this last */
#endif
+#ifdef CONFIG_HOTPLUG
/* do this after other 'do this last' stuff, because we want
* to minimize spurious executions of /sbin/hotplug
* during boot-up
*/
net_notifier_init();
+#endif
/* Mount the root filesystem.. */
mount_root();
After this, everything seems and runs okay.
Be seeing you around.
--
Dan Podeanu,
Extreme Solutions Inc., Bucharest, Romania.
-
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/
linux-2.4.0-test11-pre6 fails to compile
Hello everybody,
When attempting to compile test11-pre6 it crashes out with:
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686
-DNTFS_IN_LINUX_KERNEL -DNTFS_VERSION=\"000607\" -c -o inode.o inode.c
inode.c:1054: conflicting types for `new_inode'
/usr/src/linux/include/linux/fs.h:1153: previous declaration of
`new_inode'
make[3]: *** [inode.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.0-test11-pre6/fs/ntfs'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.0-test11-pre6/fs/ntfs'
make[1]: *** [_subdir_ntfs] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.0-test11-pre6/fs'
make: *** [_dir_fs] Error 2
Indeed, in fs/ntfs/inode.c we have a
static int new_inode (ntfs_volume* vol,int* result) { ... }
while in include/linux/fs.h an
static inline struct inode * new_inode(struct super_block *sb) { ... }
It appears that simply renaming new_inode to, for instance, ntfs_new_inode
makes it compile cleanly
--- fs/ntfs/inode.c.origFri Nov 17 19:40:43 2000
+++ fs/ntfs/inode.c Fri Nov 17 19:41:49 2000
@@ -1050,7 +1050,7 @@
/* We have to skip the 16 metafiles and the 8 reserved entries */
static int
-new_inode (ntfs_volume* vol,int* result)
+ntfs_new_inode (ntfs_volume* vol,int* result)
{
int byte,error;
int bit;
@@ -1236,11 +1236,11 @@
ntfs_volume* vol=dir-vol;
int byte,bit;
- error=new_inode (vol,(result-i_number));
+ error=ntfs_new_inode (vol,(result-i_number));
if(error==ENOSPC){
error=ntfs_extend_mft(vol);
if(error)return error;
- error=new_inode(vol,(result-i_number));
+ error=ntfs_new_inode(vol,(result-i_number));
}
if(error){
ntfs_error ("ntfs_get_empty_inode: no free inodes\n");
Compiling also breaks at net/core/dev.c
make[3]: Entering directory `/usr/src/linux-2.4.0-test11-pre6/net/core'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o
dev.o dev.c
dev.c: In function `run_sbin_hotplug':
dev.c:2736: `hotplug_path' undeclared (first use in this function)
dev.c:2736: (Each undeclared identifier is reported only once
dev.c:2736: for each function it appears in.)
make[3]: *** [dev.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.0-test11-pre6/net/core'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.0-test11-pre6/net/core'
make[1]: *** [_subdir_core] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.0-test11-pre6/net'
make: *** [_dir_net] Error 2
After a bit of digging, it appears to me that the whole bottom part of
net/core/dev.c should be wrapped in an #ifdef CONFIG_HOTPLUG, like in:
--- net/core/dev.c.orig Fri Nov 17 19:55:25 2000
+++ net/core/dev.c Fri Nov 17 20:04:02 2000
@@ -2712,6 +2712,7 @@
* Currently reported events are listed in netdev_event_names[].
*/
+#ifdef CONFIG_HOTPLUG
/* /sbin/hotplug ONLY executes for events named here */
static char *netdev_event_names[] = {
[NETDEV_REGISTER] = "register",
@@ -2765,3 +2766,4 @@
printk (KERN_WARNING "unable to register netdev
notifier\n"
KERN_WARNING "/sbin/hotplug will not be run.\n");
}
+#endif
... and init/main.c
--- init/main.c.origFri Nov 17 20:15:39 2000
+++ init/main.c Fri Nov 17 20:13:52 2000
@@ -712,11 +712,13 @@
init_pcmcia_ds(); /* Do this last */
#endif
+#ifdef CONFIG_HOTPLUG
/* do this after other 'do this last' stuff, because we want
* to minimize spurious executions of /sbin/hotplug
* during boot-up
*/
net_notifier_init();
+#endif
/* Mount the root filesystem.. */
mount_root();
After this, everything seems and runs okay.
Be seeing you around.
--
Dan Podeanu,
Extreme Solutions Inc., Bucharest, Romania.
-
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: uid
On Mon, 18 Sep 2000, Christopher Allen Wing wrote: .. snipped .. > tar should work okay, I think; by default it uses textual user names > instead of numeric UIDs. Not true. All the kernels I download from a certain local mirror are owned by the local user 'tarabas' since the uid happens to be the same with those on the mirror site. So numeric uids. - 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: uid
On Mon, 18 Sep 2000, Christopher Allen Wing wrote: .. snipped .. tar should work okay, I think; by default it uses textual user names instead of numeric UIDs. Not true. All the kernels I download from a certain local mirror are owned by the local user 'tarabas' since the uid happens to be the same with those on the mirror site. So numeric uids. - 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/
