problem in building 4.8.0: references to non-existent util CLANG

Is CLANG required for building now? when I did a "make xconfig" (or any make, for that matter), I get: make xconfig scripts/kconfig/qconf Kconfig invocation line: ./scripts/clang-version.sh gcc ## debug line I added ./scripts/clang-version.sh: line 15: ./COPYING: Permission denied

problem in building 4.8.0: references to non-existent util CLANG

Is CLANG required for building now? when I did a "make xconfig" (or any make, for that matter), I get: make xconfig scripts/kconfig/qconf Kconfig invocation line: ./scripts/clang-version.sh gcc ## debug line I added ./scripts/clang-version.sh: line 15: ./COPYING: Permission denied

Re: Howto tell kernel to use 4096 as granularity & minimum size?

Dave Chinner wrote: I can partition the disk and setup the allocation size to 4096, but I'd like to tell the kernel to use a virtual-size of 4096 for the sector as an additional performance 'hint', so nothing will even try to use smaller i/o's than that. Just format the filesystem with

Re: Howto tell kernel to use 4096 as granularity minimum size?

Dave Chinner wrote: I can partition the disk and setup the allocation size to 4096, but I'd like to tell the kernel to use a virtual-size of 4096 for the sector as an additional performance 'hint', so nothing will even try to use smaller i/o's than that. Just format the filesystem with

Re: RFE?: why no 'bind' info in /proc/mounts?

Ah... didn't know about the other format file... thanks! On 10/31/2013 9:15 PM, NeilBrown wrote: Take a look in /proc/self/mountinfo. It contains more useful stuff about the mount table which couldn't be put in /proc/mounts without breaking compatibility. NeilBrown -- To unsubscribe

Re: RFE?: why no 'bind' info in /proc/mounts?

Ah... didn't know about the other format file... thanks! On 10/31/2013 9:15 PM, NeilBrown wrote: Take a look in /proc/self/mountinfo. It contains more useful stuff about the mount table which couldn't be put in /proc/mounts without breaking compatibility. NeilBrown -- To unsubscribe

RFE?: why no 'bind' info in /proc/mounts?

If I only mount 1 file (or a subdir) via "bind", it still shows the entire device being mounted on the "bound" directory. Is there anyway to get a bit more granularity as to *what* was bound on a name? (subdir/file..?) -- To unsubscribe from this list: send the line "unsubscribe

RFE?: why no 'bind' info in /proc/mounts?

If I only mount 1 file (or a subdir) via bind, it still shows the entire device being mounted on the bound directory. Is there anyway to get a bit more granularity as to *what* was bound on a name? (subdir/file..?) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in

Fwd: BUG: key ffff880c1148c478 not in .data! (V3.10.0)

