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 ./scri

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 4

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 fro

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"

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! [4.429474

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 5500

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 w/und

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: > > 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

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 m

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. *s

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 presen

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 ato

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 to

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 easily

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

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

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 t

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 neede

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 i

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 Suppo

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. Si

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 i

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).

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 so

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

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 f

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: 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.o

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- capa

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)

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 physi

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 c

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)

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 "s

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 2.6.20/proc/confi

[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: 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 l

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 pro

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 ver

lock checking feedback (bug?) 2.6.20(xfs)/i386 during boot

Turned on lock testing/proving/deadlock detection. Not chasing any particular problem, but looking for things "oddities". Turned on options (under kernel hacking): Locking API boot-time self-tests RT Mutex debugging, deadlock detection Lock debugging: prove locking correctness Multiple r

Re: PM-Timer clock source is slow. Try something else: How slow? What other source(s)?

Srinivasa Ds wrote: You can change the clock source using "clock=" kernel parameter. Please refer to Documentation/kernel-parameters.txt file of kernel source. --- Uh, yeah...you mean the "clock=" parameter that is "deprecated"? :-) *cough* *sigh* thanks, Linda - To unsubsc

PM-Timer clock source is slow. Try something else: How slow? What other source(s)?

I recently noticed this message in my bootup that I don't remember from before: PCI: Probing PCI hardware (bus 00) * Found PM-Timer Bug on the chipset. Due to workarounds for a bug, * this clock source is slow. Consider trying other clock sources -- How would this affect my clock? It says

WARNING in 2.6.18.2 (ACPI) Section mismatch...

MODPOST WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0x14de) and 'acpi_processor_power_exit' AS arch/i386/boot/compressed/head.o Turned on APCI and am now getting the above warning. Did a ma

Re: 2.4 Cpu usuage (display oddities more than anything)

Some oddities w/kapmd(2.4.0)... If I sit in X and do nothing other than run top or "vmstat 5", I get down to as low as 60% idle and 40% in system -- with kapmd getting 'charged' for the 40%. Then I go and run 'freeamp' and the CPU usage goes to 100% idle, presumably because kapmd never gets call

Re: 2.4 disk speed 66% slowdown...

ATA-2 ATA-3 ATA-4 UDMA mode (2) seems to be identical to before. Andre Hedrick wrote: > > On Tue, 23 Jan 2001, Florin Andrei wrote: > > > Linda Walsh wrote: > > > > > > The REAL problem was in disk performance. The apm made no difference: > >

Re: 2.4 disk speed 66% slowdown...

I think we're on to something. I did gen's of the kernel with the following configs: 1) 2.2.17 (w/apm), 2) 2.4(w/apm), 3) 2.4(w/o apm). The apm seems to be a red herring in terms of actual performance hit. It seems to count apm time as 'system' time instead of 'idle'. Kernel gen times were: 1)

RE: Large File support and blocks.

With all the talk about bugs and slowness on a 386/486/586 -- does anyone think those platforms will have multi-T disks hooked up to them? Now bugs in the compiler are a problem, but at some point in the future, one would hope we could move to a compiler that can handle division w/no problems.

RE: Large File support and blocks.

nology, Core Linux, SGI [EMAIL PROTECTED] | Voice: (650) 933-5338 > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Richard > Henderson > Sent: Thursday, August 31, 2000 9:51 PM > To: Matti Aarnio >

RE: Large File support and blocks.

And the below is what percentage of time doing disk i/o? > Just put this in a loop and time it. Change SIZE to long long, and do > it again! It doesn't scale well. The long long code is nearly 10 times > slower! You can do `gcc -S -o xxx name.c` and see why. > > > #define SIZE long > > SIZE

RE: Large File support and blocks.

> It is propably from reasoning of: > > "there is really no point in it, as at 32bit systems >int and long are same size, thus same limit comes >with both types." > > At 64-bit machines there is, of course, definite difference. ---

RE: Large File support and blocks.

Ooopsthe time frame is closer to today on part of this. While it may be a while before we hit the 1T limit on 1 single device, things like readpage, do so based of the inode -- which on a metadisk could have a filesize much larger than current physical device limits. So it seems that at leas

Large File support and blocks.

It may not matter too too much, but blocks are being passed around as 'ints'. On the ia32 architecture, this implies a maximum of 512*2G->1T disk size. Probably don't need to worry about this today, but in a few years? Should we be changing the internal interfaces to use a long (or a long unsig