Kernel Traffic #160 For 1 Apr 2002

There were 465 different contributors. 233 posted more than once. 192 posted last week too.

David Schwartz asked if anyone was working on support for Protection of BGP Sessions via the TCP MD5 Signature Option under Linux. He added, "My interest for this is mostly for Zebra to be able to make secure BGP connections, so I would also contribute a patch for Zebra to support this feature on Linux." Alan Cox replied, "Since this memo was first issued (under a different title), the MD5 algorithm has been found to be vulnerable to collision search attacks [Dobb], and is considered by some to be insufficiently strong for this type of application." Elsewhere, David S. Miller had harsher words:

There is no reason to not be doing this MD5 garbage in userspace. Whoever thought to do this in the protocol itself was smoking something.

And if people want encryption they can use ipsec. And if ipsec is broken it should be fixed because adding a new abomination to MD5.

Maybe I'm missing something, but I see no reason this MD5 stuff belongs in the protocol and not in the APP.

Alan added that even in userspace, MD5 was not the best choice. He said, "The crypto folks prefer SHA and for good reasons." David Schwartz replied:

There is no problem with MD5 that makes it unsuitable for this particular application. A SHA signature would enlarge each packet, further reducing the effective MTU. This would increase the cost of what was intended to be a simple mechanism to solve a specific problem (spoofed SYNs/RSTs).

What it comes down to is simply whether you care whether Linux machines can interoperate with Cisco's BGP authentication scheme. This feature would be very useful to me, so I personally do care, even if the scheme is not the best possible scheme.

David S. Miller replied that ignoring valid RST frames would break TCP, and Alan said:

If they don't have the right MD5 frame they are not valid. The RFC came about because people discovered RST spoofing cisco backbone routers was a great way to remove unwanted ISP's. Then people discovered that spoofing icmp df framesizes down to 68 bytes worked anyway and the whole MD5 thing went to shit.

Later crypto folks showed that MD5 is not always good enough

Finally if you are patient and extremely irritating you can capture BGP sessions, predict the next time the other end will initiate that sequence number and do BGP replay games. Fortunately thats extremely hard.

IPSEC has a lot more going for it, but most cisco's still only support the MD5 stuff. However if you can get/set IP/TCP options in user space you could I guess do it that way

David S. Miller replied, "I frankly don't care what Cisco's do or do not do. I don't care if Cisco made a rotten decision. I'm not going to let Cisco's mistakes crap up Linux's networking." He pointed out that Alan's point about the frames actually being invalid was not a fair objection. MD5 signatures, he went on, were inherently against the simplicity and clarity required for RST to function properly. For that reason, PAWS timestamps and other checks were disabled for RST frames. Only the sequence number would be verified. So it made no sense to say the frames were invalid just because of an MD5 signature that was never used.

Alan felt David was talking out of his ass, and said, "I'm not saying the RFC is a good idea (tho its a needed patch to use Linux for backbone routing sanely with most vendors BGP kit). Your argument about the RST frame is however pure horseshit." But David S. Miller reasserted, "Look, TCP is the last place more complexity needs to exist. Errors in logic in TCP need to be dealt with by breaking the connection and spitting a RST out, and it must be done in a way that is as easy to verify as possible."

Alan still disagreed, but said instead, "I've actually got a more constructive suggestion for the zebra folks. Route the BGP crap through a netlink tap device, mangle and unmangle the tcp frames in luserspace. Saves doing TCP in userspace, saves screwing up Dave's nice networking stack. You'll still need to kill SACK support to make it fit." And David S. Miller added, "Another solution could involve a netfilter module to mangle the packets."

Alan thought David S. Miller's solution would be fast enough for David Schwartz's needs, but then David S. Miller came back with, "After some thinking, the TAP idea is even nicer as it guarentees zero overhead, make it such that you only route the BGP stuff over the device having the TAP attached (make a dummy eth alias just for this purpose)." Mike Fedyk pointed out that this wouldn't be more efficient, because "You'd have to use netfilter to mark the correct packets, then route on that mark to the dummy interface." But David S. Miller said, "You can bind sockets to specific devices under Linux, this does not require netfilter."

