Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Kernel Traffic #112 For 23 Mar 2001

By Zack Brown

linux-kernel FAQ | subscribe to linux-kernel | linux-kernel Archives | kernelnotes.org | LxR Kernel Source Browser | All Kernels | Kernel Ports | Kernel Docs | Gary's Encyclopedia: Linux Kernel | #kernelnewbies

Table Of Contents

Mailing List Stats For This Week

We looked at 855 posts in 3580K.

There were 355 different contributors. 150 posted more than once. 130 posted last week too.

The top posters of the week were:

1. Potential Filesystem Corruption With IBM Travelstar 20G Drive

4 Mar 2001 - 12 Mar 2001 (7 posts) Archive Link: "Interesting fs corruption story"

Topics: FS: ReiserFS, FS: ext2

People: Tim WrightEttore PerazzoliAlan Cox

Ettore Perazzoli reported filesystem corruption on his Dell Inspiron 5000. He'd already stumped Alan Cox, who'd suggested posting to linux-kernel, so Ettore did. He explained that when his hard drive had broken recently, he'd installed an IBM Travelstar 20G drive, put Debian on it with a reiserfs root partition, and an ext2 /boot partition. After awhile, he'd started seeing massive metadata corruption. No one, including the reiserfs people, could figure out what had gone wrong, and in the meantime he got a new machine, an IBM Thinkpad T21 (also with a Travelstar 20G drive). He used purely ext2 this time, with Debian again, and once more saw massive metadata corruption. He thought the problem might be with the drive, but he knew of several people using that drive on their ThinkPads, who had experienced no such corruption. So he figured it had to be a kernel bug.

Tim Wright felt a spiritual movement, and said:

I have no idea if this is related to your problem since you didn't mention that key part, but with the same drive, I managed to trash my root partition incredibly badly by trying to use DMA and then do APM suspend or hibernate. On wakeup, I'd get an 'hda: lost interrupt' but then things would appear to carry on.

The fix for me was to rebuild the kernel and make sure CONFIG_APM_ALLOW_INTS was enabled. So, do you ever use power management and is this similar, or do you have a completely different problem ?

Ettore replied in amazement, "Wow, this sounds like this might be the problem. I just checked my `.config' and indeed `CONFIG_APM_ALLOW_INTS' is not enabled. And indeed I have been suspending/resuming the machine a few times before the partition got corrupted." Later, he added that Tim's advice had been a complete fix. He suggested, "Maybe the help message for this kernel option (CONFIG_APM_ALLOW_INTS) should report in big blocky letters that disabling it might cause major data loss with some drive/bios combinations?.. I was not aware that I was touching such a sensitive parameter when I rebuilt the kernel, and the help message didn't warn me in any way." There was no reply.

2. Status Of POSIX ACLs

7 Mar 2001 - 11 Mar 2001 (3 posts) Archive Link: "Status of posix-ACL's"

Topics: Access Control Lists, FS: NFS, FS: ext2, POSIX, Samba

People: Jochen DolzeAlbert D. CahalanBernd Eckenfels

Jochen Dolze asked, "i found at http://acl.bestbits.at the ACL-linux-project. Now i want to know, if there is a plan to integrate posix-ACLs into the fs-part of the kernel, e.g. into the VFS-Layer? Is there a general discussion about this anywhere? What are the biggest problems? (i know that many userland-tools must be changed for this)." Albert D. Cahalan retched into his hand, and said he hoped POSIX ACLs never got into the kernel. He added, "POSIX ACLs are crap. NFSv4 mostly follows NT. Compatibility with NFSv4 and SMB (Samba's protocol) is important." And Bernd Eckenfels added:

AFAIK there is no Support in User Land Programs required. You just have additional tools for managing the ACLs . The main problem with ACLs are the storage of the additional info in the file system. This is a hard job if you want to have it for all/most file systems. Remy had a working Version for ext2, but it never got very public.. dunno why.

NTs ACLs are somewhat messy cause they require too much scanning.

End of thread.

3. Update To Framebuffer Logos

8 Mar 2001 - 11 Mar 2001 (5 posts) Archive Link: "[PATCH] Penguin logos"

Topics: Framebuffer, Version Control

People: Geert UytterhoevenSimon RichterOliver Xymoron

Geert Uytterhoeven posted a patch for the Linux framebuffer logo, and announced:

This patch fixes some issues with the frame buffer device penguin logo code.

Bug list:

