Re: iSCSI target stops sending responses to login requests
Evgenii Lepikhin wrote: Hello, We have several NAS servers with kernels 3.4.xx-3.13.xx. We've got a problem: after 1..4 months of work target servers stops responding to login requests. I have seen a very similar problem on file servers, in my case an NFS workgroup server. I thought it was due to down level 3.8.13-fc17 kernel, not scheduled for upgrade for a few months yet, probably over Labor Day weekend. However, existing connections on the machine also will respond to ENTER with a newline, but any connand requiring a new process hangs. It behaves as if the machine was out of processes, but I traced processes every few minutes and saw no buildup. In addition, the machine hosts a virtual machine which continues to work just fine. Does any of this match additional issues you didn't mention or haven't checked? [__ snip __] Any ideas? May or may not be related, we have a console open on the machine and can verify the odd behavior. -- Bill Davidsen "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: early intel microcode update violating alignment rules
Borislav Petkov wrote: On Mon, Aug 11, 2014 at 10:16:13AM -0300, Henrique de Moraes Holschuh wrote: On Mon, 11 Aug 2014, Borislav Petkov wrote: On Sat, Aug 09, 2014 at 08:19:11PM -0300, Henrique de Moraes Holschuh wrote: Is there a way to fix this in the kernel for the BSP? I think you're looking at this the wrong way around. :-) The thing that needs fixing is the SDM since some CPUs seem to accept 16-byte unaligned microcode just fine. I often wonder how much of the Intel SDM is really a fairy tale... it certainly has enough legends from times long past inside ;-) But just like old stories, should you forget all about them, they sometimes grow fangs back and get you when you're least prepared. Now, seriously, we're neither aligning the thing, nor checking any of it for alignment, so userspace can mess with us at will. Unless it is trying to be actively malicious, we'll get 4-byte alignment out of userspace for the data inside the early initramfs (assuming the use of the common cpio tools: GNU cpio and GNU pax), but that's it. I can easily propose fixes to reject incorrectly aligned data (and will do so), but you *really* don't want to know the kind of crap I came up with to try to align the microcode update for the BSP: Standard Lovecraftian Mythos Safety Procedures apply! So I am turning to you for ideas... It seems to me you're looking for issues where there are none. We simply have to ask Intel people what's with the 16-byte alignment and fix the SDM, apparently. If the processor accepts the non-16-byte-aligned update, why do you care? Because if the requirement is enforced in some future revision, and updates then fail in some insane way, the vendor is justified in claiming "I told you so." Don't suppose you have anything in memory right after the microcode which you could put on the stack (15 bytes) slide the image up into alignment, load it, and put everything back. Haven't looked at the code or data, just tossing out an idea I used for something else back when. -- Bill Davidsen "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RAID extremely slow
Kevin Ross wrote:
On 07/27/2012 09:45 PM, Grant Coady wrote:
On Fri, 27 Jul 2012 14:45:18 -0700, you wrote:
On 07/27/2012 12:08 PM, Bill Davidsen wrote:
Have you set the io scheduler to deadline on all members of the array?
That's kind of "job one" on older kernels.
I have not, thanks for the tip, I'll look into that now.
Plus I disable the on-drive queuing (NCQ) during startup, right now
I don't have benchmarks to show the difference. This on a six by 1TB
drive RAID6 array I built over a year ago on Slackware64-13.37:
# cat /etc/rc.d/rc.local
...
# turn off NCQ on the RAID drives by adjusting queue depth to 1
n=1
echo "rc.local: Disable RAID drives' NCQ"
for d in a b c d e f
do
echo " set NCQ depth to $n on sd${d}"
echo $n> /sys/block/sd${d}/device/queue_depth
done
...
Maybe you could try that? See if it makes a difference. My drives
are Seagate.
Grant.
Does disabling NCQ improve performance?
Does for me!
The suggestion to use kernel 3.4.6 has been working quite well so far,
hopefully that fixes the problem. I'll know for sure in a few more days...
Thanks!
-- Kevin
--
Bill Davidsen
We are not out of the woods yet, but we know the direction and have
taken the first step. The steps are many, but finite in number, and if
we persevere we will reach our destination. -me, 2010
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RAID extremely slow
Kevin Ross wrote: unused devices: # cat /proc/sys/dev/raid/speed_limit_min 1 MD is unable to reach its minimum rebuild rate while other system activity is ongoing. You might want to lower this number to see if that gets you out of the stalls. Or temporarily shut down mythtv. I will try lowering those numbers next time this happens, which will probably be within the next day or two. That's about how often this happens. Unfortunately, it has happened again, with speeds at near zero. # cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid6 sdh1[0] sdd1[9] sde1[10] sdb1[6] sdi1[7] sdc1[4] sdf1[3] sdg1[8] sdj1[1] 6837311488 blocks super 1.2 level 6, 512k chunk, algorithm 2 [9/9] [U] [=>...] resync = 8.3% (81251712/976758784) finish=1057826.4min speed=14K/sec unused devices: atop doesn't show ANY activity on the raid device or the individual drives. http://img687.imageshack.us/img687/2913/screenshotfrom201207252.png Also, I tried writing to a test file with the following command, and it hangs. I let it go for about 30 minutes, with no change. # dd if=/dev/zero of=test bs=1M count=1 dmesg only reports hung tasks. It doesn't report any other problems. Here's my dmesg output: http://pastebin.ca/2174778 I'm going to try rebooting into single user mode, and see if the rebuild succeeds without stalling. Have you set the io scheduler to deadline on all members of the array? That's kind of "job one" on older kernels. -- Bill Davidsen "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Driver removals
[EMAIL PROTECTED] wrote: On Fri, 15 Feb 2008 20:08:13 EST, Bill Davidsen said: can never make you see why technological extortion is evil. People have always moved to new drivers without pushing because they were *better*, guess that model is dead. And the drivers get better because the Code Fairy comes and sprinkles magic bugfix dust all over them? And the Code Fairy knows where to sprinkle bugfix dust because it can see where the Bugreport Fairy sprinkled Bugreport Dust? Drivers get better because someone who finds a benefit in them also finds a problem. They don't get better by developers looking for intermittent, probably load dependent, bugs which effect eight year old server hardware which was a low volume item, the developers are unlikely to have, and which is in use providing services, not on someone's desktop where it can reasonably be rebooted to test patches. Yes, people will move without pushing when the drivers are better. However, remember that a major cultural motivation for the GPL is the concept of "give back". And if a user can't be bothered to even give back enough to say "wow, this blows, my Frobnozz9800 doesn't work with this driver", that's a problem with the user. They're getting it for free, they should at least give the developers the kindness of a bug report if something is broken... Not when drivers are "better" but when a new driver offers some benefit, be it reliability, capability, etc. When the new driver offers not a single benefit and the only "feature" is "possible unknown bugs," people are not going to change, and I don't think forcing people off working drivers is any more ethical than Microsoft killing XP to force people to VISTA. Less ethical, actually, because MSFT is looking for profit, and they make no pretense of caring about the users in any role but revenue stream. Insert it right next to the diatribe about developers who think that because some new feature was a lot of work that Linus *must* put it in the kernel, or users show show proper respect and gratitude and disrupt their production hardware to test and debug some new code which offers zero added functionality on that hardware. If you think downtime is "free" then you have not been working in the right environments, or for the right management. -- Bill Davidsen <[EMAIL PROTECTED]> "Woe unto the statesman who makes war without a reason that will still be valid when the war is over..." Otto von Bismark -- 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: Driver removals
Adrian Bunk wrote: On Fri, Feb 15, 2008 at 02:07:41PM -0500, Bill Davidsen wrote: Adrian Bunk wrote: On Wed, Feb 13, 2008 at 09:26:26PM -0500, Bill Davidsen wrote: ... In general, if a driver works and is being used, until it *needs* attention I see no reason to replace it. I don't agree that "it forces people to try the new driver" is a valid reason, being unmaintained is only a problem if it needs maintenance. I am not going to reopen that topic, I'm simply noting a general opposition to unfunded mandates, and requiring changes to kernel, module and/or rc.local config is just that. Keeping a working unmaintained driver in the tree is not a big deal - we have hundreds of them. But you miss the main point that removal of an obsolete driver with a new replacement driver forces people to finally report their problems with the new driver, thus making the new driver better. You sure are proud of that new driver! People won't use it because the old one is working fine, so you think it's fine to force them to make changes in their system to use the new driver. Sometimes what is best in the global picture is not what everyone subjectively considers to be the best thing for him. Well, our whole society is based on this principle... Best case is it works after costing the user some time, worst case it doesn't and breaks their system, so they stop upgrading the kernel and don't get security fixes. ... Instead of sending a bug report? To get the system working. When removing an obsolete driver adult people suddenly start whining "the new driver didn't work for me when I tried it one year ago". And when asking where they reported the bug in the new driver the answer is that they didn't report it. Driver development heavily relies on getting bug reports when something doesn't work. If you don't see an ethical problem in removing a working driver which is not taking support resources, in order to force people to test and debug a driver they don't now and never would need, so that it might in time offer them the same functionality those users already had... then I can never make you see why technological extortion is evil. People have always moved to new drivers without pushing because they were *better*, guess that model is dead. -- Bill Davidsen <[EMAIL PROTECTED]> "Woe unto the statesman who makes war without a reason that will still be valid when the war is over..." Otto von Bismark -- 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: Is there a "blackhole" /dev/null directory?
Jan Engelhardt wrote: On Feb 14 2008 10:46, Andi Kleen wrote: Jasper Bryant-Greene <[EMAIL PROTECTED]> writes: This could be done fairly trivially with FUSE, and IMHO is a good use for FUSE because since you're just throwing most data away, performance is not a concern. There is a much more interesting 'problem' with a "/dev/null directory". Q: Why would you need such a directory? A: To temporarily fool a program into believing it wrote something. Also: to let a program believe it was creating files which are used to hold the written data. Otherwise /dev/null would probably be the solution. Q: Should all files disappear? (e.g. "unlink after open") A: Maybe not, programs may stat() the file right afterwards and get confused by the "inexistence". I think what is going to happen is that files created behave as if they are the result of a mknod resulting in a /dev/null clone. Q: What if a program attempts to mkdir /dev/nullmnt/foo to just create a file /dev/nullmnt/foo/barfile? A: /dev/nullmnt/foo must continue to exist or be accepted for a while, or perhaps for eternity. The directory structure can persist, it's the writing of data which can be avoided. Real example: A program which reads log files and prepares a whole raft of reports in a directory specified. If you just want to see the summary (stdout) and exception notices (stderr) having a nulldir would avoid the disk space and i/o load if you were just looking at the critical output rather than the analysis. Yes, if this was an original program requirement it would or should have been a feature. Real world cases sometimes use tools in creative ways. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Driver removals
Adrian Bunk wrote: On Wed, Feb 13, 2008 at 09:26:26PM -0500, Bill Davidsen wrote: ... In general, if a driver works and is being used, until it *needs* attention I see no reason to replace it. I don't agree that "it forces people to try the new driver" is a valid reason, being unmaintained is only a problem if it needs maintenance. I am not going to reopen that topic, I'm simply noting a general opposition to unfunded mandates, and requiring changes to kernel, module and/or rc.local config is just that. Keeping a working unmaintained driver in the tree is not a big deal - we have hundreds of them. But you miss the main point that removal of an obsolete driver with a new replacement driver forces people to finally report their problems with the new driver, thus making the new driver better. You sure are proud of that new driver! People won't use it because the old one is working fine, so you think it's fine to force them to make changes in their system to use the new driver. Best case is it works after costing the user some time, worst case it doesn't and breaks their system, so they stop upgrading the kernel and don't get security fixes. After all, the people who scream loudly that the new driver doesn't work for them when the old driver gets removed are the people who should have reported their problems with the new driver many years ago... Is it not obvious that the problem lies with the "when the old driver gets removed" part, there is absolutely no effort needed to keep an old driver, and if it's left in until some change requires rewriting every module in the kernel, it's likely that either the old hardware or the user will die before that ever happens again. There is no benefit to users, if the old driver didn't work they would have switched, there's no saving in support effort because, as you pointed out, there are "hundreds of them" now. This reminds me of Microsoft and XP vs. VISTA. MSFT is stopping sales and support of XP to "force people to upgrade" to VISTA. You want to "force people to upgrade" to newer drivers. The difference is that MSFT at least has money as a reason, as far as I can tell the reason you want to force people to use new drivers is because people put all the effort into writing the new drivers and now most of us want to use the old one if it works. We don't want to change configuration and hope something else new works, because we know the old driver works for us and we want to use our system instead of helping test the new driver. I appreciate the effort it took to write new drivers, I believe most users able to build their own kernels do. I use new drivers on new systems because install picks them and a new system has to go through shakedown in any case. I just wish that *you* could appreciate that a driver change requires user effort and chance to find bugs in a new driver, for each and every system, many of which are at EOL now. I wish you valued the user's time as much as users value developer time. *EOL - end-of-life, if your organization doesn't use the term. the "it's paid for, use it but don't spend money on it" phase of ownership. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Feature Removals for 2.6.25
Stephen Hemminger wrote: Ping? What: sk98lin network driver When: Feburary 2008 Why:In kernel tree version of driver is unmaintained. Sk98lin driver replaced by the skge driver. Who:Stephen Hemminger <[EMAIL PROTECTED]> --- We have been over this several times, and I thought someone had taken over the driver and was providing patches to put it in. Both skge and sky2 have been proposed as the replacement, people have reported problems with each. Suggest leaving this alone until the sk98lin actually needs work, then take it out. Problems in my problem system have been intermittent, take 4-40 hours to show and generate no errors, other than the driver thinks it's sending packets and the sniffer doesn't. The vendor sk98lin driver will continue it's happy life out of tree. The version in 2.6.25 is ancient and unmaintained and only supports older hardware. There are no outstanding issues with skge driver (sky2 is prone to hardware problems, but then so is vendor driver). And those of us who are using it *have* old hardware. Old hardware that perhaps the people forcing other driver on us don't have. Unfortunately, removing sk98lin seems to be the only way to make die hard users report problems. The last time we removed it, some user's of old Genesis boards showed with issues, but those are now fixed. I guess I have a real problem with the "make die hard users report problems" thing, because it assumes that there is nothing wrong with *causing* us problems. Understand, this is not "change is bad" but "change is expensive." Because it means a change in kernel config, modules.conf, and possibly rc.local or initrd or similar. A per-machine effort which is small in ones, and large in sum. Jeff has scheduled sk98lin for removal in 2.6.26. (and it will probably be gone from -mm before that). If this were a case of the sk98lin driver needing work, I wouldn't be making the argument. But to make work for users in a case where there is no saving in effort for developers, sounds as if the developers place no value at all on the time of the people who build their own kernels, and if the vendors are good with it, that's all that matters. Note that because the hardware is old, it's highly likely that most of it will be retired before that sk98lin driver needs a change. I can't see anyone using sk98lin on a new system, so it would be less contentious to let the hardware (or users) die of natural causes if you can. -- Bill Davidsen <[EMAIL PROTECTED]> "Woe unto the statesman who makes war without a reason that will still be valid when the war is over..." Otto von Bismark -- 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: "ide=reverse" do we still need this?
Greg KH wrote: On Wed, Feb 13, 2008 at 02:41:07AM +0100, Rene Herman wrote: On 13-02-08 01:15, Greg KH wrote: I'm reworking the pci device list logic (we currently keep all PCI devices in 2 lists, which isn't the nicest, we should be able to get away with only 1 list.) The only bother I've found so far is the pci_get_device_reverse() function, it's used in 2 places, IDE and the calgary driver. I'm curious if we really still support the ide=reverse option? It's a config option that I don't think the distros still enable (SuSE does not). Is this still needed these days? In digging, we changed this option in 2.2.x from being called "pci=reverse" and no one else seems to miss it. Any thoughts? While details escape me somewhat again at the monment, a few months ago I was playing around with a PCI Promise IDE controller and needed ide=reverse to save me from having to switch disks around to still have a bootable system. Or some such. Not too clear anymore, but I remember it saved the day. You couldn't just change the boot disk in grub? Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable? There are any number of things you can do when the system is booted, but the only thing you can do when the system won't boot is use kernel boot options. This is primarily useful for old systems running modern software, such as old PC redeployed to network, external device control, or system monitoring. Upgrading the BIOS is no longer going to happen, and upgrading the hardware isn't cost effective, but keeping old systems out of the landfill is ecologically and financially sound. The option is a holdover from the past, but so arm some of my clients and their hardware. ;-) And *my* hardware, I might add, I am as cheap as anyone. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: reading user. extended attributes from symlinks in 2.6 kernels
Rok Ruzic wrote: Hello, I have an XFS filesystem containing files and symlinks with application-specific EAs in the user namespace. The files, symlinks and their EAs were created while running a 2.4 kernel. In 2.6 kernels access to user EAs was prevented for symlinks. My problem is that i have to upgrade the kernel from 2.4 to 2.6 series and i have to have access to all the EAs after upgrade. Is there a way to read user EAs off of symlinks on an XFS filesystem on a 2.6 kernel either from userspace or from a filter driver sitting between VFS and XFS filesystem code? I would appreciate it very much if somebody could point me towards a solution. If you want to do it at user code level, you could note the symlink, follow it to the "real" name, and read the EA there. I don't see any easy way to force the kernel to follow the symlink. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: [BUG] Problem with recording on hda-intel (sata_sil or hda-intel bug) - HP nx6325
Grzegorz Chwesewicz wrote: Hi. Problem description: I have a problem with recording on HP nx6325 notebook (hda-intel with AD1981HD codec). Playback works fine, but after 5-10 min. of recording microphone stops working (playback works all the time). Unloading and loading sound modules fixes problem, but only for another 5-10 minutes. This problem exists from more than a year (at least from 2.6.17.13 kernel). In [1] we came to conclusion that this problem is ralated to IRQ sharing [2] (HDA Intel is on the same IRQ as sata_sil). How to reproduce the problem: 1) on one console run arecord and see the output (You should see some garbage) 2) on another console run cat /etc/* 3) at once arecord on the first console gives no output So, doing lot of hdd I/O occurs problem with mic. I had problems a few years ago with USB stopping when the screen saver kicked in, just a wild thought. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: [rft] s2ram wakeup moves to .c, could fix few machines
H. Peter Anvin wrote: Rafael J. Wysocki wrote: The asm() for making beeps really need to be moved to a function and cleaned up (redone in C using inb()/outb()) if they are to be retained at all. Yes, they are. For some people they're the only tool to debug broken resume. That's fine, but they should get cleaned up. /me is tempted to provide a version which can send messages in Morse Code ;) Thought someone did that a while ago. Alan Cox, maybe. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Feature Removals for 2.6.25
Harvey Harrison wrote: What: CONFIG_FORCED_INLINING When: June 2006 Why:Config option is there to see if gcc is good enough. (in january 2006). If it is, the behavior should just be the default. If it's not, the option should just go away entirely. Who:Arjan van de Ven Patch submitted to Arjan, maybe 2.6.25? --- The "good enough" of gcc may be architecture dependent. Taking the option away where it works because somewhere else it doesn't may not be the optimal solution. Ping? What: eepro100 network driver When: January 2007 Why:replaced by the e100 driver Who:Adrian Bunk <[EMAIL PROTECTED]> --- The last time we discussed this the team working on e100 said there were still issues (IIRC). Have they all been resolved? Ping? What: sk98lin network driver When: Feburary 2008 Why:In kernel tree version of driver is unmaintained. Sk98lin driver replaced by the skge driver. Who:Stephen Hemminger <[EMAIL PROTECTED]> --- We have been over this several times, and I thought someone had taken over the driver and was providing patches to put it in. Both skge and sky2 have been proposed as the replacement, people have reported problems with each. Suggest leaving this alone until the sk98lin actually needs work, then take it out. Problems in my problem system have been intermittent, take 4-40 hours to show and generate no errors, other than the driver thinks it's sending packets and the sniffer doesn't. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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/
Driver removals
Just a general thought on removing drivers in general, when a driver is removed because there's a better one, it would be good to have either a message which shows up at "make oldconfig" time, or a file listing the driver(s) which replace it. Half the resistance to removing drivers is finding what is supposed to replace the driver. For instance a list of all the drivers Adrian Bunk has suggested to replace sk98lin, so users have something better than searching the source code and/or LKML archive to find the next thing to try. In general, if a driver works and is being used, until it *needs* attention I see no reason to replace it. I don't agree that "it forces people to try the new driver" is a valid reason, being unmaintained is only a problem if it needs maintenance. I am not going to reopen that topic, I'm simply noting a general opposition to unfunded mandates, and requiring changes to kernel, module and/or rc.local config is just that. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Scheduler(?) regression from 2.6.22 to 2.6.24 for short-lived threads
Olof Johansson wrote: However, I fail to understand the goal of the reproducer. Granted it shows irregularities in the scheduler under such conditions, but what *real* workload would spend its time sequentially creating then immediately killing threads, never using more than 2 at a time ? If this could be turned into a DoS, I could understand, but here it looks a bit pointless :-/ It seems generally unfortunate that it takes longer for a new thread to move over to the second cpu even when the first is busy with the original thread. I can certainly see cases where this causes suboptimal overall system behaviour. I think the moving to another CPU gets really dependent on the CPU type. On a P4+HT the caches are shared, and moving costs almost nothing for cache hits, while on CPUs which have other cache layouts the migration cost is higher. Obviously multi-core should be cheaper than multi-socket, by avoiding using the system memory bus, but it still can get ugly. I have an IPC test around which showed that, it ran like hell on HT, and progressively worse as cache because less shared. I wonder why the latest git works so much better? -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Massive IDE problems. Who leaves data here?
Manuel Reimer wrote: Hello, anything started with a try to burn Slackware 12.0 from the original DVD to an new medium with different boot settings. I always got corrupted results and didn't know why. So I started with an "md5sum -c CHECKSUMS.md5" directly on the original media. This resulted in "anything OK". Now I copied the whole DVD to my hard drive and created an ISO from it. I mounted the ISO locally and my md5sum now results in 5 corrupted files. --> A Bug in mkisofs? No, unfortunately not, as a md5sum on the copy, I have created from the original DVD by using "cp -vr" is corrupted, too! Possibly a known kernel problem, you may have read past the end of data into the pad sectors of the DVD and gotten garbage at the end of the ISO image. Use isoinfo to determine the correct size of the ISO filesystem, and compare. You can try setting readahead on the DVD reader to zero with blockdev. If the file is smaller, other bug, if readahead hit EOF it returns no data instead of a short read, the blockdev fix should handle that as well. This was supposed to be fixed in recent kernels, that may be true. I suggest the [EMAIL PROTECTED] mailing list is a better forum for CD/DVD/BR problems, good technical people, unfortunately with personal agendas in some cases. So md5sum on the original DVD is OK, but after copying to my hard drive, several files are corrupted. That's odd, I would expect the data on the disk to just be the wrong size, and get a CRC on that. You might also use readcd to pull the data, that almost always does what it should. I'm using kernel 2.6.21.5. Distribution is Slackware 12.0 All my "partitions" are LVs in LVM2 I also updated the kernel to 2.6.23.12 to test with this one, but I still get corrupted files. Is this a LVM bug? Do I already have a corrupted LVM filesystem? How to check/fix it? Is this a known kernel bug? Which may be the reason for corrupted files? I've created a backup of my important data to a second disc to a "real ext2 partition" (without LVM), but this is connected to the same IDE controller and I don't even know if I may still trust my mainboard... I also get those kernel messages via dmesg: http://pastebin.org/16537 Could be anything, in no order dirty lens, bad drive, bad DVD, firmware error, cable, power supply, acpi confused... could even be a poorly handled end of data on the DVD. Not enough info for me to tell, for sure. Trying readcd is cheap, turning off readahead on the DVD drive is easy, if the problem persists you probably want to take it to the mailing list. Thank you very much in advance for any help! I'm not sure I helped, but you now have more and better things about which to be confused. ;-) Yours Manuel -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: [RFC][PATCH] per-task I/O throttling
Andrea Righi wrote: Allow to limit the bandwidth of I/O-intensive processes, like backup tools running in background, large files copy, checksums on huge files, etc. This kind of processes can noticeably impact the system responsiveness for some time and playing with tasks' priority is not always an acceptable solution. This patch allows to specify a maximum I/O rate in sectors per second for each single process via /proc//io_throttle (default is zero, that specify no limit). It would seem to me that this would be vastly more useful in the real world if there were a settable default, so that administrators could avoid having to find and tune individual user processes. And it would seem far less common that the admin would want to set the limit *up* for a given process, and it's likely to be one known to the admin, at least by name. Of course if you want to do the effort to make it fully tunable, it could have a default by UID or GID. Usful on machines shared by students or managers. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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][RFC] fast file mapping for loop
Jens Axboe wrote: Hi, loop.c currently uses the page cache interface to do IO to file backed devices. This works reasonably well for simple things, like mapping an iso9660 file for direct mount and other read-only workloads. Writing is somewhat problematic, as anyone who has really used this feature can attest to - it tends to confuse the vm (hello kswapd) since it break dirty accounting and behaves very erratically on writeout. Did I mention that it's pretty slow as well, for both reads and writes? Since you are looking for comments, I'll mention a loop-related behavior I've been seeing and see if it gets comments or is useful, since it can be used to tickle bad behavior on demand. I have an 6GB sparse file, which I mount with cryptoloop and populate as an ext3 filesystem (more later on why). I then copy ~5.8GB of data to the filesystem, which is unmounted to be burnt to a DVD. Before it's burned the "dvdisaster" application is used to add some ECC information to the end, and make an image which fits on a DVD-DL. Media will be burned and distributed to multiple locations. The problem: When copying with rsync, the copy runs at ~25MB/s for a while, then falls into a pattern of bursts of 25MB/s followed by 10-15 sec of iowait with no disk activity. So I tried doing the copy by cpio find . -depth | cpio -pdm /mnt/loop which shows exactly the same behavior. Then, for no good reason I tried find . -depth | cpio -pBdm /mnt/loop and the copy ran at 25MB/s for the whole data set. I was able to see similar results with a pure loop mount, I only mention the crypto for accuracy. Because many of these have been shipped over the last two years and new loop code would only be useful in this case if it were compatible so old data sets could be read. It also behaves differently than a real drive. For writes, completions are done once they hit page cache. Since loop queues bio's async and hands them off to a thread, you can have a huge backlog of stuff to do. It's hard to attempt to guarentee data safety for file systems on top of loop without making it even slower than it currently is. Back when loop was only used for iso9660 mounting and other simple things, this didn't matter. Now it's often used in xen (and others) setups where we do care about performance AND writing. So the below is a attempt at speeding up loop and making it behave like a real device. It's a somewhat quick hack and is still missing one piece to be complete, but I'll throw it out there for people to play with and comment on. So how does it work? Instead of punting IO to a thread and passing it through the page cache, we instead attempt to send the IO directly to the filesystem block that it maps to. loop maintains a prio tree of known extents in the file (populated lazily on demand, as needed). Advantages of this approach: - It's fast, loop will basically work at device speed. - It's fast, loop it doesn't put a huge amount of system load on the system when busy. When I did comparison tests on my notebook with an external drive, running a simple tiobench on the current in-kernel loop with a sparse file backing rendered the notebook basically unusable while the test was ongoing. The remapper version had no more impact than it did when used directly on the external drive. - It behaves like a real block device. - It's easy to support IO barriers, which is needed to ensure safety especially in virtualized setups. Disadvantages: - The file block mappings must not change while loop is using the file. This means that we have to ensure exclusive access to the file and this is the bit that is currently missing in the implementation. It would be nice if we could just do this via open(), ideas welcome... - It'll tie down a bit of memory for the prio tree. This is GREATLY offset by the reduced page cache foot print though. - It cannot be used with the loop encryption stuff. dm-crypt should be used instead, on top of loop (which, I think, is even the recommended way to do this today, so not a big deal). -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Freezing filesystems (Was Re: What's in store for 2008 for TuxOnIce?)
Theodore Tso wrote: On Wed, Jan 02, 2008 at 10:54:18AM +1100, Nigel Cunningham wrote: I would also like the TuxOnIce issues related to drivers, ACPI, etc. to go to one of the kernel-related lists, but I think linux-pm may be better for that due to the much lower traffic. I guess that makes sense. I guess people can always be referred to LKML for the issues where the appropriate person isn't on linux-pm. Hi Nigel, I'd really recommend pushing the TuxOnIce discussions to LKML. That way people can see the size of the user community and Andrew and Linus can see how many people are using TuxOnIce. They can also see how well the TuxOnIce community helps address user problems, which is a big consideration when Linus decides whether or not to merge a particular technology. If the goal is eventual merger of TuxOnIce, LKML is really the best place to have the discussions. Examples such as Realtime, CFS, and others have shown that you really want to keep the discussion front and center. When one developer says, "not my problem; my code is perfect", and the other developer is working with users who report problems, guess which technology generally ends up getting merged by Linus? Judging from the fact that TuxOnIce is still excluded, I would say the answer is obvious. :-( Posession is nine points of the law... -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: semi-regular plea for stable device mapping
Jan Engelhardt wrote: On Jan 1 2008 10:54, Gene Heskett wrote: BUT! This defeats a fix I've had in my modprobe.conf for over a year now that gave the LVM stuff a stable major device # of 238, and now my LVM major is back to whatever mood the kernel is in, in this particular bootup case to #253. It may now be stable for a bit at that number because I see that pktcdvd has been given a stable address of its own, apparently with a major of 10. That was the wedgie that fscked things up originally for me. But what else lurks in the deep end of this experimental pool, to play piranna with us again when we least expect it? Why exactly would you require a fixed major - not running udev or thelike? Use the boot parameter, dm_mod.major=238. What? And what happens when that gets used for something else? And if you say "we'll avoid using that" then you are treating it as a fixed value anyway. This drives tar up a wall because it uses this device number as part of the file comparisons it does, and it thinks everything is therefore new and needs a full level 0 backup. This is not at all practical, and requires that I wonder how FreeBSD gets around this, because they've got dynamic numbers everywhere. Did they? I haven't tried using tar in the appropriate ways on BSD to see if it behaves in the same way. Of course on a system which doesn't change between backups I guess the dynamic number would be the same in any case. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: RAID timeout parameter accessibility request
Jose de la Mancha wrote: Hi everyone. I'm sorry but I'm not currently subscribed to this list (I've been sent here by the listmaster), so please CC me all your answers/comments. Thanks in advance. SHORT QUESTION : In a Debian-controlled RAID array, is there a parameter that handles the timeout before a non-responding drive is dropped from the array ? Can this timeout become user-adjustable in a future build ? EXPLANATIONS : As you might know, if you install and use a "desktop edition" hard drive in a RAID array, the drive may not work correctly. This is caused by the normal error recovery procedure that a desktop edition hard drive uses : when an error is found on a desktop edition hard drive, the drive will enter into a deep recovery cycle to attempt to repair the error, recover the data from the problematic area, and then reallocate a dedicated area to replace the problematic area. This process can take up to 120 seconds depending on the severity of the issue. The problem is that most RAID controllers allow a very short amount of time (7-15 seconds) for a hard drive to recover from an error. If a hard drive takes too long to complete this process, the drive will be dropped from the RAID array ! Of course there are "RAID edition" hard drives with a feature called TLER (Time Limited Error Recovery) which stops the hard drive from entering into a deep recovery cycle. The hard drive will only spend 7 seconds to attempt to recover. This means that the hard drive will not be dropped from a RAID array. But these "special" hard drives are way too expensive IMHO just for a small firmware-based feature. I'm not sure "way too expensive" is appropriate. I'm using Seagate 320GB "NS" drives instead of "AS" models, and at the time I bought them they were $100 vs. $95 and are now $95 vs. $85. Other sizes and vendors have similar price points. A 10-15% premium seems reasonable for the firmware, faster access, and a general assurance that the drive is intended for 7/24 use. On a small home array the cost is minimal, and if you are running desktop drives in huge arrays 7/24 you probably are doing other cost cutting tradeoffs to reliability, it's a choice. There would be an easy way to allow users to use "ordinary" hard drives in a Debian software-controlled RAID array. So here's my request : I suppose there is a parameter that handles the default timeout before a drive is dropped from the RAID array. I don't know if this parameter is hardcoded, but it would be nice if it was user-adjustable. This way, we could simply set up this parameter to 120 seconds or more (instead of 7-15) and we wouldn't have any more problems with using desktop "edition hard" drives in a RAID array. What do you think ? Can it be done in a future build ? Just in general I agree, I'd like to see the error reported back up and let the user make the decision. One of the benefits of Linux is that it lets you make your own decisions, even bad ones. Windows assumes it owns the computer, you're an idiot, and it will let you use your computer if you do it their way. I really hope that you'll be able to help, because I guess a lot of people can be concerned by this issue. Not so much, with rewrites of sectors where possible this problem is less common than it was. But I agree on the drive kicking option, more control is good. However, the timeout should be in the driver, not in the raid code, that's where it belongs. The kernel copes with errors better than having a drive go practice self-gratification for minutes at a time. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: More verizon problems
Gene Heskett wrote: Resend, with more odd data from fetchmail.log appended. Just for a heads up, for about the last 8 hours, verizon, my ISP, has been inserting themselves into the path between my gmail account and my local fetchmail of this email subcription at pop.gmail.com. Worse yet they are bouncing the messages in a way that makes it look as if I sent them when they in fact originated at vger.kernel.org. Somehow they have convinced themselves that any mailing list this busy must be spam and is to be bounced. Either that or they, verizon, since they sleep with M$, have taken a large under the table payment to screw with linux in any way they can. It bears investigating. I called just now and screamed bloody murder at tech support, and in about 15 minutes I started getting the list again, BUT they are still in the path between vger and my fetchmail daemon as shown below. Or at least that is how I am interpreting the incoming headers, which now look like this by the time they hit my inbox but with my SA headers clipped: --- Received: from incoming.verizon.net [206.46.232.10] by coyote.coyote.den with POP3 (fetchmail-6.3.6) for <[EMAIL PROTECTED]> (single-drop); Thu, 20 Dec 2007 21:10:08 -0500 (EST) Received: from mailbag1.bizmailsrvcs.net ([172.18.12.131]) by vms051.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <[EMAIL PROTECTED]> for [EMAIL PROTECTED]; Thu, 20 Dec 2007 20:08:11 -0600 (CST) Received: from [64.233.162.238] (port= helo=nz-out-0506.google.com) by mailbag1.bizmailsrvcs.net with esmtp (Exim 4.68) (envelope-from <[EMAIL PROTECTED]>) id 1J5XG9-00052G-Dufor [EMAIL PROTECTED]; Thu, 20 Dec 2007 20:05:09 -0600 Right here I see that google forwarded your mail from their (google) server sending to the bizmailsrvcs.net (verizon) server, and VZ didn't jump in the path, google put them there. Received: by nz-out-0506.google.com with SMTP id x7so90741nzc.3 for <[EMAIL PROTECTED]>; Thu, 20 Dec 2007 18:08:08 -0800 (PST) Most likely cause is that you forwarded mail from google to verizon, which is probably a bad thing on many levels. Not Verizon's fault. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Trying to convert old modules to newer kernels
Lennart Sorensen wrote: On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Well I guess you can either fix the assembly once and for all to handle the current linux way of doing things, or you can patch to kernel back to the old ways of doing things when using your driver. I suppose you could just add some wrapper functions to your assembly that uses the new regparm calling method and then calls your methods the old way and selectively enable those when regparm is used by the kernel if you want to support all kernel versions. Or you could use inline assembly in C functions to handle the calling convention for you. If I were to guess, based on nothing but what's in this thread, people who write modules in assembler would want to avoid the the wrapper overhead. Of course putting image processing in the kernel at all instead of user programs is not something I ever do... -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Trying to convert old modules to newer kernels
James Courtier-Dutton wrote: J.A. Magallón wrote: I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Just for curiosity... yep, I understand now you have everything written in assembler, but why not consider start writing it in C and stop doing the compiler work (such as pipelining, out of order reordering, loop unrolling for specific processor, and so on...) That's what everyone taught me, nowadays you won't be better than the compiler in anything longer than three lines... Not true for image processing. compilers are not too good with optimizing mmx and sse algorithms. This is why user space libraries like ffmpeg still use assembly code. If half of what I read about the Intel compiler is true, that may no longer be true. That being said, I don't think sse and mmx are available in kernel space, so I would have suggested doing all the grunt work in userspace would be better for this persons application so that he could use sse and mmx etc. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: /dev/urandom uses uninit bytes, leaks user data
Theodore Tso wrote: On Tue, Dec 18, 2007 at 02:39:00PM +1030, David Newall wrote: Thus, the entropy saved at shutdown can be known at boot-time. (You can examine the saved entropy on disk.) If you can examine the saved entropy on disk, you can also introduce a trojan horse kernel that logs all keystrokes and all generated entropy to the FBI carnivore server --- you can replace the gpg binary with one which ships copies of the session keys to the CIA --- and you can replace the freeswan server with one which generates emphermal keys by encrypting the current timestamp with a key known only by the NSA. So if the attacker has access to your disk between shutdown and boot up, you are *done*. /dev/random is the least of your worries. Really, why is it that people are so enamored about proposing these totally bogus scenarios? Yes, if you have direct physical access to your machine, you can compromise it. But there are far easier ways that such a vulnerability can be exploited, rather than making it easy to carry out an cryptoanalytic attack on /dev/random. (And yes, after using the saved state to load the entropy at boot-time, the saved state file is overwritten, and if you're paranoid, you can scrub the disk after it is read and mixed into the entropy pool. And yes, the saved state is *not* the entropy pool used during the previous boot, but entropy extracted using SHA-1 based CRNG.) If you have a server, the best thing you can do is use a hardware random number generator, if it exists. Fortunately a number of hardware platforms, such as IBM blades and Thinkpads, come with TPM modules that include hardware RNG's. That's ultimately the best way to solve these issues. Just how random are they? Do they turn out to be quite predictable if you're IBM? They use a noise diode, so they are as good as any other hardware random number generator. Of course, you ultimately have to trust the supplier of your hardware not to do something screwy, and Thinkpads are now made by Lenovo, which has caused some US Government types to get paranoid --- but that's why the best way to do things is to get entropy from as many places as possible, and mix it all into /dev/random. If any one of them is unknown to the attacker, he's stuck. In another thread I believe I mentioned things an attacker can't know (unless your system is already compromised) like fan speed, CPU temperature, etc. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: /dev/urandom uses uninit bytes, leaks user data
David Newall wrote: Theodore Tso wrote: On Tue, Dec 18, 2007 at 01:43:28PM +1030, David Newall wrote: On a server, keyboard and mouse are rarely used. As you've described it, that leaves only the disk, and during the boot process, disk accesses and timing are somewhat predictable. Whether this is sufficient to break the RNG is (clearly) a matter of debate. In normal operaiton, entropy is accumlated on the system, extracted via /dev/urandom at shutdown, and then loaded back into the system when it boots up. Thus, the entropy saved at shutdown can be known at boot-time. (You can examine the saved entropy on disk.) If you have a server, the best thing you can do is use a hardware random number generator, if it exists. Fortunately a number of hardware platforms, such as IBM blades and Thinkpads, come with TPM modules that include hardware RNG's. That's ultimately the best way to solve these issues. Just how random are they? Do they turn out to be quite predictable if you're IBM? The typical RNG is a noise diode or other similar hardware using thermal noise, so it's unlikely that anyone but God could predict it. There are some USB devices which supposedly use radioactive decay, I'm unsure if that's better but I don't want to carry the dongle in my pants pocket. The hotbits network site uses radioactive decay to generate it's numbers. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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 00/29] Swap over NFS -v15
Peter Zijlstra wrote: Hi, Another posting of the full swap over NFS series. Andrew/Linus, could we start thinking of sticking this in -mm? Two questions: 1 - what is the memory use impact on the system which don't do swap over NFS, such as embedded systems, and 2 - what is the advantage of this code over the two existing network swap approaches, swapping to NFS mounted file and swap to NBD device? I've used the NFS file when a program was running out of memory and that seemed to work, people in UNYUUG have reported that the nbd swap works, so what's better here? -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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 2/6] random: use xor for mixing
Theodore Tso wrote: On Sat, Dec 08, 2007 at 06:40:17PM -0600, Matt Mackall wrote: I'm working on strengthening forward security for cases where the internals are exposed to an attacker. There are any number of situations where this can and does happen, and ensuring we don't expose ourselves to backtracking is a worthwhile theoretical concern. See my other comments; I don't think we are currently vulnerable to backtracking. I tend to view backtracking as largely a theoretical concern, as most of the time, if the attacker has read access to kernel memory in order to compromise the internal state of /dev/random, the attacker very likely has *write* access to kernel memory, at which point you have much bigger problems to worry about, at least going forward. I suppose if you had *just* generated an 80-bit AES session key, right before the internal state was compromised, this might be interesting, but if the attacker can compromise arbitrary kernel memory, then attacker might as well just grab keying information from the userspace process --- such as perhaps the long-term private key of the user, or the data to be encrypted. So my personal take on it is that protecting against backtracking attacks is mainly useful in silencing academics who like to come up with, well, largely academic and theoretical scenario. If it doesn't take much effort, sure, let's try to protect against it (and I think we're OK already). But a much better use of our time would be spent creating userspace support so we can more efficiently pull entropy from TPM modules, or the noise from a sound/microphone input, etc., or other hardware sources of entropy. That would provide a much more practical improvement to the /dev/random subsystem than worry about what I feel are largely academic concerns. That doesn't actually sound too hard, and the sounds of passing traffic are not likely to be replicable in any case. Lots of sensor data might be used as well, fan rpm, etc. That sounds so obvious I can't believe there isn't a reason it's not being done. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Iomega ZIP-100 drive unsupported with jmicron JMB361 chip?
trash can wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Success! I downloaded kernel-2.6.24-0.81.rc4.git7.fc9.src.rpm from the Fedora development tree. Went through "rpm dependecy hell" and solved all dependencies by installing other fc9 rpms. I used config-2.6.23.1-42.fc8 as my starting point. My config-2.6.24-0.81.rc4.git7.local.fc8 is attached. After compilation and installation of the kernel rpm, upon boot I could see a device sdc4 being created, but boot failed with "mount: missing mount point", some errors in mounting from setuproot and switchroot. I believe the problem was with the Red Hat/Fedora anaconda installer and/or grub, and my multiboot machine setup. I had not been able to boot updated fc8 kernel packages, only the originally installed kernel. Note that my Fedora 7 and Fedora 8 distributions share no directories (one exception) and all this work is taking place in the Fedora 8 distribution. The /boot partition IS shared among my distributions. I found my /etc/fstab file had two "/" mount point entries. The last line contained LABEL=/ and is a reference to my Fedora 7 root partition. I deleted this line from fstab as I did not want to change the mount point for this line to mount my Fedora 7 distribution on Fedora 8. This kernel installation process was appending LABEL=/ to my kernel line in grub.conf: kernel /vmlinuz-2.6.24-0.81.rc4.git7.local.fc8 ro root=/dev/VGf800/LogVol00 rhgb quiet LABEL=/ LABEL=/ was removed from the line. I then needed to recreate my initrd image: mkinitrd /boot/initrd-2.6.24-0.81.rc4.git7.local.fc8.img \ 2.6.24-0.81.rc4.git7.local.fc8 Finally I was able to boot (Zip disk inserted) to the local kernel and the Zip drive works as expected. # blkid /dev/sdc4: SEC_TYPE="msdos" LABEL="ZIP-100" UUID="4910-1305" TYPE="vfat" dmesg: ata9.00: ATAPI: LITE-ON DVDRW SOHW-1693S, KS0B, max UDMA/66 ata9.01: ATAPI: IOMEGA ZIP 100 ATAPI, 05.H, max MWDMA1, CDB intr ata9.00: limited to UDMA/33 due to 40-wire cable ata9.00: configured for UDMA/33 ata9.01: configured for MWDMA1 scsi 8:0:0:0: CD-ROMLITE-ON DVDRW SOHW-1693S KS0B PQ: 0 ANSI: 5 scsi 8:0:1:0: Direct-Access IOMEGA ZIP 100 05.H PQ: 0 ANSI: 5 sd 8:0:1:0: [sdc] 196608 512-byte hardware sectors (101 MB) sd 8:0:1:0: [sdc] Write Protect is off sd 8:0:1:0: [sdc] Mode Sense: 00 40 00 00 sd 8:0:1:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 8:0:1:0: [sdc] 196608 512-byte hardware sectors (101 MB) sd 8:0:1:0: [sdc] Write Protect is off sd 8:0:1:0: [sdc] Mode Sense: 00 40 00 00 sd 8:0:1:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc4 My thanks to all the great people who solved this problem and those who patiently responded to my queries. - -RoyBoy626 I've been behing reading this list, I was going to say that I have always had best luck with those drives using the old idescsi driver, although I haven't used a kernel newer than... 2.6.18 or so on the old machines. Since you have a solution I won't suggest you try that with an old kernel ;-) -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: programs vanish with 2.6.22+
Markus wrote: Well, now some windows vanished, but no additional messages were produced by kernel. When somebody could tell what I exactly need to do... would be nice. Or a hit, in what direction I should look. Because its really nasty to not being able to use a current kernel. I already rebuild the whole system, as suggested by the gentoo-devs, without success. I could also try to debug/strace/whatever the apps and wait for it to disappear. Just talk to me, I am not able to do this on my own... Try running under GNOME if you can, this sounds as if it may be an X problem. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Does vger.kernel.org automatically drop spams?
Tetsuo Handa wrote: Hello. Matti Aarnio wrote: Does vger.kernel.org have spam filter and automatically drop spams? Yes. Yes. And even worse: SILENTLY drop it. The reason was: global taboo header: m!OJFS! I don't recall why that was declared taboo, but it apparently bites on References: headers.. Entirely unintentional, I assure you. I see. Thank you. Well, may be my address was registered as a spammer. What should I do to post my message? Should I use different From: address? Should I stop sending to multiple lists? Since this was in the References header, stop replying to messages with OFJS in the Message-Id would do it, if I read Matti's reply correctly. Were other replies also blocked, Matti? Does the filter hit References: but not In-Reply-To: and so apply to responses to the post found in a newsgroup but not on the mailing list? We (the postmasters) can approve your messages for posting, but it will take a few hours that I get off work, and have time to do it. (I need to do some additional setups, all those lists are not in my existing majordomo password database..) Should I wait for your approval? -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: sockets affected by IPsec always block (2.6.23)
David Miller wrote: From: Herbert Xu <[EMAIL PROTECTED]> Date: Wed, 5 Dec 2007 11:12:32 +1100 [INET]: Export non-blocking flags to proto connect call Previously we made connect(2) block on IPsec SA resolution. This is good in general but not desirable for non-blocking sockets. To fix this properly we'd need to implement the larval IPsec dst stuff that we talked about. For now let's just revert to the old behaviour on non-blocking sockets. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> We made an explicit decision not to do things this way. Non-blocking has a meaning dependant upon the xfrm_larval_drop sysctl setting, and this is across the board. If xfrm_larval_drop is zero, non-blocking semantics do not extend to IPSEC route resolution, otherwise it does. If he sets this sysctl to "1" as I detailed in my reply, he'll get the behavior he wants. I think you for the hint, but I would hardly call this sentence "detailed" in terms of being a cookbook solution to the problem. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Kernel 2.6.23.9 / P35 Chipset + WD 750GB Drives (reset port)
Tejun Heo wrote: Bill Davidsen wrote: Jan Engelhardt wrote: On Dec 1 2007 06:26, Justin Piszcz wrote: I ran the following: dd if=/dev/zero of=/dev/sdc dd if=/dev/zero of=/dev/sdd dd if=/dev/zero of=/dev/sde (as it is always a very good idea to do this with any new disk) Why would you care about what's on the disk? fdisk, mkfs and the day-to-day operation will overwrite it _anyway_. (If you think the disk is not empty, you should look at it and copy off all usable warez beforehand :-) Do you not test your drive for minimum functionality before using them? I personally don't. Also, if you have the tools to check for relocated sectors before and after doing this, that's a good idea as well. S.M.A.R.T is your friend. And when writing /dev/zero to a drive, if it craps out you have less emotional attachment to the data. Writing all zero isn't too useful tho. Drive failing reallocation on write is catastrophic failure. It means that the drive wanna relocate but can't because it used up all its extra space which usually indicates something else is seriously wrong with the drive. The drive will have to go to the trash can. This is all serious and bad but the catch is that in such cases the problem usually stands like a sore thumb so either vendor doesn't ship such drive or you'll find the failure very early. I personally haven't seen any such failure yet. Maybe I'm lucky. The problem is usually not with what the vendor ships, but what the carrier delivers. Bad handling does happen, "drop ship" can have several meanings, and I have received shipments with the "G sensor" in the case triggered. Zero is a handy source of data, but the important thing is to look at the relocated sector count before and after the write. If there are a lot of bad sectors initially, the drive is probably a poor choice for anything critical. Most data loss occurs when the drive fails to read what it thought it wrote successfully and the opposite - reading and dumping the whole disk to /dev/null periodically is probably much better than writing zeros as it allows the drive to find out deteriorating sector early while it's still readable and relocate. But then again I think it's an overkill. Writing zeros to sectors is more useful as cure rather than prevention. If your drive fails to read a sector, write whatever value to the sector. The drive will forget about the data on the damaged sector and reallocate and write new data to it. Of course, you lose data which was originally on the sector. I personally think it's enough to just throw in an extra disk and make it RAID0 or 5 and rebuild the array if read fails on one of the disks. If write fails or read fail continues, replace the disk. Of course, if you wanna be extra cautious, good for you. :-) -- Bill Davidsen <[EMAIL PROTECTED]> "Woe unto the statesman who makes war without a reason that will still be valid when the war is over..." Otto von Bismark -- 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: Why does reading from /dev/urandom deplete entropy so much?
Adrian Bunk wrote: On Thu, Dec 06, 2007 at 02:32:05PM -0500, Bill Davidsen wrote: ... Sounds like a local DoS attack point to me... As long as /dev/random is readable for all users there's no reason to use /dev/urandom for a local DoS... The original point was that urandom draws entropy from random, and that it is an an inobvious and unintentional drain on the entropy pool. At least that's how I read it. I certainly have programs which draw on urandom simply because it's a convenient source of meaningless data. I have several fewer since this discussion started, though, now that I have looked at the easy alternatives. -- Bill Davidsen <[EMAIL PROTECTED]> "Woe unto the statesman who makes war without a reason that will still be valid when the war is over..." Otto von Bismark -- 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: ICH9 & Core2 Duo - kernel crash
Pavol Cvengros wrote: Bill Davidsen wrote: Pavol Cvengros wrote: On Thursday 06 December 2007 21:15:53 Bill Davidsen wrote: Pavol Cvengros wrote: Hello, I am trying LKML to get some help on one linux kernel related problem. Lately we got a machine with new HW from Intel. CPU is Intel Core2 Duo E6850 3GHz with 2GB of RAM. Motherboard is Intel DG33BU with G33 chipset. After long fight with kernel crashes on different things, we figured out that if the multicore is disabled in bios, everything is ok and machine is running good. No kernel crashes no problems, but with one core only. This small table will maybe explain: Cores - kernel - state 2 - nonsmp or smp - crash 1 - smp or nonsmp - ok All crashes have been different (swaper, rcu, irq, init.) or we just got internal gcc compiler error while compiling kernel/glibc/ and the machine was frozen. Please can somebody advise what to do to identify that problem more precisely. (debug kernel options?) Our immpresion - ICH9 & ICH9R support in kernel is bad... sorry to say.. I have seen unusual memory behavior under heavy load, in the cases I saw it was heavy DMA load from multiple SCSI controllers, and one case with FFT on the CPU and heavy network load with gigE. Have you run memtest on this hardware? Just a thought, but I see people running Linux on that chipset, if not that particular board. A cheap test even if it shows nothing. Of course it could be a CPU cache issue in that one CPU, although that's unlikely. yes, memtest was running all his tests without problems. The wierd thing is that all kernel crashes we have seen were different (as stated in original mail) The problem with memtest, unless I underestimate it, is that it doesn't use all core and siblings, so it doesn't quite load the memory system the way regular usage would. Needless to say, if this does turn out to be a memory loading issue I don't know of any tools to really test it. I fall back on part swapping, but that only helps if it's the memory DIMM itself. right now that machine has 2 x 1GB DDR2 - 800MHz do you think I should test the machine with only one DDR? (I hope to put there 4GB all together) Well, odd memory problems are rare, did you look for a BIOS update? It could be that the chipset isn't being set properly, and would explain why it might work differently with another BIOS. But if there's nothing else to try, it won't hurt to see if it works differently with only one DDR. -- Bill Davidsen <[EMAIL PROTECTED]> "Woe unto the statesman who makes war without a reason that will still be valid when the war is over..." Otto von Bismark -- 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.6.23.9: x86_64: floppy not working: p35 chipset
Justin Piszcz wrote: On Fri, 7 Dec 2007, Bill Davidsen wrote: Justin Piszcz wrote: Trying to format a floppy (2-3 of them) on a GA-P35-DS4 2.0 with a regular Sony floppy on Debian x86_64 with kernel 2.6.23.9: # fdformat /dev/fd0 Could not determine current format type: No such device # mformat a: mformat: Could not get geometry of device (No such device) # # cat /proc/interrupts |grep floppy 6: 38 37 39 41 IO-APIC-edge floppy # dmesg|grep -A1 fd0 [ 52.689487] Floppy drive(s): fd0 is 1.44M [ 52.704661] FDC 0 is a post-1991 82077 During the 'attempted format' I've tried a few different floppies, the result is the same. The system is 64-bit only, no 32-bit emulation is enabled using a strict 64-bit-only userland. Has anyone else gotten their floppy drive to work under 64-bit? Is this just a case of a DOA floppy drive or is something else wrong? Maybe booting from a 32 bit live CD would help determine that. It certainly was seen at boot time. Didn't get hooked to some SCSI device name by udev, did it? -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot Retried with some other floppies and later tried the original, everything seems to be working now, must have been a bad floppy/some transient issue. Great! I did test that FC8 with a Fedora kernel will see and use the floppy. Even found a floppy to use. Now I have to figure out why I have a floppy with a gzipped ext2 filesystem on it. :-( Doesn't appear to be bootable, I thought it might be SYSLINUX for an old system which couldn't boot from CD or USB, but that doesn't seem to be the case. Anyway, glad the problem went away. -- Bill Davidsen <[EMAIL PROTECTED]> "Woe unto the statesman who makes war without a reason that will still be valid when the war is over..." Otto von Bismark -- 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: ICH9 & Core2 Duo - kernel crash
Pavol Cvengros wrote: On Thursday 06 December 2007 21:15:53 Bill Davidsen wrote: Pavol Cvengros wrote: Hello, I am trying LKML to get some help on one linux kernel related problem. Lately we got a machine with new HW from Intel. CPU is Intel Core2 Duo E6850 3GHz with 2GB of RAM. Motherboard is Intel DG33BU with G33 chipset. After long fight with kernel crashes on different things, we figured out that if the multicore is disabled in bios, everything is ok and machine is running good. No kernel crashes no problems, but with one core only. This small table will maybe explain: Cores - kernel - state 2 - nonsmp or smp - crash 1 - smp or nonsmp - ok All crashes have been different (swaper, rcu, irq, init.) or we just got internal gcc compiler error while compiling kernel/glibc/ and the machine was frozen. Please can somebody advise what to do to identify that problem more precisely. (debug kernel options?) Our immpresion - ICH9 & ICH9R support in kernel is bad... sorry to say.. I have seen unusual memory behavior under heavy load, in the cases I saw it was heavy DMA load from multiple SCSI controllers, and one case with FFT on the CPU and heavy network load with gigE. Have you run memtest on this hardware? Just a thought, but I see people running Linux on that chipset, if not that particular board. A cheap test even if it shows nothing. Of course it could be a CPU cache issue in that one CPU, although that's unlikely. yes, memtest was running all his tests without problems. The wierd thing is that all kernel crashes we have seen were different (as stated in original mail) The problem with memtest, unless I underestimate it, is that it doesn't use all core and siblings, so it doesn't quite load the memory system the way regular usage would. Needless to say, if this does turn out to be a memory loading issue I don't know of any tools to really test it. I fall back on part swapping, but that only helps if it's the memory DIMM itself. -- Bill Davidsen <[EMAIL PROTECTED]> "Woe unto the statesman who makes war without a reason that will still be valid when the war is over..." Otto von Bismark -- 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.6.23.9: x86_64: floppy not working: p35 chipset
Justin Piszcz wrote: Trying to format a floppy (2-3 of them) on a GA-P35-DS4 2.0 with a regular Sony floppy on Debian x86_64 with kernel 2.6.23.9: # fdformat /dev/fd0 Could not determine current format type: No such device # mformat a: mformat: Could not get geometry of device (No such device) # # cat /proc/interrupts |grep floppy 6: 38 37 39 41 IO-APIC-edge floppy # dmesg|grep -A1 fd0 [ 52.689487] Floppy drive(s): fd0 is 1.44M [ 52.704661] FDC 0 is a post-1991 82077 During the 'attempted format' I've tried a few different floppies, the result is the same. The system is 64-bit only, no 32-bit emulation is enabled using a strict 64-bit-only userland. Has anyone else gotten their floppy drive to work under 64-bit? Is this just a case of a DOA floppy drive or is something else wrong? Maybe booting from a 32 bit live CD would help determine that. It certainly was seen at boot time. Didn't get hooked to some SCSI device name by udev, did it? -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: [RFC] [PATCH] A clean approach to writeout throttling
Daniel Phillips wrote: On Wednesday 05 December 2007 17:24, Andrew Morton wrote: On Wed, 5 Dec 2007 16:03:01 -0800 Daniel Phillips <[EMAIL PROTECTED]> wrote: ...a block device these days may not be just a single device, but may be a stack of devices connected together by a generic mechanism such as device mapper, or a hardcoded stack such as multi-disk or network block device. It is necessary to consider the resource requirements of the stack as a whole _before_ letting a transfer proceed into any layer of the stack, otherwise deadlock on many partially completed transfers becomes a possibility. For this reason, the bio throttling is only implemented at the initial, highest level submission of the bio to the block layer and not for any recursive submission of the same bio to a lower level block device in a stack. This in turn has rather far reaching implications: the top level device in a stack must take care of inspecting the entire stack in order to determine how to calculate its resource requirements, thus becoming the boss device for the entire stack. Though this intriguing idea could easily become the cause of endless design work and many thousands of lines of fancy code, today I sidestep the question entirely using the "just provide lots of reserve" strategy. Horrifying as it may seem to some, this is precisely the strategy that Linux has used in the context of resource management in general, from the very beginning and likely continuing for quite some time into the future My strongly held opinion in this matter is that we need to solve the real, underlying problems definitively with nice code before declaring the opening of fancy patch season. So I am leaving further discussion of automatic resource discovery algorithms and the like out of this post. Rather than asking the stack "how much memory will this request consume" you could instead ask "how much memory are you currently using". ie: on entry to the stack, do current->account_block_allocations = 1; make_request(...); rq->used_memory += current->pages_used_for_block_allocations; and in the page allocator do if (!in_interrupt() && current->account_block_allocations) current->pages_used_for_block_allocations++; and then somehow handle deallocation too ;) Ah, and how do you ensure that you do not deadlock while making this inquiry? Perhaps send a dummy transaction down the pipe? Even so, deadlock is possible, quite evidently so in the real life example I have at hand. Yours is essentially one of the strategies I had in mind, the other major one being simply to examine the whole stack, which presupposes some as-yet-nonexistant kernel wide method of representing block device stacks in all there glorious possible topology variations. The basic idea being to know in real time how much memory a particular block stack is presently using. Then, on entry to that stack, if the stack's current usage is too high, wait for it to subside. We do not wait for high block device resource usage to subside before submitting more requests. The improvement you suggest is aimed at automatically determining resource requirements by sampling a running system, rather than requiring a programmer to determine them arduously by hand. Something like automatically determining a workable locking strategy by analyzing running code, wouldn't that be a treat? I will hope for one of those under my tree at Christmas. The problem is that you (a) may or may not know just how bad a worst case can be, and (b) may block unnecessarily by being pessimistic. The dummy transaction would be nice, but it would be perfect if you could send the real transaction down with a max memory limit and a flag, have each level check and decrement the max by what's actually needed, and then return some pass/fail status for that particular transaction. Clearly every level in the stack would have to know how to do that. It would seem that once excess memory use was detected the transaction could be failed without deadlock. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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] bw-qcam: adds parameter aggressive to skip passive detection and directly attempt initialization
Brett Warden wrote: On Dec 5, 2007 9:37 AM, Alan Cox <[EMAIL PROTECTED]> wrote: Although I would suggest that "aggressive" may not be the best term - I'm not such of a good one however - skip_passive ? How about force_init? Much more descriptive. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: ICH9 & Core2 Duo - kernel crash
Pavol Cvengros wrote: Hello, I am trying LKML to get some help on one linux kernel related problem. Lately we got a machine with new HW from Intel. CPU is Intel Core2 Duo E6850 3GHz with 2GB of RAM. Motherboard is Intel DG33BU with G33 chipset. After long fight with kernel crashes on different things, we figured out that if the multicore is disabled in bios, everything is ok and machine is running good. No kernel crashes no problems, but with one core only. This small table will maybe explain: Cores - kernel - state 2 - nonsmp or smp - crash 1 - smp or nonsmp - ok All crashes have been different (swaper, rcu, irq, init.) or we just got internal gcc compiler error while compiling kernel/glibc/ and the machine was frozen. Please can somebody advise what to do to identify that problem more precisely. (debug kernel options?) Our immpresion - ICH9 & ICH9R support in kernel is bad... sorry to say.. I have seen unusual memory behavior under heavy load, in the cases I saw it was heavy DMA load from multiple SCSI controllers, and one case with FFT on the CPU and heavy network load with gigE. Have you run memtest on this hardware? Just a thought, but I see people running Linux on that chipset, if not that particular board. A cheap test even if it shows nothing. Of course it could be a CPU cache issue in that one CPU, although that's unlikely. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Why does reading from /dev/urandom deplete entropy so much?
Matt Mackall wrote: On Tue, Dec 04, 2007 at 08:54:52AM -0800, Ray Lee wrote: (Why hasn't anyone been cc:ing Matt on this?) On Dec 4, 2007 8:18 AM, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Tue, Dec 04, 2007 at 12:41:25PM +0100, Marc Haber wrote: While debugging Exim4's GnuTLS interface, I recently found out that reading from /dev/urandom depletes entropy as much as reading from /dev/random would. This has somehow surprised me since I have always believed that /dev/urandom has lower quality entropy than /dev/random, but lots of it. man 4 random This also means that I can "sabotage" applications reading from /dev/random just by continuously reading from /dev/urandom, even not meaning to do any harm. Before I file a bug on bugzilla, ... The bug would be closed as invalid. No matter what you consider as being better, changing a 12 years old and widely used userspace interface like /dev/urandom is simply not an option. You seem to be confused. He's not talking about changing any userspace interface, merely how the /dev/urandom data is generated. For Matt's benefit, part of the original posting: Before I file a bug on bugzilla, can I ask why /dev/urandom wasn't implemented as a PRNG which is periodically (say, every 1024 bytes or even more) seeded from /dev/random? That way, /dev/random has a much higher chance of holding enough entropy for applications that really need "good" entropy. A PRNG is clearly unacceptable. But roughly restated, why not have /dev/urandom supply merely cryptographically strong random numbers, rather than a mix between the 'true' random of /dev/random down to the cryptographically strong stream it'll provide when /dev/random is tapped? In principle, this'd leave more entropy available for applications that really need it, especially on platforms that don't generate a lot of entropy in the first place (servers). The original /dev/urandom behavior was to use all the entropy that was available, and then degrade into a pure PRNG when it was gone. The intent is for /dev/urandom to be precisely as strong as /dev/random when entropy is readily available. The current behavior is to deplete the pool when there is a large amount of entropy, but to always leave enough entropy for /dev/random to be read. This means we never completely starve the /dev/random side. The default amount is twice the read wakeup threshold (128 bits), settable in /proc/sys/kernel/random/. In another post I suggested having a minimum bound (use not entropy) and a maximum bound (grab some entropy) with the idea that between these values some limited entropy could be used. I have to wonder if the entropy available is at least as unpredictable as the entropy itself. But there's really not much point in changing this threshold. If you're reading the /dev/random side at the same rate or more often that entropy is appearing, you'll run out regardless of how big your buffer is. Right, my thought is to throttle user + urandom use such that the total stays below the available entropy. I had forgotten that that was a lower bound, although it's kind of an on-off toggle rather than proportional. Clearly if you care about this a *lot* you will use a hardware RNG. Thanks for the reminder on read_wakeup. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Why does reading from /dev/urandom deplete entropy so much?
Adrian Bunk wrote: On Tue, Dec 04, 2007 at 12:41:25PM +0100, Marc Haber wrote: While debugging Exim4's GnuTLS interface, I recently found out that reading from /dev/urandom depletes entropy as much as reading from /dev/random would. This has somehow surprised me since I have always believed that /dev/urandom has lower quality entropy than /dev/random, but lots of it. man 4 random This also means that I can "sabotage" applications reading from /dev/random just by continuously reading from /dev/urandom, even not meaning to do any harm. Before I file a bug on bugzilla, ... The bug would be closed as invalid. No matter what you consider as being better, changing a 12 years old and widely used userspace interface like /dev/urandom is simply not an option. I don't see that he is proposing to change the interface, just how it gets the data it provides. Any program which depends on the actual data values it gets from urandom is pretty broken, anyway. I think that getting some entropy from network is a good thing, even if it's used only in urandom, and I would like a rational discussion of checking the random pool available when urandom is about to get random data, and perhaps having a lower and upper bound for pool size. That is, if there is more than Nmax random data urandom would take some, if there was less than Nmin it wouldn't, and between them it would take data, but less often. This would improve the urandom quality in the best case, and protect against depleting the /dev/random entropy in low entropy systems. Where's the downside? There has also been a lot of discussion over the years about improving the quality of urandom data, I don't personally think making the quality higher constitutes "changing a 12 years old and widely used userspace interface like /dev/urandom" either. Sounds like a local DoS attack point to me... -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: PROBLEM: loadlin incompatible with 2.6.23 kernels
Kenneth Howlett wrote: The loadlin boot loader fails to boot 2.6.23 kernels. I used msdos 6.22 in real mode, without himem.sys or any other memory manager, without any tsrs; loadlin 1.6c; and kernel 2.6.23.1-42.fc8, which is the install kernel for the fedora core 8 distribution. The normal loadlin messages are displayed, the display is cleared and the cursor moves to the upper left corner, and then nothing else happens. No kernel boot messages are displayed. The computer does not respond to most keyboard actions, but the computer does reboot when I press control-alternate-delete. My computer is a dell dimension 4100 with pentium III 733mhz and intel chipset, and ATI radeon all-in-wonder display controller. The output of loadlin -d is: LOADLIN v1.6c (C) 1994..2002 Hans Lermen <[EMAIL PROTECTED]> Your current LINUX kernel boot configuration is: image file: fed8.ker kernel version2.6.23.1-42.fc8 ([EMAIL PROTECTED]) #1 SMP Tue Oct 30 13:05:10 EDT 2007 kernel size: 0x001E0300 (high loaded) setup size: 0x2C00, heap: 0x1200 VGA mode: 0x command line (size 0x0013): BOOT_IMAGE=fed8.ker Your current DOS/CPU configuration is: load buffer size: 0x00F6 EXT , setup buffer size: 0x3E00 lowmem buffer:0x0008 (part of load buffer) total memory: 0x040FFC00 CPU is in REAL mode SetupIntercept: YES, legal intercept, setup header version 0206 stat1: cpu in real 386 mode, no need to backswitch input params (size 0x0011): fed8.ker -d o.txt LOADLIN started from DOS-prompt Option -t set, Linux not loaded I tried using loadlin -f, and the result was the same. I tried using loadlin -noheap, and the computer rebooted itself instead of crashing. I tried using freedos 1.0 instead of msdos 6.22, and instead of crashing, the computer displayed a message saying invalid opcode, and the dos prompt returned. I tried using the 586, 686, and debug kernels from packages on the fedora core 8 dvd, and the result was the same. I tried using the pae kernel from the package on the fedora core 8 dvd, and the computer crashed like before, but this time the computer did not respond to control-alternate-delete. Loadlin works ok with older kernels. The kernel works ok with other boot loaders. I tested the integrity of my fedora core 8 dvd and it was ok. I searched the web, and the only reference I found was http://kerneltrap.org/node/14842";>http://kerneltrap.org/node/14842. The first comment is from me. The person who wrote the original post seems to be compiling his own kernels; therefore this is probably a kernel problem, not a problem with the fedora core 8 distribution. The person who wrote the original post says that kernel 2.6.22.12 did not have this problem, therefore the problem probably appeared in the 2.6.23 kernels, and earlier kernels are probably ok. I do not know if the problem is with the kernel or with loadlin. Probably some people will say it is the kernel's fault, and other people will say it is loadlin's fault. I am not knowledgable about the kernel boot process, but I am guessing that the first thing the kernel does is uncompress itself, and the second thing the kernel does is set the vga or framebuffer mode. I am guessing that the clearing of the display is not done by loadlin, but is done as part of setting the vga or framebuffer mode. Therefore I guessed that the kernel successfully uncompressed itself, then got stuck setting the vga or framebuffer mode. So I tried changing the vga options. With vga=normal, the result is the same. With vga=771 (vesa framebuffer, 800x600, 256 colors), the computer crashes like before, but the cursor is not visible in the upper left corner. With vga=ask, the computer displays a message saying press enter for list, press space to continue. If I press space, the computer crashes. If I press enter, the computer displays a list of video modes. If I select 0, the computer crashes without changing the display. If I select 1, the text becomes smaller and occupies a smaller part of the display, and the computer crashes. If I select 2, the display clears and the computer crashes. With all of these crashes, the computer can still be rebooted by pressing control alternate delete. I conclude that the problem occurs after or at the end of setting the vga or framebuffer mode. The problem probably occurs before or at the beginning of probing for hardware, because no kernel boot messages are displayed after the vga=ask messages. I do not know why this occurs with loadlin and not with other boot loaders. Lots of stuff has changed in recent versions, if you can try booting with the option "acpi=off" that might or might not be informative. Haven't used loadlin in years, and be aware that the Fedora kernel is not entirely compatible with the kernel.org releases, although that's rarely a problem. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the
Re: Kernel Development & Objective-C
Alan Cox wrote: Well, original C allowed you to do what you wanted with pointers (I used to teach that back when K&R was "the" C manual). Now people which about having pointers outside the array, which is a crock in practice, as long as you don't actually /use/ an out of range value. Actually the standards had good reasons to bar this use, because many runtime environments used segmentation and unsigned segment offsets. On a 286 you could get into quite a mess with out of array reference tricks. variable with the address of the start. I was more familiar with the B stuff, I wrote both the interpreter and the code generator+library for the 8080 and GE600 machines. B on MULTICS, those were the days... :-D B on Honeywell L66, so that may well have been a relative of your code generator ? Probably the Bell Labs one. I did an optimizer on the Pcode which caught jumps to jumps, then had separate 8080 and L66 code generators into GMAP on the GE and the CP/M assembler or the Intel (ISIS) assembler for 8080. There was also an 8085 code generator using the "ten undocumented instructions" from the Dr Dobbs article. GE actually had a contract with Intel to provide CPUs with those instructions, and we used them in the Terminet(r) printers. Those were the days ;-) -- Bill Davidsen <[EMAIL PROTECTED]> "Woe unto the statesman who makes war without a reason that will still be valid when the war is over..." Otto von Bismark -- 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: Kernel 2.6.23.9 / P35 Chipset + WD 750GB Drives (reset port)
Jan Engelhardt wrote: On Dec 1 2007 06:26, Justin Piszcz wrote: I ran the following: dd if=/dev/zero of=/dev/sdc dd if=/dev/zero of=/dev/sdd dd if=/dev/zero of=/dev/sde (as it is always a very good idea to do this with any new disk) Why would you care about what's on the disk? fdisk, mkfs and the day-to-day operation will overwrite it _anyway_. (If you think the disk is not empty, you should look at it and copy off all usable warez beforehand :-) Do you not test your drive for minimum functionality before using them? Also, if you have the tools to check for relocated sectors before and after doing this, that's a good idea as well. S.M.A.R.T is your friend. And when writing /dev/zero to a drive, if it craps out you have less emotional attachment to the data. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Fedora's latest gcc produces unbootable kernels
Pierre Ossman wrote: On Sat, 1 Dec 2007 15:42:23 +0100 Pierre Ossman <[EMAIL PROTECTED]> wrote: The latest GCC in Fedora rawhide contains some serious bug (or provokes a latent one in the kernel) that makes every kernel built unbootable. It just locks up halfway through the init. Kernels that previously worked fine all now experience the same symptom. Even RH's own kernels exhibit this. The kernel built Nov 24th works, Nov 26th doesn't. gcc was updated 26th, 14 hours earlier. Digging a bit further, it is indeed the high-res stuff (the first missing message) that hangs. If I hard code the kernel to just be non-high-res capable, it boots, but time keeping is horribly broken. Anyway, hopefully this means I'll soon have the object file that gets miscompiled. Jakub also pointed me to an older gcc RPM so that I can produce an object file with that as well and see what differs. If you are referring to the "compat" RPMs, be aware that they use the current headers, which is a good or bad thing depending on what you want to do. If you want to build old software, you get to keep a down-rev virtual machine to do it right :-( -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Kernel Development & Objective-C
Alan Cox wrote: BCPL was typeless, as was the successor B (between Bell Labs and GE we B isn't quite typeless. It has minimal inbuilt support for concepts like strings (although you can of course multiply a string by an array pointer ;)) It also had some elegances that C lost, notably case 1..5: the ability to do no zero biased arrays x[40]; x-=10; Well, original C allowed you to do what you wanted with pointers (I used to teach that back when K&R was "the" C manual). Now people which about having pointers outside the array, which is a crock in practice, as long as you don't actually /use/ an out of range value. and the ability to reassign function names. printk = wombat; I had forgotten that, the function name was actually a variable with the entry point, say so in section 3.11. And as I recall the code, arrays were the same thing, a length ten vector was actually the vector and variable with the address of the start. I was more familiar with the B stuff, I wrote both the interpreter and the code generator+library for the 8080 and GE600 machines. B on MULTICS, those were the days... :-D as well as stuff like free(function); Alan (who learned B before C, and is still waiting for P) I had the BCPL book still on the reference shelf in the office, along with goodies like the four candidates to be Ada, and a TRAC manual. I too expected the next language to be "P". -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Kernel Development & Objective-C
David Newall wrote: Jan Engelhardt wrote: On Nov 30 2007 11:20, Xavier Bestel wrote: On Fri, 2007-11-30 at 19:09 +0900, KOSAKI Motohiro wrote: Has Objective-C ever been considered for kernel development? Why not C# instead ? Why not Haskell nor Erlang instead ? :-D I heard of a bash compiler. That would enable development time rationalization and maximize the collaborative convergence of a community-oriented synergy. Fortran90 it has to be. It used to be written in BCPL; or was that Multics? BCPL was typeless, as was the successor B (between Bell Labs and GE we write thousands of lines of B, ported to 8080, GE600, etc). C introduced types, and the rest is history. Multics is written in PL/1, and I wrote a lot of PL/1 subset G back when as well. You don't know slow compile until you get a seven pass compiler with each pass on floppy. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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.6.23.1: mdadm/raid5 hung/d-state
Jeff Lessem wrote: Dan Williams wrote: > The following patch, also attached, cleans up cases where the code looks > at sh->ops.pending when it should be looking at the consistent > stack-based snapshot of the operations flags. I tried this patch (against a stock 2.6.23), and it did not work for me. Not only did I/O to the effected RAID5 & XFS partition stop, but also I/O to all other disks. I was not able to capture any debugging information, but I should be able to do that tomorrow when I can hook a serial console to the machine. That can't be good! This is worrisome because Joel is giddy with joy because it fixes his iSCSI problems. I was going to try it with nbd, but perhaps I'll wait a week or so and see if others have more information. Applying patches before a holiday weekend is a good way to avoid time off. :-( I'm not sure if my problem is identical to these others, as mine only seems to manifest with RAID5+XFS. The RAID rebuilds with no problem, and I've not had any problems with RAID5+ext3. Hopefully it's not the raid which is the issue. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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.6.24-rc1: First impressions
Andrew Morton wrote: On Fri, 26 Oct 2007 21:33:40 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote: * Andrew Morton <[EMAIL PROTECTED]> wrote: so a final 'sync' should be added to the test too, and the time it takes factored into the bandwidth numbers? That's one way of doing it. Or just run the test for a "long" time. ie: much longer than (total-memory / disk-bandwidth). Probably the latter will give a more accurate result, but it can get boring. Longer might be less inaccurate, but without flushing the last data you really don't get best accuracy, you just reduce the error. Clearly doing fdatasync() is best, since other i/o caused by sync() can skew the results. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: RAID 10 w AHCI w NCQ = Spurius I/O error
Nestor A. Diaz wrote: Hello People, I need your help, this problem is turning me crazy. Did you know there is a raid list? I have created a RAID 10 using a RAID0 configuration on top of a two RAID1 devices (all software raid), like this: You have created a raid 0+1, raid10 is a different thing. Given your setup, raid10 is probably what you *should* have created. Personalities : [raid0] [raid1] md4 : active raid0 md2[0] md3[1] 605071872 blocks 64k chunks md0 : active raid1 sdd3[3] sda3[0] sdc3[2] sdb3[1] 9791552 blocks [4/4] [] md3 : active raid1 sdd2[2](F) sdb2[0] 302536000 blocks [2/1] [U_] md1 : active raid1 sdd1[3] sda1[0] sdc1[2] sdb1[1] 240832 blocks [4/4] [] md2 : active raid1 sda2[0] sdc2[1] 302536000 blocks [2/2] [UU] unused devices: But the sdd device sometimes fail, i have changed the hard disk, check the older sata drive, reformat using mke2fs -c -c (to check for media errrors both read and write, no media problems found, change the sata disk and the problem remains, also with a new sata hard disk). The systema is a supermicro server 5015-mt+ with an ich7 ahci controller [___snip___] The RAID 1 builds perfectly, but five days after that, the system shows a: end_request: I/O error, dev sdd, sector 144006110 raid1: Disk failure on sdd2, disabling device. Operation continuing on 1 devices end_request: I/O error, dev sdd, sector 144006222 end_request: I/O error, dev sdd, sector 144268814 RAID1 conf printout: --- wd:1 rd:2 disk 0, wo:0, o:1, dev:sdb2 disk 1, wo:1, o:0, dev:sdd2 RAID1 conf printout: --- wd:1 rd:2 disk 0, wo:0, o:1, dev:sdb2 Hardware error, almost certainly. If you're using a hub, I suspect that first, then cables and heat problems, then the controller, in rough order of likelyhood. a week before i get (under 2.6.18) the following message: [___lots more snip___] I have updated from 2.6.18 to 2.6.22 expecting to not have the problem, but the problem remains and i didn't know what could be the problem, the problem always happen on /dev/sdd, i use LVM on top of the RAID 10 software device. I am not sure if the problem was because i create the RAID10 using two RAID1 devices and then do a RAID0, or should i have to be used mdadm and the level 10 option ? Any suggestions will be welcome. Do you ever get errors in partitions which are not part of the raid0+1 setup, like md1? If not, look at your partition tables to see if you have any strange values there. Are all drives at the same firmware level? -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: Possible 2.6.23 regression - Disappearing disk space
James Ausmus wrote: Since updating my laptop to 2.6.23, occasionally all of my free disk space on my root partition will just go away, with no files accounting for the space, with no odd messages in dmesg or my syslog. If I reboot, I immediately have the proper amount of free space again. Here is the output of a du -sx * on /, and the output of the df command when the problem is occuring, followed by the same info after a fresh reboot (literally just did the command in the failed state, then immediately rebooted and ran the same commands again) - any thoughts as to what might be happening? Clearly some process is still using a deleted file. However, if it doesn't happen with 2.6.22.x kernels, it would seem fall under the category of regression, in the "used to work" sense. Before going further you may want to be really sure that an older kernel doesn't do this, so no one wastes time on a non-problem. Assuming the older kernel works fine, it's possible that some new behavior of the kernel as causing a process to misbehave, and step one is to use lsof and try to find the process. It's possible that "top" might be useful, although whatever is using the disk space may just be lurking. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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.6.25 patch] the planned eepro100 removal
Adrian Bunk wrote: This patch contains the planned removal of the eepro100 driver. Are the e100 people satisfied that e100 now handles all known cases? I remember that there were corner cases e100 didn't handle, have they all been fixed? -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: [RFD] iptables: mangle table obsoletes filter table
Al Boldi wrote: [EMAIL PROTECTED] wrote: On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said: Sure, the idea was to mark the filter table obsolete as to make people start using the mangle table to do their filtering for new setups. The filter table would then still be available for legacy/special setups. But this would only be possible if we at least ported the REJECT target to mangle. That's *half* the battle. The other half is explaining why I should move from a perfectly functional setup that uses the filter table. What gains do I get from doing so? What isn't working that I don't know about? etc? In other words - why do I want to move from filter to mangle? This has already been explained in this thread; here it is again: Al Boldi wrote: The problem is that people think they are safe with the filter table, when in fact they need the prerouting chain to seal things. Right now this is only possible in the mangle table. Why do they need PREROUTING? Well, for example to stop any transient packets being forwarded. You could probably hack around this using mark's, but you can't stop the implied route lookup, unless you stop it in prerouting. Basically, you have one big unintended gaping whole in your firewall, that could easily be exploited for DoS attacks at the least, unless you put in specific rules to limit this. Well... true enough on a small firewall machine with a really fast link, maybe. I like your point about efficiency better, it's more logical, like putting an ACCEPT of established connections before a lot of low probability rules. The only time I have seen rules actually bog a machine was when a major ISP sent out a customer "upgrade" with a bug which caused certain connections to be SYN-SYN/ACK-RST leaving half open sockets. They sent out 160k of them and the blocking list became very long as blocking rules were added. Plus, it's outrageously incorrect to accept invalid packets, just because your filtering infrastructure can only reject packets after they have been prerouted. As long as the filter table doesn't go away, sometimes things change after PREROUTING, like NAT, and additional rules must be used. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: "spurious completions during NCQ" with 2.6.23.1 and DVD Multi-Recorder on Thinkpad T61
Alan Cox wrote: On Mon, 22 Oct 2007 09:56:10 +0800 Federico Sevilla III <[EMAIL PROTECTED]> wrote: Hi, Using the 2.6.23.1 kernel and Debian Etch on a Lenovo Thinkpad T61 7659A21, I am getting two weird errors, as follows: Turn off bluetooth and you may find the stuck IRQ goes away - at least on some thinkpads there are weird extra IRQs when bluetooth is running which break stuff. There was an old American Music/Comedy show called "Hee Haw!" which had a recurring skit consisting of a farmer running into the doctor's office and saying "Doctor, doctor! It hurts when I do this!" followed by some unlikely activity. The doctor always replied "Then don't do that." Turning off bluetooth is a useful diagnostic test, but for some systems it's not a practical operating configuration. Any thoughts on making bluetooth work in these cases? Most laptops make a unit like the Logitech MX5000 BT keyboard desirable for extended use. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: Killing a network connection
Stefan Monnier wrote: [ I suppose this is not the best place to ask this, but comp.os.linux.networking couldn't come up with a good answer and I can't think of any intermediate step between these two groups ;-( ] I'd like (as root, obviously) to kill some of the TCP connections visible in netstat. I've found `tcpkill' and `cutter' but `cutter' only kills TCP connections that go *though* the machine (in my case, the machine is not a router, so there aren't any such thu connections anyway) and `tcpkill' can only kill the conection after seeing some activity (and it doesn't know to exit when the connections are killed). Also those 2 tools seem just overkill. I'd like simply to do (metaphorically) rm /tcpfs/ so it should not need to involve *any* use of the TCP protocol: just kill it locally, warn the associated process(es), free the resources and let the other end deal with it. The main use for me is to deal with dangling connections due to taking network interfaces up&down with different IP addresses (typically the wlan0 interface where the IP is different because I've modes from an AP to another). Of course, maybe there's another way to solve this particular problem, in case I'd like to hear about it as well. I'd like a way to just close TCP connections which are misbehaving in some way, not necessarily due to bad intent. I envision some tool which would take either IP or IP+port and send an RST to both ends. Yes, I could write one, but I bet someone already has. I did something similar a few years ago, but the requestor owns the code. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: Flynn's Original Paper about Computer Organization
Alan Cox wrote: On Mon, 15 Oct 2007 20:52:50 +0200 "Mohamed Bamakhrama" <[EMAIL PROTECTED]> wrote: Hi all, I am looking for Michael Flynn original paper about computer organization in which Flynn devised the so-called "Flynn Taxonomy". I tried Google, IEEE Xplore, ACM, Yahoo but in vain. I would be very grateful if someone can post a scanned version of the manuscript. You may find the following useful http://en.wikipedia.org/Wiki/Copyright Please don't ask on this list for people to abuse copyright law. His request is off-topic, and "post" would be a violation, but he is allowed a personal copy under "fair use" doctrine unless the law has changed recently. US copyright is unique, things on which copyright has expired were re-protected when the law changed, making copying which was legal when done a crime after the fact. I'm not sure British law using 400 year old precedents is better, just more predictable. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: What still uses the block layer?
Jeff Garzik wrote: But again, please remember that these USB devices are really SCSI devices. Same for SATA devices. There is a reason they are using the SCSI layer, and it isn't just because the developers felt like it :) /somewhat/ true I'm afraid: libata uses the SCSI layer for ATAPI devices because they are essentially bridges to SCSI devices. It uses the SCSI layer for ATA devices because the SCSI layer provided a huge amount of infrastructure that would need to have been otherwise duplicated, /then/ massaged into coordinating between layer> and when dealing with ATAPI. There is also a detail that was of /huge/ value when introducing a new device class: distro installers automatically work, if you use SCSI. If you use a new block device type, that behaves differently from other types and is on a different major, you have to poke the distros into action or do it yourself. IOW, it was the high Just Works(tm) value of the SCSI layer when it came to ATA (not ATAPI) devices. For the future, ATA will eventually be more independent (though the SCSI simulator will be available as an option, for compat), but the value is big enough to put that task on the back-burner. I remember being told that I didn't understand the problem when I suggested using ide-scsi for everything and just hiding the transport. I get great pleasure from having been (mostly) right on that one. I still have old systems running ZIP drives as scsi... -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: [RFD] iptables: mangle table obsoletes filter table
Bill Davidsen wrote: If not, then shouldn't the filter table be obsoleted to avoid confusion? That would probably confuse people. Just don't use it if you don't need to. That is a most practical suggestion. The problem is that people think they are safe with the filter table, when in fact they need the prerouting chain to seal things. Right now this is only possible in the mangle table. I'm not sure what you think is unsafe about using the filter table, and the order of evaluation issues certainly seem to suggest that some actions would take a major rethink at least. Perhaps you could avoid breaking all of the setups which currently work, rather than force everyone to do things differently because you feel that your way is better. It was my intention to suggest that unintentional breakage of existing setups should be avoided, not that removing the filter table was some evil plot. ;-) On rereading my original post I failed to make that clear, please take it as intended. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: [RFD] iptables: mangle table obsoletes filter table
Al Boldi wrote:
Patrick McHardy wrote:
Please send mails discussing netfilter to netfilter-devel.
Ok. I just found out this changed to vger. But
[EMAIL PROTECTED] is bouncing me.
Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
Other than requiring the REJECT target to be ported to the mangle table,
is the filter table faster than the mangle table?
There are some minor differences in ordering (mangle comes before
DNAT, filter afterwards), but for most rulesets thats completely
irrelevant. The only difference that really matters is that mangle
performs rerouting in LOCAL_OUT for packets that had their routing
key changed, so its really a superset of the filter table. If you
want to use REJECT in the mangle table, you just need to remove the
restriction to filter, it works fine. I would prefer to also remove
the restriction of MARK, CONNMARK etc. to mangle, they're used for
more than just routing today so that restriction also doesn't make
much sense. Patches for this are welcome.
Something like this (untested):
--- ipt_REJECT.bak.c2007-10-12 08:25:17.0 +0300
+++ ipt_REJECT.c2007-10-12 08:31:44.0 +0300
@@ -165,6 +165,7 @@ static void send_reset(struct sk_buff *o
static inline void send_unreach(struct sk_buff *skb_in, int code)
{
+ if (!skb_in->dst) ip_route_me_harder(&skb_in, RTN_UNSPEC);
icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
}
@@ -245,9 +246,6 @@ static struct xt_target ipt_reject_reg =
.family = AF_INET,
.target = reject,
.targetsize = sizeof(struct ipt_reject_info),
- .table = "filter",
- .hooks = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
- (1 << NF_IP_LOCAL_OUT),
.checkentry = check,
.me = THIS_MODULE,
};
If not, then shouldn't the filter table be obsoleted to avoid confusion?
That would probably confuse people. Just don't use it if you don't
need to.
That is a most practical suggestion.
The problem is that people think they are safe with the filter table, when in
fact they need the prerouting chain to seal things. Right now this is only
possible in the mangle table.
I'm not sure what you think is unsafe about using the filter table, and
the order of evaluation issues certainly seem to suggest that some
actions would take a major rethink at least. Perhaps you could avoid
breaking all of the setups which currently work, rather than force
everyone to do things differently because you feel that your way is better.
--
Bill Davidsen <[EMAIL PROTECTED]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
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: howto boost write(2) performance?
Michael Stiller wrote: Hi list, i'm developing an application (in C) which needs to write about 1Gbit/s (125Mb/s) to a disk array attached via U320 SCSI. It runs on Dual Core 2 Xeons @2Ghz utilizing kernel 2.6.22.7. People regularly report speeds higher than that on the RAID list, and I can get that order of magnitude speed using dd with 1MB buffers to a software RAID-0 array or cheap SATA drives. Are you using a decent controller? Many "RAID" controllers have bandwidth limitations, buffer size issues, etc. I had some chea "SCSI" arrays which were just SCSI controllers in from of a bunch of cheap, slow, non-SCSI drives. I buffer the data in (currently 4) 400Mb buffers and use write(2) in a dedicated thread to write them to the raw disk (no fs). I would limit the write size to a MB and see if that helps, regardless of the buffer size. A circular queue of smaller buffers, like ptbuf, may perform better. The write(2) performance is not good enough, the writer threads take to much time, and i ask you for ideas, howto to boost the write performance. Maybe mmaping the disk would work? I don't think it would help, I'd really try limiting the size of the write() calls first, assuming your hardware is adequate. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
Alan Cox wrote: Jan's code is here today and it works fine for me. How can you coherently argue against the plain fact that his feature solves my usecases perfectly fine, So add a notifier for console printk output. Then you can keep whatever out of kernel patches you like for printk output in chinese, colour, swedish chef ... And of those the chinese is probably a good deal more relevant than the colour. If kernel printing were going to be done over, I would suggest that instead of the current fixed format strings, the format argument would be an index, an ordinal into an array of *char pointers, and the string so described would be used as the format. These strings and pointers could be put in two modules, one part of init to be released after boot like other init code, one resident. And by loading different modules the error messages could be as short, long, or colorful as desired, and in any language and/or character set available via escape sequence. Of course people would say it's larger than what we have, harder to use, would take a huge effort to convert existing messages... and that's all true. But as you said, the Chinese is probably more germane than colors. Think about it, kernel messages in Gaelic or even rap lyrics "Hate to tell you, it must be said, I can't boot your disk be dead." Or Latin, CRDOS had some comments in Latin and one PhD who thought his code was best described in BNF. To be serious, a notifier to a user program, *after boot*, would allow all this flexibility, although I still think it's too late to change. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
Oleg Verych wrote: Hallo, Ingo. On Sun, Oct 07, 2007 at 08:07:07AM +0200, Ingo Molnar wrote: To clarify. `Scrollback' here is *useful* scrollback during early boot and OOPs (which is absent, AFAIK), "nothing like that" is coloring of the messages by loglevel. even if it were true (which it isnt), that is not an argument against including a useful change that exists now and that people are interested in. Coloring isn't useful. If it was, it would be implemented ~16 years ago. So anything that wasn't implemented a decade ago is not useful? Virtual machines, software raid, fair scheduling, jumbo packets, SMT/SMP/NUMA support, support for >4GB physical memory on x86, all fluff? (and yes, i have implemented kernel console improvements in the past and vga scrollback support was in fact amongst one of my first ever Linux kernel hacks so your comment is doubly wrong.) This `scrollback' is usual late boot / console one. If fact useful, until first tty switch or if `screen` cannot be used. But for some reason if scrolling region (DECSTBM) is less than whole screen, nothing works. And if width set to odd number of columns `stty columns $((80-1))` whole output becomes somewhat funny. I think by the time you get up enough to be running ill-advised commands from shell, you are past "early boot." Your comments about scrollback not working right if you break it are hopefully an attempt at humor. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: solved: 2.6.23 && fglrx && s2ram
Adrian Bunk wrote: On Fri, Oct 12, 2007 at 01:49:07AM +0200, Michael Leun wrote: On Fri, 12 Oct 2007 01:31:17 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: Hi, On Friday, 12 October 2007 00:07, Michael Leun wrote: Hello, (please, don't blame me for using the binary only driver, I will happily switch to a open source one once it properly runs mplayer, e.g.). Renaming the config options for suspend/sleep broke fglrx power management. It looks like your patch is against the fglrx driver, isn't it? It is - I should have mentioned that, sorry. This makes it 100% off-topic for linux-kernel - please send patches for illegal modules to the vendors of these modules and not here. Which would help the actual users of the module not one whit. Whereas putting the patch here helps the people who need it and allows multiple people to complain to the vendor. If this module violates some law you should report it to the appropriate authorities rather than posting it here, otherwise you should probably should not use the term illegal casually. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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.6.23
Ingo Molnar wrote: * Nick Piggin <[EMAIL PROTECTED]> wrote: ;) I think you snipped the important bit: "the peak is terrible but it has virtually no dropoff and performs better under load than the default 2.6.21 scheduler." (verbatim) hm, i understood that peak remark to be in reference to FreeBSD's scheduler (which the FreeBSD guys are primarily interested in obviously), not v2.6.21 - but i could be wrong. In any case, there is indeed a regression with sysbench and a low number of threads, and it's being fixed. The peak got improved visibly in sched-devel: http://people.redhat.com/mingo/misc/sysbench-sched-devel.jpg but there is still some peak regression left, i'm testing a patch for that. There's one important bit missing from that graph, the 2.6.23-SCHED_BATCH values. Without that we can't tell how much improvement is from sched-devel and how much from SCHED_BATCH. Clearly 2.6.23 is better than 2.6.22.any in this test, the locking issues seem to dominate that difference to the point that nothing else would be informative. This weekend I have to do some building of kernels for various machines, so I intend to run some builds SCHED_BATCH and some will just run. If I find anything interesting I'll report. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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 1/2] Colored kernel output (run3)
I tried something useful with this, see below.
Jan Engelhardt wrote:
On Oct 9 2007 07:12, Antonino A. Daplas wrote:
References: http://lkml.org/lkml/2007/4/1/162
http://lkml.org/lkml/2007/10/5/199
This is quite a long thread :-)
It was a patch series after all. But as Greg puts it, be persistent.
+config VT_PRINTK_COLOR
+ hex "Colored kernel message output"
+ range 0x00 0xFF
+ depends on VT_CKO
+ default 0x07
+ ---help---
+ This option defines with which color kernel messages will be
+ printed to the console.
+
+ The value you need to enter here is the value is composed
The more correct term for "The value" is probably "The attribute".
"The value for this kconfig entry" it should read in the minds.
+ (Foreground colors 0x08 to 0x0F do not work when a VGA
+ console font with 512 glyphs is used.)
You might have to include a warning that those values or attributes are
interpreted differently depending on the driver used, and the above is
mostly true for 16-color console drivers only.
Are there any other drivers besides vgacon and fbcon that use vt.c?
For 2-colors [...] With a 4-color fb console (4-level grayscale) [...]
With an 8-color console, only the first 8 values are considered.
With a 16-color console, that is also not consistent:[...]
I see. That probably means the explanation of values moves from Kconfig
to Documentation/. Somehow I think we could do without doc and let
interested starts find out for themselves and learn a little about
vgacon/fbcon. ;)
It probably means that the very clear explanations you shortened above
should go it a file in Documentation. Particularly with the feature to
have different levels of message different colors this allows monitoring
of machines even when you can't read the message from a distance. When
you see the magic color you can go look closer.
With vgacon, it supports 16-color foreground (fg), 8-color
background (bg) at 256 chars. Becomes 8 fg and 8 bg with 512 chars.
With fbcon, it supports 16 fg and 16 bg at 256, 16 fg and 8 bg at
512 chars.
And then there is fbiterm, which supports at least 16 fg/16 bg with ...
the whole Unicode set of chars. :)
And for drivers that have their own con_build_attr() hook, they will be
interpreted differently again.
+ Background:
+ 0x00 = black, 0x40 = blue,
+ 0x10 = red, 0x50 = magenta,
+ 0x20 = green, 0x60 = cyan,
+ 0x30 = brown, 0x70 = gray,
+
+ For example, 0x1F would yield white on red.
You may need to specify that the values here are the console default,
ie, the default_blue|grn|red boot options are not filled up.
+static inline void vc_set_color(struct vc_data *vc, unsigned char color)
+{
+ vc->vc_color = color_table[color & 0xF] |
+ (color_table[(color >> 4) & 0x7] << 4) |
+ (color & 0x80);
You may want to leave out the blink attribute (0x80) from this part.
Otherwise setterm -blink on|off will produce the opposite effect.
But 0x80 might be interpreted in a different fashion for some othercon,
yielding for example superbold rather than blinking.
I'll have to try this, because usually, setterm operates on TTYs
rather than VCs.
I tried something here, I have a monitor page on my window manager with
lots of xterms opened to machines like DNS, HTTP, mail and NNTP servers.
I use 100x25 xterms, with font size default. So just for fun I put a one
line message on one in green on black (instead of black on white) and
sized them all down to "unreadable" (cntl-right click menu) and I could
clearly tell which one had the message even on the postage stamps.
Then I tried white on red, white on blue, and white on green. Those
messages made the tiny xterm stand out as well. So I think it's a true
statement that using colors to make important stuff stand out is
something which in practice would be useful. Obviously if you use the
"unreadable" font you can't read it, but that one xterm can be resized
to a sane font to actually use it.
This isn't any dumber that Fedora printing the boot status of anything
which fails in red, that may be "damned by faint praise" of course.
--
Bill Davidsen <[EMAIL PROTECTED]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
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] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Serge E. Hallyn wrote: (tongue-in-cheek) No no, everyone knows you don't build simpler things on top of more complicated ones, you go the other way around. So what he was suggesting was that selinux be re-written on top of smack. Having gone from proposing a simpler and easier to use security system as an alternative to SELinux, you now propose to change the one working security system we have. And yes, it's hard to use, but it works. Let's keep this a patch, people who want adventure can have one, and people who have gotten Linux accepted "if SELinux is enabled" will avoid one. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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] Cute feature: colored printk output
Jan Engelhardt wrote: On Oct 6 2007 15:53, Bill Davidsen wrote: Jan Engelhardt wrote: Colored kernel message output Let's work more on Linux's cuteness! [http://lkml.org/lkml/2007/10/4/431] The following patch makes it possible to give kernel messages a selectable color which helps to distinguish it from other noise, such as boot messages. NetBSD has it, OpenBSD has it, FreeBSD to some extent, so I think Linux should too. Inspired by cko (http://freshmeat.net/p/cko/), but independently written, later contributed forth and back. I like it, although having a boot option would be nice (I have a friend with color perception issues). sysfs attributes can be set at boot time (and not only that). Here, try the "davej's salad" configuration :-) vt.default_red=0,192,128,170,0,170 vt.default_grn=0,0,170,128,64,0 vt.default_blu=0,0,0,0,128,128 vt.printk_color=1,1,1,1,5,3,2 I start my root xterm in white on blue for identification, so color coding sounds like a great idea to me. This has nothing to do with xterms, this is "VGA color console" only. xterm config is in /usr/share/X11/app-defaults/XTerm-color. Try reparsing that... I said I use color coding in root xterm, so I am generally in favor of the color coding concept to make important messages obvious. Is that clearer? -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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] Cute feature: colored printk output
Jan Engelhardt wrote: Colored kernel message output Let's work more on Linux's cuteness! [http://lkml.org/lkml/2007/10/4/431] The following patch makes it possible to give kernel messages a selectable color which helps to distinguish it from other noise, such as boot messages. NetBSD has it, OpenBSD has it, FreeBSD to some extent, so I think Linux should too. Inspired by cko (http://freshmeat.net/p/cko/), but independently written, later contributed forth and back. I like it, although having a boot option would be nice (I have a friend with color perception issues). I start my root xterm in white on blue for identification, so color coding sounds like a great idea to me. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: [code] Unlimited partitions, a try
H. Peter Anvin wrote: Alan Cox wrote: On Fri, 05 Oct 2007 15:11:52 -0700 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: Jan Engelhardt wrote: 15 partitions (at least for sd_mod devices) are too few. Now when we have 20-bit minors, can't we simply recycle some of the higher bits for additional partitions, across the board? 63 partitions seem to have been sufficient; at least I haven't heard anyone complain about that for 15 years. This was proposed ages ago. Al Viro vetoed sparse minors and it has been stuck this way ever since. If you have > 15 partitions use device mapper for it. I'd prefer it fixed but its arguable that device mapper is the right way to punt all our partitioning to userspace Sure. However, that takes having that bit of userspace in even the most trivial configurations, and not just on bootup, but continuously. I'm not sure that configurations requiring more than 15 partitions are properly described as "trivial." Which is not to disagree with your point about required user tools, but most systems needing such tools will be large and complex enough that a userspace solution will be acceptable. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Kyle Moffett wrote: On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote: What we want from the LSM is the ability to say -EPERM when we can clearly articulate that we want to disallow something. This sort of depends on perspective; typically with security infrastructure you actually want "... the ability to return success when we can clearly articulate that we want to *ALLOW* something". File permissions work this way; we don't have a list of forbidden users attached to each file, we have an owner, a group, and a mode representing positive permissions. With that said in certain high-risk environments you need something even stronger that cannot be changed by the "owner" of the file, if we don't entirely trust them, Other than ACLs, of course, which do allow blacklisting individual users. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: [13/18] x86_64: Allow fallback for the stack
Rik van Riel wrote: On Thu, 4 Oct 2007 12:20:50 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> wrote: On Thu, 4 Oct 2007, Andi Kleen wrote: We've known for ages that it is possible. But it has been always so rare that it was ignored. Well we can now address the rarity. That is the whole point of the patchset. Introducing complexity to fight a very rare problem with a good fallback (refusing to fork more tasks, as well as lumpy reclaim) somehow does not seem like a good tradeoff. Is there any evidence this is more common now than it used to be? It will be more common if the stack size is increased beyond 8k. Why would we want to do such a thing? 8kB stacks are large enough... Why would anyone need more than 640k... In addition to NUMA, who can tell what some future hardware might do, given that the size of memory is expanding as if it were covered in Moore's Law. As memory sizes increase someone will bump the page size again. Better to Let people make it as large as they feel they need and warn at build time performance may suck. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES
Mathieu Chouquet-Stringer wrote: Hey there, I've seen the changes you made in commit b6a2fea39318 and I guess they might be responsible for my xargs breakage... In the kernel source tree, if I run a stupid find | xargs ls, I now get this: xargs: ls: Argument list too long Which is kind of annoying but I can work around it though make distclean in my kernel tree dies with the same symptom (aka -E2BIG). You can work around it many ways, using the options provided for xargs or using ls directly being among them. find . -ls I don't see it with 2.6.23-rc8-git3 so it may be related to xargs version as well, I have 4.2.27 in FC6. I run a vanilla 2.6.23-rc9 (Linux version 2.6.23-rc9 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-27)) #1 Tue Oct 2 08:13:47 EDT 2007) on FC7... Let me know if I can do anything. I'm going to try to bisect the problem after I recompile the kernel without this patch... Best, Mathieu [EMAIL PROTECTED] (Linus Torvalds) writes: I said I was hoping that -rc8 was the last -rc, and I hate doing this, but we've had more changes since -rc8 than we had in -rc8. And while most of them are pretty trivial, I really couldn't face doing a 2.6.23 release and take the risk of some really stupid brown-paper-bag thing. [...] -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: [RFC/PATCH -v2] Add sysfs control to modify a user's cpu share
Heiko Carstens wrote: Changelog since v1: 1. Added a mutex to serialize directory creation/destruction for a user in sysfs 2. Added a spinlock in the task_group structure to serialize writes to tg->shares. 3. Removed /proc/root_user_cpu_shares. 4. Added Documentation about the group scheduler. thanks - I have added this to the queue. i'm wondering about the following: could not (yet) existing UIDs be made configurable too? I.e. if i do this in a bootup script: echo 2048 > /sys/kernel/uids/500/cpu_share this should just work too, regardless of there not being any UID 500 tasks yet. Likewise, once configured, the /sys/kernel/uids/* directories (with the settings in them) should probably not go away either. Shouldn't that be done via uevents? E.g. UID x gets added to the sysfs tree, generates a uevent and a script then figures out the cpu_share and sets it. That way you also don't need to keep the directories. No? That sounds complex administratively. It means that instead of setting a higher or lower than default once and having it persist until reboot I have to create a script, which *will* in some cases be left in place even after the need has gone. I agree with Ingo, once it's done it should be persistent. And as another administrative convenience I can look at that set of values and see what shares are being used, even when the user is not currently active. Final question, how do setuid processes map into this implementation? -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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] sky2: jumbo frame regression fix
Ian Kumlien wrote: On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote: Remove unneeded check that caused problems with jumbo frame sizes. The check was recently added and is wrong. When using jumbo frames the sky2 driver does fragmentation, so rx_data_size is less than mtu. Confirmed working. Now running with 9k mtu with no errors, =) Have you verified that you are actually getting jumbo packets out of the NIC? I had one machine which did standard packets silently using sky2 and jumbo using sk98lin. I was looking for something else with tcpdump and got one of those WTF moments when I saw all the tiny packets. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: shutdown -h now, 2.6.23-rc8 & 9
Gene Heskett wrote: On Tuesday 02 October 2007, Bill Davidsen wrote: Gene Heskett wrote: Indeed it went to the system halted message and just sat there. I hadn't yet booted to rc9 as amanda was running, so I did just a few minutes ago. After the reboot to rc9, I ran a make xconfig again to check that the option was enabled, but it seems to have disappeared from the menus in xconfig. Why was this removed? Or if moved, where to? What? Was what removed? This phrase has not existed in any .config newer than 2.6.23-rc1 here: CONFIG_APM_REAL_MODE_POWER_OFF=y Yes, it's still there as of 23-rc8-git5, the latest source I've built on this machine. If you start menuconfig and search for the value, (I used "/APM") you will see that it now depends on various other options. I haven't personally needed it in a long time, but there are ACPI implementations which are seriously broken. And probably some embedded hardware and/or hand-held devices now. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Linus Torvalds wrote: On Tue, 2 Oct 2007, Bill Davidsen wrote: And yet you can make the exact same case for schedulers as security, you can quantify the behavior, but if your only choice is A it doesn't help to know that B is better. You snipped a key part of the argument. Namely: Another difference is that when it comes to schedulers, I feel like I actually can make an informed decision. Which means that I'm perfectly happy to just make that decision, and take the flak that I get for it. And I do (both decide, and get flak). That's my job. which you seem to not have read or understood (neither did apparently anybody on slashdot). Actually I had quoted that, made a reply, and decided that my reply was too close to a flame and deleted the quote and the nasty reply, because I couldn't find a nice way to say what I wanted. Oh well, I tried to keep to a higher level, but... on this topic you seem to be off on an ego trip. You are not the decider, George Bush is the decider, and the only time he's not wrong he didn't understand the question. I checked the schedule, it's not you week to be God. There are sensible people you respect on other topics, who have the opinion that there is room for behaviors other than CFS, and who have created a pluggable scheduler framework which they are trying to hand you on a platter. And you won't even consider that they might be right, because you believe there can be one scheduler which is close to optimal for all loads. You say "performance" as if it had universal meaning. Blah. Bogus and pointless argument removed. When it comes to schedulers, "performance" *is* pretty damn well-defined, and has effectively universal meaning. The arguments that "servers" have a different profile than "desktop" is pure and utter garbage, and is perpetuated by people who don't know what they are talking about. The whole notion of "server" and "desktop" scheduling being different is nothing but crap. Unfortunately not so, I've been looking at schedulers since MULTICS, and desktops since the 70s (MP/M), and networked servers since I was the ARPAnet technical administrator at GE's Corporate R&D Center. And on desktops response is (and should be king), while on a server, like nntp or mail, I will happily go from 1ms to 10sec for a message to pass through the system if only I can pass 30% more messages per hour, because in virtually all cases transit time in that range is not an issue. Same thing for DNS, LDAP, etc, only smaller time range. If my goal is <10ms, I will not sacrifice capacity to do it. I don't know who came up with it, or why people continue to feed the insane ideas. Why do people think that servers don't care about latency? Because people who run servers for a living, and have to live with limited hardware capacity realize that latency isn't the only issue to be addressed, and that the policy for degradation of latency vs. throughput may be very different on one server than another or a desktop. Why do people believe that desktop doesn't have multiple processors or through-put intensive loads? Why are people continuing this *idiotic* scheduler discussion? Because people can't get you to understand that one size doesn't fit all (and I doubt I've broken through). Really - not only is the whole "desktop scheduler" argument totally bogus to begin with (and only brought up by people who either don't know anything about it, or who just want to argue, regardless of whether the argumen is valid or not), quite frankly, when you say that it's the "same issue" as with security models, you're simply FULL OF SH*T. The real issue is that you can't imagine that people who don't share your opinion are not only wrong but don't understand the problem. You may be right, but when you say anyone who disagrees is wrong by definition, then you have lost sight of productive technical differences. When your arguments drop to personal attacks and rants it's time to look at your technical values. The issue with LSM is that security people simply cannot even agree on the model. It has nothing to do with performance. It's about management, and it's about totally different models. Have you even *looked* at the differences between AppArmor and SELinux? Did you look at SMACK? They are all done by people who are interested in security, but have totally different notions of what "security" even *IS*ALL*ABOUT. Exactly, and I'm not the only one who doubts that more than one model would be useful. I'm sorry you can't see that about CPU schedulers as well. In contrast, anybody who claims that the CPU scheduler doesn't know what it's all about is jus
Re: One process with multiple user ids.
Giuliano Gagliardi wrote: Hello, I have a server that has to switch to different user ids, but because it does other complex things, I would rather not have it run as root. I only need the server to be able to switch to certain pre-defined user ids. I have seen that two possible solutions have already been suggested here on the LKML, but it was some years ago, and nothing like it has been implemented. (1) Having supplementary user ids like there are supplementary group ids and system calls getuids() and setuids() that work like getgroups() and setgroups() (2) Allowing processes to pass user and group ids via sockets. Both (1) and (2) would solve my problem. Now my question is whether there are any fundamental flaws with (1) or (2), or whether the right way to solve my problem is another one. Changing to a limited set of IDs is interesting, I have never looked at what happens when a thread does setuid, and neither the man page or a very quick look at the code tells me. But the portable way is to do the things needed for init, then fork into three processes and give each a UID as needed. I would really evaluate the design which made this necessary, to see if some IPC could be used. Certainly that's more likely to be portable. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: shutdown -h now, 2.6.23-rc8 & 9
Gene Heskett wrote: Greetings everybody; After seeing a message indicating that rc8 no longer did a powerdown, I thought I'd check that since I needed to, my tv card wasn't even showing up in the lspci report. It was partially backed out of the pci slot, this case seems to encourage that. I have rc8-git3 running on several machines, and I'm delighted to say that it powers down, reboots, and suspends to mem/disk without bothering to patch in suspend2. I saw the same message, but perhaps git3 had the fix, since machines go down correctly. I'm going to boot a laptop off CD and try the rc9 on that to see if the wireless issues I had to patch around are fixed as promised. If so I'll go to the newest kernel for power saving. Indeed it went to the system halted message and just sat there. I hadn't yet booted to rc9 as amanda was running, so I did just a few minutes ago. After the reboot to rc9, I ran a make xconfig again to check that the option was enabled, but it seems to have disappeared from the menus in xconfig. Why was this removed? Or if moved, where to? What? Was what removed? -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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.6.23-rc9 and a heads-up for the 2.6.24 series..
John Stoffel wrote: Linus> I said I was hoping that -rc8 was the last -rc, and I hate Linus> doing this, but we've had more changes since -rc8 than we had Linus> in -rc8. And while most of them are pretty trivial, I really Linus> couldn't face doing a 2.6.23 release and take the risk of some Linus> really stupid brown-paper-bag thing. Linus> So there's a final -rc out there, and right now my plan is to Linus> make this series really short, and release 2.6.23 in a few Linus> days. So please do give it a last good testing, and holler Linus> about any issues you find! Just to let people know, I was running 2.6.23-rc for over 53 days without any issues. Mix of SCSI, Sata, tape drives, disks, MD, LVM, SMP, etc. I suspect we've got a pretty darn stable release coming out soon. I've been running rc8-git3 since it came out, and while I've built git-5 and will build rc9, I probably will continue testing until I find a bug or have to boot for some other reason. Running really well, even with a lot of kvm stuff going on, kernel builds for other machines, etc. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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.6.23-rc9 and a heads-up for the 2.6.24 series..
Mel Gorman wrote: On (02/10/07 14:15), Ingo Molnar didst pronounce: * Mel Gorman <[EMAIL PROTECTED]> wrote: Dirt. Booting with "profile=sleep,2" is broken in 2.6.23-rc9 and 2.6.23-rc8 but working in 2.6.22. I was checking it out as part of a discussion in another thread and noticed it broken in -mm as well (2.6.23-rc8-mm2). Bisect is in progress but suggestions as to the prime candidates are welcome or preferably, pointing out that I'm an idiot because I missed twiddling some config change. Mel, does the patch below fix this bug for you? (Note: you will need to enable CONFIG_SCHEDSTATS=y too.) Nice one Ingo - got it first try. The problem commit was dd41f596cda0d7d6e4a8b139ffdfabcefdd46528 and it's clear that the code removed in this commit is put back by this latest patch. When applied, profile=sleep works as long as CONFIG_SCHEDSTAT is set. And if it isn't set? I can easily see building a new kernel with stats off and forgetting to change the boot options. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Linus Torvalds wrote: On Mon, 1 Oct 2007, Stephen Smalley wrote: You argued against pluggable schedulers, right? Why is security different? Schedulers can be objectively tested. There's this thing called "performance", that can generally be quantified on a load basis. Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers. And yet you can make the exact same case for schedulers as security, you can quantify the behavior, but if your only choice is A it doesn't help to know that B is better. You say "performance" as if it had universal meaning. In truth people want to optimize for total tps (servers), or responsiveness on the human scale (mail, dns, nntp servers), or perceived smoothness (with many threads updating a display to slow with load rather than start visibly jumping the motion from one to another), or very short term response (-rt patches). People want very different behavior under the same load, and that is what *they* call "performance," namely best delivery of what's important. The numbers are "hard science" but the choice of which numbers are important is still "people wanking around with their opinions". -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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] Patches for tiny 386 kernels, again. Linux kernel 2.6.22.7
Lennart Sorensen wrote: On Fri, Sep 28, 2007 at 05:24:20PM -0400, Bill Davidsen wrote: I'll offer this suggestion, knowing it may piss you off, given the difficulty of preserving whitespace on *many* mailers without using attachments, and given that attachments can be saved easily without prying them out of the message, why don't you (one person) switch to a capable mail agent, if only for patches, instead of trying to teach many people to jump through hoops to avoid whitespace issues? Not criticizing, just seems easier for everybody for you to avoid teaching people things they don't find useful elsewhere, or getting discouraged and not bothering. Ehm, so you want people to save the patch, then when replying they should load the patch into their (much better) mail client where they can comment on the patch? That is the reason the patch should be inline. People need to comment on it just as they would comment on any other plain text email. And in a perfect world everyone would have a mail client which made that easy, no one would be force by company policy or other circumstances to use a client which didn't work the way you think it should, no company or ISP would filter and mangle outgoing mail, and all vendors would understand that pristine patches are more important that all that stuff they do to make business communications look reasonable. In my world people send me attachments so they don't get mangled, and if I need to quote them I know how to do so. Well that and some people use git to import patches from the email in a mostly automated way which also expects them to have the info at top with signed-off and then the patch, which attachments also screw up. So yes there are good reasons for getting a non broken mail client when sending patches to lkml. And reading them, many show attached text at the end of the message and make turning it into inline text simple. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
Matthew wrote: Hi Ingo & everbody on the list, first of all: many thanks for developing this great scheduler (also: kudos to Con Kolivas for having developed SD & CK-patchset) (this is my second mail to this list and I hope I'm doing everything right) I'm doing some backup during work right now: rsyncing my home partition (nearly 180 GB) to another harddrive locally & since I'm running compiz-fusion, openoffice and gnome, therefore am in some real "working environment" I thought: give Ingo's new scheduler a test-ride during heavy load ;) first some impressions: cpu load balancing looks great again (pretty symmetrical loading on both cores - it looks pretty similar to 19.1 if not better if I recall right), v20 wasn't that "good-looking" ;) (with gnome-system-monitor) both cpus have a continous load of ~ 70% right now so I'll be starting up 9 instances of glxgears, below are some output & details of my system (cpu frequency switching is disabled since it doesn't work right now with the current bios version) short summary: unfortunately after starting glxgears everything stuttered a lot, don't know if it's expactable during that heavy load - just wanted to let you know; after having closed each instance of glxgears, everything was fine again ... cat /proc/sched_debug Sched Debug Version: v0.05-v22, 2.6.23-rc8-cfs-v22 #1 now at 3890590.670323 msecs .sysctl_sched_latency: 20.00 .sysctl_sched_nr_latency : 0.20 .sysctl_sched_wakeup_granularity : 2.00 .sysctl_sched_batch_wakeup_granularity : 25.00 .sysctl_sched_child_runs_first : 0.01 .sysctl_sched_features : 3 Try setting features to 14. That helps my similar issues. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: regression in 2.6.23-rc8 - power off failed
Alexey Starikovskiy wrote:
-static void
-acpi_power_off (void)
-{
- printk("%s called\n",__FUNCTION__);
- /* Some SMP machines only can poweroff in boot CPU */
- set_cpus_allowed(current, cpumask_of_cpu(0));
ACPI in kernel 2.6.12 did disable non-boot cpus too in powe_off.
Later only comment was left for some reason...
Am I midreading that code, or does it really assume that the boot cpu is
always zero? Or just that zero will be able to do the power off?
In any case I have had an SMP machine which did not have a CPU zero, and
it was discussed here, I believe. Wonder what happens if you set
affinity to a CPU you don't have...
--
Bill Davidsen <[EMAIL PROTECTED]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
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/
[FYI] 2.6.23-rc8-git3 misc observations
Running FC6 (updated this am) the temp sensors GNOME applet works with the kernel.org kernel, not the FC6 kernel. This has been true for a while, and I've stopped chasing it, I don't really care right now, since the sensors command works fine and that's what my daemon checks. Using 2.6.23-rc8 (no git) the NIC came up at 100Mbit instead of gigE once, not reproducible. Just in case this kicks off a bunch of "mee too" replies. lspci info follows text. Boot times: I occasionally boot repeatedly for various tests, these are the fastest of three (or more) boots of a given kernel, ID is what uname gives. 2.6.21-sd04655.29 2.6.21-cfs-v6 55.93 2.6.20-1.2944.fc6 64.71 2.6.23-rc8-git3 65.06 2.6.22.7-57.fc6 69.02 lspci: 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller Subsystem: ASUSTeK Computer Inc. Unknown device 81c2 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- R- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 223 Region 0: Memory at cffe (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at d800 [size=32] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+ Address: fee0200c Data: 41d1 Capabilities: [e0] Express Endpoint IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <512ns, L1 <64us Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM unknown, Port 0 Link: Latency L0s <128ns, L1 <64us Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number De-LE-TE-D -- Bill Davidsen He was a full-time professional cat, not some moonlighting ferret or weasel. He knew about these 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/
2.6.23-rc8 - Hangcheck on resume from x2mem
I find this in dmesg after resume from s2mem: Hangcheck: hangcheck value past margin! System: ASUS P5LD2-VM board, Intel 6600 CPU at 2.40 GHz (no o/c) 2GB RAM, 3x320GB SATA sw RAID-5. FC6 distribution, fully updated, suspend via "system" menu pulldown. Just in case this is of interest, the resume and suspend work without suspend2 patching, although since it's a server and has mains power it's only of interest for testing. USB backup devices were *not* connected. -- Bill Davidsen He was a full-time professional cat, not some moonlighting ferret or weasel. He knew about these 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: [patch 0/2] suspend/resume regression fixes
Mark Lord wrote: Linus Torvalds wrote: On Sat, 22 Sep 2007, Thomas Gleixner wrote: My final enlightment was, when I removed the ACPI processor module, which controls the lower idle C-states, right before resume; this worked fine all the time even without all the workaround hacks. I really hope that this two patches finally set an end to the "jinxed VAIO heisenbug series", which started when we removed the periodic tick with the clockevents/dyntick patches. Ok, so the patches look fine, but I somehow have this slight feeling that you gave up a bit too soon on the "*why* does this happen?" question. On a closely related note: I just now submitted a patch to fix SMP-poweroff, by having it do disable_nonboot_cpus before doing poweroff. Which has led me to thinking.. ..are similar precautions perhaps necessary for *all* ACPI BIOS calls? Because one never knows what the other CPUs are doing at the same time, and what the side effects may be on the ACPI BIOS functions. And also, I wonder if at a minimum we should be guaranteeing ACPI BIOS calls only ever happen from CPU#0 (or the "boot" CPU)? Or do we do that already? Boot CPU, and AFAIK suspend is the only place which does it. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: PROBLEM: Network sky2 Module, kernel version 2.6.23-rc7
ben soo wrote: i spoke too soon. The Gbit interface still dies. Lasted around 19hrs. or so. i can't tell if there are hardware issues: yesterday a Gbit NIC on the firewall died. Different chip (Realtek), different driver, different machine, same segment. Segment is a mix of 100Mbit and 1Gbit machines. Symptoms of the failure are it just stops functioning with no error messages. ifconfig says there are packets being TX'd and none being RX'd. Interface can't be brought up again. If you search through my exchanges with Adrian Bunk WRT sk98lin removal, I mentioned a very similar problem. When I wrote that I had some notes in front of me, which are now archived and not quickly available. unloading and reloading the modules didn't fix it, IIRC. I will be doing an update on the machine in question by the end of the year, and at that time I will try shy2 again, since I'll be able to do better testing. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: [git] CFS-devel, latest code
Ingo Molnar wrote: Maybe there's more to come: if we can get CONFIG_FAIR_USER_SCHED to work properly then your Xorg will have a load-independent 50% of CPU time all to itself. It seems that perhaps that 50% makes more sense on a single/dual CPU system than on a more robust one, such as a four way dual core Xeon with HT or some such. With hotplug CPUs, and setups on various machines, perhaps some resource limit independent of the available resource would be useful. Just throwing out the idea, in case it lands on fertile ground. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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] Patches for tiny 386 kernels, again. Linux kernel 2.6.22.7
Randy Dunlap wrote: This seems reasonable, so I tried to use it. Here are the results and comments and meta-comments. 1. Please forcibly wrap text lines in mail body at around column 70-72. 2. Put patches inline in the mail body, not as attachments. I'll offer this suggestion, knowing it may piss you off, given the difficulty of preserving whitespace on *many* mailers without using attachments, and given that attachments can be saved easily without prying them out of the message, why don't you (one person) switch to a capable mail agent, if only for patches, instead of trying to teach many people to jump through hoops to avoid whitespace issues? Not criticizing, just seems easier for everybody for you to avoid teaching people things they don't find useful elsewhere, or getting discouraged and not bothering. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: USB autosuspend and turning of usb pendrive leds
Hans de Goede wrote: Hi All, Please keep me CC-ed as I'm not subscribed. Some time ago a mail about turning of the leds on usb pendrives once unmounted by hal was send to the fedora-devel list: https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01807.html This mail talked about echo 2 > power/state for usb devices. I tested the method described in the mail to turn of the drive light and it worked well. As I think that turning of the drive led (as windows does) would be good visual feedback to the end user that its safe to remove the device I've written a patch for hal which does the power state change automatically when the last partition of a usb massstorage device gets unmounted. However when testing the patch I found out that my now newer kernel no longer has power/state for usb devices, it only has power/level. I can send suspend to power/level, but then remounting the device won't work and me syslog fills itself with: sd 2:0:0:0: [sdc] READ CAPACITY failed sd 2:0:0:0: [sdc] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK sd 2:0:0:0: [sdc] Sense not available. sd 2:0:0:0: [sdc] Write Protect is off sd 2:0:0:0: [sdc] Mode Sense: 00 00 00 00 sd 2:0:0:0: [sdc] Assuming drive cache: write through Because hal keeps polling the device. What did power/state do, and can that capability be easily recovered? Being able to turn off the lights is desirable, but it may be that standby is the only way to do that, with all the issue already discussed in this thread. But if there's another way, it would be useful. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: fpu IO port reservation (arch/i386)
Andi Kleen wrote: "Maciej W. Rozycki" <[EMAIL PROTECTED]> writes: Hi Peter, Does anybody know why we reserve this range of IO ports for 'fpu'? AFAIK from all the IO maps I can find on the internet for various x86 chipsets only 0x00f0 is actaully ever used. There are two ports used: 0xf0 is the busy latch reset and 0xf1 is the coprocessor reset. They are legacy ports resulting from the interesting way the FPU has been wired by IBM in their PC design. Was it really needed on 386s? I didn't think there was a IBM 386 PC. There were 386 PC clones for sure, and they almost certainly needed it and still do. IBM was doing the MCA thing at that time and it was a wonderful time for the clone makers. None of them is used by Linux for i486 and newer systems, which can support the FPU in its native configuration. I can remove it from x86-64 at least. AFAIK you are just right, I'm pretty sure there will be systems needing it for 386 and 486, and maybe the old Pentium systems as well. A lot of system vendors wanted it so software for the old systems would still work. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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: sys_chroot+sys_fchdir Fix
Theodore Tso wrote: On Thu, Sep 27, 2007 at 09:28:08AM +0200, Christer Weinigel wrote: So the OpenBSD man page seems to be in the minority here. Any portable code can not assume that CWD changes. And changing the Linux behaviour now would be a rather big change which might break userspace. And yes, there are applications that rely on this, I've used it when building software for cross compiling. Changing Linux behavior would violate the POSIX and SuSV2 specifications; the standards explicitly state that the working directory will NOT change. And standards adherance is important; we break them only if we have a d*mn good reason. And trying to make chroot() something which it is not (i.e., a secure jail) is certainly not a good enough reason. Can we please end this thread now? And can we put in a Kernel FAQ saying that this is not something which is NOT up for discussion? It seems there are (at least) two parts to this, one regarding changing working directory which is clearly stated in the standards and must work as it does, and the various issues regarding getting out of the chroot after the cwd has entered that changed root. That second part seems to offer room for additional controls on getting out of the chroot which do not violate any of the obvious standards, and which therefore might be valid candidates for discussion on the basis of benefit rather than portability. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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 2.6.23-rc7 1/3] async_tx: usage documentation and developer notes
Dan Williams wrote: Signed-off-by: Dan Williams <[EMAIL PROTECTED]> --- Documentation/crypto/async-tx-api.txt | 217 + 1 files changed, 217 insertions(+), 0 deletions(-) diff --git a/Documentation/crypto/async-tx-api.txt b/Documentation/crypto/async-tx-api.txt new file mode 100644 index 000..48d685a --- /dev/null +++ b/Documentation/crypto/async-tx-api.txt @@ -0,0 +1,217 @@ +Asynchronous Transfers/Transforms API + +1 INTRODUCTION + +2 GENEALOGY + +3 USAGE +3.1 General format of the API +3.2 Supported operations +3.2 Descriptor management +3.3 When does the operation execute? +3.4 When does the operation complete? +3.5 Constraints +3.6 Example + This is very readable, and appears extensible to any new forthcoming technology I'm aware of. Great job! -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: [Announce] Linux-tiny project revival
Rob Landley wrote:
On Wednesday 19 September 2007 1:03:09 pm Tim Bird wrote:
Recently, the CE Linux forum has been working to revive the
Linux-tiny project. At OLS, I asked for interested parties
to volunteer to become the new maintainer for the Linux-tiny patchset.
A few candidates came forward, but eventually Michael Opdenacker
was selected as the new primary maintainer. A few other
people, including John Cooper of Wind River and myself
are working to support this effort.
Recently, many of the Linux-tiny patches have been brought up-to-date
and are now available for use with a 2.6.22 kernel. The intent
is to test these, and begin mainlining the most effective sub-patches,
in the next few months.
Cool!
Could you update http://www.selenic.com/linux-tiny/ to mention the new
maintainer and new URLs?
Some automated testing has already been set up, with some
preliminary results published at a CELF conference in Japan.
(See the linux-tiny page below for a link to the presentation.)
Hopefully, results publishing will also be automated soon.
We encourage anyone with interest in this project to get involved.
If you have ideas how to reduce the static or dynamic memory footprint
of Linux, or, even better, patches for this, please let us know about
them.
I've been playing with an idea for a while to improve the printk() situation,
but it's a more intrusive change than I've had time to bang on.
Right now, the first argument to printk() is a loglevel, but it's handled via
string concatenation. I'd like to change that to be an integer, and make it
an actual comma-separated first argument. (Mandatory, not optional.)
So instead of:
printk(KERN_NOTICE "Fruit=%d\n", banana);
It would now be:
printk(KERN_NOTICE, "Fruit=%d\n", banana);
Change the header from:
#define KERN_NOTICE "<5>"
to:
#define KERN_NOTICE 5
Then you can change the printk guts to do something vaguely like (untested):
#define printk(arg1, arg2, ...) actual_printk("<" #arg1 ">" arg2, __VA_ARGS__)
And so far no behavior has changed. But now the _fun_ part is, you can add a
config symbol for "what is the minimum loglevel I care about?" Set that as a
number from 0-9. And then you can define the printk to do:
#define printk(level, str, ...) \
do { \
if (level < CONFIG_PRINTK_DOICARE) \
actual_printk("<" #level ">" str, __VA_ARGS__); \
} while(0);
And viola (however you spell that, I think I'm using the stringed instrument
but it's french and I'm not trying to type a diacritical mark anyway), the
compiler's dead code eliminator zaps the printks you don't care about so they
don't bloat the kernel image. But this doesn't _completely_ eliminate
printks, so you can still get the panic() calls and such. You tweak precisly
how much bloat you want, using the granularity information that's already
there in the source code...
Opinions?
All the people who don't have the need will come up with reasons not to
do it. Like "saves too little" and "makes debugging hard" (these are the
people who don't realize that having no output device and human in the
loop makes it hard, too). How about "too complex, would confuse users,"
that's popular.
I could go into a list of thing people want to take out or keep out for
reasons which boil down to "I don't need it" or "leaving it out only
bothers lazy users who don't want to convert to {flavor_of_the_month}."
People with really small systems care about every few bytes, people with
big systems don't understand (in general) about people with small
systems. The best developers do, fortunately, and will probably approve
of kernel liposuction.
--
Bill Davidsen <[EMAIL PROTECTED]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
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: sys_chroot+sys_fchdir Fix
David Newall wrote: Philipp Marek wrote: AFAIK pivot_root() changes the / mapping for *all* processes, no? The manual page is confusing. It even admits to being "intentionally vague". However the goal seems clear: "pivot_root() moves the root file system of the current process to the directory put_old and makes new_root the new root file system of the current process" -- man 2 pivot_root There's an argument that pivot_root could be improved... And very little argument that the man page could be improved, perhaps. However, there is no question that pivot_root is intended to have breadth for more than one process. Keeping this functionality sounds a little like putting a bow tie and tux on your bug and calling it a "feature." Not all bugs are useless for legitimate purposes, but it doesn't make them safe. It appears to be a sort-of way to get per-process bind mounts. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: sys_chroot+sys_fchdir Fix
Alan Cox wrote: On Wed, 19 Sep 2007 09:19:50 +0200 majkls <[EMAIL PROTECTED]> wrote: Hello, here is an fix to an exploit (obtained somewhere in internet). This exploit can workaround chroot with CAP_SYS_CHROOT. It is also possible (with sufficient filedescriptor (if there is na directory fd opened in root) workaround chroot with sys_fchdir. This patch fixes it. If you have the ability to use chroot() you are root. If you are root you can walk happily out of any chroot by a thousand other means. I thought this was to prevent breaking out of chroot as a normal user. ie. chroot /var/myjail /bin/su - guest or similar. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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/