Also am seeing this for the first time: (don't know, but seems unlikely to be related to https://patchwork.kernel.org/patch/87359/ Yet it is the only hit I found for the same message. Looks like it's back to a more stable 3.9.8... (*sigh*) BUG: key 880c1148c478 not in .data! [

Disabling interrupt remapping seems to cause 50% drop in ethernet speed (v3.10)

There seems to be a new check : Comments Neil Horman - April 15, 2013, 4:28 p.m. A few years back intel published a spec update: http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf For the 5520 and

Disabling interrupt remapping seems to cause 50% drop in ethernet speed (v3.10)

There seems to be a new check : Comments Neil Horman mailto:nhor...@tuxdriver.com - April 15, 2013, 4:28 p.m. A few years back intel published a spec update: http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf For the 5520 and 5500

Fwd: BUG: key ffff880c1148c478 not in .data! (V3.10.0)

Also am seeing this for the first time: (don't know, but seems unlikely to be related to https://patchwork.kernel.org/patch/87359/ Yet it is the only hit I found for the same message. Looks like it's back to a more stable 3.9.8... (*sigh*) BUG: key 880c1148c478 not in .data! [

mod filenames != modnames? (inconsistent name changing)

Should we have any expectation that a module name and it's filename should be equivalent? I was writing an auto-complete script for modprobe so it wouldn't give me the option to double load a module (I'd have to manually type it in if I really wanted it). Trouble is some modules with names

mod filenames != modnames? (inconsistent name changing)

Should we have any expectation that a module name and it's filename should be equivalent? I was writing an auto-complete script for modprobe so it wouldn't give me the option to double load a module (I'd have to manually type it in if I really wanted it). Trouble is some modules with names

Re: mount --no-canonical seems broken.

Karel Zak wrote: > On Mon, May 20, 2013 at 04:30:21PM -0700, Linda Walsh wrote: > >> widely known as "df" or "mount". >> >> I might point out that by default, >> >>> findmnt / >>> >> TARGET SOURCEFSTY

Re: mount --no-canonical seems broken.

Karel Zak wrote: On Mon, May 20, 2013 at 04:30:21PM -0700, Linda Walsh wrote: widely known as df or mount. I might point out that by default, findmnt / TARGET SOURCEFSTYPE OPTIONS / /dev/root xfsrw,nodiratime,relatime,attr2,inode64,noquota l /dev

Re: mount --no-canonical seems broken.

Karel Zak wrote: > > The problem is that "mount" (without options) prints always canonicalized > paths (and in this case --no-canonicalize has no effect, this option > is used for mounting only). It means if you have non-canonical paths > in /etc/mtab then "mount" still prints canonical paths.

Re: new mount is broken w/regard to devnames in /etc/fstab

Rob Landley wrote: > On 05/19/2013 12:01:18 AM, Linda Walsh wrote: >> 1) How is one supposed to get the real root device? >> It's not /dev/root -- and on my system /dev/root doesn't even exist. > There was a thread on this a couple months ago: > https://lkml.org/lkml/

Re: new mount is broken w/regard to devnames in /etc/fstab

Rob Landley wrote: On 05/19/2013 12:01:18 AM, Linda Walsh wrote: 1) How is one supposed to get the real root device? It's not /dev/root -- and on my system /dev/root doesn't even exist. There was a thread on this a couple months ago: https://lkml.org/lkml/2013/3/20/315 You can get

Re: mount --no-canonical seems broken.

Karel Zak wrote: The problem is that mount (without options) prints always canonicalized paths (and in this case --no-canonicalize has no effect, this option is used for mounting only). It means if you have non-canonical paths in /etc/mtab then mount still prints canonical paths. I can

new mount is broken w/regard to devnames in /etc/fstab

There are 2 problems -- they are unlikely to be directly related, but are in so much as they are in the new version of mount. 1) How is one supposed to get the real root device? It's not /dev/root -- and on my system /dev/root doesn't even exist. (though to be fair, it has in the past -- udev

new mount is broken w/regard to devnames in /etc/fstab

There are 2 problems -- they are unlikely to be directly related, but are in so much as they are in the new version of mount. 1) How is one supposed to get the real root device? It's not /dev/root -- and on my system /dev/root doesn't even exist. (though to be fair, it has in the past -- udev

Re: upgrade to 3.8.1 : BUG Scheduling while atomic in bonding driver:

Michael Wang wrote: > On 03/02/2013 01:21 PM, Linda Walsh wrote: > Update -- it *used* to stop the messages in 3.6.7. > > It no longer stops the messages in 3.8.1 -- (and isn't present by > default -- tried > adding the unlock/lock -- no difference. > > Weird. *sigh*

Re: upgrade to 3.8.1 : BUG Scheduling while atomic in bonding driver:

Michael Wang wrote: On 03/02/2013 01:21 PM, Linda Walsh wrote: Update -- it *used* to stop the messages in 3.6.7. It no longer stops the messages in 3.8.1 -- (and isn't present by default -- tried adding the unlock/lock -- no difference. Weird. *sigh* Hi, Linda Do you have the BUG

Re: upgrade to 3.8.1 : BUG Scheduling while atomic in bonding driver:

Linda Walsh wrote: > > > This patch is not in the latest kernel. I don't know if it is the > 'best' way, but it does stop BUG error messages. --- Update -- it *used* to stop the messages in 3.6.7. It no longer stops the messages in 3.8.1 -- (and isn't present by default --

upgrade to 3.8.1 : BUG Scheduling while atomic in bonding driver:

Just installed 3.8.1 Thought this had been fixed? Note it causes the kernel to show up as tainted after the 1st... As the system was coming up and initializing the bond0 driver: [ 19.847743] ixgbe :06:00.0: registered PHC device on eth_s2_0 [ 20.258245] BUG: scheduling while

upgrade to 3.8.1 : BUG Scheduling while atomic in bonding driver:

Just installed 3.8.1 Thought this had been fixed? Note it causes the kernel to show up as tainted after the 1st... As the system was coming up and initializing the bond0 driver: [ 19.847743] ixgbe :06:00.0: registered PHC device on eth_s2_0 [ 20.258245] BUG: scheduling while

Re: upgrade to 3.8.1 : BUG Scheduling while atomic in bonding driver:

Linda Walsh wrote: This patch is not in the latest kernel. I don't know if it is the 'best' way, but it does stop BUG error messages. --- Update -- it *used* to stop the messages in 3.6.7. It no longer stops the messages in 3.8.1 -- (and isn't present by default -- tried adding

Re: BUG: scheduling while atomic: ifup-bonding/3711/0x00000002 -- V3.6.7

Jay Vosburgh wrote: --- If I am running 'rr' on 2 channels -- specifically for the purpose of link speed aggregation (getting 1 20Gb channel out of 2 10Gb channels) I'm not sure I see how miimon would provide benefit. -- if 1 link dies, the other, being on the same card is likely to be dead

Re: BUG: scheduling while atomic: ifup-bonding/3711/0x00000002 -- V3.6.7

Jay Vosburgh wrote: --- If I am running 'rr' on 2 channels -- specifically for the purpose of link speed aggregation (getting 1 20Gb channel out of 2 10Gb channels) I'm not sure I see how miimon would provide benefit. -- if 1 link dies, the other, being on the same card is likely to be dead

Re: BUG: scheduling while atomic: ifup-bonding/3711/0x00000002 -- V3.6.7

Sorry for the delay my distro (Suse) has made rebooting my system a chore (have to often boot from rescue to get it to come up because they put mount libs in /usr/lib expecting they will always boot from their ram disk -- preventing those of use who boot directly from disk from doing so

Re: BUG: scheduling while atomic: ifup-bonding/3711/0x00000002 -- V3.6.7

Sorry for the delay my distro (Suse) has made rebooting my system a chore (have to often boot from rescue to get it to come up because they put mount libs in /usr/lib expecting they will always boot from their ram disk -- preventing those of use who boot directly from disk from doing so

Re: BUG: scheduling while atomic: ifup-bonding/3711/0x00000002 -- V3.6.7

Cong Wang wrote: On Wed, Nov 28, 2012 at 4:37 AM, Linda Walsh wrote: Is this a known problem / bug, or should I file a bug on it? Does this quick fix help? ... Thanks! Applied: --- bond_main.c.orig 2012-09-30 16:47:46.0 -0700 +++ bond_main.c 2012-11-28 12:58:34.064931997

Re: BUG: scheduling while atomic: ifup-bonding/3711/0x00000002 -- V3.6.7

Cong Wang wrote: On Wed, Nov 28, 2012 at 4:37 AM, Linda Walsh l...@tlinx.org wrote: Is this a known problem / bug, or should I file a bug on it? Does this quick fix help? ... Thanks! Applied: --- bond_main.c.orig 2012-09-30 16:47:46.0 -0700 +++ bond_main.c 2012-11-28 12:58

BUG: scheduling while atomic: ifup-bonding/3711/0x00000002 -- V3.6.7

Is this a known problem / bug, or should I file a bug on it? It doesn't cause a complete failure, and it happens multiple times (~28 times in 2.5 days?... so maybe 10x/day?) about 8 start with ifup, and the rest start @ kworker -- both happen upon enabling the bonding driver on a 10Gb dual

BUG: scheduling while atomic: ifup-bonding/3711/0x00000002 -- V3.6.7

Is this a known problem / bug, or should I file a bug on it? It doesn't cause a complete failure, and it happens multiple times (~28 times in 2.5 days?... so maybe 10x/day?) about 8 start with ifup, and the rest start @ kworker -- both happen upon enabling the bonding driver on a 10Gb dual

Re: 2 physical-cpu (like 2x6core) config and NUMA?

Jike Song wrote: Do you have anything printed with: # acpidump -a --table SRAT It prints out a bunch of stuff, but the word SRAT wasn't in the output. I don't remember a node interleaving in the BIOS -- There's a ECC mode, where I only get 4/6 slots for usable memory, or an optimized mode

Re: 2 physical-cpu (like 2x6core) config and NUMA?

Jike Song wrote: Do you have anything printed with: # acpidump -a --table SRAT It prints out a bunch of stuff, but the word SRAT wasn't in the output. I don't remember a node interleaving in the BIOS -- There's a ECC mode, where I only get 4/6 slots for usable memory, or an optimized mode

2 physical-cpu (like 2x6core) config and NUMA?

I was wondering, on dual processor MB's, Intel uses dedicated memory for each cpu 6 memchips in the X5XXX series, and to access the memory of the other chip's cores, the memory has to be transferred over the QPI bus. So wouldn't it be of benefit if such dual chip configurations were to be

2 physical-cpu (like 2x6core) config and NUMA?

I was wondering, on dual processor MB's, Intel uses dedicated memory for each cpu 6 memchips in the X5XXX series, and to access the memory of the other chip's cores, the memory has to be transferred over the QPI bus. So wouldn't it be of benefit if such dual chip configurations were to be

NETRTLINK: Device not found moving from 3.2.21 -> 3.3.6, on 2 ethernet interfaces...??? (worse in 3.4)

I tried upgrading directly from 3.2.5 -> 3.4.4. Had two probs (the one mentioned in this email, and inability to set MTU size on the other card under 3.4.4). So, I thought to break it down -- first upgrading to current 3.2 (.22 at the time), then 3.3.6, and then 3.4.4. First was went

NETRTLINK: Device not found moving from 3.2.21 - 3.3.6, on 2 ethernet interfaces...??? (worse in 3.4)

I tried upgrading directly from 3.2.5 - 3.4.4. Had two probs (the one mentioned in this email, and inability to set MTU size on the other card under 3.4.4). So, I thought to break it down -- first upgrading to current 3.2 (.22 at the time), then 3.3.6, and then 3.4.4. First was went

Re: xfsaild causing 30+ wakeups/s on an idle system since 2.6.25-rcX

Not to look excessively dumb, but what's xfsaild? xfs seems to be sprouting daemons at a more rapid pace these days...xfsbufd, xfssyncd, xfsdatad, xfslogd, xfs_mru_cache, and now xfsaild? Not a complaint if it ups performance, but I do sorta wonder what all of them are for and why they are

Re: xfsaild causing 30+ wakeups/s on an idle system since 2.6.25-rcX

Not to look excessively dumb, but what's xfsaild? xfs seems to be sprouting daemons at a more rapid pace these days...xfsbufd, xfssyncd, xfsdatad, xfslogd, xfs_mru_cache, and now xfsaild? Not a complaint if it ups performance, but I do sorta wonder what all of them are for and why they are

Re: Disk schedulers

Lukas Hejtmanek wrote: whom should I blame about disk schedulers? I have the following setup: 1Gb network 2GB RAM disk write speed about 20MB/s If I'm scping file (about 500MB) from the network (which is faster than the local disk), any process is totally unable to read anything from the local

Re: Disk schedulers

Lukas Hejtmanek wrote: whom should I blame about disk schedulers? I have the following setup: 1Gb network 2GB RAM disk write speed about 20MB/s If I'm scping file (about 500MB) from the network (which is faster than the local disk), any process is totally unable to read anything from the local

Re: x86-32-config: why is pc-speaker an input device?

[EMAIL PROTECTED] wrote: The last time around for this question, I was half-paying attention, and the rationale sounded like "We had an input device framework, no output device framework, and too many bad shrooms to do something comprehensible". --- Yeah, hmm...the question I'd have then

x86-32-config: why is pc-speaker an input device?

I'm wondering how the generic, builtin PC-Speaker (config option "INPUT_PCSPKR") can be used as an input device. If it can not be used for input, why is it under the input config section: "Device Drivers" + -> "Input Device Support" + -> "Miscellaneous devices" + -> "PC Speaker

x86-32-config: why is pc-speaker an input device?

I'm wondering how the generic, builtin PC-Speaker (config option INPUT_PCSPKR) can be used as an input device. If it can not be used for input, why is it under the input config section: Device Drivers + - Input Device Support + - Miscellaneous devices + - PC Speaker Support When

Re: x86-32-config: why is pc-speaker an input device?

[EMAIL PROTECTED] wrote: The last time around for this question, I was half-paying attention, and the rationale sounded like We had an input device framework, no output device framework, and too many bad shrooms to do something comprehensible. --- Yeah, hmm...the question I'd have then is

Re: xfs [_fsr] probs in 2.6.24.0

Eric Sandeen wrote: Linda Walsh wrote: David Chinner wrote: Filesystem bugs rarely hang systems hard like that - more likely is a hardware or driver problem. And neither of the lockdep reports below are likely to be responsible for a system wide, no-response hang. --- "Ish&quo

Re: xfs [_fsr] probs in 2.6.24.0

David Chinner wrote: Filesystem bugs rarely hang systems hard like that - more likely is a hardware or driver problem. And neither of the lockdep reports below are likely to be responsible for a system wide, no-response hang. --- "Ish", the 32-bitter, has been the only hard-hanger.

Re: xfs [_fsr] probs in 2.6.24.0

Eric Sandeen wrote: Linda Walsh wrote: David Chinner wrote: Filesystem bugs rarely hang systems hard like that - more likely is a hardware or driver problem. And neither of the lockdep reports below are likely to be responsible for a system wide, no-response hang. --- Ish, the 32

graphics probing messages: questions

Maybe this should go to a more specific list, but I had a question about a dmesg v. Kconfig item. One option under graphics asks about enabling firmware EDID and says should be safe. So it's 'yes' Further down under nVidia FB Support, there is an option "Enable DDC Support" which tries to use

xfs [_fsr] probs in 2.6.24.0

I'm getting similar errors on an x86-32 & x86-64 kernel. The x86-64 system (2nd log below w/date+times) was unusable this morning: one or more of the xfs file systems had "gone off line" due to some unknown error (upon reboot, no errors were indicated; all partitions on the same physical disk).

graphics probing messages: questions

Maybe this should go to a more specific list, but I had a question about a dmesg v. Kconfig item. One option under graphics asks about enabling firmware EDID and says should be safe. So it's 'yes' Further down under nVidia FB Support, there is an option Enable DDC Support which tries to use

xfs [_fsr] probs in 2.6.24.0

I'm getting similar errors on an x86-32 x86-64 kernel. The x86-64 system (2nd log below w/date+times) was unusable this morning: one or more of the xfs file systems had gone off line due to some unknown error (upon reboot, no errors were indicated; all partitions on the same physical disk). I

Re: Known prob: MAX_LOCK_DEPTH too low?

Peter Zijlstra wrote: On Fri, 2008-01-18 at 17:17 -0800, Linda Walsh wrote: On my x86_64 machine, I got the following message in log (kern = 2.6.23.14) Jan 16 04:08:38 Astara kernel: BUG: MAX_LOCK_DEPTH too low! Jan 16 04:08:38 Astara kernel: turning off the locking correctness validator

Known prob: MAX_LOCK_DEPTH too low?

On my x86_64 machine, I got the following message in log (kern = 2.6.23.14) Jan 16 04:08:38 Astara kernel: BUG: MAX_LOCK_DEPTH too low! Jan 16 04:08:38 Astara kernel: turning off the locking correctness validator. Have no idea what caused it as I found the message on my console somewhat after

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

Robert Hancock wrote: If this is a Seagate, I believe that they don't have AAM enabled on any of their newer drives (something about a lawsuit for patent infringement on that feature, or something). Quite likely they don't support that power management command, either. -- Do you have a

Re: Believed resolved: SATA kern-buffRd read slow: based on promise driver bug

Mikael Pettersson wrote: Linda Walsh writes: > Mikael Pettersson wrote: > > Linda Walsh writes: > > > > Linda Walsh wrote: > > > >>>> read rate began falling; (.25 - .3); > > > more importantly; a chronic error message associ

Re: Believed resolved: SATA kern-buffRd read slow: based on promise driver bug

Mikael Pettersson wrote: Linda Walsh writes: Mikael Pettersson wrote: Linda Walsh writes: Linda Walsh wrote: read rate began falling; (.25 - .3); more importantly; a chronic error message associated with drive may be causing some or all of the problem(s

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

Robert Hancock wrote: If this is a Seagate, I believe that they don't have AAM enabled on any of their newer drives (something about a lawsuit for patent infringement on that feature, or something). Quite likely they don't support that power management command, either. -- Do you have a

general config preemption Q: preempt-model and Big-Lock Preemption

A question that comes to mind every time I go through the settings for "Preemption Model" and "Preempt The Big Kernel Lock". Do each of the combinations "make sense", or are some "no-ops"? For model, we have 1) no forced (server), 2) Voluntary (Desktop) 3) preemptible (low-latency Desktop), and

general config preemption Q: preempt-model and Big-Lock Preemption

A question that comes to mind every time I go through the settings for Preemption Model and Preempt The Big Kernel Lock. Do each of the combinations make sense, or are some no-ops? For model, we have 1) no forced (server), 2) Voluntary (Desktop) 3) preemptible (low-latency Desktop), and for Big

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

Robert Hancock wrote: Looks like the drive reports ERR/ABRT (command aborted), meaning it likely doesn't support those commands. --- Except the PATA version of the drive does (same capacity, & other specs). Seagate would disable "advanced" features for SATA but leave them for the older

Re:Believed resolved: SATA kern-buffRd read slow: based on promise driver bug

Mikael Pettersson wrote: Linda Walsh writes: > Robert Hancock wrote: > > Linda Walsh wrote: > >>>> read rate began falling; at 128k block-reads-at-a-time or larger, it > >>>> drops below 20MB/s (only on buffered SATA). > > But more im

Re:Believed resolved: SATA kern-buffRd read slow: based on promise driver bug

Mikael Pettersson wrote: Linda Walsh writes: Robert Hancock wrote: Linda Walsh wrote: read rate began falling; at 128k block-reads-at-a-time or larger, it drops below 20MB/s (only on buffered SATA). But more importantly -- I notice a chronic error message associate

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

Robert Hancock wrote: Looks like the drive reports ERR/ABRT (command aborted), meaning it likely doesn't support those commands. --- Except the PATA version of the drive does (same capacity, other specs). Seagate would disable advanced features for SATA but leave them for the older

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

Robert Hancock wrote: Linda Walsh wrote: Alan Cox wrote: rate began falling; at 128k block-reads-at-a-time or larger, it drops below 20MB/s (only on buffered SATA). Try disabling NCQ - see if you've got a drive with the 'NCQ = no readahead' flaw. http://linux-ata.org/faq.html#ncq

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

Alan Cox wrote: rate began falling; at 128k block-reads-at-a-time or larger, it drops below 20MB/s (only on buffered SATA). Try disabling NCQ - see if you've got a drive with the 'NCQ = no readahead' flaw. --- I'm not aware, off hand, how to disable NCQ. I haven't had any NCQ- or SATA-

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

Holger Hoffstaette wrote: Another new "problem" (not as important) -- even though SATA disks are called with "sdX", my ATA disks that *were* at hda-hdc are now at hde-hdg. Devices hda-hdd are not populated in my dev directory on bootup. Of I think this is because the Promise SATA

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

Holger Hoffstaette wrote: Another new problem (not as important) -- even though SATA disks are called with sdX, my ATA disks that *were* at hda-hdc are now at hde-hdg. Devices hda-hdd are not populated in my dev directory on bootup. Of I think this is because the Promise SATA card

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

Alan Cox wrote: rate began falling; at 128k block-reads-at-a-time or larger, it drops below 20MB/s (only on buffered SATA). Try disabling NCQ - see if you've got a drive with the 'NCQ = no readahead' flaw. --- I'm not aware, off hand, how to disable NCQ. I haven't had any NCQ- or SATA-

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

Robert Hancock wrote: Linda Walsh wrote: Alan Cox wrote: rate began falling; at 128k block-reads-at-a-time or larger, it drops below 20MB/s (only on buffered SATA). Try disabling NCQ - see if you've got a drive with the 'NCQ = no readahead' flaw. http://linux-ata.org/faq.html#ncq

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

Robert Hancock wrote: Have you tried using a different block size to see how that effects the results? There might be some funny interaction there. There is some interaction with the large block size (but only on the SATA disk). Counts were adjusted to keep the read near 2G (~2x

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

Robert Hancock wrote: Have you tried using a different block size to see how that effects the results? There might be some funny interaction there. There is some interaction with the large block size (but only on the SATA disk). Counts were adjusted to keep the read near 2G (~2x

SATA buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

I needed to get a new hard disk for one of my systems and thought that it was about time to start going with SATA. I picked up a Promise 4-Port Sata300-TX4 to go with a 750G Seagate SATA -- I'd had good luck with a Promise ATA100 (P)ATA and lower capacity Seagates and thought it would be a good

SATA buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

I needed to get a new hard disk for one of my systems and thought that it was about time to start going with SATA. I picked up a Promise 4-Port Sata300-TX4 to go with a 750G Seagate SATA -- I'd had good luck with a Promise ATA100 (P)ATA and lower capacity Seagates and thought it would be a good

ConfigQ? arch=i368; AES (generic v. i586)

There are two options for AES cipher algorithms under the Cryptographic API. They read: _ AES Cipher algorithms _ AES Cipher algorithms (i586) --- I assume(?) the i586 is for pentiums of some nature -- but is that any machine pentium(i586) or "newer"(686, P4, Core2, Centrino?). If both options

Config Q?: Preempt Model & Preempt Big Kern Lock

Not big deal, just some config-validity questions regarding i386 preemption models and preemption of the big-kern lock. I.e. the relevant options are: (PM) "Preemption model", there are 3 choices (i386): (none) No Forced Preemption (Server) (vol) Voluntary Preempt (Desktop) (full)

Config Q?: Preempt Model Preempt Big Kern Lock

Not big deal, just some config-validity questions regarding i386 preemption models and preemption of the big-kern lock. I.e. the relevant options are: (PM) Preemption model, there are 3 choices (i386): (none) No Forced Preemption (Server) (vol) Voluntary Preempt (Desktop) (full)

ConfigQ? arch=i368; AES (generic v. i586)

There are two options for AES cipher algorithms under the Cryptographic API. They read: _ AES Cipher algorithms _ AES Cipher algorithms (i586) --- I assume(?) the i586 is for pentiums of some nature -- but is that any machine pentium(i586) or newer(686, P4, Core2, Centrino?). If both options

Re: reboot -df "broken" in 2.6.23.1 (from 2.6.22.12)

More info, the last program executed to reboot was: "reboot -df" (in the "reboot" system script"). That should reboot w/no disk sync and no-wtmp entry (they are done earlier in the program, explicitly). I looked at the reboot code in the kernel for the i386 (arch/i386/kernel/reboot.c). A new

auto-reboot "broken" in 2.6.23.1 (from 2.6.22.12)

Hello, I upgraded the kernel on a multi-cpu Dell workstation (690) to 2.6.23.1. It had been running at 2.6.20. I moved to the new kernel via "make oldconfig" -- choosing defaults. That didn't work. To narrow things down I tried it under 2.6.21.1 (made oldconfig from working

auto-reboot broken in 2.6.23.1 (from 2.6.22.12)

Hello, I upgraded the kernel on a multi-cpu Dell workstation (690) to 2.6.23.1. It had been running at 2.6.20. I moved to the new kernel via make oldconfig -- choosing defaults. That didn't work. To narrow things down I tried it under 2.6.21.1 (made oldconfig from working

Re: reboot -df broken in 2.6.23.1 (from 2.6.22.12)

More info, the last program executed to reboot was: reboot -df (in the reboot system script). That should reboot w/no disk sync and no-wtmp entry (they are done earlier in the program, explicitly). I looked at the reboot code in the kernel for the i386 (arch/i386/kernel/reboot.c). A new

[PATCH] rm_inter-arch Kconfig dep. (was Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch)

Heiko Carstens wrote: > Send a patch. The following seems to work for me. Hope the form is ok. How does one include source if one wants to compose using Firefox? Seems to eat the tabs... :-( Are "text/plain" attachments ok to send to the list? Haven't seen any, but maybe it is not a necessary

[PATCH] rm_inter-arch Kconfig dep. (was Re: building i386 requires s390: driver/crypto/Kconfig sourcing s390 arch)

Heiko Carstens wrote: Send a patch. The following seems to work for me. Hope the form is ok. How does one include source if one wants to compose using Firefox? Seems to eat the tabs... :-( Are text/plain attachments ok to send to the list? Haven't seen any, but maybe it is not a necessary

Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch

Randy Dunlap wrote: if S390 source "arch/s390/crypto/Kconfig" endif Why bother? Why not just move the contents of s390's crypto "Kconfig" in place of the "source" statement. All the options in s390's Kconfig are already conditional depending on S390. The contents simply need to be [moved]

Re: building i386 requires s390: driver/crypto/Kconfig sourcing s390 arch

Randy Dunlap wrote: if S390 source arch/s390/crypto/Kconfig endif Why bother? Why not just move the contents of s390's crypto Kconfig in place of the source statement. All the options in s390's Kconfig are already conditional depending on S390. The contents simply need to be [moved]

Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch

Randy Dunlap wrote: On Fri, 18 May 2007 12:32:47 -0700 Linda Walsh wrote: Seems there is an include of s390 based config in file drivers/crypto/Kconfig: source "arch/s390/crypto/Kconfig" The line doesn't seem to be need for an i386 build (haven't tried x86_64 though

building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch

Seems there is an include of s390 based config in file drivers/crypto/Kconfig: source "arch/s390/crypto/Kconfig" The line doesn't seem to be need for an i386 build (haven't tried x86_64 though). I take it that this was a braino? - To unsubscribe from this list: send the line "unsubscribe

building i386 requires s390: driver/crypto/Kconfig sourcing s390 arch

Seems there is an include of s390 based config in file drivers/crypto/Kconfig: source arch/s390/crypto/Kconfig The line doesn't seem to be need for an i386 build (haven't tried x86_64 though). I take it that this was a braino? - To unsubscribe from this list: send the line unsubscribe

Re: building i386 requires s390: driver/crypto/Kconfig sourcing s390 arch

Randy Dunlap wrote: On Fri, 18 May 2007 12:32:47 -0700 Linda Walsh wrote: Seems there is an include of s390 based config in file drivers/crypto/Kconfig: source arch/s390/crypto/Kconfig The line doesn't seem to be need for an i386 build (haven't tried x86_64 though). I take

Re: Corrupt XFS -Filesystems on new Hardware and Kernel

Oliver Joa wrote: eason or another, xfs has detected a corrupted on-disk inode format which it cannot recognize, and shuts down. Oh, one other thing that may not apply in your case, but may. Does your SATA disk support write caching? Does it support something called a barrier function?

Re: Corrupt XFS -Filesystems on new Hardware and Kernel

Oliver Joa wrote: eason or another, xfs has detected a corrupted on-disk inode format which it cannot recognize, and shuts down. It is likely the result of something which has gone wrong previously. xfs_repair should fix it. Are there other non-xfs messages in your logs indicating other

Re: Corrupt XFS -Filesystems on new Hardware and Kernel

Oliver Joa wrote: eason or another, xfs has detected a corrupted on-disk inode format which it cannot recognize, and shuts down. It is likely the result of something which has gone wrong previously. xfs_repair should fix it. Are there other non-xfs messages in your logs indicating other

Re: Corrupt XFS -Filesystems on new Hardware and Kernel

Oliver Joa wrote: eason or another, xfs has detected a corrupted on-disk inode format which it cannot recognize, and shuts down. Oh, one other thing that may not apply in your case, but may. Does your SATA disk support write caching? Does it support something called a barrier function?

2.6.20/i386 copy_e820_map debug messages left "on" during boot

Just verifying -- It's probably already fixed, but when the e820_map routine was moved to a separate file in the 386 architecture, what appear to be debugging messages were left "on" for display on boot. Were(/are) these intended to be temporary? Linux version 2.6.20 ([EMAIL PROTECTED]) (gcc

  1   2   >