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:

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.

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:

End of thread.

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

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:

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.

Anton Blanchard reported:

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.

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.

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:

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.

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.

Mark McLoughlin announced:

There was no reply.

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.

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:

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.

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.

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:

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