Re: [git pull] x86 arch updates for v2.6.25
On Feb 13, 2008 2:26 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Amit Shah <[EMAIL PROTECTED]> wrote: > > > > As far as I remembers, Ubuntu uses klibc in initramfs, right? > > > > > > What version of klibc do you have? There was a bug in klibc that > > > causes such behavior on PIE-randomization-enabled kernels, and has > > > been fixed in klibc-1.45 by commit [1]. Please make sure you have > > > updated klibc version that doesn't contain this bug. > > > > Thanks Jiri. > > so your problem was resolved by an updated klibc version? Yes, it was. I downloaded the sources from the gutsy repo (which is version 1.5) -- Amit Shah http://www.amitshah.net/ -- 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 arch updates for v2.6.25
* Amit Shah <[EMAIL PROTECTED]> wrote: > > As far as I remembers, Ubuntu uses klibc in initramfs, right? > > > > What version of klibc do you have? There was a bug in klibc that > > causes such behavior on PIE-randomization-enabled kernels, and has > > been fixed in klibc-1.45 by commit [1]. Please make sure you have > > updated klibc version that doesn't contain this bug. > > Thanks Jiri. so your problem was resolved by an updated klibc version? 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: [git pull] x86 arch updates for v2.6.25
On Feb 10, 2008 6:00 PM, Jiri Kosina <[EMAIL PROTECTED]> wrote: > On Sat, 9 Feb 2008, Amit Shah wrote: > > > cc503c1b "x86: PIE executable randomization" doesn't boot on my Ubuntu > > Feisty Fawn Intel Core2 system. > > I get numerous segfaults before getting a (initramfs) busybox shell. A > > similar bug was reported much earlier: > > [ please, when you experience a problem and are able to identify the > commit that triggers it, don't forget to CC the author of the commit in > question -- me, in this case ] > > As far as I remembers, Ubuntu uses klibc in initramfs, right? > > What version of klibc do you have? There was a bug in klibc that causes > such behavior on PIE-randomization-enabled kernels, and has been fixed in > klibc-1.45 by commit [1]. Please make sure you have updated klibc version > that doesn't contain this bug. Thanks Jiri. > > [1] > http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=10df6dfb13ffefe716f12136bbc667f18ff64744 > > -- > Jiri Kosina -- Amit Shah http://www.amitshah.net/ -- 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 arch updates for v2.6.25
On Sat, 9 Feb 2008, Amit Shah wrote: > cc503c1b "x86: PIE executable randomization" doesn't boot on my Ubuntu > Feisty Fawn Intel Core2 system. > I get numerous segfaults before getting a (initramfs) busybox shell. A > similar bug was reported much earlier: [ please, when you experience a problem and are able to identify the commit that triggers it, don't forget to CC the author of the commit in question -- me, in this case ] As far as I remembers, Ubuntu uses klibc in initramfs, right? What version of klibc do you have? There was a bug in klibc that causes such behavior on PIE-randomization-enabled kernels, and has been fixed in klibc-1.45 by commit [1]. Please make sure you have updated klibc version that doesn't contain this bug. [1] http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=10df6dfb13ffefe716f12136bbc667f18ff64744 -- Jiri Kosina -- 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 arch updates for v2.6.25
On Jan 30, 2008 6:45 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > - PIE/brk randomization. Not a single regression happened due to this so > far (and it's been in x86.git for months) - it seems exec-shield has > rooted out stuff years ago - but we'll see. Details in the patch. It's > easily revertable in any case. cc503c1b "x86: PIE executable randomization" doesn't boot on my Ubuntu Feisty Fawn Intel Core2 system. I get numerous segfaults before getting a (initramfs) busybox shell. A similar bug was reported much earlier: http://lkml.org/lkml/2007/7/20/421 Sadly, reverting this (or all of the PIE patches) results in a lot of conflicts now with git-revert too failing, mainly in arch/x86/mm/mmap_64.c. -- Amit Shah http://www.amitshah.net/ -- 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][PATCH] KGDB: remove kgdb-own fault handling (was: Re: [git pull] x86 arch updates for v2.6.25)
On Fri, 8 Feb 2008, Jan Kiszka wrote:
>
> Well, let's try it this way: Find below a patch against kgdb.git that
> removes the special fault handling (this wouldn't be the first feature I
> recently removed from kgdb :->). Light testing revealed no obvious
> problems yet.
That is indeed horrible code. No way will I merge anything that has things
like that even in it's *history* (ie somebody needs to re-generate the
tree without code like that - some things should not be allowed to exist).
That said, while just using "probe_kernel_addr()" is certainly much
better, it's still really inefficient. If you actually want to do a "safe
memory copy", then the right way to do that is basically to do
pagefault_disable();
leftover = __copy_from_user_inatomic(dst, src, count);
pagefault_enable();
if (leftover)
handle_the_fact_that_the_copy_didnt_complete();
which should even be reasonably efficient and should work in all contexts
(hardware interrupts disabled, spinlocks held, you name it).
So all those "kgdb_{get|set}_mem()" things seem bogus (they also have
insane calling semantics - return NULL or errptr? Why not just return an
integer error code?
Linus
--
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/
[RFC][PATCH] KGDB: remove kgdb-own fault handling (was: Re: [git pull] x86 arch updates for v2.6.25)
Andi Kleen wrote: >> /me was once wondering as well why kgdb installs a seconds way of >> handling (its own) faults. Jason explained to me that this approach is >> more robust against corruption along the normal fix-up path. > > That's 100% bogus. > >> If you recall the issues (and they are still present), it would be nice >> to have them listed. kgdb suffered a lot from historic cruft, but we >> already remove at least some of it over the last patching rounds. >> Whatever remains should be addressed ASAP. > > I sent Jason a couple of mails last time when he posted (and before that the > previous maintainer when he tried to merge it). All were > fairly "beratungsresistent". > > If you're truly interested i can dig out the mails or do a fresh review. > > Long ago I did a quite clean x86-64 kgdb for Linux 2.4 based on the > old 2.4 stub that dropped in without any strange other hooks > (except for a straight forward change to the serial code). It worked > just fine this way. Well, let's try it this way: Find below a patch against kgdb.git that removes the special fault handling (this wouldn't be the first feature I recently removed from kgdb :->). Light testing revealed no obvious problems yet. Jason, please tell us what problems this could cause. I just dug out the reply you sent me regarding this last year, and you specifically mentioned non-recoverable unaligned accesses by gdb on MIPS. Is this still true? Is there no way to handle this particular arch separately and leave the rest happily with what the kernel already provides? Jan snip As the kernel already provides the infrastructure to carefully access potentially bogus memory locations, kgdb does not need to maintain its own, complex, arch-dependent mechanism. Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]> --- arch/x86/kernel/Makefile |2 arch/x86/kernel/kgdb-jmp_32.S | 74 arch/x86/kernel/kgdb-jmp_64.S | 65 - arch/x86/kernel/kgdb.c|5 - include/asm-x86/kgdb.h|6 -- include/linux/kgdb.h | 27 - kernel/kgdb.c | 125 -- 7 files changed, 16 insertions(+), 288 deletions(-) Index: b/arch/x86/kernel/Makefile === --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -58,7 +58,7 @@ obj-$(CONFIG_MODULES) += module_$(BITS) obj-$(CONFIG_ACPI_SRAT)+= srat_32.o obj-$(CONFIG_EFI) += efi.o efi_$(BITS).o efi_stub_$(BITS).o obj-$(CONFIG_DOUBLEFAULT) += doublefault_32.o -obj-$(CONFIG_KGDB) += kgdb.o kgdb-jmp_$(BITS).o +obj-$(CONFIG_KGDB) += kgdb.o obj-$(CONFIG_VM86) += vm86_32.o obj-$(CONFIG_EARLY_PRINTK) += early_printk.o Index: b/arch/x86/kernel/kgdb-jmp_32.S === --- a/arch/x86/kernel/kgdb-jmp_32.S +++ /dev/null @@ -1,74 +0,0 @@ -/* - * arch/x86/kernel/kgdb-jmp_32.S - * - * Save and restore system registers so that within a limited frame we - * may have a fault and "jump back" to a known safe location. - * - * Author: George Anzinger <[EMAIL PROTECTED]> - * - * Cribbed from glibc, which carries the following: - * Copyright (C) 1996, 1996, 1997, 2000, 2001 Free Software Foundation, Inc. - * Copyright (C) 2005 by MontaVista Software. - * - * This file is licensed under the terms of the GNU General Public License - * version 2. This program as licensed "as is" without any warranty of - * any kind, whether express or implied. - */ - -#include - -#define PCOFF 0 -#define LINKAGE4 /* just the return address */ -#define PTR_SIZE 4 -#define PARMS LINKAGE /* no space for saved regs */ -#define JMPBUF PARMS -#define VALJMPBUF+PTR_SIZE - -#define JB_BX 0 -#define JB_SI 1 -#define JB_DI 2 -#define JB_BP 3 -#define JB_SP 4 -#define JB_PC 5 - -/* This must be called prior to kgdb_fault_longjmp and - * kgdb_fault_longjmp must not be called outside of the context of the - * last call to kgdb_fault_setjmp. - * kgdb_fault_setjmp(int *jmp_buf[6]) - */ -ENTRY(kgdb_fault_setjmp) - movl JMPBUF(%esp), %eax - - /* Save registers. */ - movl%ebx, (JB_BX*4)(%eax) - movl%esi, (JB_SI*4)(%eax) - movl%edi, (JB_DI*4)(%eax) - /* Save SP as it will be after we return. */ - lealJMPBUF(%esp), %ecx - movl%ecx, (JB_SP*4)(%eax) - movlPCOFF(%esp), %ecx /* Save PC we are returning to now. */ - movl%ecx, (JB_PC*4)(%eax) - movl%ebp, (JB_BP*4)(%eax) /* Save caller's frame pointer. */ - - /* Restore state so we can now try the access. */ - movlJMPBUF(%esp), %ecx /* User's jmp_buf in %ecx. */ - /* Save the return address now. */ - movl
remote DMA via FireWire (was Re: [git pull] x86 arch updates for v2.6.25)
Bernhard Kaindl wrote: > Regarding security: > > On the software side: The new fw-ohci driver seems to allow physical DMA only > to devices which pretend to be FireWire disks (it is the specified way to > transfer the data) ... To be precise, firewire-sbp2 tells firewire-ohci to open up the physical response unit (which implements the remote DMA feature) for the target node from when it tries the SBP-2 login until when it completes the SBP-2 logout or the target is plugged out. Let's call it filtered physical DMA. A mode which doesn't require the physical response unit could be implemented in firewire-sbp2, but this would come with a considerable overhead regarding code, runtime CPU usage due to huge interrupt handling load, and additional runtime memory footprint. The older sbp2 driver relies on unfiltered physical DMA, hence is less secure. There can be a mode selected at compile time to run without physical DMA, but that's buggy and implemented in a way which is not portable. The only reason why we don't have an SBP-2 initiator which works without remote DMA is that nobody is bothered enough to either debug that mode in the old driver or implement it in the new driver. Besides, we could rather trivially add filtered physical DMA to the old sbp2/ieee1394/ohci1394 stack but nobody took the time to do this yet either. > With FireWire enabled by the BIOS, a hacker could (in theory) load his > own operating system into the system RAM and boot it ... x86 BIOSes don't initialize OHCI-1394 controllers up to the point that its physical response unit were working remote nodes were granted access to it. Apple's OpenFirmware implements SBP-2 initiator but I don't know if it uses the physical response unit. But this point is moot --- you can boot from SBP-2 targets. -- Stefan Richter -=-==--- --=- -=--- http://arcgraph.de/sr/ -- 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 arch updates for v2.6.25
On Tue, 5 Feb 2008, H. Peter Anvin wrote:
> John Stoffel wrote:
> >
> > Linus> So I'd merge a patch that puts oops information (or the whole
> > Linus> console printout) in the Intel management stuff in a
> > Linus> heartbeat.
> >
> > How about we put in some sort of console logging tool so we can buffer
> > and log the console output better? Currently if I have both a serial
> > and tty console defined, my GDM prompter looses the mouse until I goto
> > the XDMCP chooser and back again.
> > I'm pretty sure it's a GDM problem, since Xdm doesn't have this issue
> > at all. Haven't had time to chase it though.
> >
> > In any case, having some way to log oopses better would be really
> > nice. Not sure how we could do it reliably for suspend/resume needs
> > on laptops without dedicated management hardware like the ILOM stuff
> > on Intel/Sun boxes.
>
> Hm. Dumping oops information plus perhaps even a memory dump to a USB key
> sounds like it would be highly useful - lots of storage capacity, readily
> available, and can be plugged into just about any system.
>
> I don't know if the backdoor debugging mode in EHCI can be used for that.
> Either way, this would have to be done *very* carefully to avoid clobbering
> USB devices not intended for this purpose.
If the machine can be hooked up over FireWire to another Linux box, you can
use the OHCI1394 controller's "physical DMA" feature to get lots if info:
What you need:
- An OHCI1394-compliant (nearly all are) FireWire port in the oopsing system
- A second Linux system (with other tools also other OS) with any FireWire port
- A FireWire cable which connects the two ports (there are two kinds of plugs)
- ftp://ftp.suse.de/private/bk/firewire/tools/firescope-0.2.2.tar.bz2
What you do:
1 - You boot both systems and connect them with the FireWire cable
2 - You initialize FireWire on both systems and ensure that 'physical DMA'
is enabled in the OHCI1394-compliant FireWire controller of the oopsing
machine.
3 - You transfer the System.map of the debugged kernel to the second system.
- Everything after this point does not need the cooperation of the CPU
of the debugged system, the PCI bus needs to be working and unlocked,
but the CPU(s) of the debugged system can otherwise do anything or
nothing at all anymore.
4 - You trigger the oops/crash/hang, but leave the debugged machine turned on.
5 - You install firescope (URL in the list above) on the second machine and
run it for example with:
firescope -A System.map-of-debugged-kernel
6) you press Ctrl-D (this is just one way to do it)
What you get are the contents of the printk buffer containing the messages
which the kernel logged into the in-memory printk buffer (such as oopses)
- directly from the other machine's RAM over remote DMA (which is called
"physical DMA" in FireWire language)
Of course you can put firescope into "auto update mode" and just watch or
log the printk buffer as it gets messages on the remote system - in real time.
--
There is new code in mainline now to debug early boot issues:
If the oops/hang/crash happens early in boot, before the normal ohci1394 kernel
driver can initialize the OHCI1394-compatible controllers on the debugged
system, such as in the ACPI initialisation or so, you can employ my early
initialisation patch for OHCI1394 controllers to get remote access early:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f212ec4b7b4d84290f12c9c0416cdea283bf5f40
It has been committed into mainline (for 2.6.25) with the x86 merge on
January 30 and it contains more documentation on debugging over FireWire.
To to ensure everybody: The code is not compiled by default, and even if
compiled, it runs __only__ when a specific boot parameter is given on boot.
However, the initialization of the ohci1394 driver allows physical DMA to
all FireWire nodes unless it is loaded with phys_dma=0. See the PS of
this mail for more regarding security.
You can also use the new code on debugging suspend/resume from disk/ram:
To debug suspend:
1 - enable the early firewire patch as documentented in the patch
2 - have the second linux system set up and connected on boot already
3 - ensure that no OHIC1394 driver is ever loaded, as suspending as
well as the driver unload would disable the OHCI1394 controller.
4 - suspend the machine to get the oops/hang/crash.
To debug resume from disk:
Nothing add to the above. The new code gets called when the boot kernel
initializes the machine hardware on resume, so you can get access.
To debug resume from ram:
Disable the __init{,data} flags in the patch and insert a call to
init_ohci1394_dma_on_all_controllers()
early on resume, after the registers of PCI cards are accessible.
Testing and submitting that would be the next thing on my todo list for
debugging with firewire, but someone tries
Re: [git pull] x86 arch updates for v2.6.25
> /me was once wondering as well why kgdb installs a seconds way of > handling (its own) faults. Jason explained to me that this approach is > more robust against corruption along the normal fix-up path. That's 100% bogus. > > If you recall the issues (and they are still present), it would be nice > to have them listed. kgdb suffered a lot from historic cruft, but we > already remove at least some of it over the last patching rounds. > Whatever remains should be addressed ASAP. I sent Jason a couple of mails last time when he posted (and before that the previous maintainer when he tried to merge it). All were fairly "beratungsresistent". If you're truly interested i can dig out the mails or do a fresh review. Long ago I did a quite clean x86-64 kgdb for Linux 2.4 based on the old 2.4 stub that dropped in without any strange other hooks (except for a straight forward change to the serial code). It worked just fine this way. -Andi -- 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 arch updates for v2.6.25
Andi Kleen wrote: >> kgdb? Not so interesting. We have many more hard problems happening at >> user sites, not in developer hands. > > The other problem with the current kgdb code is that it has some serious > problems. e.g. it reinvents various kernel interfaces that already > exist -- one example is that it adds new notify_die()s just to reimplement > the standard __ex_table exceptions in a bogus way. /me was once wondering as well why kgdb installs a seconds way of handling (its own) faults. Jason explained to me that this approach is more robust against corruption along the normal fix-up path. Maybe he can elaborate better than I why this is useful (or what real-life bug once encouraged the current design). > Couple of other issues. So even if it was a good idea to merge the > code is not really fully in merge shape anyways. If you recall the issues (and they are still present), it would be nice to have them listed. kgdb suffered a lot from historic cruft, but we already remove at least some of it over the last patching rounds. Whatever remains should be addressed ASAP. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- 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 arch updates for v2.6.25
Linus Torvalds <[EMAIL PROTECTED]> writes: > > So I'd merge a patch that puts oops information (or the whole console > printout) in the Intel management stuff in a heartbeat. That code is > likely much grottier than any kgdb thing will ever be (Intel really > screwed up the interface and made it some insane XML thing), but it's also > fundamentally more important - if it means that normal users can give oops > reports after they happened in X (or, these days, probably more commonly > during suspend/resume) and the machine just died. I agree. Even with XML ugliness that's a fairly important area. > kgdb? Not so interesting. We have many more hard problems happening at > user sites, not in developer hands. The other problem with the current kgdb code is that it has some serious problems. e.g. it reinvents various kernel interfaces that already exist -- one example is that it adds new notify_die()s just to reimplement the standard __ex_table exceptions in a bogus way. Couple of other issues. So even if it was a good idea to merge the code is not really fully in merge shape anyways. -Andi -- 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 arch updates for v2.6.25
Hi Christoph, Christoph Hellwig wrote: > But kgdb traditionally was more than just a simple gdb stub and > contained hooks all over the place for additional functionality. > I don't think all this is a good idea and I'd be against it. > > I'd be really happy to see a common gdb stub with small arch support > that allows attaching gdb to the kernel through various transports. > > Maybe someone is up to do just that? Even the full blown kgdb with > all the hooks would benefit from having the gdb stub already in, > so maybe I could motivate some kgdb developers to do that work? For sure, every small step forward will help. Maybe you could have a look at current kgdb.git at kernel.org and comment on what you would like to see in a first submission round, what kind of hooks, specifically regarding the core, are not yet in an acceptable state, and so forth. We will listen. TiA, Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- 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 arch updates for v2.6.25
On Mon, Feb 04, 2008 at 08:11:03PM -0800, Phil Oester wrote: > On Mon, Feb 04, 2008 at 07:27:53PM -0800, Linus Torvalds wrote: > > kgdb? Not so interesting. We have many more hard problems happening at > > user sites, not in developer hands. > > FWIW, I'm not a fulltime developer by any means, but on occasion > I have fixed a few bugs in the netfilter area of the kernel. > And in almost all cases, I used kgdb in my debugging and testing > of fixes. > > In doing so, it was a bit of a PITA to find/patch kgdb into the > kernel, and having it as a configurable option would have saved > me some time and effort and made the process much smoother. > > So perhaps someone else out there would find it similarly useful, > and the extra time it takes to find/patch/compile kgdb in is > precluding them from participating? Why would we ever want to do > that? Just as a note I find it extremly useful in some case to be able to run gdb on a kernel. As said by Andrew it's less the tradition debugging but more to get a picture of what's going on. But kgdb traditionally was more than just a simple gdb stub and contained hooks all over the place for additional functionality. I don't think all this is a good idea and I'd be against it. I'd be really happy to see a common gdb stub with small arch support that allows attaching gdb to the kernel through various transports. Maybe someone is up to do just that? Even the full blown kgdb with all the hooks would benefit from having the gdb stub already in, so maybe I could motivate some kgdb developers to do that work? -- 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 arch updates for v2.6.25
On Wednesday 06 February 2008 04:08, Jan Kiszka wrote: > While too many people consider a debugger as _the_ tool for kernel > development, which it clearly isn't, it remains a fairly useful > feature, and I don't see any regression, technically or > organizationally, it may introduce to Linux. IMHO, it would be a pity > if kgdb have to remain out off tree and may potentially fall back at > quality levels that many of us had fought with in the past. I do pretty much all my debugging with printk, not just because it is a pain to go find a working kgdb patch, but also because tools like uml make printk style debugging really fast. That said, I often find my development time sinking away into tedious activity like putting in a printk after each line of code, just to find out where some bad thing started going bad. At that point a source level debugger would save me a bunch of time and I would not have to remove the printks afterwards. However, if the time required to patch the kernel with kgdb is more than the time spent putting in prinks then I will just grit my teeth and put in the printks. Never mind that I will end up going through the printk insertion process many times, while only needing to apply the kgdb patch once. Ahem, that is once per kernel version, and I change kernel versions like I change socks (that means "often" for the wags among you.) One thing I like to do with a source level debugger besides debugging is take a walk once through some new algorithm I have implemented. Not because I think there is a bug, but more for the same reason that I like to do a side by side walkthrough of new code with another developer before ever running it. This just provides a different perspective, so that perhaps some little blemishes, inefficiencies and redundancies will show themselves, and the code quality usually improves because of it. Not that this is the only way I review my own code, it is just another way. More ways of reviewing code are better. In this sense, the debugger is like a mechanical friend who always has time available to join in a side by side code review. Regards, 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: [git pull] x86 arch updates for v2.6.25
On Monday 04 February 2008 19:27, Linus Torvalds wrote: > On Tue, 5 Feb 2008, Maxim Levitsky wrote: > > The x86 tree was merged several times, but I don't see kgdb > > included in latest mainline -git. > > > > So just one question, will it be included or no? > > I won't even consider pulling it unless it's offered as a separate > tree, not mixed up with other things. At that point I can give a > look. > > That said, I explained to Ingo why I'm not particularly interested in > it. I don't think that "developer-centric" debugging is really even > remotely our problem, and that I'm personally a lot more interested > in infrastructure that helps normal users give better bug-reports. > And kgdb isn't even _remotely_ it. > > So I'd merge a patch that puts oops information (or the whole console > printout) in the Intel management stuff in a heartbeat. That code is > likely much grottier than any kgdb thing will ever be (Intel really > screwed up the interface and made it some insane XML thing), but it's > also fundamentally more important - if it means that normal users can > give oops reports after they happened in X (or, these days, probably > more commonly during suspend/resume) and the machine just died. > > kgdb? Not so interesting. We have many more hard problems happening > at user sites, not in developer hands. Hi Linus, If you listen carefully you can hear dozens of Linux kernel developers collectively holding their breath and thinking "Maybe Linus will finally merge kgdb". Yes, user bug reports are important. Developer efficiency is important too. Regards, 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: [git pull] x86 arch updates for v2.6.25
Andrew Morton wrote:
> On Mon, 4 Feb 2008 20:11:03 -0800 Phil Oester <[EMAIL PROTECTED]> wrote:
>
>> On Mon, Feb 04, 2008 at 07:27:53PM -0800, Linus Torvalds wrote:
>>> kgdb? Not so interesting. We have many more hard problems happening at
>>> user sites, not in developer hands.
>> FWIW, I'm not a fulltime developer by any means, but on occasion
>> I have fixed a few bugs in the netfilter area of the kernel.
>> And in almost all cases, I used kgdb in my debugging and testing
>
>^^^
>> of fixes.
>
> yup.
I can also underline this - and add the aspect that a kernel debugger
may also nicely serve to explore tricky code paths interactively. This
specifically can lower the entrance barrier to complex kernel subsystems
for new developers/bug hunters.
With the latest changes, now all available through Jason's git repos for
2.6.25, kgdb should be usable again ("Now even more stable than ever!"
;) ). It became much less invasive towards critical code paths during
recent rounds of refactoring, so we can hopefully meet the requirements
for merging it upstream soon (2.6.26?).
While too many people consider a debugger as _the_ tool for kernel
development, which it clearly isn't, it remains a fairly useful feature,
and I don't see any regression, technically or organizationally, it may
introduce to Linux. IMHO, it would be a pity if kgdb have to remain out
off tree and may potentially fall back at quality levels that many of us
had fought with in the past.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--
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 arch updates for v2.6.25
Dear Kernel Maintainers, I am with Phil Oester and Andrew Morton when it comes to getting kgdb into the mainline kernel. I _am_ a full time developer, and when I have to work with Linux kernel code, kgdb makes things a lot easier. I work on many different platforms, with many different operating systems, and there just is not enough time in the day to learn every line of every version of the kernel. kgdb allows me to get in, see what I need, and get out. That being said, if kgdb _does_ become mainline, and people are able to get more visibility into how the kernel works in real time, you will probably see more exploits. This may be the secret reason for reluctance by the powers on high. CC me if you want me to see your reply as I am not on the list. -- Thank you, David Cullen [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: [git pull] x86 arch updates for v2.6.25
John Stoffel wrote: Linus> So I'd merge a patch that puts oops information (or the whole Linus> console printout) in the Intel management stuff in a Linus> heartbeat. How about we put in some sort of console logging tool so we can buffer and log the console output better? Currently if I have both a serial and tty console defined, my GDM prompter looses the mouse until I goto the XDMCP chooser and back again. I'm pretty sure it's a GDM problem, since Xdm doesn't have this issue at all. Haven't had time to chase it though. In any case, having some way to log oopses better would be really nice. Not sure how we could do it reliably for suspend/resume needs on laptops without dedicated management hardware like the ILOM stuff on Intel/Sun boxes. Hm. Dumping oops information plus perhaps even a memory dump to a USB key sounds like it would be highly useful - lots of storage capacity, readily available, and can be plugged into just about any system. I don't know if the backdoor debugging mode in EHCI can be used for that. Either way, this would have to be done *very* carefully to avoid clobbering USB devices not intended for this purpose. -hpa -- 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 arch updates for v2.6.25
> "Linus" == Linus Torvalds <[EMAIL PROTECTED]> writes: Linus> On Tue, 5 Feb 2008, Maxim Levitsky wrote: >> >> The x86 tree was merged several times, but I don't see kgdb included in >> latest mainline -git. >> >> So just one question, will it be included or no? Linus> I won't even consider pulling it unless it's offered as a Linus> separate tree, not mixed up with other things. At that point I Linus> can give a look. Linus> That said, I explained to Ingo why I'm not particularly Linus> interested in it. I don't think that "developer-centric" Linus> debugging is really even remotely our problem, and that I'm Linus> personally a lot more interested in infrastructure that helps Linus> normal users give better bug-reports. And kgdb isn't even Linus> _remotely_ it. Linus> So I'd merge a patch that puts oops information (or the whole Linus> console printout) in the Intel management stuff in a Linus> heartbeat. How about we put in some sort of console logging tool so we can buffer and log the console output better? Currently if I have both a serial and tty console defined, my GDM prompter looses the mouse until I goto the XDMCP chooser and back again. I'm pretty sure it's a GDM problem, since Xdm doesn't have this issue at all. Haven't had time to chase it though. In any case, having some way to log oopses better would be really nice. Not sure how we could do it reliably for suspend/resume needs on laptops without dedicated management hardware like the ILOM stuff on Intel/Sun boxes. Dunno... just viocing my desires... John -- 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 arch updates for v2.6.25
On Mon, 4 Feb 2008 20:11:03 -0800 Phil Oester <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 04, 2008 at 07:27:53PM -0800, Linus Torvalds wrote:
> > kgdb? Not so interesting. We have many more hard problems happening at
> > user sites, not in developer hands.
>
> FWIW, I'm not a fulltime developer by any means, but on occasion
> I have fixed a few bugs in the netfilter area of the kernel.
> And in almost all cases, I used kgdb in my debugging and testing
^^^
> of fixes.
yup.
> In doing so, it was a bit of a PITA to find/patch kgdb into the
> kernel, and having it as a configurable option would have saved
> me some time and effort and made the process much smoother.
>
> So perhaps someone else out there would find it similarly useful,
> and the extra time it takes to find/patch/compile kgdb in is
> precluding them from participating? Why would we ever want to do
> that?
I used kgdb continuously for 4-5 years until it broke. I don't think I
ever used it much for "debugging" as such. I used it more for general
observation of what's going on in the kernel. And for _confirmation_ of
what's going on (ie: testing that the actual state matches the expected
state).
I'd end up doing my development with the assumption that kgdb was present.
One example: rather than putting printks all over the place to ensure that
the right thing was happening at the right time I'd instead add code like
void foo(void)
{
}
...
if (expr)
foo();
then, when the testcase was up and running and in steady state, break in
and put a breakpoint on foo(). Continue, wait for the breakpoint then go
in and observe locals, globals, data structures, etc.
It's hard to describe (and remember!). But the presence of the debugger as
a development (not debugging) tool changes the way you do development a bit.
--
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 arch updates for v2.6.25
On Mon, Feb 04, 2008 at 07:27:53PM -0800, Linus Torvalds wrote: > kgdb? Not so interesting. We have many more hard problems happening at > user sites, not in developer hands. FWIW, I'm not a fulltime developer by any means, but on occasion I have fixed a few bugs in the netfilter area of the kernel. And in almost all cases, I used kgdb in my debugging and testing of fixes. In doing so, it was a bit of a PITA to find/patch kgdb into the kernel, and having it as a configurable option would have saved me some time and effort and made the process much smoother. So perhaps someone else out there would find it similarly useful, and the extra time it takes to find/patch/compile kgdb in is precluding them from participating? Why would we ever want to do that? Phil -- 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 arch updates for v2.6.25
On Tue, 5 Feb 2008, Maxim Levitsky wrote: > > The x86 tree was merged several times, but I don't see kgdb included in > latest mainline -git. > > So just one question, will it be included or no? I won't even consider pulling it unless it's offered as a separate tree, not mixed up with other things. At that point I can give a look. That said, I explained to Ingo why I'm not particularly interested in it. I don't think that "developer-centric" debugging is really even remotely our problem, and that I'm personally a lot more interested in infrastructure that helps normal users give better bug-reports. And kgdb isn't even _remotely_ it. So I'd merge a patch that puts oops information (or the whole console printout) in the Intel management stuff in a heartbeat. That code is likely much grottier than any kgdb thing will ever be (Intel really screwed up the interface and made it some insane XML thing), but it's also fundamentally more important - if it means that normal users can give oops reports after they happened in X (or, these days, probably more commonly during suspend/resume) and the machine just died. kgdb? Not so interesting. We have many more hard problems happening at user sites, not in developer hands. Linus -- 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 arch updates for v2.6.25
On Wednesday, 30 January 2008 03:15:50 Ingo Molnar wrote: > > Linus, please pull the latest x86 git tree from: > > git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git > > Find the shortlog attached below. > > Most of the changes we have described here: > > http://lkml.org/lkml/2008/1/21/230 > > It's not a small merge, it consists of 908 commits from 96 individual > arch/x86 developers (!): > > 671 files changed, 42791 insertions(+), 38967 deletions(-) > > so here are a few highlevel comments as well, in addition to the > shortlog: > > - a number of core files are changed as well: most notably percpu, > debugging details, timers, the firewire remote debugging patch and ... > the KGDB remote debugging stub in kernel/kgdb.c. > > - we tested KGDB to be merge-worthy within the x86 architecture (the > only supported architecture for now) and it's better to have > kernel/kgdb.c than arch/x86/kernel/kgdb.c. The code is reasonably > clean and the user-space exposure is small - the only real exposure is > the decades-old remote GDB protocol. We are happy to fix up any > further cleanliness comments that people might have - but we really > wanted to start somewhere and get this thing moving. As an added > bonus: finally a kernel debugger that can be read without puking too > much ;-) [anyone remember KDB?] > The x86 tree was merged several times, but I don't see kgdb included in latest mainline -git. So just one question, will it be included or no? Best regards, Maxim Levitsky -- 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 arch updates for v2.6.25
Ingo Molnar wrote:
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
What about the breakages caused by commit
a5a19c63f4e55e32dc0bc3d936d7f94793d8b380 (this commit broke the
defconfig compilation on at least avr32, blackfin, sh, sparc and uml)?
the patch below fixes that.
Is it safe, or why did Jeremy state in the commit
"I removed this include to avoid an include cycle"?
that is an x86.git complication alone, and only affects 32-bit PAE: it
is solved by the uninlining patch (that i've queued up to before the
asm-generic/tlb.h revert/fix).
Ingo
->
Subject: x86: uninline __pte_free_tlb() and __pmd_free_tlb()
From: Ingo Molnar <[EMAIL PROTECTED]>
this also removes an include file dependency.
Yes, that simplifies things a lot.
J
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable_32.c | 19 +++
include/asm-x86/pgalloc_32.h | 19 ++-
2 files changed, 21 insertions(+), 17 deletions(-)
Index: linux/arch/x86/mm/pgtable_32.c
===
--- linux.orig/arch/x86/mm/pgtable_32.c
+++ linux/arch/x86/mm/pgtable_32.c
@@ -376,3 +376,22 @@ void check_pgt_cache(void)
{
quicklist_trim(0, pgd_dtor, 25, 16);
}
+
+void __pte_free_tlb(struct mmu_gather *tlb, struct page *pte)
+{
+ paravirt_release_pt(page_to_pfn(pte));
+ tlb_remove_page(tlb, pte);
+}
+
+void __pmd_free_tlb(struct mmu_gather *tlb, pmd_t *pmd)
+{
+ /* This is called just after the pmd has been detached from
+ the pgd, which requires a full tlb flush to be recognized
+ by the CPU. Rather than incurring multiple tlb flushes
+ while the address space is being pulled down, make the tlb
+ gathering machinery do a full flush when we're done. */
+ tlb->fullmm = 1;
+
+ paravirt_release_pd(__pa(pmd) >> PAGE_SHIFT);
+ tlb_remove_page(tlb, virt_to_page(pmd));
+}
Index: linux/include/asm-x86/pgalloc_32.h
===
--- linux.orig/include/asm-x86/pgalloc_32.h
+++ linux/include/asm-x86/pgalloc_32.h
@@ -51,11 +51,7 @@ static inline void pte_free(struct page
}
-static inline void __pte_free_tlb(struct mmu_gather *tlb, struct page *pte)
-{
- paravirt_release_pt(page_to_pfn(pte));
- tlb_remove_page(tlb, pte);
-}
+extern void __pte_free_tlb(struct mmu_gather *tlb, struct page *pte);
#ifdef CONFIG_X86_PAE
/*
@@ -72,18 +68,7 @@ static inline void pmd_free(pmd_t *pmd)
free_page((unsigned long)pmd);
}
-static inline void __pmd_free_tlb(struct mmu_gather *tlb, pmd_t *pmd)
-{
- /* This is called just after the pmd has been detached from
- the pgd, which requires a full tlb flush to be recognized
- by the CPU. Rather than incurring multiple tlb flushes
- while the address space is being pulled down, make the tlb
- gathering machinery do a full flush when we're done. */
- tlb->fullmm = 1;
-
- paravirt_release_pd(__pa(pmd) >> PAGE_SHIFT);
- tlb_remove_page(tlb, virt_to_page(pmd));
-}
+extern void __pmd_free_tlb(struct mmu_gather *tlb, pmd_t *pmd);
static inline void pud_populate(struct mm_struct *mm, pud_t *pudp, pmd_t *pmd)
{
--
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 arch updates for v2.6.25
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > What about the breakages caused by commit
> > > a5a19c63f4e55e32dc0bc3d936d7f94793d8b380 (this commit broke the
> > > defconfig compilation on at least avr32, blackfin, sh, sparc and uml)?
> >
> > the patch below fixes that.
>
> Is it safe, or why did Jeremy state in the commit
> "I removed this include to avoid an include cycle"?
that is an x86.git complication alone, and only affects 32-bit PAE: it
is solved by the uninlining patch (that i've queued up to before the
asm-generic/tlb.h revert/fix).
Ingo
->
Subject: x86: uninline __pte_free_tlb() and __pmd_free_tlb()
From: Ingo Molnar <[EMAIL PROTECTED]>
this also removes an include file dependency.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/x86/mm/pgtable_32.c | 19 +++
include/asm-x86/pgalloc_32.h | 19 ++-
2 files changed, 21 insertions(+), 17 deletions(-)
Index: linux/arch/x86/mm/pgtable_32.c
===
--- linux.orig/arch/x86/mm/pgtable_32.c
+++ linux/arch/x86/mm/pgtable_32.c
@@ -376,3 +376,22 @@ void check_pgt_cache(void)
{
quicklist_trim(0, pgd_dtor, 25, 16);
}
+
+void __pte_free_tlb(struct mmu_gather *tlb, struct page *pte)
+{
+ paravirt_release_pt(page_to_pfn(pte));
+ tlb_remove_page(tlb, pte);
+}
+
+void __pmd_free_tlb(struct mmu_gather *tlb, pmd_t *pmd)
+{
+ /* This is called just after the pmd has been detached from
+ the pgd, which requires a full tlb flush to be recognized
+ by the CPU. Rather than incurring multiple tlb flushes
+ while the address space is being pulled down, make the tlb
+ gathering machinery do a full flush when we're done. */
+ tlb->fullmm = 1;
+
+ paravirt_release_pd(__pa(pmd) >> PAGE_SHIFT);
+ tlb_remove_page(tlb, virt_to_page(pmd));
+}
Index: linux/include/asm-x86/pgalloc_32.h
===
--- linux.orig/include/asm-x86/pgalloc_32.h
+++ linux/include/asm-x86/pgalloc_32.h
@@ -51,11 +51,7 @@ static inline void pte_free(struct page
}
-static inline void __pte_free_tlb(struct mmu_gather *tlb, struct page *pte)
-{
- paravirt_release_pt(page_to_pfn(pte));
- tlb_remove_page(tlb, pte);
-}
+extern void __pte_free_tlb(struct mmu_gather *tlb, struct page *pte);
#ifdef CONFIG_X86_PAE
/*
@@ -72,18 +68,7 @@ static inline void pmd_free(pmd_t *pmd)
free_page((unsigned long)pmd);
}
-static inline void __pmd_free_tlb(struct mmu_gather *tlb, pmd_t *pmd)
-{
- /* This is called just after the pmd has been detached from
- the pgd, which requires a full tlb flush to be recognized
- by the CPU. Rather than incurring multiple tlb flushes
- while the address space is being pulled down, make the tlb
- gathering machinery do a full flush when we're done. */
- tlb->fullmm = 1;
-
- paravirt_release_pd(__pa(pmd) >> PAGE_SHIFT);
- tlb_remove_page(tlb, virt_to_page(pmd));
-}
+extern void __pmd_free_tlb(struct mmu_gather *tlb, pmd_t *pmd);
static inline void pud_populate(struct mm_struct *mm, pud_t *pudp, pmd_t *pmd)
{
--
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 arch updates for v2.6.25
On Thu, Jan 31, 2008 at 05:15:23PM +0100, Ingo Molnar wrote: > >* Adrian Bunk <[EMAIL PROTECTED]> wrote: > >> On Thu, Jan 31, 2008 at 05:00:33PM +0100, Ingo Molnar wrote: >> > >> > * Adrian Bunk <[EMAIL PROTECTED]> wrote: >> > >> > > You tested x86 but broke more than half a dozen other archtectures, >> > > with at least 3 different commits breaking other architectures. >> > >> > Note that all known breakages are fixed in current -git, except for the >> > s390 problem that Martin/Nick posted the fix. >> >> What about the breakages caused by commit >> a5a19c63f4e55e32dc0bc3d936d7f94793d8b380 (this commit broke the >> defconfig compilation on at least avr32, blackfin, sh, sparc and uml)? > >the patch below fixes that. > I just send the same patch[1] minutes ago. ;-) 1. http://lkml.org/lkml/2008/1/31/223 -- 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 arch updates for v2.6.25
On Thu, Jan 31, 2008 at 05:15:23PM +0100, Ingo Molnar wrote: > > * Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > On Thu, Jan 31, 2008 at 05:00:33PM +0100, Ingo Molnar wrote: > > > > > > * Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > > > > You tested x86 but broke more than half a dozen other archtectures, > > > > with at least 3 different commits breaking other architectures. > > > > > > Note that all known breakages are fixed in current -git, except for the > > > s390 problem that Martin/Nick posted the fix. > > > > What about the breakages caused by commit > > a5a19c63f4e55e32dc0bc3d936d7f94793d8b380 (this commit broke the > > defconfig compilation on at least avr32, blackfin, sh, sparc and uml)? > > the patch below fixes that. Is it safe, or why did Jeremy state in the commit "I removed this include to avoid an include cycle"? > Ingo > > --- > include/asm-generic/tlb.h |1 + > 1 file changed, 1 insertion(+) > > Index: linux/include/asm-generic/tlb.h > === > --- linux.orig/include/asm-generic/tlb.h > +++ linux/include/asm-generic/tlb.h > @@ -15,6 +15,7 @@ > > #include > #include > +#include > #include > > /* 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: [git pull] x86 arch updates for v2.6.25
* Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Thu, Jan 31, 2008 at 05:00:33PM +0100, Ingo Molnar wrote: > > > > * Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > > You tested x86 but broke more than half a dozen other archtectures, > > > with at least 3 different commits breaking other architectures. > > > > Note that all known breakages are fixed in current -git, except for the > > s390 problem that Martin/Nick posted the fix. > > What about the breakages caused by commit > a5a19c63f4e55e32dc0bc3d936d7f94793d8b380 (this commit broke the > defconfig compilation on at least avr32, blackfin, sh, sparc and uml)? the patch below fixes that. Ingo --- include/asm-generic/tlb.h |1 + 1 file changed, 1 insertion(+) Index: linux/include/asm-generic/tlb.h === --- linux.orig/include/asm-generic/tlb.h +++ linux/include/asm-generic/tlb.h @@ -15,6 +15,7 @@ #include #include +#include #include /* -- 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 arch updates for v2.6.25
On Thu, Jan 31, 2008 at 05:00:33PM +0100, Ingo Molnar wrote: > > * Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > You tested x86 but broke more than half a dozen other archtectures, > > with at least 3 different commits breaking other architectures. > > Note that all known breakages are fixed in current -git, except for the > s390 problem that Martin/Nick posted the fix. What about the breakages caused by commit a5a19c63f4e55e32dc0bc3d936d7f94793d8b380 (this commit broke the defconfig compilation on at least avr32, blackfin, sh, sparc and uml)? This commit touched two different not x86 specific headers, and both of them broke (different) architectures. > Ingo 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: [git pull] x86 arch updates for v2.6.25
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > Note that all known breakages are fixed in current -git, except for > the s390 problem that Martin/Nick posted the fix. find below the s390 fix. Ingo Index: linux/arch/s390/Kconfig === --- linux.orig/arch/s390/Kconfig +++ linux/arch/s390/Kconfig @@ -22,6 +22,9 @@ config RWSEM_GENERIC_SPINLOCK config RWSEM_XCHGADD_ALGORITHM def_bool y +config GENERIC_LOCKBREAK + def_bool y + config ARCH_HAS_ILOG2_U32 bool default n -- 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 arch updates for v2.6.25
* Adrian Bunk <[EMAIL PROTECTED]> wrote: > You tested x86 but broke more than half a dozen other archtectures, > with at least 3 different commits breaking other architectures. Note that all known breakages are fixed in current -git, except for the s390 problem that Martin/Nick posted the fix. 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: [git pull] x86 arch updates for v2.6.25
On Wed, Jan 30, 2008 at 02:15:50AM +0100, Ingo Molnar wrote: > > Linus, please pull the latest x86 git tree from: > > git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git > > Find the shortlog attached below. > > Most of the changes we have described here: > > http://lkml.org/lkml/2008/1/21/230 > > It's not a small merge, it consists of 908 commits from 96 individual > arch/x86 developers (!): > > 671 files changed, 42791 insertions(+), 38967 deletions(-) > > so here are a few highlevel comments as well, in addition to the > shortlog: >... > the x86.git queue has been built and booted on 32-bit and 64-bit x86, > allnoconfig and allyesconfig [the new CONFIG_SIS190 gigabit driver in > -git has been disabled because it has build failures], including a real > legacy i386 DX 33 MHz system which successfully booted x86.git today. > > In the past few weeks tens of thousands of random x86.git bzImages were > successfully built and booted on a number of (commodity) 32-bit and > 64-bit testsystems - and there has been a fair amount of test exposure > on -mm as well. We expect the x86.git changes to be pretty robust - if > any problems there are they should be under more specialized conditions. > (or due to very recent changes that we kept at the tail of the commit > list) Famous last words? :) >... You tested x86 but broke more than half a dozen other archtectures, with at least 3 different commits breaking other architectures. It now takes a few days until this mess is completely sorted out, and I hope there won't be too many poor souls having to bisect 2.6.25-rc1 regresions on !x86 since this can now become the pure horror. And if people give up trying to bisect 2.6.25 might ship with more regressions. I already said in the past that the x86 tree contains not architecture specific stuff that doesn't belong there, and looking at the following parts of the diffstat, most of it does simply not belong into an "x86 arch update": > b/Makefile|8 > b/arch/arm/Kconfig|5 > b/arch/ia64/Kconfig |8 > b/arch/ia64/ia32/binfmt_elf32.c |3 > b/arch/ia64/kernel/module.c |2 > b/arch/m32r/Kconfig |5 > b/arch/mips/Kconfig |5 > b/arch/mips/kernel/i8253.c| 12 > b/arch/parisc/Kconfig |5 > b/arch/powerpc/Kconfig|8 > b/arch/powerpc/kernel/ptrace.c| 52 > b/arch/sparc64/Kconfig|8 > b/arch/um/kernel/ksyms.c |4 > b/arch/um/sys-i386/signal.c | 50 > b/arch/um/sys-x86_64/signal.c | 70 >... > b/drivers/Makefile|2 > b/drivers/acpi/processor_idle.c | 34 > b/drivers/char/agp/ali-agp.c |2 > b/drivers/char/agp/backend.c |3 > b/drivers/char/agp/generic.c |3 > b/drivers/char/agp/i460-agp.c |2 > b/drivers/char/agp/intel-agp.c| 11 > b/drivers/char/hpet.c | 126 - > b/drivers/char/keyboard.c |1 > b/drivers/char/rtc.c | 253 +- > b/drivers/cpufreq/cpufreq.c |2 > b/drivers/firmware/dmi_scan.c | 26 > b/drivers/ieee1394/Makefile |1 > b/drivers/ieee1394/init_ohci1394_dma.c| 285 ++ > b/drivers/input/mouse/pc110pad.c |7 > b/drivers/kvm/svm.c |2 > b/drivers/kvm/vmx.c |8 > b/drivers/lguest/x86/core.c |4 > b/drivers/pnp/pnpbios/bioscalls.c |5 > b/drivers/serial/8250.c | 52 > b/drivers/serial/8250_kgdb.c | 558 + > b/drivers/serial/Kconfig |2 > b/drivers/serial/Makefile |1 > b/drivers/serial/serial_core.c| 24 > b/drivers/video/vermilion/vermilion.c | 15 > b/fs/Kconfig.binfmt |4 > b/fs/Makefile |1 > b/fs/aio.c|2 > b/fs/binfmt_elf.c | 677 -- > b/fs/compat_binfmt_elf.c | 131 + > b/fs/jbd/checkpoint.c |3 > b/fs/jbd/commit.c |2 > b/fs/jbd2/checkpoint.c|3 > b/fs/jbd2/commit.c|2 > b/include/acpi/reboot.h |9 > b/include/asm-alpha/agp.h |1 > b/include/asm-generic/bug.h | 17 > b/
