Re: 2.6.24-rc4-git5: Reported regressions from 2.6.23
Hi, On Sat, Dec 08, 2007 at 02:20:01AM -0800, Andrew Morton wrote: Does this report now win me the lucky draw, pretty please? ;) nah, you have to cc the acpi guys to get a prize ;) Thought so shortly, but missed it. Andreas, please do separately report that WOL problem too.. Local setup issue only, at least this one *isn't* a 2.6.24-rc regression. ;) Our list just reached 30. Oh, so this is in fact a separate issue? Wasn't sure, couldn't do enough analysis of similar cases. Will test any (already submitted!) suggestions ASAP. Andreas Mohr -- 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 guidance
[EMAIL PROTECTED] wrote: On Sat, 08 Dec 2007 07:56:21 +0300, Al Boldi said: It probably goes without saying, that gitfs should have some basic configuration file to setup its transparent behaviour But then it's not *truly* transparent, is it? Don't mistake transparency with some form of auto-heuristic. Transparency only means that it inserts functionality without impeding your normal workflow. And that leaves another question - if you make a config file that excludes all the .o files - then what's backing the .o files? Those data blocks need to be *someplace*. Maybe you can do something ugly like use unionfs to combine your gitfs with something else to store the other files... Or any number of other possible implementation scenarios... But at that point, you're probably better off just creating a properly designed versioning filesystem. But gitfs is not about designing a versioning filesystem, it's about designing a transparent interface into git to handle an SCM use-case. Thanks! -- Al -- 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-rc4-git5: Reported regressions from 2.6.23
On Sat, Dec 08, 2007 at 02:20:01AM -0800, Andrew Morton wrote: On Sat, 8 Dec 2007 11:12:57 +0100 Andreas Mohr [EMAIL PROTECTED] wrote: ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0) is beyond end of object [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.GTF_] (Node c180b990), AE_AML_PACKAGE_LIMIT ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.CHN0.DRV1._GTF] (Node c180b888), AE_AML_PACKAGE_LIMIT ata1.01: _GTF evaluation failed (AE 0x300d) 037f6bb79f753c014bc84bca0de9bf98bb5ab169 ought to have fixed this? -- Matthew Garrett | [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: RocketPort Linux driver errors on module reload
On Oct 19, 2007 12:02 AM, Nick Thompson [EMAIL PROTECTED] wrote: From: Jiri Slaby [mailto:[EMAIL PROTECTED] And the last question, when do you expect/estimate this would happen? Jiri, To be honest, it would be hard to estimate at this point. I've discussed it with one of our software engineers, but we do not know how long it will be at this point, as there is a lot of work to do to get it up to kernel coding standards. I will definitely keep the list up to date. Hi Nick, any progress, any problems? thanks. -- 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-rc4-git5: Reported regressions from 2.6.23
On Sat, 8 Dec 2007 03:40:49 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: This message contains a list of some regressions from 2.6.23 which have been reported since 2.6.24-rc1 was released and for which there are no fixes in the mainline that I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. .. Subject : system hangs after a few minutes Submitter : Marcus Better [EMAIL PROTECTED] References: http://bugzilla.kernel.org/show_bug.cgi?id=9335 Handled-By: Andrew Morton [EMAIL PROTECTED] Alan Stern [EMAIL PROTECTED] Patch : http://bugzilla.kernel.org/attachment.cgi?id=13871action=view This one we have a confirmed fix from Alan but it doesn't appear to be in anyone's tree. There is a second bug in here, applicable to core x86: Marcus's machine won't boot with nmi_watchdog=1. -- 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: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]
On 12/08/2007 09:39 AM, Ingo Molnar wrote: * Jiri Slaby [EMAIL PROTECTED] wrote: Unfortunately no change here. could you try to revert this change: -int softlockup_thresh = 10; +int softlockup_thresh = 60; i.e. change the value of softlockup_thresh back to 10. You should be able to tweak this runtime as well, without patching the kernel: echo 10 /proc/sys/kernel/softlockup_thresh What should have this changed? I can't see any 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: [patch 07/18] v4l: nopage
* Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 05 Dec 2007 18:15:54 +1100
[EMAIL PROTECTED] wrote:
+static int
+videobuf_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
struct page *page;
- dprintk(3,nopage: fault @ %08lx [vma %08lx-%08lx]\n,
- vaddr,vma-vm_start,vma-vm_end);
- if (vaddr vma-vm_end)
- return NOPAGE_SIGBUS;
+ dprintk(3,fault: fault @ %08lx [vma %08lx-%08lx]\n,
+ (unsigned long)vmf-virtual_address,vma-vm_start,vma-vm_end);
page = alloc_page(GFP_USER | __GFP_DMA32);
if (!page)
- return NOPAGE_OOM;
+ return VM_FAULT_OOM;
clear_user_page(page_address(page), vaddr, page);
This didn't compile on sparc64 because `vaddr' is undefined.
Let us see why:
#define clear_user_page(page, vaddr, pg) clear_page(page)
#define copy_user_page(to, from, vaddr, pg) copy_page(to, from)
#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \
alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr)
root cause: lack of argument checking on x86 due to stupid macros.
Could someone *please* start a little project of extirpating this
utter brain damage? Convert those macros to typechecked static
inlines on x86 (at least) so this sort of thing (which happens again
and again and again) is lessened?
i wanted to write a reply to suggest a checkpatch policy for this. When
i noticed this sentence at the end of your mail:
macros are such miserable things. I wonder if we could get checkpatch
to help out here?
/me too :-)
any policy that gets into checkpatch.pl's default output is a policy for
arch/x86 patch merging. (as long as it's not a false positive) And
because we do all these unifications the effects of checkpatch.pl
permeate basically every aspect of arch/x86.
one approach would be to make new macros in include/* a no-no. That
would hurt a few of the legitimate uses though, so maybe a useful
refinement would be to check the structure of macros: are arguments used
twice (side-effect), are arguments unused (typechecking dager), are
arguments cast (type-loss danger), etc. Looks very hard to implement
though :-/ Andy, what do you think?
Ingo
--
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: Possible EXT2 race
On Fri, 2007-12-07 at 13:58 -0500, linux-os (Dick Johnson) wrote: On Fri, 7 Dec 2007, Dave Jones wrote: On Fri, Dec 07, 2007 at 08:15:42AM -0500, linux-os (Dick Johnson) wrote: Dec 7 04:05:55 chaos kernel: sd 0:0:1:0: [sdb] Add. Sense: Peripheral device write fault This sounds more like a hardware problem. There was an attempt to write beyond the end of the device because everything in the file-system was getting trashed. I can read/write the 5 year-old SCSI physical drive with no errors from both within linux and through the Adaptec BIOS. This problem only occurs when I attempt to truncate a file that is being written by another task. Well, that might be how you can reproduce it, but this is almost certainly a hardware problem and not EXT2 at fault - the filesystem can only do just so much once its data has been corrupted by an old disk. Jon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development Objective-C
Ben Crowhurst wrote: Loïc Grenié wrote: 2007/11/29, Ben Crowhurst [EMAIL PROTECTED]: Has Objective-C ever been considered for kernel development? regards, BPC I have tried it in a toy kernel. Oskit style. The code reuse is very high specially with string ops and driver interfaces. Its also very easy to do unit testing with. My main problem was the quality of the compiler optimization. Its just not good enough. I think if the compiler can do the right kind of optimizations correctly then a low overhead OO language like objective-c can be used in a kernel. On the other hand its the automated testing part that really matters for me. Imagine adding features to linux week after week without ever getting a serious panic or two. And then getting a big performance boost whenever the compiler does more and more optimizations correctly. No, it has not. Any language that looks remotely like an OO language has not ever been considered for (Linux) kernel development and for most, if not all, other operating systems kernels. Various problems occur in an object oriented language. One of them is garbage collection: it provokes asynchronous delays and, during an interrupt or a system call for a real time task, the kernel cannot wait. Objective C 1.0 does not force nor have garbage collection. True. Another is memory overhead: all the magic that OO languages provide take space in memory and Linux kernel is used in embedded systems with very tight memory requirements. But are embedded systems not rapidly moving on. Turning to stare at the ADSL X6 modem with MB's of ram. Its all about optimizations. -- Democracy is about two wolves and a sheep deciding what to eat for dinner. begin:vcard fn:Rogelio M. Serrano Jr n:M. Serrano Jr;Rogelio org:SMSG Communications Philippines;Technical Department adr:;;Republic of the Philippines email;internet:[EMAIL PROTECTED] title:Programmer tel;work:+6327534145 tel;home:+6329527026 tel;cell:+639209202267 x-mozilla-html:FALSE version:2.1 end:vcard signature.asc Description: OpenPGP digital signature
Re: 2.6.24-rc4-git5: Reported regressions from 2.6.23
* Fabio Comolli [EMAIL PROTECTED] wrote:
snip
Subject : Battery shows up twice in kpowersave
Submitter : Rolf Eike Beer [EMAIL PROTECTED]
References : http://bugzilla.kernel.org/show_bug.cgi?id=9494
Handled-By : Alexey Starikovskiy [EMAIL PROTECTED]
Patch :
I don't think that this is a regression: I reported on RedHat bugzilla
when I switched from F7 to F8 and I was using 2.6.23.8 at that time.
It looks to me an HAL regression, but of course I may be wrong :-) as
the reported bisected to a bad commit.
https://bugzilla.redhat.com/show_bug.cgi?id=373041
By the way, I now switched to Fedrora Rawhide with a 2.6.24-rc4-git5
custom kernel and Gnome desktop and the problem is still present, even
with gnome-power-manager.
to me this looks like an ABI regression - utilities should work without
change. Something changed in /sys output that caused HAL to think that
there are two batteries:
| The output of lshal shows that there are two UDI's with
| info.capabilities = { 'battery' }:
|
| udi = '/org/freedesktop/Hal/devices/acpi_BAT0'
| udi = '/org/freedesktop/Hal/devices/computer_power_supply_0'
whether it's a HAL bug or a kernel bug, the original state should be
restored and it should be worked out without breaking users of older HAL
versions.
grumble: way too many times do various system utilities break when i
upgrade the kernel on my laptop. Maybe a new debug mechanism: we should
start fingerprinting the exact /sys and /proc output and enforce that
it's immutable across kernel releases as long as the hardware is
unmodified?
Ingo
--
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-rc4-git5: Reported regressions from 2.6.23
On Sat, 2007-12-08 at 03:40 +0100, Rafael J. Wysocki wrote: Subject : leds: ledtrig-timer calls sleeping function from invalid context Submitter : Márton Németh [EMAIL PROTECTED] References: http://bugzilla.kernel.org/show_bug.cgi?id=9264 Handled-By: Richard Purdie [EMAIL PROTECTED] Patch : http://bugzilla.kernel.org/attachment.cgi?id=13493action=view The fix is now in mainline: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=dc47206e552c0850ad11f7e9a1fca0a3c92f5d65 Cheers, Richard -- 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-rc4-git5: Reported regressions from 2.6.23
On Sat, 8 Dec 2007 11:12:57 +0100 Andreas Mohr [EMAIL PROTECTED] wrote: Hi, On Sat, Dec 08, 2007 at 01:36:31AM -0800, Andrew Morton wrote: Subject : PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond end of object Submitter : Hans de Bruin [EMAIL PROTECTED] References: http://bugzilla.kernel.org/show_bug.cgi?id=9320 Handled-By: Robert Moore [EMAIL PROTECTED] Tejun Heo [EMAIL PROTECTED] Fu Michael [EMAIL PROTECTED] Patch : A number of other people are seeing the same thing and Tejun is putting in a blacklist of machines which cannot use libata+acpi. That patch is not yet in any git tree which I pull. AFACIT the machines kepe working OK - there's just some nasty dmesg spew. If any machines _are_ breaking then this could cause real problems and I'd prefer that we either go for a whitelist or arrange to detect the condition and fall back to non-acpi ata. Does this report now win me the lucky draw, pretty please? ;) nah, you have to cc the acpi guys to get a prize ;) Lenco, could you please take a look? Andreas, please do separately report that WOL problem too.. Our list just reached 30. STD regression rc1 - rc234, suspend fails completely, recovering is pretty much useless since HDD is DEAD from this point on anyway. Managed to capture -rc2 suspend logging via still-alive ssh session. 2.6.24-rc1 suspend/resume log, successful (well, a couple seconds delay, most likely due to well-recovered AML failure): swsusp: Marking nosave pages: 0009f000 - 0010 swsusp: Basic memory bitmaps created Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Shrinking memory... done (0 pages freed) Freed 0 kbytes in 0.02 seconds (0.00 MB/s) Suspending console(s) hub 4-0:1.0: hub_suspend usb usb4: bus suspend ehci_hcd :00:10.3: suspend root hub hub 3-0:1.0: hub_suspend usb usb3: bus suspend usb usb3: suspend_rh hub 2-0:1.0: hub_suspend usb usb2: bus suspend usb usb2: suspend_rh hub 1-0:1.0: hub_suspend usb usb1: bus suspend usb usb1: suspend_rh sd 0:0:0:0: [sda] Synchronizing SCSI cache parport_pc 00:09: disabled serial 00:08: disabled serial 00:07: disabled ACPI: PCI interrupt for device :00:11.5 disabled ACPI handle has no context! ACPI: PCI interrupt for device :00:11.1 disabled ACPI: PCI interrupt for device :00:10.3 disabled ehci_hcd :00:10.3: -- PCI D3/wakeup uhci_hcd :00:10.2: uhci_suspend ACPI: PCI interrupt for device :00:10.2 disabled uhci_hcd :00:10.2: -- PCI D3 uhci_hcd :00:10.1: uhci_suspend ACPI: PCI interrupt for device :00:10.1 disabled uhci_hcd :00:10.1: -- PCI D3 uhci_hcd :00:10.0: uhci_suspend ACPI: PCI interrupt for device :00:10.0 disabled uhci_hcd :00:10.0: -- PCI D3 ACPI: PCI interrupt for device :00:0d.0 disabled ACPI handle has no context! ACPI: PCI interrupt for device :00:0c.0 disabled ACPI handle has no context! pci_set_power_state(): :00:00.0: state=3, current state=5 swsusp: critical section: swsusp: Need to copy 51195 pages Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. evxfevnt-0079 [00] enable: System is already in ACPI mode ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 20 ACPI: PCI Interrupt Link [ALKB] BIOS reported IRQ 0, using IRQ 21 ACPI: PCI Interrupt Link [ALKC] BIOS reported IRQ 0, using IRQ 22 ACPI: PCI Interrupt Link [ALKD] BIOS reported IRQ 0, using IRQ 23 evxfevnt-0079 [00] enable: System is already in ACPI mode ACPI: Unable to turn cooling device [c180ff60] 'off' PCI: Setting latency timer of device :00:01.0 to 64 ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[db14-db1407ff] Max Packet=[2048] IR/IT contexts=[4/8] ACPI: PCI Interrupt :00:0a.0[A] - GSI 18 (level, low) - IRQ 18 e100: eth-intel: e100_watchdog: link up, 100Mbps, full-duplex PM: Writing back config space on device :00:0d.0 at offset 1 (was 217, writing 213) ACPI: PCI Interrupt :00:0d.0[A] - GSI 19 (level, low) - IRQ 22 uhci_hcd :00:10.0: PCI D0, from previous PCI D3 ACPI: PCI Interrupt :00:10.0[A] - Link [ALKB] - GSI 21 (level, low) - IRQ 20 uhci_hcd :00:10.0: uhci_resume uhci_hcd :00:10.0: uhci_check_and_reset_hc: cmd = 0x uhci_hcd :00:10.0: Performing full reset usb usb1: root hub lost power or was reset usb usb1: suspend_rh uhci_hcd :00:10.1: PCI D0, from previous PCI D3 ACPI: PCI Interrupt :00:10.1[B] - Link [ALKB] - GSI 21 (level, low) - IRQ 20 uhci_hcd :00:10.1: uhci_resume uhci_hcd :00:10.1: uhci_check_and_reset_hc: cmd = 0x uhci_hcd :00:10.1: Performing full reset usb usb2: root hub lost power or was reset usb usb2:
Re: [patch 07/18] v4l: nopage
On Sat, 8 Dec 2007 10:15:08 +0100 Ingo Molnar [EMAIL PROTECTED] wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 05 Dec 2007 18:15:54 +1100
[EMAIL PROTECTED] wrote:
+static int
+videobuf_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
struct page *page;
- dprintk(3,nopage: fault @ %08lx [vma %08lx-%08lx]\n,
- vaddr,vma-vm_start,vma-vm_end);
- if (vaddr vma-vm_end)
- return NOPAGE_SIGBUS;
+ dprintk(3,fault: fault @ %08lx [vma %08lx-%08lx]\n,
+ (unsigned long)vmf-virtual_address,vma-vm_start,vma-vm_end);
page = alloc_page(GFP_USER | __GFP_DMA32);
if (!page)
- return NOPAGE_OOM;
+ return VM_FAULT_OOM;
clear_user_page(page_address(page), vaddr, page);
This didn't compile on sparc64 because `vaddr' is undefined.
Let us see why:
#define clear_user_page(page, vaddr, pg)clear_page(page)
#define copy_user_page(to, from, vaddr, pg) copy_page(to, from)
#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \
alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr)
root cause: lack of argument checking on x86 due to stupid macros.
Could someone *please* start a little project of extirpating this
utter brain damage? Convert those macros to typechecked static
inlines on x86 (at least) so this sort of thing (which happens again
and again and again) is lessened?
We should fix existing stuff, like this.
i wanted to write a reply to suggest a checkpatch policy for this. When
i noticed this sentence at the end of your mail:
macros are such miserable things. I wonder if we could get checkpatch
to help out here?
/me too :-)
any policy that gets into checkpatch.pl's default output is a policy for
arch/x86 patch merging. (as long as it's not a false positive) And
because we do all these unifications the effects of checkpatch.pl
permeate basically every aspect of arch/x86.
one approach would be to make new macros in include/* a no-no. That
would hurt a few of the legitimate uses though, so maybe a useful
refinement would be to check the structure of macros: are arguments used
twice (side-effect), are arguments unused (typechecking dager), are
arguments cast (type-loss danger), etc. Looks very hard to implement
though :-/ Andy, what do you think?
I think whining about anything which matches
#define foo(...) bar(
would be a decent start.
grep '^[ ]*#[]*define[ ][ ]*[^(]*[(][^)]*[)][
]*[a-zA-Z]' include/asm-x86/*.h
(hey, that worked on the first attempt)
Lots of falsies tho.
--
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: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regressions from 2.6.23]
On Sat, 8 Dec 2007 10:30:39 +0100 Ingo Molnar [EMAIL PROTECTED] wrote: * Rafael J. Wysocki [EMAIL PROTECTED] wrote: Subject : tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() Submitter : Ingo Molnar [EMAIL PROTECTED] References : http://lkml.org/lkml/2007/11/29/157 http://bugzilla.kernel.org/show_bug.cgi?id=9497 Handled-By : Matt Mackall [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/11/29/387 Matt, the above bug is still occuring en masse during random bootups: [ 67.828312] WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() [ 41.270905] WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() [ 82.378714] WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() [ 35.308126] WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() [ 35.484155] WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() and the patch does not seem to be upstream yet. err, umm, OK, I'll go hunt it down and take a closer look at it. -- 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-rc4-git5: Reported regressions from 2.6.23
On Sat, 8 Dec 2007 03:40:49 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: This message contains a list of some regressions from 2.6.23 which have been reported since 2.6.24-rc1 was released and for which there are no fixes in the mainline that I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. ... Subject : cd/dvd inaccessible in 2.6.24-rc2 Submitter : Will Trives [EMAIL PROTECTED] References: http://lkml.org/lkml/2007/11/9/290 http://bugzilla.kernel.org/show_bug.cgi?id=9346 Handled-By: Len Brown [EMAIL PROTECTED] Tejun Heo [EMAIL PROTECTED] Patch : Nasty one. Tejun and several diligent reporters are doing sterling work there and things have improved. I don't know whether any of Tejun's patches have been merged yet, but we'll probably be OK on this one. What is unclear (to me) is what actually caused those people's machines to break? -- 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/
Quotaon livelock
Hi lkml, Enabling FS quotas can take up to several minutes to finish and depends on other users disk activity. This makes it a livelock (as it can be finished anyway). The problem described at: http://bugzilla.kernel.org/show_bug.cgi?id=9520 Yes, if we need to enable quotas once in the system start - no problem. But if we have to disable/enable it periodically - this become a nightmare. Please don't advice to use edquota or so (quotactl(Q_SETQUOTA...) based things). What if it's really needed to use quotactl(Q_QUOTAOFF...)/quotactl(Q_QUOTAON...) The problem is at fs/dquot.c:add_dquot_ref() It's restarting to loop over the inodes list once it inits quota on an inode. And this happens over and over if something is modifying inodes list during quotas enabling. It looks like the action must take some time depending on FS size, but not on other users disk activity... Any advices how the algorithm at fs/dquot.c:add_dquot_ref() can be enhanced? Thanks Nick -- 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: Out of tree module using LSM
On Thu 2007-11-29 23:58:44, Andi Kleen wrote: Alan Cox [EMAIL PROTECTED] writes: The simple case is open write cathedral and bazaar in some order close trap close - process - label eric_t open (eric_t) - SELinux no Anyone smart will then write it out of order and keep the file open, or That would assume Eric already has a program running on your system optimized to inject his works in a obfuscated way. And if he has a program running he can do nearly everything already. You already lost the game. The normal case Tvrtko et.al. are trying to handle would be more the work getting downloaded from somewhere or read from a usb stick using normal programs like web browsers or file managers who don't do any out of order writing tricks and other obfuscation. Fortunately normal programs tend to be dynamically linked, so LD_PRELOAD is fine to handle them. And we know we can't handle nasty programs. Seems like LD_PRELOAD is the way to go. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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-rc4-git5: Reported regressions from 2.6.23
Hi, On Sat, Dec 08, 2007 at 01:36:31AM -0800, Andrew Morton wrote: Subject : PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond end of object Submitter : Hans de Bruin [EMAIL PROTECTED] References : http://bugzilla.kernel.org/show_bug.cgi?id=9320 Handled-By : Robert Moore [EMAIL PROTECTED] Tejun Heo [EMAIL PROTECTED] Fu Michael [EMAIL PROTECTED] Patch : A number of other people are seeing the same thing and Tejun is putting in a blacklist of machines which cannot use libata+acpi. That patch is not yet in any git tree which I pull. AFACIT the machines kepe working OK - there's just some nasty dmesg spew. If any machines _are_ breaking then this could cause real problems and I'd prefer that we either go for a whitelist or arrange to detect the condition and fall back to non-acpi ata. Does this report now win me the lucky draw, pretty please? ;) STD regression rc1 - rc234, suspend fails completely, recovering is pretty much useless since HDD is DEAD from this point on anyway. Managed to capture -rc2 suspend logging via still-alive ssh session. 2.6.24-rc1 suspend/resume log, successful (well, a couple seconds delay, most likely due to well-recovered AML failure): swsusp: Marking nosave pages: 0009f000 - 0010 swsusp: Basic memory bitmaps created Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Shrinking memory... done (0 pages freed) Freed 0 kbytes in 0.02 seconds (0.00 MB/s) Suspending console(s) hub 4-0:1.0: hub_suspend usb usb4: bus suspend ehci_hcd :00:10.3: suspend root hub hub 3-0:1.0: hub_suspend usb usb3: bus suspend usb usb3: suspend_rh hub 2-0:1.0: hub_suspend usb usb2: bus suspend usb usb2: suspend_rh hub 1-0:1.0: hub_suspend usb usb1: bus suspend usb usb1: suspend_rh sd 0:0:0:0: [sda] Synchronizing SCSI cache parport_pc 00:09: disabled serial 00:08: disabled serial 00:07: disabled ACPI: PCI interrupt for device :00:11.5 disabled ACPI handle has no context! ACPI: PCI interrupt for device :00:11.1 disabled ACPI: PCI interrupt for device :00:10.3 disabled ehci_hcd :00:10.3: -- PCI D3/wakeup uhci_hcd :00:10.2: uhci_suspend ACPI: PCI interrupt for device :00:10.2 disabled uhci_hcd :00:10.2: -- PCI D3 uhci_hcd :00:10.1: uhci_suspend ACPI: PCI interrupt for device :00:10.1 disabled uhci_hcd :00:10.1: -- PCI D3 uhci_hcd :00:10.0: uhci_suspend ACPI: PCI interrupt for device :00:10.0 disabled uhci_hcd :00:10.0: -- PCI D3 ACPI: PCI interrupt for device :00:0d.0 disabled ACPI handle has no context! ACPI: PCI interrupt for device :00:0c.0 disabled ACPI handle has no context! pci_set_power_state(): :00:00.0: state=3, current state=5 swsusp: critical section: swsusp: Need to copy 51195 pages Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. evxfevnt-0079 [00] enable: System is already in ACPI mode ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 20 ACPI: PCI Interrupt Link [ALKB] BIOS reported IRQ 0, using IRQ 21 ACPI: PCI Interrupt Link [ALKC] BIOS reported IRQ 0, using IRQ 22 ACPI: PCI Interrupt Link [ALKD] BIOS reported IRQ 0, using IRQ 23 evxfevnt-0079 [00] enable: System is already in ACPI mode ACPI: Unable to turn cooling device [c180ff60] 'off' PCI: Setting latency timer of device :00:01.0 to 64 ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[db14-db1407ff] Max Packet=[2048] IR/IT contexts=[4/8] ACPI: PCI Interrupt :00:0a.0[A] - GSI 18 (level, low) - IRQ 18 e100: eth-intel: e100_watchdog: link up, 100Mbps, full-duplex PM: Writing back config space on device :00:0d.0 at offset 1 (was 217, writing 213) ACPI: PCI Interrupt :00:0d.0[A] - GSI 19 (level, low) - IRQ 22 uhci_hcd :00:10.0: PCI D0, from previous PCI D3 ACPI: PCI Interrupt :00:10.0[A] - Link [ALKB] - GSI 21 (level, low) - IRQ 20 uhci_hcd :00:10.0: uhci_resume uhci_hcd :00:10.0: uhci_check_and_reset_hc: cmd = 0x uhci_hcd :00:10.0: Performing full reset usb usb1: root hub lost power or was reset usb usb1: suspend_rh uhci_hcd :00:10.1: PCI D0, from previous PCI D3 ACPI: PCI Interrupt :00:10.1[B] - Link [ALKB] - GSI 21 (level, low) - IRQ 20 uhci_hcd :00:10.1: uhci_resume uhci_hcd :00:10.1: uhci_check_and_reset_hc: cmd = 0x uhci_hcd :00:10.1: Performing full reset usb usb2: root hub lost power or was reset usb usb2: suspend_rh uhci_hcd :00:10.2: PCI D0, from previous PCI D3 ACPI: PCI Interrupt :00:10.2[C] - Link [ALKB] - GSI 21 (level, low) - IRQ 20 uhci_hcd :00:10.2: uhci_resume uhci_hcd :00:10.2: uhci_check_and_reset_hc: cmd = 0x uhci_hcd :00:10.2: Performing full reset usb usb3: root hub lost power or was reset usb usb3: suspend_rh ehci_hcd
Re: 2.6.24-rc4-git5: Reported regressions from 2.6.23
On Sat, 8 Dec 2007 03:40:49 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: This message contains a list of some regressions from 2.6.23 which have been reported since 2.6.24-rc1 was released and for which there are no fixes in the mainline that I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. Subject : PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond end of object Submitter : Hans de Bruin [EMAIL PROTECTED] References: http://bugzilla.kernel.org/show_bug.cgi?id=9320 Handled-By: Robert Moore [EMAIL PROTECTED] Tejun Heo [EMAIL PROTECTED] Fu Michael [EMAIL PROTECTED] Patch : A number of other people are seeing the same thing and Tejun is putting in a blacklist of machines which cannot use libata+acpi. That patch is not yet in any git tree which I pull. AFACIT the machines kepe working OK - there's just some nasty dmesg spew. If any machines _are_ breaking then this could cause real problems and I'd prefer that we either go for a whitelist or arrange to detect the condition and fall back to non-acpi ata. -- 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: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regressions from 2.6.23]
* Rafael J. Wysocki [EMAIL PROTECTED] wrote: Subject : tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() Submitter : Ingo Molnar [EMAIL PROTECTED] References: http://lkml.org/lkml/2007/11/29/157 http://bugzilla.kernel.org/show_bug.cgi?id=9497 Handled-By: Matt Mackall [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/11/29/387 Matt, the above bug is still occuring en masse during random bootups: [ 67.828312] WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() [ 41.270905] WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() [ 82.378714] WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() [ 35.308126] WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() [ 35.484155] WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() and the patch does not seem to be upstream yet. Ingo -- 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-rc4-git5: Reported regressions from 2.6.23
On Sat, 8 Dec 2007 03:40:49 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: This message contains a list of some regressions from 2.6.23 which have been reported since 2.6.24-rc1 was released and for which there are no fixes in the mainline that I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. Twenty nine, huh? It would be useful if these records were sorted in date-of-reportage order and had a date stamp so we could see how long they've been hanging about. Something to think about for the post-2.6.24 regression if you'll be handling those? Subject : leds: ledtrig-timer calls sleeping function from invalid context Submitter : Márton Németh [EMAIL PROTECTED] References: http://bugzilla.kernel.org/show_bug.cgi?id=9264 Handled-By: Richard Purdie [EMAIL PROTECTED] Patch : http://bugzilla.kernel.org/attachment.cgi?id=13493action=view That patch has been merged (dc47206e552c0850ad11f7e9a1fca0a3c92f5d65) and assuming Márton has tested the latest git snapshot (ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots) successfully we can cross it off? -- 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-rc4-mm1: undefined reference to `compat_sys_timerfd' on sparc64
LD .tmp_vmlinux1 arch/sparc64/kernel/head.o: In function `sys_call_table32': arch/sparc64/kernel/head.S:(.text+0x224e0): undefined reference to `compat_sys_timerfd' make: *** [.tmp_vmlinux1] Error 1 argh, sorry, I am soo fed up with fixing that patch. --- a/arch/sparc64/kernel/systbls.S~timerfd-v3-new-timerfd-api-sparc64-fix +++ a/arch/sparc64/kernel/systbls.S @@ -80,7 +80,7 @@ sys_call_table32: .word sys_fchmodat, sys_faccessat, compat_sys_pselect6, compat_sys_ppoll, sys_unshare /*300*/ .word compat_sys_set_robust_list, compat_sys_get_robust_list, compat_sys_migrate_pages, compat_sys_mbind, compat_sys_get_mempolicy .word compat_sys_set_mempolicy, compat_sys_kexec_load, compat_sys_move_pages, sys_getcpu, compat_sys_epoll_pwait -/*310*/ .word compat_sys_utimensat, compat_sys_signalfd, compat_sys_timerfd, sys_eventfd, compat_sys_fallocate +/*310*/ .word compat_sys_utimensat, compat_sys_signalfd, sys_ni_syscall, sys_eventfd, compat_sys_fallocate #endif /* CONFIG_COMPAT */ Ok - that helped. Thanks, Mariusz -- 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] scheduler: fix x86 regression in native_sched_clock
* Nick Piggin [EMAIL PROTECTED] wrote:
On Saturday 08 December 2007 11:50, Nick Piggin wrote:
I guess your patch is fairly complex but it should work
I should also add that although complex, it should have a much smaller
TSC delta window in which the wrong scaling factor can get applied to
it (I guess it is about as good as you can possibly get). So I do like
it :)
ok :-)
the scariest bit isnt even the scaling i think - that is a fairly
straightforward and clean PER_CPU-ization of the global scaling factor,
and its hookup with cpufreq events. (and the credit for that goes to
Guillaume Chazarain) We could even split it into two to make it even
less scary and more bisectable.
the scariest bit is the adding of cpu_clock() to kernel/printk.c so late
in the game, and the anti-recursion code i did there. Maybe because this
only affects CONFIG_PRINTK_TIME we could try it even for v2.6.24.
i've now completed a couple of hundred random bootups on x86 overnight,
with the full stack of these patches applied, and no problems.
Could have a really critical look at the two patches below and give your
Reviewed-by line(s) if you agree with having them in v2.6.24? I'd feel a
lot better about this that way :-) I do have the feeling that it makes
printk printout a lot more robust in general, independently of the
cpu_clock() change - especially with more complex consoles like
netconsole or fbcon.
Ingo
Subject: printk: make printk more robust by not allowing recursion
From: Ingo Molnar [EMAIL PROTECTED]
make printk more robust by allowing recursion only if there's a crash
going on. Also add recursion detection.
I've tested it with an artificially injected printk recursion - instead
of a lockup or spontaneous reboot or other crash, the output was a well
controlled:
[ 41.057335] SysRq : 2BUG: recent printk recursion!
[ 41.057335] loglevel0-8 reBoot Crashdump show-all-locks(D) tErm Full kIll
saK showMem Nice powerOff showPc show-all-timers(Q) unRaw Sync showTasks
Unmount shoW-blocked-tasks
also do all this printk-debug logic with irqs disabled.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
kernel/printk.c | 48 ++--
1 file changed, 38 insertions(+), 10 deletions(-)
Index: linux/kernel/printk.c
===
--- linux.orig/kernel/printk.c
+++ linux/kernel/printk.c
@@ -628,30 +628,57 @@ asmlinkage int printk(const char *fmt, .
/* cpu currently holding logbuf_lock */
static volatile unsigned int printk_cpu = UINT_MAX;
+const char printk_recursion_bug_msg [] =
+ KERN_CRIT BUG: recent printk recursion!\n;
+static int printk_recursion_bug;
+
asmlinkage int vprintk(const char *fmt, va_list args)
{
+ static int log_level_unknown = 1;
+ static char printk_buf[1024];
+
unsigned long flags;
- int printed_len;
+ int printed_len = 0;
+ int this_cpu;
char *p;
- static char printk_buf[1024];
- static int log_level_unknown = 1;
boot_delay_msec();
preempt_disable();
- if (unlikely(oops_in_progress) printk_cpu == smp_processor_id())
- /* If a crash is occurring during printk() on this CPU,
-* make sure we can't deadlock */
- zap_locks();
-
/* This stops the holder of console_sem just where we want him */
raw_local_irq_save(flags);
+ this_cpu = smp_processor_id();
+
+ /*
+* Ouch, printk recursed into itself!
+*/
+ if (unlikely(printk_cpu == this_cpu)) {
+ /*
+* If a crash is occurring during printk() on this CPU,
+* then try to get the crash message out but make sure
+* we can't deadlock. Otherwise just return to avoid the
+* recursion and return - but flag the recursion so that
+* it can be printed at the next appropriate moment:
+*/
+ if (!oops_in_progress) {
+ printk_recursion_bug = 1;
+ goto out_restore_irqs;
+ }
+ zap_locks();
+ }
+
lockdep_off();
spin_lock(logbuf_lock);
- printk_cpu = smp_processor_id();
+ printk_cpu = this_cpu;
+ if (printk_recursion_bug) {
+ printk_recursion_bug = 0;
+ strcpy(printk_buf, printk_recursion_bug_msg);
+ printed_len = sizeof(printk_recursion_bug_msg);
+ }
/* Emit the output into the temporary buffer */
- printed_len = vscnprintf(printk_buf, sizeof(printk_buf), fmt, args);
+ printed_len += vscnprintf(printk_buf + printed_len,
+ sizeof(printk_buf), fmt, args);
/*
* Copy the output into log_buf. If the caller didn't provide
@@ -744,6 +771,7 @@ asmlinkage int vprintk(const char *fmt,
Re: [PATCH] depmod: sort output according to modules.order
On Sat, 2007-12-08 at 03:03 -0500, Jon Masters wrote: On Tue, 2007-12-04 at 22:55 +0900, Tejun Heo wrote: Kbuild now generates and installs modules.order along with modules. This patch updates depmod such that it sorts module list according to the file before generating output files. Modules which aren't on modules.order are put after modules which are ordered by modules.order. Thanks. Please CC me in general on these patches :-) I was planning to also discuss ordering of module aliases entries, since we can have several modules providing the same modalias (this gets even worse on Enterprise Linux distributions, where we might have third party modules providing additional aliases). I guess this ordering is probably better than just a numeric sort, which was the original idea. Actually, this still won't quite solve that problem, because modules not installed in the kernel itself won't have ordering data supplied. Maybe I need to do this, *and* then sort modaliases numerically aswell. Jon. -- 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: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]
On 12/07/2007 06:51 PM, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
thanks for tracking it down. Does the patch below help?
oops, that should be the patch below. Otherwise the watchdog kernel
threads will just loop around.
Ingo
---
kernel/softlockup.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
Index: linux/kernel/softlockup.c
===
--- linux.orig/kernel/softlockup.c
+++ linux/kernel/softlockup.c
@@ -101,7 +101,11 @@ void softlockup_tick(void)
now = get_timestamp(this_cpu);
- /* Warn about unreasonable delays: */
+ /* Wake up the high-prio watchdog task every second: */
+ if (now (touch_timestamp + 1))
+ wake_up_process(per_cpu(watchdog_task, this_cpu));
+
+ /* Warn about unreasonable 10+ seconds delays: */
if (now = (touch_timestamp + softlockup_thresh))
return;
@@ -213,8 +217,9 @@ static int watchdog(void *__bind_cpu)
* debug-printout triggers in softlockup_tick().
*/
while (!kthread_should_stop()) {
+ set_current_state(TASK_INTERRUPTIBLE);
touch_softlockup_watchdog();
- msleep_interruptible(1);
+ schedule();
/*
* Only do the hung-tasks check on one CPU:
Unfortunately no change here.
--
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] depmod: sort output according to modules.order
On Thu, 2007-12-06 at 08:28 +0900, Tejun Heo wrote: As I said, I don't think leaving duplicate lines in a file which will be installed, distributed and used widely is the RTTD. For what it's worth, I changed the module processing in depmod so that it doesn't output duplicate entries. Having duplicates is not the right solution - especially modalias entries that depend entirely upon the file layout on disk when you run depmod against a kernel. Thanks for the ordering patches folks - a good idea! Jon. -- 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] depmod: sort output according to modules.order
On Tue, 2007-12-04 at 22:55 +0900, Tejun Heo wrote: Kbuild now generates and installs modules.order along with modules. This patch updates depmod such that it sorts module list according to the file before generating output files. Modules which aren't on modules.order are put after modules which are ordered by modules.order. Thanks. Please CC me in general on these patches :-) I was planning to also discuss ordering of module aliases entries, since we can have several modules providing the same modalias (this gets even worse on Enterprise Linux distributions, where we might have third party modules providing additional aliases). I guess this ordering is probably better than just a numeric sort, which was the original idea. Jon. -- 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-rc4-mm1 and Very Slow PCMCIA Compact Flash
On Fri, 07 Dec 2007 22:01:33 -0700 Zan Lynx [EMAIL PROTECTED] wrote: On Fri, 2007-12-07 at 15:22 -0800, Andrew Morton wrote: On Fri, 07 Dec 2007 23:09:43 + Zan Lynx [EMAIL PROTECTED] wrote: [cut] Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I only get read rates of 1.6 MB/s. When it used to work in 2.6.20 I got at least 16 MB/s. The card itself is capable of 30+ in the USB-2 reader. [cut] Maybe pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards.patch? Could you try a `patch -R' of the below? From: Alan Cox [EMAIL PROTECTED] Signed-off-by: Alan Cox [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/ata/pata_pcmcia.c | 31 +-- 1 file changed, 17 insertions(+), 14 deletions(-) diff -puN drivers/ata/pata_pcmcia.c~pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards drivers/ata/pata_pcmcia.c [cut] Nope, that did not change anything. It still detects as PIO0 and still runs at 1.6 MB/s. argh. OK. And Linus's current tree is OK, yes? In which case we should be OK for 2.6.24 and I guess we can hope like heck that the dud patch doesn't leak into mainline. Hopefully Alan will get some time to look into it before 2.6.25 opens. looks OK, there's a patch in Jeff's tree pata_pcmcia: Add support for dumb 8bit IDE emulations which could be our guy. I've uploaded two patches, against 2.6.24-rc4: http://userweb.kernel.org/~akpm/zl.with.gz origin.patch + git-libata-all.patch http://userweb.kernel.org/~akpm/zl.without.gz origin.patch + git-libata-all.patch - 5ddcddd4dfeb16a9509dad647f509828d6fee605 It would be great if you could test both. If zl.with is bad and zl.without is good then we know that 5ddcddd4dfeb16a9509dad647f509828d6fee605 caused this problem. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] swap image signature check upon resume
On Fri, Dec 07, 2007 at 09:19:09PM +0100, Rafael J. Wysocki wrote: ... Well, there's a patchset in the current mainline that allows you to use arbitrary (sufficiently new) kernel to load the image and then restore the image kernel. So, you can hibernate 2.6.24-rc3 and use 2.6.24-rc2 to restore it, for example. I'm going to do that for i386 too. right, this is d307c4a8e826c44f9633bd3f7e60d0491e7d885a (Hibernation: Arbitrary boot kernel support - generic code), i should've seen that. What's the status of those bits, from a quick scan it seems they need some rewiring (Kconfig, e.g. CONFIG_ARCH_HIBERNATION_HEADER etc..) and arch-specific save and restore functions? No, this code is fully functional. :-) The arch save and restore functions are in arch/x86/kernel/suspend_64.c . As I said, i386 is not yet supported. nice, holler if you need a tester when you have some prototypes ready. By the way, what do you do when the suspend image header mismatches and it is unsafe to continue booting? Also, there's a freakishly long comment in suspend_64.c, might wanna shorten it: Signed-off-by: Borislav Petkov [EMAIL PROTECTED] diff --git a/arch/x86/kernel/suspend_64.c b/arch/x86/kernel/suspend_64.c index db284ef..0a23e5f 100644 --- a/arch/x86/kernel/suspend_64.c +++ b/arch/x86/kernel/suspend_64.c @@ -118,7 +118,12 @@ void fix_processor_context(void) int cpu = smp_processor_id(); struct tss_struct *t = per_cpu(init_tss, cpu); - set_tss_desc(cpu,t);/* This just modifies memory; should not be necessary. But... This is necessary, because 386 hardware has concept of busy TSS or some similar stupidity. */ + /* +* This just modifies memory; should not be necessary. But... This +* is necessary, because 386 hardware has concept of busy TSS or some +* similar stupidity. +*/ + set_tss_desc(cpu,t); cpu_gdt(cpu)[GDT_ENTRY_TSS].type = 9; @@ -138,7 +143,6 @@ void fix_processor_context(void) loaddebug(current-thread, 6); loaddebug(current-thread, 7); } - } #ifdef CONFIG_HIBERNATION -- Regards/Gruß, Boris. -- 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 guidance
Hi, On Fri, 7 Dec 2007, Al Boldi wrote: Jakub Narebski wrote: Version control system is all about WORKFLOW B, where programmer controls when it is time to commit (and in private repository he/she can then rewrite history to arrive at Perfect patch series[*1*]); something that for example CVS failed at, requiring programmer to do a merge if upstream has any changes when trying to commit. Because WORKFLOW C is transparent, it won't affect other workflows. So you could still use your normal WORKFLOW B in addition to WORKFLOW C, gaining an additional level of version control detail at no extra cost other than the git-engine scratch repository overhead. BTW, is git efficient enough to handle WORKFLOW C? The question is not if git is efficient enough to handle workflow C, but if that worflow is efficient enough to help anybody. Guess what takes me the longest time when committing? The commit message. But it is really helpful, so there is a _point_ in writing one, and there is a _point_ in committing when I do it: it is a point in time where I expect the tree to be in a good shape, to be compilable, and to solve a specific problem which I describe in the commit message. So I absolutely hate this transparency. Git _is_ transparent; it does not affect any of my other tools; they still work very well thankyouverymuch. What your version of transparency would do: destroy bisectability, make an absolute gibberish of the history, and more! Nobody could read the output of git log and form an understanding what was done. Nobody could read the commit message for a certain git blamed line that she tries to make sense of. IOW you would revert the whole meaning of the term Source Code Management. Hth, Dscho -- 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-rc4-git5: Reported regressions from 2.6.23
On Sat, 8 Dec 2007 03:40:49 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: This message contains a list of some regressions from 2.6.23 which have been reported since 2.6.24-rc1 was released and for which there are no fixes in the mainline that I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. ... Subject : snd_hda_intel 2.6.24-rc2 bug: interrupts don't always work on Lenovo X60s Submitter : Roland Dreier [EMAIL PROTECTED] References: http://lkml.org/lkml/2007/11/8/255 http://bugzilla.kernel.org/show_bug.cgi?id=9332 Handled-By: Patch : Takashi had a patch and that has been merged. AFAIK this regression has been fixed and we're left with a new but harmless warning. However Roland reported other problems and it appears that the trail went cold (http://lkml.org/lkml/2007/11/14/251) Ted was hitting some of the same problems but that trail appears to also have gone cold (http://lkml.org/lkml/2007/11/23/17). Guys, can we have a status update on all of this please? -- 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-rc4-git5: Reported regressions from 2.6.23
On Sat, 8 Dec 2007 09:28:15 +0100 Ingo Molnar [EMAIL PROTECTED] wrote:
* Fabio Comolli [EMAIL PROTECTED] wrote:
snip
Subject : Battery shows up twice in kpowersave
Submitter : Rolf Eike Beer [EMAIL PROTECTED]
References : http://bugzilla.kernel.org/show_bug.cgi?id=9494
Handled-By : Alexey Starikovskiy [EMAIL PROTECTED]
Patch :
I don't think that this is a regression: I reported on RedHat bugzilla
when I switched from F7 to F8 and I was using 2.6.23.8 at that time.
It looks to me an HAL regression, but of course I may be wrong :-) as
the reported bisected to a bad commit.
https://bugzilla.redhat.com/show_bug.cgi?id=373041
By the way, I now switched to Fedrora Rawhide with a 2.6.24-rc4-git5
custom kernel and Gnome desktop and the problem is still present, even
with gnome-power-manager.
to me this looks like an ABI regression - utilities should work without
change. Something changed in /sys output that caused HAL to think that
there are two batteries:
Yep. Although HAL is of course a most special case of userspace.
| The output of lshal shows that there are two UDI's with
| info.capabilities = { 'battery' }:
|
| udi = '/org/freedesktop/Hal/devices/acpi_BAT0'
| udi = '/org/freedesktop/Hal/devices/computer_power_supply_0'
whether it's a HAL bug or a kernel bug, the original state should be
restored and it should be worked out without breaking users of older HAL
versions.
breaking users of older HAL versions == breaking machines.
The patch should be reverted. Do we know which one it was?
grumble: way too many times do various system utilities break when i
upgrade the kernel on my laptop. Maybe a new debug mechanism: we should
start fingerprinting the exact /sys and /proc output and enforce that
it's immutable across kernel releases as long as the hardware is
unmodified?
That would be neat. It would need to be executed on a lot of different
machines.
I wonder if there's something sneaky we can do here. Install the script in
/lib/modules/$(uname -r) and then run it from the kernel when the fork
count reaches 1000 ;)
(hey, I've seen worse: /proc files which start with #!/bin/sh)
--
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] mm/mmap: Remove sparse-warning (NULL as 0).
Fixing: CHECK mm/mmap.c mm/mmap.c:1623:29: warning: Using plain integer as NULL pointer mm/mmap.c:1623:29: warning: Using plain integer as NULL pointer mm/mmap.c:1944:29: warning: Using plain integer as NULL pointer Signed-off-by: Richard Knutsson [EMAIL PROTECTED] --- Added by: 8869477a49c3e99def1fcdadd6bbc407fea14b45 (Linus' tree) Compile-tested on i386 with all[yes|mod|no]config. diff --git a/mm/mmap.c b/mm/mmap.c index 15678aa..bfa389f 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1620,7 +1620,7 @@ static inline int expand_downwards(struct vm_area_struct *vma, return -ENOMEM; address = PAGE_MASK; - error = security_file_mmap(0, 0, 0, 0, address, 1); + error = security_file_mmap(NULL, 0, 0, 0, address, 1); if (error) return error; @@ -1941,7 +1941,7 @@ unsigned long do_brk(unsigned long addr, unsigned long len) if (is_hugepage_only_range(mm, addr, len)) return -EINVAL; - error = security_file_mmap(0, 0, 0, 0, addr, 1); + error = security_file_mmap(NULL, 0, 0, 0, addr, 1); if (error) return 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: HTC TyTN || (P4550) violates GPL?? Or maybe Qualcomm itself with MSM7200???
Dne so 8. prosince 2007 Mauricio Mauad Menegaz Filho napsal(a): 2007/12/7, CIJOML [EMAIL PROTECTED]: Hi there, ... Can anybody else confirm this and contact those companies for source codes? It seems that the sources are there: http://www.ertos.nicta.com.au/software/ Mauad Hi Mauad, I haven't checked that, but this is only paravirtualized solution. I am interrested about drivers for MSM chipset which this linux controls and these sources probably doesn't include it. Michal -- 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/
iscsi project page changed
There's a merging news happened two years ago: http://www.open-iscsi.org/ Linux-iSCSI(sfnet) and Open-iSCSI projects merged!(April 11, 2005) http://marc.theaimsgroup.com/?l=linux-kernelm=111327337005048w=2 so the information should change, and there are needs about iscsi documentation under Documentation/scsi/, or just some links to the documents on the website. --- diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index a6676be..3e75b24 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -341,7 +341,7 @@ config ISCSI_TCP The userspace component needed to initialize the driver, documentation, and sample configuration files can be found here: -http://linux-iscsi.sf.net +http://www.open-iscsi.org/ config SGIWD93_SCSI tristate SGI WD93C93 SCSI Driver -- 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] kernel/params.c: Remove sparse-warning (different signedness).
Fixing:
CHECK kernel/params.c
kernel/params.c:329:41: warning: incorrect type in argument 8 (different
signedness)
kernel/params.c:329:41:expected int *num
kernel/params.c:329:41:got unsigned int *
Signed-off-by: Richard Knutsson [EMAIL PROTECTED]
---
Compile-tested on x86 with all[yes|mod|no]config.
Since 'num' is initialized to '0', then only increments, it can/should be
unsigned.
diff --git a/kernel/params.c b/kernel/params.c
index 2a4c514..de1d0c4 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -272,7 +272,7 @@ static int param_array(const char *name,
unsigned int min, unsigned int max,
void *elem, int elemsize,
int (*set)(const char *, struct kernel_param *kp),
- int *num)
+ unsigned int *num)
{
int ret;
struct kernel_param kp;
--
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] depmod: sort output according to modules.order
it doesn't output duplicate entries. Having duplicates is not the right solution - especially modalias entries that depend entirely upon the file layout on disk when you run depmod against a kernel. Thanks for the ordering patches folks - a good idea! And as it happens just what I need for the upcoming pata_legacy module changes -- 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] Fix lguest documentation
On Sat, 8 Dec 2007, Sheela wrote: Share net is not supported , Rusty is an idiot . Signed-off-by: Sheela Sequeira [EMAIL PROTECTED] Reviewed-by: James Morris [EMAIL PROTECTED] - James -- James Morris [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: [PATCH 1/6] indirect: use asmlinkage in i386 syscall table prototype
tor, 06 12 2007 kl. 15:20 -0800, skrev Zach Brown:
call_indirect() was using the wrong calling convention for the system call
handlers. system call handlers would get mixed up arguments.
Signed-off-by: Zach Brown [EMAIL PROTECTED]
diff --git a/include/asm-x86/indirect_32.h b/include/asm-x86/indirect_32.h
index a1b72ac..e3dea8e 100644
--- a/include/asm-x86/indirect_32.h
+++ b/include/asm-x86/indirect_32.h
@@ -15,8 +15,8 @@ struct indirect_registers {
static inline long call_indirect(struct indirect_registers *regs)
{
- extern long (*sys_call_table[]) (__u32, __u32, __u32, __u32, __u32, __u32);
-
+ extern asmlinkage long (*sys_call_table[])(long, long, long,
This should be something like below instead, otherwise gcc wont parse
asmlinkage as being an attribute of the function signature.
extern long (asmlinkage *sys_call_table[])(long, long, long,
I don't now if it has changed with recent gcc versions, this works for
me with 4.2.0.
+long, long, long);
return sys_call_table[INDIRECT_SYSCALL(regs)](regs-ebx, regs-ecx,
regs-edx, regs-esi,
regs-edi, regs-ebp);
Simon Holm Thøgersen
--
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] Fix lguest documentation
Share net is not supported , Rusty is an idiot . Signed-off-by: Sheela Sequeira [EMAIL PROTECTED] diff --git a/Documentation/lguest/lguest.txt b/Documentation/lguest/lguest.txt index 7885ab2..722d4e7 100644 --- a/Documentation/lguest/lguest.txt +++ b/Documentation/lguest/lguest.txt @@ -109,10 +109,6 @@ Running Lguest: See http://linux-net.osdl.org/index.php/Bridge for general information on how to get bridging working. -- You can also create an inter-guest network using - --sharenet=filename: any two guests using the same file are on - the same network. This file is created if it does not exist. - There is a helpful mailing list at http://ozlabs.org/mailman/listinfo/lguest Good luck! -- 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: programs vanish with 2.6.22+
I try that, but it will take a lot of time! Markus fre, 07 12 2007 kl. 23:52 +0100, skrev Markus: Well, now some windows vanished, but no additional messages were produced by kernel. When somebody could tell what I exactly need to do... would be nice. Or a hit, in what direction I should look. Because its really nasty to not being able to use a current kernel. I already rebuild the whole system, as suggested by the gentoo-devs, without success. I could also try to debug/strace/whatever the apps and wait for it to disappear. Just talk to me, I am not able to do this on my own... If you feel like you are able to tell whether a specific kernel version is buggy or not, you might want to try to bisect it. See Documentation/BUG-HUNTING in the sources, and please ask. Simon Holm Thøgersen -- 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: lockdep problem conversion semaphore-mutex (dev-sem)
On Sat, 2007-12-08 at 00:02 +0100, Remy Bohmer wrote: Hello Peter, What specifically is wrong with dev-sem ? Nothing really, other than that they use semaphores to avoid lockdep :-/ I think I know how to annotate this, after Alan Stern explained all the use cases, but I haven't come around to implementing it. Hope to do that soonish. I was looking for an easy semaphore I could convert to a mutex, and I ran into one that was widely spread and interesting, and which seemed quite doable at first sight. So, I started working on it, but was forgotten this discussion, (until Daniel made me remember it this afternoon). So, I (stupid me ;-) ) tried to convert dev-sem... After doing the monkey part of the conversion I can boot the kernel completely on X86 and ARM, and everything works fine, except after enabling lockdep, lockdep starts complaining... Is this the problem you were pointing at? Yeah, one of the interesting nestings :-) I tried debugging it, and I have not found a recursive mutex locking so far, only locking of 2 different mutexes in a row prior to this warning, which IMO should be valid. What is your opinion? Yeah, the locking is all valid afaics, its just that it needs some interesting annotations to make lockdep see it that way. BTW: I attached my patch for dev-sem as I have it now, that generates this lockdep warning ( for if you want to look at it yourself also, so you do not have to do the monkey part yourself anymore ;-) I have a similar patch floating around, but thanks anyway :-) -- 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 pull] x86/hrtimer/acpi fixes
* Fernando Lopez-Lezcano [EMAIL PROTECTED] wrote: On Fri, 2007-12-07 at 20:59 +0100, Ingo Molnar wrote: * Fernando Lopez-Lezcano [EMAIL PROTECTED] wrote: Nope, it doesn't still getting delay and xrun messages galore. Attached: configuration and dmesg output booting with idle=poll, reconfirmed that that makes the delay and xrun messages go away. could you try the rolled up patch of various fixlets, ontop of current -git? (it might even apply to -rc4) It includes some more stuff beyond the ones in the pull request. (still being tested/reviewed) I'll try but it will take me a while to figure git and do a package build of it... if you want to try a vanilla kernel package then pick up the kernel package from Fedora rawhide - this fixlet should show up there within a couple of days, Dave Jones is doing a really nice job of keeping up with latest -git. (and the Fedora kernel has hrtimers and dynticks enabled.) Ingo -- 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: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]
* Jiri Slaby [EMAIL PROTECTED] wrote: Unfortunately no change here. could you try to revert this change: -int softlockup_thresh = 10; +int softlockup_thresh = 60; i.e. change the value of softlockup_thresh back to 10. You should be able to tweak this runtime as well, without patching the kernel: echo 10 /proc/sys/kernel/softlockup_thresh Ingo -- 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] NLM: Add lockd reference counting and clean up lockd startup and shutdown
+ mutex_lock(nlmsvc_mutex);
+ while (atomic_read(nlmsvc_ref) != 0) {
might be better to do the refcounting outside the thread and use the
kthread api, which is something we still need to do for lockd anyway.
--
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: programs vanish with 2.6.22+
On Sat, Dec 08, 2007 at 01:25:21PM +0100, Markus wrote: Well, just tried it. Started a dozen konquerors and attached strace to everyone. When one disapeared, I only got a Process 9246 detached, nothing else is printed or written in the log. Markus Hallo Markus Whenever the connection to the X server is dropped the application using that connection will be terminated by the client library error handler (KDE/Qt/X11). Probably the applications simply drop out of their event loop and terminate, you should see some X11 related error messages in .xsession-errors My guess would be that some of the eye-candy in KDE is using DRI / OpenGL features that might be the cause for mailfunction. I would suggest you start by disabling DRI / AIGLX rendering in your xorg.conf and see if your applications work without all those nifty features. Below you can find some settings to disable AIGLX, DRI and composite rendering. They should be integrated in the configuration sections I quoted. This is not a complete configuration file. Best regards, Patrick --- snip --- Section ServerFlags Option AIGLX false EndSection Section Module Disable dri EndSection Section Extensions Option Composite false EndSection --- snip --- -- 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] NLM: Add lockd reference counting and clean up lockd startup and shutdown
When a lock that a client is blocking on comes free, lockd does this in
nlmsvc_grant_blocked():
nlm_async_call(block-b_call, NLMPROC_GRANTED_MSG, nlmsvc_grant_ops);
the callback from this call is nlmsvc_grant_callback(). That function
does this at the end to wake up lockd:
svc_wake_up(block-b_daemon);
However there is no guarantee that lockd will be up when this happens.
If someone shuts down or restarts lockd before the async call completes,
then the b_daemon pointer will point to freed memory and the kernel
may oops.
I first noticed this on older kernels and had mistakenly thought that
newer kernels weren't susceptible, but that's not correct. There's a bit
of a race to make sure that the nlm_host is bound when the async call is
done, but I can now reproduce this at will on current kernels.
This patch is based on Trond's suggestion to add a new reference counter
to lockd, and only allows lockd to go down when it reaches 0. With this
change, continuing to allow a new lockd to replace one that's still
running will leave the kernel susceptible to the original oops. So the
patch also ensures that only one lockd can be running at a time.
It does this by having lockd take the nlmsvc_mutex when checking the
nlmsvc_ref and holding it until exit if the ref has gone to 0. With
this, there's no reason to have lockd_down wait for lockd to come down,
so it now returns immediately after sending the signal.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
---
fs/lockd/svc.c | 70 +-
fs/lockd/svclock.c |4 ++
include/linux/lockd/lockd.h |1 +
3 files changed, 40 insertions(+), 35 deletions(-)
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index 82e2192..22f3a5d 100644
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -49,12 +49,12 @@ EXPORT_SYMBOL(nlmsvc_ops);
static DEFINE_MUTEX(nlmsvc_mutex);
static unsigned intnlmsvc_users;
static pid_t nlmsvc_pid;
+atomic_t nlmsvc_ref = ATOMIC_INIT(0);
static struct svc_serv *nlmsvc_serv;
intnlmsvc_grace_period;
unsigned long nlmsvc_timeout;
static DECLARE_COMPLETION(lockd_start_done);
-static DECLARE_WAIT_QUEUE_HEAD(lockd_exit);
/*
* These can be set at insmod time (useful for NFS as root filesystem),
@@ -148,13 +148,17 @@ lockd(struct svc_rqst *rqstp)
/*
* The main request loop. We don't terminate until the last
-* NFS mount or NFS daemon has gone away, and we've been sent a
-* signal, or else another process has taken over our job.
+* NFS mount or NFS daemon has gone away, and the nlm_blocked
+* list is empty. The nlmsvc_mutex ensures that we prevent
+* a new lockd from being started before the old lockd is
+* down when lockd is restarted.
*/
- while ((nlmsvc_users || !signalled()) nlmsvc_pid == current-pid) {
+ mutex_lock(nlmsvc_mutex);
+ while (atomic_read(nlmsvc_ref) != 0) {
long timeout = MAX_SCHEDULE_TIMEOUT;
char buf[RPC_MAX_ADDRBUFLEN];
+ mutex_unlock(nlmsvc_mutex);
if (signalled()) {
flush_signals(current);
if (nlmsvc_ops) {
@@ -180,11 +184,11 @@ lockd(struct svc_rqst *rqstp)
*/
err = svc_recv(rqstp, timeout);
if (err == -EAGAIN || err == -EINTR)
- continue;
+ goto again;
if (err 0) {
printk(KERN_WARNING
- lockd: terminating on error %d\n,
- -err);
+ lockd: terminating on error %d\n, -err);
+ mutex_lock(nlmsvc_mutex);
break;
}
@@ -192,24 +196,23 @@ lockd(struct svc_rqst *rqstp)
svc_print_addr(rqstp, buf, sizeof(buf)));
svc_process(rqstp);
+again:
+ mutex_lock(nlmsvc_mutex);
}
- flush_signals(current);
-
/*
-* Check whether there's a new lockd process before
-* shutting down the hosts and clearing the slot.
+* at this point lockd is committed to going down. We hold the
+* nlmsvc_mutex until just before exit to prevent a new one
+* from starting before it's down.
*/
- if (!nlmsvc_pid || current-pid == nlmsvc_pid) {
- if (nlmsvc_ops)
- nlmsvc_invalidate_all();
- nlm_shutdown_hosts();
- nlmsvc_pid = 0;
- nlmsvc_serv = NULL;
- } else
- printk(KERN_DEBUG
- lockd: new process, skipping host shutdown\n);
- wake_up(lockd_exit);
+ flush_signals(current);
+
+ if (nlmsvc_ops)
+ nlmsvc_invalidate_all();
+
Re: programs vanish with 2.6.22+
Well, just tried it. Started a dozen konquerors and attached strace to everyone. When one disapeared, I only got a Process 9246 detached, nothing else is printed or written in the log. Markus On Fri, 7 Dec 2007, Markus wrote: Well, now some windows vanished, but no additional messages were produced by kernel. When somebody could tell what I exactly need to do... would be nice. Or a hit, in what direction I should look. Because its really nasty to not being able to use a current kernel. I already rebuild the whole system, as suggested by the gentoo-devs, without success. I could also try to debug/strace/whatever the apps and wait for it to disappear. Well, you could attach strace to all likely crash candidates like strace -etrace=none -o/tmp/pid.trace -ppid which would at least tell you what signal it caught... good luck Guennadi Just talk to me, I am not able to do this on my own... Markus On Fri, 7 Dec 2007, Markus wrote: Hi again! The memtest ran 14 passes (~10h) without an error. I now have a 2.6.24-rc4 with some debug-options turned on, waiting for something to happen... can I just leave it untill a window disappears or do I need to manually enable something or run some user-space app?! It depends - different options have it differently. Most simple ones are just compile-time, so, you don't have to enable them. Look in help for respective debug-options. Thanks Guennadi --- Guennadi Liakhovetski --- Guennadi Liakhovetski -- 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] ivtv: Some general fixes
Fix warning: Using plain integer as NULL pointer.
Convert 'x y ? x : y' to use min() instead.
Signed-off-by: Richard Knutsson [EMAIL PROTECTED]
Signed-off-by: Hans Verkuil [EMAIL PROTECTED]
---
Compile-tested on i386 with allyesconfig and allmodconfig.
Resend, since the 'Remove a gcc-2.95 requirement'-part is taken away.
Was sent 2007-12-04
ivtv-driver.c |2 +-
ivtv-ioctl.c |2 +-
ivtv-irq.c |4 ++--
ivtv-streams.c |4 ++--
ivtvfb.c |2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-driver.c
b/drivers/media/video/ivtv/ivtv-driver.c
index 6d2dd87..96f340c 100644
--- a/drivers/media/video/ivtv/ivtv-driver.c
+++ b/drivers/media/video/ivtv/ivtv-driver.c
@@ -979,7 +979,7 @@ static int __devinit ivtv_probe(struct pci_dev *dev,
}
itv = kzalloc(sizeof(struct ivtv), GFP_ATOMIC);
- if (itv == 0) {
+ if (itv == NULL) {
spin_unlock(ivtv_cards_lock);
return -ENOMEM;
}
diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c
b/drivers/media/video/ivtv/ivtv-ioctl.c
index fd6826f..24270de 100644
--- a/drivers/media/video/ivtv/ivtv-ioctl.c
+++ b/drivers/media/video/ivtv/ivtv-ioctl.c
@@ -688,7 +688,7 @@ static int ivtv_debug_ioctls(struct file *filp, unsigned
int cmd, void *arg)
ivtv_reset_ir_gpio(itv);
}
if (val 0x02) {
- itv-video_dec_func(itv, cmd, 0);
+ itv-video_dec_func(itv, cmd, NULL);
}
break;
}
diff --git a/drivers/media/video/ivtv/ivtv-irq.c
b/drivers/media/video/ivtv/ivtv-irq.c
index fd1688e..1384615 100644
--- a/drivers/media/video/ivtv/ivtv-irq.c
+++ b/drivers/media/video/ivtv/ivtv-irq.c
@@ -204,7 +204,7 @@ static int stream_enc_dma_append(struct ivtv_stream *s, u32
data[CX2341X_MBOX_MA
s-sg_pending[idx].dst = buf-dma_handle;
s-sg_pending[idx].src = offset;
s-sg_pending[idx].size = s-buf_size;
- buf-bytesused = (size s-buf_size) ? size : s-buf_size;
+ buf-bytesused = min(size, s-buf_size);
buf-dma_xfer_cnt = s-dma_xfer_cnt;
s-q_predma.bytesused += buf-bytesused;
@@ -705,7 +705,7 @@ static void ivtv_irq_dec_data_req(struct ivtv *itv)
s = itv-streams[IVTV_DEC_STREAM_TYPE_YUV];
}
else {
- itv-dma_data_req_size = data[2] = 0x1 ? 0x1 : data[2];
+ itv-dma_data_req_size = min_t(u32, data[2], 0x1);
itv-dma_data_req_offset = data[1];
s = itv-streams[IVTV_DEC_STREAM_TYPE_MPG];
}
diff --git a/drivers/media/video/ivtv/ivtv-streams.c
b/drivers/media/video/ivtv/ivtv-streams.c
index aa03e61..0e9e7d0 100644
--- a/drivers/media/video/ivtv/ivtv-streams.c
+++ b/drivers/media/video/ivtv/ivtv-streams.c
@@ -572,10 +572,10 @@ int ivtv_start_v4l2_encode_stream(struct ivtv_stream *s)
clear_bit(IVTV_F_I_EOS, itv-i_flags);
/* Initialize Digitizer for Capture */
- itv-video_dec_func(itv, VIDIOC_STREAMOFF, 0);
+ itv-video_dec_func(itv, VIDIOC_STREAMOFF, NULL);
ivtv_msleep_timeout(300, 1);
ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0);
- itv-video_dec_func(itv, VIDIOC_STREAMON, 0);
+ itv-video_dec_func(itv, VIDIOC_STREAMON, NULL);
}
/* begin_capture */
diff --git a/drivers/media/video/ivtv/ivtvfb.c
b/drivers/media/video/ivtv/ivtvfb.c
index 52ffd15..f73ce98 100644
--- a/drivers/media/video/ivtv/ivtvfb.c
+++ b/drivers/media/video/ivtv/ivtvfb.c
@@ -1053,7 +1053,7 @@ static int ivtvfb_init_card(struct ivtv *itv)
}
itv-osd_info = kzalloc(sizeof(struct osd_info), GFP_ATOMIC);
- if (itv-osd_info == 0) {
+ if (itv-osd_info == NULL) {
IVTVFB_ERR(Failed to allocate memory for osd_info\n);
return -ENOMEM;
}
--
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: programs vanish with 2.6.22+
On Sat, 8 Dec 2007 13:12:14 +0100 Markus [EMAIL PROTECTED] wrote: I try that, but it will take a lot of time! Markus This problem remembers me something... http://groups.google.com/group/linux.kernel/browse_thread/thread/85859519ffec7dc8/591a0b3a05bd3596?lnk=gstq=konqueror+vanish#591a0b3a05bd3596 Are you the same Markus? (or it's just a coincidence?) It seems the same BUG... -- Paolo Ornati Linux 2.6.24-rc4-g7e1fb765 on x86_64 -- 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] NLM: Add lockd reference counting and clean up lockd startup and shutdown
On Sat, 8 Dec 2007 14:07:47 +
Christoph Hellwig [EMAIL PROTECTED] wrote:
+ mutex_lock(nlmsvc_mutex);
+ while (atomic_read(nlmsvc_ref) != 0) {
might be better to do the refcounting outside the thread and use the
kthread api, which is something we still need to do for lockd anyway.
Currently sending a SIGKILL to lockd tells it to drop all of its locks
without exiting. If we change lockd to use kthreads, will we have to
change that to use a different mechanism?
--
Jeff Layton [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: [PATCH] kbuild: implement modules.order
On Sat, Dec 08, 2007 at 08:59:31AM +0900, Tejun Heo wrote: Adrian Bunk wrote: On Tue, Dec 04, 2007 at 10:49:37PM +0900, Tejun Heo wrote: When multiple built-in modules (especially drivers) provide the same capability, they're prioritized by link order specified by the order listed in Makefile. This implicit ordering is lost for loadable modules. ... What exactly are the drivers you are thinking of? I would rather see us getting away from any link order dependencies. E.g. we might one day want to compile the whole kernel with one gcc call (using --combine -fwhole-program). The following bugzilla triggered this change and I think contains enough discussion on the subject. http://bugzilla.kernel.org/show_bug.cgi?id=8933 Thanks. Thanks, that explains much. And thinking about it, it doesn't seem to add any problems regarding what I have in mind: If we would ever stop having any well-defined link-order for in-kernel code and express everything through initcall levels, we simply must additionally update the modules.order file. tejun cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- 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 fs/dcache.c:595 in 2.4.24rc3-git3 during NFS umount
On Monday 03 December 2007 16:23:58 Andi Kleen wrote: FYI Just saw this on a test system of mine running 2.4.24rc3 (+ some suse patches, but they're not changing anything near this AFAIK) Got it again after rebooting the system. Can this be made a 2.6.24 blocker or something? Admittedly that was with a few suse patches again; I'll double check it happens in a vanilla kernel too although I don't think there is anything touching this area. The system runs autofs and mounts/umounts NFS servers regularly. -Andi [39943.212533] [ cut here ] [39943.221973] kernel BUG at fs/dcache.c:595! [39943.230369] invalid opcode: [1] SMP [39943.238638] last sysfs file: /devices/system/cpu/cpu7/cache/index2/shared_cpu_map [39943.253998] CPU 3 [39943.258283] Modules linked in: nfs lockd nfs_acl sunrpc autofs4 iptable_filter ip_tables ip6table_filter ip6_tables x_tables af_packet ipv6 cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq dm_crypt ext2 ext3 jbd mbcache loop dm_mod e1000 i2c_i801 shpchp container pci_hotplug button iTCO_wdt rtc_cmos rtc_core i2c_core iTCO_vendor_support rtc_lib sr_mod cdrom floppy sg ehci_hcd uhci_hcd sd_mod usbcore edd reiserfs fan aic79xx scsi_transport_spi ata_piix ahci libata scsi_mod thermal processor [39943.351718] Pid: 31869, comm: umount.nfs Tainted: G N 2.6.24-rc4-git3-20071206230004-default #1 [39943.370555] RIP: 0010:[802a64ce] [802a64ce] shrink_dcache_for_umount_subtree+0x16/0x241 [39943.390671] RSP: 0018:8101dc88fe18 EFLAGS: 00010206 [39943.401552] RAX: RBX: 8100840893c0 RCX: [39943.416040] RDX: RSI: 0296 RDI: 8100840893c0 [39943.430504] RBP: 8100084fff20 R08: 81004d0a6850 R09: 0296 [39943.444969] R10: 81004d0a6850 R11: 802f778c R12: 810222439400 [39943.459424] R13: R14: 7fef065cdf00 R15: [39943.473887] FS: 7fef052ad6f0() GS:810226419940() knlGS: [39943.490452] CS: 0010 DS: ES: CR0: 8005003b [39943.502134] CR2: 7f5793a36580 CR3: 00021ee38000 CR4: 06e0 [39943.516599] DR0: DR1: DR2: [39943.531049] DR3: DR6: 0ff0 DR7: 0400 [39943.545507] Process umount.nfs (pid: 31869, threadinfo 8101dc88e000, task 81021ef3b080) [39943.563289] Stack: 0296 810222439400 883e9be0 810222439400 [39943.579846] 802a6728 810222439400 80297e34 [39943.595152] 81004d0a67c0 0017 88401a80 80297f33 [39943.609871] Call Trace: [39943.615566] [802a6728] shrink_dcache_for_umount+0x2f/0x3d [39943.628463] [80297e34] generic_shutdown_super+0x19/0xf1 [39943.641011] [80297f33] kill_anon_super+0x9/0x35 [39943.652193] [883cd1ba] :nfs:nfs_kill_super+0xd/0x16 [39943.664037] [80297fe4] deactivate_super+0x6a/0x83 [39943.675537] [802ab8ab] sys_umount+0x23c/0x24d [39943.686361] [802a5c8a] d_kill+0x40/0x55 [39943.696139] [802a7217] dput+0x26/0x115 [39943.705745] [802970c0] __fput+0x14a/0x179 [39943.715861] [802aabd1] mntput_no_expire+0x1f/0x86 [39943.727375] [802946ea] filp_close+0x5a/0x61 [39943.737853] [8020bfde] system_call+0x7e/0x83 [39943.748495] [39943.751674] [39943.751675] Code: 0f 0b eb fe 48 c7 c7 80 06 63 80 e8 67 75 17 00 48 8b 53 40 [39943.770405] RIP [802a64ce] shrink_dcache_for_umount_subtree+0x16/0x241 [39943.785790] RSP 8101dc88fe18 [82148.423473] JBD: barrier-based sync failed on dm-1 - disabling barriers -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi_wait_scan Kconfig option
Nick Warne schrieb: I am bringing this up again - primarily as I forgot about it after patching my build tree ages ago: http://lkml.org/lkml/2007/10/27/68 Please see the patch I sent some days ago, which does the very same thing: http://marc.info/?l=linux-kernelm=119677244318528w=2 I would extend the help text a bit more to make clear what it really does, since there is not much documentation around. I try not to build a modular kernel, but only have modules ON due to nVidia (sigh). So I was semi-surprised when I saw the scsi_wait_scan module being built again, yet NO WHERE in menuconfig is it present to turn OFF. Even if I hand edit .config, make puts it back again... True... Regards, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 -- 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] Fix lguest documentation
On Saturday 08 December 2007 23:19:58 Sheela wrote: Share net is not supported , Rusty is an idiot . Signed-off-by: Sheela Sequeira [EMAIL PROTECTED] Acked-by: Rusty Russell [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: ICH9 Core2 Duo - kernel crash
Pavol Cvengros wrote: Bill Davidsen wrote: Pavol Cvengros wrote: On Thursday 06 December 2007 21:15:53 Bill Davidsen wrote: Pavol Cvengros wrote: Hello, I am trying LKML to get some help on one linux kernel related problem. Lately we got a machine with new HW from Intel. CPU is Intel Core2 Duo E6850 3GHz with 2GB of RAM. Motherboard is Intel DG33BU with G33 chipset. After long fight with kernel crashes on different things, we figured out that if the multicore is disabled in bios, everything is ok and machine is running good. No kernel crashes no problems, but with one core only. This small table will maybe explain: Cores - kernel - state 2 - nonsmp or smp - crash 1 - smp or nonsmp - ok All crashes have been different (swaper, rcu, irq, init.) or we just got internal gcc compiler error while compiling kernel/glibc/ and the machine was frozen. Please can somebody advise what to do to identify that problem more precisely. (debug kernel options?) Our immpresion - ICH9 ICH9R support in kernel is bad... sorry to say.. I have seen unusual memory behavior under heavy load, in the cases I saw it was heavy DMA load from multiple SCSI controllers, and one case with FFT on the CPU and heavy network load with gigE. Have you run memtest on this hardware? Just a thought, but I see people running Linux on that chipset, if not that particular board. A cheap test even if it shows nothing. Of course it could be a CPU cache issue in that one CPU, although that's unlikely. yes, memtest was running all his tests without problems. The wierd thing is that all kernel crashes we have seen were different (as stated in original mail) The problem with memtest, unless I underestimate it, is that it doesn't use all core and siblings, so it doesn't quite load the memory system the way regular usage would. Needless to say, if this does turn out to be a memory loading issue I don't know of any tools to really test it. I fall back on part swapping, but that only helps if it's the memory DIMM itself. right now that machine has 2 x 1GB DDR2 - 800MHz do you think I should test the machine with only one DDR? (I hope to put there 4GB all together) Well, odd memory problems are rare, did you look for a BIOS update? It could be that the chipset isn't being set properly, and would explain why it might work differently with another BIOS. But if there's nothing else to try, it won't hurt to see if it works differently with only one DDR. -- Bill Davidsen [EMAIL PROTECTED] Woe unto the statesman who makes war without a reason that will still be valid when the war is over... Otto von Bismark -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi_wait_scan Kconfig option
On Sat, 08 Dec 2007 14:11:44 +0100 Clemens Koller [EMAIL PROTECTED] wrote: Nick Warne schrieb: I am bringing this up again - primarily as I forgot about it after patching my build tree ages ago: http://lkml.org/lkml/2007/10/27/68 Subject: Re: Fw: scsi_wait_scan Kconfig option Date: Fri, 7 Dec 2007 12:47:56 -0700 On Fri, Dec 07, 2007 at 07:39:53PM +, Nick Warne wrote: I try not to build a modular kernel, but only have modules ON due to nVidia (sigh). So I was semi-surprised when I saw the scsi_wait_scan module being built again, yet NO WHERE in menuconfig is it present to turn OFF. Even if I hand edit .config, make puts it back again... On Fri, 7 Dec 2007 12:47:56 -0700 Matthew Wilcox [EMAIL PROTECTED] wrote: You have modules on ... which means you might decide to load a scsi driver as a module. Maybe one that isn't part of the source tree. The scsi_wait_scan module is only 1500 bytes. Apart from a sense of ideological purity (odd in someone who chooses to use nVidia rather than, say, nv or nouveau), this really isn't a problem. Please see the patch I sent some days ago, which does the very same thing: http://marc.info/?l=linux-kernelm=119677244318528w=2 True... Well, that's two of us would that like to be able to stop it building :-) Nick -- Free Software Foundation Associate Member 5508 -- 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] PLIP driver: convert killed_timer_sem to completion
PLIP driver: convert the semaphore killed_timer_sem to
a completion
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
--
diff --git a/drivers/net/plip.c b/drivers/net/plip.c
index 57c9866..fee3d7b 100644
--- a/drivers/net/plip.c
+++ b/drivers/net/plip.c
@@ -106,6 +106,7 @@ static const char version[] = NET3 PLIP version
2.4-parport [EMAIL PROTECTED]
#include linux/if_plip.h
#include linux/workqueue.h
#include linux/spinlock.h
+#include linux/completion.h
#include linux/parport.h
#include linux/bitops.h
@@ -114,7 +115,6 @@ static const char version[] = NET3 PLIP version
2.4-parport [EMAIL PROTECTED]
#include asm/system.h
#include asm/irq.h
#include asm/byteorder.h
-#include asm/semaphore.h
/* Maximum number of devices to support. */
#define PLIP_MAX 8
@@ -221,7 +221,7 @@ struct net_local {
int should_relinquish;
spinlock_t lock;
atomic_t kill_timer;
- struct semaphore killed_timer_sem;
+ struct completion killed_timer_cmp;
};
static inline void enable_parport_interrupts (struct net_device *dev)
@@ -385,7 +385,7 @@ plip_timer_bh(struct work_struct *work)
schedule_delayed_work(nl-timer, 1);
}
else {
- up (nl-killed_timer_sem);
+ complete(nl-killed_timer_cmp);
}
}
@@ -1112,9 +1112,9 @@ plip_close(struct net_device *dev)
if (dev-irq == -1)
{
- init_MUTEX_LOCKED (nl-killed_timer_sem);
+ init_completion(nl-killed_timer_cmp);
atomic_set (nl-kill_timer, 1);
- down (nl-killed_timer_sem);
+ wait_for_completion(nl-killed_timer_cmp);
}
#ifdef NOTDEF
--
Matthias Kaehlcke
Linux System Developer
Barcelona
La libertad es como la mañana. Hay quienes esperan dormidos a que
llegue, pero hay quienes desvelan y caminan la noche para alcanzarla
(Subcomandante Marcos)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
--
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] Fix casting on architectures with 32-bit pointers/longs.
tor, 06 12 2007 kl. 15:20 -0800, skrev Zach Brown: The following patches are a substantial refactoring of the syslet code. I'm branding them as the v7 release of the syslet infrastructure, though they represent a signifiant change in focus. My current focus is to see the most fundamental functionality brought to maturity. To me, this means getting a ABI that is used by applications through glibc on x86 and PPC64. Only once that is ready should we distract ourselves with advanced complexity. To that end, this patch series differs from v6 in significant ways: * syslets are initiated by providing syslet arguments to sys_indirect(). * uatoms, threadlets, and the kaio changes are postponed until they can be justified and rebuilt on more complete infrastructure. (I'm not saying these shouldn't or won't be persued. I'm saying that we should get the simplest piece working first.) * the code is clarified and commented, the patches are bisectable and pass checkpatch. The use of sys_indirect() and the move from 'atom's simplified the ABI considerably. I've put a trivial example in a syslet-userspace git tree: git://git.kernel.org/pub/scm/linux/kernel/git/zab/syslets-userspace.git Signed-of-by: Simon Holm Thøgersen [EMAIL PROTECTED] --- diff --git a/basic.c b/basic.c index 418a1a3..5938d85 100644 --- a/basic.c +++ b/basic.c @@ -42,7 +42,7 @@ int main(int argc, char **argv) params.syslet.frame.sp = (u64)(long)memalign(pagesize, pagesize); memset(params, 0, sizeof(params)); - params.syslet.frame.ip = (u64)syslet_return_func; + params.syslet.frame.ip = (u64)(long)syslet_return_func; params.syslet.frame.sp = (u64)(long)memalign(pagesize, pagesize); params.syslet.ring_ptr = (u64)(long)ring; @@ -55,7 +55,7 @@ int main(int argc, char **argv) pid, my_pid); } - params.syslet.frame.ip = (u64)syslet_return_func; + params.syslet.frame.ip = (u64)(long)syslet_return_func; params.syslet.frame.sp = (u64)(long)memalign(pagesize, pagesize); params.syslet.ring_ptr = (u64)(long)ring; params.syslet.caller_data = CALLER_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: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regressions from 2.6.23]
On Sat, Dec 08, 2007 at 10:30:39AM +0100, Ingo Molnar wrote:
* Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Subject : tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52
kmap_atomic_prot()
Submitter : Ingo Molnar [EMAIL PROTECTED]
References : http://lkml.org/lkml/2007/11/29/157
http://bugzilla.kernel.org/show_bug.cgi?id=9497
Handled-By : Matt Mackall [EMAIL PROTECTED]
Patch : http://lkml.org/lkml/2007/11/29/387
Matt, the above bug is still occuring en masse during random bootups:
I was hoping for some discussion about whether it was the best fix.
The current kzalloc thing strikes me as a step backwards for all
allocators. We'd do better to have a single non-inline kzalloc
function rather than an extra branch in the normal kmalloc fast path.
But here's the patch again, with my sign-off:
Avoid calling page allocator with __GFP_ZERO, as we might be in atomic
context and this will make thing unhappy on highmem systems. Instead,
manually zero allocations from the page allocator.
Signed-off-by: Matt Mackall [EMAIL PROTECTED]
diff -r f7edf7226317 mm/slob.c
--- a/mm/slob.c Wed Dec 05 15:57:06 2007 -0600
+++ b/mm/slob.c Wed Dec 05 15:57:51 2007 -0600
@@ -223,6 +231,7 @@ static void *slob_new_page(gfp_t gfp, in
{
void *page;
+ gfp = ~__GFP_ZERO;
#ifdef CONFIG_NUMA
if (node != -1)
page = alloc_pages_node(node, gfp, order);
@@ -457,6 +470,8 @@ void *__kmalloc_node(size_t size, gfp_t
page = virt_to_page(ret);
page-private = size;
}
+ if (unlikely((gfp __GFP_ZERO) ret))
+ memset(ret, 0, size);
return ret;
}
}
--
Mathematics is the supreme nostalgia of our 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: 2.6.24-rc4-git5: Reported regressions from 2.6.23
On Sat, 8 Dec 2007, Andrew Morton wrote: On Sat, 8 Dec 2007 03:40:49 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: This message contains a list of some regressions from 2.6.23 which have been reported since 2.6.24-rc1 was released and for which there are no fixes in the mainline that I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. .. Subject : system hangs after a few minutes Submitter : Marcus Better [EMAIL PROTECTED] References : http://bugzilla.kernel.org/show_bug.cgi?id=9335 Handled-By : Andrew Morton [EMAIL PROTECTED] Alan Stern [EMAIL PROTECTED] Patch : http://bugzilla.kernel.org/attachment.cgi?id=13871action=view This one we have a confirmed fix from Alan but it doesn't appear to be in anyone's tree. An expanded version of that fix is in Greg's queue: http://marc.info/?l=linux-usb-develm=119697043410947w=2 Since he's away until Tuesday, nothing will happen for a few days. However you might want to replace the old fix that got added to -mm. There is a second bug in here, applicable to core x86: Marcus's machine won't boot with nmi_watchdog=1. Alan Stern -- 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] 3W RAID drivers: memset not needed in probe
the memory return from scsi_host_alloc is alloced by kzalloc, which is already zero initilized, so memset not needed. Signed-off-by: Denis Cheng [EMAIL PROTECTED] --- drivers/scsi/3w-9xxx.c |2 -- drivers/scsi/3w-.c |2 -- 2 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c index afb262b..cb28511 100644 --- a/drivers/scsi/3w-9xxx.c +++ b/drivers/scsi/3w-9xxx.c @@ -2028,8 +2028,6 @@ static int __devinit twa_probe(struct pci_dev *pdev, const struct pci_device_id } tw_dev = (TW_Device_Extension *)host-hostdata; - memset(tw_dev, 0, sizeof(TW_Device_Extension)); - /* Save values to device extension */ tw_dev-host = host; tw_dev-tw_pci_dev = pdev; diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c index 59716eb..a8c12d7 100644 --- a/drivers/scsi/3w-.c +++ b/drivers/scsi/3w-.c @@ -2295,8 +2295,6 @@ static int __devinit tw_probe(struct pci_dev *pdev, const struct pci_device_id * } tw_dev = (TW_Device_Extension *)host-hostdata; - memset(tw_dev, 0, sizeof(TW_Device_Extension)); - /* Save values to device extension */ tw_dev-host = host; tw_dev-tw_pci_dev = pdev; -- 1.5.3.4 -- 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] scheduler: fix x86 regression in native_sched_clock
On Saturday 08 December 2007 16:33:27 Ingo Molnar wrote: * Michael Buesch [EMAIL PROTECTED] wrote: On Saturday 08 December 2007 16:13:41 Ingo Molnar wrote: * Mark Lord [EMAIL PROTECTED] wrote: Ingo Molnar wrote: ... thanks. I do get the impression that most of this can/should wait until 2.6.25. The patches look quite dangerous. .. I confess to not really trying hard to understand everything in this thread, but the implication seems to be that this bug might affect udelay() and possibly jiffies ? no, it cannot affect jiffies. (jiffies was a red herring all along) udelay() cannot be affected either - sched_clock() has no effect on udelay(). _But_, when there are TSC problems then tsc based udelay() suffers too so the phenomenons may _seem_ related. What about msleep()? I suspect problems in b43 because of this issue. msleep() returning too early. Is that possible with this bug? i cannot see how. You can verify msleep by running something like this: while :; do time usleep 111000; done you should see a steady stream of: real0m0.113s real0m0.113s real0m0.113s (on an idle system). If it fluctuates, with occasional longer delays, there's some timer problem present. Does the sleeping and timing use different time references? I mean, if it uses the same reference and that reference does fluctuate you won't see it in the result. But anyway, Stefano. Can you test this? -- Greetings Michael. -- 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: Reproducible data corruption with sendfile+vsftp - splice regression?
Francois Romieu wrote: Holger Hoffstaette [EMAIL PROTECTED] : [...] Maybe turning off sendfile or NAPI just lead to random success - so far it really looks like tso on the r8169 is the common cause. TSO on the r8169 is the magic switch but the regression makes imvho more sense from a VM pov: - the corrupted file has the same size as the expected file - the corrupted file exhibits holes which come as a multiple of 4096 bytes (8*4k, 2 places, there may be more) ... That's interesting. I had the those exact same symptoms here with copying data to/from a USB stick recently. But that stick died completely shortly thereafter, so this was written-off as bad hardware. Strange that you see the same symptoms from a different scenario. Probably no relationship there, but .. -- 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] scheduler: fix x86 regression in native_sched_clock
* Mark Lord [EMAIL PROTECTED] wrote: Ingo Molnar wrote: ... thanks. I do get the impression that most of this can/should wait until 2.6.25. The patches look quite dangerous. .. I confess to not really trying hard to understand everything in this thread, but the implication seems to be that this bug might affect udelay() and possibly jiffies ? no, it cannot affect jiffies. (jiffies was a red herring all along) udelay() cannot be affected either - sched_clock() has no effect on udelay(). _But_, when there are TSC problems then tsc based udelay() suffers too so the phenomenons may _seem_ related. If so, then fixing it has to be a *must* for 2.6.24, as otherwise we'll get all sorts of one-in-while odd driver bugs.. like maybe these two for starters: [Bug 9492] 2.6.24: false double-clicks from USB mouse [Bug 9489] 2+ wake-ups/second in 2.6.24 iirc these high rate wakeups happened on 2.6.22 too. Ingo -- 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: lockdep problem conversion semaphore-mutex (dev-sem)
On Sat, 2007-12-08 at 13:16 +0100, Peter Zijlstra wrote: On Sat, 2007-12-08 at 00:02 +0100, Remy Bohmer wrote: Hello Peter, What specifically is wrong with dev-sem ? Nothing really, other than that they use semaphores to avoid lockdep :-/ I think I know how to annotate this, after Alan Stern explained all the use cases, but I haven't come around to implementing it. Hope to do that soonish. I was looking for an easy semaphore I could convert to a mutex, and I ran into one that was widely spread and interesting, and which seemed quite doable at first sight. So, I started working on it, but was forgotten this discussion, (until Daniel made me remember it this afternoon). So, I (stupid me ;-) ) tried to convert dev-sem... After doing the monkey part of the conversion I can boot the kernel completely on X86 and ARM, and everything works fine, except after enabling lockdep, lockdep starts complaining... Is this the problem you were pointing at? Yeah, one of the interesting nestings :-) It must be the locking in __driver_attach(), taking dev-parent-sem then taking dev-sem .. Assuming those are different structures, why does lockdep trigger? Daniel -- 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][AT91] Fix compile error for at91rm9200 in latest git
On Tue, Dec 04, 2007 at 09:14:29AM +0100, Jan Altenberg wrote: Hi all, Your patch looks correct, and seems to be the only obvious chunk that's missing. So, I'll ack it FWIW ... usual policy for these patches is to go through Russell. You can add my Ack for what it's worth. OK, CC'ed Russell and added your Acked-by. Signed-off-by: Jan Altenberg [EMAIL PROTECTED] Acked-by: Andrew Victor [EMAIL PROTECTED] - patch system please. -- 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] iwlwifi3945/4965 - fix rate control algo reference leak
Zhu Yi wrote: On Thu, 2007-12-06 at 12:39 +0300, Cyrill Gorcunov wrote: From: Cyrill Gorcunov [EMAIL PROTECTED] Subject: [PATCH] iwlwifi3945/4965 - fix rate control algo reference leak .. Any chance of getting LEDs support re-added to this driver, perhaps in the 2.6.25 timeframe? With that in there, I could finally switch the machines around here away from the earlier ipw3945 stuff. Thanks -- 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: soft lockup - CPU#1 stuck for 15s! [swapper:0]
On Dec 8, 2007 10:47 AM, Ingo Molnar [EMAIL PROTECTED] wrote: does the patch below help? But the root cause is likely some timer problems - do you get consistent results from: Haven't yet tried the patch - will try a little later. while :; do time usleep 111; done or do these sleeps fluctuate? They seem to fluctuate - not sure if that's supposed to be exact or if below variations are normal - This is when my compiles are running - [EMAIL PROTECTED] ~]$ while :; do time usleep 111; done real0m1.116s user0m0.000s sys 0m0.000s real0m1.112s user0m0.000s sys 0m0.000s real0m1.130s user0m0.000s sys 0m0.004s real0m1.144s user0m0.000s sys 0m0.000s Thanks Parag -- 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: soft lockup - CPU#1 stuck for 15s! [swapper:0]
* Parag Warudkar [EMAIL PROTECTED] wrote: [c0438293] tick_broadcast_oneshot_control+0x10/0xda [c0437ce2] tick_notify+0x1d4/0x2eb [c04281bc] get_next_timer_interrupt+0x143/0x1b4 [c06058a1] notifier_call_chain+0x2a/0x47 [c04345c0] raw_notifier_call_chain+0x17/0x1a [c043781e] clockevents_notify+0x19/0x4f [c0533d23] acpi_idle_enter_simple+0x183/0x1d0 [c058cf03] cpuidle_idle_call+0x53/0x78 [c058ceb0] cpuidle_idle_call+0x0/0x78 [c0402575] cpu_idle+0x97/0xb8 === BUG: soft lockup - CPU#1 stuck for 11s! [vim:3736] does the patch below help? But the root cause is likely some timer problems - do you get consistent results from: while :; do time usleep 111; done or do these sleeps fluctuate? Ingo Index: linux/kernel/sched.c === --- linux.orig/kernel/sched.c +++ linux/kernel/sched.c @@ -774,6 +774,7 @@ void sched_clock_idle_wakeup_event(u64 d struct rq *rq = cpu_rq(smp_processor_id()); u64 now = sched_clock(); + touch_softlockup_watchdog(); rq-idle_clock += delta_ns; /* * Override the previous timestamp and ignore all -- 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] scheduler: fix x86 regression in native_sched_clock
Ingo Molnar wrote: ... thanks. I do get the impression that most of this can/should wait until 2.6.25. The patches look quite dangerous. .. I confess to not really trying hard to understand everything in this thread, but the implication seems to be that this bug might affect udelay() and possibly jiffies ? If so, then fixing it has to be a *must* for 2.6.24, as otherwise we'll get all sorts of one-in-while odd driver bugs.. like maybe these two for starters: [Bug 9492] 2.6.24: false double-clicks from USB mouse [Bug 9489] 2+ wake-ups/second in 2.6.24 Neither of which happens often enough to explain or debug, but either of which *could* be caused by some weird jiffies thing maybe. ??? -- 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] PPP synchronous tty: convert dead_sem to completion
PPP synchronous tty channel driver: convert the semaphore dead_sem to
a completion
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
--
diff --git a/drivers/net/ppp_synctty.c b/drivers/net/ppp_synctty.c
index f0c6a19..f7472c8 100644
--- a/drivers/net/ppp_synctty.c
+++ b/drivers/net/ppp_synctty.c
@@ -42,9 +42,9 @@
#include linux/if_ppp.h
#include linux/ppp_channel.h
#include linux/spinlock.h
+#include linux/completion.h
#include linux/init.h
#include asm/uaccess.h
-#include asm/semaphore.h
#define PPP_VERSION2.4.2
@@ -70,7 +70,7 @@ struct syncppp {
struct tasklet_struct tsk;
atomic_trefcnt;
- struct semaphore dead_sem;
+ struct completion dead_cmp;
struct ppp_channel chan;/* interface to generic ppp layer */
};
@@ -195,7 +195,7 @@ static struct syncppp *sp_get(struct tty_struct *tty)
static void sp_put(struct syncppp *ap)
{
if (atomic_dec_and_test(ap-refcnt))
- up(ap-dead_sem);
+ complete(ap-dead_cmp);
}
/*
@@ -225,7 +225,7 @@ ppp_sync_open(struct tty_struct *tty)
tasklet_init(ap-tsk, ppp_sync_process, (unsigned long) ap);
atomic_set(ap-refcnt, 1);
- init_MUTEX_LOCKED(ap-dead_sem);
+ init_completion(ap-dead_cmp);
ap-chan.private = ap;
ap-chan.ops = sync_ops;
@@ -273,7 +273,7 @@ ppp_sync_close(struct tty_struct *tty)
* by the time it returns.
*/
if (!atomic_dec_and_test(ap-refcnt))
- down(ap-dead_sem);
+ wait_for_completion(ap-dead_cmp);
tasklet_kill(ap-tsk);
ppp_unregister_channel(ap-chan);
--
Matthias Kaehlcke
Linux System Developer
Barcelona
In itself, homosexuality is as limiting as heterosexuality: the
ideal should be to be capable of loving a woman or a man; either,
a human being, without feeling fear, restraint, or obligation
(Simone de Beauvoir)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
--
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 4/4] Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig
Move the instrumentation Kconfig to arch/Kconfig for architecture dependent options - oprofile - kprobes and init/Kconfig for architecture independent options - profiling - markers Remove the Instrumentation Support menu. Everything moves to General setup. Delete the kernel/Kconfig.instrumentation file. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED] CC: Sam Ravnborg [EMAIL PROTECTED] --- arch/Kconfig | 28 arch/alpha/Kconfig |2 - arch/arm/Kconfig |2 - arch/blackfin/Kconfig |2 - arch/cris/Kconfig |2 - arch/frv/Kconfig |2 - arch/h8300/Kconfig |2 - arch/ia64/Kconfig |2 - arch/m32r/Kconfig |2 - arch/m68k/Kconfig |2 - arch/m68knommu/Kconfig |2 - arch/mips/Kconfig |2 - arch/parisc/Kconfig|2 - arch/powerpc/Kconfig |2 - arch/ppc/Kconfig |2 - arch/s390/Kconfig |2 - arch/sh/Kconfig|2 - arch/sparc/Kconfig |2 - arch/sparc64/Kconfig |2 - arch/um/Kconfig|2 - arch/v850/Kconfig |2 - arch/x86/Kconfig |2 - arch/xtensa/Kconfig|2 - init/Kconfig | 12 kernel/Kconfig.instrumentation | 55 - 25 files changed, 40 insertions(+), 99 deletions(-) Index: linux-2.6-lttng.mm/arch/Kconfig === --- linux-2.6-lttng.mm.orig/arch/Kconfig2007-12-08 09:57:15.0 -0500 +++ linux-2.6-lttng.mm/arch/Kconfig 2007-12-08 10:10:53.0 -0500 @@ -1,3 +1,31 @@ # # General architecture dependent options # + +config OPROFILE + tristate OProfile system profiling (EXPERIMENTAL) + depends on PROFILING !UML + depends on HAVE_OPROFILE + help + OProfile is a profiling system capable of profiling the + whole system, include the kernel, kernel modules, libraries, + and applications. + + If unsure, say N. + +config HAVE_OPROFILE + def_bool n + +config KPROBES + bool Kprobes + depends on KALLSYMS MODULES + depends on HAVE_KPROBES + help + Kprobes allows you to trap at almost any kernel address and + execute a callback function. register_kprobe() establishes + a probepoint and specifies the callback. Kprobes is useful + for kernel debugging, non-intrusive instrumentation and testing. + If in doubt, say N. + +config HAVE_KPROBES + def_bool n Index: linux-2.6-lttng.mm/init/Kconfig === --- linux-2.6-lttng.mm.orig/init/Kconfig2007-12-08 09:57:15.0 -0500 +++ linux-2.6-lttng.mm/init/Kconfig 2007-12-08 10:08:17.0 -0500 @@ -701,6 +701,18 @@ config PROC_PAGE_MONITOR /proc/kpagecount, and /proc/kpageflags. Disabling these interfaces will reduce the size of the kernel by approximately 4kb. +config PROFILING + bool Profiling support (EXPERIMENTAL) + help + Say Y here to enable the extended profiling support mechanisms used + by profilers such as OProfile. + +config MARKERS + bool Activate markers + help + Place an empty function call at each marker site. Can be + dynamically changed for a probe function. + source arch/Kconfig endmenu# General setup Index: linux-2.6-lttng.mm/arch/alpha/Kconfig === --- linux-2.6-lttng.mm.orig/arch/alpha/Kconfig 2007-12-08 09:57:56.0 -0500 +++ linux-2.6-lttng.mm/arch/alpha/Kconfig 2007-12-08 10:08:17.0 -0500 @@ -658,8 +658,6 @@ source drivers/Kconfig source fs/Kconfig -source kernel/Kconfig.instrumentation - source arch/alpha/Kconfig.debug # DUMMY_CONSOLE may be defined in drivers/video/console/Kconfig Index: linux-2.6-lttng.mm/arch/arm/Kconfig === --- linux-2.6-lttng.mm.orig/arch/arm/Kconfig2007-12-08 09:57:56.0 -0500 +++ linux-2.6-lttng.mm/arch/arm/Kconfig 2007-12-08 10:08:17.0 -0500 @@ -1077,8 +1077,6 @@ endmenu source fs/Kconfig -source kernel/Kconfig.instrumentation - source arch/arm/Kconfig.debug source security/Kconfig Index: linux-2.6-lttng.mm/arch/blackfin/Kconfig === --- linux-2.6-lttng.mm.orig/arch/blackfin/Kconfig 2007-12-08 09:57:56.0 -0500 +++ linux-2.6-lttng.mm/arch/blackfin/Kconfig2007-12-08 10:08:17.0 -0500 @@ -995,8 +995,6 @@ source drivers/Kconfig source fs/Kconfig -source
Re: soft lockup - CPU#1 stuck for 15s! [swapper:0]
On Dec 7, 2007 9:56 PM, Thomas Gleixner [EMAIL PROTECTED] wrote: This looks pretty much like the problem I was solving yesterday. Parag, can you please try Linus latest and please check whether there is a stack trace with clockevents_program_event on the top in your dmesg. Just booted with latest git and there is no clockevents_program_event in dmesg anywhere. Any way I have enabled CPU_IDLE again and the machine's got to do lot of compiles today. I'll see if the problem reproduces. Thanks Parag -- 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] Kprobes: Indicate kretprobe support in arch/arch/Kconfig
* Andrew Morton ([EMAIL PROTECTED]) wrote: On Tue, 13 Nov 2007 21:17:10 +0530 Ananth N Mavinakayanahalli [EMAIL PROTECTED] wrote: From: Ananth N Mavinakayanahalli [EMAIL PROTECTED] This patch adds CONFIG_ARCH_SUPPORTS_KRETPROBES to the arch/arch/Kconfig file for relevant architectures with kprobes support. This facilitates easy handling of in-kernel modules (like samples/kprobes/kretprobe_example.c) that depend on kretprobes being present in the kernel. This patch depends on Mathieu Desnoyers' Instrumentation menu removal patchset (http://marc.info/?l=linux-kernelm=119496432229633w=2) I didn't merge this because I didn't merge Mathieu's patches because my brain is not large enough to keep up with Mathieu's patches so sparc64 is still busted. Please send fixes against 2.6.24-rc4-mm1? Thanks. I'll resend the instrumentation menu removal patchset against 2.6.24-rc4-mm1 immediately. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the General setup menu. Linus: Should it come with a re-duplication of it's content into each architecture, which was the case previously ? The oprofile and kprobes menu entries were litteraly cut and pasted from one architecture to another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive depends on list-of-archiectures-here might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. [...] The above suggestion is actually not exactly the best way to do it... First the naming.. A quick grep shows following usage today (in Kconfig files) ARCH_HAS51 ARCH_SUPPORTS 4 HAVE_ARCH 7 ARCH_HAS is the clear winner. In the common Kconfig file do: config FOO depends on ARCH_HAS_FOO bool bla bla config ARCH_HAS_FOO def_bool n In the arch specific Kconfig file in a suitable place do: config SUITABLE_OPTION select ARCH_HAS_FOO The naming of ARCH_HAS_ is fixed and shall be: ARCH_HAS_config option it will enable Only a single line added pr. architecture. And we will end up with a (maybe even commented) list of trivial selects. - Yet another update : Moving to HAVE_* now. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED] CC: Sam Ravnborg [EMAIL PROTECTED] --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng.mm/init/Kconfig === --- linux-2.6-lttng.mm.orig/init/Kconfig2007-12-08 09:54:40.0 -0500 +++ linux-2.6-lttng.mm/init/Kconfig 2007-12-08 09:57:15.0 -0500 @@ -701,6 +701,8 @@ config PROC_PAGE_MONITOR /proc/kpagecount, and /proc/kpageflags. Disabling these interfaces will reduce the size of the kernel by approximately 4kb. +source arch/Kconfig + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng.mm/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng.mm/arch/Kconfig 2007-12-08 09:57:15.0 -0500 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- 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 0/4] Instrumentation menu removal, against 2.6.24-rc4-mm1 (mmotm)
Hi Andrew, This time I am taking no chance : The instrumentation menu removal patchset here applies against 2.6.24-rc4-mm1 _and_ against mmotm (dated : stamp-2007-12-05-15-24) without problem. We should hopefully be able to stop racing against other architecture specific fixes done underneath. Please be aware that the following fix : - fix-oprofile-configuration-breakage.patch from MIPS did not show up in your mmotm tree. I guess you just sent it upstream without keeping it in your own tree. I have applied the content of this fix in my patchset (meaning : select HAVE_OPROFILE if !MIPS_MT_SMTC in add-have-oprofile.patch), but I think you might have a reject if you still have this fix-oprofile-configuration-breakage.patch in your local tree but not in mmotm. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- 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: soft lockup - CPU#1 stuck for 15s! [swapper:0]
On Dec 8, 2007 10:10 AM, Parag Warudkar [EMAIL PROTECTED] wrote: On Dec 7, 2007 9:56 PM, Thomas Gleixner [EMAIL PROTECTED] wrote: This looks pretty much like the problem I was solving yesterday. Parag, can you please try Linus latest and please check whether there is a stack trace with clockevents_program_event on the top in your dmesg. Just booted with latest git and there is no clockevents_program_event in dmesg anywhere. Any way I have enabled CPU_IDLE again and the machine's got to do lot of compiles today. I'll see if the problem reproduces. Whoa whoa whoa - this happens left and right with latest Linus +CPU_IDLE. As soon as I start compiling, dmesg starts filling up with - Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #5) EIP: 0060:[c0533d06] EFLAGS: 0202 CPU: 1 EIP is at acpi_idle_enter_simple+0x166/0x1d0 EAX: f7829f88 EBX: 0da1 ECX: 0266 EDX: ESI: EDI: 00042070 EBP: 000412cf ESP: f7829f88 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 CR0: 8005003b CR2: 080ce178 CR3: 00715000 CR4: 06d0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 [c058cf03] cpuidle_idle_call+0x53/0x78 [c058ceb0] cpuidle_idle_call+0x0/0x78 [c0402575] cpu_idle+0x97/0xb8 === BUG: soft lockup - CPU#1 stuck for 11s! [swapper:0] Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #5) EIP: 0060:[c0603eaa] EFLAGS: 0202 CPU: 1 EIP is at _spin_lock_irqsave+0x16/0x27 EAX: c06b4110 EBX: 0001 ECX: f7873808 EDX: 0293 ESI: 0005 EDI: f7873808 EBP: ESP: f7829f10 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 CR0: 8005003b CR2: 080ff4b0 CR3: 37cf5000 CR4: 06d0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 [c0438293] tick_broadcast_oneshot_control+0x10/0xda [c0437ce2] tick_notify+0x1d4/0x2eb [c04281bc] get_next_timer_interrupt+0x143/0x1b4 [c06058a1] notifier_call_chain+0x2a/0x47 [c04345c0] raw_notifier_call_chain+0x17/0x1a [c043781e] clockevents_notify+0x19/0x4f [c0533d23] acpi_idle_enter_simple+0x183/0x1d0 [c058cf03] cpuidle_idle_call+0x53/0x78 [c058ceb0] cpuidle_idle_call+0x0/0x78 [c0402575] cpu_idle+0x97/0xb8 === BUG: soft lockup - CPU#1 stuck for 11s! [vim:3736] Pid: 3736, comm: vim Not tainted (2.6.24-rc4 #5) EIP: 0060:[c060540b] EFLAGS: 0206 CPU: 1 EIP is at do_page_fault+0x117/0x583 EAX: f6ec1380 EBX: 005d0ff4 ECX: 007b EDX: 0003 ESI: f6dd1fb8 EDI: 004c2000 EBP: f149eae0 ESP: f6dd1f70 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: 004c2000 CR3: 3736a000 CR4: 06d0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 [c046d80d] vfs_read+0x105/0x115 [c06052f4] do_page_fault+0x0/0x583 [c06040aa] error_code+0x72/0x78 [c060] netlbl_domhsh_walk+0x94/0xba === BUG: soft lockup - CPU#1 stuck for 11s! [swapper:0] Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #5) EIP: 0060:[c0533d06] EFLAGS: 0202 CPU: 1 EIP is at acpi_idle_enter_simple+0x166/0x1d0 EAX: f7829f88 EBX: 000a ECX: 0266 EDX: ESI: EDI: 008e8c88 EBP: 008e8c7e ESP: f7829f88 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 CR0: 8005003b CR2: 005da044 CR3: 37cf5000 CR4: 06d0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 [c058cf03] cpuidle_idle_call+0x53/0x78 [c058ceb0] cpuidle_idle_call+0x0/0x78 [c0402575] cpu_idle+0x97/0xb8 === BUG: soft lockup - CPU#1 stuck for 22s! [swapper:0] Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #5) EIP: 0060:[c0533d06] EFLAGS: 0206 CPU: 1 EIP is at acpi_idle_enter_simple+0x166/0x1d0 EAX: f7829f88 EBX: 0d9b ECX: 0266 EDX: ESI: EDI: 007d1802 EBP: 007d0a67 ESP: f7829f88 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 CR0: 8005003b CR2: 005da044 CR3: 37cf5000 CR4: 06d0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 [c058cf03] cpuidle_idle_call+0x53/0x78 [c058ceb0] cpuidle_idle_call+0x0/0x78 [c0402575] cpu_idle+0x97/0xb8 === BUG: soft lockup - CPU#1 stuck for 18s! [swapper:0] Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #5) EIP: 0060:[c0533d06] EFLAGS: 0206 CPU: 1 EIP is at acpi_idle_enter_simple+0x166/0x1d0 EAX: f7829f88 EBX: 0da2 ECX: 0266 EDX: ESI: EDI: 00b651f2 EBP: 00b64450 ESP: f7829f88 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 CR0: 8005003b CR2: 005da044 CR3: 37cf5000 CR4: 06d0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 [c058cf03] cpuidle_idle_call+0x53/0x78 [c058ceb0] cpuidle_idle_call+0x0/0x78 [c0402575] cpu_idle+0x97/0xb8 === BUG: soft lockup - CPU#1 stuck for 14s! [swapper:0] Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #5) EIP: 0060:[c0603eaa] EFLAGS: 0202 CPU: 1 EIP is at _spin_lock_irqsave+0x16/0x27 EAX: c06b4110 EBX: 0001 ECX: f7873808 EDX: 0293 ESI:
Re: [PATCH] scheduler: fix x86 regression in native_sched_clock
* Michael Buesch [EMAIL PROTECTED] wrote: On Saturday 08 December 2007 16:13:41 Ingo Molnar wrote: * Mark Lord [EMAIL PROTECTED] wrote: Ingo Molnar wrote: ... thanks. I do get the impression that most of this can/should wait until 2.6.25. The patches look quite dangerous. .. I confess to not really trying hard to understand everything in this thread, but the implication seems to be that this bug might affect udelay() and possibly jiffies ? no, it cannot affect jiffies. (jiffies was a red herring all along) udelay() cannot be affected either - sched_clock() has no effect on udelay(). _But_, when there are TSC problems then tsc based udelay() suffers too so the phenomenons may _seem_ related. What about msleep()? I suspect problems in b43 because of this issue. msleep() returning too early. Is that possible with this bug? i cannot see how. You can verify msleep by running something like this: while :; do time usleep 111000; done you should see a steady stream of: real0m0.113s real0m0.113s real0m0.113s (on an idle system). If it fluctuates, with occasional longer delays, there's some timer problem present. Ingo -- 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: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]
* Jiri Slaby [EMAIL PROTECTED] wrote: On 12/08/2007 09:39 AM, Ingo Molnar wrote: * Jiri Slaby [EMAIL PROTECTED] wrote: Unfortunately no change here. could you try to revert this change: -int softlockup_thresh = 10; +int softlockup_thresh = 60; i.e. change the value of softlockup_thresh back to 10. You should be able to tweak this runtime as well, without patching the kernel: echo 10 /proc/sys/kernel/softlockup_thresh What should have this changed? I can't see any difference. it changes the wakeup frequency of the softlockup thread. i'm wondering why it had no effect now - the new code is in essence a NOP over what we had. Could you send me your current (modified) kernel/softlockup.c code? Ingo -- 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] scheduler: fix x86 regression in native_sched_clock
On Saturday 08 December 2007 16:13:41 Ingo Molnar wrote: * Mark Lord [EMAIL PROTECTED] wrote: Ingo Molnar wrote: ... thanks. I do get the impression that most of this can/should wait until 2.6.25. The patches look quite dangerous. .. I confess to not really trying hard to understand everything in this thread, but the implication seems to be that this bug might affect udelay() and possibly jiffies ? no, it cannot affect jiffies. (jiffies was a red herring all along) udelay() cannot be affected either - sched_clock() has no effect on udelay(). _But_, when there are TSC problems then tsc based udelay() suffers too so the phenomenons may _seem_ related. What about msleep()? I suspect problems in b43 because of this issue. msleep() returning too early. Is that possible with this bug? -- Greetings Michael. -- 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 3/4] Add HAVE_KPROBES
Linus: On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Changelog: Actually, I know I gave this as the magic incantation, but now that I see it, I realize that I should have told you to just use config KPROBES_SUPPORT def_bool y instead, which is a bit denser. We seem to use both kinds of syntax for these things, but this is really what def_bool is there for... - Use HAVE_KPROBES - Use a select - Yet another update : Moving to HAVE_* now. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED] CC: Sam Ravnborg [EMAIL PROTECTED] --- arch/avr32/Kconfig |1 + arch/ia64/Kconfig |1 + arch/powerpc/Kconfig |1 + arch/ppc/Kconfig |1 + arch/s390/Kconfig |1 + arch/sparc64/Kconfig |1 + arch/x86/Kconfig |1 + kernel/Kconfig.instrumentation |5 - 8 files changed, 11 insertions(+), 1 deletion(-) Index: linux-2.6-lttng.mm/arch/avr32/Kconfig === --- linux-2.6-lttng.mm.orig/arch/avr32/Kconfig 2007-12-08 09:57:56.0 -0500 +++ linux-2.6-lttng.mm/arch/avr32/Kconfig 2007-12-08 10:07:28.0 -0500 @@ -11,6 +11,7 @@ config AVR32 # that we usually don't need on AVR32. select EMBEDDED select HAVE_OPROFILE + select HAVE_KPROBES help AVR32 is a high-performance 32-bit RISC microprocessor core, designed for cost-sensitive embedded applications, with particular Index: linux-2.6-lttng.mm/arch/ia64/Kconfig === --- linux-2.6-lttng.mm.orig/arch/ia64/Kconfig 2007-12-08 09:57:56.0 -0500 +++ linux-2.6-lttng.mm/arch/ia64/Kconfig2007-12-08 10:07:28.0 -0500 @@ -16,6 +16,7 @@ config IA64 select PM if (!IA64_HP_SIM) select ARCH_SUPPORTS_MSI select HAVE_OPROFILE + select HAVE_KPROBES default y help The Itanium Processor Family is Intel's 64-bit successor to Index: linux-2.6-lttng.mm/arch/powerpc/Kconfig === --- linux-2.6-lttng.mm.orig/arch/powerpc/Kconfig2007-12-08 09:57:56.0 -0500 +++ linux-2.6-lttng.mm/arch/powerpc/Kconfig 2007-12-08 10:07:28.0 -0500 @@ -80,6 +80,7 @@ config PPC bool default y select HAVE_OPROFILE + select HAVE_KPROBES config EARLY_PRINTK bool Index: linux-2.6-lttng.mm/arch/ppc/Kconfig === --- linux-2.6-lttng.mm.orig/arch/ppc/Kconfig2007-12-08 09:57:56.0 -0500 +++ linux-2.6-lttng.mm/arch/ppc/Kconfig 2007-12-08 10:07:28.0 -0500 @@ -43,6 +43,7 @@ config PPC bool default y select HAVE_OPROFILE + select HAVE_KPROBES config PPC32 bool Index: linux-2.6-lttng.mm/arch/s390/Kconfig === --- linux-2.6-lttng.mm.orig/arch/s390/Kconfig 2007-12-08 09:57:56.0 -0500 +++ linux-2.6-lttng.mm/arch/s390/Kconfig2007-12-08 10:07:28.0 -0500 @@ -52,6 +52,7 @@ mainmenu Linux Kernel Configuration config S390 def_bool y select HAVE_OPROFILE + select HAVE_KPROBES source init/Kconfig Index: linux-2.6-lttng.mm/arch/sparc64/Kconfig === --- linux-2.6-lttng.mm.orig/arch/sparc64/Kconfig2007-12-08 09:57:56.0 -0500 +++ linux-2.6-lttng.mm/arch/sparc64/Kconfig 2007-12-08 10:07:28.0 -0500 @@ -9,6 +9,7 @@ config SPARC bool default y select HAVE_OPROFILE + select HAVE_KPROBES config SPARC64 bool Index: linux-2.6-lttng.mm/kernel/Kconfig.instrumentation === --- linux-2.6-lttng.mm.orig/kernel/Kconfig.instrumentation 2007-12-08 09:59:35.0 -0500 +++ linux-2.6-lttng.mm/kernel/Kconfig.instrumentation 2007-12-08 10:07:28.0 -0500 @@ -35,7 +35,7 @@ config HAVE_OPROFILE config KPROBES bool Kprobes
[patch 2/4] Add HAVE_OPROFILE
Linus: On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Changelog: Actually, I know I gave this as the magic incantation, but now that I see it, I realize that I should have told you to just use config ARCH_SUPPORTS_KPROBES def_bool y instead, which is a bit denser. We seem to use both kinds of syntax for these things, but this is really what def_bool is there for... Changelog : - Moving to HAVE_*. - Add AVR32 oprofile. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED] CC: Sam Ravnborg [EMAIL PROTECTED] CC: Andrew Morton [EMAIL PROTECTED] CC: Haavard Skinnemoen [EMAIL PROTECTED] --- arch/alpha/Kconfig |1 + arch/arm/Kconfig |1 + arch/avr32/Kconfig |1 + arch/blackfin/Kconfig |1 + arch/ia64/Kconfig |1 + arch/m32r/Kconfig |1 + arch/mips/Kconfig |1 + arch/parisc/Kconfig|1 + arch/powerpc/Kconfig |1 + arch/ppc/Kconfig |1 + arch/s390/Kconfig |1 + arch/sh/Kconfig|1 + arch/sparc/Kconfig |1 + arch/sparc64/Kconfig |1 + arch/x86/Kconfig |1 + kernel/Kconfig.instrumentation |5 - 16 files changed, 19 insertions(+), 1 deletion(-) Index: linux-2.6-lttng.mm/kernel/Kconfig.instrumentation === --- linux-2.6-lttng.mm.orig/kernel/Kconfig.instrumentation 2007-12-08 09:53:22.0 -0500 +++ linux-2.6-lttng.mm/kernel/Kconfig.instrumentation 2007-12-08 09:59:35.0 -0500 @@ -21,7 +21,7 @@ config PROFILING config OPROFILE tristate OProfile system profiling (EXPERIMENTAL) depends on PROFILING !UML - depends on ALPHA || ARM || AVR32 || BLACKFIN || X86_32 || IA64 || M32R || MIPS || PARISC || PPC || S390 || SUPERH || SPARC || X86_64 + depends on HAVE_OPROFILE help OProfile is a profiling system capable of profiling the whole system, include the kernel, kernel modules, libraries, @@ -29,6 +29,9 @@ config OPROFILE If unsure, say N. +config HAVE_OPROFILE + def_bool n + config KPROBES bool Kprobes depends on KALLSYMS MODULES Index: linux-2.6-lttng.mm/arch/alpha/Kconfig === --- linux-2.6-lttng.mm.orig/arch/alpha/Kconfig 2007-12-08 09:54:47.0 -0500 +++ linux-2.6-lttng.mm/arch/alpha/Kconfig 2007-12-08 09:57:56.0 -0500 @@ -5,6 +5,7 @@ config ALPHA bool default y + select HAVE_OPROFILE help The Alpha is a 64-bit general-purpose processor designed and marketed by the Digital Equipment Corporation of blessed memory, Index: linux-2.6-lttng.mm/arch/arm/Kconfig === --- linux-2.6-lttng.mm.orig/arch/arm/Kconfig2007-12-08 09:54:47.0 -0500 +++ linux-2.6-lttng.mm/arch/arm/Kconfig 2007-12-08 09:57:56.0 -0500 @@ -10,6 +10,7 @@ config ARM default y select RTC_LIB select SYS_SUPPORTS_APM_EMULATION + select HAVE_OPROFILE help The ARM series is a line of low-power-consumption RISC chip designs licensed by ARM Ltd and targeted at embedded applications and Index: linux-2.6-lttng.mm/arch/blackfin/Kconfig === --- linux-2.6-lttng.mm.orig/arch/blackfin/Kconfig 2007-12-08 09:22:46.0 -0500 +++ linux-2.6-lttng.mm/arch/blackfin/Kconfig2007-12-08 09:57:56.0 -0500 @@ -24,6 +24,7 @@ config RWSEM_XCHGADD_ALGORITHM config BLACKFIN bool default y + select HAVE_OPROFILE config ZONE_DMA bool Index: linux-2.6-lttng.mm/arch/ia64/Kconfig === --- linux-2.6-lttng.mm.orig/arch/ia64/Kconfig 2007-12-08 09:22:46.0 -0500 +++ linux-2.6-lttng.mm/arch/ia64/Kconfig2007-12-08 09:57:56.0 -0500 @@ -15,6 +15,7 @@ config IA64 select ACPI if (!IA64_HP_SIM) select PM if (!IA64_HP_SIM)
Re: [PATCH] scheduler: fix x86 regression in native_sched_clock
* Michael Buesch [EMAIL PROTECTED] wrote: i cannot see how. You can verify msleep by running something like this: while :; do time usleep 111000; done you should see a steady stream of: real0m0.113s real0m0.113s real0m0.113s (on an idle system). If it fluctuates, with occasional longer delays, there's some timer problem present. Does the sleeping and timing use different time references? yes. But the real paranoid can do this from another box: while :; do time ssh testbox usleep 111000; done Ingo -- 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.23-rc3 can't see sd partitions on Alpha
On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote: Kay Sievers wrote: Is the udev daemon (still) running while it fails? Yes, and there's something else I forgot to mention that may be significant... For the bad case, in addition to udevd, ps -ef shows a sh -e /lib/udev/net.agent running with a PPID of 1. This process doesn't exit until I reboot. If this is normal under the circumstances, please disregard. Does SysRq-T show where it hangs? Kay -- 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: scale cyc_2_nsec according to CPU frequency
On Fri, 7 Dec 2007 15:52:06 +0100 Ingo Molnar [EMAIL PROTECTED] wrote: * Guillaume Chazarain [EMAIL PROTECTED] wrote: Le Fri, 7 Dec 2007 14:55:25 +0100, Ingo Molnar [EMAIL PROTECTED] a ??crit : Firstly, we dont need the 'offset' anymore because cpu_clock() maintains offsets itself. Yes, but a lower quality one. __update_rq_clock tries to compensate large jumping clocks with a jiffy resolution, while my offset arranges for a very smooth frequency transition. yes, but that would be easy to fix up via calling sched_clock_idle_wakeup_event(0) when doing a frequency transition, without burdening the normal sched_clock() codepath with the offset. See the attached latest version. can this deal with dual/quad core where the frequency of one core changes if the sofware changes the frequency of the other core? -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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.6.24-rc4] proc: Remove/Fix proc generic d_revalidate
On Dec 7, 2007 11:25 PM, Eric W. Biederman [EMAIL PROTECTED] wrote:
Ultimately to implement /proc perfectly we need an implementation
of d_revalidate because files and directories can be removed behind
the back of the VFS, and d_revalidate is the only way we can let
the VFS know that this has happened.
Unfortunately the linux VFS can not cope with anything in the path
to a mount point going away. So a proper d_revalidate method that
calls d_drop also needs to call have_submounts which is moderately
expensive, so you really don't want a d_revalidate method that
unconditionally calls it, but instead only calls it when the
backing object has really gone away.
proc generic entries only disappear on module_unload (when
not counting the fledgling network namespace) so it is quite rare
that we actually encounter that case and has not actually caused
us real world trouble yet.
So until we get a proper test for keeping dentries in the dcache
fix the current d_revalidate method by completely removing it. This
returns us to the current status quo.
So with CONFIG_NETNS=n things should look as they have always looked.
For CONFIG_NETNS=y things work most of the time but there are a few
rare corner cases that don't behave properly. As the network namespace
is barely present in 2.6.24 this should not be a problem.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
fs/proc/generic.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index 8d49838..6a2fe51 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -374,16 +374,9 @@ static int proc_delete_dentry(struct dentry * dentry)
return 1;
}
-static int proc_revalidate_dentry(struct dentry *dentry, struct nameidata
*nd)
-{
- d_drop(dentry);
- return 0;
-}
-
static struct dentry_operations proc_dentry_operations =
{
.d_delete = proc_delete_dentry,
- .d_revalidate = proc_revalidate_dentry,
};
/*
--
1.5.3.rc6.17.g1911
Confirmed. This patch fixes the problem for me.
Shane
--
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: lockdep problem conversion semaphore-mutex (dev-sem)
On Sat, 2007-12-08 at 18:11 +0100, Peter Zijlstra wrote: It must be the locking in __driver_attach(), taking dev-parent-sem then taking dev-sem .. Assuming those are different structures, why does lockdep trigger? They aren't different, parent is a struct device again. It's different memory tho .. I wasn't sure how to term that .. The locks are in two different memory location so it couldn't be recursive .. I'm only asking for my own understanding .. I don't mind inspecting potentially bad locking .. Daniel -- 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: programs vanish with 2.6.22+
Well, no I am not the same markus. And I found that before, but I thought it was something about cfs and imo that made it into linus-tree in .23 not .22. But I should perhaps try to change my name, perhaps that fixes it -.- Markus PS: am currently doing a bisect, thats really bad: third bisect and the kernel is unusable. On Sat, 8 Dec 2007 13:12:14 +0100 Markus [EMAIL PROTECTED] wrote: I try that, but it will take a lot of time! Markus This problem remembers me something... http://groups.google.com/group/linux.kernel/browse_thread/thread/85859519ffec7dc8/591a0b3a05bd3596?lnk=gstq=konqueror+vanish#591a0b3a05bd3596 Are you the same Markus? (or it's just a coincidence?) It seems the same BUG... -- 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 does reading from /dev/urandom deplete entropy so much?
On Sat, Dec 08, 2007 at 02:37:57AM -0500, Jon Masters wrote: BTW, You may be better off using uuidgen -t to generate the UUID in the smolt RPM, since that will use 12 bits of randomness from /dev/random, plus the MAC, address and timestamp. So even if there is zero randomness in /dev/random, and the time is January 1, 1970, at least the MAC will contribute some uniqueness to the UUID. I haven't checked how uuidgen uses the MAC, but I would suggest that that is not something Fedora should jump at doing - although it would help ensure unique UUIDs, it also contributes to the tinfoil hat responses that usually come up with things like smolt. Huh? What's the concern? All you are submitting is a list of hardware devices in your system. That's hardly anything sensitive - Ted -- 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: lockdep problem conversion semaphore-mutex (dev-sem)
On Sat, 2007-12-08 at 09:06 -0800, Daniel Walker wrote: On Sat, 2007-12-08 at 18:11 +0100, Peter Zijlstra wrote: It must be the locking in __driver_attach(), taking dev-parent-sem then taking dev-sem .. Assuming those are different structures, why does lockdep trigger? They aren't different, parent is a struct device again. It's different memory tho .. I wasn't sure how to term that .. The locks are in two different memory location so it couldn't be recursive .. I'm only asking for my own understanding .. I don't mind inspecting potentially bad locking .. Yeah, it are different lock instances, however by virtue of sharing the same lock init site, they belong to the same lock class. Lockdep works by tracking class dependancies, not instance dependancies. By generalizing to classes it can detect locking errors before they actually occur. -- 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 does reading from /dev/urandom deplete entropy so much?
Theodore Tso wrote: On Sat, Dec 08, 2007 at 02:37:57AM -0500, Jon Masters wrote: BTW, You may be better off using uuidgen -t to generate the UUID in the smolt RPM, since that will use 12 bits of randomness from /dev/random, plus the MAC, address and timestamp. So even if there is zero randomness in /dev/random, and the time is January 1, 1970, at least the MAC will contribute some uniqueness to the UUID. I haven't checked how uuidgen uses the MAC, but I would suggest that that is not something Fedora should jump at doing - although it would help ensure unique UUIDs, it also contributes to the tinfoil hat responses that usually come up with things like smolt. Huh? What's the concern? All you are submitting is a list of hardware devices in your system. That's hardly anything sensitive We actually had a very vocal minority about all of that which ended up putting us in the unfortunate position of generating a random UUID instead of using a hardware UUID from hal :-/ -Mike -- 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: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]
On 12/08/2007 04:24 PM, Ingo Molnar wrote: i'm wondering why it had no effect now - the new code is in essence a NOP over what we had. Maybe a dumb question. Why those changes in process_32.c in the patch and not in process_64.c? -- 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: lockdep problem conversion semaphore-mutex (dev-sem)
On Sat, 2007-12-08 at 08:53 -0800, Daniel Walker wrote: On Sat, 2007-12-08 at 13:16 +0100, Peter Zijlstra wrote: On Sat, 2007-12-08 at 00:02 +0100, Remy Bohmer wrote: Hello Peter, What specifically is wrong with dev-sem ? Nothing really, other than that they use semaphores to avoid lockdep :-/ I think I know how to annotate this, after Alan Stern explained all the use cases, but I haven't come around to implementing it. Hope to do that soonish. I was looking for an easy semaphore I could convert to a mutex, and I ran into one that was widely spread and interesting, and which seemed quite doable at first sight. So, I started working on it, but was forgotten this discussion, (until Daniel made me remember it this afternoon). So, I (stupid me ;-) ) tried to convert dev-sem... After doing the monkey part of the conversion I can boot the kernel completely on X86 and ARM, and everything works fine, except after enabling lockdep, lockdep starts complaining... Is this the problem you were pointing at? Yeah, one of the interesting nestings :-) It must be the locking in __driver_attach(), taking dev-parent-sem then taking dev-sem .. Assuming those are different structures, why does lockdep trigger? They aren't different, parent is a struct device again. -- 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 does reading from /dev/urandom deplete entropy so much?
On Sat, Dec 08, 2007 at 12:32:04PM -0500, Theodore Tso wrote: On Sat, Dec 08, 2007 at 02:37:57AM -0500, Jon Masters wrote: BTW, You may be better off using uuidgen -t to generate the UUID in the smolt RPM, since that will use 12 bits of randomness from /dev/random, plus the MAC, address and timestamp. So even if there is zero randomness in /dev/random, and the time is January 1, 1970, at least the MAC will contribute some uniqueness to the UUID. I haven't checked how uuidgen uses the MAC, but I would suggest that that is not something Fedora should jump at doing - although it would help ensure unique UUIDs, it also contributes to the tinfoil hat responses that usually come up with things like smolt. Huh? What's the concern? All you are submitting is a list of hardware devices in your system. That's hardly anything sensitive Using MAC addresses -does- de-anonymize things though and presumably anonymous collection is a stated goal. -- Mathematics is the supreme nostalgia of our 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: Why does reading from /dev/urandom deplete entropy so much?
On Sat, 2007-12-08 at 12:32 -0500, Theodore Tso wrote: On Sat, Dec 08, 2007 at 02:37:57AM -0500, Jon Masters wrote: BTW, You may be better off using uuidgen -t to generate the UUID in the smolt RPM, since that will use 12 bits of randomness from /dev/random, plus the MAC, address and timestamp. So even if there is zero randomness in /dev/random, and the time is January 1, 1970, at least the MAC will contribute some uniqueness to the UUID. I haven't checked how uuidgen uses the MAC, but I would suggest that that is not something Fedora should jump at doing - although it would help ensure unique UUIDs, it also contributes to the tinfoil hat responses that usually come up with things like smolt. Huh? What's the concern? All you are submitting is a list of hardware devices in your system. That's hardly anything sensitive Right, but the MAC is globally unique (well, that's normally true) so it is an identifiable user characteristic, moreso than just a list of PCI device IDs sitting on a particular bus. It's silly, but there it is. Jon. -- 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 does reading from /dev/urandom deplete entropy so much?
On Sat, 2007-12-08 at 11:43 -0600, Matt Mackall wrote: On Sat, Dec 08, 2007 at 12:32:04PM -0500, Theodore Tso wrote: On Sat, Dec 08, 2007 at 02:37:57AM -0500, Jon Masters wrote: BTW, You may be better off using uuidgen -t to generate the UUID in the smolt RPM, since that will use 12 bits of randomness from /dev/random, plus the MAC, address and timestamp. So even if there is zero randomness in /dev/random, and the time is January 1, 1970, at least the MAC will contribute some uniqueness to the UUID. I haven't checked how uuidgen uses the MAC, but I would suggest that that is not something Fedora should jump at doing - although it would help ensure unique UUIDs, it also contributes to the tinfoil hat responses that usually come up with things like smolt. Huh? What's the concern? All you are submitting is a list of hardware devices in your system. That's hardly anything sensitive Using MAC addresses -does- de-anonymize things though and presumably anonymous collection is a stated goal. Right. And the more I think about it, the more I think the solution is going to be for the smolt server to generate the UUID and tell the client about it. Anything else seems to be based on hope, especially when you're installing via kickstart or similar type of process. Jon. -- 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: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regressions from 2.6.23]
On Sat, 8 Dec 2007, Matt Mackall wrote: Avoid calling page allocator with __GFP_ZERO, as we might be in atomic context and this will make thing unhappy on highmem systems. Instead, manually zero allocations from the page allocator. I think this is fine, but didn't we fix the warning already? Calling page allocators with __GFP_ZERO should be fine, as long as __GFP_HIGHMEM isn't set, and slab/slub/slob/kmalloc cannot use GFP_HIGHMEM *anyway*. But I'll apply it anyway, because it looks obviously correct from the standpoint that the _other_Â slob user already clears the end result explicitly later on, and we simply should never pass down __GFP_ZERO to the actual page allocator. On that note, shouldn't we also do this for slub.c? Christoph? Linus --- mm/slub.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index b9f37cb..9c1d9f3 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -1468,6 +1468,9 @@ static void *__slab_alloc(struct kmem_cache *s, void **object; struct page *new; + /* We handle __GFP_ZERO in the caller */ + gfpflags = ~__GFP_ZERO; + if (!c-page) goto new_slab; -- 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 does reading from /dev/urandom deplete entropy so much?
On Sat, Dec 08, 2007 at 11:33:57AM -0600, Mike McGrath wrote: Huh? What's the concern? All you are submitting is a list of hardware devices in your system. That's hardly anything sensitive We actually had a very vocal minority about all of that which ended up putting us in the unfortunate position of generating a random UUID instead of using a hardware UUID from hal :-/ Tinfoil hat responses indeed! Ok, if those folks are really that crazy, my suggestion then would be to do a ifconfig -a /dev/random before generating the UUID, and/or waiting until you just about to send the first profile, and/or if you don't yet have a UUID, generating it at that very moment. The first will mix in the MAC address into the random pool, which will help guarantee uniqueness, and waiting until just before you send the result will mean it is much more likely that the random pool will have collected some entropy from user I/O, thus making the random UUID not only unique, but also unpredictable. - Ted -- 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 does reading from /dev/urandom deplete entropy so much?
On Sat, 2007-12-08 at 12:49 -0500, Theodore Tso wrote: On Sat, Dec 08, 2007 at 11:33:57AM -0600, Mike McGrath wrote: Huh? What's the concern? All you are submitting is a list of hardware devices in your system. That's hardly anything sensitive We actually had a very vocal minority about all of that which ended up putting us in the unfortunate position of generating a random UUID instead of using a hardware UUID from hal :-/ Tinfoil hat responses indeed! Ok, if those folks are really that crazy, my suggestion then would be to do a ifconfig -a /dev/random before generating the UUID, and/or waiting until you just about to send the first profile, and/or if you don't yet have a UUID, generating it at that very moment. The first will mix in the MAC address into the random pool, which will help guarantee uniqueness, and waiting until just before you send the result will mean it is much more likely that the random pool will have collected some entropy from user I/O, thus making the random UUID not only unique, but also unpredictable. I do like that idea, and it could be combined with the DMI data for the system containing things like asset tracking numbers, etc. Could use HAL to generate a UUID based on hardware IDs and feed that in as entropy ;-) Jon. -- 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/
