Re: [PATCH] sysctl: Add a feature to drop caches selectively
On 26.06.2014 13:57, Luká? Czerner wrote: > > So if the authors want to sell this new interface (in whatever form) to > > the kernel community, they should start with providing a solid use-case, > > with some more details, explore alternatives and show how the > > alternatives do not work for them. > > Yes please, let's see some solid use-case for this. Personally i would want it to verify files after copying them: Especially while moving files: - Copy a file - - Verify that it really is correct on stable storage - Remove original file Currently i choose either of the 3 ways: - drop_caches - umount/mount - Write more data than memory in machine (Which is only an approximnation and you have to verify in the same order the files were written, so it is likely that any cache was thrashed in the meantime) But having a way to selectivly "destory" the cache of a file would make this task easier. -- Matthias -- 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: Partially Privileged Applications
On 11.11.2013 14:05, Shahbaz Youssefi wrote: > On Sun, Nov 10, 2013 at 8:06 PM, Matthias Schniedermeyer wrote: > > I don't see a way around "borders" (Papers please), otherwise you can't > > reject things you don't want, you have to check if that something that > > is to be done is allowed. For e.g. you would get around every > > permission-check, because the code you called is allowed to do > > everything. > > You're right actually. Proper linking solves the issue for "good people", > but I can't think of a not-dirty way for preventing bad calls from > "bad people". I may get back here if I do find a solution. After thinking a bit about this. It depends on the samantics of when the processor switches privileges. IF the processor only ever switches privileges for jmp/call/ret(...) you could place a privileged page with nothing but NOPs before the function that you actually want to call with elevated privileges, but whose page is NOT marked as privileged. You then call/jump to the last NOP and let the CPU "slide" over into the next page. This way you could be sure that the necessary check-part of the function can't be circumvented and still have the higher privileges. But then what about functions the function might have to call, they would need to be in a privileged page or you would need a "keep privileges, regardless of page attribute" jmp/call. In the case of that functions being in a privileged page, you would have to make sure that you can't call them directly as "bad people" would just do that. You would then need this kind auf NOP-Page before each function you want to be able to call, which wastes a certain amount of memory and also forces you to align each function to the beginning of a page (which also wastes memory). But what is a megabyte or so of wasted memory with gigabytes of memory. :-) But essentially it would still be similar to the mentioned call gates. All in all it still sounds like a nightmare to "get right". -- Matthias -- 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: [RFC][PATCH 4/3] vfs: Allow rmdir to remove mounts in all but the current mount namespace
On 06.10.2013 23:55, Eric W. Biederman wrote: > "Serge E. Hallyn" writes: > > So if we can feel safe just depending on the parent directory > permissions (which are not hidden by a mount) protecting our mount > points, I feel much better about this patchset. As far as i can tell, the permissions of the host-directory of a mount-point are hidden, at least for user-space. (Ignoring (bind-)mounting the parent-mount somewhere else) As root: $ mkdir /tmp/test $ ls -ld /tmp/test drwxr-xr-x 2 root root 40 Oct 8 12:33 /tmp/test $ mount tmpfs -t tmpfs /tmp/test $ ls -ld /tmp/test drwxrwxrwt 2 root root 40 Oct 8 12:33 /tmp/test $ chown nobody.users /tmp/test $ ls -ld /tmp/test drwxrwxrwt 2 nobody users 40 Oct 8 12:33 /tmp/test $ umount /tmp/test $ ls -ld /tmp/test drwxr-xr-x 2 root root 40 Oct 8 12:33 /tmp/test So if the kernel would check the host-directory-permissions for allowing umounting by rmdir it follows that a "plain user" doesn't have any possibility to know beforehand if rmdir/umount would be possible. -- Matthias -- 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/
Build-failure with old files in build-directory (Was: Linux 3.9 released)
On 28.04.2013 17:56, Linus Torvalds wrote: I'm not sure if it is supported, but building with a O= -directory that was previously used to build a 3.8.9-kernel that was "clean"ed (but not "mrproper"ed) before building 3.9 results in a build-failure: make[2]: *** No rule to make target `/xssd/usr_src/ko/leeloo/include/config/hz.h', needed by `kernel/hz.bc'. Stop. After deleting everything in the KBUILD_OUTPUT-directory, except the .config-file, the kernel-build worked again. At least in the past a "clean" seamed to be enough. I had a file with a 2.6.39-name inside, so it seams i have build my kernels this way for the last few releases. -- Matthias -- 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: [regression] external HDD in USB3 enclosure cannot be dynamically removed (Re: Linux 3.7.5)
On 13.02.2013 11:33, Sarah Sharp wrote: > On Wed, Feb 13, 2013 at 06:16:56PM +0100, Matthias Schniedermeyer wrote: > > On 13.02.2013 09:28, Holger Hoffstätte wrote: > > > On 12.02.2013 21:42, Sarah Sharp wrote: > > > > [..] > > > > There was a further set of patches queued for 3.9 to deal with connected > > > > devices going to the Inactive state, but they looked like they were too > > > > big for stable: > > > > > > > > d3b9d7a USB: Fix connected device switch to Inactive state. > > > > a24a607 USB: Rip out recursive call on warm port reset. > > > > 2d4fa94 USB: Prepare for refactoring by adding extra udev checks. > > > > 0fe51aa USB: Don't use EHCI port sempahore for USB 3.0 hubs. > > > > > > > > Can you retry with Greg's usb-next branch? > > > > > > > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git > > > > -b usb-next > > > > > > > > If that fixes your problem, we should either get those additional > > > > patches into 3.8 and the stable trees, or do a revert of the whole > > > > series and just let 3.9 carry the full patchset. > > > > > > Good news! This one does indeed work as expected - the device can be > > > removed and is gone for good. Upstream & Stable plz :) > > > > That kernel fixes the problem for me too. > > Great! > > Holger and Matthias, can you double check that cherry picking just those > four patches on top of 3.7.7 or 3.8 works as well? 3.7.7 + those 4 patches workes for me. As i'm not very firm in git i generated separate diffs for each commit and applying them in the order 2d4fa94 0fe51aa d3b9d7a a24a607 worked without hunks dropped. I have attached `git diff` against vanilla 3.7.7, so you can check that i got it right. -- Matthias combined.diff.gz Description: Binary data
Re: [regression] external HDD in USB3 enclosure cannot be dynamically removed (Re: Linux 3.7.5)
On 13.02.2013 09:28, Holger Hoffstätte wrote: > On 12.02.2013 21:42, Sarah Sharp wrote: > > [..] > > I think I see the issue. Your host controller reports the Inactive > > state after a USB disconnect. My host controllers go to the RxDetect > > state on a disconnect. > > > > The patches that went into 3.8 and the stable kernels to better handle > > the Inactive state were not designed to handle a connected device going > > to the Inactive state. I thought that would be a rare case, but > > apparently it's not. > > > > There was a further set of patches queued for 3.9 to deal with connected > > devices going to the Inactive state, but they looked like they were too > > big for stable: > > > > d3b9d7a USB: Fix connected device switch to Inactive state. > > a24a607 USB: Rip out recursive call on warm port reset. > > 2d4fa94 USB: Prepare for refactoring by adding extra udev checks. > > 0fe51aa USB: Don't use EHCI port sempahore for USB 3.0 hubs. > > > > Can you retry with Greg's usb-next branch? > > > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git -b > > usb-next > > > > If that fixes your problem, we should either get those additional > > patches into 3.8 and the stable trees, or do a revert of the whole > > series and just let 3.9 carry the full patchset. > > Good news! This one does indeed work as expected - the device can be > removed and is gone for good. Upstream & Stable plz :) That kernel fixes the problem for me too. -- Matthias -- 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: Linux 3.6
On 03.10.2012 13:05, Kees Cook wrote: > Hi Nick, > > 3.6 introduced link restrictions: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7 > > It sounds like you've got symlinks in a world-writable directory, and > you're following those symlinks across mis-matched uids. You can either > have the symlinks be owned by the directory owner, or you can turn off > symlink restrictions in sysctl: > > # echo 0 > /proc/sys/fs/protected_symlinks According to documentation world writable isn't the problem. It's world writable inside/or below a directory with sticky bit. (Documentation/sysctl/fs.txt -> protected_symlinks) So /scratch_space must have the sticky bit set. Question is: Why? Personally i would have been bitten by this change, because for years i have used a symlink in /tmp (which has the sticky bit) to a directory somewhere else for historical reasons. But as i was aware of this change i fixed my system before booting the new kernel. > On Wed, Oct 03, 2012 at 03:46:14PM -0400, Nick Bowler wrote: > > On 2012-09-30 17:38 -0700, Linus Torvalds wrote: > > > So here it is, 3.6 final. Sure, I'd have been happier with even fewer > > > changes, but that just never happens. And holding off the release > > > until people get too bored to send me the small stuff just makes the > > > next merge window more painful. > > > > Just upgraded to 3.6 from 3.5, and now some of my kernel build scripts > > are throwing "permission denied" errors. Apparently symlinks are > > broken somehow? > > > > # id > > uid=0(root) gid=0(root) > > groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) > > > > # ls -l /scratch_space/linux > > drwxr-xr-x 24 nbowler eng 4096 2012-10-03 13:41 /scratch_space/linux > > > > # readlink /scratch_space/linux-2.6 > > linux > > > > # cd /scratch_space/linux > > # pwd > > /scratch_space/linux > > > > # cd /scratch_space/linux-2.6 > > cd: permission denied: /scratch_space/linux-2.6 > > > > WTF? 3.5 is fine. I will try to bisect this later, but I figured I'd > > throw this out there now in case anyone has any ideas... Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- 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: The ext3 way of journalling
On 12.01.2008 18:10, TimC wrote: > Bodo Eggert <[EMAIL PROTECTED]> said on Sat, 12 Jan 2008 02:41:17 +0100 (CET): > > On Fri, 11 Jan 2008, Lennart Sorensen wrote: > > > On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote: > > > > > > What can happen if someone does tune2fs -Lroot /dev/usbstick > > > > and puts that stick into this system? > > > > > > Don't know. I use UUIDs rather than LABELs. Having duplicated labels > > > just means being careless. Having duplicate UUIDs should require being > > > malicous. > > > > That's exactly what you have to assume for your users. Otherwise, you could > > remove any security feature from the system. > > If they've got physical access to your machine, you've already lost. As a last resort there is always the option to encrypt everything. Of course you loose the LABEL & UUID support with that. But i circumvented that by a custom udev script and marking the MBR in the documented 4 bytes for an ID that is used by said script to create an appropriate symlink. Together with a matching autofs-conf i can still automatically mount all my >50 encrypted HDDs i have stacked on my shelf. :-) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- 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: The ext3 way of journalling
On 10.01.2008 12:30, Helge Hafting wrote: > Matthias Schniedermeyer wrote: >>>> Don't use udev then. Good old static dev works fine if you have a fixed >>>> set of devices. >>>> >>> It doesn't, with the unpredictable SCSI mapping insanity. >>> >> >> That what LABEL und UUID-Support in mount is for. >> >> You label the filesystems (e2label for ext2 and ext3) and use that label to >> mount them >> >> - fstab - >> LABEL=root /xfs defaults,noatime0 1 >> LABEL=boot /bootext2defaults,noatime0 2 >> > Would've been nice if they worked, but they don't. > > Disks should be so easy to identify uniquely, because they have > storage space that can be used for that label. > > So I tried (debian linux, last year). > > Mount by label was fine, of course. > Until the 33rd reboot, when it was decided that a > fsck was necessary "just to be safe". The problem was that fsck > fail to find the correct device when /etc/fstab specifies a label > instead of a device. The boot failed, reboot with init=/bin/sh > and replace the dysfunctional labels with oldfashioned device names. > > I can live with this kind of problem on my desktop, but this machine > was going to be a internet router for a customer, so occational > boot failure requiring intervention was not an option. As written by Theodore somewhere else in this thread support for labels in fsck came later, so maybe the fsck-version on your problematic-server was too old. Personally i never had a problem with labels and i use them for about 4-5 years now. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- 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: The ext3 way of journalling
On 09.01.2008 11:21, Matthias Schniedermeyer wrote: > On 09.01.2008 09:56, Tuomo Valkonen wrote: > > On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote: > > > That what LABEL und UUID-Support in mount is for. > > > > That's udev shit. I don't want it. > > No. To be more verbose. The 'LABEL=' is native mount turf and is much older than udev. That udev ALSO supports the same labels, by providing sym-links in /dev/disk/by-label/<...>, is written on another page. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- 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: The ext3 way of journalling
On 09.01.2008 09:56, Tuomo Valkonen wrote: > On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote: > > That what LABEL und UUID-Support in mount is for. > > That's udev shit. I don't want it. No. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- 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: The ext3 way of journalling
> > Don't use udev then. Good old static dev works fine if you have a fixed > > set of devices. > > It doesn't, with the unpredictable SCSI mapping insanity. That what LABEL und UUID-Support in mount is for. You label the filesystems (e2label for ext2 and ext3) and use that label to mount them - fstab - LABEL=root /xfs defaults,noatime 0 1 LABEL=boot /bootext2defaults,noatime 0 2 ... - snip - Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- 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 is deleting (or reading) files not counted as IO-Wait in top?
On 05.01.2008 01:31, Andrew Morton wrote: > On Wed, 2 Jan 2008 20:35:03 +0100 Matthias Schniedermeyer <[EMAIL PROTECTED]> > wrote: > > > Hi > > > > > > Currently i'm deleting about 500.000 files on a XFS-filesystem which > > takes a few minutes, as i had a top open i saw that 'wa' is shown as > > 0.0% (Nothing else running currently) and everything except 'id' is near > > the bottom too. Kernel is 2.6.23.11. > > > > So, as 'rm -rf' is essentially a IO (or seek, to be more correct)-bound > > task, shouldn't that count as "Waiting for IO"? > > > > The man-page of top says: > > 'Amount of time the CPU has been waiting for I/O to complete.' > > > > But AFAICT wa only seams to be (ac)counted for writing and not for > > reading. I come to that conclusion because, when i fire 'sync' i can see > > some percent wa for a few seconds. > > > > Yes, you would absolutely expect `rm' to be stuck in D state and > contributing to both load average and io-wait in this situation. > > I'd think that either XFS is playing games (and it'd take some pretty > inventive games to do this) or your observations are in error. I don't think that i could do much wrong(tm). rm -rf (Took >30 minutes to delete) Everything else was sleeping at the time. The sleeping processes are the usual handful of about 200 processes, you have laying around today. 47 kernel threads, another about 40 or so demons, and the rest >100 processes was my KDE-Session (mostly 'konsole's with bashes inside) with Iceweasel (Firefox) as sugar on top. But as i said, there weren't doing anything at all, 'us' peaked at about 1-1.4 when i watched top. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- 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 is deleting (or reading) files not counted as IO-Wait in top?
On 03.01.2008 02:16, Maxim Levitsky wrote: > On Wednesday, 2 January 2008 21:35:03 Matthias Schniedermeyer wrote: > > Hi > > > > > > Currently i'm deleting about 500.000 files on a XFS-filesystem which > > takes a few minutes, as i had a top open i saw that 'wa' is shown as > > 0.0% (Nothing else running currently) and everything except 'id' is near > > the bottom too. Kernel is 2.6.23.11. > > > > So, as 'rm -rf' is essentially a IO (or seek, to be more correct)-bound > > task, shouldn't that count as "Waiting for IO"? > > > > The man-page of top says: > > 'Amount of time the CPU has been waiting for I/O to complete.' > > > > But AFAICT wa only seams to be (ac)counted for writing and not for > > reading. I come to that conclusion because, when i fire 'sync' i can see > > some percent wa for a few seconds. > > The IOWAIT time is the IDLE time that was spent waiting > for I/O. (meaning that there were no tasks running, but some were waiting on > I/O) > > Thus if you have another task that is not I/O bound, it can run in that time, > and ideally, you shouldn't notice any I/O slowdown, but the iowait time will > decrease. > > It wasn't the case before CFS introduction. I did few tests that showed > almost 50% slowdown > when running another task in that iowait time. > It is not longer a problem with CFS. I can understand that, but in my case nothing else was running, so i would expect about 46%-50% wa (Dual Core Processor). Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- 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/
Why is deleting (or reading) files not counted as IO-Wait in top?
Hi Currently i'm deleting about 500.000 files on a XFS-filesystem which takes a few minutes, as i had a top open i saw that 'wa' is shown as 0.0% (Nothing else running currently) and everything except 'id' is near the bottom too. Kernel is 2.6.23.11. So, as 'rm -rf' is essentially a IO (or seek, to be more correct)-bound task, shouldn't that count as "Waiting for IO"? The man-page of top says: 'Amount of time the CPU has been waiting for I/O to complete.' But AFAICT wa only seams to be (ac)counted for writing and not for reading. I come to that conclusion because, when i fire 'sync' i can see some percent wa for a few seconds. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- 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: Strange Memory Corruption Problem with Core2Duo E6700, P965 Chipset MB and >=4GB RAM
On 16.12.2007 02:39, Matthias Schniedermeyer wrote: > Hi It appears i found my culprit. :-) I have a ISDN-controller which is driven by the HFC-PCI-driver and it appears to not be 64bit-safe. I will test more thorough after i have relocated the card to another computer. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- 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/
Strange Memory Corruption Problem with Core2Duo E6700, P965 Chipset MB and >=4GB RAM
Hi Yesterday i upgraded an 1 year old System from 4x1GB (32Bit, No Memory-Remap) to 4x2GB (64Bit, Memory-Remap) Today i due to a lucky coincidence i discovered that i have a memory corruption problem. This problem happens only with at least 4GB RAM and Memory-Remap. It happens with any 2 of the 4x2GB RAM-Modules and regardless of slot or dual or single channel configuration. After some trying i found a way to "catch" the error. I wrote a small perl script to fill a tmpfs with 1MB zero-files. Then i MD5 all the files and discard all with the MD5-sum of a 1MB zero-file. Here is what hexdump says about the file-content of the "bad"-file when it is called several times. :/misc/badram> hexdump bad 000 * 00d50a0 84cf 1fff fd0f 00d50b0 * 00d90a0 161f 1fff 43ff 00d90b0 00d90c0 0001 00d90d0 * 010 :/misc/badram> hexdump bad 000 * 00d50a0 84cf 1fff fd0f 00d50b0 * 00d90a0 e59d 1fff 43bf 00d90b0 00d90c0 0001 00d90d0 * 010 :/misc/badram> hexdump bad 000 * 00d50a0 84cf 1fff fd0f 00d50b0 * 00d90a0 f7fb 1fff 43ff 00d90b0 00d90c0 0001 00d90d0 * 010 :/misc/badram> hexdump bad 000 * 00d50a0 84cf 1fff ff03 00d50b0 * 00d90a0 df3b 1fff 43ff 00d90b0 00d90c0 0001 00d90d0 * 010 Strange is that some parts are static and other parts change. Kernel is 2.6.23.11. Kernel is 64Bit/x86-64, Userspace is 32bit. I only need the RAM for a huge ramdisk, so i don't need 64bit userspace. Can anybody help me with this problem? Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- 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: [poll] Is the megafreeze development model broken?
On 12.11.2007 17:18, Tuomo Valkonen wrote:
> On 2007-11-12, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > Geeks like you and me want the latest software
> > (I'm using Debian unstable/testing).
> >
> > But most users want a Linux installation that simply works - and this
> > includes all software on the system at all times.
>
> I'm not in either category. I want a truly stable (as in "quality", not
> as in "static" as the distros use the term) base system that simply
> works, but I want to follow certain interesting software more closely.
That's the problem(tm).
Contrary to Closed Source Software all(!) OSS-Software is
interdependent. There is no "Stand-Alone"-Software. There is always at
least "libc". (Scripts depend on a script-interpreter, which in turn
depends at least on libc, so there is nothing(tm) that doesn't depend on
libc)
Where is not uncommon for Closed Source Software to not have external
dependencies or to bring along it's dependent librarys.
e.g. (On Debian sid, *)
"kdebase" has a nice little total dependency-list of only 254 packages.
or
"openoffice.org" just 265 dependent packages.
"gimp" comes with light backage, only 146 packages.
Not to speak about such nice little (meta-)packages like "kde" or
"gnome" that are 649 and 684 packages.
All that interdependency form a nice little (:-) web.
(Sometimes called the dependency hell)
What i want to say is this: You can't say that you only want to update a
specific region of your web, at least not without the risk of ripping
your web here and there.
I'm using Linux since 1995, i can life with it's problems and i like
Linux more that ever. :-)
And despite me always using the latest kernel and Debian SID/unstable
for the past few years, for home & work, i have neven been badly burned.
Not that there weren't a few bruises here and there. There is nothing
like a fried X for breakfast. (Which Debian managed at least 2 or 3
times in the past years)
;-)
*:
apt-rdepends <(meta)packagename> | grep " Depends" | cut -d '(' -f0,1 | perl
-pe 's/ +$//' | sort | uniq | wc -l
e.g.
apt-rdepends kde | grep " Depends" | cut -d '(' -f0,1 | sort | perl -pe 's/
+$//' | uniq | wc -l
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
-
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] Add quirk to set AHCI mode on ICH boards
On 11.11.2007 15:05, Thorsten Leemhuis wrote: > On 10.11.2007 00:32, Matthias Schniedermeyer wrote: > > [...] > > My computer/mainboard @work has such a "broken" BIOS. Of the 5 > > SATA-Ports this MB has only 1 (and 1 "missing" that is reported by > > linux but i can't find on the MB) is configured as AHCI [...] > > There is nothing "broken" here. You have a ICH8 (without R) that drives > four SATA ports, which are handled by ata_piix. > > Then you have a Jmicron JMB363 -- it handles the PATA-Channel and two > SATA-Ports -- one internal (near the battery)/next to the PCI-Slot and a > external eSATA port. Seems you configured it in AHCI-Mode in the > BIOS-Setup. Linux will work just fine if you connect the hard disc to > that port. But if you want to install Windows XP you need a driver from > Jmicron. > > There were BIOSes for the P5B where you could enabled AHCI for the ICH8 > as well. It seems Asus removed it in the later BIOS-versions again as > Intel doesn't provide a Windows-AHCI driver for the basic ICH8. I don't have an P5B @work, but i guess MSI cooks with water too. :-) But i have a (1 year old) P5B @home and it is exactly like you said. My main point is still the same, if Linux could force AHCI mode, i wouldn't have to switch between those modes when booting Wintendo to play some games. (And i could use AHCI @work where i can't switch it in BIOS) On a side note, with the mainboard i had before the P5B (ASUS, 925X Chipset, ICH 6 or 7) Linux worked in AHCI-mode and Wintendo worked also without problems. (IOW: I did not need to switch modes in BIOS!) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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] Add quirk to set AHCI mode on ICH boards
On 10.11.2007 13:01, Mark Lord wrote: > Matthias Schniedermeyer wrote: >> .. >> My computer/mainboard @work has such a "broken" BIOS. Of the 5 SATA-Ports >> this MB has only 1 (and 1 "missing" that is reported by linux but i can't >> find on the MB) is configured as AHCI which means that with > .. > > I have a P5B-VM here (very similar). > The "missing" AHCI port is an eSATA connector on the back panel > for this board. Maybe your board just has empty tracks where > the connector would otherwise have been populated (?). Maybe, but that still doesn't "solve" my problem of the SATA-ports that i have to drive by PIIX, instead of the more preferable AHCI. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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] Add quirk to set AHCI mode on ICH boards
On 09.11.2007 22:08, Jeff Garzik wrote: > Matthias Schniedermeyer wrote: >> And on the topic of "broken" BIOSes. I have a little empathy for the MB >> manufactures as non-RAID AHCI royaly screws Windos, so not supporting it >> reduces their support costs enough to overlook screwing the non-windos >> faction. > > non-RAID AHCI works just fine on Windows. And even if, that doesn't change the fact that there are BIOSes where you can't set AHCI-mode, like my MB @work. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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] Add quirk to set AHCI mode on ICH boards
On 09.11.2007 22:08, Jeff Garzik wrote: > Matthias Schniedermeyer wrote: >> And on the topic of "broken" BIOSes. I have a little empathy for the MB >> manufactures as non-RAID AHCI royaly screws Windos, so not supporting it >> reduces their support costs enough to overlook screwing the non-windos >> faction. > > non-RAID AHCI works just fine on Windows. Last i know is that Intel doesn't provide an AHCI driver for the non-RAID version. (For whatever political reason). That is even documented in the german "c't", they even had an articel about "patching in the Device-IDs" so the RAID-AHCI driver accepts the non-RAID AHCI chipsets. And i can second that, when i configure my @home MB (ASUS P5B = non-RAID) to AHCI neither XP nor Vista work. @work i tried to install Vista on an AHCI-configured machine and aborted that "expriment" after about 2 hours. In IDE-mode it took Vista about 3 Minutes to reach the point where i aborted the AHCI experiment. So i must say: My milage varies. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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] Add quirk to set AHCI mode on ICH boards
On 09.11.2007 12:04, Alan Cox wrote: > On Thu, 8 Nov 2007 22:46:22 -0500 > Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > On Thu, Nov 08, 2007 at 10:29:37PM -0500, Mark Lord wrote: > > > And I might even privately patch my own kernels to map the ACHI BAR > > > in the cases where the BIOS didn't... > > > > The inability to do this in the general case is the main reason why > > AHCI was not unconditionally enabled, even in IDE mode, when it was > > originally added... :/ > > We've done it all the time for various devices without problems (eg S3 > video cards). I'd like to see it go in - although perhaps attached to a > force_ahci boot param initially I second that. My computer/mainboard @work has such a "broken" BIOS. Of the 5 SATA-Ports this MB has only 1 (and 1 "missing" that is reported by linux but i can't find on the MB) is configured as AHCI which means that with a HDD & a DVD-ROM connected to 2 of the 4 "piix"-ports, i only have 1 hot-pluggable port instead of the possible 3. And for some temporary work i would really need at least 2 hot-pluggable ports. So as a work-around i will try a Promise 150 TX4 controller as it is supposed to support hotplug since 2.6.23. After having hotplug @home from the date the linux-kernel supporting it was released, i don't want to live without it, as i use it daily. And on the topic of "broken" BIOSes. I have a little empathy for the MB manufactures as non-RAID AHCI royaly screws Windos, so not supporting it reduces their support costs enough to overlook screwing the non-windos faction. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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: recent nfs change causes autofs regression
> > It's not very conservative to suddenly change default behavior and break > > autofs mounts. There is not even one kernel message that "_tells_ user why > > it thinks it's wrong". It just silently fails. > > No it doesn't. It reports an error code to the caller. If autofs is > failing silently, then that is a bug in autofs: mount will report the > error to the user. Wrong(tm). autofs AND mounting at the commandline just say: mount.nfs: /mnt is already mounted or busy Which has an actual information value of about 1%. In my case i moved a nfs exported directory inside another nfs-exported directory month ago and placed a symlink where the direcotry was (on the server-side). It never acured to me that that was "wrong"(tm). Now i can only mount one of the two mounts and the other just tells "busy". After reading this i could fix my case easyly. I just erased the "deeper" mount and symlinked the directory from the other mount. But YOU HAVE TO KNOW THAT YOU DID SOMETHING WRONG. Just getting a "Busy" lets you staying with Question-marks flying around you head! Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)
markus reichelt wrote: PS: Just wondering: Who came up with this "on-demand" hype? I don't remember the names, but i remember the root causes. Here we go: The discussion started when someone with a CD-Server ran out of loops as 256 was the "fixed" maximum. The other "root"-cause was that the data-structure for the loop-devices was fixed in size at load-time, so after you load the loop-module you couldn't change anything. From "increasing" the maximum to the discussion went to dynamic allocation. Dynamic allocation has the added nicety that there is a bit less waste of resources, in case you don't need so many loops and that you can scale to a large number of loops if you need to. When all the bugs and usability problems are shaken out, everybody is happy, especially the members of the "i need massive amounts of loops"-fraction. So much for the background. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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] Documentation/HOWTO translated into Japanese
Greg KH wrote: > On Sun, Jun 10, 2007 at 07:56:52PM +0200, Matthias Schniedermeyer wrote: >> Greg KH wrote: >> I could see the point in ONE "HOWTO" file per language to get people >> started, but everything else is a pointless exercise. >> A developer/bug-reporter has to be able to express him-/herself in English >> and understand English, otherwise you can not accomplish very much. > > Yes, but this file, and the stable-api-nonsense.txt files are there to > help people understand both the kernel's philosophy, as well as > encourage them to help contribute. This was the part that i understood wrong. I thought the point was a translation of Documentation/*. A concur that translating this small set of files could be helpful. -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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] Documentation/HOWTO translated into Japanese
Greg KH wrote: On Sun, Jun 10, 2007 at 02:24:51PM +0200, Jesper Juhl wrote: Since the common language of most kernel contributors is english I personally feel that we should stick to just that one language in the tree and then perhaps keep translations on a website somewhere. So the authoritative docs stay in the tree, in english, so that as many contributors as possible can read and update them. It would then be a seperate project to generate translations and keep them updated according to what's in the tree. Perhaps we could get the kernel.org people to create an official space for that and then place a pointer to that site in Documentation/ somewhere. No, I think the translated files should be in the tree proper, we have the space :) Frankly i don't see the difference between this and the annual reoccurring "why can't the kernel messages be localized" discussion. (Which is a little overdue, but maybe this replaces it this time.) I could see the point in ONE "HOWTO" file per language to get people started, but everything else is a pointless exercise. A developer/bug-reporter has to be able to express him-/herself in English and understand English, otherwise you can not accomplish very much. All the points of the localized-messages discussion: - You have to have a common language, otherwise you can't communicate. - The translation will per definition be out of sync - Translations tend to introduce (translation-)errors - ... also apply here. A little anecdote: Very Long ago (last millennium i think) SuSE defaulted to a german translated kernel for one release of their distribution. (And optionally for a few more) But even though i'm german i couldn't understand a single word. And here is the FAQ-Entry about the annually reoccurring discussion: http://www.tux.org/lkml/#s9-16 Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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] DualFS: File System with Meta-data and Data Separation
Yakov Lerner wrote: > On 2/14/07, sfaibish <[EMAIL PROTECTED]> wrote: >> On Sat, 10 Feb 2007 22:06:37 -0500, Sorin Faibish <[EMAIL PROTECTED]> >> wrote: >> >> > Introducing DualFS >> > >> > File System developers played with the idea of separation of >> > meta-data from data in file systems for a while. The idea was >> > lately revived by a small group of file system enthusiasts >> > from Spain (from the little known University of Murcia) and >> > it is called DualFS. We believe that the separation idea >> > will bring to Linux file systems great value. >> > >> > We see DualFS as a next-generation journaling file system which >> > has the same consistency guaranties as traditional journaling >> > file systems but better performance characteristics. The new file >> > system puts data and meta-data on different devices (usually, two >> > partitions on the same disk or different disks) > > Do you guys have an option of using just one partiton, and > divide it into two fixed parts at mkfs-time , one part X% (for metadata) > and 2nd part at (100-X)% (file file blocks) ? Would not this option > be easier-to-administer choice for naive users ? Or, you do not > view your FS as an option for naive users in the first place ? Personally i would prefer to put the metadata-part as a file inside another filesystem. - The files can shrink and grow as needed - If you have several Partitions like that you don't have that much overhead because of fixed size metadata For e.g. I have 41 external HDDs (11TB, currently with XFS), when i could split the metadata from the actual data. And when it would be possible to mount the metadata without it's data i would gain the following niceties. - I could gather all metadata in one place - No "overhead" for filesystem on the external HDDs just "pure" data. - They would be searchable, at least on the metadata level, so i could search something and then connect the needed HDD for full access. In my case the metadata overhead should be quite small as the smallest file is about 400MB and range up to 5GB. For e.g. i have HDDs which are full by only about 90 files. The file are mostly write-once, so the current overhead for dualfs would be 'extreme' for my case. AFAIR the overhead of XFS (with log reduced to near minimum) was about 4-5MB in total for a 200GB HDD. But i'm currently at work so i can't verify that. -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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: SATA-performance: Linux vs. FreeBSD
Martin A. Fink wrote: >> The needed total bandwidth may be to high and at least the incoming part via > GigE may have serious overhead. >> 150MB/s in via (at least 2) GigE, without Zero-Copy there is another 150MB/s > memory to memory. >> Then there is the next 150MB/s memory to the discs, without Zero-Copy there > also another 150MB/s memory to memory. >> In total that's 300MB/s to 600MB/s without any processing. > > I dont understand your calculation: from 3 GE ports come around 50 MB/each. > These altogether 150MB/s have to be copied to memory. From there they will be > copied to disk. So we talk about 2x150 MB/s running through my system. That > is less than 2 PCIe lanes can handle... And there are more than 2 lanes > between north and south bridge It may be that the TCP/IP-Stack has to copy the data around. But someone that knows the inner workings would have to answer this. That may also depend on the used NIC. Also the data doesn't appear 'en bloc', but arrives over a period of time, so you have more or less big "gaps" in the processing. Especially the "gaps" can considerably lower total achievable bandwidth. A little naive fallacy (According to dict.leo.org a translation for: Milchmädchenrechnung): You get a package of work every (say) 1ms and you (say) need .2ms for processing, shoveling and writing to disc. Then there is no way you can saturate more than 1/5 of total theoretical bandwidth, because 80% of the time you are waiting for more work to come. -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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: SATA-performance: Linux vs. FreeBSD
Martin A. Fink wrote: >> Also you have skipped the information how the images "arrive" on the system > (PCI(e) card?), that may be important for an "end to end" view of the > problem. > > Images arrive via Gigabit Ethernet. GigE Vision standard. (PCIe x4) The the next question is: ChipSet/Used Protocol/JumboFrames/(NAPI)/... . Have you already determined the load caused by this part? Depending on the GigE-Chipset, and Protocol/JumboFrames/(NAPI)/..., the involved overhead can be quite serious. >> And what's also missing. What is "a long period of time". >> Calculating best-case with the SSD: >> 27GB divided by 30MB/s only gives a bit more than 15 Minutes. >> And worst case with 50MB/s is less than 10 Minutes. > > Well. The testdrive has 27GB. The final drive will have 225 GB. And there > will > be 3 cameras and thus 3 disks. This means we talk about 140 MB/s for around > 90 minutes. > For space applications with low power but high performance this is a long > time... ;-) The MB/CPU/RAM will be the one specified in the first mail? My gut feeling says: Forget it. The needed total bandwidth may be to high and at least the incoming part via GigE may have serious overhead. 150MB/s in via (at least 2) GigE, without Zero-Copy there is another 150MB/s memory to memory. Then there is the next 150MB/s memory to the discs, without Zero-Copy there also another 150MB/s memory to memory. In total that's 300MB/s to 600MB/s without any processing. But on the other hand, hdparm -T says my system (Core2Duo E6700, FSB1066, 2GB DDR2-800 RAM, 32Bit) has a buffer-cache bandwidth around 4000MB/s. As you don't said which FSB and Memory-Type you have i would guess that your system should reach between 2000MB/s and 3500MB/s of LINEAR(!) memory bandwidth. (Total usable Memory-Bandwidth is unfortunately also dependent on usage pattern. Large & linear is not as important as with a rotating HDD, but it factors in) Btw. On the topic of filesystem and Linux performance: SGI did a "really big" test some time ago width a big iron having 24 Itanium2-CPUs in 12 nodes, and 12*2 GB of ram and having 256 discs using XFS(Which is from SGI!). The pdf-file is here: http://oss.sgi.com/projects/xfs/papers/ols2006/ols-2006-paper.pdf According the the paper the system had a theoretical peak IO-performance of 11.5 GB/s and practically peaked at 10.7GB/s reading and 8.9GB/s writing. IOW Linux and XFS CAN perform quite well, but the system has to have enough muscle for the job. And since the paper (and Kernel 2.6.5) the development of Linux hasn't stopped. -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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: SATA-performance: Linux vs. FreeBSD
Martin A. Fink wrote: > Am Dienstag, 13. Februar 2007 00:31 schrieben Sie: >> Martin A. Fink wrote: >>> I have to store big amounts of data coming from 2 digital cameras to disk. >>> Thus I have to write blocks of around 1 MB at 30 to 50 frames per second >>> for >>> a long period of time. So it is important for me that the harddisk drive >>> is >>> reliable in the sense of "if it is capable of 50 MB/s then it should >>> operate >>> at this speed. Constantly." >> The good old handful of suggestions: >> >> - Use a dedicated disc for the task. > > I used a dedicated disk for this task. No one else besides the task is > writing > to it! OK. >> - Use an empty disc so there is no fragmentation. > > All tests were performed on empty disk! OK. >> - Buy a bigger disk, they have high bandwidths. > > I have a flash disk from a manufacturer who grants me 48 MB/s. And FreeBSD as > well as Windows reach this value. Only Linux 2.6.18 is far away from it (42 > MB/s) Even 48MB/s is quite low. I've reached up to 70MB/s with a single 500GB Seagate model and even my older HDDs all reach 60MB/s (at least on the outer cylinders) But i haven't tested any "sync/fsync" in between, only after. >> - Buy a more "specialized" disc. > > see above > >> for e.x.: Western Digital Raptor X(*) a 150GB, 10-KRPM S-ATA disc. >> - Buy several discs and use RAID 0 >> or alternate between discs when writing. > > What I have to build is an application for the International Space Station > ISS. I am limited with power and space. So If the disk is able to write > constantly 48 MB/s then the Operating System should do this! OK. That appears to be a serious constraint. Do HDDs cope well with zero gravity? At least the SSD won't have a problem with that. ;-) > The problem is: FreeBSD is fast, but lacks of some special drivers. Linux has > all drivers but access to harddisk is unpredictable and thus unreliable! > What can I do?? Personally i haven't had such bad write speeds in years. Taking USB connected and/or encrypted partitions aside. But on the other hand: I don't sync(fsync) until i have to. And personally i have good (and constant bandwidth) experience using XFS as a filesystem. (I have 41 HDDs with a total capacity of 10.5 TB, performance is quite important for me.) Also you have skipped the information how the images "arrive" on the system (PCI(e) card?), that may be important for an "end to end" view of the problem. And what's also missing. What is "a long period of time". Calculating best-case with the SSD: 27GB divided by 30MB/s only gives a bit more than 15 Minutes. And worst case with 50MB/s is less than 10 Minutes. -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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: SATA-performance: Linux vs. FreeBSD
Martin A. Fink wrote: > I have to store big amounts of data coming from 2 digital cameras to disk. > Thus I have to write blocks of around 1 MB at 30 to 50 frames per second for > a long period of time. So it is important for me that the harddisk drive is > reliable in the sense of "if it is capable of 50 MB/s then it should operate > at this speed. Constantly." The good old handful of suggestions: - Use a dedicated disc for the task. - Use an empty disc so there is no fragmentation. - Buy a bigger disk, they have high bandwidths. - Buy a more "specialized" disc. for e.x.: Western Digital Raptor X(*) a 150GB, 10-KRPM S-ATA disc. - Buy several discs and use RAID 0 or alternate between discs when writing. - use XFS. AFAIK XFS has about the best "large file" and "high bandwidth" characteristics. - that with XFS you can preallocate the files doesn't seem relevant in this case. It's more for the case that you write several files simultaneously over a longer period of time. - Write to one large file and separate the individual files later. if you are sure that you don't get a power-failure: - Disable Write-Barriers, especially on a logging-filesystem. - Enable write-caching. (hdparm doesn't appear to be able to do that with a SATA-disc, but blktool appears to be able to) The later has a good chance of corrupting your filesystem when you do get a power-failure!!! *: I don't think you want something from the server-line, SCSI/FibreChannel/...? IIRC i read a something about the first 100MB/s disc with in the 15-KRPM league. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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] How to (automatically) find the correct maintainer(s)
Richard Knutsson wrote: > Stefan Richter wrote: > >> On 15 Jan, Matthias Schniedermeyer wrote: >> >> >>> Stefan Richter wrote: >>> >>> >>>> On 14 Jan, Richard Knutsson wrote: >>>> >>>> >>>>> (Really liked the idea to have a "Maintainer"-button next to "Help" >>>>> in *config) >>>>> >>>> >>>> Rhetorical question: What will this button be used for? >>>> >>> >>> Having "all(tm)" information of something in one place? >>> >> >> >> Or, "click here to say 'it does not work'"? >> >> My rhetorical question wasn't about what it is intended for, but what >> people would think it was intended for if it was there. >> >> > > I think it could be practical to have an easy access to whom is > responsible for a driver and which mailinglist its development is > addressed to, both for people interested in helping develop the driver > and those who got an error (or fan-mail :). > >>> I think adding the Maintainers-data is more or less a logical next step. >>> >>> It's not always clear from the MAINTAINERS-file who is the right person >>> for what. Especially as it is a rather large text-file with only >>> mediocre search-friendlieness. It's a 3.5 K-lines file! >>> >>> So when you know that you have a problem with drivers X, wouldn't it be >>> great if you could just "go to" the driver in *config and see not only >>> the Help-Text but the Maintainers-Data also. >>> >> >> >> Seems more like what you actually want to have there is links to users' >> mailinglists or forums. >> >> When this thread started, it was about assisting authors in submitting >> patches. >> >> > > Yes, this is a bit out of scope, but just realized a simple way to > implement it if using the CONFIG_FLAG-approach, just "grep" after the > flag, under which the user hit the "Maintainer"-button, in the > MAINTAINER-file. Also, I think this solves the handler-problem since an > entry can have multiple CONFIG_FLAG's stated. > > I don't think we should add the maintainer-entries directly in Kconfig, > as you Stefan stated, because it is for configure the kernel. With the > above approach, it will just require minor fixes in the "make *config" > to handle it. But how do you suppose the user gets the CONFIG_-String, which the user then could for searching? I'd say only a small percentage of hardcore-users would use the .config-file directly, the others would deviate over *config, so i'd say if the MAINTAINERS-data is integrated into Kconfig it's the perfect(tm) 90% solution. OTOH you could just teach the *config to lookup a MAINTAINERS-entry when all they are properly flagged. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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] How to (automatically) find the correct maintainer(s)
Stefan Richter wrote: > On 14 Jan, Richard Knutsson wrote: > >>(Really liked the idea to have a "Maintainer"-button >>next to "Help" in *config) > > > Rhetorical question: What will this button be used for? Having "all(tm)" information of something in one place? Help-Text and Dependencies/Selects are already there. I think adding the Maintainers-data is more or less a logical next step. It's not always clear from the MAINTAINERS-file who is the right person for what. Especially as it is a rather large text-file with only mediocre search-friendlieness. It's a 3.5 K-lines file! So when you know that you have a problem with drivers X, wouldn't it be great if you could just "go to" the driver in *config and see not only the Help-Text but the Maintainers-Data also. And you can place "Fallback"-Maintainers-Data on Tree-Parents, for the cases where you only can pinpoint a area, like when you have a problem with a USB-device. I can ask a rhetorical question too: Why not go back to Config.help. Having a huge X K-Lines file with everything in one file can't be that bad. It worked before! Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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] How to (automatically) find the correct maintainer(s)
Richard Knutsson wrote: > Matthias Schniedermeyer wrote: > >> Richard Knutsson wrote: >> >> >>> Matthias Schniedermeyer wrote: >>> >>> >>> >>>> Richard Knutsson wrote: >>>> >>>> >>>> >>>> >>>> >>>>> Any thoughts on this is very much appreciated (is there any flaws with >>>>> this?). >>>>> >>>> >>>> The thought that crossed my mind was: >>>> >>>> Why not do the same thing that was done to the "Help"-file. (Before it >>>> was superseded by Kconfig). >>>> >>>> Originaly there was a central Help-file, with all the texts. Then it >>>> was >>>> split and placed in each sub-dir. And later it was superseded by >>>> Kconfig. >>>> >>>> On the other hand you could skip the intermediate step and just fold >>>> the >>>> Maintainer-data directly into Kconfig, that way everything is "in one >>>> place" and you could place a "Maintainers"-Button next to the >>>> "Help"-Button in *config, or just display it alongside the help. >>>> >>>> And MAYBE that would also lessen the "update-to-date"-problem, as you >>>> can just write the MAINTAINERs-data when you create/update the >>>> Kconfig-file. Which is a thing that creates much bigger pain when you >>>> forget it accidently. ;-) >>>> >>>> Oh, and it neadly solves the mapping-problem, for at least all >>>> kernel-parts that have a Kconfig-option/Sub-Tree. >>>> >>> >>> I'm all for splitting up the MAINTAINERS! :) >>> >>> Just, do you have any ideas how to solve the possible multiple of the >>> same entries, when handling multiple sub-directories and when many >>> different drivers with different maintainers are in the same directory >>> and a maintainer have more then one driver? >>> >> >> >> Handles. >> If a Maintainer maintains several subsystems/drivers a "handle" could be >> used to references to a handle-list (hello MAINTAINERS) or to the place >> where the full-maintainers-entry is placed. >> > > Mm, and maybe store the entry on the shortest-pathway common directory. > Then there should be just a few left entries in the current MAINTAINERS. > But how to create the handles? > * Name (problem with persons with the same name) > * E-mail (much to change when they change it) > This also make a problem when there is a change of the maintainer, what > happens with the entry if there is no maintainer? > * Just numbers and increase every new one with one? (quite ugly!) > ... and here is the end of my ideas. > > Any good ideas? (Really liked the idea to have a "Maintainer"-button > next to "Help" in *config) I'd say something like: e.g. MS0001 MaSchn001 or something along that line. Some people have several entries in the MAINTAINERs and a new way would have to make that possible too. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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] How to (automatically) find the correct maintainer(s)
Richard Knutsson wrote: > Matthias Schniedermeyer wrote: > >> Richard Knutsson wrote: >> >> >> >>> Any thoughts on this is very much appreciated (is there any flaws with >>> this?). >>> >> >> >> The thought that crossed my mind was: >> >> Why not do the same thing that was done to the "Help"-file. (Before it >> was superseded by Kconfig). >> >> Originaly there was a central Help-file, with all the texts. Then it was >> split and placed in each sub-dir. And later it was superseded by Kconfig. >> >> On the other hand you could skip the intermediate step and just fold the >> Maintainer-data directly into Kconfig, that way everything is "in one >> place" and you could place a "Maintainers"-Button next to the >> "Help"-Button in *config, or just display it alongside the help. >> >> And MAYBE that would also lessen the "update-to-date"-problem, as you >> can just write the MAINTAINERs-data when you create/update the >> Kconfig-file. Which is a thing that creates much bigger pain when you >> forget it accidently. ;-) >> >> Oh, and it neadly solves the mapping-problem, for at least all >> kernel-parts that have a Kconfig-option/Sub-Tree. >> > > I'm all for splitting up the MAINTAINERS! :) > > Just, do you have any ideas how to solve the possible multiple of the > same entries, when handling multiple sub-directories and when many > different drivers with different maintainers are in the same directory > and a maintainer have more then one driver? Handles. If a Maintainer maintains several subsystems/drivers a "handle" could be used to references to a handle-list (hello MAINTAINERS) or to the place where the full-maintainers-entry is placed. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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] How to (automatically) find the correct maintainer(s)
Richard Knutsson wrote: > Any thoughts on this is very much appreciated (is there any flaws with > this?). The thought that crossed my mind was: Why not do the same thing that was done to the "Help"-file. (Before it was superseded by Kconfig). Originaly there was a central Help-file, with all the texts. Then it was split and placed in each sub-dir. And later it was superseded by Kconfig. On the other hand you could skip the intermediate step and just fold the Maintainer-data directly into Kconfig, that way everything is "in one place" and you could place a "Maintainers"-Button next to the "Help"-Button in *config, or just display it alongside the help. And MAYBE that would also lessen the "update-to-date"-problem, as you can just write the MAINTAINERs-data when you create/update the Kconfig-file. Which is a thing that creates much bigger pain when you forget it accidently. ;-) Oh, and it neadly solves the mapping-problem, for at least all kernel-parts that have a Kconfig-option/Sub-Tree. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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: The Input Layer and the Serial Port
Loye Young wrote: >>Take for example the AT keyboard which is >>one of the most common keyboards in the world. I have seen and >>used it attached to a PC via parport, serial port and the standard >>PS/2 port. So to handle cases like this the input layer created a >>serio interface. > > > If plain ASCII text is coming in the serial port, would the kernel know or > even care what device was generating the characters? Could I just use > whatever interface you did? A problem at this point may be that a AT-keyboard doesn't spit out ASCII but Scan-Codes, so a serial device spitting out ASCII would have to be put into the loop AFTER the stage that makes conversions, or you would have to convert ASCII back to Scan-Codes before. Btw. I'm not normaly into barcode-scanning, but for something at work i tried a USB-scanner (From Symbol AFAIR) to see what is stored in the barcodes that are on the prints that i have to generate. The scanner just registered as a plain HID-device, which resulted in the data comming as key-presses. It was just "Plug & Play", i didn't need any software or anything else. I just plugged the device in, opened a text-editor to catch the data, then i scanned the bar-codes and was happy. :-) So if you aren't nailed to a serial scanner, you just may try a USB-scanner. >>I recommend you take a look at sermouse.c >>in the drivers/input.mouse directory >>for a guide. > > > I looked, but the source code I have (2.6.17, Debian) doesn't have anything > called sermouse.c in the /drivers/input directory. # find /usr/src/linux-2.6.19 -name "*sermouse*" /usr/src/linux-2.6.19/drivers/input/mouse/sermouse.c Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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: Support 2.4 modules features in 2.6
Jaswinder Singh wrote: > Hello, > > I want to support old 2.4 modules features in 2.6 kernel modules:- > 1. no kernel source tree is required to build modules. I don't think that is possible. There are a few "questions" that are quite fundamental when you want to build a module that can be loaded by a given kernel. About the most important fundamental "questions" i can think of ATM: - UP/SMP - Preempt yes/no - RegParm yes/no (x86)- High Memory off/4g/64G(IOW PAE yes/no) And maybe a few more "not so fundamental" points. AFAIK there is no way to build a module that would work in all of the 8/16 possible "kernel-types" you get with these 3/4 fundamental options alone. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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: single bit errors on files stored on USB-HDDs via USB2/usb_storage
Stefan Richter wrote: > Matthias Schniedermeyer wrote: > >>Robert Hancock wrote: >> >>>Matthias Schniedermeyer wrote: >>> >>>>I have a 1,5 Meter and a 4,5 Meter cable connected to the USB-Controller >>>>and i only use of them depending on where the HDD is placed in my room, >>>>the other one is dangling unconnected. >>>> >>>>Then i will unconnect the short cable and use the long cable exclusivly >>>>and see if it gets better(tm). > > BTW, I suspect front panel connectors could introduce noise too, via the > jumper cables from motherboard to the panel. It's a 5 port PCI-Addon-Card, no front panel connectors. (The computers has only an OHCI/USB 1.1 controller onboard, which i use for keyboard & mouse) >>>That long cable could be part of the problem - I don't think the USB >>>specification allows for cables that long (something like a 6 foot max >>>as I recall). >> >>http://en.wikipedia.org/wiki/USB2 >> >>Says that 5 meters are allowed. > > > I don't know about USB 2.0, but in case of FireWire, ~4.5m long cables > are theoretically in spec too. I've got a FireWire 400 and a FireWire > 800 cable this long, and both don't work very unreliable. Depending on > what's connected, they fail sooner or later. However due to how FireWire > works, this is immediately noticed as data CRC errors or bus resets. > I.e. it's nearly impossible for noisy hardware to _silently_ cause data > corruption. I would suppose USB has similar CRC checks. > > Also, you mentioned that the corruption occurs systematically on certain > byte patterns. Therefore it's certainly not related to the cables. It'd guess that too, but who can that say for sure. :-| Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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: single bit errors on files stored on USB-HDDs via USB2/usb_storage
Pete Zaitcev wrote: > On Thu, 07 Dec 2006 20:41:12 +0100, Matthias Schniedermeyer <[EMAIL > PROTECTED]> wrote: > > >>>>I'm using a Bunch auf HDDs in USB-Enclosures for storing files. >>>>(currently 38 HDD, with a total capacity of 9,5 TB of which 8,5 TB is used) >>>>[] >>>>This time i kept the defective files and used "vbindiff" to show me the >>>>difference. Strangly in EVERY case the difference is a single bit in a >>>>sequence of "0xff"-Bytes inside a block of varing bit-values that >>>>changed a "0xff" into a "0xf7". > > >>>This was almost certainly caused by hardware flaws in the USB interface >>>chips of the enclosures. There's nothing the kernel can do about it >>>because the errors aren't reported; all that happens is that incorrect >>>data is sent to or from the drive. >> >>So pretty much all ich can do is to pray that the errors don't corrupt >>the Filesystem-Metadata (XFS). > > > No, this is not all. You should buy a variety of different enclosures > with different chipsets (e.g. find a Freecom if you can), That would definetly cost way to much money and time to be in any way "efficient". > and also use decent cables. I replaced all cables with "High Quality"-cables. But as a "Joe user" it is practically impossible to really know if the cables are good. All i can say is that the "original" cables that came with the enclosures appear a bit thin and the ones i bought appear much more thick, have gold plated contacts and have a massive plaited shielding IOW appear much more trustworthy. But, as i said, in the end i can't really know if they are better than the original ones. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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: single bit errors on files stored on USB-HDDs via USB2/usb_storage
Robert Hancock wrote: > Matthias Schniedermeyer wrote: > >> Hmmm. That's the only thing that i currently may be doing wrong. >> I have a 1,5 Meter and a 4,5 Meter cable connected to the USB-Controller >> and i only use of them depending on where the HDD is placed in my room, >> the other one is dangling unconnected. >> >> Then i will unconnect the short cable and use the long cable exclusivly >> and see if it gets better(tm). > > > That long cable could be part of the problem - I don't think the USB > specification allows for cables that long (something like a 6 foot max > as I recall). http://en.wikipedia.org/wiki/USB2 Says that 5 meters are allowed. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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: single bit errors on files stored on USB-HDDs via USB2/usb_storage
DervishD wrote: > Hi Matthias :) > > * Matthias Schniedermeyer <[EMAIL PROTECTED]> dixit: > >>My averate file size is about 1GB with files from about 400MB to >>5000MB I estimate the average error-rate at about one damaged file in >>about 10GB of data. >> >>I'm not sure and haven't checked if the files are wrongly written or >>"only" wrongly read back as i delete the defective files and copy them >>again. >> >>Today i copied a few files back and checked them against the stored MD5 >>sums and 5 files of 86 (each about 700 MB) had errors. So i copied the 5 >>files again. 4 of the files were OK after that and coping the last file >>the third time also resulted in the correct MD5. > > > I had more or less the same issue a week or two ago. I performed > lots of tests and only by replacing the USB2.0 PCI card, the USB cable > and the power supply of the usb-hdd adapter got the problem solved. > > I'm not sure if the problem is really gone, but the system works now > reliably. I don't know if sooner or later I'll get the issue again, > because I didn't really identify a culprit: looks like the > card+adapter+cable combination was just "ugly", and errors from the > adapter were not reported correctly. The 38 HDDs are in 38 enclosures, so each has it's own power supply. I have used different cables and i replaced the USB-Controller once. So it can't be a single faulty component. Except when the computer itself would be the culprit. >>NEVER did i see any messages in syslog regarding erros or an aborting >>program due to errors passed down from the kernel or something like >>that. > > The same here! Looks like USB-HDD adapters don't report any errors > to the kernel :? > > The best advice I can give you, from my limited experience with the > problem, is: replace the cable. This minimizes the chance of corrupted > data getting into the adapter. If that doesn't solve the problem, try > removing any unconnected cable that is plugged into the USB card. > Believe it or not, a long but unconnected cable (put there just to be > able to plug my USB card-reader without having to look for the cable in > a drawer) was causing errors *even in a Kingston USB key that worked > flawlessly otherwise*!!! Hmmm. That's the only thing that i currently may be doing wrong. I have a 1,5 Meter and a 4,5 Meter cable connected to the USB-Controller and i only use of them depending on where the HDD is placed in my room, the other one is dangling unconnected. Then i will unconnect the short cable and use the long cable exclusivly and see if it gets better(tm). > If you have any other question, feel free to drop me a note. I'm > sorry I cannot give a much more technical or scientific answer, but > unfortunately I have none :(( Thank you anyway. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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-storage] single bit errors on files stored on USB-HDDs via USB2/usb_storage
Alan Stern wrote: > On Wed, 6 Dec 2006, Matthias Schniedermeyer wrote: > > >>Hi >> >> >>I'm using a Bunch auf HDDs in USB-Enclosures for storing files. >>(currently 38 HDD, with a total capacity of 9,5 TB of which 8,5 TB is used) >> >>After i realised about a year(!) ago that the files copied to the HDDs >>sometimes aren't identical to the "original"-files i changed my >>procedured so that each file is MD5 before and after and deleted/copied >>again if an error is detected. >> >>My averate file size is about 1GB with files from about 400MB to 5000MB >>I estimate the average error-rate at about one damaged file in about >>10GB of data. >> >>I'm not sure and haven't checked if the files are wrongly written or >>"only" wrongly read back as i delete the defective files and copy them >>again. >> >>Today i copied a few files back and checked them against the stored MD5 >>sums and 5 files of 86 (each about 700 MB) had errors. So i copied the 5 >>files again. 4 of the files were OK after that and coping the last file >>the third time also resulted in the correct MD5. >> >>This time i kept the defective files and used "vbindiff" to show me the >>difference. Strangly in EVERY case the difference is a single bit in a >>sequence of "0xff"-Bytes inside a block of varing bit-values that >>changed a "0xff" into a "0xf7". >>Also interesting is that each error is at a 0xXXX5-Position >> >>Attached is a file with 5 of the 6 differences named 1-5. Of each of the >>5 2x3 lines-blocks the first 3 lines are the original the following 3 >>lines contain the error in the middle row 6th value. >> >>NEVER did i see any messages in syslog regarding erros or an aborting >>program due to errors passed down from the kernel or something like that. > > > This was almost certainly caused by hardware flaws in the USB interface > chips of the enclosures. There's nothing the kernel can do about it > because the errors aren't reported; all that happens is that incorrect > data is sent to or from the drive. So pretty much all ich can do is to pray that the errors don't corrupt the Filesystem-Metadata (XFS). So i should definetly consider writing me a "NO-FS" where the "filesystem"-part is stored elsewhere and the HDD contains 100% content (Minus a Dummy-MBR-Block for sector 0). On the plus side such a filesystem won't have any overhead at all, but on the flipside you loose pretty much the whole content if you lose the metadata. But i guess in my case it would considerably lower the risk of loosing data. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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: single bit errors on files stored on USB-HDDs via USB2/usb_storage
Robert Hancock wrote: > Matthias Schniedermeyer wrote: >> Hi >> >> >> I'm using a Bunch auf HDDs in USB-Enclosures for storing files. >> (currently 38 HDD, with a total capacity of 9,5 TB of which 8,5 TB is >> used) > > All the same enclosure type? 36x"Fantec (was MaPower) DB-335U2-1" with Genesys-Logic-Chipset (at least the model i used yesterday said that. I bought this 36 enclosures in the time from May/2005 - October/2006, so it is possible that they use different chipsets and/or revisions of the chipset) 2x"IOmega 33644" bought last week, with a Chipset that says it is from IOMega, but i guess it is just a rebranded. I have errors with all of them. I have a spare enclosure Fantec DB-35U2-2, AFAICT it uses a Cypress-Chipset which i haven't used for some time, so ATM i don't remember if i had it with this one too. >> This time i kept the defective files and used "vbindiff" to show me the >> difference. Strangly in EVERY case the difference is a single bit in a >> sequence of "0xff"-Bytes inside a block of varing bit-values that >> changed a "0xff" into a "0xf7". >> Also interesting is that each error is at a 0xXXX5-Position >> >> Attached is a file with 5 of the 6 differences named 1-5. Of each of the >> 5 2x3 lines-blocks the first 3 lines are the original the following 3 >> lines contain the error in the middle row 6th value. >> >> NEVER did i see any messages in syslog regarding erros or an aborting >> program due to errors passed down from the kernel or something like that. > > The fact that the corruption seems data dependent would seem to me to > point to some kind of hardware problem. I would tend to suspect the > USB-to-IDE converters in the enclosures as being faulty or something > like that.. > -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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/
single bit errors on files stored on USB-HDDs via USB2/usb_storage
Hi
I'm using a Bunch auf HDDs in USB-Enclosures for storing files.
(currently 38 HDD, with a total capacity of 9,5 TB of which 8,5 TB is used)
After i realised about a year(!) ago that the files copied to the HDDs
sometimes aren't identical to the "original"-files i changed my
procedured so that each file is MD5 before and after and deleted/copied
again if an error is detected.
My averate file size is about 1GB with files from about 400MB to 5000MB
I estimate the average error-rate at about one damaged file in about
10GB of data.
I'm not sure and haven't checked if the files are wrongly written or
"only" wrongly read back as i delete the defective files and copy them
again.
Today i copied a few files back and checked them against the stored MD5
sums and 5 files of 86 (each about 700 MB) had errors. So i copied the 5
files again. 4 of the files were OK after that and coping the last file
the third time also resulted in the correct MD5.
This time i kept the defective files and used "vbindiff" to show me the
difference. Strangly in EVERY case the difference is a single bit in a
sequence of "0xff"-Bytes inside a block of varing bit-values that
changed a "0xff" into a "0xf7".
Also interesting is that each error is at a 0xXXX5-Position
Attached is a file with 5 of the 6 differences named 1-5. Of each of the
5 2x3 lines-blocks the first 3 lines are the original the following 3
lines contain the error in the middle row 6th value.
NEVER did i see any messages in syslog regarding erros or an aborting
program due to errors passed down from the kernel or something like that.
Data for the computer/software:
Hardware:
Computer is a Dual P3-933Mhz with 3GB (ECC) SD-RAM, Severworks HE-SL-Chipset
Source-HDD is a 200GB S-ATA device connected to a Promise TX-4 using libata.
Destination-HDDs: Several different models in several different
enclosures and different chipsets, mostly Genesys Logic)
USB-controller: Currently i use a EHCI/OHCI-NEC-Chipset add-on card but
since about 4-5 month ago i used a EHCI/UHCI-VIA-Chipset add-on card
with same results.
Software:
Kernel: up to 2.6.18, self compiled
vanilla kernels.
I haven't tried 2.6.19 and i don't expect any changes from it.
Distribution: Debian SID
I you need any other information i will provide them as good as i can.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
1:
245A E2F0: 0E D9 35 01 00 F4 7B F8 00 00 01 E0 09 00 80 00 ..5...{.
245A E300: 0D FF FF FF FF FF FF FF FF FF FF FF FF FF DF FC
245A E310: 20 92 50 90 DC F4 0C 1A 1A 18 DB 80 4E 61 25 80 .P. Na%.
245A E2F0: 0E D9 35 01 00 F4 7B F8 00 00 01 E0 09 00 80 00 ..5...{.
245A E300: 0D FF FF FF FF F7 FF FF FF FF FF FF FF FF DF FC
245A E310: 20 92 50 90 DC F4 0C 1A 1A 18 DB 80 4E 61 25 80 .P. Na%.
2:
24F9 F770: 00 00 01 E0 09 00 80 00 0D FF FF FF FF FF FF FF
24F9 F780: FF FF FF FF FF FF FC 13 64 0B 38 68 EA A2 11 86 d.8h
24F9 F790: 61 7A EE EC ED 1D 6F 31 32 6E 4D D9 B5 31 37 66 azo1 2nM..17f
24F9 F770: 00 00 01 E0 09 00 80 00 0D FF FF FF FF FF FF FF
24F9 F780: FF FF FF FF FF F7 FC 13 64 0B 38 68 EA A2 11 86 d.8h
24F9 F790: 61 7A EE EC ED 1D 6F 31 32 6E 4D D9 B5 31 37 66 azo1 2nM..17f
3:
20CB C6B0: 00 FB 3F F8 00 00 01 E0 09 00 80 80 0D 21 2A 1B ..?. .!*.
20CB C6C0: 65 F1 FF FF FF FF FF FF FF FF 3E C4 BC 2B 39 A4 e... ..>..+9.
20CB C6D0: 8E 85 50 EB 7B 02 7B 93 79 77 50 EF 60 32 8C 03 ..P.{.{. ywP.`2..
20CB C6B0: 00 FB 3F F8 00 00 01 E0 09 00 80 80 0D 21 2A 1B ..?. .!*.
20CB C6C0: 65 F1 FF FF FF F7 FF FF FF FF 3E C4 BC 2B 39 A4 e... ..>..+9.
20CB C6D0: 8E 85 50 EB 7B 02 7B 93 79 77 50 EF 60 32 8C 03 ..P.{.{. ywP.`2..
4:
1F13 06B0: 00 00 01 E0 09 00 80 00 0D FF FF FF FF FF FF FF
1F13 06C0: FF FF FF FF FF FF 7F 5C 14 05 F2 9E 90 0F 6F A4 ...\ ..o.
1F13 06D0: B8 10 BF E9 6A 78 A3 00 13 00 FD 9C 00 A5 5B EB jx.. ..[.
1F13 06B0: 00 00 01 E0 09 00 80 00 0D FF FF FF FF FF FF FF
1F13 06C0: FF FF FF FF FF F7 7F 5C 14 05 F2 9E 90 0F 6F A4 ...\ ..o.
1F13 06D0: B8 10 BF E9 6A 78 A3 00 13 00 FD 9C 00 A5 5B EB jx.. ..[.
5:
1F13 06B0: 00 00 01 E0 09 00 80 00 0D FF FF FF FF FF FF FF
1F13 06C0: FF FF FF FF FF FF 7F 5C 14 05 F2 9E 90 0F 6F A4 ...\ ..o.
1F13 06D0: B8 10 BF E9 6A 78 A3 00 13 00 FD 9C 00 A5 5B EB jx.. ..[.
1F13 06B0: 00 00 01 E0 09 00 80 00 0D FF FF FF FF FF FF FF
1F13 06C0: FF FF FF FF FF F7 7F 5C 14 05 F2 9E 90 0F 6F A4 ...\ ..o.
1F13 06D0: B8 10 BF E9 6A 78 A3 00 13 00 FD 9C 00 A5 5B EB jx.. ..[.
Re: ahci, SActive flag, and the HD activity LED
Martin Wilck wrote: Jens Axboe wrote: If I am reading the specs correctly, that'd mean the ahci driver is wrong in setting the SActive bit. I completely agree, that was my reading of the spec as well and hence my original posts about this in the NCQ thread. Have you (or has anybody else) also seen the wrong behavior of the activity LED? 925X-Chipset Lspci says: 8086:2652 Intel Corp. 82801FR/FRW (ICH6R/ICH6RW) SATA Controller (rev 03) HDD: Western Digital WD2000JD-00H, i believe this HDD is non-NCQ. Kernels: 2.6.10 - 2.6.12 The Activity-LED has burned like a light-bulb every since i have that computer. (Excluding the few seconds before booting Linux. :-) ) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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: SCSI-CD-Writer don't show up
On Sun, Jun 03, 2001 at 06:38:27PM +0200, Gérard Roudier wrote: > > On Sat, 2 Jun 2001, Matthias Schniedermeyer wrote: > > > I have 3 SCSI-CD-Writers. "Strange" is that the boot-process only finds > > the first one (1 0 5 0), the other two i have to add with > > > > echo "scsi add-single-device 2 0 4 0" > /proc/scsi/scsi > > echo "scsi add-single-device 2 0 6 0" > /proc/scsi/scsi > > > > to make them useable. > > > > Here is the complete ist of my SCSI-Devices: > > > > Host: scsi0 Channel: 00 Id: 06 Lun: 00 > > Vendor: IBM Model: DDYS-T18350N Rev: S93E > > Type: Direct-AccessANSI SCSI revision: 03 > > Host: scsi1 Channel: 00 Id: 00 Lun: 00 > > Vendor: PLEXTOR Model: CD-ROM PX-32TS Rev: 1.03 > > Type: CD-ROM ANSI SCSI revision: 02 > > Host: scsi1 Channel: 00 Id: 01 Lun: 00 > > Vendor: PIONEER Model: DVD-ROM DVD-303 Rev: 1.10 > > Type: CD-ROM ANSI SCSI revision: 02 > > Host: scsi1 Channel: 00 Id: 05 Lun: 00 > > Vendor: TEAC Model: CD-R58S Rev: 1.0N > > Type: CD-ROM ANSI SCSI revision: 02 > > Host: scsi2 Channel: 00 Id: 02 Lun: 00 > > Vendor: PIONEER Model: DVD-ROM DVD-304 Rev: 1.03 > > Type: CD-ROM ANSI SCSI revision: 02 > > Host: scsi2 Channel: 00 Id: 03 Lun: 00 > > Vendor: PIONEER Model: DVD-ROM DVD-304 Rev: 1.03 > > Type: CD-ROM ANSI SCSI revision: 02 > > Host: scsi2 Channel: 00 Id: 04 Lun: 00 > > Vendor: TEAC Model: CD-R58S Rev: 1.0K > > Type: CD-ROM ANSI SCSI revision: 02 > > Host: scsi2 Channel: 00 Id: 06 Lun: 00 > > Vendor: TEAC Model: CD-R58S Rev: 1.0P > > Type: CD-ROM ANSI SCSI revision: 02 > > > > I have a "Symbios 53c1010 (Dual Channel Ultra 160)" and a "NCR 810a" The > > two devices which are not found are connected through adapters onto the > > second channel of the Symbios 53c1010. > > > > Kernel is 2.4.4 or 2.4.5ac6. > > As host-adapter-driver i use the "SYM53C8XX"-driver > > > > If other info is needed, no problem. :-) > > You should check if your devices are enabled for SCAN in the NVRAM. I had disabled all IDs from scanning (except those which had a drive) when i first installed the system. Now i enabled all IDs for scanning. :-) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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/
SCSI-CD-Writer don't show up
#Include I have 3 SCSI-CD-Writers. "Strange" is that the boot-process only finds the first one (1 0 5 0), the other two i have to add with echo "scsi add-single-device 2 0 4 0" > /proc/scsi/scsi echo "scsi add-single-device 2 0 6 0" > /proc/scsi/scsi to make them useable. Here is the complete ist of my SCSI-Devices: Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: IBM Model: DDYS-T18350N Rev: S93E Type: Direct-AccessANSI SCSI revision: 03 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: PLEXTOR Model: CD-ROM PX-32TS Rev: 1.03 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 01 Lun: 00 Vendor: PIONEER Model: DVD-ROM DVD-303 Rev: 1.10 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 05 Lun: 00 Vendor: TEAC Model: CD-R58S Rev: 1.0N Type: CD-ROM ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 02 Lun: 00 Vendor: PIONEER Model: DVD-ROM DVD-304 Rev: 1.03 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 03 Lun: 00 Vendor: PIONEER Model: DVD-ROM DVD-304 Rev: 1.03 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 04 Lun: 00 Vendor: TEAC Model: CD-R58S Rev: 1.0K Type: CD-ROM ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 06 Lun: 00 Vendor: TEAC Model: CD-R58S Rev: 1.0P Type: CD-ROM ANSI SCSI revision: 02 I have a "Symbios 53c1010 (Dual Channel Ultra 160)" and a "NCR 810a" The two devices which are not found are connected through adapters onto the second channel of the Symbios 53c1010. Kernel is 2.4.4 or 2.4.5ac6. As host-adapter-driver i use the "SYM53C8XX"-driver If other info is needed, no problem. :-) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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: Promise Ultra 100 TX2
> I just bought one of $subject (PDC 20268) > > Removed a Ultra 66 from my system and plugged the new one into the 66Mhz > PCI-Bus (Intependent from the 33Mhz PCI-Bus (Tyan Thunder HE-SL Mainboard > with Serverworks HE-SL-Chipset)) > > Kernel is 2.4.4 with Promise support compiled in. (The Ultra 66 works like > a charm with this kernel) > > > But the new controller wasn't deteced by the IDE-Subsystem AT ALL. (It > only showed the onboard OSB4-Adapter) with "ide.2.4.4-p1.04092001.patch.bz2" it now works like a charm. :-) (As there is no update in 2.4.5 or in (current) 2.4.5ac4 i look what Andre has produced and found that patch.) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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/
Promise Ultra 100 TX2
#Include I just bought one of $subject (PDC 20268) Removed a Ultra 66 from my system and plugged the new one into the 66Mhz PCI-Bus (Intependent from the 33Mhz PCI-Bus (Tyan Thunder HE-SL Mainboard with Serverworks HE-SL-Chipset)) Kernel is 2.4.4 with Promise support compiled in. (The Ultra 66 works like a charm with this kernel) But the new controller wasn't deteced by the IDE-Subsystem AT ALL. (It only showed the onboard OSB4-Adapter) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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/
Memory leak in 2.4.2 (+loop-6-patch)???
#Include After some days of uptime, i just stopped (nearly) all programs, unmounted all unnecessary devices. But top & free say that 1/3 of my RAM is still "used" Here is what top means: (Swap is 0K because i don't use Swap at all. Should i use swap?) 9:54pm up 11 days, 23 min, 4 users, load average: 0.00, 0.22, 0.52 30 processes: 29 sleeping, 1 running, 0 zombie, 0 stopped CPU0 states: 0.1% user, 0.0% system, 0.0% nice, 99.4% idle CPU1 states: 0.0% user, 0.2% system, 0.0% nice, 99.3% idle Mem: 1028648K av, 334624K used, 694024K free, 0K shrd,3556K buff Swap: 0K av, 0K used, 0K free 55136K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 1 root 4 0 100 10060 S 0.0 0.0 0:17 init 2 root 9 0 00 0 SW0.0 0.0 0:00 keventd 3 root 9 0 00 0 SW0.0 0.0 0:53 kswapd 4 root 9 0 00 0 SW0.0 0.0 0:00 kreclaimd 5 root 9 0 00 0 SW0.0 0.0 6:21 bdflush 6 root 9 0 00 0 SW0.0 0.0 0:34 kupdate 7 root 9 0 00 0 SW0.0 0.0 0:00 khubd 294 root 8 0 164 16472 S 0.0 0.0 0:01 cron 373 root 9 0 508 508 144 S 0.0 0.0 0:00 login 374 root 9 0 508 508 144 S 0.0 0.0 0:00 login 375 root 9 0 508 508 144 S 0.0 0.0 0:00 login 380 root 9 084 84 0 S 0.0 0.0 0:00 mingetty 385 root 9 0 508 508 144 S 0.0 0.0 0:00 login 386 root 9 084 84 0 S 0.0 0.0 0:00 mingetty 389 ms 8 0 1072 1072 736 S 0.0 0.1 0:00 bash 396 root 0 0 1264 1264 896 S 0.0 0.1 0:01 bash 404 root 11 0 1132 1132 732 S 0.0 0.1 0:01 bash 463 citd 8 0 1192 1192 852 S 0.0 0.1 0:00 bash 6520 root 9 0 612 612 524 S 0.0 0.0 0:00 mingetty 6521 root 9 0 612 612 524 S 0.0 0.0 0:00 mingetty 6522 root 9 0 612 612 524 S 0.0 0.0 0:00 mingetty 6523 root 9 0 612 612 524 S 0.0 0.0 0:00 mingetty 6524 root 9 0 612 612 524 S 0.0 0.0 0:00 mingetty 6525 root 9 0 612 612 524 S 0.0 0.0 0:00 mingetty 6526 root 9 0 612 612 524 S 0.0 0.0 0:00 mingetty 6527 root 9 0 612 612 524 S 0.0 0.0 0:00 mingetty 6528 root 9 0 612 612 524 S 0.0 0.0 0:00 mingetty 6529 root 9 0 612 612 524 S 0.0 0.0 0:00 mingetty 6652 root 12 0 1008 1008 804 R 0.0 0.0 0:00 top 6663 root 17 0 544 544 468 S 0.0 0.0 0:00 gpm uname -a Linux leeloo 2.4.2 #18 SMP Fri Feb 23 19:31:03 CET 2001 i686 unknown gcc --version 2.95.2 Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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.4.1-ac5
> > now that -ac grows that huge, could you put out incremental patches? > > Takes me too much time. But if anyone else wants to, go ahead This is what i use to diff 2 different kernels - snip - diffkernel) mount none /d/kernel -t ramfs cd /d/kernel tar -zxf $1 cp -a linux linuxa cd /d/kernel/linuxa zcat $2 | patch -p1 -E -s cd /d/kernel/linux zcat $3 | patch -p1 -E -s cd /d/kernel diff -Nur linuxa linux cd umount /d/kernel - snip - This takes about 8 seconds (for 2.4 kernels) on my Dual PIII-933, 1Gig-RAM Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
"Bigger" rsync hangs with 2.4.0, 2.4.1, 2.4.1ac4
#include (Relevant) HW is: MB: Serverworks HE-Chipset RAM: 1GB CPU: 2xPIII 933Mhz "System"-HDD: 18GB Ultra 160SCSI "Data"-HDD: 2xIBM DTLA 307045 plugged onto a "Promise Ultra 66" Some "simple" steps to do that. mount /dev/hde1 /x1 mount /dev/hdg1 /x2 (The two DTLAs) rsync -av --delete /x1/kernel/ /x2/kernel/ "a few" files works without problems, when the rsync is "a bit" bigger than it will hang "forever" when it did the work. (I can "recreate" it with rsyncing "2.4.1" to "2.4.1ac4") The rsync is "successfull". (Rerunning it works without problems. "diff -Nur" doesn't show any differences) Filesystem doesn't seam to matter. I had the problem with reiserfs and ext2. If you need more Information i will provide them. (Even remote-login is no problem) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Mainboard with Serverworks HE Chipset
> You could try booting with 'nmi_watchdog=0' and see what happens. Since i "append"ed it into the lilo-confi i haven't had a lockup. :-)) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Mainboard with Serverworks HE Chipset
> > Now my problem. > > > > The Graphic-Card is a Geforce 2, Xfree is 4.02 (compiled under 2.2.17). > > > > When i start X, everything is fine. When i go back to text-console and > > wait "some time" and then switch back to X the computer locks solid and i > > have to press the Big-Red Button. (Switching back to X after a "short" > > periode of time, at the text-console, works "normaly") > > > > If anyone needs more information, i will happily provide them. > > I have same card, but haven't tried to do that kind of switching.. > .. at least not recently. At work i use xterms, at home i use the console. (diffrent profiles ) > You don't mention which kernel you are running, and what userspace > package. I knew i forgot important details. :-) Kernel is 2.4.1-pre7 System is/was a SuSE 7.0, when i installed it a few month ago. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Mainboard with Serverworks HE Chipset
#include I got a "Tyan Thunder HE-SL"-Mainboard today, which has a "Severworks ServerSet III HE"-Chipset. (2xPIII 933, 2x512MB PC133 ECC-Registered SDRAM) And i have one problem and one question. First the question. I have an uptime of phenomenal 29minutes and "cat /proc/interrupts" tells me this NMI: 175819 175819 LOC: 175829 175828 Should i be worried? Or can i ignore it. With my former Mainboard NMI was (AFAIR) always 0. Now my problem. The Graphic-Card is a Geforce 2, Xfree is 4.02 (compiled under 2.2.17). When i start X, everything is fine. When i go back to text-console and wait "some time" and then switch back to X the computer locks solid and i have to press the Big-Red Button. (Switching back to X after a "short" periode of time, at the text-console, works "normaly") If anyone needs more information, i will happily provide them. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: About Celeron processor memory barrier problem
> > I found that when I compiled the 2.4 kernel with the option > > of Pentium III or Pentium 4 on a Celeron's PC, it could cause the > > system hang at very beginning boot stage, and I found the problem > > is cause by the fact that Intel Celeron doesn't have a real memory > > barrier,but when you choose the Pentium III option, the kernel > > assume the processor has a real memory barrier. > > Here is a patch to fix it: > > No. > > The fix is to not lie to the configurator. > > A Celeron isn't a PIII, and you shouldn't tell the configure that it is. > > The whole point of being able to choose the CPU to optimize for is that we > can optimize things at compile-time. This is what 2.2.17 thinks about my Celeron 600MHz processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 6 cpu MHz : 601.374 cache size : 128 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr xmm bogomips: 1199.31 Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
CD slowdown
#include I two Pioneer DVD U04S (SCSI) 10x DVD 40xCD. When i want to play CD-Rs they are "loud". So i searched for a "slowdown" Programm on freshmeat and fount "cdrom_speed.c". The problem is that the drive seems to ignore the speed changes and spins the CDR with full speed. Kernel is 2.2.17, HA is an adaptec 7895. (Drives are Pioneer DVD U04S) Is there something i can do? Or do i have to change the drives with U03S ones. (Which are nearly noiseless) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
