Kernel Traffic #130 For 13 Aug 2001

I'll be out of town for a week, starting next weekend, so Kernel Traffic probably won't come out for the rest of August. Sorry folks. Believe it or not, this will be my first genuine vacation from KT since its inception in January 1999.

There were 534 different contributors. 267 posted more than once. 145 posted last week too.

My genuine digital network interface card ceased to work with the tulip driver contained in kernel revisions >= 2.4.4 and the development driver from sourceforge.net.

It seems that the driver incorrectly configures the card for full duplex mode and I could not figure out how to override this with the new MODULE_PARM macro.

I am now using the stable driver 0.9.14 from sourceforge.net which works fine.

Joshua Schmidlkofer added that he also had problems with the tuplip driver on several SMC NIC's that use the DEC chipset. Jeff Garzik replied, "Currently there are problems with 21041 old chipsets, which include SMC and several other cards. You can use 0.9.14 from http://sf.net/projects/tulip/ until I get around to fixing it." Michal Jaegermann added his own experience, "I reported few times problems with DS21143 Tulip rev 65, which is not exactly old, and with anything above tulip-0.9.14, and did not get back even a half line acknowledment not mentioning annoucements of fixes. I also posted mii-diag output from a card in working and not working state." And Patrick Cole put in, "My 21041 is also not working with late 2.4 series tulip drver. I've heard the de4x5 driver does however work."

Elsewhere, Chris Friesen asked Thomas how the Sourceforge version differed from the on at scyld.com. Jeff explained, "They are totally different, though they have a common origin." And Ben Greear added, "Becker (Scyld) has only recently gotten his drivers to even compile on 2.4 kernel, and they are still beta quality for 2.4, evidently. There seem to be attempts to keep the drivers in sync, functionally, but the architectures have diverged quite a lot..."

Richard Gooch posted a patch to provide kernel support for up to approximately 2144 SCSI disks, and asked for testers. The three scenarios that were handled differently in the code, he explained, were the case of less than 16 SCSI disks, between 17 and 128 SCSI disks, and greater than 128 SCSI disks. He asked for reports on these three cases, and reminded folks to watch out for their data. Evan Felix replied, "I am pleased to see this, I recently expanded the majors number range on my system from 8 majors to 32 by just pushing the secondary range from 65-71 to 65-95, This solution Stomped on other majors, COMPAQ SMART array and IDE6-9, etc. I did not think this was a viable solution to the mainstream kernel so I have only been using it here. I am glad someone with more experience is fixing this one." He added, "I wrote a patch for the Scsi Generic Driver that uses devfs to extend the numbers of genric devices beyond the 256 minor limit. It will use as many major/minor numbers that it can get from devfs for generic scsi drivers. it can be found on the official sg web site at: http://gear.torque.net/sg/ as an experimental driver(sg3120df)." Richard replied, "Yes, Doug talked to me about it at OLS. Unfortunately you've added another search loop in a BH handler. Not your fault, really, since the SCSI midlayer doesn't have a pointer from the SCSI request structure to the upper-level driver instance structure. I urged Doug to send in a patch to Linus that does this." Elsewhere, Eric Youngdale replied to Richard's initial post, "At some point in the 2.5 series I would like to do some serious surgery on the sd datastructures - this will mainly remove load order dependencies and eliminate the need for CONFIG_SD_EXTRA. I believe that some of the work that Jens has already started on the blk device layer will make support for very large numbers of disks much easier."

Nadav Har'El had heard that 2.2 couldn't support SMP on AMD systems, only on Intel. He quoted the old SMP HOWTO as saying, "Intel claims ownership to the APIC SMP scheme, and unless a company licenses it from Intel they may not use it. There are currently no companies that have done so. (This of course can change in the future) FYI - Both Cyrix and AMD support the non- proprietary OpenPIC SMP standard but currently there are no motherboards that use it." Johannes Erdfelt replied that recent 2.2 kernels, as well as all 2.4 kernels, did support SMP on AMD systems. He added that these systems did use Intel's APIC SMP scheme.