Changes:

  1. Update the frame buffer console code to no longer change the palette when displaying the 16 color logo. Remove the tricks to load the logo palette in unused palette entries on displays with >= 32 colors.
  2. Replace the PI 16 color Penguin-with-beer logo by a new one, derived from the 224 color logo.
  3. Remove a superfluous include from drivers/char/console.c. The logo code was moved to drivers/video/fbcon.c a long time ago.
  4. Replace the PI black & white Penguin-with-beer logo by a new one, derived from the PostScript version on Larry Ewing's webpage.
  5. Remove drivers/sgi/char/linux_logo.h (containing a PI 224 color Penguin-with-beer logo) since it's no longer used.
  6. Remove the PI black & white Penguin-with-wine logo used on SPARC and SPARC64. Use the generic logo instead.
  7. Move linux_logo_* prototypes to <linux/linux_logo.h>.
  8. Simplify the logo selection logic in arch-specific <asm-xxx/linux_logo.h>. If you want to have an arch-specific logo, #define ARCH_LINUX_LOGO* and declare your data (if INCLUDE_LINUX_LOGO_DATA is defined).

Changes 1, 2 and 3 are already present in Alan's tree. Change 5 is already present in the Linux/MIPS CVS tree.

Patches (for both 2.4.3-pre3 and 2.4.2-ac14) can be downloaded from:

http://home.tvd.be/cr26864/Linux/fbdev/logo.html

