Re: [PATCH] Update documentation to reflect what TAINT_CPU_OUT_OF_SPEC means nowadays
Hello, On Tue, Dec 08, 2020 at 09:58:32AM -0800, Randy Dunlap wrote: > On 12/8/20 9:54 AM, Jonathan Corbet wrote: > > On Wed, 2 Dec 2020 16:32:43 +0100 > > Mathieu Chouquet-Stringer wrote: > >> Signed-off-by: Mathieu Chouquet-Stringer > > > > Hearing no objection, I've applied this. Thanks Jon. > Hm, I was glad to read this new info since my old testing laptop > now tells me that it needs a microcode update. :( In my case I first saw the error because tuned uses x86_energy_perf_policy which uses to poke at MSRs [1]. And that was tainting my kernel and I initially couldn't understand why. It's been fixed but will be released in an upcoming kernel version (it's in tip at the moment [2]). Thanks to Borislav for work and for helping me out! [1] https://lore.kernel.org/lkml/20201117210018.GA4247@weirdfishes/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=fe0a5788624c8b8f113a35bbe4636e37f9321241 -- Mathieu Chouquet-Stringer me@mathieu.digital The sun itself sees not till heaven clears. -- William Shakespeare --
[PATCH] Update documentation to reflect what TAINT_CPU_OUT_OF_SPEC means nowadays
Hello Jonathan, Here's a patch updating the meaning of TAINT_CPU_OUT_OF_SPEC after Borislav introduced changes in a7e1f67ed29f and upcoming patches in tip. TAINT_CPU_OUT_OF_SPEC now means a bit more what it implies as the flag isn't set just because of a CPU misconfiguration or mismatch. Historically it was for SMP kernel oops on an officially SMP incapable processor but now it also covers CPUs whose MSRs have been incorrectly poked at from userspace, drivers being used on non supported architectures, broken firmware, mismatched CPUs, ... Update documentation and script to reflect that. Signed-off-by: Mathieu Chouquet-Stringer --- Documentation/admin-guide/sysctl/kernel.rst | 2 +- Documentation/admin-guide/tainted-kernels.rst | 23 +++ tools/debugging/kernel-chktaint | 2 +- 3 files changed, 20 insertions(+), 7 deletions(-) diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index d4b32cc32bb7..edd89e2d3af7 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -1336,7 +1336,7 @@ ORed together. The letters are seen in "Tainted" line of Oops reports. == = == 1 `(P)` proprietary module was loaded 2 `(F)` module was force loaded - 4 `(S)` SMP kernel oops on an officially SMP incapable processor + 4 `(S)` kernel running on an out of specification system 8 `(R)` module was force unloaded 16 `(M)` processor reported a Machine Check Exception (MCE) 32 `(B)` bad page referenced or some unexpected page flags diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst index f718a2eaf1f6..ceeed7b0798d 100644 --- a/Documentation/admin-guide/tainted-kernels.rst +++ b/Documentation/admin-guide/tainted-kernels.rst @@ -84,7 +84,7 @@ Bit Log Number Reason that got the kernel tainted === === == 0 G/P 1 proprietary module was loaded 1 _/F 2 module was force loaded - 2 _/S 4 SMP kernel oops on an officially SMP incapable processor + 2 _/S 4 kernel running on an out of specification system 3 _/R 8 module was force unloaded 4 _/M 16 processor reported a Machine Check Exception (MCE) 5 _/B 32 bad page referenced or some unexpected page flags @@ -116,10 +116,23 @@ More detailed explanation for tainting 1) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all modules were loaded normally. - 2) ``S`` if the oops occurred on an SMP kernel running on hardware that - hasn't been certified as safe to run multiprocessor. - Currently this occurs only on various Athlons that are not - SMP capable. + 2) ``S`` if the kernel is running on a processor or system that is out of + specification: hardware has been put into an unsupported configuration, + therefore proper execution cannot be guaranteed. + Kernel will be tainted if, for example: + + - on x86: PAE is forced through forcepae on intel CPUs (such as Pentium M) + which do not report PAE but may have a functional implementation, an SMP + kernel is running on non officially capable SMP Athlon CPUs, MSRs are + being poked at from userspace. + - on arm: kernel running on certain CPUs (such as Keystone 2) without + having certain kernel features enabled. + - on arm64: there are mismatched hardware features between CPUs, the + bootloader has booted CPUs in different modes. + - certain drivers are being used on non supported architectures (such as + scsi/snic on something else than x86_64, scsi/ips on non + x86/x86_64/itanium, have broken firmware settings for the + irqchip/irq-gic on arm64 ...). 3) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all modules were unloaded normally. diff --git a/tools/debugging/kernel-chktaint b/tools/debugging/kernel-chktaint index 2240cb56e6e5..607b2b280945 100755 --- a/tools/debugging/kernel-chktaint +++ b/tools/debugging/kernel-chktaint @@ -72,7 +72,7 @@ if [ `expr $T % 2` -eq 0 ]; then addout " " else addout "S" - echo " * SMP kernel oops on an officially SMP incapable processor (#2)" + echo " * kernel running on an out of specification system (#2)" fi T=`expr $T / 2` -- 2.28.0
Re: [PATCH] x86/msr: Filter MSR writes
Hey Borislav, On Thu, Nov 19, 2020 at 11:53:44AM +0100, Mathieu Chouquet-Stringer wrote: > On Wed, Nov 18, 2020 at 06:50:48PM +0100, Borislav Petkov wrote: > > Please fix the text in Documentation/admin-guide/sysctl/kernel.rst also. > > Done. I haven't heard from you, what did you think of my last patch? -- Mathieu Chouquet-Stringer me@mathieu.digital The sun itself sees not till heaven clears. -- William Shakespeare --
Re: [PATCH] x86/msr: Filter MSR writes
On Wed, Nov 18, 2020 at 06:50:48PM +0100, Borislav Petkov wrote: > Please fix the text in Documentation/admin-guide/sysctl/kernel.rst also. Done. > People might wonder what "out of specifications" means. I'd say > something along the lines of "the CPU has been put into a not supported > configuration, therefore proper execution cannot be guaranteed". Grep > the tree for TAINT_CPU_OUT_OF_SPEC to see when this gets set, might give > you a better idea of what to say. Did the grep thing and it showed it's not just a CPU thing as drivers can also set that flag hence why I use "system" instead of CPU now. > And here you can expand on the examples by saying that poking at random > MSRs from userspace is one possible way to mis-configure it. I added almost all examples I found to the documentation. > Yeah, can you think of a better formulation than "out of spec > processor"? > > The CPU is fine, only its current configuration is not. Given it can be something else than just a CPU thing which tainted the kernel, I use out of spec system as there are too many cases to have a clear simple short definition. I mean I've yet to find a better explanation... So what about that patch? --- TAINT_CPU_OUT_OF_SPEC now means what a bit more than what it implies as the flag isn't set just because of a CPU misconfiguration or mismatch. Historically it was for SMP kernel oops on an officially SMP incapable processor but now it also covers CPUs whose MSRs have been incorrectly poked at from userspace, drivers being used on non supported architectures, broken firmware, mismatched CPUs, ... Update documentation and script to reflect that. Signed-off-by: Mathieu Chouquet-Stringer --- Documentation/admin-guide/sysctl/kernel.rst | 2 +- Documentation/admin-guide/tainted-kernels.rst | 22 +- tools/debugging/kernel-chktaint | 2 +- 3 files changed, 19 insertions(+), 7 deletions(-) diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index d4b32cc32bb7..edd89e2d3af7 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -1336,7 +1336,7 @@ ORed together. The letters are seen in "Tainted" line of Oops reports. == = == 1 `(P)` proprietary module was loaded 2 `(F)` module was force loaded - 4 `(S)` SMP kernel oops on an officially SMP incapable processor + 4 `(S)` kernel running on an out of specification system 8 `(R)` module was force unloaded 16 `(M)` processor reported a Machine Check Exception (MCE) 32 `(B)` bad page referenced or some unexpected page flags diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst index f718a2eaf1f6..5737dfa17cd1 100644 --- a/Documentation/admin-guide/tainted-kernels.rst +++ b/Documentation/admin-guide/tainted-kernels.rst @@ -84,7 +84,7 @@ Bit Log Number Reason that got the kernel tainted === === == 0 G/P 1 proprietary module was loaded 1 _/F 2 module was force loaded - 2 _/S 4 SMP kernel oops on an officially SMP incapable processor + 2 _/S 4 kernel running on an out of specification system 3 _/R 8 module was force unloaded 4 _/M 16 processor reported a Machine Check Exception (MCE) 5 _/B 32 bad page referenced or some unexpected page flags @@ -116,10 +116,22 @@ More detailed explanation for tainting 1) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all modules were loaded normally. - 2) ``S`` if the oops occurred on an SMP kernel running on hardware that - hasn't been certified as safe to run multiprocessor. - Currently this occurs only on various Athlons that are not - SMP capable. + 2) ``S`` if the kernel is running on a processor or system that is out of + specification: hardware has been put into an unsupported configuration, + therefore proper execution cannot be guaranteed. + Kernel will be tainted for example if: + + - on x86: you force PAE on intel CPUs, you run a SMP kernel on non + officially capable SMP Athlon CPUs, you poke at random MSRs from + userspace. + - on arm: you run a kernel on certain CPUs (such as Keystone 2) without + having certain kernel features enabled. + - on arm64: you have mismatched hardware features between CPUs, the + bootloader has booted CPUs in different modes. + - you use certain drivers on non supported architectures (such as + scsi/snic on something else than x86_64, scsi/ips on non + x86/x86_64/itanium, have broken firmware settings for the + irqchip/irq-gic on arm64 ...). 3) ``R`` if a module w
[PATCH] x86/msr: Filter MSR writes
On Wed, Nov 18, 2020 at 12:50:27PM +0100, Borislav Petkov wrote: > On Wed, Nov 18, 2020 at 10:09:29AM +0100, Mathieu Chouquet-Stringer wrote: > > Speaking of doc, looking at the patches you submitted, I didn't see any > > update to the documentation. Would you like me to create a patch for > > that? > > Sure, that would be appreciated. Here you go, let me know if I got that right... --- TAINT_CPU_OUT_OF_SPEC now means what it says. Historically it was for SMP kernel oops on an officially SMP incapable processor but now it also covers CPUs whose MSRs have been incorrectly poked at. Update documentation and script to reflect that. Signed-off-by: Mathieu Chouquet-Stringer --- Documentation/admin-guide/tainted-kernels.rst | 11 ++- tools/debugging/kernel-chktaint | 2 +- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst index f718a2eaf1f6..95f432c43ba0 100644 --- a/Documentation/admin-guide/tainted-kernels.rst +++ b/Documentation/admin-guide/tainted-kernels.rst @@ -84,7 +84,7 @@ Bit Log Number Reason that got the kernel tainted === === == 0 G/P 1 proprietary module was loaded 1 _/F 2 module was force loaded - 2 _/S 4 SMP kernel oops on an officially SMP incapable processor + 2 _/S 4 kernel running on out of spec processor 3 _/R 8 module was force unloaded 4 _/M 16 processor reported a Machine Check Exception (MCE) 5 _/B 32 bad page referenced or some unexpected page flags @@ -116,10 +116,11 @@ More detailed explanation for tainting 1) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all modules were loaded normally. - 2) ``S`` if the oops occurred on an SMP kernel running on hardware that - hasn't been certified as safe to run multiprocessor. - Currently this occurs only on various Athlons that are not - SMP capable. + 2) ``S`` if the kernel is running on any processor that is out of + specifications (writing to MSRs will trigger this behavior). + Historically, it could also be if an oops occured on a kernel running on + hardware that hasn't been certified as safe to run multiprocessor, such + as various Athlons that are not SMP capable. 3) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all modules were unloaded normally. diff --git a/tools/debugging/kernel-chktaint b/tools/debugging/kernel-chktaint index 2240cb56e6e5..0b9d93e27910 100755 --- a/tools/debugging/kernel-chktaint +++ b/tools/debugging/kernel-chktaint @@ -72,7 +72,7 @@ if [ `expr $T % 2` -eq 0 ]; then addout " " else addout "S" - echo " * SMP kernel oops on an officially SMP incapable processor (#2)" + echo " * kernel running on out of spec processor (#2)" fi T=`expr $T / 2`
Re: [PATCH -v2.1] x86/msr: Filter MSR writes
On Tue, Nov 17, 2020 at 10:20:16PM +0100, Borislav Petkov wrote: > I agree with the update-the-documentation aspect - S does not mean only > SMP kernel on !SMP-capable CPU but the more general, CPU is out of spec. Speaking of doc, looking at the patches you submitted, I didn't see any update to the documentation. Would you like me to create a patch for that? -- Mathieu Chouquet-Stringer me@mathieu.digital The sun itself sees not till heaven clears. -- William Shakespeare --
Re: [PATCH -v2.1] x86/msr: Filter MSR writes
On Tue, Nov 17, 2020 at 01:22:49PM -0800, Matthew Garrett wrote: > > MSR_IA32_ENERGY_PERF_BIAS (cc: Len Brown, who tried mightily to > > convince me I was wrong here) on the grounds that it was exporting an > > implementation detail rather than providing a generic interface, and > > that it was something that could be done via userland instead. I > > thought we'd end up with more examples of similar functionality and > > could tie it into something more reasonable - history has proven me > > wrong on that. I think it's probably reasonable to dust off the driver > > that Len submitted however many years ago and push that into the > > kernel now. > > But ha ok based on Borislav's response it looks like someone's already > done that. Indeed, all is good. Just have to wait for it to be merged and the proper kernel to be released... -- Mathieu Chouquet-Stringer me@mathieu.digital The sun itself sees not till heaven clears. -- William Shakespeare --
Re: [PATCH -v2.1] x86/msr: Filter MSR writes
On Tue, Nov 17, 2020 at 10:20:16PM +0100, Borislav Petkov wrote: > Not for long: > > https://git.kernel.org/tip/fe0a5788624c8b8f113a35bbe4636e37f9321241 That's fantastic. > Because if you poke at random MSRs and you manage to "configure" your > CPU to run "out of spec" - this is what the taint flag is called: > TAINT_CPU_OUT_OF_SPEC - then this is exactly the case you've created: a > CPU executing outside of specifications. Don't get me wrong, it makes total sense to do that, it's just the original reason of !SMP-capable isn't so clear while CPU out of spec is. -- Mathieu Chouquet-Stringer me@mathieu.digital The sun itself sees not till heaven clears. -- William Shakespeare --
Re: [PATCH -v2.1] x86/msr: Filter MSR writes
Hello all, On Tue, Jul 14, 2020 at 12:17:50PM -0700, Matthew Garrett wrote: > On Tue, Jul 14, 2020 at 9:04 AM Chris Down wrote: > > Either way, again, this isn't really the point. :-) The point is that there > > _are_ currently widespread cases involving poking MSRs from userspace, > > however > > sacrilegious or ugly (which I agree with!), and while people should be told > > about that, it's excessive to have the potential to take up 80% of kmsg in > > the > > default configuration. It doesn't take thousands of messages to get the > > message > > across, that's what a custom printk ratelimit is for. > Agreed - we should now offer all the necessary interfaces to avoid > userspace having to hit MSRs directly for thermal management, but that > wasn't always the case, and as a result there's tooling that still > behaves this way. I'm late to the party but it seems allowing MSR_IA32_ENERGY_PERF_BIAS has the downside of flagging the kernel as tainted without telling you why if you use something like x86_energy_perf_policy (from tools/power/x86/x86_energy_perf_policy) which itself is used by tuned. I can taint my kernel manually by just running: x86_energy_perf_policy -c all performance The net impact is an OOPS triggered on such kernel won't necessarily be read by anyone nor analyzed by reporting tools as the kernel is now considered tainted. For instance abrt reports the following: ===8<===8<===8<===8<===8<===8< A kernel problem occurred, but your kernel has been tainted (flags:GS). Explanation: S - SMP with CPUs not designed for SMP. Kernel maintainers are unable to diagnose tainted reports. ===8<===8<===8<===8<===8<===8< To add to the confusion, kernel documentation (Documentation/admin-guide/tainted-kernels.rst) is not up to date so while looking for an explanation, one gets to wonder how what used to be a regular average computer can now be classified as something using "an officially SMP incapable processor"... So while both documentation and tools should be updated as to be clearer and to not taint the kernel respectively, there's something that remains to be done to explain why or how the kernel got tainted because of poking into MSRs... -- Mathieu Chouquet-Stringer The sun itself sees not till heaven clears. -- William Shakespeare --
Re: [Ilw] iwlwifi/iwldvm soft lockup with 3.8.0-rc5 (was: almost unusable on 3.8.0-rc5)
On Tue, Jan 29, 2013 at 10:14 AM, Mathieu Chouquet-Stringer wrote: > On Tue, Jan 29, 2013 at 8:16 AM, Grumbach, Emmanuel > wrote: >> Please try this one: >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c3e5d7181afb66657393066bccce0956fab09ab3 >> >> as you can see, it is in mainline already. > > Ha, that was fast! I'll check tonight, thanks for your quick turn around. Issue is indeed fixed: thank you! -- 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: [Ilw] iwlwifi/iwldvm soft lockup with 3.8.0-rc5 (was: almost unusable on 3.8.0-rc5)
On Tue, Jan 29, 2013 at 10:14 AM, Mathieu Chouquet-Stringer math...@csetco.com wrote: On Tue, Jan 29, 2013 at 8:16 AM, Grumbach, Emmanuel emmanuel.grumb...@intel.com wrote: Please try this one: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c3e5d7181afb66657393066bccce0956fab09ab3 as you can see, it is in mainline already. Ha, that was fast! I'll check tonight, thanks for your quick turn around. Issue is indeed fixed: thank you! -- 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: [Ilw] iwlwifi/iwldvm soft lockup with 3.8.0-rc5 (was: almost unusable on 3.8.0-rc5)
Hello Emmanuel, On Tue, Jan 29, 2013 at 8:16 AM, Grumbach, Emmanuel wrote: > Please try this one: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c3e5d7181afb66657393066bccce0956fab09ab3 > > as you can see, it is in mainline already. Ha, that was fast! I'll check tonight, thanks for your quick turn around. -- 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: [Ilw] iwlwifi/iwldvm soft lockup with 3.8.0-rc5 (was: almost unusable on 3.8.0-rc5)
Hello Emmanuel, On Tue, Jan 29, 2013 at 8:16 AM, Grumbach, Emmanuel emmanuel.grumb...@intel.com wrote: Please try this one: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c3e5d7181afb66657393066bccce0956fab09ab3 as you can see, it is in mainline already. Ha, that was fast! I'll check tonight, thanks for your quick turn around. -- 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/
iwlwifi/iwldvm soft lockup with 3.8.0-rc5 (was: almost unusable on 3.8.0-rc5)
Hello all, Oh the irony, I was just starting an email saying wifi is almost unusable for me with 3.8 and my machine (a thinkpad t530) completely froze while typing it... I was going to say I'm getting a lot of: iwlwifi :03:00.0: fail to flush all tx fifo queues with this device: 03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 3e) Subsystem: Intel Corporation Centrino Ultimate-N 6300 3x3 AGN Kernel driver in use: iwlwifi But now I will be able to give you links to the actual soft lockup: http://mathieu.csetco.com/iwlwifi/iwlwifi-oops1.jpeg http://mathieu.csetco.com/iwlwifi/iwlwifi-oops2.jpeg http://mathieu.csetco.com/iwlwifi/iwlwifi-oops3.jpeg The same machine works perfectly fine with a vanilla 3.7. On 3.8, before the machine froze I could see my download speed going up and down like crazy (that's what prompted the "almost unusable" comment, it's so painful loading a web page feels like being on dialup). A rough text version is a follow: BUG: soft lockup - CPU#1 stuck for 23s! [...] Call Trace: iwl_trans_pcie_stop_device+0x15c/0x1c0 [iwlwifi] iwl_down+0x1fd/0x300 [iwldvm] iwlagn_prepare_restart+0x4f/0xd0 [iwldvm] ? idle_balance+0x110/0x2f0 iwl_bg_restart+0x52/0xe0 [iwldvm] process_one_work+0x147/0x490 ? iwl_op_mode_dvm_start+0xa50/0xa50 [iwldvm] [...] After that I the whole thing was frozen: keyboard/mouse would still work but no IO would go whatsoever (even disk)... The "fail to flush all tx fifo queues" are easy to reproduce: I get that by copying file around / downloading and browsing the web. Let me know if I can help in any way (like decoding addresses). Cheers, -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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/
iwlwifi/iwldvm soft lockup with 3.8.0-rc5 (was: almost unusable on 3.8.0-rc5)
Hello all, Oh the irony, I was just starting an email saying wifi is almost unusable for me with 3.8 and my machine (a thinkpad t530) completely froze while typing it... I was going to say I'm getting a lot of: iwlwifi :03:00.0: fail to flush all tx fifo queues with this device: 03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 3e) Subsystem: Intel Corporation Centrino Ultimate-N 6300 3x3 AGN Kernel driver in use: iwlwifi But now I will be able to give you links to the actual soft lockup: http://mathieu.csetco.com/iwlwifi/iwlwifi-oops1.jpeg http://mathieu.csetco.com/iwlwifi/iwlwifi-oops2.jpeg http://mathieu.csetco.com/iwlwifi/iwlwifi-oops3.jpeg The same machine works perfectly fine with a vanilla 3.7. On 3.8, before the machine froze I could see my download speed going up and down like crazy (that's what prompted the almost unusable comment, it's so painful loading a web page feels like being on dialup). A rough text version is a follow: BUG: soft lockup - CPU#1 stuck for 23s! [...] Call Trace: iwl_trans_pcie_stop_device+0x15c/0x1c0 [iwlwifi] iwl_down+0x1fd/0x300 [iwldvm] iwlagn_prepare_restart+0x4f/0xd0 [iwldvm] ? idle_balance+0x110/0x2f0 iwl_bg_restart+0x52/0xe0 [iwldvm] process_one_work+0x147/0x490 ? iwl_op_mode_dvm_start+0xa50/0xa50 [iwldvm] [...] After that I the whole thing was frozen: keyboard/mouse would still work but no IO would go whatsoever (even disk)... The fail to flush all tx fifo queues are easy to reproduce: I get that by copying file around / downloading and browsing the web. Let me know if I can help in any way (like decoding addresses). Cheers, -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: GPF in read_extent_buffer while scrubbing on 3.7.0-rc8-00014-g27d7c2a
Hi, Anyone has any idea about what I should try next regarding this bug? On Mon, Dec 10, 2012 at 11:21:25PM +0100, Mathieu Chouquet-Stringer wrote: > after enabling page alloc and slub debug, I was able to capture an error > followed by the "usual" GPF. More below. > > On Thu, Dec 06, 2012 at 03:34:58PM +0100, Mathieu Chouquet-Stringer wrote: > > Using the last couple of kernels (3.6 or 3.7), scrubbing my btrfs fs (which > > is > > on a luks based lvm device) will always end up crashing my pc. > > [...] > > The warning: > WARNING: at fs/btrfs/extent_io.c:4680 read_extent_buffer+0xee/0x120() > Hardware name: 2392CTO > Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast > ipt_MASQUERADE ip6table_mangle ip6t_REJECT lockd sunrpc nf_conntrack_ipv6 > nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat_ipv4 nf_nat > iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack > rfcomm bnep arc4 iwldvm mac80211 iTCO_wdt iTCO_vendor_support > snd_hda_codec_realtek coretemp kvm_intel kvm microcode uvcvideo > videobuf2_vmalloc videobuf2_memops pcspkr videobuf2_core videodev btusb media > i2c_i801 bluetooth snd_hda_intel snd_hda_codec cdc_ncm usbnet mii cdc_wdm > cdc_acm snd_hwdep snd_seq snd_seq_device snd_pcm lpc_ich mfd_core iwlwifi > cfg80211 e1000e snd_page_alloc mei snd_timer thinkpad_acpi snd soundcore > rfkill uinput dm_crypt crc32c_intel nouveau ghash_clmulni_intel mxm_wmi ttm > i915 i2c_algo_bit drm_kms_helper firewire_ohci drm sdhci_pci firewire_core > sdhci mmc_core crc_itu_t i2c_core wmi video > Pid: 536, comm: btrfs-endio-met Not tainted 3.7.0-rc8-00039-ged23ec4 #4 > Call Trace: > [] warn_slowpath_common+0x7f/0xc0 > [] warn_slowpath_null+0x1a/0x20 > [] read_extent_buffer+0xee/0x120 > [] btrfs_node_key+0x22/0x30 > [] __readahead_hook.isra.5+0x3a0/0x3f0 > [] btree_readahead_hook+0x24/0x40 > [] btree_readpage_end_io_hook+0x139/0x290 > [] end_bio_extent_readpage+0xd3/0xa40 > [] ? end_workqueue_fn+0x36/0x50 > [] bio_endio+0x1d/0x30 > [] end_workqueue_fn+0x41/0x50 > [] worker_loop+0x136/0x580 > [] ? btrfs_queue_worker+0x300/0x300 > [] kthread+0xc0/0xd0 > [] ? kthread_create_on_node+0x120/0x120 > [] ret_from_fork+0x7c/0xb0 > [] ? kthread_create_on_node+0x120/0x120 > > gdb says it's this WARN ON: > (gdb) l *(read_extent_buffer + 0xee) > 0x726e is in read_extent_buffer (fs/btrfs/extent_io.c:4680). > 4675char *kaddr; > 4676char *dst = (char *)dstv; > 4677size_t start_offset = eb->start & ((u64)PAGE_CACHE_SIZE - 1); > 4678unsigned long i = (start_offset + start) >> PAGE_CACHE_SHIFT; > 4679 > > 4680WARN_ON(start > eb->len); > > 4681WARN_ON(start + len > eb->start + eb->len); > 4682 > 4683offset = (start_offset + start) & ((unsigned > long)PAGE_CACHE_SIZE - 1); > 4684 > > The GPF which follows right after is: > general protection fault: [#1] SMP DEBUG_PAGEALLOC > Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast > ipt_MASQUERADE ip6table_mangle ip6t_REJECT lockd sunrpc nf_conntrack_ipv6 > nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat_ipv4 nf_nat > iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack > rfcomm bnep arc4 iwldvm mac80211 iTCO_wdt iTCO_vendor_support > snd_hda_codec_realtek coretemp kvm_intel kvm microcode uvcvideo > videobuf2_vmalloc videobuf2_memops pcspkr videobuf2_core videodev btusb media > i2c_i801 bluetooth snd_hda_intel snd_hda_codec cdc_ncm usbnet mii cdc_wdm > cdc_acm snd_hwdep snd_seq snd_seq_device snd_pcm lpc_ich mfd_core iwlwifi > cfg80211 e1000e snd_page_alloc mei snd_timer thinkpad_acpi snd soundcore > rfkill uinput dm_crypt crc32c_intel nouveau ghash_clmulni_intel mxm_wmi ttm > i915 i2c_algo_bit drm_kms_helper firewire_ohci drm sdhci_pci firewire_core > sdhci mmc_core crc_itu_t i2c_core wmi video > CPU 1 > Pid: 536, comm: btrfs-endio-met Tainted: GW > 3.7.0-rc8-00039-ged23ec4 #4 LENOVO 2392CTO/2392CTO > RIP: 0010:[] [] memcpy+0x6/0x110 > RSP: 0018:8804215a9b70 EFLAGS: 00010207 > RAX: 8804215a9c57 RBX: 0011 RCX: 0011 > RDX: 0011 RSI: 00050803 RDI: 8804215a9c57 > RBP: 8804215a9bb8 R08: R09: 0486 > R10: 0001 R11: 00aa R12: 8804215a9c68 > R13: 8803f4c5cfc0 R14: 0048 R15: 0011 > FS: () GS:88043e24() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7fe992197000 CR3: 01c0b000 CR4: 001407e0 >
Re: GPF in read_extent_buffer while scrubbing on 3.7.0-rc8-00014-g27d7c2a
Hi, Anyone has any idea about what I should try next regarding this bug? On Mon, Dec 10, 2012 at 11:21:25PM +0100, Mathieu Chouquet-Stringer wrote: after enabling page alloc and slub debug, I was able to capture an error followed by the usual GPF. More below. On Thu, Dec 06, 2012 at 03:34:58PM +0100, Mathieu Chouquet-Stringer wrote: Using the last couple of kernels (3.6 or 3.7), scrubbing my btrfs fs (which is on a luks based lvm device) will always end up crashing my pc. [...] The warning: WARNING: at fs/btrfs/extent_io.c:4680 read_extent_buffer+0xee/0x120() Hardware name: 2392CTO Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep arc4 iwldvm mac80211 iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek coretemp kvm_intel kvm microcode uvcvideo videobuf2_vmalloc videobuf2_memops pcspkr videobuf2_core videodev btusb media i2c_i801 bluetooth snd_hda_intel snd_hda_codec cdc_ncm usbnet mii cdc_wdm cdc_acm snd_hwdep snd_seq snd_seq_device snd_pcm lpc_ich mfd_core iwlwifi cfg80211 e1000e snd_page_alloc mei snd_timer thinkpad_acpi snd soundcore rfkill uinput dm_crypt crc32c_intel nouveau ghash_clmulni_intel mxm_wmi ttm i915 i2c_algo_bit drm_kms_helper firewire_ohci drm sdhci_pci firewire_core sdhci mmc_core crc_itu_t i2c_core wmi video Pid: 536, comm: btrfs-endio-met Not tainted 3.7.0-rc8-00039-ged23ec4 #4 Call Trace: [8104bebf] warn_slowpath_common+0x7f/0xc0 [8104bf1a] warn_slowpath_null+0x1a/0x20 [812aae9e] read_extent_buffer+0xee/0x120 [812a1bb2] btrfs_node_key+0x22/0x30 [812dd720] __readahead_hook.isra.5+0x3a0/0x3f0 [812ddb14] btree_readahead_hook+0x24/0x40 [81286069] btree_readpage_end_io_hook+0x139/0x290 [812a6ff3] end_bio_extent_readpage+0xd3/0xa40 [812853a6] ? end_workqueue_fn+0x36/0x50 [811b27ed] bio_endio+0x1d/0x30 [812853b1] end_workqueue_fn+0x41/0x50 [812b5916] worker_loop+0x136/0x580 [812b57e0] ? btrfs_queue_worker+0x300/0x300 [8106f480] kthread+0xc0/0xd0 [8106f3c0] ? kthread_create_on_node+0x120/0x120 [8168e8ec] ret_from_fork+0x7c/0xb0 [8106f3c0] ? kthread_create_on_node+0x120/0x120 gdb says it's this WARN ON: (gdb) l *(read_extent_buffer + 0xee) 0x726e is in read_extent_buffer (fs/btrfs/extent_io.c:4680). 4675char *kaddr; 4676char *dst = (char *)dstv; 4677size_t start_offset = eb-start ((u64)PAGE_CACHE_SIZE - 1); 4678unsigned long i = (start_offset + start) PAGE_CACHE_SHIFT; 4679 4680WARN_ON(start eb-len); 4681WARN_ON(start + len eb-start + eb-len); 4682 4683offset = (start_offset + start) ((unsigned long)PAGE_CACHE_SIZE - 1); 4684 The GPF which follows right after is: general protection fault: [#1] SMP DEBUG_PAGEALLOC Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep arc4 iwldvm mac80211 iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek coretemp kvm_intel kvm microcode uvcvideo videobuf2_vmalloc videobuf2_memops pcspkr videobuf2_core videodev btusb media i2c_i801 bluetooth snd_hda_intel snd_hda_codec cdc_ncm usbnet mii cdc_wdm cdc_acm snd_hwdep snd_seq snd_seq_device snd_pcm lpc_ich mfd_core iwlwifi cfg80211 e1000e snd_page_alloc mei snd_timer thinkpad_acpi snd soundcore rfkill uinput dm_crypt crc32c_intel nouveau ghash_clmulni_intel mxm_wmi ttm i915 i2c_algo_bit drm_kms_helper firewire_ohci drm sdhci_pci firewire_core sdhci mmc_core crc_itu_t i2c_core wmi video CPU 1 Pid: 536, comm: btrfs-endio-met Tainted: GW 3.7.0-rc8-00039-ged23ec4 #4 LENOVO 2392CTO/2392CTO RIP: 0010:[8136c756] [8136c756] memcpy+0x6/0x110 RSP: 0018:8804215a9b70 EFLAGS: 00010207 RAX: 8804215a9c57 RBX: 0011 RCX: 0011 RDX: 0011 RSI: 00050803 RDI: 8804215a9c57 RBP: 8804215a9bb8 R08: R09: 0486 R10: 0001 R11: 00aa R12: 8804215a9c68 R13: 8803f4c5cfc0 R14: 0048 R15: 0011 FS: () GS:88043e24() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fe992197000 CR3: 01c0b000 CR4: 001407e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400
Re: GPF in read_extent_buffer while scrubbing on 3.7.0-rc8-00014-g27d7c2a
Hi again, after enabling page alloc and slub debug, I was able to capture an error followed by the "usual" GPF. More below. On Thu, Dec 06, 2012 at 03:34:58PM +0100, Mathieu Chouquet-Stringer wrote: > Using the last couple of kernels (3.6 or 3.7), scrubbing my btrfs fs (which is > on a luks based lvm device) will always end up crashing my pc. > [...] The warning: WARNING: at fs/btrfs/extent_io.c:4680 read_extent_buffer+0xee/0x120() Hardware name: 2392CTO Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep arc4 iwldvm mac80211 iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek coretemp kvm_intel kvm microcode uvcvideo videobuf2_vmalloc videobuf2_memops pcspkr videobuf2_core videodev btusb media i2c_i801 bluetooth snd_hda_intel snd_hda_codec cdc_ncm usbnet mii cdc_wdm cdc_acm snd_hwdep snd_seq snd_seq_device snd_pcm lpc_ich mfd_core iwlwifi cfg80211 e1000e snd_page_alloc mei snd_timer thinkpad_acpi snd soundcore rfkill uinput dm_crypt crc32c_intel nouveau ghash_clmulni_intel mxm_wmi ttm i915 i2c_algo_bit drm_kms_helper firewire_ohci drm sdhci_pci firewire_core sdhci mmc_core crc_itu_t i2c_core wmi video Pid: 536, comm: btrfs-endio-met Not tainted 3.7.0-rc8-00039-ged23ec4 #4 Call Trace: [] warn_slowpath_common+0x7f/0xc0 [] warn_slowpath_null+0x1a/0x20 [] read_extent_buffer+0xee/0x120 [] btrfs_node_key+0x22/0x30 [] __readahead_hook.isra.5+0x3a0/0x3f0 [] btree_readahead_hook+0x24/0x40 [] btree_readpage_end_io_hook+0x139/0x290 [] end_bio_extent_readpage+0xd3/0xa40 [] ? end_workqueue_fn+0x36/0x50 [] bio_endio+0x1d/0x30 [] end_workqueue_fn+0x41/0x50 [] worker_loop+0x136/0x580 [] ? btrfs_queue_worker+0x300/0x300 [] kthread+0xc0/0xd0 [] ? kthread_create_on_node+0x120/0x120 [] ret_from_fork+0x7c/0xb0 [] ? kthread_create_on_node+0x120/0x120 gdb says it's this WARN ON: (gdb) l *(read_extent_buffer + 0xee) 0x726e is in read_extent_buffer (fs/btrfs/extent_io.c:4680). 4675char *kaddr; 4676char *dst = (char *)dstv; 4677size_t start_offset = eb->start & ((u64)PAGE_CACHE_SIZE - 1); 4678unsigned long i = (start_offset + start) >> PAGE_CACHE_SHIFT; 4679 4680WARN_ON(start > eb->len); 4681WARN_ON(start + len > eb->start + eb->len); 4682 4683offset = (start_offset + start) & ((unsigned long)PAGE_CACHE_SIZE - 1); 4684 The GPF which follows right after is: general protection fault: [#1] SMP DEBUG_PAGEALLOC Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep arc4 iwldvm mac80211 iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek coretemp kvm_intel kvm microcode uvcvideo videobuf2_vmalloc videobuf2_memops pcspkr videobuf2_core videodev btusb media i2c_i801 bluetooth snd_hda_intel snd_hda_codec cdc_ncm usbnet mii cdc_wdm cdc_acm snd_hwdep snd_seq snd_seq_device snd_pcm lpc_ich mfd_core iwlwifi cfg80211 e1000e snd_page_alloc mei snd_timer thinkpad_acpi snd soundcore rfkill uinput dm_crypt crc32c_intel nouveau ghash_clmulni_intel mxm_wmi ttm i915 i2c_algo_bit drm_kms_helper firewire_ohci drm sdhci_pci firewire_core sdhci mmc_core crc_itu_t i2c_core wmi video CPU 1 Pid: 536, comm: btrfs-endio-met Tainted: GW3.7.0-rc8-00039-ged23ec4 #4 LENOVO 2392CTO/2392CTO RIP: 0010:[] [] memcpy+0x6/0x110 RSP: 0018:8804215a9b70 EFLAGS: 00010207 RAX: 8804215a9c57 RBX: 0011 RCX: 0011 RDX: 0011 RSI: 00050803 RDI: 8804215a9c57 RBP: 8804215a9bb8 R08: R09: 0486 R10: 0001 R11: 00aa R12: 8804215a9c68 R13: 8803f4c5cfc0 R14: 0048 R15: 0011 FS: () GS:88043e24() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fe992197000 CR3: 01c0b000 CR4: 001407e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process btrfs-endio-met (pid: 536, threadinfo 8804215a8000, task 8804224eb0e0) Stack: 812aae73 8804105ea000 8003 1000 8804215a9c20 03dd 88041232a7c0 8804215a9c20 aeb3f3fe4e814d8e 8804215a9bc8 812a1bb2 8804215a9c98 Call Trace: [] ? read_extent_buffer+0xc3/0x120 [] btrfs_node_key+0x22/0x30 [] __readahead_hook.isra.5+0x3a0/0x3f0 [] btree_readahead_hook+0x24/0x40 [] btree_readpage_
Re: GPF in read_extent_buffer while scrubbing on 3.7.0-rc8-00014-g27d7c2a
Hi again, after enabling page alloc and slub debug, I was able to capture an error followed by the usual GPF. More below. On Thu, Dec 06, 2012 at 03:34:58PM +0100, Mathieu Chouquet-Stringer wrote: Using the last couple of kernels (3.6 or 3.7), scrubbing my btrfs fs (which is on a luks based lvm device) will always end up crashing my pc. [...] The warning: WARNING: at fs/btrfs/extent_io.c:4680 read_extent_buffer+0xee/0x120() Hardware name: 2392CTO Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep arc4 iwldvm mac80211 iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek coretemp kvm_intel kvm microcode uvcvideo videobuf2_vmalloc videobuf2_memops pcspkr videobuf2_core videodev btusb media i2c_i801 bluetooth snd_hda_intel snd_hda_codec cdc_ncm usbnet mii cdc_wdm cdc_acm snd_hwdep snd_seq snd_seq_device snd_pcm lpc_ich mfd_core iwlwifi cfg80211 e1000e snd_page_alloc mei snd_timer thinkpad_acpi snd soundcore rfkill uinput dm_crypt crc32c_intel nouveau ghash_clmulni_intel mxm_wmi ttm i915 i2c_algo_bit drm_kms_helper firewire_ohci drm sdhci_pci firewire_core sdhci mmc_core crc_itu_t i2c_core wmi video Pid: 536, comm: btrfs-endio-met Not tainted 3.7.0-rc8-00039-ged23ec4 #4 Call Trace: [8104bebf] warn_slowpath_common+0x7f/0xc0 [8104bf1a] warn_slowpath_null+0x1a/0x20 [812aae9e] read_extent_buffer+0xee/0x120 [812a1bb2] btrfs_node_key+0x22/0x30 [812dd720] __readahead_hook.isra.5+0x3a0/0x3f0 [812ddb14] btree_readahead_hook+0x24/0x40 [81286069] btree_readpage_end_io_hook+0x139/0x290 [812a6ff3] end_bio_extent_readpage+0xd3/0xa40 [812853a6] ? end_workqueue_fn+0x36/0x50 [811b27ed] bio_endio+0x1d/0x30 [812853b1] end_workqueue_fn+0x41/0x50 [812b5916] worker_loop+0x136/0x580 [812b57e0] ? btrfs_queue_worker+0x300/0x300 [8106f480] kthread+0xc0/0xd0 [8106f3c0] ? kthread_create_on_node+0x120/0x120 [8168e8ec] ret_from_fork+0x7c/0xb0 [8106f3c0] ? kthread_create_on_node+0x120/0x120 gdb says it's this WARN ON: (gdb) l *(read_extent_buffer + 0xee) 0x726e is in read_extent_buffer (fs/btrfs/extent_io.c:4680). 4675char *kaddr; 4676char *dst = (char *)dstv; 4677size_t start_offset = eb-start ((u64)PAGE_CACHE_SIZE - 1); 4678unsigned long i = (start_offset + start) PAGE_CACHE_SHIFT; 4679 4680WARN_ON(start eb-len); 4681WARN_ON(start + len eb-start + eb-len); 4682 4683offset = (start_offset + start) ((unsigned long)PAGE_CACHE_SIZE - 1); 4684 The GPF which follows right after is: general protection fault: [#1] SMP DEBUG_PAGEALLOC Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep arc4 iwldvm mac80211 iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek coretemp kvm_intel kvm microcode uvcvideo videobuf2_vmalloc videobuf2_memops pcspkr videobuf2_core videodev btusb media i2c_i801 bluetooth snd_hda_intel snd_hda_codec cdc_ncm usbnet mii cdc_wdm cdc_acm snd_hwdep snd_seq snd_seq_device snd_pcm lpc_ich mfd_core iwlwifi cfg80211 e1000e snd_page_alloc mei snd_timer thinkpad_acpi snd soundcore rfkill uinput dm_crypt crc32c_intel nouveau ghash_clmulni_intel mxm_wmi ttm i915 i2c_algo_bit drm_kms_helper firewire_ohci drm sdhci_pci firewire_core sdhci mmc_core crc_itu_t i2c_core wmi video CPU 1 Pid: 536, comm: btrfs-endio-met Tainted: GW3.7.0-rc8-00039-ged23ec4 #4 LENOVO 2392CTO/2392CTO RIP: 0010:[8136c756] [8136c756] memcpy+0x6/0x110 RSP: 0018:8804215a9b70 EFLAGS: 00010207 RAX: 8804215a9c57 RBX: 0011 RCX: 0011 RDX: 0011 RSI: 00050803 RDI: 8804215a9c57 RBP: 8804215a9bb8 R08: R09: 0486 R10: 0001 R11: 00aa R12: 8804215a9c68 R13: 8803f4c5cfc0 R14: 0048 R15: 0011 FS: () GS:88043e24() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fe992197000 CR3: 01c0b000 CR4: 001407e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process btrfs-endio-met (pid: 536, threadinfo 8804215a8000, task 8804224eb0e0) Stack: 812aae73 8804105ea000 8003 1000 8804215a9c20 03dd 88041232a7c0 8804215a9c20
[Nouveau] Regression on a NV30 card: garbled output
[ DRM] BMP version 5.41 [2.635608] nouveau [ DRM] Bios version 04.34.20.84 [2.635861] nouveau [ DRM] DCB version 2.2 [2.636123] nouveau [ DRM] DCB outp 00: 01000300 88b8 [2.636377] nouveau [ DRM] DCB outp 01: 02010310 88b8 [2.636631] nouveau [ DRM] DCB outp 02: 01000302 [2.636884] nouveau [ DRM] DCB outp 03: 04010312 [2.637923] nouveau [ DRM] Saving VGA fonts [2.719185] nouveau [ DRM] 0xB64D: Parsing digital output script table [2.769474] nouveau [ DRM] 0xB73A: Parsing digital output script table [2.820886] nouveau [ DRM] 0 available performance level(s) [2.821155] nouveau [ DRM] c: core 252MHz memory 405MHz [2.822667] nouveau [ DRM] MM: using M2MF for buffer copies [2.909675] nouveau [ DRM] allocated 1280x1024 fb: 0x9000, bo 880137aa3000 [2.910502] fbcon: nouveaufb (fb0) is primary device [2.926568] nouveau [ DRM] 0xB64D: Parsing digital output script table [2.990085] nouveau [ DRM] 0xB73A: Parsing digital output script table Is there anything I could do to help? Verbose output? Cheers, -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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/
[Nouveau] Regression on a NV30 card: garbled output
[ DRM] BMP version 5.41 [2.635608] nouveau [ DRM] Bios version 04.34.20.84 [2.635861] nouveau [ DRM] DCB version 2.2 [2.636123] nouveau [ DRM] DCB outp 00: 01000300 88b8 [2.636377] nouveau [ DRM] DCB outp 01: 02010310 88b8 [2.636631] nouveau [ DRM] DCB outp 02: 01000302 [2.636884] nouveau [ DRM] DCB outp 03: 04010312 [2.637923] nouveau [ DRM] Saving VGA fonts [2.719185] nouveau [ DRM] 0xB64D: Parsing digital output script table [2.769474] nouveau [ DRM] 0xB73A: Parsing digital output script table [2.820886] nouveau [ DRM] 0 available performance level(s) [2.821155] nouveau [ DRM] c: core 252MHz memory 405MHz [2.822667] nouveau [ DRM] MM: using M2MF for buffer copies [2.909675] nouveau [ DRM] allocated 1280x1024 fb: 0x9000, bo 880137aa3000 [2.910502] fbcon: nouveaufb (fb0) is primary device [2.926568] nouveau [ DRM] 0xB64D: Parsing digital output script table [2.990085] nouveau [ DRM] 0xB73A: Parsing digital output script table Is there anything I could do to help? Verbose output? Cheers, -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Nouveau regression between 3.6 and 3.7-rc3: driver stuck at "running init tables"
On Tue, Oct 30, 2012 at 03:12:59PM +1000, Ben Skeggs wrote: > Not sure what's up with the hang yet, however, I noticed the issue [1] > which is likely causing the error messages from nouveau's i2c code. > With some luck, it'll stop triggering whatever bug is making it hang in > the VBIOS init table parser. Just tested that and it works (TM). So yeah, that fixed it. Thanks. Reported-by: Mathieu Chouquet-Stringer Tested-by: Mathieu Chouquet-Stringer -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Nouveau regression between 3.6 and 3.7-rc3: driver stuck at running init tables
On Tue, Oct 30, 2012 at 03:12:59PM +1000, Ben Skeggs wrote: Not sure what's up with the hang yet, however, I noticed the issue [1] which is likely causing the error messages from nouveau's i2c code. With some luck, it'll stop triggering whatever bug is making it hang in the VBIOS init table parser. Just tested that and it works (TM). So yeah, that fixed it. Thanks. Reported-by: Mathieu Chouquet-Stringer math...@csetco.com Tested-by: Mathieu Chouquet-Stringer math...@csetco.com -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Nouveau regression between 3.6 and 3.7-rc3: driver stuck at "running init tables"
Hi again, On Tue, Oct 30, 2012 at 09:15:59AM +1000, Ben Skeggs wrote: > Are you able to go back to the current master, and get me a > log/screenshot with "nouveau.debug=trace" appended to your kernel > options? Hmmm I did just that on v3.7-rc3-8-g35fd3dc and it doesn't seem to output more stuff: http://mathieu.csetco.com/nouveau.jpeg -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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: Nouveau regression between 3.6 and 3.7-rc3: driver stuck at running init tables
Hi again, On Tue, Oct 30, 2012 at 09:15:59AM +1000, Ben Skeggs wrote: Are you able to go back to the current master, and get me a log/screenshot with nouveau.debug=trace appended to your kernel options? Hmmm I did just that on v3.7-rc3-8-g35fd3dc and it doesn't seem to output more stuff: http://mathieu.csetco.com/nouveau.jpeg -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES
On Thu, Oct 04, 2007 at 05:12:11PM -0700, Linus Torvalds wrote: > I also tested that "ulimit -s" seems to do the right thing for me. > > I'm also assuming Mathieu is running x86 (or x86-64): HP-PA has a stack > that grows upwards, and that has traditionally been exciting. Correct, x86 it is but as I said it's this stupid auditd thing that breaks the whole process. I'm gonna file a bug against it. Thanks for the help though. -- Mathieu Chouquet-Stringer [EMAIL PROTECTED] The sun itself sees not till heaven clears. -- William Shakespeare -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES
On Thu, Oct 04, 2007 at 07:17:50PM +0200, Peter Zijlstra wrote: > what happens if you up the stack limit to say 128M ? > > Also, do you happen to have execve syscall audit stuff enabled? Actually, you were right, not only it's enabled but it's also the culprit. If I stop it, all is well... Sorry for the noise. -- Mathieu Chouquet-Stringer [EMAIL PROTECTED] The sun itself sees not till heaven clears. -- William Shakespeare -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES
On Thu, Oct 04, 2007 at 05:50:00PM -0400, Chuck Ebbert wrote: > On 10/04/2007 01:05 PM, Mathieu Chouquet-Stringer wrote: > > In the kernel source tree, if I run a stupid find | xargs ls, I now get > > this: > > xargs: ls: Argument list too long > > > > Can you strace it to see what syscall is failing? Sure: 25789 <... execve resumed> )= -1 E2BIG (Argument list too long) I'm going to reboot to a kernel that has Linus' printks... -- Mathieu Chouquet-Stringer [EMAIL PROTECTED] The sun itself sees not till heaven clears. -- William Shakespeare -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES
On Thu, Oct 04, 2007 at 07:17:50PM +0200, Peter Zijlstra wrote: > /me tries > > yep works like a charm, and that is a tree with a full git repo and > several build dirs in it. Well, what can I say? ;-) > what happens if you up the stack limit to say 128M ? It's unlimited. > Also, do you happen to have execve syscall audit stuff enabled? Nope. -- Mathieu Chouquet-Stringer [EMAIL PROTECTED] The sun itself sees not till heaven clears. -- William Shakespeare -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES
Thank you for getting back to me. On Thu, Oct 04, 2007 at 10:27:52AM -0700, Linus Torvalds wrote: > What does your "ulimit -s" say? That's actually the first thing I checked. mchouque - /usr/src/kernel/linux %ulimit -s unlimited And for the record, ulimit -a yields: -t: cpu time (seconds) unlimited -f: file size (blocks) unlimited -d: data seg size (kbytes) unlimited -s: stack size (kbytes)unlimited -c: core file size (blocks)0 -m: resident set size (kbytes) unlimited -u: processes 16375 -n: file descriptors 1024 -l: locked-in-memory size (kb) 32 -v: address space (kb) unlimited -x: file locks unlimited -i: pending signals16375 -q: bytes in POSIX msg queues 819200 -N 13: 0 -N 14: 0 > I suspect that you might hit the code that limits execve() arguments to > one quarter of the maximum stack size. > > We could change that from 25% to something else (half? three quarters?), > but if you really are hitting that limit, it sounds like you may have a > really small stack size to begin with (ie if 25% is smaller than the old > argument size limit of 128kB, you're running with a stack limit of less > than half a meg, which sounds pretty dang small). > > So I'd like to verify that the stack limit really is the issue, and not > something else. Anything else you'd like me to try? -- Mathieu Chouquet-Stringer [EMAIL PROTECTED] The sun itself sees not till heaven clears. -- William Shakespeare -- - 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/
[BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES
Hey there, I've seen the changes you made in commit b6a2fea39318 and I guess they might be responsible for my xargs breakage... In the kernel source tree, if I run a stupid find | xargs ls, I now get this: xargs: ls: Argument list too long Which is kind of annoying but I can work around it though make distclean in my kernel tree dies with the same symptom (aka -E2BIG). I run a vanilla 2.6.23-rc9 (Linux version 2.6.23-rc9 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-27)) #1 Tue Oct 2 08:13:47 EDT 2007) on FC7... Let me know if I can do anything. I'm going to try to bisect the problem after I recompile the kernel without this patch... Best, Mathieu [EMAIL PROTECTED] (Linus Torvalds) writes: > I said I was hoping that -rc8 was the last -rc, and I hate doing this, but > we've had more changes since -rc8 than we had in -rc8. And while most of > them are pretty trivial, I really couldn't face doing a 2.6.23 release and > take the risk of some really stupid brown-paper-bag thing. > [...] -- Mathieu Chouquet-Stringer [EMAIL PROTECTED] The sun itself sees not till heaven clears. -- William Shakespeare -- - 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/
[BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES
Hey there, I've seen the changes you made in commit b6a2fea39318 and I guess they might be responsible for my xargs breakage... In the kernel source tree, if I run a stupid find | xargs ls, I now get this: xargs: ls: Argument list too long Which is kind of annoying but I can work around it though make distclean in my kernel tree dies with the same symptom (aka -E2BIG). I run a vanilla 2.6.23-rc9 (Linux version 2.6.23-rc9 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-27)) #1 Tue Oct 2 08:13:47 EDT 2007) on FC7... Let me know if I can do anything. I'm going to try to bisect the problem after I recompile the kernel without this patch... Best, Mathieu [EMAIL PROTECTED] (Linus Torvalds) writes: I said I was hoping that -rc8 was the last -rc, and I hate doing this, but we've had more changes since -rc8 than we had in -rc8. And while most of them are pretty trivial, I really couldn't face doing a 2.6.23 release and take the risk of some really stupid brown-paper-bag thing. [...] -- Mathieu Chouquet-Stringer [EMAIL PROTECTED] The sun itself sees not till heaven clears. -- William Shakespeare -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES
Thank you for getting back to me. On Thu, Oct 04, 2007 at 10:27:52AM -0700, Linus Torvalds wrote: What does your ulimit -s say? That's actually the first thing I checked. mchouque - /usr/src/kernel/linux %ulimit -s unlimited And for the record, ulimit -a yields: -t: cpu time (seconds) unlimited -f: file size (blocks) unlimited -d: data seg size (kbytes) unlimited -s: stack size (kbytes)unlimited -c: core file size (blocks)0 -m: resident set size (kbytes) unlimited -u: processes 16375 -n: file descriptors 1024 -l: locked-in-memory size (kb) 32 -v: address space (kb) unlimited -x: file locks unlimited -i: pending signals16375 -q: bytes in POSIX msg queues 819200 -N 13: 0 -N 14: 0 I suspect that you might hit the code that limits execve() arguments to one quarter of the maximum stack size. We could change that from 25% to something else (half? three quarters?), but if you really are hitting that limit, it sounds like you may have a really small stack size to begin with (ie if 25% is smaller than the old argument size limit of 128kB, you're running with a stack limit of less than half a meg, which sounds pretty dang small). So I'd like to verify that the stack limit really is the issue, and not something else. Anything else you'd like me to try? -- Mathieu Chouquet-Stringer [EMAIL PROTECTED] The sun itself sees not till heaven clears. -- William Shakespeare -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES
On Thu, Oct 04, 2007 at 07:17:50PM +0200, Peter Zijlstra wrote: /me tries yep works like a charm, and that is a tree with a full git repo and several build dirs in it. Well, what can I say? ;-) what happens if you up the stack limit to say 128M ? It's unlimited. Also, do you happen to have execve syscall audit stuff enabled? Nope. -- Mathieu Chouquet-Stringer [EMAIL PROTECTED] The sun itself sees not till heaven clears. -- William Shakespeare -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES
On Thu, Oct 04, 2007 at 05:50:00PM -0400, Chuck Ebbert wrote: On 10/04/2007 01:05 PM, Mathieu Chouquet-Stringer wrote: In the kernel source tree, if I run a stupid find | xargs ls, I now get this: xargs: ls: Argument list too long Can you strace it to see what syscall is failing? Sure: 25789 ... execve resumed )= -1 E2BIG (Argument list too long) I'm going to reboot to a kernel that has Linus' printks... -- Mathieu Chouquet-Stringer [EMAIL PROTECTED] The sun itself sees not till heaven clears. -- William Shakespeare -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES
On Thu, Oct 04, 2007 at 07:17:50PM +0200, Peter Zijlstra wrote: what happens if you up the stack limit to say 128M ? Also, do you happen to have execve syscall audit stuff enabled? Actually, you were right, not only it's enabled but it's also the culprit. If I stop it, all is well... Sorry for the noise. -- Mathieu Chouquet-Stringer [EMAIL PROTECTED] The sun itself sees not till heaven clears. -- William Shakespeare -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES
On Thu, Oct 04, 2007 at 05:12:11PM -0700, Linus Torvalds wrote: I also tested that ulimit -s seems to do the right thing for me. I'm also assuming Mathieu is running x86 (or x86-64): HP-PA has a stack that grows upwards, and that has traditionally been exciting. Correct, x86 it is but as I said it's this stupid auditd thing that breaks the whole process. I'm gonna file a bug against it. Thanks for the help though. -- Mathieu Chouquet-Stringer [EMAIL PROTECTED] The sun itself sees not till heaven clears. -- William Shakespeare -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.6.20.4 Unaligned address
Hello,
[EMAIL PROTECTED] (David Miller) writes:
> Please report sparc platform bugs to sparclinux@vger.kernel.org next
> time, thank you.
>
> Meanwhile I'll take a look at this one.
I have a similar problem on an U5 [*] running 2.6.21-rc6-gbbef6181 :
Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0
Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0
Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0
Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0
Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0
Disassembling vmlinux gives me that:
0x006c993c : call 0x5999c8
0x006c9940 : clr %o0
0x006c9944 : call 0x6c7d4c
0x006c9948 : mov %l3, %o0
0x006c994c : ld [ %l1 + 0x88 ], %g2
0x006c9950 : ldx [ %l5 + 8 ], %g3
0x006c9954 : mov 0x11, %g1
0x006c9958 : add %g2, -8, %i0
0x006c995c : st %g1, [ %l4 + 0xdc8 ]
0x006c9960 : cmp %g3, 8
0x006c9964 : be,pn %xcc,
0x6c999c
The same stuff but using objdump this time:
21c4: R_SPARC_WDISP30 clear_bit
21c8: 90 10 20 00 clr %o0
21cc: 7f ff f9 02 call 5d4
21d0: 90 10 00 13 mov %l3, %o0
21d4: c4 04 60 88 ld [ %l1 + 0x88 ], %g2
21d8: c6 5d 60 08 ldx [ %l5 + 8 ], %g3
21dc: 82 10 20 11 mov 0x11, %g1
21e0: b0 00 bf f8 add %g2, -8, %i0
21e4: c2 25 2d c8 st %g1, [ %l4 + 0xdc8 ]
21e8: 80 a0 e0 08 cmp %g3, 8
21ec: 02 60 00 0e be,pn %xcc, 2224
21f0: f0 25 21 24 st %i0, [ %l4 + 0x124 ]
21f4: 40 00 00 00 call 21f4
21f4: R_SPARC_WDISP30 net_ratelimit
Looking at svc_udp_recvfrom, it all comes down to this portion of code (I
believe, unless I got it wrong):
/*
* Maybe more packets - kick another thread ASAP.
*/
svc_sock_received(svsk);
len = skb->len - sizeof(struct udphdr);
rqstp->rq_arg.len = len;<=
rqstp->rq_prot = IPPROTO_UDP;
if (cmh->cmsg_level != IPPROTO_IP ||
cmh->cmsg_type != IP_PKTINFO) {
if (net_ratelimit())
printk("rpcsvc: received unknown control message:"
"%d/%d\n",
cmh->cmsg_level, cmh->cmsg_type);
skb_free_datagram(svsk->sk_sk, skb);
return 0;
}
I won't have access to this box for quite some time: I'm just unsure when I
will be able to test again any kind of patches...
I hope I've forwarded enough information though.
Cheers,
Mathieu
[*] :
cpu : TI UltraSparc IIi (Sabre)
fpu : UltraSparc IIi integrated FPU
prom: OBP 3.31.0 2001/07/25 20:36
type: sun4u
ncpus probed: 1
ncpus active: 1
D$ parity tl1 : 0
I$ parity tl1 : 0
Cpu0Bogo: 720.40
Cpu0ClkTck : 15752a00
MMU Type: Spitfire
Kernel got compiled with:
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-cpu=v8
--enable-checking=release sparc-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
--
Mathieu Chouquet-Stringer
The sun itself sees not till heaven clears.
-- William Shakespeare --
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.6.20.4 Unaligned address
Hello,
[EMAIL PROTECTED] (David Miller) writes:
Please report sparc platform bugs to sparclinux@vger.kernel.org next
time, thank you.
Meanwhile I'll take a look at this one.
I have a similar problem on an U5 [*] running 2.6.21-rc6-gbbef6181 :
Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0
Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0
Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0
Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0
Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0
Disassembling vmlinux gives me that:
0x006c993c svc_udp_recvfrom+512: call 0x5999c8 clear_bit
0x006c9940 svc_udp_recvfrom+516: clr %o0
0x006c9944 svc_udp_recvfrom+520: call 0x6c7d4c svc_sock_enqueue
0x006c9948 svc_udp_recvfrom+524: mov %l3, %o0
0x006c994c svc_udp_recvfrom+528: ld [ %l1 + 0x88 ], %g2
0x006c9950 svc_udp_recvfrom+532: ldx [ %l5 + 8 ], %g3
0x006c9954 svc_udp_recvfrom+536: mov 0x11, %g1
0x006c9958 svc_udp_recvfrom+540: add %g2, -8, %i0
0x006c995c svc_udp_recvfrom+544: st %g1, [ %l4 + 0xdc8 ]
0x006c9960 svc_udp_recvfrom+548: cmp %g3, 8
0x006c9964 svc_udp_recvfrom+552: be,pn %xcc,
0x6c999csvc_udp_recvfrom+608
The same stuff but using objdump this time:
21c4: R_SPARC_WDISP30 clear_bit
21c8: 90 10 20 00 clr %o0
21cc: 7f ff f9 02 call 5d4 svc_sock_enqueue
21d0: 90 10 00 13 mov %l3, %o0
21d4: c4 04 60 88 ld [ %l1 + 0x88 ], %g2
21d8: c6 5d 60 08 ldx [ %l5 + 8 ], %g3
21dc: 82 10 20 11 mov 0x11, %g1
21e0: b0 00 bf f8 add %g2, -8, %i0
21e4: c2 25 2d c8 st %g1, [ %l4 + 0xdc8 ]
21e8: 80 a0 e0 08 cmp %g3, 8
21ec: 02 60 00 0e be,pn %xcc, 2224 svc_udp_recvfrom+0x260
21f0: f0 25 21 24 st %i0, [ %l4 + 0x124 ]
21f4: 40 00 00 00 call 21f4 svc_udp_recvfrom+0x230
21f4: R_SPARC_WDISP30 net_ratelimit
Looking at svc_udp_recvfrom, it all comes down to this portion of code (I
believe, unless I got it wrong):
/*
* Maybe more packets - kick another thread ASAP.
*/
svc_sock_received(svsk);
len = skb-len - sizeof(struct udphdr);
rqstp-rq_arg.len = len;=
rqstp-rq_prot = IPPROTO_UDP;
if (cmh-cmsg_level != IPPROTO_IP ||
cmh-cmsg_type != IP_PKTINFO) {
if (net_ratelimit())
printk(rpcsvc: received unknown control message:
%d/%d\n,
cmh-cmsg_level, cmh-cmsg_type);
skb_free_datagram(svsk-sk_sk, skb);
return 0;
}
I won't have access to this box for quite some time: I'm just unsure when I
will be able to test again any kind of patches...
I hope I've forwarded enough information though.
Cheers,
Mathieu
[*] :
cpu : TI UltraSparc IIi (Sabre)
fpu : UltraSparc IIi integrated FPU
prom: OBP 3.31.0 2001/07/25 20:36
type: sun4u
ncpus probed: 1
ncpus active: 1
D$ parity tl1 : 0
I$ parity tl1 : 0
Cpu0Bogo: 720.40
Cpu0ClkTck : 15752a00
MMU Type: Spitfire
Kernel got compiled with:
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-cpu=v8
--enable-checking=release sparc-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
--
Mathieu Chouquet-Stringer
The sun itself sees not till heaven clears.
-- William Shakespeare --
-
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: cifs kernel module and MS DFS shares [2.6.12-1.1411_FC4]
[EMAIL PROTECTED] (Thomas Chiverton) writes: > [EMAIL PROTECTED] gbb_domain]# mount.cifs //exchsvr/dfs /mnt/dfs/ -o > user=tchiverton,domain=BLUEFINGER > Password: > [EMAIL PROTECTED] gbb_domain]# ls /mnt/dfs/ > Applications Consultants Engineering ManagementVersion > CommonDirectorsFinance Software Development WinTA Data > [EMAIL PROTECTED] gbb_domain]# ls /mnt/dfs/Consultants/ > Applications Consultants Engineering ManagementVersion > CommonDirectorsFinance Software Development WinTA Data > [EMAIL PROTECTED] gbb_domain]# I've got the same issue but if I go down 2 or 3 levels, it works (ie continue to go down the same directory until you see a valid content). Even better, I can cd into non existing directories and it "works" (as in I still see the content of the mountpoint). So using your example, to see the real content of Consultants, I would have to do this: cd /mnt/dfs/Consultants/Consultants/Consultants or this cd /mnt/dfs/what/ev/Consultants I haven't looked at the source yet so I'm not sure what's going on there... -- Mathieu Chouquet-Stringer "Le disparu, si l'on vénère sa mémoire, est plus présent et plus puissant que le vivant". -- Antoine de Saint-Exupéry, Citadelle -- - 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: cifs kernel module and MS DFS shares [2.6.12-1.1411_FC4]
[EMAIL PROTECTED] (Thomas Chiverton) writes: [EMAIL PROTECTED] gbb_domain]# mount.cifs //exchsvr/dfs /mnt/dfs/ -o user=tchiverton,domain=BLUEFINGER Password: [EMAIL PROTECTED] gbb_domain]# ls /mnt/dfs/ Applications Consultants Engineering ManagementVersion CommonDirectorsFinance Software Development WinTA Data [EMAIL PROTECTED] gbb_domain]# ls /mnt/dfs/Consultants/ Applications Consultants Engineering ManagementVersion CommonDirectorsFinance Software Development WinTA Data [EMAIL PROTECTED] gbb_domain]# I've got the same issue but if I go down 2 or 3 levels, it works (ie continue to go down the same directory until you see a valid content). Even better, I can cd into non existing directories and it works (as in I still see the content of the mountpoint). So using your example, to see the real content of Consultants, I would have to do this: cd /mnt/dfs/Consultants/Consultants/Consultants or this cd /mnt/dfs/what/ev/Consultants I haven't looked at the source yet so I'm not sure what's going on there... -- Mathieu Chouquet-Stringer Le disparu, si l'on vénère sa mémoire, est plus présent et plus puissant que le vivant. -- Antoine de Saint-Exupéry, Citadelle -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] remove support for gcc < 3.2
[EMAIL PROTECTED] (Gustavo Guillermo Pérez) writes: > Please keep the 2.95 support I use to use a lot, on not new hardware. > If you have old hardware with not much resources gcc 2.95 works just fine and > fast, even you build the main kernel on other machine, by compatibility > issues one or two drivers should be builded a lot of times into the older > hardware, then we are forced to build gcc 3.4 or something like. Moreover I get some weird networking problems which prevent setting up the routes (RNETLINK invalid argument messages) when I compile my kernel with 4.0.1 while the same kernel, same config works fine compiled with 3.2.3... So eventhough 4.0 is supposed to be supported, it doesn't work too well in my case. -- Mathieu Chouquet-Stringer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] remove support for gcc 3.2
[EMAIL PROTECTED] (Gustavo Guillermo Pérez) writes: Please keep the 2.95 support I use to use a lot, on not new hardware. If you have old hardware with not much resources gcc 2.95 works just fine and fast, even you build the main kernel on other machine, by compatibility issues one or two drivers should be builded a lot of times into the older hardware, then we are forced to build gcc 3.4 or something like. Moreover I get some weird networking problems which prevent setting up the routes (RNETLINK invalid argument messages) when I compile my kernel with 4.0.1 while the same kernel, same config works fine compiled with 3.2.3... So eventhough 4.0 is supposed to be supported, it doesn't work too well in my case. -- Mathieu Chouquet-Stringer - 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/
Oops while unmounting a reiserfs partition
b9a 2: 83 c4 0c add$0xc,%esp Code; c018bb9d 5: c3ret Code; c018bb9e 6: 89 f6 mov%esi,%esi Code; c018bba0 8: 31 c0 xor%eax,%eax Code; c018bba2 a: c3ret Code; c018bba3 b: 8d b6 00 00 00 00 lea0x0(%esi),%esi Code; c018bba9 11: 8d bc 27 00 00 00 00 lea0x0(%edi,1),%edi 3 warnings issued. Results may not be reliable. -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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/
Oops while unmounting a reiserfs partition
Trace; c014bf3f iput+3f/170 Trace; c0137494 fsync_super+b4/c0 Trace; c013bd72 kill_super+a2/120 Trace; c0140e79 path_release+29/30 Trace; c013c22d sys_umount+12d/160 Trace; c0126ec3 sys_munmap+33/50 Trace; c013c26c sys_oldumount+c/10 Trace; c0106e0b system_call+33/38 Code; c018bb98 reiserfs_check_lock_depth+38/40 _EIP: Code; c018bb98 reiserfs_check_lock_depth+38/40 = 0: 0f 0b ud2a = Code; c018bb9a reiserfs_check_lock_depth+3a/40 2: 83 c4 0c add$0xc,%esp Code; c018bb9d reiserfs_check_lock_depth+3d/40 5: c3ret Code; c018bb9e reiserfs_check_lock_depth+3e/40 6: 89 f6 mov%esi,%esi Code; c018bba0 push_journal_writer+0/10 8: 31 c0 xor%eax,%eax Code; c018bba2 push_journal_writer+2/10 a: c3ret Code; c018bba3 push_journal_writer+3/10 b: 8d b6 00 00 00 00 lea0x0(%esi),%esi Code; c018bba9 push_journal_writer+9/10 11: 8d bc 27 00 00 00 00 lea0x0(%edi,1),%edi 3 warnings issued. Results may not be reliable. -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: Carefull: The Mawanella message has a virus with it. (
[EMAIL PROTECTED] ("BAUDRILLARD ETIENNE") writes:
> Carefull: The Mawanella message has a virus with it. (Mawanella.vbs)
Because I presume that most of us use Unix, we do not really care... Thanks
anyway!
--
Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED]
Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
-- Alan J. Perlis
-
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: Carefull: The Mawanella message has a virus with it. (
[EMAIL PROTECTED] (BAUDRILLARD ETIENNE) writes: Carefull: The Mawanella message has a virus with it. (Mawanella.vbs) Because I presume that most of us use Unix, we do not really care... Thanks anyway! -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: LANANA: To Pending Device Number Registrants
Last time I checked (that was 5 minutes ago :-) )only the last two ones were supported... On Wed, May 16, 2001 at 01:16:50PM -0700, James Simmons wrote: > > > On Wed, May 16, 2001 at 01:05:47PM -0700, James Simmons wrote: > > > > Did you ever try grub?? This a gnu project, a boot-loader, with an embedded > > > > shell... You can read ext2fs and select, your kernel, your root disk, your > > > > params, etc... > > > > > > Yes I have tried it. Pretty cool. The only thing is what do you do if > > > /boot sites ontop of a non ext2 partition? > > > > Well if it's not ext2, fat, ffs, reiserfs or minix, too bad... On what kind > > of partition does your /boot site? > > For the machines I work with > > JFFS > JFFS2 > XFS > Reiserfs > ext2 -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: LANANA: To Pending Device Number Registrants
On Wed, May 16, 2001 at 01:05:47PM -0700, James Simmons wrote: > > Did you ever try grub?? This a gnu project, a boot-loader, with an embedded > > shell... You can read ext2fs and select, your kernel, your root disk, your > > params, etc... > > Yes I have tried it. Pretty cool. The only thing is what do you do if > /boot sites ontop of a non ext2 partition? Well if it's not ext2, fat, ffs, reiserfs or minix, too bad... On what kind of partition does your /boot site? -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: LANANA: To Pending Device Number Registrants
[EMAIL PROTECTED] (Hacksaw) writes: > >So what is your solution for preventing a boot failure after disks/partitions > >change ? > >volume labels/UUID ? > > As a sys-admin, let me add a vote for this. Having (one day) a prom monitor > program that looks at all the disks, and gives a menu of which one to boot > from would make life so nice. > > I very often had to move disks from one platform to another, and changing ID's > on the was hard or impossible in some cases, and required in others. Being > able to find the disk by a label is a thousand times better. Did you ever try grub?? This a gnu project, a boot-loader, with an embedded shell... You can read ext2fs and select, your kernel, your root disk, your params, etc... -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: LANANA: To Pending Device Number Registrants
[EMAIL PROTECTED] (Hacksaw) writes: So what is your solution for preventing a boot failure after disks/partitions change ? volume labels/UUID ? As a sys-admin, let me add a vote for this. Having (one day) a prom monitor program that looks at all the disks, and gives a menu of which one to boot from would make life so nice. I very often had to move disks from one platform to another, and changing ID's on the was hard or impossible in some cases, and required in others. Being able to find the disk by a label is a thousand times better. Did you ever try grub?? This a gnu project, a boot-loader, with an embedded shell... You can read ext2fs and select, your kernel, your root disk, your params, etc... -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: LANANA: To Pending Device Number Registrants
On Wed, May 16, 2001 at 01:05:47PM -0700, James Simmons wrote: Did you ever try grub?? This a gnu project, a boot-loader, with an embedded shell... You can read ext2fs and select, your kernel, your root disk, your params, etc... Yes I have tried it. Pretty cool. The only thing is what do you do if /boot sites ontop of a non ext2 partition? Well if it's not ext2, fat, ffs, reiserfs or minix, too bad... On what kind of partition does your /boot site? -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: LANANA: To Pending Device Number Registrants
Last time I checked (that was 5 minutes ago :-) )only the last two ones were supported... On Wed, May 16, 2001 at 01:16:50PM -0700, James Simmons wrote: On Wed, May 16, 2001 at 01:05:47PM -0700, James Simmons wrote: Did you ever try grub?? This a gnu project, a boot-loader, with an embedded shell... You can read ext2fs and select, your kernel, your root disk, your params, etc... Yes I have tried it. Pretty cool. The only thing is what do you do if /boot sites ontop of a non ext2 partition? Well if it's not ext2, fat, ffs, reiserfs or minix, too bad... On what kind of partition does your /boot site? For the machines I work with JFFS JFFS2 XFS Reiserfs ext2 -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: ioctl arg passing
<[EMAIL PROTECTED]> writes: > On Mon, 23 Apr 2001, Ingo Oeser wrote: > > > On Mon, Apr 23, 2001 at 05:06:48PM +0100, Matt wrote: > > > I'm writing a char device driver for a dsp card that drives a motion > > > platform. > > > > Can you elaborate on the dsp card? Is it freely programmable? I'm > > working on a project to support this kind of stuff via a > > dedicated subsystem for Linux. > > Very interesting... The emu10k1 driver (SBLive!) that will appear > shortly in acXX will support loading code to it's DSP. It's a very > simple chip with only 16 instructions but it can generate > hardware interrupts, DMA to host memory, 32 bit math. The maximum > program size is 512 instructions (64 bits each) and can make use of 256 > registers (32 bits). Do you mean we will be able to have the same kind of stuff they have on Windows (like the mp3 encoding computed by the SB Live)?? -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: ioctl arg passing
[EMAIL PROTECTED] writes: On Mon, 23 Apr 2001, Ingo Oeser wrote: On Mon, Apr 23, 2001 at 05:06:48PM +0100, Matt wrote: I'm writing a char device driver for a dsp card that drives a motion platform. Can you elaborate on the dsp card? Is it freely programmable? I'm working on a project to support this kind of stuff via a dedicated subsystem for Linux. Very interesting... The emu10k1 driver (SBLive!) that will appear shortly in acXX will support loading code to it's DSP. It's a very simple chip with only 16 instructions but it can generate hardware interrupts, DMA to host memory, 32 bit math. The maximum program size is 512 instructions (64 bits each) and can make use of 256 registers (32 bits). Do you mean we will be able to have the same kind of stuff they have on Windows (like the mp3 encoding computed by the SB Live)?? -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: ethernet phy link state info
Try http://www.scyld.com/diag/
[EMAIL PROTECTED] ("Johan Adolfsson") writes:
> I don't have an answer but a related question:
> Is there any "standard ioctl" to force an interface
> to a certain link state, eg. auto, 10Mbs, 100Mbps,
> half/full duplex etc.?
>
> If not, can we create a standard ioctl mechanism for it?
>
> /Johan
>
> - Original Message -
> From: Bernhard Bender <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, April 06, 2001 16:54
> Subject: ethernet phy link state info
>
>
> >
> >
> > Hi all,
> >
> > where do I find information about the current link state of the ethernet
> PHY
> > (e.g. 100mbit/s full duplex) ?
> > Something like /proc/sys/net/* ?
> >
> > Thanks
> > Bernhard
> >
> >
> > -
> > 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/
> >
>
> -
> 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/
>
--
Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED]
Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
-- Alan J. Perlis
-
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: ethernet phy link state info
Try http://www.scyld.com/diag/
[EMAIL PROTECTED] ("Johan Adolfsson") writes:
I don't have an answer but a related question:
Is there any "standard ioctl" to force an interface
to a certain link state, eg. auto, 10Mbs, 100Mbps,
half/full duplex etc.?
If not, can we create a standard ioctl mechanism for it?
/Johan
- Original Message -
From: Bernhard Bender [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, April 06, 2001 16:54
Subject: ethernet phy link state info
Hi all,
where do I find information about the current link state of the ethernet
PHY
(e.g. 100mbit/s full duplex) ?
Something like /proc/sys/net/* ?
Thanks
Bernhard
-
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/
-
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/
--
Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED]
Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
-- Alan J. Perlis
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: problem in BOGOmips
[EMAIL PROTECTED] (Ashish Gupta) writes: > Hi, > I want to use bogomips as the indicator of CPU capability for > different architectures. I have found following values from /proc/cpuinfo > for different CPUs. You got your answer. Try pronounce bogomips and you will hear bogo like in bogus. The Bogomips don't represent anything but a way to have a good delay mechanism... So you can't compare them between CPUs! -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: problem in BOGOmips
[EMAIL PROTECTED] (Ashish Gupta) writes: Hi, I want to use bogomips as the indicator of CPU capability for different architectures. I have found following values from /proc/cpuinfo for different CPUs. You got your answer. Try pronounce bogomips and you will hear bogo like in bogus. The Bogomips don't represent anything but a way to have a good delay mechanism... So you can't compare them between CPUs! -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: modules as drivers and the order of loading
[EMAIL PROTECTED] (Alan Chandler) writes: > As I was building 2.4.1 afresh I took the opportunity to build some of > the device drivers as modules. In particular I have a SCSI cdrom > device (it actually is a cd writer) and I had made that and its > controller (Adaptec AIC-7xxx driver) modules. > > However, during boot they fail to load because at the time they are > brought up VFS had not mounted the root filesystem > > I am not sure why they can be built as modules if they then can't be > loaded? > > OR have I completely misunderstood the approach here. Well you got it right and wrong at the same time: if you want to use modules which are used during the boot process, you have to use an initrd image (which will be loaded before the kernel and stores all your modules). -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: problems with sblive as well as 3com 3c905
You need to get the latest modutils: the directory tree under /lib/modules
changed recently and that's why it works if you create symlinks...
[EMAIL PROTECTED] ("Timothy A. DeWees") writes:
> You need to create a symlink
>
> ln -s /lib/modules/2.4.1/kernel/drivers/net /lib/modules/2.4.1/net
>
> That will fix the nic, I am not sure about sound. You may need to
> create a misc link like
>
> ln -s /lib/modules/2.4.1/kernel/drivers/misc /lib/modules/2.4.1/misc
>
>
> - Original Message -
> From: "Lukasz Gogolewski" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 31, 2001 4:03 PM
> Subject: problems with sblive as well as 3com 3c905
>
>
> > After I compiled kernel 2.4.1 on rh 6.2 I enabled module support for 2
> > of those devices.
> >
> > However when I rebooted my machine both of those devices are not
> > working.
> >
> > I don't know what's wrong since I did make moudle and make
> > module_install.
> >
> > When I try to configure mdoule for the sound card, I get a message
> > saying that module wasn't found.
> >
> > For the network card I get Delaying initialization
> >
> > any suggestions on how to fix it?
> >
> > - Lucas
> >
> >
> >
> >
> >
> > -
> > 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/
>
> -
> 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/
>
--
Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED]
Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
-- Alan J. Perlis
-
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: problems with sblive as well as 3com 3c905
You need to get the latest modutils: the directory tree under /lib/modules
changed recently and that's why it works if you create symlinks...
[EMAIL PROTECTED] ("Timothy A. DeWees") writes:
You need to create a symlink
ln -s /lib/modules/2.4.1/kernel/drivers/net /lib/modules/2.4.1/net
That will fix the nic, I am not sure about sound. You may need to
create a misc link like
ln -s /lib/modules/2.4.1/kernel/drivers/misc /lib/modules/2.4.1/misc
- Original Message -
From: "Lukasz Gogolewski" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 31, 2001 4:03 PM
Subject: problems with sblive as well as 3com 3c905
After I compiled kernel 2.4.1 on rh 6.2 I enabled module support for 2
of those devices.
However when I rebooted my machine both of those devices are not
working.
I don't know what's wrong since I did make moudle and make
module_install.
When I try to configure mdoule for the sound card, I get a message
saying that module wasn't found.
For the network card I get Delaying initialization
any suggestions on how to fix it?
- Lucas
-
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/
-
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/
--
Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED]
Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
-- Alan J. Perlis
-
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: modules as drivers and the order of loading
[EMAIL PROTECTED] (Alan Chandler) writes: As I was building 2.4.1 afresh I took the opportunity to build some of the device drivers as modules. In particular I have a SCSI cdrom device (it actually is a cd writer) and I had made that and its controller (Adaptec AIC-7xxx driver) modules. However, during boot they fail to load because at the time they are brought up VFS had not mounted the root filesystem I am not sure why they can be built as modules if they then can't be loaded? OR have I completely misunderstood the approach here. Well you got it right and wrong at the same time: if you want to use modules which are used during the boot process, you have to use an initrd image (which will be loaded before the kernel and stores all your modules). -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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/
network problem (not ECN)
Hi everybody! I've seen that the discussion with the ECN thing is quiet interesting and I'm experiencing something strange when I try to ftp to ftp.kernel.org. That's what I get: NcFTP 3.0.1 (March 27, 2000) by Mike Gleason ([EMAIL PROTECTED]). ncftp> open ftp.kernel.org Connecting to 209.10.41.242... ProFTPD 1.2.0 Server (ProFTPD) [zeus.kernel.org] Logging in... Welcome to the LINUX KERNEL ARCHIVES ftp.kernel.org Remote host has closed the connection. Logged in to ftp.kernel.org. ncftp> I've attached the tcpdump output for this session. If anyone is able to explain that to me... Thanks! User level filter, protocol ALL, TURBO mode (575 frames), datagram packet socket tcpdump: listening on all devices 13:51:15.483800 eth0 > myname.mydomain.com.47029 > zeus.kernel.org.ftp: S 4270986830:4270986830(0) win 5840 (DF) (ttl 64, id 0) 13:51:15.573976 eth0 < zeus.kernel.org.ftp > myname.mydomain.com.47029: S 4266783476:4266783476(0) ack 4270986831 win 32120 (DF) (ttl 51, id 1348) 13:51:15.573998 eth0 > myname.mydomain.com.47029 > zeus.kernel.org.ftp: . 1:1(0) ack 1 win 5840 (DF) (ttl 64, id 0) 13:51:25.661937 eth0 < zeus.kernel.org.ftp > myname.mydomain.com.47029: P 1:55(54) ack 1 win 32120 (DF) (ttl 51, id 18753) 13:51:25.661988 eth0 > myname.mydomain.com.47029 > zeus.kernel.org.ftp: . 1:1(0) ack 55 win 5840 (DF) (ttl 64, id 0) 13:51:25.662327 eth0 > myname.mydomain.com.47029 > zeus.kernel.org.ftp: P 1:17(16) ack 55 win 5840 (DF) (ttl 64, id 0) 13:51:25.750853 eth0 < zeus.kernel.org.ftp > myname.mydomain.com.47029: . 55:55(0) ack 17 win 32120 (DF) (ttl 51, id 18942) 13:51:25.76 eth0 < zeus.kernel.org.ftp > myname.mydomain.com.47029: P 55:127(72) ack 17 win 32120 (DF) (ttl 51, id 18979) 13:51:25.770210 eth0 > myname.mydomain.com.47029 > zeus.kernel.org.ftp: P 17:52(35) ack 127 win 5840 (DF) (ttl 64, id 0) 13:51:25.871311 eth0 < zeus.kernel.org.ftp > myname.mydomain.com.47029: . 127:127(0) ack 52 win 32120 (DF) (ttl 51, id 19168) 13:51:25.873171 eth0 < zeus.kernel.org.ftp > myname.mydomain.com.47029: P 127:154(27) ack 52 win 32120 (DF) (ttl 51, id 19169) 13:51:25.873580 eth0 < zeus.kernel.org.ftp > myname.mydomain.com.47029: P 154:157(3) ack 52 win 32120 (DF) (ttl 51, id 19170) 13:51:25.874052 eth0 < zeus.kernel.org.ftp > myname.mydomain.com.47029: P 157:184(27) ack 52 win 32120 (DF) (ttl 51, id 19171) 13:51:25.874497 eth0 < zeus.kernel.org.ftp > myname.mydomain.com.47029: P 184:208(24) ack 52 win 32120 (DF) (ttl 51, id 19172) 13:51:25.908647 eth0 > myname.mydomain.com.47029 > zeus.kernel.org.ftp: . 52:52(0) ack 208 win 5840 (DF) (ttl 64, id 0) 13:51:26.009354 eth0 < zeus.kernel.org.ftp > myname.mydomain.com.47029: P 1656:2066(410) ack 52 win 32120 (DF) (ttl 51, id 19408) 13:51:26.009396 eth0 > myname.mydomain.com.47029 > zeus.kernel.org.ftp: . 52:52(0) ack 208 win 5840 (DF) (ttl 64, id 0) 13:51:26.097802 eth0 < zeus.kernel.org.ftp > myname.mydomain.com.47029: R 4266783684:4266783684(0) win 0 (ttl 242, id 19596) 9252 packets received by filter -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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/
network problem (not ECN)
Hi everybody!
I've seen that the discussion with the ECN thing is quiet interesting and
I'm experiencing something strange when I try to ftp to
ftp.kernel.org. That's what I get:
NcFTP 3.0.1 (March 27, 2000) by Mike Gleason ([EMAIL PROTECTED]).
ncftp open ftp.kernel.org
Connecting to 209.10.41.242...
ProFTPD 1.2.0 Server (ProFTPD) [zeus.kernel.org]
Logging in...
Welcome to the
LINUX KERNEL ARCHIVES
ftp.kernel.org
Remote host has closed the connection.
Logged in to ftp.kernel.org.
ncftp
I've attached the tcpdump output for this session. If anyone is able to
explain that to me...
Thanks!
User level filter, protocol ALL, TURBO mode (575 frames), datagram packet socket
tcpdump: listening on all devices
13:51:15.483800 eth0 myname.mydomain.com.47029 zeus.kernel.org.ftp: S
4270986830:4270986830(0) win 5840 mss 1460,sackOK,timestamp 16037859 0,nop,wscale 0
(DF) (ttl 64, id 0)
13:51:15.573976 eth0 zeus.kernel.org.ftp myname.mydomain.com.47029: S
4266783476:4266783476(0) ack 4270986831 win 32120 mss 1460,sackOK,timestamp 794396911
16037859,nop,wscale 0 (DF) (ttl 51, id 1348)
13:51:15.573998 eth0 myname.mydomain.com.47029 zeus.kernel.org.ftp: . 1:1(0) ack 1
win 5840 nop,nop,timestamp 16037868 794396911 (DF) (ttl 64, id 0)
13:51:25.661937 eth0 zeus.kernel.org.ftp myname.mydomain.com.47029: P 1:55(54) ack
1 win 32120 nop,nop,timestamp 794397920 16037868 (DF) (ttl 51, id 18753)
13:51:25.661988 eth0 myname.mydomain.com.47029 zeus.kernel.org.ftp: . 1:1(0) ack
55 win 5840 nop,nop,timestamp 16038877 794397920 (DF) (ttl 64, id 0)
13:51:25.662327 eth0 myname.mydomain.com.47029 zeus.kernel.org.ftp: P 1:17(16) ack
55 win 5840 nop,nop,timestamp 16038877 794397920 (DF) (ttl 64, id 0)
13:51:25.750853 eth0 zeus.kernel.org.ftp myname.mydomain.com.47029: . 55:55(0) ack
17 win 32120 nop,nop,timestamp 794397928 16038877 (DF) (ttl 51, id 18942)
13:51:25.76 eth0 zeus.kernel.org.ftp myname.mydomain.com.47029: P 55:127(72)
ack 17 win 32120 nop,nop,timestamp 794397930 16038877 (DF) (ttl 51, id 18979)
13:51:25.770210 eth0 myname.mydomain.com.47029 zeus.kernel.org.ftp: P 17:52(35)
ack 127 win 5840 nop,nop,timestamp 1603 794397930 (DF) (ttl 64, id 0)
13:51:25.871311 eth0 zeus.kernel.org.ftp myname.mydomain.com.47029: . 127:127(0)
ack 52 win 32120 nop,nop,timestamp 794397941 1603 (DF) (ttl 51, id 19168)
13:51:25.873171 eth0 zeus.kernel.org.ftp myname.mydomain.com.47029: P 127:154(27)
ack 52 win 32120 nop,nop,timestamp 794397941 1603 (DF) (ttl 51, id 19169)
13:51:25.873580 eth0 zeus.kernel.org.ftp myname.mydomain.com.47029: P 154:157(3)
ack 52 win 32120 nop,nop,timestamp 794397941 1603 (DF) (ttl 51, id 19170)
13:51:25.874052 eth0 zeus.kernel.org.ftp myname.mydomain.com.47029: P 157:184(27)
ack 52 win 32120 nop,nop,timestamp 794397941 1603 (DF) (ttl 51, id 19171)
13:51:25.874497 eth0 zeus.kernel.org.ftp myname.mydomain.com.47029: P 184:208(24)
ack 52 win 32120 nop,nop,timestamp 794397941 1603 (DF) (ttl 51, id 19172)
13:51:25.908647 eth0 myname.mydomain.com.47029 zeus.kernel.org.ftp: . 52:52(0) ack
208 win 5840 nop,nop,timestamp 16038902 794397941 (DF) (ttl 64, id 0)
13:51:26.009354 eth0 zeus.kernel.org.ftp myname.mydomain.com.47029: P
1656:2066(410) ack 52 win 32120 nop,nop,timestamp 794397953 16038902 (DF) (ttl 51,
id 19408)
13:51:26.009396 eth0 myname.mydomain.com.47029 zeus.kernel.org.ftp: . 52:52(0) ack
208 win 5840 nop,nop,timestamp 16038912 794397941,nop,nop, sack 1 {1656:2066} (DF)
(ttl 64, id 0)
13:51:26.097802 eth0 zeus.kernel.org.ftp myname.mydomain.com.47029: R
4266783684:4266783684(0) win 0 (ttl 242, id 19596)
9252 packets received by filter
--
Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED]
Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
-- Alan J. Perlis
-
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: [UPDATE] Zerocopy patches, against 2.4.1-pre10
[EMAIL PROTECTED] ("Jonathan Earle") writes:
> > I'm back from OZ, and to help deal with my sudden lack of Victoria
> > Bitter, I've made a new zerocopy patch set.
>
> What are "zerocopy patch set"s?
Basically, if you want to send something to the network, the kernel has to
copy your data to its memory space. It is an overhead and with these
patches, the kernel doesn't has to do it. So it is faster. Moreover, few
ethernet cards are able to compute the ip checksum so linux doesn't need
anymore to do that.
--
Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED]
Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
-- Alan J. Perlis
-
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/
oops with ac97 sound card
Warning (compare_maps): ksyms_base symbol acpi_os_sleep_usec_R__ver_acpi_os_sleep_usec not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_processor_sleep_R__ver_acpi_processor_sleep not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_remove_address_space_handler_R__ver_acpi_remove_address_space_handler not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_remove_gpe_handler_R__ver_acpi_remove_gpe_handler not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_remove_notify_handler_R__ver_acpi_remove_notify_handler not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_set_current_resources_R__ver_acpi_set_current_resources not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_set_processor_sleep_state_R__ver_acpi_set_processor_sleep_state not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_set_processor_throttling_state_R__ver_acpi_set_processor_throttling_state not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol debug_print_prefix_R__ver_debug_print_prefix not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol debug_print_raw_R__ver_debug_print_raw not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol function_exit_R__ver_function_exit not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol function_status_exit_R__ver_function_status_exit not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol function_trace_R__ver_function_trace not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol function_value_exit_R__ver_function_value_exit not found in System.map. Ignoring ksyms_base entry Jan 24 16:15:06 shookay kernel: Unable to handle kernel paging request at virtual address 6559d250 Jan 24 16:15:06 shookay kernel: d082ceea Jan 24 16:15:06 shookay kernel: *pde = Jan 24 16:15:06 shookay kernel: Oops: 0002 Jan 24 16:15:06 shookay kernel: CPU:0 Jan 24 16:15:06 shookay kernel: EIP: 0010:[i810_audio:__insmod_i810_audio_S.text_L9922+7818/10144] Jan 24 16:15:06 shookay kernel: EFLAGS: 00010286 Jan 24 16:15:06 shookay kernel: eax: c14b2f50 ebx: cf5d02a0 ecx: 2903a8c0 edx: a40ea300 Jan 24 16:15:06 shookay kernel: esi: c876cba0 edi: cf5d02a8 ebp: cf5d02d0 esp: c9d8df60 Jan 24 16:15:06 shookay kernel: ds: 0018 es: 0018 ss: 0018 Jan 24 16:15:06 shookay kernel: Process sox (pid: 8956, stackpage=c9d8d000) Jan 24 16:15:06 shookay kernel: Stack: cf5d02a0 c876cba0 c14b3f20 cd5bc460 cd59e720 c0131530 cd5bc460 c876cba0 Jan 24 16:15:06 shookay kernel:c876cba0 bbf0 c01306fc c876cba0 cc5e6420 Jan 24 16:15:06 shookay kernel:c876cba0 c876cba0 080ae320 c0130747 c876cba0 cc5e6420 c9d8c000 Jan 24 16:15:06 shookay kernel: Call Trace: [fput+56/208] [filp_close+92/100] [sys_close+67/84] [system_call+51/56] Jan 24 16:15:06 shookay kernel: Code: c7 04 02 00 00 00 00 83 c4 04 31 c0 5b 5e 5f 5d c3 90 83 ec Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: c7 04 02 00 00 00 00 movl $0x0,(%edx,%eax,1) Code; 0007 Before first symbol 7: 83 c4 04 add$0x4,%esp Code; 000a Before first symbol a: 31 c0 xor%eax,%eax Code; 000c Before first symbol c: 5bpop%ebx Code; 000d Before first symbol d: 5epop%esi Code; 000e Before first symbol e: 5fpop%edi Code; 000f Before first symbol f: 5dpop%ebp Code; 0010 Before first symbol 10: c3ret Code; 0011 Before first symbol 11: 90nop Code; 0012 Before first symbol 12: 83 ec 00 sub$0x0,%esp 45 warnings issued. Results may not be reliable. -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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/
oops with ac97 sound card
Warning (compare_maps): ksyms_base symbol acpi_os_sleep_usec_R__ver_acpi_os_sleep_usec not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_processor_sleep_R__ver_acpi_processor_sleep not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_remove_address_space_handler_R__ver_acpi_remove_address_space_handler not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_remove_gpe_handler_R__ver_acpi_remove_gpe_handler not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_remove_notify_handler_R__ver_acpi_remove_notify_handler not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_set_current_resources_R__ver_acpi_set_current_resources not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_set_processor_sleep_state_R__ver_acpi_set_processor_sleep_state not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_set_processor_throttling_state_R__ver_acpi_set_processor_throttling_state not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol debug_print_prefix_R__ver_debug_print_prefix not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol debug_print_raw_R__ver_debug_print_raw not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol function_exit_R__ver_function_exit not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol function_status_exit_R__ver_function_status_exit not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol function_trace_R__ver_function_trace not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol function_value_exit_R__ver_function_value_exit not found in System.map. Ignoring ksyms_base entry Jan 24 16:15:06 shookay kernel: Unable to handle kernel paging request at virtual address 6559d250 Jan 24 16:15:06 shookay kernel: d082ceea Jan 24 16:15:06 shookay kernel: *pde = Jan 24 16:15:06 shookay kernel: Oops: 0002 Jan 24 16:15:06 shookay kernel: CPU:0 Jan 24 16:15:06 shookay kernel: EIP: 0010:[i810_audio:__insmod_i810_audio_S.text_L9922+7818/10144] Jan 24 16:15:06 shookay kernel: EFLAGS: 00010286 Jan 24 16:15:06 shookay kernel: eax: c14b2f50 ebx: cf5d02a0 ecx: 2903a8c0 edx: a40ea300 Jan 24 16:15:06 shookay kernel: esi: c876cba0 edi: cf5d02a8 ebp: cf5d02d0 esp: c9d8df60 Jan 24 16:15:06 shookay kernel: ds: 0018 es: 0018 ss: 0018 Jan 24 16:15:06 shookay kernel: Process sox (pid: 8956, stackpage=c9d8d000) Jan 24 16:15:06 shookay kernel: Stack: cf5d02a0 c876cba0 c14b3f20 cd5bc460 cd59e720 c0131530 cd5bc460 c876cba0 Jan 24 16:15:06 shookay kernel:c876cba0 bbf0 c01306fc c876cba0 cc5e6420 Jan 24 16:15:06 shookay kernel:c876cba0 c876cba0 080ae320 c0130747 c876cba0 cc5e6420 c9d8c000 Jan 24 16:15:06 shookay kernel: Call Trace: [fput+56/208] [filp_close+92/100] [sys_close+67/84] [system_call+51/56] Jan 24 16:15:06 shookay kernel: Code: c7 04 02 00 00 00 00 83 c4 04 31 c0 5b 5e 5f 5d c3 90 83 ec Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol _EIP: Code; Before first symbol 0: c7 04 02 00 00 00 00 movl $0x0,(%edx,%eax,1) Code; 0007 Before first symbol 7: 83 c4 04 add$0x4,%esp Code; 000a Before first symbol a: 31 c0 xor%eax,%eax Code; 000c Before first symbol c: 5bpop%ebx Code; 000d Before first symbol d: 5epop%esi Code; 000e Before first symbol e: 5fpop%edi Code; 000f Before first symbol f: 5dpop%ebp Code; 0010 Before first symbol 10: c3ret Code; 0011 Before first symbol 11: 90nop Code; 0012 Before first symbol 12: 83 ec 00 sub$0x0,%esp 45 warnings issued. Results may not be reliable. -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: [UPDATE] Zerocopy patches, against 2.4.1-pre10
[EMAIL PROTECTED] ("Jonathan Earle") writes:
I'm back from OZ, and to help deal with my sudden lack of Victoria
Bitter, I've made a new zerocopy patch set.
What are "zerocopy patch set"s?
Basically, if you want to send something to the network, the kernel has to
copy your data to its memory space. It is an overhead and with these
patches, the kernel doesn't has to do it. So it is faster. Moreover, few
ethernet cards are able to compute the ip checksum so linux doesn't need
anymore to do that.
--
Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED]
Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
-- Alan J. Perlis
-
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: Modules not being found with 2.4.0 on a 486 based box
You need to install a recent version of modutils (at least 2.4.0) because the directory structure changed as you noticed it and the new modutils are able to deal with that. [EMAIL PROTECTED] (C Sanjayan Rosenmund) writes: > Please cc: me as well, as I'm on to many lists as is. . . > > Irecently built 2.4.0 on two diferent x486 PCs and neither of them > recognised the new module directory structure found in the 2.4.x > kernels. I did not have this problem on the Pentium and better > machines that I built this same kernel on. I got around the problem > by making a symlink from where the module actually was > (/lib/modules/2.4.0/kernel/drivers/net/) to where the system was > looking for it (/lib/modules/2.4.0/net/) and all is well. . .for now. > I was wondering if there was any light that could be shed on why this > might happen? I have only found this to be a problem on 486s, > everything bigger has worked fine. Details below: > Feature Working Not Wotking > Processor Pentium + 486 (486DX2-66, 486DX-50) > Distrobution Debian unstable Debian stable (unstable caused other > problems) > RAM 16Mb + 16Mb + > Hdd size 1Gb + 540Mb + > Modules involved Any network cards (that is all I was using) > > More info can be provided if needed. This is low priority, I was > wondering if you had any ideas why (or how to get around it, other > than my solution). > > Thank you all for your time, and for producing a kernel that is worth > all this work . -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: [OT?] Coding Style
[EMAIL PROTECTED] ("Christopher Friesen") writes:
> Georg Nikodym wrote:
>
> > I think that the distinction is moot and this argument a waste of
> > time. If you are anything more than a code tourist, you should have
> > no trouble dealing with mnemonic names. So the above can become:
> >
> > /*
> > * timcaefn == this is my clear and easy function name
> > */
> > void timcaefn (void);
> >
> > If you're at all concerned about RSI, your fingers will thank you.
>
> This is why the autocompletion of functions and struct members in VC++ is
> awfully nice...hit the first few unique letters and it will complete the rest of
> the function for you, then hit tab and keep going. Is there anything with that
> functionality under Linux?
Esc-/ under emacs...
--
Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED]
Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
-- Alan J. Perlis
-
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: [OT?] Coding Style
[EMAIL PROTECTED] ("Christopher Friesen") writes:
Georg Nikodym wrote:
I think that the distinction is moot and this argument a waste of
time. If you are anything more than a code tourist, you should have
no trouble dealing with mnemonic names. So the above can become:
/*
* timcaefn == this is my clear and easy function name
*/
void timcaefn (void);
If you're at all concerned about RSI, your fingers will thank you.
This is why the autocompletion of functions and struct members in VC++ is
awfully nice...hit the first few unique letters and it will complete the rest of
the function for you, then hit tab and keep going. Is there anything with that
functionality under Linux?
Esc-/ under emacs...
--
Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED]
Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
-- Alan J. Perlis
-
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: Modules not being found with 2.4.0 on a 486 based box
You need to install a recent version of modutils (at least 2.4.0) because the directory structure changed as you noticed it and the new modutils are able to deal with that. [EMAIL PROTECTED] (C Sanjayan Rosenmund) writes: Please cc: me as well, as I'm on to many lists as is. . . Irecently built 2.4.0 on two diferent x486 PCs and neither of them recognised the new module directory structure found in the 2.4.x kernels. I did not have this problem on the Pentium and better machines that I built this same kernel on. I got around the problem by making a symlink from where the module actually was (/lib/modules/2.4.0/kernel/drivers/net/) to where the system was looking for it (/lib/modules/2.4.0/net/) and all is well. . .for now. I was wondering if there was any light that could be shed on why this might happen? I have only found this to be a problem on 486s, everything bigger has worked fine. Details below: Feature Working Not Wotking Processor Pentium + 486 (486DX2-66, 486DX-50) Distrobution Debian unstable Debian stable (unstable caused other problems) RAM 16Mb + 16Mb + Hdd size 1Gb + 540Mb + Modules involved Any network cards (that is all I was using) More info can be provided if needed. This is low priority, I was wondering if you had any ideas why (or how to get around it, other than my solution). Thank you all for your time, and for producing a kernel that is worth all this work grin. -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: Floppy disk strange behavior
Ok, I emailed [EMAIL PROTECTED] and got this response from Jim Meyering <[EMAIL PROTECTED]>: Thanks for the report. That's fixed in the latest test release. ftp://alpha.gnu.org/gnu/fetish/fileutils-4.0.35.tar.gz It's fixed in 4.0.33, too. [EMAIL PROTECTED] (Alexander Viro) writes: > On Tue, 9 Jan 2001, Alan Cox wrote: > > > > dd bug. It tries to ftruncate() the output file and gets all upset when > > > kernel refuses to truncate a block device (surprise, surprise). > > > > Standards compliant but unexpected. > > dd is supposed to be portable. On Solaris: > % man ftruncate > [snip] > EINVALThe fildes argument does not correspond to an >ordinary file. > > > Actually its explicitly mentioned by the spec that truncate _may_ extend > > a file but need not do so. > > However, it also explicitly mentions that truncate can fail for non-regular > file. > > > > Try to build GNU dd on other Unices and you will be able to trigger that > > > bug on quite a few of them. > > > > I think not > > Solaris, for one thing. OK, let's ask folks to test it on different systems > and see what it gives. > > > > ftruncate(2) is _not_ supposed to succeed on anything other than regular > > > files. I.e. dd(1) should not call it and expect success if file is not > > > regular. Plain and simple... > > > > 2.2 is least suprise 2.4 is most information, but misleading errno IMHO > > Agreed. It should be -EINVAL, not -EPERM. > > IMO there are two issues: > * dd(1) portability bug. Obviously there - ftruncate(2) is allowed > to fail on non-regular ones. Fix is trivial and it (or something equivalent) > should go into the fileutils. > * What should 2.4 do here? I would prefer -EINVAL - it is true > (requested action is invalid for the arguments we got), it is consistent > with other systems and it doesn't hide the failure. Data that used to > be in the file we were trying to truncate is still there. -EPERM is > arguably wrong here - it's not like the problem was in the lack of > permissions. > > - > 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/ > -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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/
Floppy disk strange behavior
Hi! I have switched a long time ago to linux-2.4 (and even 2.3 series) and I have a wierd problem. I use GRUB to boot my system. Basically, when you want to install GRUB on a floppy disk, you do that: dd if=stage1 of=/dev/fd0 bs=512 count=1 dd if=stage2 of=/dev/fd0 bs=512 seek=1 But since kernel 2.3.xx (I don't remember exactly), I got this error message when I try to do the second dd (even as root): dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied And this thing works properly when under 2.2.xx... I try to look a the diff of floppy.c between 2.2.18 and 2.4.0 but at this time, I didn't find anything... -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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/
Floppy disk strange behavior
Hi! I have switched a long time ago to linux-2.4 (and even 2.3 series) and I have a wierd problem. I use GRUB to boot my system. Basically, when you want to install GRUB on a floppy disk, you do that: dd if=stage1 of=/dev/fd0 bs=512 count=1 dd if=stage2 of=/dev/fd0 bs=512 seek=1 But since kernel 2.3.xx (I don't remember exactly), I got this error message when I try to do the second dd (even as root): dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied And this thing works properly when under 2.2.xx... I try to look a the diff of floppy.c between 2.2.18 and 2.4.0 but at this time, I didn't find anything... -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: Floppy disk strange behavior
Ok, I emailed [EMAIL PROTECTED] and got this response from Jim Meyering [EMAIL PROTECTED]: Thanks for the report. That's fixed in the latest test release. ftp://alpha.gnu.org/gnu/fetish/fileutils-4.0.35.tar.gz It's fixed in 4.0.33, too. [EMAIL PROTECTED] (Alexander Viro) writes: On Tue, 9 Jan 2001, Alan Cox wrote: dd bug. It tries to ftruncate() the output file and gets all upset when kernel refuses to truncate a block device (surprise, surprise). Standards compliant but unexpected. dd is supposed to be portable. On Solaris: % man ftruncate [snip] EINVALThe fildes argument does not correspond to an ordinary file. Actually its explicitly mentioned by the spec that truncate _may_ extend a file but need not do so. However, it also explicitly mentions that truncate can fail for non-regular file. Try to build GNU dd on other Unices and you will be able to trigger that bug on quite a few of them. I think not Solaris, for one thing. OK, let's ask folks to test it on different systems and see what it gives. ftruncate(2) is _not_ supposed to succeed on anything other than regular files. I.e. dd(1) should not call it and expect success if file is not regular. Plain and simple... 2.2 is least suprise 2.4 is most information, but misleading errno IMHO Agreed. It should be -EINVAL, not -EPERM. IMO there are two issues: * dd(1) portability bug. Obviously there - ftruncate(2) is allowed to fail on non-regular ones. Fix is trivial and it (or something equivalent) should go into the fileutils. * What should 2.4 do here? I would prefer -EINVAL - it is true (requested action is invalid for the arguments we got), it is consistent with other systems and it doesn't hide the failure. Data that used to be in the file we were trying to truncate is still there. -EPERM is arguably wrong here - it's not like the problem was in the lack of permissions. - 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/ -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: kernel network problem ?
You have to take a look at ENC:
Explicit Congestion Notification (ECN) allows routers to notify
clients about network congestion, resulting in fewer dropped packets
and increased network performance. This option adds ECN support to the
Linux kernel, as well as a sysctl (/proc/sys/net/ipv4/tcp_ecn) which
allows ECN support to be disabled at runtime.
Note that, on the Internet, there are many broken firewalls which
refuse connections from ECN-enabled machines, and it may be a while
before these firewalls are fixed. Until then, to access a site behind
such a firewall (some of which are major sites, at the time of this
writing) you will have to disable this option, either by saying N now
or by using the sysctl.
You can disable it at runtime with:
echo 0 > /proc/sys/net/ipv4/tcp_ecn
[EMAIL PROTECTED] ("Nicolas Parpandet") writes:
> Hi all,
>
> I'm testing 2.4 series for few weeks,
> even the last prerelease
>
> I've seen stranges things :
>
> I cannot access to some ips adresses ! :
> in http or in smtp using "konqueror", "netscape",
> "mail", "telnet 25".
>
> I cannot login to hotmail (in the web page:http)
> or send mail (smtp) to hotmail users (don't blame me !!)
> All the others network things works well, the network in general seems
> good only very few sites like hotmail doesn't works.
>
> And only with 2.4 series !! not with 2.2 ...
>
> maybe it's a glibc or kernel issue, I'dont know.
> I have an intel SMP motherboard connected to the net (cable)
> with a PCI realtek 8019.
>
> I didn't analyse packets sent. If somebody else have the
> same problems ...
>
> Nicolas.
>
> Sorry for my poor english.
>
> PS: funny "bug" isn't it ? (hotmail !)
> PS2: thanks for all, very good job done,
> 2.4 is very fast and seems stable.
>
>
>
> -
> 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/
>
--
Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED]
Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
-- Alan J. Perlis
-
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: kernel network problem ?
You have to take a look at ENC:
Explicit Congestion Notification (ECN) allows routers to notify
clients about network congestion, resulting in fewer dropped packets
and increased network performance. This option adds ECN support to the
Linux kernel, as well as a sysctl (/proc/sys/net/ipv4/tcp_ecn) which
allows ECN support to be disabled at runtime.
Note that, on the Internet, there are many broken firewalls which
refuse connections from ECN-enabled machines, and it may be a while
before these firewalls are fixed. Until then, to access a site behind
such a firewall (some of which are major sites, at the time of this
writing) you will have to disable this option, either by saying N now
or by using the sysctl.
You can disable it at runtime with:
echo 0 /proc/sys/net/ipv4/tcp_ecn
[EMAIL PROTECTED] ("Nicolas Parpandet") writes:
Hi all,
I'm testing 2.4 series for few weeks,
even the last prerelease
I've seen stranges things :
I cannot access to some ips adresses ! :
in http or in smtp using "konqueror", "netscape",
"mail", "telnet 25".
I cannot login to hotmail (in the web page:http)
or send mail (smtp) to hotmail users (don't blame me !!)
All the others network things works well, the network in general seems
good only very few sites like hotmail doesn't works.
And only with 2.4 series !! not with 2.2 ...
maybe it's a glibc or kernel issue, I'dont know.
I have an intel SMP motherboard connected to the net (cable)
with a PCI realtek 8019.
I didn't analyse packets sent. If somebody else have the
same problems ...
Nicolas.
Sorry for my poor english.
PS: funny "bug" isn't it ? (hotmail !)
PS2: thanks for all, very good job done,
2.4 is very fast and seems stable.
-
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/
--
Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED]
Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
-- Alan J. Perlis
-
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: Abysmal RAID 0 performance on 2.4.0-test10 for IDE?
[EMAIL PROTECTED] (Tim Wright) writes: > On Wed, Dec 27, 2000 at 04:23:43PM +, Paul Jakma wrote: > > On Tue, 26 Dec 2000, Ian Stirling wrote: > > > > > The PCI bus can move around 130MB/sec, > > > > in bursts yes, but sustained data bandwidth of PCI is a lot lower, > > maybe 30 to 50MB/s. And you won't get sustained RAID performance > > > sustained PCI performance. > > > > No. A well-designed card and driver doing cache-line sized transfers can > achieve ~100MB/s. On the IBM (Sequent) NUMA machines, we achieved in excess > of 3GB/s sustained read I/O (database full table scan) on a 16-quad (32 PCI > bus) system. That works out at around 100MB/s per bus. Sadly, I am sure that your "well-designed" system must be costly as hell... :( -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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: Abysmal RAID 0 performance on 2.4.0-test10 for IDE?
[EMAIL PROTECTED] (Tim Wright) writes: On Wed, Dec 27, 2000 at 04:23:43PM +, Paul Jakma wrote: On Tue, 26 Dec 2000, Ian Stirling wrote: The PCI bus can move around 130MB/sec, in bursts yes, but sustained data bandwidth of PCI is a lot lower, maybe 30 to 50MB/s. And you won't get sustained RAID performance sustained PCI performance. No. A well-designed card and driver doing cache-line sized transfers can achieve ~100MB/s. On the IBM (Sequent) NUMA machines, we achieved in excess of 3GB/s sustained read I/O (database full table scan) on a 16-quad (32 PCI bus) system. That works out at around 100MB/s per bus. Sadly, I am sure that your "well-designed" system must be costly as hell... :( -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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/
Sound problem with AC97 module
Hello! I have a Dell precision 220 at work with an built-in sound card. The problem I have is that I continiously get these error messages in my logs: Dec 14 18:21:02 shookay kernel: DMA overrun on send Dec 14 18:21:02 shookay kernel: i810_audio: drain_dac, dma timeout? I have joined output of the module and output of lspci. My motherboard's chipset is an i820. If I can give further help or debugging stuff, please let me know! Regards, Mathieu. Here the output of the soundcard module: Dec 14 17:13:25 shookay kernel: Intel 810 + AC97 Audio, version 0.01, 13:38:36 Dec 12 2000 Dec 14 17:13:25 shookay kernel: PCI: Setting latency timer of device 00:1f.5 to 64 Dec 14 17:13:25 shookay kernel: i810: Intel ICH 82801AA found at IO 0xdc80 and 0xd800, IRQ 17 Dec 14 17:13:25 shookay kernel: ac97_codec: AC97 Audio codec, id: 0x4144:0x5340 (Analog Devices AD1881) Here the output of lspci: = 00:00.0 Host bridge: Intel Corporation 82820 820 (Camino) Chipset Host Bridge (MCH) (rev 03) Subsystem: Dell Computer Corporation: Unknown device 0095 Flags: bus master, fast devsel, latency 0 Memory at e000 (32-bit, prefetchable) [size=256M] Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: Intel Corporation 82820 820 (Camino) Chipset PCI to AGP Bridge (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Memory behind bridge: fc00-fdff Prefetchable memory behind bridge: f000-f1ff 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 I/O behind bridge: e000-efff Memory behind bridge: fa00-fbff 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) (prog-if 80 [Master]) Subsystem: Intel Corporation 82801AA IDE Flags: bus master, medium devsel, latency 0 I/O ports at ffa0 [size=16] 00:1f.2 USB Controller: Intel Corporation 82801AA USB (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801AA USB Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at ff80 [size=32] 00:1f.3 SMBus: Intel Corporation 82801AA SMBus (rev 02) Subsystem: Intel Corporation 82801AA SMBus Flags: medium devsel, IRQ 17 I/O ports at dcd0 [size=16] 00:1f.5 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio (rev 02) Subsystem: Dell Computer Corporation: Unknown device 0095 Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at d800 [size=256] I/O ports at dc80 [size=64] 01:00.0 VGA compatible controller: nVidia Corporation Riva TnT2 [NV5] (rev 11) (prog-if 00 [VGA]) Subsystem: Diamond Multimedia Systems: Unknown device 5a40 Flags: 66Mhz, medium devsel, IRQ 16 Memory at fc00 (32-bit, non-prefetchable) [size=16M] Memory at f000 (32-bit, prefetchable) [size=32M] Expansion ROM at 8000 [disabled] [size=64K] Capabilities: [60] Power Management version 1 Capabilities: [44] AGP version 2.0 02:07.0 SCSI storage controller: Adaptec AHA-2940U2/W Subsystem: Adaptec: Unknown device 2180 Flags: bus master, medium devsel, latency 64, IRQ 16 BIST result: 00 I/O ports at ec00 [size=256] Memory at fafff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at fb00 [disabled] [size=128K] Capabilities: [dc] Power Management version 1 02:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 78) Subsystem: Dell Computer Corporation: Unknown device 0095 Flags: bus master, medium devsel, latency 64, IRQ 18 I/O ports at e880 [size=128] Memory at faffec00 (32-bit, non-prefetchable) [size=128] Expansion ROM at fb00 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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/
unexpected IO-APIC
2.4494 MHz. Dec 14 17:13:24 shookay kernel: cpu: 0, clocks: 1324494, slice: 662247 Dec 14 17:13:24 shookay kernel: CPU0 Dec 14 17:13:24 shookay kernel: mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) Dec 14 17:13:24 shookay kernel: mtrr: detected mtrr type: Intel Dec 14 17:13:24 shookay kernel: PCI: PCI BIOS revision 2.10 entry at 0xfc05e, last bus=2 Dec 14 17:13:24 shookay kernel: PCI: Using configuration type 1 Dec 14 17:13:24 shookay kernel: PCI: Probing PCI hardware Dec 14 17:13:24 shookay kernel: Unknown bridge resource 0: assuming transparent Dec 14 17:13:24 shookay kernel: Unknown bridge resource 2: assuming transparent Dec 14 17:13:24 shookay kernel: PCI: Using IRQ router PIIX [8086/2410] at 00:1f.0 Dec 14 17:13:24 shookay kernel: PCI->APIC IRQ transform: (B0,I31,P3) -> 19 Dec 14 17:13:24 shookay kernel: PCI->APIC IRQ transform: (B0,I31,P1) -> 17 Dec 14 17:13:24 shookay kernel: PCI->APIC IRQ transform: (B0,I31,P1) -> 17 Dec 14 17:13:24 shookay kernel: PCI->APIC IRQ transform: (B1,I0,P0) -> 16 Dec 14 17:13:25 shookay kernel: PCI->APIC IRQ transform: (B2,I7,P0) -> 16 Dec 14 17:13:25 shookay kernel: PCI->APIC IRQ transform: (B2,I12,P0) -> 18 lscpi output == 00:00.0 Host bridge: Intel Corporation 82820 820 (Camino) Chipset Host Bridge (MCH) (rev 03) Subsystem: Dell Computer Corporation: Unknown device 0095 Flags: bus master, fast devsel, latency 0 Memory at e000 (32-bit, prefetchable) [size=256M] Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: Intel Corporation 82820 820 (Camino) Chipset PCI to AGP Bridge (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Memory behind bridge: fc00-fdff Prefetchable memory behind bridge: f000-f1ff 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 I/O behind bridge: e000-efff Memory behind bridge: fa00-fbff 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) (prog-if 80 [Master]) Subsystem: Intel Corporation 82801AA IDE Flags: bus master, medium devsel, latency 0 I/O ports at ffa0 [size=16] 00:1f.2 USB Controller: Intel Corporation 82801AA USB (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801AA USB Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at ff80 [size=32] 00:1f.3 SMBus: Intel Corporation 82801AA SMBus (rev 02) Subsystem: Intel Corporation 82801AA SMBus Flags: medium devsel, IRQ 17 I/O ports at dcd0 [size=16] 00:1f.5 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio (rev 02) Subsystem: Dell Computer Corporation: Unknown device 0095 Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at d800 [size=256] I/O ports at dc80 [size=64] 01:00.0 VGA compatible controller: nVidia Corporation Riva TnT2 [NV5] (rev 11) (prog-if 00 [VGA]) Subsystem: Diamond Multimedia Systems: Unknown device 5a40 Flags: 66Mhz, medium devsel, IRQ 16 Memory at fc00 (32-bit, non-prefetchable) [size=16M] Memory at f000 (32-bit, prefetchable) [size=32M] Expansion ROM at 8000 [disabled] [size=64K] Capabilities: [60] Power Management version 1 Capabilities: [44] AGP version 2.0 02:07.0 SCSI storage controller: Adaptec AHA-2940U2/W Subsystem: Adaptec: Unknown device 2180 Flags: bus master, medium devsel, latency 64, IRQ 16 BIST result: 00 I/O ports at ec00 [size=256] Memory at fafff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at fb00 [disabled] [size=128K] Capabilities: [dc] Power Management version 1 02:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 78) Subsystem: Dell Computer Corporation: Unknown device 0095 Flags: bus master, medium devsel, latency 64, IRQ 18 I/O ports at e880 [size=128] Memory at faffec00 (32-bit, non-prefetchable) [size=128] Expansion ROM at fb000000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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/
unexpected IO-APIC
: 662247 Dec 14 17:13:24 shookay kernel: CPU0T0:1324480,T1:662224,D:9,S:662247,C:1324494 Dec 14 17:13:24 shookay kernel: mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) Dec 14 17:13:24 shookay kernel: mtrr: detected mtrr type: Intel Dec 14 17:13:24 shookay kernel: PCI: PCI BIOS revision 2.10 entry at 0xfc05e, last bus=2 Dec 14 17:13:24 shookay kernel: PCI: Using configuration type 1 Dec 14 17:13:24 shookay kernel: PCI: Probing PCI hardware Dec 14 17:13:24 shookay kernel: Unknown bridge resource 0: assuming transparent Dec 14 17:13:24 shookay kernel: Unknown bridge resource 2: assuming transparent Dec 14 17:13:24 shookay kernel: PCI: Using IRQ router PIIX [8086/2410] at 00:1f.0 Dec 14 17:13:24 shookay kernel: PCI-APIC IRQ transform: (B0,I31,P3) - 19 Dec 14 17:13:24 shookay kernel: PCI-APIC IRQ transform: (B0,I31,P1) - 17 Dec 14 17:13:24 shookay kernel: PCI-APIC IRQ transform: (B0,I31,P1) - 17 Dec 14 17:13:24 shookay kernel: PCI-APIC IRQ transform: (B1,I0,P0) - 16 Dec 14 17:13:25 shookay kernel: PCI-APIC IRQ transform: (B2,I7,P0) - 16 Dec 14 17:13:25 shookay kernel: PCI-APIC IRQ transform: (B2,I12,P0) - 18 lscpi output == 00:00.0 Host bridge: Intel Corporation 82820 820 (Camino) Chipset Host Bridge (MCH) (rev 03) Subsystem: Dell Computer Corporation: Unknown device 0095 Flags: bus master, fast devsel, latency 0 Memory at e000 (32-bit, prefetchable) [size=256M] Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: Intel Corporation 82820 820 (Camino) Chipset PCI to AGP Bridge (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Memory behind bridge: fc00-fdff Prefetchable memory behind bridge: f000-f1ff 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 I/O behind bridge: e000-efff Memory behind bridge: fa00-fbff 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) (prog-if 80 [Master]) Subsystem: Intel Corporation 82801AA IDE Flags: bus master, medium devsel, latency 0 I/O ports at ffa0 [size=16] 00:1f.2 USB Controller: Intel Corporation 82801AA USB (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801AA USB Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at ff80 [size=32] 00:1f.3 SMBus: Intel Corporation 82801AA SMBus (rev 02) Subsystem: Intel Corporation 82801AA SMBus Flags: medium devsel, IRQ 17 I/O ports at dcd0 [size=16] 00:1f.5 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio (rev 02) Subsystem: Dell Computer Corporation: Unknown device 0095 Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at d800 [size=256] I/O ports at dc80 [size=64] 01:00.0 VGA compatible controller: nVidia Corporation Riva TnT2 [NV5] (rev 11) (prog-if 00 [VGA]) Subsystem: Diamond Multimedia Systems: Unknown device 5a40 Flags: 66Mhz, medium devsel, IRQ 16 Memory at fc00 (32-bit, non-prefetchable) [size=16M] Memory at f000 (32-bit, prefetchable) [size=32M] Expansion ROM at 8000 [disabled] [size=64K] Capabilities: [60] Power Management version 1 Capabilities: [44] AGP version 2.0 02:07.0 SCSI storage controller: Adaptec AHA-2940U2/W Subsystem: Adaptec: Unknown device 2180 Flags: bus master, medium devsel, latency 64, IRQ 16 BIST result: 00 I/O ports at ec00 [size=256] Memory at fafff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at fb00 [disabled] [size=128K] Capabilities: [dc] Power Management version 1 02:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 78) Subsystem: Dell Computer Corporation: Unknown device 0095 Flags: bus master, medium devsel, latency 64, IRQ 18 I/O ports at e880 [size=128] Memory at faffec00 (32-bit, non-prefetchable) [size=128] Expansion ROM at fb00 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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/
Sound problem with AC97 module
Hello! I have a Dell precision 220 at work with an built-in sound card. The problem I have is that I continiously get these error messages in my logs: Dec 14 18:21:02 shookay kernel: DMA overrun on send Dec 14 18:21:02 shookay kernel: i810_audio: drain_dac, dma timeout? I have joined output of the module and output of lspci. My motherboard's chipset is an i820. If I can give further help or debugging stuff, please let me know! Regards, Mathieu. Here the output of the soundcard module: Dec 14 17:13:25 shookay kernel: Intel 810 + AC97 Audio, version 0.01, 13:38:36 Dec 12 2000 Dec 14 17:13:25 shookay kernel: PCI: Setting latency timer of device 00:1f.5 to 64 Dec 14 17:13:25 shookay kernel: i810: Intel ICH 82801AA found at IO 0xdc80 and 0xd800, IRQ 17 Dec 14 17:13:25 shookay kernel: ac97_codec: AC97 Audio codec, id: 0x4144:0x5340 (Analog Devices AD1881) Here the output of lspci: = 00:00.0 Host bridge: Intel Corporation 82820 820 (Camino) Chipset Host Bridge (MCH) (rev 03) Subsystem: Dell Computer Corporation: Unknown device 0095 Flags: bus master, fast devsel, latency 0 Memory at e000 (32-bit, prefetchable) [size=256M] Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: Intel Corporation 82820 820 (Camino) Chipset PCI to AGP Bridge (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Memory behind bridge: fc00-fdff Prefetchable memory behind bridge: f000-f1ff 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 I/O behind bridge: e000-efff Memory behind bridge: fa00-fbff 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) (prog-if 80 [Master]) Subsystem: Intel Corporation 82801AA IDE Flags: bus master, medium devsel, latency 0 I/O ports at ffa0 [size=16] 00:1f.2 USB Controller: Intel Corporation 82801AA USB (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801AA USB Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at ff80 [size=32] 00:1f.3 SMBus: Intel Corporation 82801AA SMBus (rev 02) Subsystem: Intel Corporation 82801AA SMBus Flags: medium devsel, IRQ 17 I/O ports at dcd0 [size=16] 00:1f.5 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio (rev 02) Subsystem: Dell Computer Corporation: Unknown device 0095 Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at d800 [size=256] I/O ports at dc80 [size=64] 01:00.0 VGA compatible controller: nVidia Corporation Riva TnT2 [NV5] (rev 11) (prog-if 00 [VGA]) Subsystem: Diamond Multimedia Systems: Unknown device 5a40 Flags: 66Mhz, medium devsel, IRQ 16 Memory at fc00 (32-bit, non-prefetchable) [size=16M] Memory at f000 (32-bit, prefetchable) [size=32M] Expansion ROM at 8000 [disabled] [size=64K] Capabilities: [60] Power Management version 1 Capabilities: [44] AGP version 2.0 02:07.0 SCSI storage controller: Adaptec AHA-2940U2/W Subsystem: Adaptec: Unknown device 2180 Flags: bus master, medium devsel, latency 64, IRQ 16 BIST result: 00 I/O ports at ec00 [size=256] Memory at fafff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at fb00 [disabled] [size=128K] Capabilities: [dc] Power Management version 1 02:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 78) Subsystem: Dell Computer Corporation: Unknown device 0095 Flags: bus master, medium devsel, latency 64, IRQ 18 I/O ports at e880 [size=128] Memory at faffec00 (32-bit, non-prefetchable) [size=128] Expansion ROM at fb00 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - 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/