Someone asked what the maximum number of threads was on a Linux system. The poster saw lockups after creating around 250 or 275 threads, and wanted to increase the limit. David Schwartz suggested fixing the bug rather than trying to work around it. But he added, "In any event, don't create so many threads. Create threads only to keep CPUs busy or to pend I/Os that can't be done asynchronously." Davide Libenzi suggested 'ulimit -u' to get the maximum allowable threads on a system, but Bill Davidsen said that /proc/sys/kernel/threads-max was the true system limit. James Bourne remarked, "One thing to note here, using pthreads there is a limit of 1024 threads per process. There are patches to glibc to increase this to a larger number (4096 or 8192)." And at one point Peter Wæchtler added, "There is another limit creeping in: pthread mmap()s 2 MB of stack for each thread. So you run out of address space on 32 bit systems with threads > 1024 (and smaller)"

Michal Jaegermann asked what the maximum paritition size was on ext2 or ext3. He was running into problems with partitions around 2 terabytes in size. Andreas Dilger replied:

2TB is the limit for all block devices in 2.2 and 2.4 kernels. This is from 2^32 * 512 byte sectors. Using LVM or MD devices will not overcome this limitation.

There was a patch floating around which extended the block counts to 64-bit ints (Jens Axboe and/or Ben LaHaise posted it), and I think at least part of it is in 2.5. Even if you have 64-bit block counts, there are other issues which pop up fairly soon - 32-bit page indexes and other 32-bit overflows in calculations in the ext2 code. There is definitely a hard limit at 16TB for 4kB block ext2 filesystems, but I suspect you will have problems at 8TB even after the 2TB block device limit is lifted.

This is bad, very bad. If the bill passes as written, all software will be subject to it. Senator Hollings and his cronies (and anyone who thinks like them) need to get a clue. They need to be out of office.

