On Saturday 03 May 2008 05:11:33 am Andrew Morton wrote: oh! am sorry about that! some cosmetic changes remain. It also contains some modifications done to the percpu_counter core. OK, so when does account_system_time get called for the first time ? after IRQs are set up, is it ? So, where do we place the hook ? Here's the patch. diff --git a/include/linux/percpu_counter.h b/include/linux/percpu_counter.h index 9007ccd..8a1b756 100644 --- a/include/linux/percpu_counter.h +++ b/include/lin...

From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> use per_cpu for per CPU data. Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> --- arch/x86/kernel/nmi_32.c | 29 +++++++++++++++++------------ 1 files changed, 17 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/nmi_32.c b/arch/x86/kernel/nmi_32.c index 11b14bb..69bdae5 100644 --- a/arch/x86/kernel/nmi_32.c +++ b/arch/x86/kernel/nmi_32.c @@ -293,9 +293,9 @@ void stop_apic_nmi_watchdog(void *unused) ...

Is a 64bit write to MMIO registers an atomic operation when using the writeq API? My concern is when I send 64bit data via writeq, will it be sent out as two 32 bit writes? If so, is it possible that another CPU be sending the data at the same time. Meaning can I write the 1st 32bit data from CPU-A, meanwhile CPU-B is writing his 32bit data at the same time, and CPU-A didn't complete the full 64bit in one shot. If this could occur, is there an API that I can use to make sure the entire data se...