Elsewhere, Joel Jaeggli mentioned that a combination of AMD processor and Athlon motherboards would work alright, although 2.4 supported a greater number of hardware configurations. But Alan Cox pointed out, "Athlon SMP will actually not always work with 2.2. Quite a few folks reported problems and patches for 2.2.20pre fixes that and broke other stuff so got reverted. 2.4 seems to do the job nicely." Johannes Erdfelt replied, "I sent you a new patch which fixes the problem." He reposted the patch, and Alan replied, "Looks like I missed that first time around - thanks will apply."

weren't you ever frustrated about the fact that updating your hardware's flash firmware needs proprietary closed source software installed? There's a solution to this problem: a kernel driver for different kinds of (Flash)BIOSs that are available in today's x86 or Alpha AXP hardware.

It's /dev/bios - and the latest version 0.3.1 was released recently.

There are well known BIOSs for

* System BIOS (resides at 0xe0000)
* graphics hardware (e.g. VGA-adapters at 0xc0000)
* SCSI host adapters
* networking interfaces with 'BOOT ROM' * ...

While in former times these BIOSs were implemented by using ROM or EPROM (both can't be updated without opening your computer) today's PC hardware is normally delivered with so called FLASH ROMs. These can simply be updated by software. This driver has the approach to make Linux read and write flash roms.

What's new in 0.3.1?

* compiles and works with Linux kernel 2.4
* rewrote flash chip probing
* always use ioremap now
* flash chips above 128k should work transparent
* Support for newer VIA chipsets

Devbios can be downloaded from http://www.freiburg.linux.de/~stepan/bios/

Please be sure to READ the README ;-) As long as you load the module without special parameters, it's in readonly mode and can't mess up your system, so please don't hesitate to try it out and mail me any test results

Rajeev Bector asked if there were a way to find out a kernel module's name given an address. Keith Owens replied, "Kai Germaschewski sent a patch to l-k a couple of days ago that has the code you need. Search the l-k archives for 'disable module backtraces'." Rajeev couldn't find it in the archives, and Keith gave a link.

The kernel build project is proud to announce the first general release of kernel build for kernel 2.5 (kbuild 2.5). http://sourceforge.net/projects/kbuild/, Package kbuild-2.5, download release 1.

This is a complete redesign and rewrite of the kernel build system. Although it is primarily intended for the 2.5 kernel series, it can be used on 2.4 kernels, in fact it was developed under 2.4. Only a few kbuild 2.4 files are changed by this patch and the changes are such that you can still do a kbuild 2.4 compile, even with the kbuild 2.5 patch installed.

Features of kbuild 2.5. For a fuller description, get the patch and read Documentation/kbuild/kbuild-2.5.txt.

Supports separate source and object directories. You can compile multiple versions of the kernel from a single source tree, using a separate object directory and config for each version. You can even compile different architectures simultaneously from the same source tree.

Supports a common source and object directory. The default mode is the same as kbuild 2.4, to use the same tree for both source and object. Even in this mode, kbuild 2.5 treats almost all the source files as read only, no more time stamp fiddling with .h files. The exceptions are files that are generated at run time and are incorrectly being shipped as part of the kernel tar ball. I will be sending patches to remove these files from the 2.4 tar ball. Obviously you can only compile one kernel at a time in this mode.

Supports multiple source directories. As the development of the kernel has become more distributed, it has become harder for external developers to package their code so it compiles against the correct kernel tree and with the correct options. With multiple source tree support (shadow trees), external code can be treated as if it were part of the base kernel tree. This is useful for developing new drivers, new file systems, testing replacements for existing drivers, overlaying architecture specific patches on the base kernel etc.

One global Makefile for the entire kernel. Instead of make recursively decending through every directory in the source tree, kbuild 2.5 collects the makefile fragments from all directories, verifies them and merges them into a single global makefile. When make is given the whole picture, it can do a much better job. In particular a change to a file or config option now only recompiles and relinks the affected objects, no more spurious compiles.

CML2 support. The patch on sourceforge uses the Configuration Mini Language 1 (CML1) code from kbuild 2.4. You can select either CML1 or CML2 support, but you have to get the current CML2 entries from Eric Raymond's CML2 page, http://www.tuxedo.org/~esr/kbuild/. We expect 2.5 kernels to support only CML2, so test CML2 now, while both versions are available.

