[sorry if this is a duplicate, looks like my first post did not make it to lkml] Fix stat.h to not use __i386__, but use BITS_PER_LONG. The UML architecture in turn includes this file. This helps resolve one build failure in the current UML code Before the fix, the failure was In file included from init/do_mounts.c:19: init/do_mounts.h: In function 'bstat': init/do_mounts.h:25: error: storage size of 'stat' isn't known init/do_mounts.h:25: warning: unused variable 'stat' init/do_mounts.h:33...

Need to check if the host is a PCI one before reading IDE_ALTSTATUS_REG. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/ide-iops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: b/drivers/ide/ide-iops.c =================================================================== --- a/drivers/ide/ide-iops.c +++ b/drivers/ide/ide-iops.c @@ -455,7 +455,7 @@ int drive_is_ready (ide_drive_t *drive) * an interrupt with another pci card/device. We ...

It is a win if the branch cannot be effectively predicted, i.e. if the outcome is essentially random, as may occur with data-dependent conditionals. I've seen a doubling of performance on one workload using a predicated instruction instead of a branch on newer Xeons in such a case. I suspect that if branch prediction fails often, the data dependency created by the cmov, etc. is less expensive than the pipeline flush required by mispredicts.. -- Robert Hancock Saskatoon, SK, Canada ...

I think Greg doesn't like it, even though we don't have an alternative at this point... Jesse -

blk_rq_map_sg doesn't initialize sg->dma_address/length to zero anymore. Some low level drivers reuse sg lists without initializing so IOMMUs might get non-zero dma_address/length. If map_sg fails, we need pass the number of the mapped entries to gart_unmap_sg. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> --- arch/x86/kernel/pci-gart_64.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_6...

I like compiling my own kernel it's just a pain doing it the first So how do distro's figure out which driver to use? Isn't it a matter It about ease of use, look at the new core2 architecture, if your gcc is new enough there is a march=core2 else you use an older flag Same with the new cell architecture you use cell if your using gcc 4.3 alpha or 930 if it's not that new. What I'm saying is sometimes GCC or the Kernel is better at making these decisions or at least make it easier Mike ...

Adds a new 'interleave_over_allowed' option to cpusets. When a task with an MPOL_INTERLEAVE memory policy is attached to a cpuset with this option set, the interleaved nodemask becomes the cpuset's mems_allowed. When the cpuset's mems_allowed changes, the interleaved nodemask for all tasks with MPOL_INTERLEAVE memory policies is also updated to be the new mems_allowed nodemask. This allows applications to specify that they want to interleave over all nodes that they are allowed to access. This ...

Every MPOL_INTERLEAVE policy is a custom policy that the application has setup. If you don't use cpusets at all, the nodemask you pass to set_mempolicy() with MPOL_INTERLEAVE is static and won't change without the application's knowledge. It has full control over the nodemask that it desires to interleave over. The problem occurs when you add cpusets into the mix and permit the allowed nodes to change without knowledge to the application. Right now, a simple remap is done so if the car...