(My apologies in advance if this does not come across as text. My regular system is broken and I'm forced to use Winsucks and Nutscrape for my mail.)

http://www.wired.com/news/politics/0,1283,51274,00.html

The obvious solution is to continue the way Richard Stallman envisaged: Distribute all code in source form only - no binary distributions.

This way, the source files are protected under freedom of speech rules and the originator of the work is safe.

It is then up to the user to do with the code what he/she wants.

I think that while many people think that Richard is paranoid, he actually was far more prophetic than most people wants to give him credit for...

Florian Weimer replied, "Unfortunately, this works only in the U.S. Other countries which will follow the US leadership in consumer suppression regulate free speech to make it conforming to law. I agree, though, that source-only distribution avoids many problems and is preferable."

Elsewhere, Itai Nahshon remarked, "Worst thing happens if somebody gets a patent for the copy protection schemes..." Alan Cox replied, "Microsoft already do." But Herman Oosthuysen replied, "The bill says that the protection scheme must be open source, so no M$ tax. I guess lots of Americans are going to tune in to European content if this bill passes. It should be a boon to Canada and Mexico too. Maybe we should support this bill..." But Rik van Riel said:

The fact that the source code is available doesn't give you the right to use it, if some company has a patent on the technology ...

I hope this law will be so absolutely crippling to the USA that the rest of the world will see the devastating effects before having the time to pass similar laws too.

If the law requires you to use it, then M$ won't be able to charge royalties for a patent on it. There are enough precedents of that kind of thing, so it will be free.

The whole idea however remains impractical, so even if it does pass into law, it would be largely irrelivant to any marginally competent geek.

What the music industry fails to understand, is that the music doesn't sell because it is bad. No amount of controls can compensate for that. Garbage in, Garbage out... Maybe they should go back to vinyl records that play on wind-up players with rose thorn pickups. That will instantly make music recordings incompatible with all CD equipment and nobody will want to copy it...

Jim MacBaine asked if there were a working ftape driver for 2.4, and Mikael Pettersson replied, "The one included in current 2.4 kernels should still work for most ftape hardware. 2.5 has a minor but fixable compile problem due to the virt_to_bus() interface change." He added of the drivers, that "They're not exactly popular, but I still use my old Seagate/Conner TR-3 unit on a remote server."

This is to announce that the new NTFS Linux kernel driver 2.0.0 (formerly NTFS TNG) is now finished (read-only). It is for kernel 2.5.7 only and will be submitted to Linus for inclusion in the 2.5 kernel series when Linus returns from his holiday.

The driver has been tested extensively and has survived all tests so far.

It is fully compatible with kernel preemption and SMP. And it should work on both little endian and big endian architectures, and both on 32 and 64 bit architectures. Note, only ia32 has actually been tested and there may be problems with architectures not supporting unaligned accesses. Any volunteers for non-ia32 architectures?

The new driver is significantly faster than the old driver (~20% in my tests), uses less CPU time and generally is superior to the old driver. (-:

The driver can be compiled both with gcc-2.95 and gcc-2.96. gcc-3.x has not been tested. (If anyone experiences compilation problems especially with gcc-2.95 please let me know and they will be fixed ASAP!)

To try the driver either use BitKeeper to obtain a clone from the repository:

bk clone -q http://linux-ntfs.bkbits.net/ntfs-tng-2.5

Or if you already have a clone derived from an official kernel repository you only need to pull in the changes:

bk pull http://linux-ntfs.bkbits.net/ntfs-tng-2.5

And then checkout all the files using bk -r co -q from within the repository directory.

For people not using BitKeeper patches for the standard 2.5.7 kernel are available here:

http://www-stu.christs.cam.ac.uk/~aia21/linux/linux-2.5.7-ntfs-2.0.0.patch.bz2
(151kiB)

http://www-stu.christs.cam.ac.uk/~aia21/linux/linux-2.5.7-ntfs-2.0.0.patch.gz
(199kiB)

http://www-stu.christs.cam.ac.uk/~aia21/linux/linux-2.5.7-ntfs-2.0.0.patch
(796kiB)

Finally, for people wanting to browse the source code on-line, point your web browser at:

http://linux-ntfs.bkbits.net:8080/ntfs-tng-2.5

Please everyone courageous enough to use a bleeding edge kernel and who is also an NTFS user give this a try and let me know if you encounter any problems! - Thanks!

Elsewhere, David Woodhouse pointed out that all architectures should support unaligned access, and so Anton's concern that there may be problems with any architecture not supporting that, was invalid. But Brad Boyer replied, "Perhaps all architectures "should", but I can assure you that many of them do no such thing. I didn't look at every current architecture, but some notable ones like the brand new IA64, as well as some older chips such as MIPS have some relatively complicated code in get_unaligned(), which can be found in the appropriate include/asm-i<arch> directory in the file unaligned.h. I suspect that at least some of these allow for an exception handler to fake the capability in user space programs, but that isn't something you can allow inside the kernel." And Alan Cox replied:

The Linux kernel assumes and requires that a processor handles alignment faults and fixups in kernel space.

This is done because there are many cases where an object is almost always aligned and it is faster to assume alignment than to mess around with every single chunk of data. Its tuned so those alignment traps should not be occurring at a high rate.

David S. Miller applied an ATM patch, and remarked, "ATM sorely needs a maintainer. Any of the kernel janitors want to learn how ATM works? :-))))" Dave Jones asked, "Isn't someone maintaining it outside the tree somewhere?" But David replied, "If they are, they aren't sending me any patches or updates, which effectively means it is still not maintained."

A while ago, I did some longish runs of OSDB (osdb.sf.net) against PostgreSQL 7.2. All runs were on kernel 2.5.6 + the dc395x driver and the futexes patch. I'd have included reiserfs too, but in 2.5.6 it seemed to oops on mount. 2.5.7 doesn't boot for me, but I'll run these again when a more interesting kernel appears.

Hardware is: 2 x P3-450, 384Mb, 3 x 9Gb Quantum disks on internal aic7xxx (new driver). Except for a "vmstat 1", the system was otherwise unused during the tests. There was no other mounted filesystem on the disk with the test partition. The numbers seem pretty consistent -- if they're more than 5% different, that's probably a valid comparision (no, I'm not a statistician and can't justify that).

The scripts I used are available on request, but they do roughly:

stop postgres
umount
mkfs
mount
create postgres data directories
start postgres (incl. creating postgres database)
"osdb-pg --datadir /scratch/data-40mb/ --short"

"Tuning" key:
"dd" -- default PG, default FS opts
"dn" -- default PG, "noatime"
"bn" -- big PG buffers, "noatime"

                PostgreSQL
        tuning? single  ir      mx-ir   oltp    mixed-oltp
                (sec)   (tps)   (sec)   (tps)   (sec)
ext2    dd      1304.72 66.64   214.25  188.50  230.55
        dn      1288.31 65.93   209.57  234.08  213.75   
        bn      1283.50 77.90   1867.71 192.43  226.77

ext3    dd      1303.84 66.87   212.49  66.06   361.04
        dn      1288.03 64.62   209.27  111.41  278.54
        bn      1285.32 65.98   1996.41 90.05   307.79

ext3-wb dn      1291.68 66.06   209.94  138.25  242.28
        bn      1287.31 98.42   2149.38 125.13  236.02

jfs     dd      1308.97 66.82   212.59  117.28  273.08
        dn      1288.60 65.08   211.56  116.18  218.22
        bn      1279.89 81.00   2059.26 114.20  225.56

minix   dd      1305.26 67.38   207.74  193.90  228.81
        dn      1331.27 67.14   210.07  223.70  214.33
        bn      1299.24 89.58   1988.31 231.17  231.17

My conclusions:

I'll have to spend more time learning to tune postgres, but clearly something went wrong there -- the "agg_simple_report" test accounted for almost all of the differences.
"noatime" is very useful switch for these circumstances.
The journalled filesystems do have measurable overhead for this workload.

Questions:

Is there anything else I should try in the way of fs options, etc?
What does jfs do in the way of data journalling? Is it "ordered" or "writeback", in ext3-speak? (I assume fully journalled data would give much worse performance.)

Andi Kleen asked if ext3 contained ordered data, and Matthew confirmed, "Yep. Everything is default unless otherwise stated." Andi also exclaimed in his same post, "Wow minix is faster than ext2 @) That certainly looks strange." And Matthew replied, "Yeah, I thought it was a little odd. Postgres does so much fsync()ing that I thought it may just have been that the lower overhead won out over ext2's cleverer layout. All the I/O was basically fsync-driven, so this test was only about write performance." Andrew Morton replied:

For fsync-intensive loads ext3's best mode is generally data=journal. That way, an fsync is satisfied by a nice single linear write to the journal.

With a high volume of data you'll quickly exhaust the journal space so it would also be beneficial to create a monster journal with, say, mke2fs -J 400.

Here we are. This is with just a 200Mb journal (the partition is only a little over 1Gb, and the datafiles grow fairly big, so I didn't brave making it any bigger).

        tuning? single  ir      mx-ir   oltp    mixed-oltp
                (sec)   (tps)   (sec)   (tps)   (sec)
ext3    bn      1285.32 65.98   1996.41 90.05   307.79
ext3-wb bn      1287.31 98.42   2149.38 125.13  236.02
ext3-jd bn      1306.90 72.07   1813.54 125.15  305.27

The I/O load should be almost exclusively fsync-driven writes, so I'm not sure how to account for the fact that the OLTP and OLTP + misc (mostly read) activity give different numbers.

I'll try to find time to run these again tomorrow to convince myself that all is sane, but these numbers are usually pretty stable.

Andrew was a bit disappointed, and added, "It sounds like a useful and valid workload to optimise for. So I'll take you up on the offer of those scripts, please." Matthew sent them over.

Back in Andi's original reply, he asked if Matthew could also test XFS (and elsewhere, Florin Andrei also asked for this). Matthew replied, "Sure. I'll try to build a more interesting kernel sometime this week. ext2 with delalloc might be fun, too. Do you know of any simple patch or patches which might get reiserfs working on 2.5.6?" There was no reply.

Andi had also originally remarked in reply to Matthew's conclusion that journalled filesystems had measurable overhead for the workload he'd tested:

Normally (non data journaling, noatime) journaling fs shouldn't have any overhead for database load, because database files should be preallocated and the database should do direct IO in/out the preallocated buffers with the FS never doing any metadata writes, except for occassional inode updates for mtime depending on what sync mode that DB uses (hmm, I guess a nomtime or verylazymtime or alwaysasyncmtime mount option could be helpful for that)

That's the theory, but doesn't seem to be the case in your test. I guess your test is not very realistic then.

Matthew replied, "Or your assumptions about DB vs filesystems are not valid in this case." He went on, "Postgres doesn't pre-allocate datafiles. They reckon it's not their job to implement a filesystem, and I'm inclined to agree. They do prefer fdatasync on datafiles and (I think) O_DATASYNC for their journal files where available, but I haven't checked that my build is doing that." Andreas Dilger replied, "If the I/O is normally sync driven, you should consider testing ext3 with "data=journal". While this seems counterintuitive because it is writing the data to disk twice, it can often be faster in real-world "bursty" environments because the sync I/O goes to the journal in one contiguous write, and it can then be written to the rest of the fs asynchronously safely. You can also set up an external journal device so that the journal is on another disk and avoid seeking between the journal and the rest of the filesystem." This made sense to Matthew, and the thread ended.

we have a computer here, that behaves very strange, from one second to another the clock changes to about 1h in the future. In the next "real" second the time is normal again.

Well, I first thought that is might be a X problem, but after running a loop over "date", it really seems that the system clock is affected. Then I thought it might be a conflict with the hardware clock, but after resetting it to the system time, the problem was still there.

The only clock that doesn't seem to be affected is the realtime clock (at least not when doing a loop of cat over the proc-file).

The problem is, that this time jumps cause the Xserver to enable its screensaver (and several other small problems).

System is: Athlon 650 on VIA board with linux-2.4.17 (unpatched)

Adam Johansson confirmed, "The same thing happened to me on an Athlon 600 on a KM133 chipset. I ran a vanilla 2.4.18 and after upgrading to 2.4.19 the problem never occured again." But Jim MacBaine added, "I have expirienced those strange screensaver activations with 2.4.19-pre2-ac4 as well."

There is a hardware bug on some via 686a systems where the RTC appears automagically change it's programmed value.

A patch was originally made against 2.4.2, and some version of this appears to be applied to current kernels (I don't have a vanilla 2.4.17 to check against). Look in arch/i386/kernel/time.c for mention of 686a.

It appears to only be used if the kernel's not compiled with CONFIG_X86_TSC though, so if you have that defined you may not see the problem at all...

Berend De Schouwer reported that in 2.4.18, "When booting kernel 2.4.18, before /sbin/init is run, the text console becomes corrupted and unreadable. Vertical lines appear on the screen in a multitude of colours. The X server will still start, and run as normal. You can login over ssh." He posted a patch, and Steven Walter replied, "Aha, another. You're the fourth or fifth person with this problem. I have a patch very similar to yours. What my patch does is only clear bit 7, which is what was experimentally determined to disable the Write Memory Queue. So far it seems that only KM133 (KT133 w/onboard S3 Savage) are afflicted." But he added, "However, the patch isn't being accepted until an explanation from VIA is obtained (apparently the head kernel honcho's were explicitly told to clear bit 5). I'm working on that now." Berend replied, "I've been told the same. Clearing bit 5 is apparently necessary to prevent IDE crruption. Asus lists two motherboards, one with a KL133, one with a KL133A. It looks like the motherboards using KL133s are broken, and the KL133As work."

This patch will allow a process or thread to changes it's priority dynamically based on it's capabilities. In our case we wanted to use threads with Linux. To have true priorities we need root to use SCHED_FIFO or SCHED_RR; in many case root access is not allowed but we still wanted priorities. So we started using setpriority to change a threads priority. Now we used nice values from 19 to 0 which did not require root access. In some cases a thread need to raise it's nice level and this would fail. I also saw a note man renice(8) that said this bug exists.

So the following patch address this problem. It allows any process or thread to raise or lower it's nice value for it's current capability. For example a CAP_SYS_NICE process can use 19 to -20 for it's value and a normal user can use 19 to 0. By capping normal user to zero then we don't have any problems with conflicts with higher priority programs in the system since zero is the default value.

Chris Wright replied, "hmm, SUS v3 seems to disagree. "Only a process with appropriate privileges can lower its nice value."" There was some discussion, and at one point Stephen said, "All this is really just pigeon dancing around the fact that Linux doesn't implement the PTHREAD_SCOPE_PROCESS which is all I want . I t would make Linux match Solaris and BSD model for POSIX threads. I guess it wouldn't be POSIX if everyone implemented it the same set of supported features. That's why I resorted to changing the nice value in hopes of have some say in how things get scheduled without all the superuser / capabilities hacks." But he said he'd go back and try to find a better solution. Bill Davidsen replied:

I just did a "man 3 pthreads" and that capability is listed as available... If you can boil it down to a small test program as I did, I'll run it on Linux and Solaris and see what I see.

Of course Linux doesn't implement anything here, you choose the implementation by pthreads lib and includes, the old MIT user-level one, the so-called "Linux threads" model, or the current NGPT model in current kernels and the library from IBM.

The latter work, at least for some definitions of "work," but I know there are some differences.

I don't see why starting two threads at different priorities when the program does init is enough overhead to notice, but I don't have your program so you may need something inobvious.

Eric Hokanson reported errors when trying to compile 2.2.21-rc2 using gcc 2.96. Alan Cox replied, "Please don't use gcc 2.96/gcc 3.0/3.1 snapshots to build 2.2 kernels. The kernel tree contains some assumptions that dont work with the newer compilers." End of thread.

This catches up with the bits and pieces that have happened in 2.4 over the last few weeks, scoops up this weeks Linux-kernel bits, and throws in various compile fixes so it hopefully all works out. Particularly of note in this one are Andre's ide fixes, feedback appreciated from anyone seeing problems in 2.5 mainline.

In other news, work has begun splitting this monster diff into lots of Bitkeeper trees. Hopefully when Linus gets back, resyncing is going to be a lot easier than it used to be.

As usual,.. Patch against 2.5.7 vanilla is available from: ftp://ftp.kernel.org/pub/linux/kernel/people/davej/patches/2.5/

Merged patch archive: http://www.codemonkey.org.uk/patches/merged/

Check http://www.codemonkey.org.uk/Linux-2.5.html before reporting known bugs that are also in mainline.

2.5.7-dj2

Merge bits of 2.4.19pre3 & pre4. Dropped quite a bit, 2.5 is really starting to diverge in quite a few areas.
Numerous compile fixups. (Me)
Various config.help updates. (Steven Cole, ESR)
AFFS compile fix. (Jarno Paananen)
Update bttv to use new v4l API. (Jarno Paananen)
Removal extraneous BUG() from accounting code. (Bob Miller)
Fix up JFS txnmgr race. (Christoph Hellwig)
Update documentation index. (Rolf Eike Beer)
Use seq_file for /proc/partitions. (Randy Dunlap)
Fix initrd kdev_same thinko. (Al Viro)
Minor sg update. (Doug Gilbert)
install .config with 'make install' (Kelly French)
Add yet another VAIO to the DMI APM blacklist. (Michael Piotrowski)
Detect get_block errors in block_read_full_page. (Anton Altaparmakov)
Kill off noquot.c (Al Viro)
Special case P4/Xeon bluesmoke init. (Jon Hourd)
Fix up ide-scsi documentation typo. (Bill Jonas)
Increment tcpPassiveOpens counter. (Dave Miller)
Fix up some of Linus' criticisms of SEM_UNDO (Dave Olien)
ibmphp compile fix. (Greg KH)
Fix up two possible panics in microcode driver. (Tigran Aivazian)
fcntl return code POSIX compliance. (Christopher Yeoh)
Lessen debug info from ide-tape. (Alfredo Sanju?n)
Various ide fixes. pdc4030 bent into shape a little by me, please test carefully. (Andre Hedrick)
EasyDisk USB storage support. (Stanislav Karchebny)
Flush cache/TLB on MCE. (Me)
Fix double free in efi partition handling. (Takanori Kawano)
Correct pci_set_mwi documentation typo. (Geert Uytterhoeven)
Fix up race in indydog driver. (Dave Hansen)
3ware driver update. (Adam Radford)
Fix mmap bug with drivers that adjust vm_start. (Benjamin LaHaise)
Register mad16 gameport with input subsystem. (Michael Haardt)
Remove stale comment. (William Lee Irwin III)
P4/Xeon Thermal LVT support for MCE. (Zwane Mwaikambo)
Various fbdev compilation fixes. (James Simmons)
Move touchscreen drivers to their own dir. (James Simmons)
Seperate reiserfs_sb_info from struct super_block (Brian Gerst)

Nathan Walp reported good success with this releaes, but reported compilation errors on the subsequent release, -dj2, in aic7xxx_osm.c; Dave promised to look at it, and Bill Davidsen remarked, "I haven't d/l this version (and I'm generally not even trying 2.5 at the moment), but I would bet the include which defines strtok got zapped or moved." Dave replied, "Indeed, in my tree strtok is dead, replaced with some fairly trivial code that uses strsep. This is one of those cases that fell through the gaps, and is worthy of adding to my 'check diff before uploading' script."

Adam D Scislowicz reported that on his SMP Athlon machines, the first CPUs all reported wrong information in /proc/cpuinfo under 2.4.18-rc4. The model name came back as "AMD Athlon(tm) MP 1800+" and the model ID as "AMD Athlon(tm) Processor". Maarten Ballintijn reported, "The same thing is happening on our Tyan S2460 motherboards, running 2.4.19-pre4-ac2. IIRC it is the BIOS that sets these strings." And Dave Jones also targetted the BIOS, saying that the vendors were not bothering to conform to the specs. He said, "'AMD Athlon(tm) Processor'. is the power-on default. On working out if the CPU is an XP or an MP (by reading the MP bit in cpu capabilities flags) it's supposed to set the name string. Crap BIOSen only do this for the first CPU. It's harmless, but I'll get around to writing a boot time fixup sometime." End of thread.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	15 Mar 2002 - 23 Mar 2002	(30 posts)	Status Of RFC 2385 Under Linux
2.	21 Mar 2002 - 25 Mar 2002	(10 posts)	Maximum Number Of Threads On A System
3.	21 Mar 2002 - 22 Mar 2002	(3 posts)	Maximum Partition Size
4.	22 Mar 2002 - 26 Mar 2002	(22 posts)	SSSCA Discussion
5.	23 Mar 2002	(2 posts)	Status Of ftape In 2.4
6.	24 Mar 2002 - 25 Mar 2002	(9 posts)	New NTFS Driver
7.	26 Mar 2002 - 27 Mar 2002	(6 posts)	Status Of ATM Maintainership
8.	27 Mar 2002 - 28 Mar 2002	(13 posts)	Filesystem Benchmarks
9.	27 Mar 2002	(6 posts)	Erratic System Times In Recent 2.4 Kernels On Some Hardware
10.	27 Mar 2002 - 28 Mar 2002	(4 posts)	2.4.18 Console Corruption On Some Motherboards
11.	27 Mar 2002 - 28 Mar 2002	(7 posts)	Changing Process Priority Via Capabilities
12.	27 Mar 2002	(2 posts)	Using Recent Compilers With 2.2 Kernels
13.	27 Mar 2002 - 28 Mar 2002	(8 posts)	-dj Kernels Forward-Porting 2.4 Code To 2.5; Migrating To BitKeeper
14.	28 Mar 2002	(3 posts)	Some BIOSes Flaky With /proc/cpuinfo Settings

Kernel Traffic #160 For 1 Apr 2002

By Zack Brown