> Here is a trace from pci express analyzer. I'm sending > 0x0800010000000000 to the adress DD1400C0 using writeq. Notice that in > the TLP header it sent a 32bit Memory write with data length of two. By the way, are you worried that there is something wrong with this trace? Your write went out in a single PCIe packet, so it looks perfect to me. Does the "Mem MWr(32)" worry you? I can't see why it would be a problem -- the PCIe TLP only has one type of memory write transaction (w...

With what CPU/chipset was that? -Andi --

I doubt the CPU was to blame. Probably the chipset split it up for some reason. Did you check the data sheets? At the CPU level writeq is simply a 64bit store on x86-64 Linux. -Andi --

From: "Moore, Eric" <Eric.Moore@lsi.com> The answer to this question this is platform dependent. On most 64-bit platforms, it is. On some 32-bit ones, it is not. This is not a SCSI layer question, so belongs minimally on linux-kernel which I've CC:'d. --

I hope that is the case. --

Yeah, I forgot I have a #ifndef writeq, then defined the x86_64 version of that. I've not tested on x86, so I'm not sure whether it works. How are you handling writeq when its not defined, as the case in x86? Eric --

Thanks for the code sample. Yes, I need to send a single atomic 64-bit transaction. Eric --

This is a SLIT sanity checking patch. It moves slit_valid() function to generic ACPI code and does sanity checking for both x86 and ia64. It sets up node_distance with LOCAL_DISTANCE and REMOTE_DISTANCE when hitting invalid SLIT table on ia64. It also cleans up unused variable localities in acpi_parse_slit() on x86. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> --- arch/ia64/kernel/acpi.c | 9 +++++++-- arch/x86/mm/srat_64.c | 27 --------------------------- drivers/acpi/n...

On Fri, 2 May 2008 15:12:06 -0700 doh. I'm pulling linux-next's constituent trees independently, so if I spot a turd in linux-next I can just grep the various git trees to find out where it came from. It seems wrong though... --

On Fri, 02 May 2008 18:20:26 -0400 Oh. Something seems to have gone wrong then. Next/Trees has: libata git git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git#NEXT but: y:/usr/src/25> diffstat patches/linux-next.patch | grep /ata/ y:/usr/src/25> There's nothing there? (plans for git-jg-misc?) --

The following patchset implments the following: o Inputfiles to all*config can be specified with K= o less chatty oldconfig mode o Drop useless warnings This is work-in-progress aimed for next mergewindow. Posted here mainly to get some feedback and a bit of review. Patches follows to lkml + kbuild lists Sam --

From: Sam Ravnborg <sam@uranus.ravnborg.org> Input file to all*config, randconfig and defconfig can be specified using the environment variable 'K'. It is expected to be used like this: make K=my_config alldefconfig This replaces the KCONFIL_ALLCONFIG support and the input files named: all*.config Signed-off-by: Sam Ravnborg <sam@ravnborg.org> --- scripts/kconfig/Makefile | 31 ++--- scripts/kconfig/aconf.c | 316 ++++++++++++++++++++++++++++++++++++++++++++++ scripts/kco...

From: Sam Ravnborg <sam@uranus.ravnborg.org> No one really used the output generated during a oldconfig run. So drop it and behave like the old 'silentoldconfig' always did. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> --- Makefile | 2 +- scripts/kconfig/Makefile | 5 +---- scripts/kconfig/conf.c | 42 ++++++++++++++---------------------------- 3 files changed, 16 insertions(+), 33 deletions(-) diff --git a/Makefile b/Makefile index d3634cd..99fcf12...

From: Sam Ravnborg <sam@uranus.ravnborg.org> The warning is only annoying and not used. So drop it. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> --- scripts/kconfig/confdata.c | 8 ++------ 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c index ee5fe94..ea44754 100644 --- a/scripts/kconfig/confdata.c +++ b/scripts/kconfig/confdata.c @@ -222,10 +222,8 @@ load: continue; if (def == S_DEF_USER) { ...

Copying the X-guys. The messages all look like debug messages from X and should not cause any side-effects other than little annoyance. I am not sure why band of 2 cm is there... Do you see any performance difference with or without PAT. Thanks, Venki --

Indeed. I think these messages are due to X using the mprotect workaround to change UC_MINUS to WB. I don't see these error messages on my 965 here. May be I have different x version. What may be happening: 1) process A mmaps /dev/mem and gets UC_MINUS 2) Changes the page table to make pg_prot WB 3) Does a fork to create process B 4) While copying the vma, we go through map_devmem request WB, but get UC_MINUS back 5) We are not changing vma pg_prot to new value at this point (we should chang...

Hi Takashi, I've found that my sound card is muted with current git: it's recognized, controls are set correctly, etc., but there's no sound in speakers. I've bisected it down and found that this issue was caused by: commit f6c7e5461e9046445d50c5c7a9a4587824239623 [ALSA] hda-codec - Fix auto-configuration of Realtek codecs This patch fixes some bugs in the auto-configurator of Realtek codecs: - add missing pin set-up for speaker pins - fix the speaker auto-mute function not to conflict with ...

From: Harvey Harrison <harvey.harrison@gmail.com> Applied. --

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> --- net/bluetooth/bnep/core.c | 8 ++++---- net/bluetooth/hci_event.c | 9 ++++----- net/bluetooth/hci_sock.c | 2 +- net/bluetooth/l2cap.c | 2 +- 4 files changed, 10 insertions(+), 11 deletions(-) diff --git a/net/bluetooth/bnep/core.c b/net/bluetooth/bnep/core.c index 347e935..f85d946 100644 --- a/net/bluetooth/bnep/core.c +++ b/net/bluetooth/bnep/core.c @...

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- lib/lzo/lzo1x_decompress.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/lib/lzo/lzo1x_decompress.c b/lib/lzo/lzo1x_decompress.c index 77f0f9b..5dc6b29 100644 --- a/lib/lzo/lzo1x_decompress.c +++ b/lib/lzo/lzo1x_decompress.c @@ -138,8 +138,7 @@ match: t += 31 + *ip++; } m_pos = op - 1; - m_pos -= le16_to_cpu(get_unaligned( - (const unsigned short *)ip)) >> 2; + ...

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- drivers/hid/hid-core.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index f43d6d3..426ac5a 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -780,7 +780,7 @@ static __inline__ __u32 extract(__u8 *report, unsigned offset, unsigned n) */ static __inline__ void implement(__u8 *report, unsigned offset, unsigned n, __u32 value) ...

From: Harvey Harrison <harvey.harrison@gmail.com> Applied. --