Well, sending SCSI patches to the kernel mailing list but not to This patch is too simplistic. ide-cd.c:ide_cdrom_drive_status() looks to be a reasonable implementation. However, the worry is that GET_EVENT_NOTIFICATION is a MMC command; devices not conforming to MMC won't support it. In theory, they should just return ILLEGAL_REQUEST, but USB devices have been known to crash when given commands they don't understand. How widely tested has this been (if it's been in Gentoo since 2004, then it...

It would depend on how the BIOS programmed the memory controllers. For 32-bit (and lots of device) compatibility, a memory hole is required below 4 GB. Not all memory controllers can remap memory in the 3-4 GB range above the 4 GB memory; I'm not sure if that varies with the different Opteron processors. Also, if you run a 32-bit distribution, you need to have HIGHMEM_64G enabled in the kernel. -hpa -

It shouldn't, AFAICS. Greetings, Rafael -

BUG: unable to handle kernel NULL pointer dereference<1>BUG: unable to handle kernel NULL pointer dereference at virtual address 00000054 printing eip: c025c099 *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: tcp_diag inet_diag cls_u32 cls_fw sch_sfq sch_htb xt_mac xt_limit xt_multiport xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nfnetlink xt_MARK iptable_mangle iptable_filter ip_tables x_tables button ac battery ipv6 dm_snapshot dm_mirror dm_mod loop iTCO_wdt pcspkr rtc...

This series kill the old i386 and x86_64 directories. The relevant files are moved and adapted and Kconfig.debug was consolidated (thanks to Randy). I had to modify both the top-lvel Makefile and the kconfig Makefile to accomplish this. It was done in such a way that it is trivial for other archs to use the same mechanism should they have the need. To solve the defconfig issue (i386 and x86_64 cannot share one) the arch/x86/configs/ directory were introduced. This has been used by other archs f...

Hi Linus. This patch serie kill the old i386 and x86_64 directories. Introducing a few trivial changes in top-level Makefile and kconfig Makefile allows us to move all files to arch/x86/ where they belong. Kay Sievers hit a bug in the first patch-set - this is now fixed and the updated patch set is uploaded to my x86.git tree. Build tested on both i386 and x86_64. I test builded a few other archs just to check that I did not break them. Shortlog: Randy Dunlap (1): x86: unification o...

Hey Sam, I get this after a simple pull from your tree and a: make clean; make: LD init/built-in.o LD .tmp_vmlinux1 arch/x86/kernel/head_64.o: In function `early_idt_handler': (.text.head+0x1e5): undefined reference to `early_printk' arch/x86/kernel/head64.o: In function `x86_64_start_kernel': head64.c:(.init.text+0xa8): undefined reference to `early_printk' arch/x86/kernel/built-in.o: In function `early_panic': (.text+0x9c07): undefined reference to `early_printk' arch/x86/mm/buil...

From c54efdb8c66e1850be60e2320a24c96957c87372 Mon Sep 17 00:00:00 2001 From: Sam Ravnborg <sam@ravnborg.org> Date: Thu, 25 Oct 2007 21:06:56 +0200 Subject: [PATCH] x86: kill the old i386 and x86_64 directories The last remaining bits were two .gitignore files. Deleting them and we have no more use of the directories. git will most likely not delete the directories for you, so this is a thing to do manually (or create a fresh clone). Signed-off-by: Sam Ravnborg <sam@ravnborg.org> -...

From 7cadfc607d91f536996a46c186711c82378e75ec Mon Sep 17 00:00:00 2001 From: Sam Ravnborg <sam@ravnborg.org> Date: Thu, 25 Oct 2007 20:42:18 +0200 Subject: [PATCH] kconfig: small code refactoring in kconfig Makefile Do not hardcode the arch/$(ARCH)/Kconfig name all over Signed-off-by: Sam Ravnborg <sam@ravnborg.org> --- scripts/kconfig/Makefile | 28 +++++++++++++++------------- 1 files changed, 15 insertions(+), 13 deletions(-) diff --git a/scripts/kconfig/Makefile b/scripts/k...

... why disabling early_printk for x86_64? YH -

I think Sam's patchset already takes care of that. -hpa -

From 9d80894bef9805c70795f73ce1758d2a9e4cb077 Mon Sep 17 00:00:00 2001 From: Sam Ravnborg <sam@ravnborg.org> Date: Thu, 25 Oct 2007 19:42:04 +0200 Subject: [PATCH] x86: move i386 and x86_64 Makefiles to arch/x86 Moving the ARCH specific Makefiles for i386 and x86_64 required a litle bit tweaking in the top-lvel Makefile. SRCARCH is now set in the top-level Makefile because we need this info to include the correct arch Makefile. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> --- ...

Hi Tim, It might help to read this thread I posted on LKML in January 2006 explaining the problem, which led to some discussion about the issue. http://lkml.org/lkml/2006/6/3/48 Using the LTTng tracer, I got the exact instruction responsible for disabling interrupts for so long. It is explained in my presentation referred to by the same email. -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA0...

Hmm, I see this at the beginning of the post-BK era (2.6.12-rc2): spin_lock_irqsave(&logbuf_lock, flags); ... spin_unlock(&logbuf_lock); call_console_drivers(_con_start, _log_end); local_irq_restore(flags); -- Mathematics is the supreme nostalgia of our time. -

Printk to the serial console uses polled I/O to get deterministic, reliable, and -timely- output. If our very next statement (or interrupt) may lock up the box, we want to be sure our printk has actually been delivered before that happens. Well, we could have a commandline option that made messages with a priority below X go out buffered. But it'd be a lousy default from a debugging perspective. -- Mathematics is the supreme nostalgia of our time. -

I've just released 2.6.24-rc1-ext4-1. It removes patches accepted by Linus and adds a number of cleanup patches. It also adds support for storing i_blocks in units of filesystem blocks instead of 512 byte sectors to eliminate one stupid (and easy to fix) large file scalability limit. git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 2.6.24-rc1-ext4-1 http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=summary and [ message continues ]

After turning on DEBUG_SG I hit a fail: kernel BUG at include/linux/scatterlist.h:50! ata_qc_issue ata_scsi_translate ipr_queuecommand scsi_dispatch_cmd scsi_request_fn elv_insert blk_execute_rq_nowait blk_execute_rq sg_io scsi_cmd_ioctl cdrom_ioctl sr_block_ioctl blkdev_driver_ioctl blkdev_ioctl block_ioctl do_ioctl vfs_ioctl sys_ioctl sg_ioctl_trans It looks like ata_sg_setup is working on an uninitialised sg table. Call sg_init_table to initialise it befor...