This page also shows the old and new logos, and includes a tool to extract logos in PNM format from the kernel sources (in case you don't trust me :-).

About the politically incorrect logo versions, Simon Richter remarked with a smirk, "Heh. Those are cool. Don't remove them. The Windoze people always look jealous at the beer tux... :-)" Oliver Xymoron offered his criticisms:

There's still some aliasing outlines on a bunch of them and I'm a bit puzzled why there's an SGI logo on the MIPS penguin but not on the SGI penguin.

Ideally, it'd be preferable to have .pnms in the source and a quick prog in tools/ to build the include files as part of the makefile. Source should be editable.

While I'm at it, may I suggest trading the gray background for black with the penguin surrounded by a halo effect? It enhances his already, erm, Buddha-esque appearance, to say nothing of "holy penguin pee".

4. System Lock-ups In 2.4

9 Mar 2001 - 12 Mar 2001 (16 posts) Archive Link: "[patch] serial console vs NMI watchdog"

People: Andrew MortonIon BadulescuIngo MolnarKeith OwensLinus Torvalds

Andrew Morton reported, "SYSRQ-T on serial console can crash the machine. This is because a large amount of output is sent to a slow device while interrupts are disabled. The NMI watchdog triggers." He posted a patch to create a new enable_nmi_watchdog() API patch, which would enable and disable NMI watchdog checking. Ion Badulescu felt that as it stood, the patch would never get past Linus Torvalds. Ion suggested, "Just have two functions, enable_nmi_watchdog and disable_nmi_watchdog. You can make them inline, or even macros..." Andrew agreed, and posted a new patch.

But elsewhere, Ingo Molnar said he felt Andrew's patch was too complex and allowed deadlocks. He suggested instead, "Why not add a "touch_nmi_watchdog_counter()" function that just changes last_irq_sums instead of adding locking? This way deadlocks will be caught in the serial code too. (because touch_nmi() will only "postpone" the NMI watchdog lockup event, not disable it.) This should be a matter of 5 lines ..." But Keith Owens pointed out that the kdb kernel debugger needed to disable the NMI counter, and that there was no alternative because of kdb's basic design. Ingo said, "it sure has an alternative. The 'cpus spinning' code calls touch_nmi() within the busy loop, the polling code on the control CPU too. This is sure more robust and catches lockup bugs in kdb too ..." Keith liked this idea, and pointed out that it would also simplify kdb itself. Ingo agreed, and posted a patch to implement it. Andrew had a few technical objections, which Ingo tried to explain, but the thread petered out inconclusively.

5. Intel Stingy With Docs

9 Mar 2001 - 11 Mar 2001 (9 posts) Archive Link: "[PATCH]: allow notsc option for buggy cpus"

Topics: Power Management: ACPI

People: Anton BlanchardAlan CoxMatti Aarnio

Anton Blanchard reported:

My IBM Thinkpad 600E changes between 100MHz and 400MHz depending if the power is on. This means gettimeofday goes backwards if you boot with the power out (tsc calibrated at 100MHz) and then plug the power in. (tsc is now spinning at 4x speed, so offsets within the HZ timer period are 4x out!).

The answer is to boot with the notsc option, however since the CONFIG_X86_TSC option is enabled for CONFIG_M686, we cannot do this. Saving one indirect function call for do_gettimeofset is not enough of a reason for CONFIG_X86_TSC. Should we trash this option?

Even so, we should really catch these cpus at run time.

Alan Cox replied, "Intel are being remarkably reluctant on the documentation front. We have the AMD speed change docs, but the intel ones (chipset not cpu based primarily) don't seem to be publically available. In fact the 815M manual looks like someone quite pointedly went through and removed the relevant material before publication." Matti Aarnio asked, "Aren't we supposed to use ACPI for this ?" But Alan replied staunchly, "If you want to trust a large in kernel interpreter of binary only interpreter code from a BIOS vendor be my guest. Im also not sure ACPI will give us the notifications we need, even in the cases where it actually works."

6. Overclocked-CPU Detection Code Removed From Alan's 2.4 Tree

10 Mar 2001 - 12 Mar 2001 (5 posts) Archive Link: "Linux 2.4.2ac18"

Topics: Kernel Release Announcement

People: Alan CoxHolger Lubitz

Alan Cox announced 2.4.2ac18, and Holger Lubitz asked why the overclocked-CPU detection code had been dropped between 2.4.2ac16 and 2.4.2ac17; Alan explained, "It doesnt work usefully. The bit we really needed (clock multiplier reading) does work so its a case of one won lost one." Holger objected, "But this won't catch FSB overclocking at all (which nowadays seems the most common way of oc-ing, since it does not involve any modifications to the CPU other than maybe a better cooler). Or am I missing something?" Alan explained that the overclocking code had just been an experimental sideline of the clock multiplier reading.

7. Config Variable Reorganization

11 Mar 2001 - 14 Mar 2001 (10 posts) Archive Link: "Rename all derived CONFIG variables"

Topics: Kernel Build System

People: Keith OwensAlan CoxEric S. RaymondHugh DickinsPhilipp RumpfOliver XymoronPeter SamuelsonJeff Garzik

Keith Owens proposed, "In 2.4.2-ac18 there are 130 CONFIG options that are always derived from other options, the user has no control over them. It is useful for the kernel build process to know which variables are derived and which variables the user can control. There are also 6 CONFIG options that are not used anywhere." He posted a link to an immense patch to remove the unused options and rename derived options from the form "CONFIG_configname" to "CONFIG_configname_DERIVED". His proposal was not met with universal praise, however. Jeff Garzik felt that lengthening the names was needless, and in any case didn't belong in the stable kernel series. He added that he hoped vendors would not start applying Keith's patch. And Alan Cox put in, "I dont see them doing that. I'm not going to be applying it for -ac either. It would appear that this is a wrong way to fix the problem."

Philipp Rumpf also saw no need for derived options to have their own namespace, especially considering that they might become non-derived in the future. And Hugh Dickins felt that the configuration process itself should be responsible for determining whether an option was derived from other options or not. Given the speed at which the kernel could change, he felt Keith's namespace solution would necessitate a lot of needless editing of sources.

There was no reply to either Philipp's or Hugh's criticisms, but elsewhere, Peter Samuelson supported Keith's initial proposal. Peter said that he'd thought of doing something similar to Keith's idea, but had never gotten around to actually writing the patch. He agreed that derived options should have their own namespace, but felt that adding "_DERIVED" at the end of each of them would be too much typing. He preferred simply using two underscores in the name, i.e. "CONFIG__configname", as being simpler to type, clear, and not intrusive. Eric S. Raymond replied:

How much point is there to this kind of cleanup in CML1, really?

After the fall LinuxWorld meeting I was under the impression that mec and the rest of the build team were planning to support switching to CML2 for the 2.5 series. If that's not true, someone should clue me in *now*, before I go misrepresenting anybody's position at the 2.5 kickoff workshop.

But if we're going to push Linus and the kernel crew to switch to CML2, then why invite the political tsuris of trying to get a large patch into 2.4 now? Maybe I'm missing something here, but this doesn't seem necessary to me.

Keith replied, "The derived config variables should be in a separate name space, whether config is CML1 or CML2. This patch does it for CML1." This made no sense to Alan or Oliver Xymoron. Oliver reiterated the idea that this kind of change belonged in the configuration scripts, not in the code itself, and would end up causing needless maintenance headaches. He suggested that whatever script Keith had developed to find the dependencies in the first place, would be a good starting point as something to include instead of the changes he'd proposed. Alan agreed tersely, and there was no more discussion.

8. IDE Hot-Swapping

12 Mar 2001 (3 posts) Archive Link: "Ide Hot-swaping?"

Topics: Disks: IDE

People: Jeremy JacksonAndre HedrickPozsar Balazs

Pozsar Balazs asked if it were possible to hot-swap IDE drives. Jeremy Jackson replied, "read a recent man page for hdparm and you will see kernel allows remove/add ide interface. scripts with correct parameter usage are in contrib directory of hdparm source. IDE maintainer has code to electrically turn off (tristate) ide channels on most PC ide chips, but is waiting to demonstrate at an industry conference before releasing to public." And Andre Hedrick replied to Pozsar simply, "I have not made public that code until more clean ups."

9. Documentation On Kernel Symbols And Modversions

13 Mar 2001 (1 post) Archive Link: "short doc on kernel symbols and modversions"

People: Mark McLoughlin

Mark McLoughlin announced:

after quite a bit of pain in the past figuring out how this all works and some questions on the kernelnewbies list recently I decided to do my best to document it.

http://www.skynet.ie/~mark/home/kernel/symbols.html

any comments are welcome..

There was no reply.

10. Workaround For Netfinity Lockups

13 Mar 2001 - 14 Mar 2001 (4 posts) Archive Link: "2.4.x: Netfinity 4500 SMP freezes without any trace"

Topics: SMP

People: Tim Wright

Hartmut Holz reported that Netfinity 4500 SMP would lock up after about a day of sitting idle under 2.4; while under 2.2 it worked fine. Tim Wright replied, "Reboot with 'nmi_watchdog=0'. That will "fix" it for now. Still chasing this. I'll announce when I find out root cause." Hartmut replied with complete success. Tim had nothing new to report from his hunting expedition, and the thread ended.

11. 2.4 Not Backward Compatible With 2.2

13 Mar 2001 - 15 Mar 2001 (7 posts) Archive Link: "poll() behaves differently in Linux 2.4.1 vs. Linux 2.2.14 (POLLHUP)"

Topics: BSD, Backward Compatibility, Networking, Random Number Generation

People: Jeffrey ButlerDavid S. MillerHenning P. SchmiedehausenJeffrew ButlerAlexey Kuznetsov

Jeffrey Butler remarked, "I've noticed that poll() calls on IPv4 sockets do not behave the same under linux 2.4 vs. linux 2.2.14. Linux 2.4 will return POLLHUP for a socket that is not connected (and has never been connected) while Linux 2.2 will not." He posted a test program that behaved differently on 2.2 and 2.4 due to this change, and asked what the reasoning was behind that decision.

David S. Miller replied shortly, "True, this behavior was changed from 2.2.x. We now match the behavior of other svr4 systems, in particular Solaris. This new behavior in 2.4.x will not change."

This confused Henning P. Schmiedehausen, who pointed out that BSD, SysVR4 and other systems all had the 2.2 behavior. He added, "I'd prefer not to have too many user space surprises in moving from 2.2 to 2.4." There was no reply to this, but Jeffrey also expressed his confusion, asking, "What version of Solaris should the poll() call behave like? I tried the test program that I posted in the original post on this thread on a couple of versions of Solaris, and they all behaved like Linux 2.2, not Linux 2.4." There was no reply to this, but elsewhere, Alexey Kuznetsov said:

Damn, we did not test behaviour on absolutely new clean never connected socket... Solaris really may return 0 on it.

However, looking from other hand the issue looks as absolutely academic and not related to practice in any way.

Jeffrey replied that the issue was not academic to him, since he had to to support a particular application on several platforms, and wanted to minimize the complexity and number of special cases involved in doing that. Alexey poured water on the whole idea, saying, "genarally we are not going to match any os and even yourselves yesterday or tomorrow in the cases when behaviour is truly undefined and the answer is meaningless. For me any solution from retunring 0 or returning POLLHUO to killing offending application or generating an answer using random number generator look equally good, acceptable and 100% compatible in this case. 8)"

End Of Thread.

12. "Doctor, It Hurts When I Do This..."

14 Mar 2001 - 16 Mar 2001 (8 posts) Archive Link: "IDE poweroff -> hangup"

People: Andre HedrickPozsar Balazs

Out of curiosity, Pozsar Balazs experimented with pulling the power plug out of the back of his hard drive during normal system operation, then plugging it in again a few seconds later. To his surprise, the machine gave a few errors and then locked up tight. Andre Hedrick exhaled slowly, and replied, "what do you think you are doing? Since you have not issued a power down command nor deregisterd the device, because I have not publish hotswap-ata yet....thus you can not do this in a pretty way" [...] "You are lucky that you have not burned the mainboard. The open-collector pull on the channel will destroy the buffers on the device. By pulling the power you can not hold the state of the latches derived from the power-ground lines." He added, "Just be glad that the kernel will crash and not eat your data."

13. Finding -pre Releases

18 Mar 2001 (4 posts) Archive Link: "Where to find -pre releases?"

People: Jeff GarzikRichard Gooch

George R. Kasica asked where to find the latest -pre releases. He'd tried Freshmeat without any luck. Several folks gave the link, and Jeff Garzik put it:

ftp://ftp.??.kernel.org/pub/linux/kernel/testing/

?? == country code: us, de, dk, uk, ...

Maybe I'm blind, but I didn't find an answer to this in the FAQ at http://www.tux.org/lkml/ Richard Gooch, FAQ maintainer, is CC'd.

By KT press-time, Richard had added this information to Section 1, Question 11.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.