Re: Mostly revert "e1000/e1000e: Move PCI-Express device IDs over to e1000e"
Adrian Bunk wrote: >> Jeff, Auke, would something like this be acceptable? It makes it very >> obvious in the driver table which entries are for the PCIE versions that >> would be handled by the E1000E driver if it is enabled.. > > I don't like it: > We should aim at having exactly one driver for one card. There is one thing I don't understand, but that may well be just me... >From Linus' original patch: > +++ b/drivers/net/e1000/e1000_main.c > + INTEL_E1000_ETHERNET_DEVICE(0x108C), So, apparently support for 8086:108c was removed from the e1000 driver. >From my lspci: $ lspci -nn | grep Ether 01:00.0 Ethernet controller [0200]: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) [8086:108c] (rev 03) But when I look at where that card is sitting: $ readlink pci/devices/\:01\:00.0/driver ../../../../bus/pci/drivers/e1000 So, it's on the PCI bus, not on the PCI-Express bus (which I also have, but which has no devices on it). Or does the e1000e driver also support cards on the PCI bus? If that's the case then the original changelog entry "Move PCI-Express device IDs over to e1000e" is misleading as it's not only PCI-Express devices... Hmmm. Or does which driver is loaded decide on which bus the device ends up? Confused, FJP -- 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: Typo in net/netfilter/xt_iprange.c (git tree)
Forward to netdev list. --- Forwarded message (begin) Subject: Typo in net/netfilter/xt_iprange.c (git tree) From: Jiri Moravec <...> Date: Fri, 01 Feb 2008 15:50:15 +0100 Function iprange_mt4 belong to IPv4 family - AF_INET. Right? .name = "iprange", .revision = 1, .family= AF_INET6, <-- Typo? .match = iprange_mt4, .matchsize = sizeof(struct xt_iprange_mtinfo), .me= THIS_MODULE, --- Forwarded message (end) -- 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: Incompatibility of "const" and __xxxinitdata?
Peter Teoh wrote: > In include/linux/init.h, it is documented that all __xxxinitdata > declaration must not have constant, as show below: See: http://lkml.org/lkml/2008/1/26/182 There's a fairly major cleanup happening at the moment as you could see from the mailing list archives for the past week or so. Cheers, FJP -- 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: [REVIEW for merge] kbuild updates including silence of section mismatch check
Sam Ravnborg wrote:
> --- a/scripts/setlocalversion
> +++ b/scripts/setlocalversion
> @@ -45,3 +45,18 @@ if hgid=`hg id 2>/dev/null`; then
> # All done with mercurial
> exit
> fi
> +
> +# Check for svn and a svn repo.
> +if rev=`svn info 2>/dev/null | grep '^Revision' | awk '{print $NF}'` ; then
> + changes=`svn status 2>/dev/null | grep '^[AMD]' | wc -l`
> +
> + # Are there uncommitted changes?
> + if [ $changes != 0 ]; then
> + printf -- '-svn%s%s%s' "$rev" -dirty "$changes"
> + else
> + printf -- '-svn%s' "$rev"
> + fi
> +
> + # All done with svn
> + exit
> +fi
This looks broken. Unless I'm very much mistaken the 'if' statement is
always going to be true because the awk statement will always execute
without error. Try: echo "" | awk '{print $NF}' || echo Error
So, the code should probably be changed to:
+if rev=`svn info 2>/dev/null | grep '^Revision' ; then
+ rev=`echo $rev | awk '{print $NF}'`
+ changes=`svn status 2>/dev/null | grep '^[AMD]' | wc -l`
or alternatively:
+if rev=`svn info 2>/dev/null | grep '^Revision' | awk '{print $NF}'` && \
+ [ -n "$rev" ] ; then
+ changes=`svn status 2>/dev/null | grep '^[AMD]' | wc -l`
Cheers,
FJP
P.S. Looks like the mercurial section is missing some indentation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: restore correct module name for apm
Sam Ravnborg wrote: > The apm module were renamed to apm_32 during the merge of 32 and 64 bit > x86 which is unfortunate. > As apm is 32 bit specific we like to keep the _32 in the filename > but the module should be named apm. > > Fix this in the Makefile. > Reported by "A.E.Lawrence" <[EMAIL PROTECTED]> > > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> > Cc: Cc: Ingo Molnar <[EMAIL PROTECTED]> > Cc: Thomas Gleixner <[EMAIL PROTECTED]> > Cc: "H. Peter Anvin" <[EMAIL PROTECTED]> > Cc: "A.E.Lawrence" <[EMAIL PROTECTED]> I assume this will be pushed for stable 2.6.24 as well? Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Tuesday 12 February 2008, Greg KH wrote: > On Tue, Feb 12, 2008 at 09:39:14PM +0100, Frans Pop wrote: > > On Monday 11 February 2008, Frans Pop wrote: > > > In general 2.6.25 if looking quite good on my desktop, but there's > > > one important issue: the system no longer powers off after shutdown. > > > This works fine with 2.6.24. > > > > Don't ask me why, but bisection shows this commit to be the cause of > > the failure to power off: > > commit c10997f6575f476ff38442fa18fd4a0d80345f9d > > Author: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > Date: Thu Dec 20 08:13:05 2007 -0800 > > > > Kobject: convert drivers/* from kobject_unregister() to > > kobject_put() > > > > Because it seemed somewhat unlikely, I have double checked this by > > doing an extra compilation for this commit and its predecessor. > > What is the symptom of not powering off? Symptom is that the system shuts down normally and completely, it just does not power off. Here are the last messages on the console: Will now halt. sd 1:0:0:0: [sdb] Synchronizing SCSI cache sd 1:0:0:0: [sdb] Stopping disk sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk ACPI: PCI interrupt for device :01:00.0 disabled Disabling non-boot CPUs ... > Can you press SysRq-T and see a task list running and waiting when > things should be shut down? The system does not respond to that anymore. > Do you happen to have a USB storage stick plugged into the system? Nothing. Only USB kbd/mouse. Note that I've had this issue before with this box: http://bugzilla.kernel.org/show_bug.cgi?id=6879 Somehow it disappeared when I pulled the extra video card that came with the system (no decent driver for it, so no loss). Since then the system has always powered off completely reliably. This time it is a clear and reproducible regression. If we can solve this one we might get a better handle on #6879 too. Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] jerky mouse cursor and randoooom key repeats
On Monday 11 February 2008, Frans Pop wrote: > In general 2.6.25 if looking quite good on my desktop, but there's one > important issue: the system no longer powers off after shutdown. > This works fine with 2.6.24. I was wrong :-( I'd not really done any real wor under 2.6.25 yet, but now while running a kernel compile with -j4 (single processor, dual core Pentium D), I see this behavior. The mouse cursor moves a bit jerky and I sometimes get key presses repeated. While I'm typing this, the load lowers a bit and immediately things become smoother and the key repeats seem to vanish. (The key repeats in the subject and para above are real examples of this, not typo's.) The keyboard repeat issue looks like what was reported in [1], but for me this is very definitely an new issue that did not appear with 2.6.24 or earlier. Cheers, FJP [1] http://lkml.org/lkml/2008/2/6/100 -- 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: [stable 2.6.24] WARNING: at kernel/time/clockevents.c
On Wednesday 13 February 2008, Thomas Gleixner wrote: > On Tue, 12 Feb 2008, Andrew Morton wrote: > > On Sun, 10 Feb 2008 14:40:21 +0100 Frans Pop <[EMAIL PROTECTED]> wrote: > > the hrtimer code is preparing an invalid ktime_t. Note that > > clockevents_program_event() actually fails when this happens - I am > > surprised that this is not causing observeable userspace problems. > > > > The WARN_ON_ONCE() means that you'll only see this warning once per > > boot. But the actually error could be happening any number of times > > without being reported. > > > > Looks pretty serious? > > Yes. It's the same problem, which got fixed with: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit >;h=62f0f61e6673e67151a7c8c0f9a09c7ea43fe2b5 OK, so probably glibc performs a unit test during build that asks for a long sleep. I guess that makes sense. Thanks Thomas and Andrew. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Wednesday 13 February 2008, you wrote: > On Tue, 12 Feb 2008 22:45:09 +0100 Frans Pop <[EMAIL PROTECTED]> wrote: > > Symptom is that the system shuts down normally and completely, it just > > does not power off. > > I've been struggling with an identically-manifesting regression on one of > my test machines for a week. It's due to softlockup changes, and setting > CONFIG_DETECT_SOFTLOCKUP=n "fixes" it. > > It sounds unlikely, but I'd suggest that you see if it's the same on your > machine so we're not both chasing the same bug. Unsetting CONFIG_DETECT_SOFTLOCKUP does not help in my case, but thanks for the suggestion. -- 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/
[PATCH] kbuild: allow to specify a custom revision for .deb packages
From: Frans Pop <[EMAIL PROTECTED]> Allow to specify a custom revision for the generated .deb package by exporting the environment variable KERNELDEBREVISION. Signed-off-by: Frans Pop <[EMAIL PROTECTED]> diff --git a/scripts/package/builddeb b/scripts/package/builddeb index ba6bf5d..2577dec 100644 --- a/scripts/package/builddeb +++ b/scripts/package/builddeb @@ -14,6 +14,11 @@ set -e # Some variables and settings used throughout the script version=$KERNELRELEASE revision=`cat .version` +if [ x"$KERNELDEBREVISION" = x ]; then + debrevision=$version-$revision +else + debrevision=$KERNELDEBREVISION +fi tmpdir="$objtree/debian/tmp" packagename=linux-$version @@ -66,7 +71,7 @@ done name="Kernel Compiler <$(id -nu)@$(hostname -f)>" # Generate a simple changelog template cat < debian/changelog -linux ($version-$revision) unstable; urgency=low +linux ($debrevision) unstable; urgency=low * A standard release -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Tuesday 12 February 2008, Greg KH wrote: > On Tue, Feb 12, 2008 at 09:39:14PM +0100, Frans Pop wrote: > > On Monday 11 February 2008, Frans Pop wrote: > > > In general 2.6.25 if looking quite good on my desktop, but there's > > > one important issue: the system no longer powers off after shutdown. > > > This works fine with 2.6.24. > > > > Don't ask me why, but bisection shows this commit to be the cause of > > the failure to power off: > > commit c10997f6575f476ff38442fa18fd4a0d80345f9d > > Author: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > Date: Thu Dec 20 08:13:05 2007 -0800 > > > > Kobject: convert drivers/* from kobject_unregister() to > > kobject_put() > > > > Because it seemed somewhat unlikely, I have double checked this by > > doing an extra compilation for this commit and its predecessor. > > What is the symptom of not powering off? I already noticed yesterday that there's one hunk in that commit that's not a straight replacement: diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 9e102af..5efd555 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1030,8 +1030,6 @@ static int __cpufreq_remove_dev (struct sys_device * sys_dev) unlock_policy_rwsem_write(cpu); - kobject_unregister(&data->kobj); - kobject_put(&data->kobj); /* we need to make sure that the underlying kobj is actually So, just on the off chance, I applied the patch below and bingo, the system powers off again. I doubt this will be the correct solution, but just in case it is, here's my signed off. A comment why the double put is needed would probably be good though. Signed-off-by: Frans Pop <[EMAIL PROTECTED]> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 64926aa..9dbaac6 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1058,6 +1058,7 @@ static int __cpufreq_remove_dev (struct sys_device * sys_dev) unlock_policy_rwsem_write(cpu); kobject_put(&data->kobj); + kobject_put(&data->kobj); /* we need to make sure that the underlying kobj is actually * not referenced anymore by anybody before we proceed with -- 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/
[PATCH] kbuild: allow alternative hook script dir in .deb packages
From: Frans Pop <[EMAIL PROTECTED]>
Hook scripts in the default directory /etc/kernel are also
executed by packages created using make-kpkg (including official
Debian kernels). Allow to specify an alternative hook scripts
directory by exporting the environment variable KERNELDEBHOOKDIR
so that this can be avoided.
Signed-off-by: Frans Pop <[EMAIL PROTECTED]>
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 2577dec..c76bbf1 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -55,14 +55,17 @@ if grep -q '^CONFIG_MODULES=y' .config ; then
fi
# Install the maintainer scripts
+# Note: hook scripts under /etc/kernel are also executed by kernel packages
+# built using make-kpkg (from the "kernelpackage" package)
+debhookdir=${KERNELDEBHOOKDIR:-/etc/kernel}
for script in postinst postrm preinst prerm ; do
- mkdir -p "$tmpdir/etc/kernel/$script.d"
+ mkdir -p "$tmpdir$debhookdir/$script.d"
cat < "$tmpdir/DEBIAN/$script"
#!/bin/sh
set -e
-test -d /etc/kernel/$script.d && run-parts --arg="$version"
/etc/kernel/$script.d
+test -d $debhookdir/$script.d && run-parts --arg="$version"
$debhookdir/$script.d
exit 0
EOF
chmod 755 "$tmpdir/DEBIAN/$script"
signature.asc
Description: This is a digitally signed message part.
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Wednesday 13 February 2008, Greg KH wrote: > > So, just on the off chance, I applied the patch below and bingo, the > > system powers off again. I doubt this will be the correct solution, but > > just in case it is, here's my signed off. A comment why the double put > > is needed would probably be good though. > > There is a bug in the cpufreq kref logic that makes this "double put" > necessary. A real fix has already been posted to solve this issue, and > I think it should be on it's way to Linus for -rc2 already. OK, great. Do you think that #6879 could be caused by a similar issue elsewhere in the tree? Can you give me some pointers on how I could find out (debugging to enable, instrumentation to add)? > Please let me know if -rc2 comes out without this needed fix. Will do. -- 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: [stable 2.6.24] WARNING: at kernel/time/clockevents.c
On Wednesday 13 February 2008, Thomas Gleixner wrote: > can you please apply the following patch ? I really should have > thought about that, when I fixed the above one. I still get the bug with this patch. At least I'm now certain it happens during glibc compilation and that I can reproduce it. I applied your patch on top of 2.6.24.2 (applied with only minor offsets) because I also saw the issue with that kernel and I don't yet completely trust 2.6.25. Here's the error from this run: WARNING: at kernel/time/clockevents.c:82 clockevents_program_event() Pid: 27638, comm: ld-linux.so.2 Not tainted 2.6.24.2-test1 #39 Call Trace: [] ktime_get+0xc/0x41 [] clockevents_program_event+0x3b/0x94 [] tick_program_event+0x31/0x4d [] hrtimer_reprogram+0x3b/0x51 [] enqueue_hrtimer+0x66/0x102 [] hrtimer_start+0x102/0x125 [] :ext3:__ext3_journal_stop+0x1f/0x3d [] rt_mutex_slowlock+0x90/0x53a [] find_lock_page+0x29/0x8d [] find_extend_vma+0x16/0x59 [] get_futex_key+0x82/0x14e [] futex_lock_pi+0x60f/0x90d [] hrtimer_wakeup+0x0/0x21 [] rt_mutex_slowlock+0x90/0x53a [] do_futex+0xa08/0xa3d [] error_exit+0x0/0x51 [] compat_sys_futex+0xf0/0x10e [] __switch_to+0x10e/0x27e [] schedule_tail+0x23/0x60 [] ia32_sysret+0x0/0xa Cheers, FJP -- 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: [stable 2.6.24] WARNING: at kernel/time/clockevents.c
On Thursday 14 February 2008, Thomas Gleixner wrote: > futex_lock_pi is called with an absolute timeout, which is based on > CLOCK_REALTIME. Nothing wrong with that, but the clockevents WARN_ON > might trap over a false positive, when the expiry value is less than > base->offset. This was intentional before we put the WARN_ON into the > clockevents code. > > The patch below should fix this issue. With these two patches on top of 2.6.24.2 I no longer get any warnings during a glibc compile: - hrtimer: check relative timeouts for overflow - hrtimer: fix abs clock realtime Thanks Thomas. Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Friday 15 February 2008, Greg KH wrote:
> I swear someone sent this patch in before. Can you try this one below,
> there seems to be an imbalance with kobject_get and _put.
I did remember seeing this patch before [1] and can confirm that it does
indeed fix the issue: with this patch applied to 2.6.25 git head my system
powers off correctly.
[1] See http://lkml.org/lkml/2008/2/8/342; also added to #9960.
> ---
> drivers/cpufreq/cpufreq.c |8
> 1 file changed, 8 deletions(-)
>
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1006,14 +1006,6 @@ static int __cpufreq_remove_dev (struct
> }
> #endif
>
> -
> - if (!kobject_get(&data->kobj)) {
> - spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> - cpufreq_debug_enable_ratelimit();
> - unlock_policy_rwsem_write(cpu);
> - return -EFAULT;
> - }
> -
> #ifdef CONFIG_SMP
>
> #ifdef CONFIG_HOTPLUG_CPU
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION 2.6.23] no vga console and no messages
Daniel Barkalow wrote: > For some reason I can't see and don't know how to debug, in 2.6.23 on my > server I don't get the vga console, but only get the dummy console. Please check if this bug report matches the issue you are seeing: http://bugzilla.kernel.org/show_bug.cgi?id=9310 Cheers, FJP -- 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/
Unable to continue testing of 2.6.25
Yesterday, after spending quite a few hours over the last days on bisecting some serious regressions and finding workarounds for them, I thought I could start using 2.6.25-rc2 as the new kernel for my desktop. Unfortunately I found that I cannot because it would make my other main activity - working on the Debian installation system - impossible. For my work on the Debian Installer I heavily rely on emulators to run test installs and ATM my emulator of choice is VirtualBox (the fully open "ose" version). This requires the vboxdrv kernel module, but unfortunately: vboxdrv: Unknown symbol change_page_attr At first I traced this to: e1271f68 x86: deprecate change_page_attr() for drivers With the introduction of the new API, no driver or non-archcore code needs to use c-p-a anymore, so this patch also deprecates the EXPORT_SYMBOL of CPA (it's a horrible API after all). which had: -EXPORT_SYMBOL(change_page_attr); +EXPORT_UNUSED_SYMBOL(change_page_attr); /* to be removed in 2.6.27 */ Which seemed entirely reasonable but left me wondering about the error I got. But then I found: d1028a15 x86: make various pageattr.c functions static change_page_attr_add is only used in pageattr.c now, so we can make this function static. change_page_attr() isn't used anywere at all anymore; this function is a really bad API anyway so just remove the bloat entirely. Which removed the entire function (without even properly mentioning it in the shortlog). OF COURSE it is up to the VirtualBox developers to adjust to the new interface (and based on past experience I expect they will with their next version). And it may very well be that they were totally braindead to use the function in the first place. I don't know and I really don't care. The important fact for me is that I can no longer use a piece of software that is essential to me and thereby lose the motivation to do any work on the kernel. Lesson of the day: thinking only about in-kernel users of published API when doing restructuring is going to lose you testers who do MORE with their systems than just kernel development. Please allow external users some decent period for transitioning. The initial plan to "remove the old function in 2.6.27" was entirely sensible. It's a pity it was not followed through. Thanks, FJP P.S. Of course I _will_ follow up on issues that I've already reported. I will just not be doing any new testing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION 2.6.23] no vga console and no messages
On Sunday 17 February 2008, Daniel Barkalow wrote: > On Sun, 17 Feb 2008, Frans Pop wrote: > > Daniel Barkalow wrote: > > > For some reason I can't see and don't know how to debug, in 2.6.23 on > > > my server I don't get the vga console, but only get the dummy > > > console. > > > > Please check if this bug report matches the issue you are seeing: > > http://bugzilla.kernel.org/show_bug.cgi?id=9310 > > I think mine might be different. I've got a vga parameter (vga=0x301), > and mine disappears very early, before when you usually get "Console: > colour VGA+ 80x25" (and I'm getting "Console: coloud dummy 80x25" > instead). I've also got CONFIG_FB turned off entirely. The main question is: do you have FRAMEBUFFER_CONSOLE_DETECT_PRIMARY enabled in you kernel config. If you do, I'd try disabling it. > But if you've got any insight into how the console driver stuff works > from troubleshooting your problem, I could use the hints... Afraid not. Are you sure you have the correct framebuffer driver compiled into the kernel? Please post your kernel config and the output of 'lspci -nn', so people can have a look. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1/2 CD/DVD burning broken
Joerg Schilling wrote: > This fragment is much too short to allow to judge on possible reasons. > There is a high probability that your problem is caused by the cdrecord > fork called "wodim". There is also the 100% certainty that this reply was from a known troll and should just be ignored. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1/2 CD/DVD burning broken
On Monday 18 February 2008, Mike Galbraith wrote: > On Mon, 2008-02-18 at 09:46 +0100, Frans Pop wrote: > > Joerg Schilling wrote: > > > This fragment is much too short to allow to judge on possible > > > reasons. There is a high probability that your problem is caused by > > > the cdrecord fork called "wodim". > > > > There is also the 100% certainty that this reply was from a known troll > > and should just be ignored. > > That was rude, crude and uncalled for. I have no problems with my reply being called "rude" or "crude". After all, I wasn't even remotely trying to be nice or considerate. However, I do think it was called for as mr. Schilling's reply was nothing other than the next mail in his endlessly running FUD campain against Wodim. If you're not aware of that campain, please try for example the following link: http://www.google.com/search?q=schilling+wodim&ie=UTF-8&oe=UTF-8 Cheers, FJP -- 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.25-rc2 - Kernel Ooops while running dbench
Jeff Garzik wrote: > Two x86-64 boxes here lock up here on 2.6.25-rc2, shortly after boot. > One running Fedora 8 + X (GNOME) and one a headless file server. > configs and lspci attached. Unable to capture any splatter so far. Sounds like it may be http://lkml.org/lkml/2008/2/17/78. Suggest you try reverting that before doing the bisect. Cheers, FJP -- 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: Unable to continue testing of 2.6.25
On Sunday 17 February 2008, Adrian Bunk wrote: > The real problem is that the kernel seems to lack functionality you > require for doing some work. Not sure how you reached that conclusion. > Why does your work on the Debian Installer depend on VirtualBox and > can't be done with what the kernel already ships? Work on the installer does not so much hard depend on VirtualBox (or any other emulator), but can be done much more effectively and efficiently using one. It allows me to run the installer inside the emulator without the need for a second computer (and using the same keyboard). It allows me to take snapshots just before stages I'm interested in and then add debugging or try changes. If what I tried does not work, I can just revert to the snapshot and try something else without having to run the full installation from scratch. It allows me to easily test RAID setups without having multiple physical disks. Etc. The fact that VirtualBox does not (yet) work for me with 2.6.25 means that I'm unable to run 2.6.25 on my main desktop and do any real work. Rebooting my desktop whenever I want to use VirtualBox is just not a realistic option. That in turn means that I cannot do any more testing of 2.6.25, because most of the testing I do consists of just using a new kernel and critically observing the behavior of my system. As I've caught a fair number of bugs that way for the past few releases, I'd say that's a useful contribution. -- 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: Unable to continue testing of 2.6.25
On Sunday 17 February 2008, Arjan van de Ven wrote: > On Sun, 17 Feb 2008 14:38:51 -0600 Paul Jackson <[EMAIL PROTECTED]> wrote: > > Adrian wrote: > > > So let's fix the problem (kernel lacks functionality) > > > > That's the problem as understood by Adrian. > > > > I hear another problem as well ... > > > > Frans wrote: > > > Please allow external users some decent period for transitioning. > > > The initial plan to "remove the old function in 2.6.27" was > > > entirely sensible. It's a pity it was not followed through. > > > > That seems plain enough to me. It's not just the lack of > > functionality, but that such lack apparently happened with too little > > warning. > > > > If this is a fair representation of what happened, then seems to me > > that we could have left that EXPORT_UNUSED_SYMBOL(change_page_attr) > > in place a bit longer. > > it's not a fair repersentation. Again.. this export was unkeepable due to > the API being nasty and having to be fixed anyway ;(. > > One of the problems was that the c-p-a api has to be followed by a cache > flush function call. Sadly that does a TOTAL flush of the caches of all > cpus in the system. As part of the -rc1 changes, it is now done only on > the exact pages that need to be flushed (so you no longer flush 12Mb of > caches when you only needed to flush 4Kb), but to achieve that, it was no > longer an option to keep this as 2 separate function calls. > Add to this that some very fundemanteal bugs couldn't be fixed without > the function underlying cpa changing prototype and behavior, so the > function had to go. That's a much better explanation than can be found in the changelog. The changelog effectively says: this commits makes a few (new) functions static; oh, and by the way, let's delete the old function _because it is unused and ugly_. Well, I've shown that the first is not true and the second by itself is absolutely not sufficient reason to remove an exported function that has long been part of the kernel. I would probably have started this thread differently if the removal had been done in a separate commit and had included the explanation you give above. > I understand where he's coming from; at the same time it's a very small > change to virtualbox to fix this and has been done already... in minutes. The problem here is that it may be a simple change for you and other similarly gifted people, but it's something that's above _my_ skills. > Frans should take that up with the virtual box support forum, I'm sure I did actually manage to create such a patch for the breakage in the VirtualBox source because of 2.6.24, but those really were very minor issues (basically overlapping definitions). I posted that on their user list (to which I am subscribed), but I never saw any response to it. I also don't think it is really realistic to expect Innotek to provide patches for unreleased kernel versions. Maybe some other user could provide me with the patch, but I'm not as confident as you are. My point still is that I feel they should not have to. That it's also the kernel developers responsibility to ensure backwards compatibility or at least a grace period for conversion whenever possible. And IMO that not only goes for user-space API, but also for interfaces used by out-of-tree kernel modules. Is it really impossible in this case for example to rewrite the old function so that it becomes a wrapper around the new interface? If it is impossible, then so be it. > they have the patch available there. I haven't seen anything on the user mailing list yet... On Tuesday 19 February 2008, Arjan van de Ven wrote: > I assume you've read the other mails right and went to the virtualbox > form to get the small patch to make it work on .25 right? If you can give me a link to that patch, I'd be grateful. As I said, I'm subscribed to their user list but have not seen any patch there. I've also googled for it, without result. I've also just quickly checked their "VirtualBox on Linux" forum, but did not see any obvious existing post about it. Cheers, FJP -- 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: Unable to continue testing of 2.6.25
On Tuesday 19 February 2008, Adrian Bunk wrote: > The "or any other emulator" is exactly where my question is directed at. > > Xen, KVM or even qemu come into my mind, but considering how loudly you > complained about a temporary breakage for VirtualBox there must be a > reason why your work on the Debian Installer can only be done > effectively and efficiently with an emulator module that has AFAIK not > been submitted for inclusion in the kernel. - Xen is currently not supported by the kernel Debian Installer uses (though work is being done to change that. - KVM AFAIK requires hardware support that I don't have. - QEMU is completely useless because of its slow speed without the (also out of tree) kqemu module, which does not work when the host system is x86_64 [1]. Also, I very much prefer the VirtualBox user interface over what qemu has to offer. - I've actually used VMWare for a long time (licenced), but stopped after the 5 series stopped working with current kernels and around that time VirtualBox became available as an alternative. Hope that explains. Cheers, FJP [1] http://bugs.debian.org/444160 -- 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: adapter, what's in a name
Karl Dahlke wrote: > Meantime, I pulled the emails out of the headers and pasted them in. > Hope that reasonably works. Well, you're still breaking the thread by starting a new one. Guess when you're implementing reply-to-all, you should also think about implementing support for In-Reply-To: and References: headers (and possibly a whole lot of other stuff that's supposed to be included in a standards-compliant MUA). Cheers, FJP -- 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/
[stable 2.6.24] WARNING: at kernel/time/clockevents.c
Kernel: vanilla 2.6.24 x86_64 SMP Environment: Debian unstable Processor: Intel(R) Pentium(R) D CPU 3.20GHz (dual core) I've been running this kernel without problems since its release, but yesterday evening I suddenly got the following error, and this afternoon it was repeated (below). The system had been powered down in between. I have no idea yet what triggers it and am unsure if I'll be able to reproduce. WARNING: at kernel/time/clockevents.c:82 clockevents_program_event() Pid: 2210, comm: ld-linux-x86-64 Not tainted 2.6.24 #1 Call Trace: [] ktime_get+0xc/0x41 [] clockevents_program_event+0x3b/0x94 [] tick_program_event+0x31/0x4d [] hrtimer_reprogram+0x3b/0x51 [] enqueue_hrtimer+0x66/0x102 [] hrtimer_start+0x105/0x128 [] rt_mutex_slowlock+0x90/0x53a [] find_extend_vma+0x16/0x59 [] get_futex_key+0x82/0x14e [] futex_lock_pi+0x60f/0x90d [] hrtimer_wakeup+0x0/0x21 [] rt_mutex_slowlock+0x90/0x53a [] do_futex+0xa08/0xa3d [] __dequeue_entity+0x1c/0x32 [] thread_return+0x3a/0xab [] sys_futex+0xe0/0xfe [] system_call+0x7e/0x83 WARNING: at kernel/time/clockevents.c:82 clockevents_program_event() Pid: 29517, comm: ld-linux.so.2 Not tainted 2.6.24 #1 Call Trace: [] ktime_get+0xc/0x41 [] clockevents_program_event+0x3b/0x94 [] tick_program_event+0x31/0x4d [] hrtimer_reprogram+0x3b/0x51 [] enqueue_hrtimer+0x66/0x102 [] hrtimer_start+0x105/0x128 [] rt_mutex_slowlock+0x90/0x53a [] thread_return+0x3a/0xab [] find_lock_page+0x29/0x8d [] find_extend_vma+0x16/0x59 [] get_futex_key+0x82/0x14e [] futex_lock_pi+0x60f/0x90d [] hrtimer_wakeup+0x0/0x21 [] rt_mutex_slowlock+0x90/0x53a [] do_futex+0xa08/0xa3d [] error_exit+0x0/0x51 [] compat_sys_futex+0xda/0xf8 [] ia32_sysret+0x0/0xa Any ideas? Cheers, FJP # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24 # Fri Jan 25 00:28:04 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_QUICKLIST is not set CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_SUPPORTS_OPROFILE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_HT=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is no
Re: [stable 2.6.24] WARNING: at kernel/time/clockevents.c
On Sunday 10 February 2008, Frans Pop wrote: > I have no idea yet what triggers it and am unsure if I'll be able to > reproduce. I think I know at least _when_ it happens: during compilation of glibc. This was almost certainly while compiling in the normal amd64 environment: > Pid: 2210, comm: ld-linux-x86-64 Not tainted 2.6.24 #1 And this was while compiling the glibc in an i386 unstable chroot: > Pid: 29517, comm: ld-linux.so.2 Not tainted 2.6.24 #1 Could it be that some glibc unit test triggers this? I have done one other compile of glibc yesterday though that did _not_ trigger the error, but that was using pbuilder (i.e. in an amd64 chroot). -- 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/
[patch] 2.6.8 Errors during initrd loading with / on LVM over RAID
I'm aware that devfs is being removed in 2.6.13, but this patch may still
interest maintainers of older versions.
I've debugged this problem using kernel version 2.6.8, but a check showed
this code is unchanged in 2.6.12. My system is Debian Sarge.
During boot using an initrd on a system having / on LVM over RAID, I
noticed the following messages on console and in /var/log/kern.log:
kernel: Inspecting /boot/System.map-2.6.8-2-686
kernel: Loaded 27390 symbols from /boot/System.map-2.6.8-2-686.
kernel: Symbols match kernel version 2.6.8.
kernel: No module symbols loaded - kernel modules not enabled.
kernel: ould not append to parent for /disc
kernel: devfs_mk_dir: invalid argument.<4>devfs_mk_dev: could not append
to parent for /disc
last message repeated 151 times
Cleaned for a missing \n in a printk and with added debug printk's in
fs/devfs/base.c, this looks like:
kernel: devfs_mk_dir: invalid argument, buf: .
kernel: _devfs_append_entry: -EEXIST for :disc
kernel: devfs_mk_dev: could not append to parent for /disc
(repeated)
The last two errors are a consequence of the error in devfs_mk_dir, so
can be ignored. The basic problem is that buf is empty when devfs_mk_dir
is called.
Tracing back I ended up in fs/partitions/check.c, which has the following
code in function register_disk:
/* No minors to use for partitions */
if (disk->minors == 1) {
if (disk->devfs_name[0] != '\0')
devfs_add_disk(disk);
return;
}
/* always add handle for the whole disk */
devfs_add_partitioned(disk);
This looks unlogical: why does the first statement check for empty
disk->devfs_name and is the second one called blindly?
Changing the last statement to:
if (disk->devfs_name[0] != '\0')
devfs_add_partitioned(disk);
else
printk(KERN_WARNING "%s: No devfs_name for %s.\n",
__FUNCTION__, disk->disk_name);
resulted in the errors disappearing and the following log output:
kernel: register_disk: No devfs_name for md_d0.
kernel: register_disk: No devfs_name for md_d64.
kernel: register_disk: No devfs_name for md_d128.
kernel: register_disk: No devfs_name for md_d192.
kernel: register_disk: No devfs_name for md_d4.
kernel: register_disk: No devfs_name for md_d68.
kernel: register_disk: No devfs_name for md_d132.
kernel: register_disk: No devfs_name for md_d196.
(repeated to md_d255)
The attached patch fixes the problem (and adds the missing \n).
--- fs/partitions/check.c.orig 2005-05-19 12:52:23.0 +0200
+++ fs/partitions/check.c 2005-07-29 00:36:04.523385998 +0200
@@ -348,7 +348,8 @@
}
/* always add handle for the whole disk */
- devfs_add_partitioned(disk);
+ if (disk->devfs_name[0] != '\0')
+ devfs_add_partitioned(disk);
/* No such device (e.g., media were just removed) */
if (!get_capacity(disk))
--- fs/devfs/base.c.orig 2005-07-29 00:32:03.329992027 +0200
+++ fs/devfs/base.c 2005-07-29 00:32:52.08934 +0200
@@ -1644,7 +1644,7 @@
va_start(args, fmt);
n = vsnprintf(buf, 64, fmt, args);
if (n >= 64 || !buf[0]) {
- printk(KERN_WARNING "%s: invalid argument.", __FUNCTION__);
+ printk(KERN_WARNING "%s: invalid argument.\n", __FUNCTION__);
return -EINVAL;
}
pgpKS89SWlhYZ.pgp
Description: PGP signature
[BUG] 2.6.24-rc5: 'sysctl table check failed' when turning on printer
(Resending as there were no replies on my first post mid December; issue is still there with -rc6.) This is the first time I've seen this error. Last time I used the printer was with 2.6.24-rc3 and that time this error did not occur. The error occurs when I start a print job, not when I turn the printer on. System is Pentium D x86_64 kernel running Debian unstable. Printer is a HP Photosmart P1100 connected via parallel port. Not sure who should be CCed on this. ppdev0: registered pardevice sysctl table check failed: /dev/parport/parport0/devices/ppdev0/timeslice Sysctl already exists Pid: 14491, comm: hpijs Not tainted 2.6.24-rc5 #1 Call Trace: [] set_fail+0x3f/0x47 [] sysctl_check_table+0x4ae/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] register_sysctl_table+0x52/0x9d [] :parport:parport_device_proc_register+0xc3/0xe3 [] :parport:parport_register_device+0x206/0x267 [] :ppdev:pp_irq+0x0/0x40 [] :ppdev:pp_ioctl+0x13f/0x77c [] do_ioctl+0x55/0x6b [] vfs_ioctl+0x243/0x25c [] sys_ioctl+0x51/0x71 [] system_call+0x7e/0x83 Cheers, FJP -- 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] 2.6.24-rc5: 'sysctl table check failed' when turning on printer
On Sunday 06 January 2008, Eric W. Biederman wrote: > Short of two programs coming in and simultaneously trying to claim > the parallel port and there being not exclusion in ppdev.c I don't > have a clue what could cause the reported error. That could well be the root cause as the full log shows: Jan 6 01:21:02 faramir kernel: ppdev0: registered pardevice Jan 6 01:21:03 faramir kernel: sysctl table check failed: /dev/parport/parport0/devices/ppdev0/timeslice Sysctl already exists Jan 6 01:21:03 faramir kernel: Pid: 11078, comm: hpijs Not tainted 2.6.24-rc6 #1 Jan 6 01:21:03 faramir kernel: Jan 6 01:21:03 faramir kernel: Call Trace: Jan 6 01:21:03 faramir kernel: [] set_fail+0x3f/0x47 Jan 6 01:21:03 faramir kernel: [] sysctl_check_table+0x4ae/0x4fb Jan 6 01:21:03 faramir kernel: [] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [] register_sysctl_table+0x52/0x9d Jan 6 01:21:03 faramir kernel: [] :parport:parport_device_proc_register+0xc3/0xe3 Jan 6 01:21:03 faramir kernel: [] :parport:parport_register_device+0x206/0x267 Jan 6 01:21:03 faramir kernel: [] :ppdev:pp_irq+0x0/0x40 Jan 6 01:21:03 faramir kernel: [] :ppdev:pp_ioctl+0x13f/0x77c Jan 6 01:21:03 faramir kernel: [] do_ioctl+0x55/0x6b Jan 6 01:21:03 faramir kernel: [] vfs_ioctl+0x243/0x25c Jan 6 01:21:03 faramir kernel: [] sys_ioctl+0x51/0x71 Jan 6 01:21:03 faramir kernel: [] system_call+0x7e/0x83 Jan 6 01:21:03 faramir kernel: Jan 6 01:21:03 faramir kernel: ppdev0: registered pardevice Jan 6 01:22:10 faramir kernel: ppdev0: released pardevice because user-space forgot Jan 6 01:22:10 faramir kernel: ppdev0: unregistered pardevice Jan 6 01:22:11 faramir kernel: ppdev0: unregistered pardevice Jan 6 03:24:57 faramir kernel: fuse exit Sorry for not providing that info earlier, but the first time I had this issue I had two print jobs after eachother and because of that I overlooked the double registering. I am printing through CUPS on a fairly standard Debian unstable system running the KDE desktop. -- 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: pnpacpi: exceeded the max number of IO resources: 24
(Adding the kernel list back. Any reason you did not send the reply there?) Sorry for the late reply: Christmas, New Year, the flue, etc. On Friday 28 December 2007, Zhao Yakui wrote: > On Mon, 2007-12-24 at 06:12 +0100, Frans Pop wrote: > > During boot with v2.6.24-rc6-125-g5356f66 on my Toshiba Satellite A40 > > laptop, I suddenly get the following message (repeated 22 times!): > >pnpacpi: exceeded the max number of IO resources: 24 > > > > Last time I tested 2.6.24 on that box was after the initial merge, but > > before -rc1. Then those lines were not present. > > > > Looks like the messages originate from a7839e96 by Zhao Yakui and that > > patch just adds the kernel messages so it was probably a hidden issue > > before, but I cannot determine if I should be worried or not. > > Thanks for caring this problem. And thank you for the reply, although I must admit that I'm still confused. > In the patch of a7839e96 the predefined PNP constant is changed. For > example: IO is changed from 8 to 24, Mem is changed from 4 to 12. > That means that more resources will be obtained from the PNP device > defined in ACPI table. So the system will print more message. OK. The change for Mem from 4 to 12 could explain the extra "iomem range" messages (although I don't quite understand why resources that "could not be reserved" still use a slot). I do not yet see how the "ioport range" messages increased from 0 to 16 is explained, but I'm not too worried about that. > At the same time another problem maybe happens. If the number of > resources defined in BIOS still exceeds the predefined PNP constant, it > will report that pnpacpi: exceeded the max number of IO resources: 24. > Although it can be fixed by changed the pnp constant bigger, it is > inappropriate because it will waste a lot of memory in most cases. > > Of course the above error message is harmless. Are the _errors_ really harmless? Your commit message was: "It brings that some resources can't be reserved and resource confilicts. This will cause PCI resources are assigned wrongly in some systems, and cause hang. This is a regression since we deleted ACPI motherboard driver and use PNP system driver." That text seems to indicate that not reserving the remaining resources _can_ cause real problems. Do we know what PCI resources are now not being correctly reserved on my laptop (and other machines)? The fact that the message is repeated 22 times seems to indicate that in my case quite a lot of resources are being ignored. Should the memory allocation maybe be made dynamic instead of static if the memory waste is really such a problem? Apparently the number of PCI resources can vary wildly from one machine to another. If the error messages really are harmless, shouldn't they be changed from ERR to DEBUG? As it is, the messages are extremely ugly and will probably cause a lot of people to file bug reports as it _looks_ like there is an error. Cheers, Frans Pop -- 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: pnpacpi: exceeded the max number of IO resources: 24
(Mail below was sent to me privately, forwarding to the lists.) On Mon, 2008-01-07 at 00:48 +0100, Frans Pop wrote: > (Adding the kernel list back. Any reason you did not send the reply > there?) > > Sorry for the late reply: Christmas, New Year, the flue, etc. > Thank you for caring this problem. > On Friday 28 December 2007, Zhao Yakui wrote: > > On Mon, 2007-12-24 at 06:12 +0100, Frans Pop wrote: > > > During boot with v2.6.24-rc6-125-g5356f66 on my Toshiba Satellite > > > A40 laptop, I suddenly get the following message (repeated 22 > > > times!): pnpacpi: exceeded the max number of IO resources: 24 > > > > > > Last time I tested 2.6.24 on that box was after the initial merge, > > > but before -rc1. Then those lines were not present. > > > > > > Looks like the messages originate from a7839e96 by Zhao Yakui and > > > that patch just adds the kernel messages so it was probably a > > > hidden issue before, but I cannot determine if I should be worried > > > or not. > > > > Thanks for caring this problem. > > And thank you for the reply, although I must admit that I'm still > confused. > > > In the patch of a7839e96 the predefined PNP constant is changed. For > > example: IO is changed from 8 to 24, Mem is changed from 4 to 12. > > That means that more resources will be obtained from the PNP device > > defined in ACPI table. So the system will print more message. > > OK. The change for Mem from 4 to 12 could explain the extra "iomem > range" messages (although I don't quite understand why resources that > "could not be reserved" still use a slot). The resources of PNP device are obtained by calling the _CRS method. Maybe some resources has been reserved. For example: Some system will reserve the following resources. BIOS-e820: fec0 - fed4 (reserved) BIOS-e820: fed45000 - 0001 (reserved) So the system will report that some resources can't be reserved. > I do not yet see how the "ioport range" messages increased from 0 to 16 > is explained, but I'm not too worried about that. > > > At the same time another problem maybe happens. If the number of > > resources defined in BIOS still exceeds the predefined PNP constant, > > it will report that pnpacpi: exceeded the max number of IO resources: > > 24. Although it can be fixed by changed the pnp constant bigger, it > > is inappropriate because it will waste a lot of memory in most cases. > > > > Of course the above error message is harmless. > > Are the _errors_ really harmless? The error message is harmless. It only tells us that the resource definition of PNP device exceeds the predefined PNP constant and maybe there will be potential problem if some important resources can't be reserved. For example about 90 IOPORT resources are defined in some PNP device. So it will print the message. Of course it is more appropriate to change the message level from ERR to DEBUG. > Your commit message was: > "It brings that some resources can't be reserved and resource > confilicts. This will cause PCI resources are assigned wrongly in some > systems, and cause hang. This is a regression since we deleted ACPI > motherboard driver and use PNP system driver." > > That text seems to indicate that not reserving the remaining resources > _can_ cause real problems. Do we know what PCI resources are now not > being correctly reserved on my laptop (and other machines)? The fact > that the message is repeated 22 times seems to indicate that in my case > quite a lot of resources are being ignored. > > Should the memory allocation maybe be made dynamic instead of static if > the memory waste is really such a problem? Apparently the number of PCI > resources can vary wildly from one machine to another. It is more appropriate to use dynamic memory allocation for Pnp device than to increase the PNP constant bigger. Now Thomas is working on it. Maybe he will submit the patch very soon. > If the error messages really are harmless, shouldn't they be changed > from ERR to DEBUG? As it is, the messages are extremely ugly and will > probably cause a lot of people to file bug reports as it _looks_ like > there is an error. -- 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: pnpacpi : exceeded the max number of IO resources
Len Brown wrote: >> > Well, yes, the warning is actually new as well. Previously your kernel >> > just silently ignored 8 more mem resources than it does now it seems. >> > >> > Given that people are hitting these limits, it might make sense to just >> > do away with the warning for 2.6.24 again while waiting for the dynamic >> > code? >> >> Ping. Should these warnings be reverted for 2.6.24? > > No. I don't think hiding this issue again is a good idea. > I'd rather live with people complaining about an addition dmesg line. We're not talking about "a" additional line. In my case [1] we're talking about 22 (!) additional identical lines. Not fixing this before 2.6.24 seems completely inconsistent: - either this is a real bug and the ERR level message is correct, in which case the limits should be increased; - or hitting the limits is harmless and the message should be changed to DEBUG level. It is great to hear that the memory allocation will become dynamic in the future and maybe that could just justify your standpoint, but having the messages is damn ugly and alarming from a user point of view. Please keep in mind that depending on distro release schedules, 2.6.24 could live for quite a bit longer than just the period needed to release 2.6.25 (if that is when the dynamic allocation will be implemented). Cheers, FJP [1] http://lkml.org/lkml/2008/1/6/279 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] libata fixes
Jeff Garzik wrote: > libata disabling command queueing (aka NCQ) based on some hueristics for > detection device brokenness that ultimately turned out to be broken. > > Remove the broken hueristic and turn NCQ back on for all the wrongfully > maligned hard drives. Yay! -- 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: menuconfig: fail with clearer error if curses.h N/A
On Sunday 09 December 2007, Sam Ravnborg wrote: > This is much better. Thanks! A few minor corrections maybe (nitpicks really). > *** Unable to find the ncurses libraries > *** or the required header files. That first line is strangely short like this. Move "or the" to the first line? > *** make menuconfig require the ncurses libraries At least s/require/requires/ and probably add a period at end of the line. I also suggest adding quotes around make menuconfig: *** 'make menuconfig' requires the ncurses libraries. > *** > *** Install ncurses (ncurses-devel) and try again Again add a period at end of the line. Cheers, FJP -- 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: /proc/cpuinfo reports erroneous CPU frequency. (2.6.23 & 2.6.22)
Alexander Rajula wrote: > While overclocking an AMD Athlon X2 (2GHz) CPU /proc/cpuinfo reports the > wrong CPU frequency. I am quite puzzled by this. > Is this an error in the kernel, or is there something strange going on? You may want to read some old threads on this list and check if that matches what you are seeing: http://lkml.org/lkml/2006/3/29/150 http://lkml.org/lkml/2006/10/26/182 Cheers, FJP -- 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: pnpacpi : exceeded the max number of IO resources
Dave Young wrote: > I noticed the port number changed to 40 in 2.6.24-rc8, but it's not > enough for me still. Same here, though the extreme noise has gone. >From /proc/ioports and dmesg it looks like I'm short by either 1, or 3 :-( Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 regression: reference count leak in PPPoE
Andi Kleen wrote: > My workstation running 2.6.24-rc8 just hung during shutdown with an > endless (or rather I didn't wait more than a few minutes) loop of > > unregister_netdev: waiting for ppp-device to become free. Usage count = 1 Same as http://lkml.org/lkml/2008/1/20/27? See also follow-up to that. Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] dm-band: The I/O bandwidth controller: Source code patch
Hi, I'm not qualified to comment on the code, but here are some suggestions on config option and comments. Cheers, FJP Ryo Tsuruta wrote: > +config DM_BAND > + tristate "I/O band width control " s/band width/bandwidth/ (it seems to be used correctly elsewhere, but you may want to double-check) > + depends on BLK_DEV_DM > + ---help--- > + Any processes or cgroups can use the same storage > + with its band-width fairly shared. s/band-width/bandwidth/ The help should probably be a bit more verbose as this does not tell anybody much who has not already read the documentation. Maybe something like: This device-mapper target allows to define how the available bandwith of a storage device should be shared between processes or cgroups. Information on how to use dm-band is available in: Documentation/device-mapper/band.txt > + * The following functiotons determine when and which BIOs should ^^^ > + * be submitted to control the I/O flow. > + * It is possible to add a new I/O scheduling policy with it. > + * > + * g_can_submit : To determine whether a given group has a right to s/a right/the right/ > + * submit BIOs. > + * The larger return value the higher priority to submit. > + * Zero means it has no right. "The larger the return value, the higher the priority [...]" > + * g_prepare_bio : Called right before submitting each BIO. > + * g_restart_bios : Called when there exist some BIOs blocked but none of > them > + * can't be submitted now. s/when there exist some BIOs blocked/if some BIOs exist that are blocked/ ? "none of them can't" : the double negative looks incorrect (and should be avoided anyway) > + * This method have to do something to restart to submit BIOs. s/have/has/ "has to do something" : that's rather vague... -- 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/
top displaying 9999% CPU usage
I saw top occasionally displaying % CPU usage for a process. The first few times it was amarokapp, this last time it was kontact. Both applications were basically idle. The "cc1" is a kernel compile (rc9 + CFS :-). I cannot remember seeing this before, but as I also don't run top that frequently I cannot be sure its a recent regression. $ uname -a Linux faramir 2.6.23-rc9 #1 SMP Tue Oct 2 11:16:15 CEST 2007 x86_64 GNU/Linux top - 14:28:27 up 38 min, 1 user, load average: 1.12, 0.67, 0.32 Tasks: 128 total, 2 running, 126 sleeping, 0 stopped, 0 zombie Cpu(s): 32.0%us, 15.7%sy, 0.0%ni, 43.8%id, 8.5%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2054476k total, 998460k used, 1056016k free,95284k buffers Swap: 979924k total,0k used, 979924k free, 485804k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 5269 fjp 20 0 441m 58m 32m S 2.9 0:16.34 kontact 8272 fjp 20 0 5952 468 208 S3 0.0 0:04.62 faked-sysv 3666 fjp 20 0 25268 2036 884 S2 0.1 0:03.30 famd 26530 fjp 20 0 20932 6292 1568 R2 0.3 0:00.06 cc1 5124 fjp 20 0 210m 26m 19m S1 1.3 0:09.18 kicker 17012 fjp 20 0 19016 1252 916 R1 0.1 0:00.34 top 5159 fjp 20 0 508m 54m 30m S0 2.7 0:12.67 amarokapp - 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: top displaying 9999% CPU usage
On Wednesday 03 October 2007, you wrote:
> Try to capture the i/o log with the following command:
> strace -o top.log top
Thanks for the suggestion.
> This will show for sure whether the kernel gives out incorrect data or
> top misinterprets them.
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
5269 fjp 20 0 442m 61m 33m S 3.1 0:34.12 kontact
Here are the last two reads for PID 5269 from /proc before that:
15:48:51 stat("/proc/5269", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
15:48:51 open("/proc/5269/stat", O_RDONLY) = 10
15:48:51 read(10, "5269 (kontact) S 1 5100 5100 0 -1 4202560 58186 7891 290 1
2911 502 10 15 20 0 6 0 9225 464408576 15694 18446744073709551615 4194304
4365900 140733817144688 18446744073709551615 47998530367074 0 0 4098 83113
18446744073709551615 0 0 17 1 0 0 0\n", 1023) = 244
15:48:51 open("/proc/5269/statm", O_RDONLY) = 10
15:48:54 stat("/proc/5269", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
15:48:54 open("/proc/5269/stat", O_RDONLY) = 10
15:48:54 read(10, "5269 (kontact) S 1 5100 5100 0 -1 4202560 58186 7891 290 1
2912 500 10 15 20 0 6 0 9225 464408576 15694 18446744073709551615 4194304
4365900 140733817144688 18446744073709551615 47998530367074 0 0 4098 83113
18446744073709551615 0 0 17 1 0 0 0\n", 1023) = 244
15:48:54 open("/proc/5269/statm", O_RDONLY) = 10
The only change is in 2 consecutive columns: "2911 502" -> "2912 500".
Is processor usage calculated from those? Can someone explain how?
In reply to Jan Engelhardt:
If I run the endless loop, top just displays 100%.
I've not seen the in htop, only occasionally "100." for both.
This is on an x86_64 SMP box.
-
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/
Decreasing stime running confuses top (was: top displaying 9999% CPU usage)
On Wednesday 03 October 2007, you wrote:
> On Wed, 3 Oct 2007, Ilpo Järvinen wrote:
> > On Wed, 3 Oct 2007, Frans Pop wrote:
> > > The only change is in 2 consecutive columns: "2911 502" -> "2912
> > > 500". Is processor usage calculated from those? Can someone explain
> > > how?
> >
> > The latter seems to be utime ...decreasing. No wonder if arithmetics
> > will give strange results (probably top is using unsigned delta?)...
>
> Hmm, minor miscounting from my side, stime seems more appropriate...
Here is a series showing utime and stime for kontact over 2 minutes.
Values were obtained using (identical values removed):
$ while true; do awk '{print $14" "$15}' /proc/5269/stat; sleep 1; done | ts
Oct 03 21:17:12 12220 1593
Oct 03 21:17:18 12221 1594
Oct 03 21:17:26 1 1593 <--
Oct 03 21:17:34 12223 1594
Oct 03 21:17:43 12224 1594
Oct 03 21:17:51 12224 1595
Oct 03 21:17:59 12225 1596
Oct 03 21:18:07 12226 1595 <--
Oct 03 21:18:15 12227 1596
Oct 03 21:18:18 12228 1596
Oct 03 21:18:22 12229 1595 <--
Oct 03 21:18:31 12230 1596
Oct 03 21:18:39 12230 1597
Oct 03 21:18:44 12231 1597
Oct 03 21:18:48 12232 1596 <--
Oct 03 21:18:56 12233 1597
Oct 03 21:19:04 12234 1596 <--
Oct 03 21:19:11 12235 1597
So, is it normal that stime decreases sometimes or a kernel bug?
/me expects the last...
-
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: Decreasing stime running confuses top (was: top displaying 9999% CPU usage)
On Wednesday 03 October 2007, you wrote: > On Wed, Oct 03, 2007 at 09:27:41PM +0200, Frans Pop wrote: > > On Wednesday 03 October 2007, you wrote: > > > On Wed, 3 Oct 2007, Ilpo Järvinen wrote: > > > > On Wed, 3 Oct 2007, Frans Pop wrote: > > > > > The only change is in 2 consecutive columns: "2911 502" -> "2912 > > > > > 500". Is processor usage calculated from those? Can someone > > > > > explain how? > > > > > > > > The latter seems to be utime ...decreasing. No wonder if > > > > arithmetics will give strange results (probably top is using > > > > unsigned delta?)... > > > > > > Hmm, minor miscounting from my side, stime seems more appropriate... > > > > So, is it normal that stime decreases sometimes or a kernel bug? > > /me expects the last... > > Let me guess... Dual core AMD64 ? Nope: Intel(R) Pentium(R) D CPU 3.20GHz > I'm 99.99% sure that if you boot with "notsc", the problem disappears. Not really. With that first test I did have: $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc If I boot with 'notsc', I get: cat /sys/devices/system/clocksource/clocksource0/current_clocksource hpet But the problem is still exactly the same: Oct 04 00:53:37 545 92 Oct 04 00:53:38 545 94 Oct 04 00:53:43 546 92 <-- Oct 04 00:53:49 547 94 Oct 04 00:53:54 549 93 <-- Oct 04 00:54:00 550 94 Some relevant lines from kernel log: checking TSC synchronization [CPU#0 -> CPU#1]: passed <--- Not there with 'notsc' hpet0: at MMIO 0xfed0, IRQs 2, 8, 0 hpet0: 3 64-bit timers, 14318180 Hz ACPI: RTC can wake from S4 Time: hpet clocksource has been installed. hpet_resources: 0xfed0 is busy Time: tsc clocksource has been installed. <--- Not there with 'notsc' > If so, you have one of those wonderful AMD64 with unsynced clock and > without HPET to sync with. I wrote a simple program in the past to exhibit > the problem. It would bsimply run "date +%s" in a busy loops and display > each time it would change. Amazing. It could jump back and forth by up to > 3 seconds! I tried your script, but the clock runs perfectly. Never saw anything other than a 1 second increment. The following may well be relevant. With 2.6.22 and early 2.6.23-rc kernels (rc3-rc6) I often had this in my kernel log (see http://lkml.org/lkml/2007/9/16/45): checking TSC synchronization [CPU#0 -> CPU#1]: Measured 248 cycles TSC warp between CPUs, turning off TSC clock. Marking TSC unstable due to check_tsc_sync_source failed Some boots the TSC synchronization would be OK, but I'd see ~2/3 failures. Kernels before 2.6.22 did not have this problem. However, checking my logs now I see that these messages have disappeared since 2.6.23-rc7. Now the TSC synchronization check always passes. I also tried with 2.6.22-6 and with that the jumping around is _not_ present. This was a boot where TSC synchronization failed, so with hpet as clocksource. Also, the numbers stay constant much longer and have bigger increments (updates look to be once per minute?): Oct 04 01:24:19 465 67 Oct 04 01:24:50 467 69 Oct 04 01:24:51 469 72 Oct 04 01:25:51 474 76 Oct 04 01:26:50 478 80 Cheers, Frans Pop - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for testing] Re: Decreasing stime running confuses top
On Friday 05 October 2007, Chuck Ebbert wrote: > procfs: Don't read runtime twice when computing task's stime > > Current code reads p->se.sum_exec_runtime twice and goes through > multiple type conversions to calculate stime. Read it once and > skip some of the conversions. > > Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]> This second patch is a major improvement. But both for kontact and amarok I still see stime decreasing occasionally. Sometimes even still quite frequently like in this series: Oct 05 17:00:42 698 178 Oct 05 17:00:43 700 177 Oct 05 17:00:44 700 177 Oct 05 17:00:45 700 177 Oct 05 17:00:46 700 178 Oct 05 17:00:47 700 178 Oct 05 17:00:48 700 177 Oct 05 17:00:49 700 177 Oct 05 17:00:50 700 178 Oct 05 17:00:51 700 178 Oct 05 17:00:52 700 179 Oct 05 17:00:53 698 180 Oct 05 17:00:54 700 179 Oct 05 17:00:55 700 179 Oct 05 17:00:56 700 179 Oct 05 17:00:57 700 179 Oct 05 17:00:58 700 180 Oct 05 17:00:59 700 179 This was after 6 minutes of steady increases. Should we try a debug patch that shows the raw data behind the calculations? I'll give the first patch a try next. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for testing] Re: Decreasing stime running confuses top
On Thursday 04 October 2007, you wrote: > Frans can you test this patch if this makes stime and utime monotic > again? > > It basically reverts the rest of > b27f03d4bdc145a09fb7b0c0e004b29f1ee555fa and should restore the 2.6.22 > behavior. The process time is used from tasks utime and stime instead of > the scheduler clock. That means, in general after a long period of time, > it is less accurate than the current time and behaves like 2.6.22. > > Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]> Yes, this gives steady increases. For kontact it also again shows updates only once every minute. I really wonder where all the other fluctuations for contact come from with the alternative code. It seems to me that this patch would be the best option for 2.6.23. Tested-by: Frans Pop <[EMAIL PROTECTED]> - 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: Trailing periods in kernel messages
On Thursday 20 December 2007, Alan Cox wrote: > The kernel printk messages are sentences. I'm afraid that I completely and utterly disagree. Kernel messages are _not_ sentences. The vast majority is not well-formed and does not contain any of the elements that are required for a proper sentence. The most kernel messages can be compared to is a rather diverse and sloppy enumeration. And enumerations follow completely different rules than sentences. It can better be characterized as a "semi-random sequence of context-sensitive technical messages". IMHO the existing rule that "Kernel messages do not have to be terminated with a period." is completely justified, though it does need some minor clarification on the cases in which proper punctuation _should_ be followed. -- 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: [s390] networking related oops during boot on Hercules (was: build failure)
On Wednesday 28 November 2007, Christian Borntraeger wrote: > This seems to be related to the new network namespace code by Eric > Biederman (CCed). Can you try the following (untested) patch? I also > CCed Ursula and Peter as they know the ctc code better than me. Yes, that fixes it. Boots fine now and I can ssh into the system. Not tested any further than that. Thanks Christian. > CC: Eric W. Biederman <[EMAIL PROTECTED]> > CC: Ursula Braun <[EMAIL PROTECTED]> > CC: Peter Tiedemann <[EMAIL PROTECTED]> > Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]> > > --- > drivers/s390/net/ctcmain.c |2 ++ > 1 file changed, 2 insertions(+) > > Index: linux-2.6/drivers/s390/net/ctcmain.c > === > --- linux-2.6.orig/drivers/s390/net/ctcmain.c > +++ linux-2.6/drivers/s390/net/ctcmain.c > @@ -56,6 +56,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -2823,6 +2824,7 @@ ctc_init_netdevice(struct net_device * d > dev->type = ARPHRD_SLIP; > dev->tx_queue_len = 100; > dev->flags = IFF_POINTOPOINT | IFF_NOARP; > + dev->nd_net = &init_net; > return dev; > } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] Writeback fix for concurrent large and small file writes
Two typos in comments. Cheers, FJP Michael Rubin wrote: > + * The flush tree organizes the dirtied_when keys with the rb_tree. Any > + * inodes with a duplicate dirtied_when value are link listed together. > This + * link list is sorted by the inode's i_flushed_when. When both the > + * dirited_when and the i_flushed_when are indentical the order in the > + * linked list determines the order we flush the inodes. s/dirited_when/dirtied_when/ > + * Here is where we interate to find the next inode to process. The > + * strategy is to first look for any other inodes with the same > dirtied_when + * value. If we have already processed that node then we > need to find + * the next highest dirtied_when value in the tree. s/interate/iterate/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] tick: add a missing dot in prink
Li Zefan wrote:
> Add a missing '.' in prink information.
> - printk(" no tick device\n");
> + printk(" no tick device.\n");
I wonder if that is correct. CodingStyle says:
Chapter 13: Printing kernel messages
[...]
Kernel messages do not have to be terminated with a period.
I personally think that rule could be made a bit stricter as for example
dmesg output currently looks fairly inconsistent with some messages
terminated with a period while most messages are not and have been wondering
if I should file patches to _remove_ periods.
Maybe the rule should be changed to:
Kernel messages should not be terminated with a period, unless a single
message contains multiple sentences.
?
Cheers,
FJP
-
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/
Trailing periods in kernel messages (was: [PATCH 6/6] tick: add a missing dot in prink)
On Thursday 29 November 2007, Li Zefan wrote:
> Frans Pop wrote:
> > Li Zefan wrote:
> >> Add a missing '.' in prink information.
> >> - printk(" no tick device\n");
> >> + printk(" no tick device.\n");
> >
> > I wonder if that is correct. CodingStyle says:
> > Chapter 13: Printing kernel messages
> >[...]
> >Kernel messages do not have to be terminated with a period.
> >
> > I personally think that rule could be made a bit stricter as for
> > example dmesg output currently looks fairly inconsistent with some
> > messages terminated with a period while most messages are not and have
> > been wondering if I should file patches to _remove_ periods.
> >
> > Maybe the rule should be changed to:
> >Kernel messages should not be terminated with a period, unless a
> >single message contains multiple sentences.
> > ?
>
> But why a kernel message should not be terminated with a period?
Exactly because kernel messages are in general _not_ sentences.
IMO trailing periods
> It does no harm at all.
Well, for one it needlessly increases the size of log files.
It also IMO just looks weird to have a trailing period only for some
messages and it certainly is completely inappropriate for messages like:
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
[...]
ACPI: RSDP 000FE020, 0014 (r0 INTEL )
ACPI: RSDT 7F6FDE48, 0058 (r1 INTEL D945GCZ FF9 MSFT 113)
If I look at my current dmesg output, *only* 16 out of 543 line have a
trailing period, and in almost all cases they just looks out of place. See
some examples at the bottom of this mail.
> And if the message is a complete sentence, it's grammatical correct to
> terminated with a period.
Exactly why I make an exception for those in my proposal.
> I think CodingStyle just says an ending period is not mandatory. It does
> not discourage the ending period.
I feel that to improve consistency the CodingStyle should be clear about
when a period should and should not be used.
Some examples of IMO unneeded/inconsistent use of trailing periods:
Entering add_active_range(0, 521983, 521984) 3 entries of 3200 used
end_pfn_map = 521984
DMI 2.3 present.
ACPI: RSDP 000FE020, 0014 (r0 INTEL )
[...]
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x8086a201 base: 0xfed0
[...]
hpet clockevent registered
TSC calibrated against HPET
time.c: Detected 3199.880 MHz processor.
Console: colour dummy device 80x25
[...]
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 *9 10 11 12)
[...]
pnp: the driver 'i8042 kbd' has been unregistered
pnp: the driver 'i8042 aux' has been unregistered
PNP: No PS/2 controller found. Probing ports directly.
[...]
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a
report
PCI-GART: No AMD northbridge found.
The last example shows the inconsistency very well. And in this case the
second line could easily be "reduced" to a regular message by using a
semicolon instead of a period between the "sentences".
This is already being done in a number of other messages, for example:
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
So I'd suggest to change those last three lines to (including some textual
improvements):
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq"; if that helps, please
post a report
PCI-GART: No AMD northbridge found
-
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: constant_tsc and TSC unstable
Paul Rolland wrote: > Total of 2 processors activated (6919.15 BogoMIPS). > ENABLING IO-APIC IRQs > ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 > checking TSC synchronization [CPU#0 -> CPU#1]: > Measured 3978592228 cycles TSC warp between CPUs, turning off TSC clock. > Marking TSC unstable due to: check_tsc_sync_source failed. > Brought up 2 CPUs > ... Not sure if this is related, but thought I'd contribute it anyway... I've got a Pentium D system (dual core, single processor) and I on some boots I get "Marking TSC unstable due to check_tsc_sync_source failed" with some cycles warp between CPUs, while most boots are OK. This kind of inconsistency seems more due to a failure in the kernel to deal with differences between boots than with something inherent to the hardware. I conclude that because basically I never have any problems with the system once it has booted and the TSC has passed. >From my kern.logs since Okt 26, I get the following data: 2.6.23+cfs: 2 passes 2.6.23.1:1 pass; 1 failure (48 cycles warp) 2.6.24-rc1: 15 passes 2.6.24-rc2: 13 passes; 1 failure (8 cycles warp) 2.6.24-rc3: 5 passes; 3 failures (8, 8 and 16 cycles warp) Note that this is not a new issue. For 2.6.21/2.6.23-RCx kernels I reported similar data in http://lkml.org/lkml/2007/9/16/45. Cheers, FJP - 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: [s390] build failure
Martin Schwidefsky wrote: > On Wed, 2007-11-28 at 11:27 +0100, Frans Pop wrote: >> arch/s390/kernel/built-in.o: In function `cleanup_io_leave_insn': >> diag.c:(.text+0xc29a): undefined reference to `preempt_schedule_irq' >> make[2]: *** [.tmp_vmlinux1] Error 1 > > This is fixes by a patch from Christian: > [S390] Fix compile error on 31bit without preemption > > You can get the latest s390 patches by pulling from > git://git390.osdl.marist.edu/pub/scm/linux-2.6.git fixes Any reason this has not been pushed into mainline yet? The fix missed -rc4 because of that... Cheers, FJP -- 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] jiffies counter leaps in 2.6.24-rc3
Stefano Brivio wrote: > It looks like the jiffies counter sometimes jumps back and forth of some > hundreds seconds in 2.6.24-rc3. I observed that this happens when I use > the su(1) command, e.g.: Can you please explain what exactly the problem is here? Are you perhaps referring to the number between square brackets for the su log lines? In that case there is no problem as in that case the number is not jiffies, but the process ID (PID) of the su process... Cheers, FJP - 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: "buggy cmd640" message followed by soft lockup
(Dropped Rafael from CC) On Sunday 25 November 2007, Bartlomiej Zolnierkiewicz wrote: > So either something went very very wrong or the oops itself is incorrect. > > Please put BUG() before the put_cmd640_reg() above so the next time > BUG happens we will know which one is it. I've spent quite a bit of time on this issue over the weekend and have seen all kinds of "interesting" behavior with various kernels with different debug patches, but no definite clues (except confirmation that on "good" boots no cmd64x hardware is detected). At some point I scrapped the virtual machine I had been using and created a new one. Since then I've been unable to reproduce the problem. I'm still quite confused by the issue exactly because it was so consistent when it _did_ happen and am still not sure if it can be blamed completely on the quirkiness of Virtualbox. I'll keep testing new kernels in VirtualBox and will keep alert for the issue, but for now I think it's best to forget about it. Bartlomiej: thanks for your feedback and suggestions. Cheers, FJP - 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/
[parisc] 2.6.24-rc3 (64-bit, smp) fails to boot on 9000/785/J5600
v2.6.24-rc3-19-g2ffbb83 fails very early in the boot procedure. 2.6.23 compiled with similar config boots fine. System is running Debian unstable; kernel was compiled using gcc 4.1.2. Cheers, Frans Pop Boot messages for 2.6.24 Command line for kernel: 'root=/dev/sda5 HOME=/ console=ttyS0 TERM=vt102 palo_kernel=' Selected kernel: /vmlinuz-2.6.24-rc3 from partition 2 Selected ramdisk: /initrd.img-2.6.24-rc3 from partition 2 ELF64 executable Entry 0010 first 0010 n 2 Segment 0 load 0010 size 4648960 mediaptr 0x1000 Segment 1 load 005c4000 size 689216 mediaptr 0x47 Loading ramdisk 3078237 bytes @ 3fcff000... Branching to kernel entry point 0x0010. If this is the last message you see, you may need to switch your console. This is a common symptom -- search the FAQ and mailing list at parisc-linux.org Linux version 2.6.24-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.3 20071019 (prerelease) (D7 FP[0] enabled: Rev 1 Model 16 The 64-bit Kernel has started... console [ttyB0] enabled Initialized PDC Console for debugging. Determining PDC firmware type: System Map. model 5d10 0491 0002 778fe5fc 10f0 0008 00b2 00b2 vers 0300 CPUID vers 17 rev 10 (0x022a) capabilities 0x3 model 9000/785/J5600 Total Memory: 2048 MB initrd: 7fcff000-7ffee85d initrd: reserving 3fcff000-3ffee85d (mem_max 8000) LCD display at fff0f05d0008,fff0f05d registered SMP: bootstrap CPU ID is 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 517120 Kernel command line: root=/dev/sda5 HOME=/ console=ttyS0 TERM=vt102 palo_kernel=2/vml3 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour dummy device 160x64 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Memory: 2051840k/2097152k available (3103k kernel code, 44736k reserved, 1388k data, ) virtual kernel memory layout: vmalloc : 0x8000 - 0x3f00 (1007 MB) memory : 0x4000 - 0xc000 (2048 MB) .init : 0x40624000 - 0x4066d000 ( 292 kB) .data : 0x40407fb0 - 0x40563000 (1388 kB) .text : 0x4010 - 0x40407fb0 (3103 kB) Diff between 2.6.23 and 2.6.24 config - $ diff -u /boot/config-2.6.23 /boot/config-2.6.24-rc3 | grep "^[+-][^#]" --- /boot/config-2.6.23 2007-11-27 08:01:51.0 + +++ /boot/config-2.6.24-rc3 2007-11-27 08:50:10.0 + +CONFIG_FAIR_GROUP_SCHED=y +CONFIG_FAIR_USER_SCHED=y +CONFIG_BLOCK_COMPAT=y +CONFIG_PCI_LEGACY=y +CONFIG_INET_LRO=m +CONFIG_NETFILTER_XT_MATCH_TIME=m +CONFIG_NET_ACT_NAT=m +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_IDE_ARCH_OBSOLETE_INIT=y +CONFIG_SCSI_SRP_ATTRS=m +CONFIG_FIXED_MII_AMNT=1 +CONFIG_SSB_POSSIBLE=y +CONFIG_SSB=m +CONFIG_SSB_PCIHOST_POSSIBLE=y +CONFIG_SSB_PCIHOST=y +CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y +CONFIG_SSB_DRIVER_PCICORE=y +CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0 +CONFIG_PRINT_QUOTA_WARNING=y -CONFIG_RAMFS=y +CONFIG_NETWORK_FILESYSTEMS=y +CONFIG_INSTRUMENTATION=y +CONFIG_ENABLE_WARN_DEPRECATED=y Full 2.6.24 config -- # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc3 # Mon Nov 26 18:45:54 2007 # CONFIG_PARISC=y CONFIG_MMU=y CONFIG_STACK_GROWSUP=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME=y CONFIG_TIME_LOW_RES=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_IRQ_PER_CPU=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_AUDIT=y CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CO
[parisc] 2.6.24-rc3 (64-bit, smp) fails to boot on 9000/785/J5600
(resending as address for port list was incorrect) v2.6.24-rc3-19-g2ffbb83 fails very early in the boot procedure. 2.6.23 compiled with similar config boots fine. System is running Debian unstable; kernel was compiled using gcc 4.1.2. Cheers, Frans Pop Boot messages for 2.6.24 Command line for kernel: 'root=/dev/sda5 HOME=/ console=ttyS0 TERM=vt102 palo_kernel=' Selected kernel: /vmlinuz-2.6.24-rc3 from partition 2 Selected ramdisk: /initrd.img-2.6.24-rc3 from partition 2 ELF64 executable Entry 0010 first 0010 n 2 Segment 0 load 0010 size 4648960 mediaptr 0x1000 Segment 1 load 005c4000 size 689216 mediaptr 0x47 Loading ramdisk 3078237 bytes @ 3fcff000... Branching to kernel entry point 0x0010. If this is the last message you see, you may need to switch your console. This is a common symptom -- search the FAQ and mailing list at parisc-linux.org Linux version 2.6.24-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.3 20071019 (prerelease) (D7 FP[0] enabled: Rev 1 Model 16 The 64-bit Kernel has started... console [ttyB0] enabled Initialized PDC Console for debugging. Determining PDC firmware type: System Map. model 5d10 0491 0002 778fe5fc 10f0 0008 00b2 00b2 vers 0300 CPUID vers 17 rev 10 (0x022a) capabilities 0x3 model 9000/785/J5600 Total Memory: 2048 MB initrd: 7fcff000-7ffee85d initrd: reserving 3fcff000-3ffee85d (mem_max 8000) LCD display at fff0f05d0008,fff0f05d registered SMP: bootstrap CPU ID is 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 517120 Kernel command line: root=/dev/sda5 HOME=/ console=ttyS0 TERM=vt102 palo_kernel=2/vml3 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour dummy device 160x64 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Memory: 2051840k/2097152k available (3103k kernel code, 44736k reserved, 1388k data, ) virtual kernel memory layout: vmalloc : 0x8000 - 0x3f00 (1007 MB) memory : 0x4000 - 0xc000 (2048 MB) .init : 0x40624000 - 0x4066d000 ( 292 kB) .data : 0x40407fb0 - 0x40563000 (1388 kB) .text : 0x4010 - 0x40407fb0 (3103 kB) Diff between 2.6.23 and 2.6.24 config - $ diff -u /boot/config-2.6.23 /boot/config-2.6.24-rc3 | grep "^[+-][^#]" --- /boot/config-2.6.23 2007-11-27 08:01:51.0 + +++ /boot/config-2.6.24-rc3 2007-11-27 08:50:10.0 + +CONFIG_FAIR_GROUP_SCHED=y +CONFIG_FAIR_USER_SCHED=y +CONFIG_BLOCK_COMPAT=y +CONFIG_PCI_LEGACY=y +CONFIG_INET_LRO=m +CONFIG_NETFILTER_XT_MATCH_TIME=m +CONFIG_NET_ACT_NAT=m +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_IDE_ARCH_OBSOLETE_INIT=y +CONFIG_SCSI_SRP_ATTRS=m +CONFIG_FIXED_MII_AMNT=1 +CONFIG_SSB_POSSIBLE=y +CONFIG_SSB=m +CONFIG_SSB_PCIHOST_POSSIBLE=y +CONFIG_SSB_PCIHOST=y +CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y +CONFIG_SSB_DRIVER_PCICORE=y +CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0 +CONFIG_PRINT_QUOTA_WARNING=y -CONFIG_RAMFS=y +CONFIG_NETWORK_FILESYSTEMS=y +CONFIG_INSTRUMENTATION=y +CONFIG_ENABLE_WARN_DEPRECATED=y Full 2.6.24 config -- # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc3 # Mon Nov 26 18:45:54 2007 # CONFIG_PARISC=y CONFIG_MMU=y CONFIG_STACK_GROWSUP=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME=y CONFIG_TIME_LOW_RES=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_IRQ_PER_CPU=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_AUDIT=y CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_
Re: [RFC] New kobject/kset/ktype documentation and example code
Greg KH wrote: > Based on an original article by Jon Corbet for lwn.net written October 1, > 2003 and located at http://lwn.net/Articles/51437/ > > Last updated November 27, 2008 ^^^ Wow, that's impressive: both kobjects de-mystified and time travel made possible! ;-) - 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/
[s390] build failure
$ git describe v2.6.24-rc3-342-g8c27eba arch/s390/kernel/built-in.o: In function `cleanup_io_leave_insn': diag.c:(.text+0xc29a): undefined reference to `preempt_schedule_irq' make[2]: *** [.tmp_vmlinux1] Error 1 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc3 # Tue Nov 27 22:13:47 2007 # CONFIG_MMU=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_BUG=y CONFIG_NO_IOMEM=y CONFIG_NO_DMA=y CONFIG_S390=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_LSF=y # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Base setup # # # Processor type and features # # CONFIG_64BIT is not set CONFIG_32BIT=y CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_HOTPLUG_CPU=y CONFIG_MATHEMU=y CONFIG_AUDIT_ARCH=y # CONFIG_S390_SWITCH_AMODE is not set # CONFIG_S390_EXEC_PROTECT is not set # # Code generation options # CONFIG_MARCH_G5=y # CONFIG_MARCH_Z900 is not set # CONFIG_MARCH_Z990 is not set # CONFIG_MARCH_Z9_109 is not set # CONFIG_PACK_STACK is not set # CONFIG_CHECK_STACK is not set # CONFIG_WARN_STACK is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # # Kernel preemption # CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_PREEMPT_BKL is not set CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set # CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=0 CONFIG_VIRT_TO_BUS=y CONFIG_HOLES_IN_ZONE=y # # I/O subsystem configuration # CONFIG_MACHCHK_WARNING=y CONFIG_QDIO=y # CONFIG_QDIO_DEBUG is not set # # Misc # CONFIG_IPL=y # CONFIG_IPL_TAPE is not set CONFIG_IPL_VM=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # CONFIG_PROCESS_DEBUG is not set CONFIG_PFAULT=y # CONFIG_SHARED_KERNEL is not set CONFIG_CMM=y CONFIG_CMM_PROC=y CONFIG_VIRT_TIMER=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_APPLDATA_BASE=y CONFIG_APPLDATA_MEM=m CONFIG_APPLDATA_OS=m CONFIG_APPLDATA_NET_SUM=m # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_NO_IDLE_HZ=y CONFIG_NO_IDLE_HZ_INIT=y CONFIG_S390_HYPFS_FS=y CONFIG_KEXEC=y # CONFIG_ZFCPDUMP is not set # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=m # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set CONFIG_NET_KEY=m # CONFIG_NET_KEY_MIGRATE is not set CONFIG_IUCV=m # CONFIG_AFIUCV is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_XFRM_TUNNEL=m
Re: [s390] build failure
On Wednesday 28 November 2007, Christian Borntraeger wrote: > We have a patch for that in our repository. > Martin will send that fix with the next bunch of fixes. Thx. - 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/
[s390] networking related oops during boot on Hercules (was: build failure)
On Wednesday 28 November 2007, Christian Borntraeger wrote:
> > arch/s390/kernel/built-in.o: In function `cleanup_io_leave_insn':
> > diag.c:(.text+0xc29a): undefined reference to `preempt_schedule_irq'
> > make[2]: *** [.tmp_vmlinux1] Error 1
>
> We have a patch for that in our repository.
That fixed it. Next issue ;-)
During boot I get the following oops in the Hercules emulator.
2.6.22 runs fine on Hercules; I've not tried .23 on it.
[...]
Synthesizing the initial hotplug events...
done.
Waiting for /dev to be fully populated...
dasd(eckd): 0.0.0121: 3390/02(CU:3990/01) Cyl:1113 Head:15 Sec:224
dasd(eckd): 0.0.0121: (4kB blks): 801360kB at 48kB/trk compatible disk layout
dasdb:VOL1/ 0X0121: dasdb1 dasdb2
TAPE_CHAR: tape gets major 254 for character devices
TAPE_BLOCK: tape gets major 253 for block device
TAPE_CORE: tape device 0.0.0581 found
HHCCP014I CPU0001: Operation exception CODE=0001 ILC=2
CPU0001: PSW=070C 8019D0DA INST=0001 ? , ?
CPU0001: GR00=00132700 GR01= GR02=0F398800 GR03=0F398800
CPU0001: GR04= GR05=80132796 GR06=0F305D7A GR07=0002
CPU0001: GR08=0F1ADA00 GR09=0F3C1F08 GR10=0F3C1F00 GR11=0F398800
CPU0001: GR12=0F398800 GR13=8019D0C2 GR14=0F305CA0 GR15=0F305C30
CPU0001: CR00=14B54E12 CR01=0031907F CR02=00011180 CR03=
CPU0001: CR04=03DE CR05=00011180 CR06=1000 CR07=8FB301FF
CPU0001: CR08= CR09= CR10= CR11=
CPU0001: CR12= CR13=8FB301FF CR14=FB00 CR15=
CTC driver initialized
cut here !
kernel BUG at net/core/dev.c:852
+
illegal operation: 0001 #1!
Modules linked in: ctc fsm tape_34xx cu3088 tape ccwgroup tape_class dm_mirror d
m_snapshot dm_mod dasd_eckd_mod dasd_mod
CPU:1Not tainted
Process hwup (pid: 990, task: 0f034c00, ksp: 0f305be0)
Krnl PSW : 070c 8019d0da (dev_alloc_name+0x1e/0x58)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:0 PM:0
Krnl GPRS: 00132700 0f398800 0f398800
80132796 0f305d7a 0002
0f1ada00 0f3c1f08 0f3c1f00 0f398800
0f398800 8019d0c2 0f305ca0 0f305c30
Krnl Code: 8019d0cc: f000bf1f2460 srp 3871(1,%r11),1120(%r2),0
8019d0d2: a7740004 brc 7,8019d0da
8019d0d6: a7f40001 brc 15,8019d0d8
>8019d0da: 5810d04e l %r1,78(%r13)
8019d0de: 41a0f060 la %r10,96(%r15)
8019d0e2: 5820c460 l %r2,1120(%r12)
8019d0e6: 184a lr %r4,%r10
8019d0e8: 0de1 basr%r14,%r1
Call Trace:
( <>! _ehead+0xfffee000/0x80)
<0019d710>! register_netdev+0x34/0x6c
<108a561e>! ctc_new_device+0x3ee/0x590 ctc!
<10861398>! ccwgroup_online_store+0xb0/0x13c ccwgroup!
<000c962a>! sysfs_write_file+0xca/0x130
<000840e6>! vfs_write+0x92/0x128
+
<000847e8>! sys_write+0x40/0x70
<0002098a>! sysc_do_restart+0x12/0x16
<77f0abaa>! 0x77f0abaa
udevd-event 949!: run_program: '/sbin/hwup' abnormal exit
done.
[...]
Setting up networking...
.
Configuring network interfaces...
-
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: > 100% CPU usage
James Kosin wrote: > Anyone remember the patch / patches done for the 2.6 series that related > to top reporting > 100% CPU usage? Do you mean these perhaps? - 73a2bcb0edb9ffb0b007b3546b430e2c6e415eee - 9301899be75b464ef097f0b5af7af6d9bd8f68a7 Cheers, FJP -- 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/
[REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
After compiling v2.6.24-rc7-163-g1a1b285 (x86_64) yesterday I suddenly see this error repeatedly: kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang kernel: Tx Queue <0> kernel: TDH kernel: TDT kernel: next_to_use kernel: next_to_clean kernel: buffer_info[next_to_clean] kernel: time_stamp <10002738a> kernel: next_to_watch kernel: jiffies <1000275b4> kernel: next_to_watch.status <1> My previous kernel was v2.6.24-rc7 and with that this error did not occur. I have also never seen it with earlier kernels. The values for "TX Queue" and "next_to_watch.status" are constant, the others vary. My NIC is: 01:00.0 Ethernet controller [0200]: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) 01:00.0 0200: 8086:108c (rev 03) Subsystem: 8086:3096 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
Wow. That's fast! :-) On Tuesday 15 January 2008, David Miller wrote: > From: Frans Pop <[EMAIL PROTECTED]> > > > kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang > > Does this make the problem go away? I'm compiling a kernel with the patch now. Will let you know the result. May take a while as I don't know how to trigger the bug, so I'll just have to let it run for some time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
On Tuesday 15 January 2008, David Miller wrote: > From: Frans Pop <[EMAIL PROTECTED]> > > kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang > > Does this make the problem go away? Yes, it very much looks like that solves it. I ran with the patch for 6 hours or so without any errors. I then switched back to an unpatched kernel and they reappeared immediately. > (Note this isn't the final correct patch we should apply. There > is no reason why this revert back to the older ->poll() logic > here should have any effect on the TX hang triggering...) s/no reason/no obvious reason/ ? ;-) Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
On Wednesday 16 January 2008, David Miller wrote: > Ok, here is the patch I'll propose to fix this. The goal is to make > it as simple as possible without regressing the thing we were trying > to fix. Looks good to me. Tested with -rc8. Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/10] x86: Reduce memory and intra-node effects with large count NR_CPUs V3
[EMAIL PROTECTED] wrote: >8472457 Total 30486950 +259% 30342823 +258% Hmmm. The table for previous versions looked a lot more impressive. now:8472457 Total+22014493 +259% +21870366 +258% V2 :7172678 Total+23314404 +325% -147590 -2% (recalculated for comparison) Did something go wrong with the "after" data? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
On Thursday 17 January 2008, David Miller wrote: > From: "Brandeburg, Jesse" <[EMAIL PROTECTED]> > > > We spent Wednesday trying to reproduce (without the patch) these issues > > without much luck, and have applied the patch cleanly and will continue > > testing it. Given the simplicity of the changes, and the community > > testing, I'll give my ack and we will continue testing. > > You need a slow CPU, and you need to make sure you do actually > trigger the TX limiting code there. Hmmm. Is a dual core Pentium D 3.20GHz considered slow these days? -- 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] 2.6.24-rc5: 'sysctl table check failed' when turning on printer
This is the first time I've seen this error. Last time I used the printer was with 2.6.24-rc3 and that time this error did not occur. System is Pentium D x86_64 kernel running Debian unstable. Printer is a HP Photosmart P1100 connected via parallel port. Not sure who should be CCed on this. ppdev0: registered pardevice sysctl table check failed: /dev/parport/parport0/devices/ppdev0/timeslice Sysctl already exists Pid: 14491, comm: hpijs Not tainted 2.6.24-rc5 #1 Call Trace: [] set_fail+0x3f/0x47 [] sysctl_check_table+0x4ae/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] register_sysctl_table+0x52/0x9d [] :parport:parport_device_proc_register+0xc3/0xe3 [] :parport:parport_register_device+0x206/0x267 [] :ppdev:pp_irq+0x0/0x40 [] :ppdev:pp_ioctl+0x13f/0x77c [] do_ioctl+0x55/0x6b [] vfs_ioctl+0x243/0x25c [] sys_ioctl+0x51/0x71 [] system_call+0x7e/0x83 Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] finish processor.h integration
Glauber de Oliveira Costa wrote: > What's left in processor_32.h and processor_64.h cannot be cleanly > integrated. However, it's just a couple of definitions. They are moved > to processor.h around ifdefs, and the original files are deleted. Note > that there's much less headers included in the final version. Either I must be missing something or this patch was corrupted somehow. I see: +#ifdef CONFIG_X86_32 [...] +#endif /* CONFIG_X86_64 */ While I'd have expected: +#ifdef CONFIG_X86_32 [...] +#endif /* CONFIG_X86_32 */ + +#ifdef CONFIG_X86_64 [...] +#endif /* CONFIG_X86_64 */ Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] finish processor.h integration
On Tuesday 18 December 2007, Glauber de Oliveira Costa wrote: > On Dec 18, 2007 6:54 PM, Frans Pop <[EMAIL PROTECTED]> wrote: > > Glauber de Oliveira Costa wrote: > > > What's left in processor_32.h and processor_64.h cannot be cleanly > > > integrated. However, it's just a couple of definitions. They are > > > moved to processor.h around ifdefs, and the original files are > > > deleted. Note that there's much less headers included in the final > > > version. > > > > Either I must be missing something or this patch was corrupted somehow. > > neither. > Note the else in the middle. It's just a mistake in the comment. Wouldn't an explicit second #ifdef block be a lot clearer (and improve maintainability) in this case? An #else can easily be overlooked among other preprocessor commands or when #ifdefs get nested. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [NET]: Remove PowerPC code from fec.c
Jochen Friedrich wrote: > +++ b/drivers/net/fec.c > @@ -23,6 +23,9 @@ > * > * Bug fixes and cleanup by Philippe De Muyter ([EMAIL PROTECTED]) > * Copyright (c) 2004-2006 Macq Electronique SA. > + * > + * This driver is now only used on ColdFire processors. Remove conditional > + * Powerpc code. > */ This comment makes sense for a changelog, but IMO it makes no sense at all to add it to the file. Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [NET]: Remove PowerPC code from fec.c
On Friday 25 January 2008, Jochen Friedrich wrote: > > Jochen Friedrich wrote: > >> +++ b/drivers/net/fec.c > >> @@ -23,6 +23,9 @@ > >> * > >> * Bug fixes and cleanup by Philippe De Muyter ([EMAIL PROTECTED]) > >> * Copyright (c) 2004-2006 Macq Electronique SA. > >> + * > >> + * This driver is now only used on ColdFire processors. Remove conditional > >> + * Powerpc code. > >> */ > > > > This comment makes sense for a changelog, but IMO it makes no sense at > > all to add it to the file. > > I just added it to clarify this code is now only used on m68knommu > (Coldfire). The comments on top are mailny about MPC860T CPUs (PowerPC), > however the driver is no longer used for these CPUs. > > Maybe the wording should be changed to: > > This driver is now only used on ColdFire (m68knommu) processors. > Conditional PowerPC code has been removed. Yes, that certainly makes more sense, although IMHO the second sentence is still somewhat redundant. (My problem was mainly with the second sentence. I should have made that more clear, sorry.) -- 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: From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> (linux.* mail to news gateway)
> config BLK_DEV_IDE_PMAC > - bool "Builtin PowerMac IDE support" > + tristate "Builtin PowerMac IDE support" This does not seem to make sense: if the option is now tristate, it is no longer "Builtin", so probably s/Builtin // in the description. Cheers, FJP -- 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/
[PATCH] Use on-board instead of built-in in config options
On Saturday 26 January 2008, Bartlomiej Zolnierkiewicz wrote: > On Saturday 26 January 2008, Jan Engelhardt wrote: > > On Jan 26 2008 21:31, Frans Pop wrote: > > >> config BLK_DEV_IDE_PMAC > > >> - bool "Builtin PowerMac IDE support" > > >> + tristate "Builtin PowerMac IDE support" > > this change is no-op at the moment because the next Kconfig line is: > > depends on PPC_PMAC && IDE=y && BLK_DEV_IDE=y > > [ PPC-specific IDE host drivers are still a special case because they are > using ppc_ide_md architecture hooks instead of doing proper host driver > initialization sequence - to be fixed after adding warm-plug support... > ] > > > >This does not seem to make sense: if the option is now tristate, it is > > > no longer "Builtin", so probably s/Builtin // in the description. > > > > Or something like s/Builtin/Onboard/; I did not even consider that meaning of built-in, but that does seem more descriptive. > Please send a patch. Of course :-) --- From: Frans Pop <[EMAIL PROTECTED]> To avoid confusion between 'built-in' drivers and 'on-board' controllers, consistently use the term 'on-board' for controllers. Minor line-wrapping improvements in descriptions for config options. Signed-off-by: Frans Pop <[EMAIL PROTECTED]> --- Spelling for on-board seems to be rather inconsistent. All of "on board", "on-board" and onboard currently occur. I've chosen "on-board" as that seems most correct to me. diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig index 64df55e..92b0117 100644 --- a/drivers/ide/Kconfig +++ b/drivers/ide/Kconfig @@ -617,8 +617,8 @@ config BLK_DEV_SC1200 tristate "National SCx200 chipset support" select BLK_DEV_IDEDMA_PCI help - This driver adds support for the built in IDE on the National - SCx200 series of embedded x86 "Geode" systems + This driver adds support for the on-board IDE controller on the + National SCx200 series of embedded x86 "Geode" systems. config BLK_DEV_PIIX tristate "Intel PIIXn chipsets support" @@ -793,22 +793,22 @@ config BLK_DEV_CELLEB depends on PPC_CELLEB select BLK_DEV_IDEDMA_PCI help - This driver provides support for the built-in IDE controller on + This driver provides support for the on-board IDE controller on Toshiba Cell Reference Board. If unsure, say Y. endif config BLK_DEV_IDE_PMAC - tristate "Builtin PowerMac IDE support" + tristate "PowerMac on-board IDE support" depends on PPC_PMAC && IDE=y && BLK_DEV_IDE=y help - This driver provides support for the built-in IDE controller on + This driver provides support for the on-board IDE controller on most of the recent Apple Power Macintoshes and PowerBooks. If unsure, say Y. config BLK_DEV_IDE_PMAC_ATA100FIRST - bool "Probe internal ATA/100 (Kauai) first" + bool "Probe on-board ATA/100 (Kauai) first" depends on BLK_DEV_IDE_PMAC help This option will cause the ATA/100 controller found in UniNorth2 @@ -823,7 +823,7 @@ config BLK_DEV_IDEDMA_PMAC depends on BLK_DEV_IDE_PMAC select BLK_DEV_IDEDMA_PCI help - This option allows the driver for the built-in IDE controller on + This option allows the driver for the on-board IDE controller on Power Macintoshes and PowerBooks to use DMA (direct memory access) to transfer data to and from memory. Saying Y is safe and improves performance. @@ -934,7 +934,7 @@ config BLK_DEV_GAYLE help This is the IDE driver for the Amiga Gayle IDE interface. It supports both the `A1200 style' and `A4000 style' of the Gayle IDE interface, - This includes builtin IDE interfaces on some Amiga models (A600, + This includes on-board IDE interfaces on some Amiga models (A600, A1200, A4000, and A4000T), and IDE interfaces on the Zorro expansion bus (M-Tech E-Matrix 530 expansion card). Say Y if you have an Amiga with a Gayle IDE interface and want to use @@ -948,10 +948,10 @@ config BLK_DEV_IDEDOUBLER depends on BLK_DEV_GAYLE && EXPERIMENTAL ---help--- This driver provides support for the so-called `IDE doublers' (made - by various manufacturers, e.g. Eyetech) that can be connected to the - builtin IDE interface of some Amiga models. Using such an IDE - doubler, you can connect up to four instead of two IDE devices on - the Amiga's builtin IDE interface. + by various manufacturers, e.g. Eyetech) that can be connected to + the on-board IDE interface of some Amiga models. Using such an IDE + doubler, you can connect up to four instead of two IDE devices to + the Amiga's on-board IDE interface. Note that the normal Amiga Gayle IDE driver may not work correctly if yo
Re: [PATCH 1/2] dm-band: The I/O bandwidth controller: Source code patch
Frans Pop wrote: > The help should probably be a bit more verbose as this does not tell > anybody much who has not already read the documentation. > > Maybe something like: > > This device-mapper target allows to define how the > available bandwith of a storage device should be > shared between processes or cgroups. > > Information on how to use dm-band is available in: >Documentation/device-mapper/band.txt > I just see in other Kconfig files that the last line should be: . Cheers, FJP -- 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/
Bind mount bug?
I'm not sure whether this is a bug or expected behavior. Suppose I create a "looped" bind mount situation as follows. # mkdir test # touch test/foo # mkdir bindtest # touch bindtest/bar # mkdir bindtest/test # mount --bind test/ bindtest/test/ # ls bindtest/test/ foo # mount --bind bindtest/ test/ # ls test/ bar test # ls test/test/ # I'd expected the last command to list "foo", but it shows an empty dir. Shouldn't it also show the original contents of test (as they were before the first bind mount)? # mount | grep test /root/test on /root/bindtest/test type none (rw,bind) /root/bindtest on /root/test type none (rw,bind) Cheers, Frans Pop - 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: Bind mount bug?
On Sunday 11 November 2007, Frans Pop wrote: > I'd expected the last command to list "foo", but it shows an empty dir. > Shouldn't it also show the original contents of test (as they were before > the first bind mount)? The problem is of course also that any changes made into /test/test will get lost into thin space: # touch test/test/baz # ls bindtest/test foo # umount test # ls test foo # - 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: Bind mount bug?
On Sunday 11 November 2007, Roland Kuhn wrote: > This mounts the bindtest/ tree on test/ _without_ copying the mount > points which are found on subtrees. Right. I guess this is the key point that tripped me up. > So, you see, test/test/test/a was (as it should) physically created > in test/test, where it is shadowed by the bind mount as long as that > is not removed. Which means that to continue the example from my follw-up mail: > # ls bindtest/test > foo > # umount test > # ls test > foo # umount bindtest/test # ls bindtest/test baz And there indeed is the missing file. > Nothing vanishes into "thin air" ;-) Yeah, I saw that syntax error after sending the mail "into space" would have been OK too, but not my combining the two :-) Thanks for the explanation! Cheers, FJP - 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: Bind mount bug?
On Sunday 11 November 2007, Jan Engelhardt wrote: > >This mounts the bindtest/ tree on test/ _without_ copying the mount > >points which are found on subtrees. This is necessary to avoid loops > >in the filesystem (bind mounts are somewhat like hardlinks on > >directories, just without the headaches). > > What you seek is mount --rbind. Thanks! That works fine with mount from util-linux-ng. Busybox' mount (at least Debian's admittedly old 1.1.3 version) seems to fail to do the recursing. I'll file a BR against busybox in Debian and check that again when we have a more current version. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/11 v3] enable "make ARCH=x86"
Sam Ravnborg wrote:
> With this patchset the former ARCH=i386 / ARCH=x86_64 are
> replaced by ARCH=x86.
[...]
> x86: drop backward compatibility symlinks to i386/boot and
>
> The fist kill the symlinks to bzImage.
> Now that we changed everything else to x86 there is no reason to
> keep the backward compatibility symlinks
> It is now people know we are unifying {i386,x86_64}=>x86 so the
> will not be too suprised seeing some breakage.
> If we do not kill the symlinks now - then when..
This was discussed before [1] and the result then was that the symlinks
should be kept for a while (Alan even suggested "a couple of years").
In fact, they were added exactly for that reason.
For one thing, this change is known to break Debian kernel builds using
kernel-package, a method I use myself to build from current git for testing.
I have so far not filed a bug report against kernel-package because there
was still discussion going on as to how things would look and IMO it's
better to change build tools once things have been finalized then trying to
keep up with a moving target.
Breaking kernel-package (and possibly other similar tools) by removing the
compat symlinks too early may mean less testing of kernels by people like me.
Cheers,
Frans Pop
P.S. The ARCH=x86 change would not have broken kernel-package as that could
be worked around using its cross-compilation options. And it currently looks
like the old options will be preserved anyway.
[1] http://lkml.org/lkml/2007/10/26/31
-
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] New Kernel Bugs
Romano Giannetti wrote: > This was what I did in my (in the end almost successful) bisecting when > trying to find the mmc problem (see the thread named "2.6.24-rc1 eat my > SD card"). This is true in theory, but it has some problem. The "this > commit does not compile is the easiest and in man git-bisect it's > explained how to solve it. The changes in .config options, added or > removed, are another problem when jumping back and forth from version. > > The main problem I had, and that stopped me to arrive to a definite is > this situation: [...] > (d was the series to change drivers to use sg helpers, and g was a "fix > fallout from sg helpers" patch). Now I have a series of kernels (d, e, > f) that did not work at all and so I cannot mark them good or bad. With > the number of patches added in the free-for-all week, this is a very > probable scenario. There is a way out from this using bisect? I think there are three strategies you can use in this case: - create a kernel config that is as simple as possible, but still supports your hardware and reproduces your problem; a simpler config will often avoid compilation issues in parts of the kernel that you're not using anyway and has the benefit of speeding up the compiles too - if you know/suspect in what part of the tree the bug is, first limit the bisection to that; you will have to verify that you did indeed find the correct (broken) change by doing a compile for the "last good commit + 1" - if you find a broken commit, use 'git-reset --hard' to try to jump past the bad set of commits, but of course that does not help in the case: g version-bad f unrelated bug corrected e d the broken commit that caused your problem c b unrelated bug that breaks compilation or system introduced a version-good in that case the best you can reasonably be expected to do is report that you narrowed it down to "between a and g" and leave the rest to the developers Cheers, FJP - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH revised] enable make ARCH=x86 (and stay backward compatible)
On Monday 12 November 2007, Sam Ravnborg wrote:
> This revised patchset does the followings things:
> o unify the i386 and x86_64 Kconfig files
> o introduce support for K64BIT to set CONFIG_64BIT on command line
> o introdue support for "make ARCH=x86"
> o degraded ARCH={i386,x86_64} to select between 32/64 for all*targets
> and otherwise just selecting the x86 architecture
>
> Based on feedback from previous submissions the following have changed:
> - The backwards compatibility links are kept
> - The backwards compatibility ARCH={i386,x86_64} are kept but degraded
> to select 32/64 bit during configuration for all*config targets.
> - ARCH={i386,x86_64} are not broken by any patches so bisect will
> not choke
Great! Thanks for being so responsive to comments Sam.
I've just built v2.6.24-rc2-409-g9418d5d + your patchset for both amd64 and
i386 using Debian's kernel-package and both went without problems.
One (minor) issue. If I start out with a .config for i386, the first make
oldconfig will ask to set 64-BIT:
64-bit kernel (64BIT) [N/y/?] (NEW)
It would be nice if that could be avoided somehow.
I'm compiling the 32-bit kernel in an i386 chroot on an x86_64 system.
Cheers,
FJP
-
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.624-rc1 regression] lost battery information
Andrey Borzenkov wrote: > I have lost battery in 2.6.24-rc1. Without CONFIG_ACPI_PROCFS I have > no /proc/acpi/battery and cannot test netlink interface because right now > there is no consumer of this. This is a known issue. Please see: http://lkml.org/lkml/2007/10/22/110 Cheers, Frans Pop - 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.624-rc1 regression] lost battery information
Andrey Borzenkov wrote: > I already have power_supply module, battery depends on it and it is > autloaded. But I fail to see where I can get battery info in /sys Ah, yes. I see what you mean now and I can confirm the same regression wrt missing battery data in /proc for my laptop. $ cat /proc/acpi/battery/BAT1/* cat: /proc/acpi/battery/BAT1/alarm: Bad address cat: /proc/acpi/battery/BAT1/info: Bad address cat: /proc/acpi/battery/BAT1/state: Bad address Sorry for the earlier misunderstanding. - 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.624-rc1 regression] lost battery information
Alexey Starikovskiy wrote: > Andrey Borzenkov wrote: >> is it in -rc1 or can you point me to the patch (I'd rather avoid having >> to pull from different git trees). Thank you. > No, it should be rc1. >> >> And what about ACPI_PROCFS case? It still needs attention I believe. > As you can see, there is info in /proc too: I'm missing the info in /sys too, so it looks like the error in proc and the missing info in /sys are related. Alexey: do you have POWER_SUPPLY and/or AC/BATTERY compiled in or modular? I wonder if that could make the difference. - 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.624-rc1 regression] lost battery information
Hmm. Things seem to have progressed since I was last online :-) With Alexey's original patch I also get a number of times: ACPI: element[12]->type = 1, expected string On Saturday 27 October 2007, Alexey Starikovskiy wrote: > As you wish... :) Please check the attached patch. With 'battery_allow_extract_string_from_integer.patch' all info in /proc is back and I now also see the new files in /sys/class/power_supply. The "OEM info" field (line 13 in BAT1/info) is empty, just as it was empty in 2.6.23 too. Tested-by: Frans Pop <[EMAIL PROTECTED]> Cheers, Frans Pop - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] I8K: Adds i8k driver to the x86_64 Kconfig
Bradley Smith wrote: > +config I8K > + tristate "Dell laptop support" Shouldn't that be config DELL_I8K, or even DELL_INSPIRON_8K? Cheers, Frans Pop - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-git4: Reported regressions from 2.6.23
David Miller wrote: > >> Subject: Settings to /proc/sys/net/ipv[46]/conf/all are >> not propagated. via sysctl too >> Submitter : Serge van den Boom <[EMAIL PROTECTED]> >> References: http://bugzilla.kernel.org/show_bug.cgi?id=9224 >> Handled-By: Hideaki YOSHIFUJI <[EMAIL PROTECTED]> > > I am to understand, from a reply from Herbert Xu, that this issue has > existed a long time, definitely since before 2.6.22, therefore it > doesn't belong on the regression list. I'm fairly sure that this originates with 2.6.21 as it looks very similar to http://bugzilla.kernel.org/show_bug.cgi?id=8519 which I filed at that time and which I traced to 8030f54499925d07. I've never been convinced that that change was correct, but as it now "works for me" due to changes in the Debian default configuration files, I decided to not follow up. Of course, not honoring 'all' is more obviously a bug than not honoring 'default' for existing interfaces. I've added a comment to #8519. Hope this helps, Frans Pop - 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: [stable] 2.6.23 regression: top displaying 9999% CPU usage
Hello Balbir, On Tuesday 16 October 2007, Balbir Singh wrote: > Christian Borntraeger wrote: > > Am Dienstag, 16. Oktober 2007 schrieb Balbir Singh: > >> I am trying to think out loud as to what the root cause of the problem > >> might be. In one of the discussion threads, I saw utime going > >> backwards, which seemed very odd, I suspect that those are rounding > >> errors. > >> > >> I don't understand your explanation below > >> > >> Initially utime = 9, stime = 0, sum_exec_runtime = S1 > >> > >> Later > >> > >> utime = 9, stime = 1, sum_exec_runtime = S2 > >> > >> We can be sure that S >= (utime + stime) > > > > I think here is the problem. How can we be sure? We cant. utime and > > stime are sampled, so they can be largely off in any direction,if the > > program sleeps often and manages to synchronize itself to the timer > > tick. Lets say a program only does a simple system call and then > > sleeps. So sum_exec_runtime is increased by lets say 1000 cycles on a > > 1Ghz box which means 1000ns. If now the timer tick happens exactly at > > this moment, stime is increased by 1 tick = 100ns. > > Yes, I thought of that just after I sent out my email. In the case that > you mention, the utime and stime accounting is incorrect anyway :-) > I think we need to find a better solution. I was going to propose that > we round correctly in (the divisions in) > > 1. task_utime() > 2. clock_t_to_cputime() > > I suspect we'll need to round task_utime() to p->utime if the value of > task_utime() < p->utime and the same thing for task_stime(). I've tried > reproducing the problem on my UML setup without any success. Let me > try and grab an x86 box. Any progress on this issue? I noticed that it's still there in current git. If a better implementation is not expected any time soon, how about an ACK on the reversion patch Christian proposed in http://lkml.org/lkml/2007/10/16/76 so we can at least get rid of the regression? Thanks, Frans Pop - 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: [stable] 2.6.23 regression: top displaying 9999% CPU usage
On Monday 29 October 2007, Ingo Molnar wrote: > * Christian Borntraeger <[EMAIL PROTECTED]> wrote: > > > - return clock_t_to_cputime(utime); > > > + p->prev_utime = max(p->prev_utime, clock_t_to_cputime(utime)); > > > + return p->prev_utime; > > > } > > > > [...] > > > > I dont think it will work. It will make utime monotic, but stime can > > still decrease. For example let sum_exec_runtime increase by a tiny > > little bit while utime will get a full additional tick. stime is > > sum-utime. So stime can still go backwards. So I think that we need > > this kind of logic for stime as well, no? > > yeah, probably. Peter? Yes, definitely :-) With this patch stime is still all over the place. Oct 29 22:12:39 314 64 Oct 29 22:12:40 392 68 Oct 29 22:12:41 408 67 <-- Oct 29 22:12:42 410 67 Oct 29 22:12:43 416 68 Oct 29 22:12:44 420 68 Oct 29 22:12:45 424 68 Oct 29 22:12:46 426 68 Oct 29 22:12:47 430 70 Oct 29 22:12:48 430 70 Oct 29 22:12:49 430 70 Oct 29 22:12:50 432 68 <-- Oct 29 22:12:51 432 69 Oct 29 22:12:52 432 69 Oct 29 22:12:53 432 69 Oct 29 22:12:54 432 69 Oct 29 22:12:55 432 69 Oct 29 22:12:56 433 70 Oct 29 22:12:57 434 69 <-- Oct 29 22:12:58 443 71 utime looks OK now, though I'd like to test it a bit more (when stime is fixed too) before giving a final verdict on that. - 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: [stable] 2.6.23 regression: top displaying 9999% CPU usage
On Monday 29 October 2007, Balbir Singh wrote: > We'll also need this additional patch (untested), OK. Both patches together do the trick. Gave it a nice long test run and got no more weirdness. Tested-by: Frans Pop <[EMAIL PROTECTED]> > but in the long run I think the approach needs to be > > 1. Update stime and utime at the time of context switching -- keep it >in sync with p->sum_exec_runtime > 2. Keep track of system/user context at system call entry points Feel free to send me a patch for testing when you have one. Cheers, Frans - 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: "Fix ATAPI transfer lengths" causes CD writing regression
Daniel Drake wrote: > I have narrowed down the exact command submission which causes those > nasty messages in dmesg. The function which submits this is named > "brasero_medium_get_page_2A_write_speed_desc". Just as an extra data point... I've compiled the test program an ran it on my ICH7/Pentium D box running 2.6.24-rc1-192-gef49c32 (x86_64), but it does not give the error and nothing in dmesg. I just get: result 0 My SATA DVD-RW drive is: Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: Optiarc Model: DVD RW AD-7170S Rev: 1.00 Type: CD-ROM ANSI SCSI revision: 05 - 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: Issue building kernel driver
Chris Holvenstot wrote: > Since I try to be slightly useful and build as many of the "test" kernel > images I can I end up rebuilding the VirtualBox kernel driver (open > source) on an almost daily basis. > > I attempted to rebuild the driver today and got the following error > messages running 2.6.24-rc1-git9 I had the same issue and managed to work around it. See: http://vbox.innotek.de/pipermail/vbox-users/2007-October/002372.html Cheers, FJP - 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/
Regression in 'tty layer struct pid conversions' (2.6.21)?
Hello Eric, Since 2.6.21, the KDE 'fish' protocol (basically remote file system access using ssh) has started showing problems, mostly on systems running x86_64 kernels. The process crashes with a signal 29. The bug log indicated a relation with the kernel. A git-bisect has shown the cause to be the activation patch in the 'tty layer struct pid conversions' patch set: commit ab521dc0f8e117fd808d3e425216864d60390500 Author: Eric W. Biederman <[EMAIL PROTECTED]> Date: Mon Feb 12 00:53:00 2007 -0800 [PATCH] tty: update the tty layer to work with struct pid It looks from the description of the patch set that it should cause no changes in behavior. It may of course be that the change in the kernel has exposed a latent issue in the KDE code. Details about the issue are available in the KDE BTS: http://bugs.kde.org/show_bug.cgi?id=145123 The comments in that report indicate that the issue is almost certainly more related to the (relative?) speed of systems than to x86_64 as an architecture. Cheers, Frans Pop - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Why are ipmi modules being loaded?
Last week I sent this same question to the openipmi-developer list on sourceforge, but did not get any replies. Does anyone here know the answer? AFAICT my system does not support ipmi, but despite that fact something is loading the ipmi_msghandler module and trying to load the ipmi_si module. The second fails, but the first stays loaded. From dmesg: ipmi message handler version 39.1 [...] ipmi_si: Trying PCI-specified kcs state machine at mem address 0x9022, slave address 0x0, irq 19 ipmi_si: There appears to be no BMC at this location ipmi_si: Unable to find any System Interface(s) This results in powertop showing: Top causes for wakeups: [...] 2.1% ( 10.0): ipmi_init_msghandler (ipmi_timeout) AFAICT from modules.pcimap, ipmi_si should only be loaded for PCI ID [103c:121a] (which I don't have), or for devices with class c0700 (which I also don't have). I also cannot find anything in /etc that could be responsible. So I wonder what _is_ responsible for trying to load the ipmi modules on my system and if that shouldn't be avoided. My system is Debian testing running 2.6.23. Cheers, Frans Pop 00:00.0 Host bridge [0600]: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub [8086:2770] (rev 02) 00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02) 00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8] (rev 01) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 [8086:27d0] (rev 01) 00:1c.2 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 [8086:27d4] (rev 01) 00:1c.3 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 [8086:27d6] (rev 01) 00:1c.4 PCI bridge [0604]: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 [8086:27e0] (rev 01) 00:1c.5 PCI bridge [0604]: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 [8086:27e2] (rev 01) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 [8086:27c8] (rev 01) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 [8086:27c9] (rev 01) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 [8086:27ca] (rev 01) 00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 [8086:27cb] (rev 01) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 01) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev e1) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge [8086:27b8] (rev 01) 00:1f.1 IDE interface [0101]: Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df] (rev 01) 00:1f.2 SATA controller [0106]: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA Storage Controller AHCI [8086:27c1] (rev 01) 00:1f.3 SMBus [0c05]: Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da] (rev 01) 01:00.0 Ethernet controller [0200]: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) [8086:108c] (rev 03) 01:00.3 Serial controller [0700]: Intel Corporation Active Management Technology - SOL [8086:108f] (rev 03) 01:00.4 Serial bus controller [0c07]: Intel Corporation 82573E KCS (Active Management) [8086:108e] (rev 03) 06:05.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [104c:8024]
Re: kbuild: disable depmod in cross-compile kernel build
Geert Uytterhoeven wrote: > Euh, is these really necessary? > > At work I have no problems running depmod on an i386 system for ppc64 > modules after I installed module-init-tools 3.3-pre2 (from Debian). That's right. I do depmod on i386 and amd64 for _all_ Debian architectures without any problems and I don't see why it should be a problem when running on other arches. It used to be a problem with depmod from modutils, but with depmod from module-init-tools it works perfectly. All it needs is the -b option and correct kernel version. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why are ipmi modules being loaded?
On Sunday 21 October 2007, Dave Jones wrote: > On Sun, Oct 21, 2007 at 03:34:11PM +0200, Frans Pop wrote: > > AFAICT from modules.pcimap, ipmi_si should only be loaded for PCI ID > > [103c:121a] (which I don't have), or for devices with class c0700 > > (which I also don't have). > > Hmm, is lspci truncating the class code? > > > 01:00.4 Serial bus controller [0c07]: Intel Corporation 82573E KCS > > (Active Management) [8086:108e] (rev 03) Actually, these three look to be related (see also link below): 01:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) 01:00.3 Serial controller: Intel Corporation Active Management Technology - SOL (rev 03) 01:00.4 Serial bus controller [0c07]: Intel Corporation 82573E KCS (Active Management) (rev 03) I did check the class files in /sys. For these devices those have: $ cat /sys/bus/pci/devices/\:01\:00.0/class 0x02 $ cat /sys/bus/pci/devices/\:01\:00.3/class 0x070002 $ cat /sys/bus/pci/devices/\:01\:00.4/class 0x0c0701 The last is close, but still does not match the 0x0c0700 in modules.pcimap. Is there some fuzzy matching going on there? > Because this smells like an IPMI-ish device. Hmm. Yes, guess it is -ish. It's documented in: http://download.intel.com/design/motherbd/cz/D1406801US.pdf (section 1.11.4) Looks like something that is only useful for remote management though and not for on-system management. Anyway, I've blacklisted the modules for now, but still feel that should not be necessary and there's an incorrect match happening. Thanks for the reply Dave. - 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: latest 2.6.23 git missing ACPI POWER_SUPPLY
Jeff Chua wrote: > Just pulled latest linux-2.6, and couldn't get ACPI to detect > ACPI_BATTERY and ACPI_AC. > > It seems ACPI POWER_SUPPLY is still missing. I had the same problem. It turns out you need to enable drivers -> Power supply class support (either built in or as module) to get ACPI AC/Battery support. I must say that having these relatively top-level ACPI settings depending on something that is relatively buried away is not very intuitive! Especially not since at first glance you don't really seem to need that option except for some weird hardware. CC'ing ACPI mailing list for other opinions. - 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: latest 2.6.23 git missing ACPI POWER_SUPPLY
On Monday 22 October 2007, Alexey Starikovskiy wrote: > Frans Pop wrote: > > I must say that having these relatively top-level ACPI settings > > depending on something that is relatively buried away is not very > > intuitive! Especially not since at first glance you don't really seem > > to need that option except for some weird hardware. > > > > CC'ing ACPI mailing list for other opinions. > > I was thinking that 'select' might be more appropriate here... > Please take a look on attached patch. Perfect! The power supply option can now no longer be unselected while battery or ac options are selected and will automatically get correct modular or compiled in status. Thanks. Tested-by: Frans Pop <[EMAIL PROTECTED]> - 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/