A far more robust mini language for the makefile fragments. Instead of setting magic make variables and hoping that Rules.make does what you expect, the Makefile.in files say what you want to do, it is up to kbuild 2.5 to determine how to achieve your requirements.

Quiet mode. By default kbuild 2.5 outputs one line for each compile, link or user defined command. The only other output is warnings and errors which are now far easier to see. Of course, you can still see the full commands if you really care.

Standard support for shipping generated files. kbuild 2.4 has had continual problems with files that are both generated and shipped. This is typically done where the generation process requires utilities that not every user has installed. In kbuild 2.5 this problem has a standard solution which should prevent recurrence of the kbuild 2.4 problems.

Correct parallel running. You can do make -j on all commands and kbuild 2.5 will ensure that commands are run in the correct order.

Multiple targets can be specified on the same make command. You cannot mix clean or mrproper with other targets but everything else can be put on one command.
make -j oldconfig installable && sudo make -j install
works beautifully.

Install targets such as bzImage, zImage, where to install System.map and .config, the install path prefix, which commands to run after install etc. are all CONFIG_ options. Copy .config from one kernel to another, run make install and it all happens, hands free.

Users who require additional processing can dynamically specify additional targets, at any point in the build cycle. This is useful for running distribution specific code without hacking the makefiles.

You can compile individual targets at any level in the tree, which is useful when you are hacking on code. Or you can compile everything in a directory, with or without recursion into sub directories. Unlike kbuild 2.4 make SUBDIRS=, the kbuild 2.5 method will not create inconsistent kernels.

The kernel version number is only incremented when vmlinux is rebuilt, not on every make.

You can rename the source and object directories without having to recompile anything.

It is documented! Read Documentation/kbuild/kbuild-2.5.txt.

TODO:

Add other architectures. Release 1 only supports ix86. IA64 will be next because I have access to a box. After that it will depend on help from the arch support groups.

Patch for -ac kernel (maybe). It only needs to track changes to makefiles in -ac, the core kbuild 2.5 code is the same for -ac kernels.

Help to convert external sources to kbuild 2.5 format. XFS is already converted, it will compile with either kbuild 2.4 or 2.5. http://marc.theaimsgroup.com/?l=linux-xfs&m=99701265316648&w=2

Performance improvements. Some of the code has behaviour O(n**2) in the number of objects being built. For a small compile, kbuild 2.5 is about 10% faster compared to 2.4 make dep + make bzImage. For a full kernel compile, kbuild 2.5 is about twice as slow as kbuild 2.4. I know where the problems are and am working on them. MEC mantra

Correctness comes first.
Then maintainability.
Then speed.

Add module symbol version support. The old genksyms was a nice idea but the implementation has fundamental design problems and has been removed. I will be adding clean module symbol version support later, after kernel 2.5 has started. The correct implementation needs a new version of modutils.

Remove incorrectly shipped files from the kernel tar ball.

Convert relative includes (#include "../..") to remove assumptions about the structure of the kernel tree, this breaks when code is moved around.

Uwe Starke asked if the new version of the AVM FritzCard PCI card was supported in recent kernels. A few folks replied that there was no support; but Kai Germaschewski replied, "I just happened to put a first development snapshot on http://www.tp1.ruhr-uni-bochum.de/~kai/i4l/hisax/."


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

1.	30 Jul 2001 - 1 Aug 2001	(12 posts)	Status Of Tulip Driver
2.	30 Jul 2001 - 2 Aug 2001	(18 posts)	Support For Many SCSI Disks
3.	1 Aug 2001 - 2 Aug 2001	(21 posts)	Status Of SMP On AMD Systems
4.	1 Aug 2001	(1 post)	Support For /dev/bios
5.	2 Aug 2001 - 3 Aug 2001	(5 posts)	Identifying Module Names By Address
6.	7 Aug 2001 - 8 Aug 2001	(12 posts)	New Release Of Kernel Build Tools
7.	9 Aug 2001	(5 posts)	Status Of AVM FritzCard PCI v2.0 Support

Kernel Traffic #130 For 13 Aug 2001

By Zack Brown