From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> acpi_mcfg_64bit_base_addr is used when CONFIG_PCI_MMCONFIG is enabled. Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> --- arch/x86/kernel/acpi/boot.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 5c89f1e..267e684 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -96,8 +96,6 @@ static u64 acpi_lapic_addr ...

I was under the impression that spudstop came in with the Pentium II so presumably < 6 would be even safer ? Alan --

Right in concept, but I dislike the implementation (duplication of the CPU detect code we already have). Could you try this patch and see if it works for you? -hpa

I gather this is a regression from .26? --

Hm. Isn't that X trying to access memory which is not mapped? Rafał, which graphics driver are you using? --

I use radeonhd from today morning git. Does it matter as I play (plug, unplug) with HDMI in init 3? I'll try bisecting tomorrow. -- Rafał Miłecki

--

WARNING: vmlinux.o(.text+0x17a3e): Section mismatch in reference from the function set_pte_vaddr_pud() to the function .init.text:spp_getpage() The function set_pte_vaddr_pud() references the function __init spp_getpage(). This is often because set_pte_vaddr_pud lacks a __init annotation or the annotation of spp_getpage is wrong. mark set_pte_vaddr_pud __init and all functions calling it Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: ...

Linus, please pull from master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus This tree is also available from kernel.org mirrors at: git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus This will get the following fixes: Alexander Schmidt (5): IB/ehca: Update qp_state on cached modify_qp() IB/ehca: Rename goto label in ehca_poll_cq_one() IB/ehca: Repoll CQ on invalid opcode IB/ehca: Check idr_find() return ...

Hi, I spotted that iwl drivers use readl method on an iomap space. IIRC some archs might return a tag instead of an address expected by readl/writel. I think you should either switch to ioread32/iowrite32 or to ioremap. --

I didn't ask for obvious answers :) --

Can you give me reading material on this? Thanks Tomas --

--

x86_64 seems to panic on boot, since 2.6.26-git2 (or maybe -git1, which wouldn't compile) 2.6.26 works. http://test.kernel.org/results/IBM/186461/debug/console kernel BUG at arch/x86/kernel/io_apic_64.c:356! invalid opcode: 0000 [1] SMP CPU 24 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.27-rc1-git2-autotest #1 RIP: 0010:[<ffffffff8021bb1a>] [<ffffffff8021bb1a>] add_pin_to_irq+0x7a/0x90 RSP: 0018:ffff88032e4b9b40 EFLAGS: 00010216 RAX: 00000000000000f0 RBX: 00000000000000f0 ...

On Tue, 12 Aug 2008 12:51:17 -0700 So this looks like ACPI breakage? --

Still looks broken to me (rc2-git5) http://test.kernel.org/results/IBM/188946/debug/console It got in since yesterday? --

In kernels 2.6.27-rc1 and rc2 /proc/diskstats only displays 15 scsi devices (includes partitions), or 9 actual devices (sda-i). I'm using multipath and device mapper, none of the dm devices are in the list either. The 2.6.26 kernel lists all devices, including all dm devices. Since diskstats does not contain all the disks, iostat will not display the io for the disks that are missing, which means, I can't see all of the io activity that is taking place on the system. This seems like a bug to ...

Good day, This e-mail will be a bit longer, as I will describe everything I was able to find out about $subj. I'm not 100% sure that the issue is what it seems to be (not even sure I'm posting to correct mailing list), so if you see I did something wrong, please tell me. Also please, Cc: me, as I'm not (yet, I was not able to find out how) subscribed to this mailing list. I started to experiment with Linux on Dell Latitude XT, actually with 2.6.26 (for more info see [1]). The system ...

Thanks a lot for your detailed observations. Your dmesg logs are still missing the interesting part at the beginning. Can you find the entire log in /var/log/messages or something similar? These lines are from your case C log, but the same thing probably happened in case B: parport_pc 00:0a: reported by Plug and Play ACPI parport0: PC-style at 0x378, irq 7 [PCSPP(,...)] parport_pc 00:0a: driver attached parport1: PC-style at 0x278 [PCSPP(,...)] We found parport0 via PNPACPI, ...

I having nothing but gratitude for anyone who has any suggestions whatsoever! I do _want_ to do both of those things... but you are right that no one should try to do them both at the same time. BTW, the bisect data was from my first post (trying to _find_ the problem) about 8 days ago. Since that time, I have been _assuming_ I located the cause problem, and had not thought about it again... until today. Unfortunately, this kernel stuff can get very deep. Just finding the commit, where ...

Hi Ingo, I spent some time on eraly_param handling and it seems it will not be possible to just set absentee parameter to end of string to prevent NULL deref. As I can see the easier way is to add checking for NULL pointer. And here is why - currently kernel will hang if user forget to specify mandatory boot parameter - pointing us to fix that point in kernel to prevent NULL deref. If we may early_param to behave as __setup() funtion does - we will have to review/fix kernel code anyway - ...

On a PowerPC board with ds1374 RTC I'm getting this error while RTC tries to probe: rtc-ds1374 0-0068: unable to request IRQ This happens because I2C probing code (drivers/of/of_i2c.c) is specifying IRQ0 for 'no irq' case, which is correct. The driver handles this incorrectly, though. This patch fixes it. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> --- drivers/rtc/rtc-ds1374.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git ...

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- arch/x86/kernel/pci-gart_64.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c index 55cc388..18db09b 100644 --- a/arch/x86/kernel/pci-gart_64.c +++ b/arch/x86/kernel/pci-gart_64.c @@ -519,6 +519,15 @@ gart_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_addr, return NULL; } +/* free a coherent mapping */ +static ...

Acked-by: Muli Ben-Yehuda <muli@il.ibm.com> Cheers, Muli -- Workshop on I/O Virtualization (WIOV '08) Co-located with OSDI '08, Dec 2008, San Diego, CA http://www.usenix.org/wiov08 --

Hi, this patchset reworks the dma_*_coherent functions in the DMA layer for the x86 architecture. The patch series extends the existing DMA backends with missing *coherent callbacks and simplifies the generic function to basically only call the registered backend. This allows future optimizations in hardware specific IOMMU implementations. The code ist tested on AMD64 with AMD IOMMU and GART as well as on my old 486 box. It is not yet tested on a Calgary IOMMU system. Joerg git diff ...

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- arch/x86/kernel/pci-nommu.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 38 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c index 3f91f71..4d8cde3 100644 --- a/arch/x86/kernel/pci-nommu.c +++ b/arch/x86/kernel/pci-nommu.c @@ -72,7 +72,45 @@ static int nommu_map_sg(struct device *hwdev, struct scatterlist *sg, return nents; } +static void ...

All dma_ops implementations support the alloc_coherent and free_coherent callbacks now. This allows a big simplification of the dma_alloc_coherent function which is done with this patch. The dma_free_coherent functions is also cleaned up and calls now the free_coherent callback of the dma_ops implementation. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- arch/x86/kernel/pci-dma.c | 116 ++++----------------------------------------- 1 files changed, 10 insertions(+), 106 ...

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- arch/x86/kernel/pci-gart_64.c | 21 +++++++++++++++++++++ 1 files changed, 21 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c index cdab678..55cc388 100644 --- a/arch/x86/kernel/pci-gart_64.c +++ b/arch/x86/kernel/pci-gart_64.c @@ -499,6 +499,26 @@ error: return 0; } +/* allocate and map a coherent mapping */ +static void * +gart_alloc_coherent(struct device *dev, ...

Observed two bugs mainly while starting/closing terminals Steps to reproduce I am tried it two times and it reproduced for me, 1. Open the gnome-terminal 2. Open xterm 3. Close gnome-terminal (system hangs (sometime) with bug1 (dmesg info) captured using serial console) 4. If system does not hang then close the opened xterm which generate the bug2 listed at the end. config attached. Tested Kernel: Commit : commit 299be36648adc14e4627173d00c18b11d08e5ecd Author: Stephen Rothwell ...

BRAIN DAMAGE CONTROL: the problem is only on my hardware, so no one on LKML can play with this hardware directly. That makes _me_ the weak link. 1. Can someone comment on whether I correctly identified the commit # causing the issue for me. Here is the 'git bisect' data from my first post: 2.6.25, good 2.6.26-rc4, bad 10c993a6b5418cb1026775765ba4c70ffb70853d, bad 334d094504c2fe1c44211ecb49146ae6bca8c321, bad eddeb0e2d863e3941d8768e70cb50c6120e61fa0, ...

I assume all of these discussions are focused on simple storage - disks direct attached to a single server - and are not targeted at SANs with arrays, multi-initiator accesses, and fabric/network impacts. True ? Such algorithms can be seriously off-base in these latter configurations. -- james s --

Hi, I just released the latest LTTng version I used to pinpoint the "prove locking correctness" latency issue. It integrates with ftrace (only the dynamic function tracing part) with what I call a "tap". See http://lkml.org/lkml/2008/8/5/321 to find out how I dug in this problem. Basically, a "tap" is a set of "enable/disable" probes one can connect on specific markers/tracepoints. These probes enable/disable a "tap", which controls recording of specific events to the trace. Since ...

From: Will Newton <will.newton@gmail.com> Add a wmb to fsl_queue_td before priming the endpoint. This ensures that the modifications to the QH are seen by the hardware. Added comment as suggested by Felipe Balbi. Signed-off-by: Will Newton <will.newton@gmail.com> Acked-by: Li Yang <leoli@freescale.com> --- drivers/usb/gadget/fsl_usb2_udc.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/usb/gadget/fsl_usb2_udc.c ...

Move spinlock initialization earlier so we can turn shared irq handler debugging on safely. Signed-off-by: Will Newton <will.newton@gmail.com> Acked-by: Li Yang <leoli@freescale.com> --- drivers/usb/gadget/fsl_usb2_udc.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/fsl_usb2_udc.c b/drivers/usb/gadget/fsl_usb2_udc.c index 44296c3..21f5616 100644 --- a/drivers/usb/gadget/fsl_usb2_udc.c +++ b/drivers/usb/gadget/fsl_usb2_udc.c @@ -2190,7 ...

From: Will Newton <will.newton@gmail.com> Rename the arguments of the fsl_writel macro to match their use. Remove a couple of unnecessary prototypes. Signed-off-by: Will Newton <will.newton@gmail.com> Acked-by: Li Yang <leoli@freescale.com> --- drivers/usb/gadget/fsl_usb2_udc.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/usb/gadget/fsl_usb2_udc.c b/drivers/usb/gadget/fsl_usb2_udc.c index 21f5616..92323c4 100644 --- ...

From: Will Newton <will.newton@gmail.com> In some circumstances when fsl_udc_probe fails udc_controller is freed but the pointer remains non-NULL. fsl_udc_remove will then try and teardown the partly initialized and freed controller structure resulting in an oops. This patch ensures udc_controller is either NULL or fully initialized after fsl_udc_probe. Signed-off-by: Will Newton <will.newton@gmail.com> Acked-by: Li Yang <leoli@freescale.com> --- drivers/usb/gadget/fsl_usb2_udc.c | 32 ...

From: Will Newton <will.newton@gmail.com> fsl_queue_td always returns 0. Make it void and remove checks for non-zero return in callers. Signed-off-by: Will Newton <will.newton@gmail.com> Acked-by: Li Yang <leoli@freescale.com> --- drivers/usb/gadget/fsl_usb2_udc.c | 19 +++++-------------- 1 files changed, 5 insertions(+), 14 deletions(-) diff --git a/drivers/usb/gadget/fsl_usb2_udc.c b/drivers/usb/gadget/fsl_usb2_udc.c index 45ae982..10fafbb 100644 --- ...

Remove check for udc == NULL in dr_controller_setup. All callers of this function have already dereferenced udc at some point. Signed-off-by: Will Newton <will.newton@gmail.com> Acked-by: Li Yang <leoli@freescale.com> --- drivers/usb/gadget/fsl_usb2_udc.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/usb/gadget/fsl_usb2_udc.c b/drivers/usb/gadget/fsl_usb2_udc.c index 6a927da..47d6c92 100644 --- a/drivers/usb/gadget/fsl_usb2_udc.c +++ ...

> It is a bug to have irq saved flags as an int and not long since > some archs may use more that 32 bits in flags. Isn't this already upstream for a while as 52fd8ca6? - R. --

But there isn't any "style of the whole". Existing styles differ. While I guess there is some agreement about the base (tab width, mostly K&R, don't do "char* ptr" etc.), the rest are simply views of single persons. This is IMHO fine as long as it's useful for the community, but not past this point. -- Krzysztof Halasa --

I think checkpatch already has gone way too far with this (and not only this). "type *var" vs "type* var" - sure, the latter is worse and provokes "type* var1, var2", but anything else is IMHO only annoying and, actually, not important WRT readability at all. For example I prefer "type* func()" - as it's a function returning "a pointer to type" and not "a pointer to a function returning type" (which "type *func()" may suggest). Yes, func is not a pointer, so why write "*" next to it? -- ...

Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git for-linus containing a few trivial fixes below against 2.6.27-rc2. Thanks! Takashi === Dmitry Baryshkov (3): ALSA: wm8750: it's MONO1, not MONO ALSA: spitz: MONO -> MONO1 ALSA: wm8750: add missing VREF output Libin Yang (1): ALSA: hda - support new AMD HDMI Audio (1002:970f) Seth Heasley (1): ALSA: hda_intel: ALSA HD Audio patch for Intel Ibex Peak ...

Ok, this is the second place. But, what about the first place ( I --

Which I think is perfectly fine and clear. There are only two matches for /attr.*=.*alloc We covered both of them. Max --

When the ehca driver detects an invalid opcode in a CQE, it currently passes the CQE to the application and returns with success. This patch changes the CQE handling to discard CQEs with invalid opcodes and to continue reading the next CQE from the CQ. Signed-off-by: Alexander Schmidt <alexs@linux.vnet.ibm.com> --- drivers/infiniband/hw/ehca/ehca_reqs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- infiniband.git.orig/drivers/infiniband/hw/ehca/ehca_reqs.c +++ ...

thanks, applied all 5. --

Hi Roland, Sorry, the first set was mangled because of a broken mailer, so here it is again, double checked... the following patchset contains four small fixes and one bigger patch (5/5) for addressing some ehca issues we found during cluster test. [1/5] update qp_state on cached modify_qp() [2/5] rename goto label in ehca_poll_cq_one() [3/5] repoll on invalid opcode instead of returning success [4/5] check idr_find() return value [5/5] discard double CQE for one WR They all apply on ...

Hi David, Why macros? When introducing APIs using trivial inlines makes sure that the conversion is correct, type correct and side effect free for the callers. Macros cannot ensure this without pain. Please respin this patch with inlines. If that needs header changes, your CRED subsytem might need that, too. Best Regards Ingo Oeser --

Can we get an acked-by from an XFS maintainer before pushing this to -- James Morris <jmorris@namei.org> --

Hi David, Ok, if that is the only reason, please mention this in the commit message. That would be enough for me to not wonder about this issue. But I wonder how you solve this issue if the amount of code behinde your wrappers grows. If you have to take them out of line, it would give me a good indication of the costs involved in the later bodies of these now trivial wrappers, if you do it right away. That way you'll find missing includes and whatnot while converting existing code to ...

Rename XFS's current_fsuid() and current_fsgid() to avoid collision with functions of the same name in upcoming COW creds. Signed-off-by: David Howells <dhowells@redhat.com> --- fs/xfs/linux-2.6/xfs_linux.h | 4 ++-- fs/xfs/xfs_inode.c | 4 ++-- fs/xfs/xfs_vnodeops.c | 8 ++++---- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_linux.h b/fs/xfs/linux-2.6/xfs_linux.h index 4d45d93..05a2e7e 100644 --- ...

Gidday I've released man-pages-3.07. This release is now available for download at: http://www.kernel.org/pub/linux/docs/man-pages or ftp://ftp.kernel.org/pub/linux/docs/man-pages This release is now available for download at: http://www.kernel.org/pub/linux/docs/man-pages or ftp://ftp.kernel.org/pub/linux/docs/man-pages The online changelog is available at http://www.kernel.org/doc/man-pages/changelog.html (an overview of the changes in this release is blogged ...

Got the bug "unable to handle kernel paging request" on rebooting 2.6.27-rc2-next-20080811 method to reproduce: reboot the machine via xterm or gnome-terminal. observe the messages during the reboot in another machine's terminal which is connected to it through a serial port setup. commit 299be36648adc14e4627173d00c18b11d08e5ecd Author: Stephen Rothwell <sfr@canb.auug.org.au>5ecd Date: Mon Aug 11 16:30:46 2008 +1000 Bug info: [ 925.528434] ======================= [ 925.532104] ...

When the ehca driver detects an invalid opcode in a CQE, it currently passes the CQE to the application and returns with success. This patch changes the CQE handling to discard CQEs with invalid opcodes and to continue reading the next CQE from the CQ. Signed-off-by: Alexander Schmidt <alexs@linux.vnet.ibm.com> --- drivers/infiniband/hw/ehca/ehca_reqs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- infiniband.git.orig/drivers/infiniband/hw/ehca/ehca_reqs.c +++ ...

Under rare circumstances, the ehca hardware might erroneously generate two CQEs for the same WQE, which is not compliant to the IB spec and will cause unpredictable errors like memory being freed twice. To avoid this problem, the driver needs to detect the second CQE and discard it. For this purpose, introduce an array holding as many elements as the SQ of the QP, called sq_map. Each sq_map entry stores a "reported" flag for one WQE in the SQ. When a work request is posted to the SQ, ...

Rename the "poll_cq_one_read_cqe" goto label to what it actually does, "repoll". Signed-off-by: Alexander Schmidt <alexs@linux.vnet.ibm.com> --- drivers/infiniband/hw/ehca/ehca_reqs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- infiniband.git.orig/drivers/infiniband/hw/ehca/ehca_reqs.c +++ infiniband.git/drivers/infiniband/hw/ehca/ehca_reqs.c @@ -589,7 +589,7 @@ static inline int ehca_poll_cq_one(struc struct ehca_qp *my_qp; int cqe_count = 0, is_error; ...

Hello, twice while booting 2.6.27-rc2 my system stalled after printing "Mounting root..." until I hit a key. I did not see this with 2.6.27-rc1. The system is booted via an initial ramdisk, because the root fs is encrypted on a RAID5 consisting of 3 sata drives, two on sata_sil24 and one on sata_nv. The second time, I uses SysRq+P,Q,W to dump some state. The SysRq keys did not resume the boot, only after hitting enter the system continued to start normally. From dmesg: [ 2.419290] ...

With this patch, dm-ioband can work with the bio cgroup. Based on 2.6.27-rc1-mm1 Signed-off-by: Ryo Tsuruta <ryov@valinux.co.jp> Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp> diff -Ndupr linux-2.6.27-rc1-mm1.cg2/drivers/md/dm-ioband-type.c linux-2.6.27-rc1-mm1.cg3/drivers/md/dm-ioband-type.c --- linux-2.6.27-rc1-mm1.cg2/drivers/md/dm-ioband-type.c 2008-08-12 14:45:59.000000000 +0900 +++ linux-2.6.27-rc1-mm1.cg3/drivers/md/dm-ioband-type.c 2008-08-12 15:07:03.000000000 +0900 @@ -6,6 ...

This patch is for cleaning up the code of the cgroup memory subsystem to remove a lot of "#ifdef"s. Based on 2.6.27-rc1-mm1 Signed-off-by: Ryo Tsuruta <ryov@valinux.co.jp> Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp> diff -Ndupr linux-2.6.27-rc1-mm1.cg0/mm/memcontrol.c linux-2.6.27-rc1-mm1.cg1/mm/memcontrol.c --- linux-2.6.27-rc1-mm1.cg0/mm/memcontrol.c 2008-08-12 14:47:11.000000000 +0900 +++ linux-2.6.27-rc1-mm1.cg1/mm/memcontrol.c 2008-08-12 14:47:40.000000000 +0900 @@ -228,6 ...

This patch splits the cgroup memory subsystem into two parts. One is for tracking pages to find out the owners. The other is for controlling how much amount of memory should be assigned to each cgroup. With this patch, you can use the page tracking mechanism even if the memory subsystem is off. Based on 2.6.27-rc1-mm1 Signed-off-by: Ryo Tsuruta <ryov@valinux.co.jp> Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp> diff -Ndupr linux-2.6.27-rc1-mm1.ioband/include/linux/memcontrol.h ...

Hi everyone, Here are new releases of dm-ioband and bio-cgroup. The major change from the previous version is that dm-ioband now supports a device-mapper bvec merge function, which removes the restriction that the device-mapper framework automatically splits a I/O request into several small I/O requests. The size of I/O requests was limited to PAGE_SIZE when the underlying device, such as software RAID, had its own merge function. This restriction had ever been applied to all device-mapper ...

Hi, On x86_64, UP, 1.2G Ram with a Hauppauge WinTV-HVR 950, v4l2, and mplayer I encounted the following panic: (arg: 2) [107637.465310] BUG: unable to handle kernel paging request at ffffc208[107637.466007] IP: [<ffffffff80332dbb>] memcpy_c+0xb/0x20 [107637.466007] PGD 4f810067 PUD 4f811067 PMD 4fbb4067 PTE 0 [107637.466007] Oops: 0002 [1] PREEMPT [107637.466007] CPU 0 [107637.466007] Modules linked in: lgdt330x em28xx_dvb dvb_core tuner_xc2028 fix[107637.466007] Pid: 31414, comm: konsole Not ...

SGksDQoNCj4gPiBGZXJuYW5kbyBMdWlzIFbDoXpxdWV6IENhbyB3cm90ZToNCj4gPiA+Pj4gVGhp cyBzZWVtcyB0byBiZSB0aGUgZWFzaWVzdCBwYXJ0LCBidXQgdGhlIGN1cnJlbnQgY2dyb3Vwcw0K PiA+ID4+PiBpbmZyYXN0cnVjdHVyZSBoYXMgc29tZSBsaW1pdGF0aW9ucyB3aGVuIGl0IGNvbWVz IHRvIGRlYWxpbmcgd2l0aCBibG9jaw0KPiA+ID4+PiBkZXZpY2VzOiBpbXBvc3NpYmlsaXR5IG9m IGNyZWF0aW5nL3JlbW92aW5nIGNlcnRhaW4gY29udHJvbCBzdHJ1Y3R1cmVzDQo+ID4gPj4+IGR5 bmFtaWNhbGx5IGFuZCBoYXJkY29kaW5nIG9mIHN1YnN5c3RlbXMgKGkuZS4gcmVzb3VyY2UgY29u dHJvbGxlcnMpLg0KPiA+ID4+PiBUaGlzIG1ha2Vz ...

Please note that the seek time for a specific IO request is strongly correlated with the IO requests that preceded it, which means that the owner of that request is not the only one to blame if it takes too long to process it. In other words, with the algorithm you propose we may end up charging the wrong guy. --

mmh.. yes. The only scenario I can imagine where this solution is not fair is when there're a lot of guys always requesting the same near blocks and a single guy looking for a single distant block (supposing disk seeks are more expensive than read/write ops). In this case it would be fair to charge a huge amount only to the guy requesting the single distant block and distribute the cost of the seek to move back the head equally among the other guys. Using the algorighm I proposed, instead, ...

Herbert and Ulrich, sorry for late reply. see below. This patch was created against cryptodev-2.6 Clean-up by new MACRO; Signed-off-by: Austin Zhang <austin.zhang@intel.com> --- crc32c-intel.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -Naurp cryptodev-2.6/arch/x86/crypto/crc32c-intel.c cryptodev-2.6-patch/arch/x86/crypto/crc32c-intel.c --- cryptodev-2.6/arch/x86/crypto/crc32c-intel.c 2008-08-12 04:44:00.000000000 -0400 +++ ...

On Tue, 12 Aug 2008 12:24:34 +0200 That was a trivial dirtyup. Should at least be "Distributed under the GPL" but I suspect that the policy in drivers/acpi/ is to add fancier copyright text than this. --

Hi Andreas, Yeah, the problem of rewriting working code is that you're likely to It did, there were workarounds for the same problem in the earlier code, I missed it. The misalignment stems from the fact that the alignment requirement is wider than the offset-pfn and the starting pfn of the node is not aligned itself, correct? I think, the cleaner fix would be to work with an aligned base pfn to begin with, like the following, untested. What do you think? Hannes diff --git ...

Could do I guess. Index: linux-2.6/mm/slub.c =================================================================== --- linux-2.6.orig/mm/slub.c +++ linux-2.6/mm/slub.c @@ -1543,7 +1543,7 @@ load_freelist: if (unlikely(!object)) goto another_slab; if (unlikely(PageSlubDebug(c->page) || c->reserve)) - goto debug; + goto slow_path; c->freelist = object[c->offset]; c->page->inuse = c->page->objects; @@ -1586,11 +1586,21 @@ grow_slab: goto load_freelist; } return ...

There can be more than one sgiioc4 card in the system so print also PCI device name on resource allocation failure (so we know which one is the problematic one). Reported-by: Jeremy Higdon <jeremy@sgi.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/pci/sgiioc4.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: b/drivers/ide/pci/sgiioc4.c =================================================================== --- ...

Hi all, Changes since next-20080811: The arm-current tree gained a trivial whitespace conflict against Linus' tree (unreported). The ide tree gained a build fix patch. The acpi tree gained a build fix patch. The vfs tree gained 2 conflicts against the xfs tree and one against the nfsd tree. The ubifs tree gained a build failure which required a revert to a commit (interaction with the vfs tree). The ttydev tree gained 2 conflicts against Linus' tree and against the usb.current ...

Hi, You are right, thanks. Hannes --

Attach the routine to get_cd to allow the MMC core to find out whether there is a card present or not without the tedious process of trying to send commands to the card or not. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Index: linux-2.6.27-rc2-quilt3/drivers/mmc/host/s3cmci.c =================================================================== --- linux-2.6.27-rc2-quilt3.orig/drivers/mmc/host/s3cmci.c 2008-08-11 23:33:09.000000000 +0100 +++ ...

Two comments to be precise. 1/ __kmalloc_reserve attempts a __GFP_NOMEMALLOC allocation, and then if that fails, ___kmalloc_reserve immediately tries again. Is that pointless? Should the second one be removed? 2/ mem_reserve_kmalloc_charge appears to assume that the 'mem_reserve' has been 'connected' and so is active. While callers probably only set GFP_MEMALLOC in cases where the mem_reserve is connected, ALLOC_NO_WATERMARKS could get via PF_MEMALLOC so we could end ...

Hi, To add coretemp (thermal monitoring) support for the Intel Q9450 processor add the code below. i have tested this on several kernels including 2.6.26 and it works fine. the code addition is *||(c->x86_model == 0x17) in the if statement* Thanks Eric *in:* drivers/hwmon/coretemp.c *in function:* static int __init coretemp_init(void) *change:* if ((c->cpuid_level < 0) || (c->x86 != 0x6) || !((c->x86_model == 0xe) || (c->x86_model == 0xf) || ...

This looks quite different to last time I looked at the code (I think). You now have a more structured "kmalloc_reserve" interface which returns a flag to say if the allocation was from an emergency pool. I think this will be a distinct improvement at the call sites, though I I cannot figure out why the spinlock is being used to protect updates to 'limit'. As far as I can see, mem_reserve_mutex already protects all those updates. Why not just if (emerg) *emerg = 1. I can't ...

Umm. What does that matter wrt what I said? What does that matter wrt your bogus argument about EIO (which we do _wrong_ right now, exactly because we return EIO too eagerly, instead of returning the partial data we got)? vfs_readdir() itself would not change AT ALL. The change I talked about was in the caller. Which you should realize, since I actually _called_ vfs_readdir() in that example code. Here's a patch to get the _semantics_ I talked about, to make the thing more ...

Would you care to grep for vfs_readdir() in the tree? It's not just sys_getdents(); for better of worse the thing had become a general-purpose iterator. And I'm not suggesting to pass the damn thing to caller of sys_getdents(). At all. --

PS: we might get away with both, if we used _positive_ values as well. E.g. have getdents() filldir return 1 if we are out of buffer *and* have ->previous != NULL (and -EINVAL if we are out of buffer on the first call)... And have some other positive constant for "->readdir() didn't feel like going all the way to the end of directory". --

No I've not. If we returned a partial result, we _should_ return a partial result. And if we got EIO on the first entry, we should return EIO. The _current_ code is crap. It sometimes returns the error (if the ->readdir() function returned error), and sometimes returns the partial Keeping them simple (and not changing them - always returning zero is what the _original_ readdir() thing did!) is why the current situation exists. So if we keep it that way, then we really *KEEP* ...

You'd truncate the inode number. What's the big deal? Inode numbers aren't that important - they're just about the _least_ important part of the data returned for a readdir. Sure, truncating the inode number may confuse some programs like old-style /bin/pwd, but the thing is, we effectively _already_ do that by generating essentially random numbers for filesystems that don't have UNIX-style The thing is, the "probably" is likely "probably not". There's a lot of things that work ...

you've just lost e.g. -EIO for getdents(). And if you bail out on non-zero return value from vfs_readdir(), you are back to -EINVAL on full buffer. Frankly, I'd rather keep ->readdir() instances simpler. There are far more of those, for one thing. As it is, we only have "stop"/"continue" ->readdir() has to care about... There's one more thing in that mess: a bunch of vfs_readdir() callers end up playing very sick games to make sure they get the entire directory. The trick is to find ...

Btw, this whole sentence, and the one from your next email seems to really We *must* handle partial returns by returning "success". And we do, except for our _confusion_ about ->readdir() returning error and that somehow "overriding" the fact that it already returned non-errors earlier through the callback. All your blathering about "positive values as well" seems to ttoally misunderstand how readdir() works. We absolutely do *not* need positive return values, because the fact is, ...

Yeah. That said, I doubt it's a very common problem in practice. I'm pretty sure nobody really cares, and almost nobody really wants to run really old binaries. So it's almost certainly not worth it (and the one time I had it happen, I didn't bother to do it right, I just hacked around it and obviously never committed the hack). I just find it a bit sad how well we actually _can_ run old binaries, but sometimes there are these new things that were literally designed to break ...

Um... Here it would happen only on attempt to return an entry for file that really has an inumber not fitting into the field; what would you do in such case? open() on a huge file is a different story, since you would get a valid opened file and that'd be it; the logics in case of open() is, IIRC, "I guess your binary is old, so it'll probably do other things that would really have to trigger -EOVERFLOW; better bail out right now". In this case, though, you either generate an error or get ...

The thing is, you still have the low 32 (or 16) bits, so even tar is better off most of the time. Let's face it, we actually always truncate things as-is. What are inode numbers on NFS but truncated file handles? And the other side of the coin is that legacy binaries are almost never _system_ binaries. You upgrade those with your system They are some odd I agree. However, the reason it f*cks up is exactly the fact that we have two different error numbers, which was why I ...

I think the same issue that your patch 0ed361dec36945f3116ee 1338638ada9a8920905 "fix PageUptodate data race" pointed out is there around buffer_head without my patch "vfs: pagecache usage optimization for pagesize!=blocksize". Because set_buffer_uptodate or buffer_uptodate are used without distinct locking facility (lock_buffer, or lock_page) in many places, so it would be needed to deal with memory ordering issue. --

Its not, we need to force slub into the debug slow path when we have a reserve page, otherwise we cannot do the permission check on each Right,.. do people prefer I just add another int? --

Ok, so the old code did: if (((p->flags & PF_MEMALLOC) || ...) && !in_interrupt) { .... goto nopage; } which avoid anything that has PF_MEMALLOC set from entering into direct reclaim, right? Now, the new code reads: if (alloc_flags & ALLOC_NO_WATERMARK) { } Which might be false, even though we have PF_MEMALLOC set - __GFP_NOMEMALLOC comes to mind. So we have to stop that recursion from happening. so we add: if (p->flags & PF_MEMALLOC) goto ...

on x86_64, SMP, 8 GB RAM: BUG: unable to handle kernel paging request at ffffe20001d5ae00 IP: [<ffffffff8027c08f>] unmap_vmas+0x42d/0x7a0 PGD 28102067 PUD 28103067 PMD 0 Oops: 0000 [1] SMP CPU 3 Modules linked in: lpfc(+) cciss ehci_hcd ohci_hcd uhci_hcd Pid: 1382, comm: udevd Not tainted 2.6.27-rc2-git5 #1 RIP: 0010:[<ffffffff8027c08f>] [<ffffffff8027c08f>] unmap_vmas+0x42d/0x7a0 RSP: 0018:ffff88027dcffd68 EFLAGS: 00010246 RAX: 000000008631b98b RBX: ffffe20001d5ade8 RCX: ...

Ingo, Can you pull this into linux-tip. Thanks, -- Steve --

I guess steven would like to see a patch which introduces both locked and lockless versions and with a very good comment explaining in what kind of unusual situation one can use the lockless version. Thanks Vivek --

Add device_pm_lock() and device_pm_unlock() in kernel_kexec() in sync with current hibernation implementation. Signed-off-by: Huang Ying <ying.huang@intel.com> --- kernel/kexec.c | 2 ++ 1 file changed, 2 insertions(+) --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -1457,6 +1457,7 @@ int kernel_kexec(void) error = disable_nonboot_cpus(); if (error) goto Resume_devices; + device_pm_lock(); local_irq_disable(); /* At this point, device_suspend() has been called, ...

Call kernel_restart_prepare() in kernel_kexec() instead of duplicating the code. Signed-off-by: Huang Ying <ying.huang@intel.com> Acked-by: Pavel Machek <pavel@suse.cz> Acked-by: Vivek Goyal <vgoyal@redhat.com> --- include/linux/reboot.h | 1 + kernel/kexec.c | 6 +----- kernel/sys.c | 2 +- 3 files changed, 3 insertions(+), 6 deletions(-) --- a/include/linux/reboot.h +++ b/include/linux/reboot.h @@ -59,6 +59,7 @@ extern void machine_crash_shutdown(struc ...

Kexec/Kexec-jump require code size in control page is less than PAGE_SIZE/2. This patch add link-time checking for this. ASSERT() of ld link script is used as the link-time checking mechanism. Signed-off-by: Huang Ying <ying.huang@intel.com> --- arch/x86/kernel/machine_kexec_32.c | 2 +- arch/x86/kernel/relocate_kernel_32.S | 10 +++++++--- arch/x86/kernel/vmlinux_32.lds.S | 6 ++++++ include/asm-x86/kexec.h | 4 ++++ 4 files changed, 18 insertions(+), 4 ...

Move if (kexec_image->preserve_context) { ... } into #ifdef CONFIG_KEXEC_JUMP to make code looks cleaner. Fix no longer correct comments of kernel_kexec(). Signed-off-by: Huang Ying <ying.huang@intel.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> --- kernel/kexec.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -1426,11 +1426,9 @@ static int __init crash_save_vmcoreinfo_ ...

I appear to have fixed it. It seems that SIGWINCH was being fired off before the tty's size was updated, as Ico hypothesized. The patch follows. Please comment! diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c index 7501310..8e2fa3c 100644 --- a/drivers/char/tty_io.c +++ b/drivers/char/tty_io.c @@ -3021,6 +3021,9 @@ static int tiocswinsz(struct tty_struct *tty, struct tty_struct *real_tty, rpgrp = get_pid(real_tty->pgrp); spin_unlock_irqrestore(&tty->ctrl_lock, ...

I spoke too soon. The problem still exists with my workaround on the latest git kernel, but it seems to be harder to reproduce. --

Correct the malformed issue for v2's patch which . 2D and HW cursor stuff of viafb driver. Signed-off-by: Joseph Chan <josephchan@via.com.tw> diff -Nurp a/drivers/video/via/accel.c b/drivers/video/via/accel.c --- a/drivers/video/via/accel.c 1970-01-01 08:00:00.000000000 +0800 +++ b/drivers/video/via/accel.c 2008-07-22 02:07:29.000000000 +0800 @@ -0,0 +1,244 @@ +/* + * Copyright 1998-2008 VIA Technologies, Inc. All Rights Reserved. + * Copyright 2001-2008 S3 Graphics, Inc. All Rights ...

Q29ycmVjdCB0aGUgZGVzY3JpcHRpb24gb2YgVlg4MDAgMkQgYWNjZWxlcmF0aW9uLCB0aGUgZHJp dmVyIGRpYWJsZXMgdGhlIGFjY2VsZXJhdGlvbg0KZnVuY3Rpb24gYnkgZGVmdWFsdCBpZiB5b3Ug dXNlIFZYODAwIGNoaXAuDQpDb3JyZWN0IHZpYV9mYl8gdG8gdmlhZmJfIGFuZCByZW1vdmUgdGhl IEtjb25maWcgcGFydCBpbiB2aWFmYi50eHQuDQoNCnZpYWZiLm1vZGVzOiBzdXBwb3J0ZWQgbW9k ZSB0YWJsZQ0KdmlhZmIudHh0OiBkb2N1bWVudGF0aW9uIG9mIHZpYWZiIGRyaXZlcg0KDQpTaWdu ZWQtb2ZmLWJ5OiBKb3NlcGggQ2hhbiA8am9zZXBoY2hhbkB2aWEuY29tLnR3Pg0KDQpkaWZmIC1O dXJwIGEvRG9jdW1lbnRhdGlvbi9mYi92aWFmYi5t ...

Got this on the latest mainline git. There are already a couple of lockdep/kvm threads. So maybe it's known. ============================================= [ INFO: possible recursive locking detected ] 2.6.27-rc2 #36 --------------------------------------------- qemu-system-x86/3445 is trying to acquire lock: (&anon_vma->lock){--..}, at: [<ffffffff8029f84d>] mm_take_all_locks+0x8d/0xf0 but task is already holding lock: (&anon_vma->lock){--..}, at: [<ffffffff8029f84d>] ...

Yes, and the hardware problem is the first thing I thinked of, but I've changed MB and cables, as well as bought a new disk. An I still get some I/O errors, even on the new one. So, or I'm a bit unlucky to find several faulty disks in a row (it can be :) ) or something unclear is going on. The disk that suffers most lockups, after many tries, is the new one, the only SATA-II drive. I'll keep stressing the HD trying to figure out what's going on, I'll even try a new sata-II unit, to see ...

Resend with proper whitespace. This patch adds the Intel Ibex Peak (PCH) IDE mode SATA Controller DeviceIDs. Signed-off-by: Seth Heasley <seth.heasley@intel.com> --- linux-2.6.26.2/drivers/ata/ata_piix.c.orig 2008-08-08 11:34:56.000000000 -0700 +++ linux-2.6.26.2/drivers/ata/ata_piix.c 2008-08-08 14:30:02.000000000 -0700 @@ -274,6 +274,14 @@ { 0x8086, 0x3a20, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata }, /* SATA Controller IDE (ICH10) */ { 0x8086, 0x3a26, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ...

Resend with proper whitespace. This patch adds the Intel Ibex Peak (PCH) HD Audio Controller DeviceIDs. Signed-off-by: Seth Heasley <seth.heasley@intel.com> --- linux-2.6.26.2/sound/pci/hda/hda_intel.c.orig 2008-08-08 11:25:05.000000000 -0700 +++ linux-2.6.26.2/sound/pci/hda/hda_intel.c 2008-08-08 11:27:24.000000000 -0700 @@ -98,6 +98,7 @@ "{Intel, ICH8}," "{Intel, ICH9}," "{Intel, ICH10}," + "{Intel, PCH}," "{Intel, SCH}," "{ATI, SB450}," "{ATI, ...

Looks good, I've added this to my tree. I will have to wait for the PCI IDs patch to go upstream before I can push it though. -- Jean Delvare --

I'd still prefer this to go into a Kconfig in the parent directory (ie. where freezer.c and the Makefile building it are located). Otherwise it's guaranteed --

On Mon, 11 Aug 2008 16:53:23 -0700 I don't think that this provides anything like sufficient detail to justify merging a whole bunch of stuff into Linux. What does "It's immediately useful for batch job management scripts." mean? How is it useful? Examples? Why would an operator want this feature, and how would it be used? _much_ more information is needed! Once we've actually found out what this work is useful for, we can move onto identification of and discussion of alternatives. One ...

better spelled version posted. -- Ben (ben@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' --

Hmm, it causes issues in ext3/4 even though it doesn't change any code executed by ext3/4? Yes, if you could send a trace... --

Pid: 2620, comm: bonnie Not tainted 2.6.27-rc2-zen1 #1 [<c026d729>] do_writepages+0x49/0x50 [<c02dc830>] ext3_write_inode+0x0/0x40 [<c02dc860>] ext3_write_inode+0x30/0x40 [<c02ad3a2>] __writeback_single_inode+0x282/0x390 [<c02ad9d4>] generic_sync_sb_inodes+0x304/0x3a0 [<f9b9b234>] reiser4_sync_inodes+0x54/0x130 [reiser4] [<c02ad940>] generic_sync_sb_inodes+0x270/0x3a0 [<c02adc64>] writeback_inodes+0x44/0xd0 [<c026d0d0>] balance_dirty_pages_ratelimited_nr+0x230/0x370 [<f9b79a5c>] ...

No, this is wrong: if (node == NULL), then there is nothing to do in this loop. --

libata lets you set the nth controller to various things (40wire etc) so I suspect the right thing to extent is the existing libata option code that Tejun wrote to include 'skip' if it doesn't already. If that gets done cc me and I'll then go audit the drivers to see who apart from it821x knows port 0 is always probed --

On Tue, 12 Aug 2008 03:09:11 +0200 if you solder the board... well you can add a tiny kernel patch or change the dmi ;) -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org --

On Tue, 12 Aug 2008 09:10:09 +0100 which is a commandline option then; because once userspace runs you've already paid the price in terms of boottime otherwise and would make the idea entirely moot. -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org --

On Mon, 11 Aug 2008 15:36:41 -0700 What happens if I plug in an additional libata using device ? What defines the probe order here particularly as people are pushing for parallel probing of multiple devices. This doesn't appear to make any rational sense as the mask isn't tied to the actual bus device identifier to keep it on the same port. It might kidn of work for an EEEPC (until you see what people retrofit into the corners of them) but it isn't a valid general solution. Also the EEE ...

last time I had mine open, I saw that the other ATA connectors are in theory usable. You have to do some heavy modifications, but some people do modifications to this kind of hardware to use it for really weird purposes. We might wanna consider adding a module parameter to disable the magic DMI table. Or do we expect them to always compile their own kernel and know where to fix this? Thoughts? Regards Marcel --

thanks! I've applied the delta fix below to tip/core/urgent. In my testing the previous version didnt cause problems either because we seldom excercise this slowpath. (Jeremy had trouble reproducing the on-stack corruption even with targeted tests.) We'll soon start using the generic-ipi facilities for TLB flushes on x86 and perhaps even reuse the IPI itself for the reschedule IPI - that should put it all under heavier scrutiny. Ingo -----------------> From ...

I'm still not 100% sure that I have this patch right... I might have seen a lockup trace implicating the smp call function path... which may have been due to some other problem or a different bug in the new call function code, but if some more people can take a look at it before merging? --

Well, hopefully. At the moment it is significantly slower though. --

This is the nightclub model and doesn't work viz: "If I put a big scary man on the door nobody will be able to get knives and drugs in because we only have one door for the public" If you have to enumerate the potential attack vectors to make your model work you already lost. There is one of you and a lot of them. Smart nightclubs don't do that they circulate looking for evidence. Yes, they will miss some, yes they will respond late to some, but they will at least notice there has been a ...

We should give the users more control to the style I think. Thanks, -yi --

what kind of control do you expect? If you need two lines of debug or error output, call IWL_ERROR twice. This will also result in the KERN_ERR is set and not forgotten since that has to follow the newline. Regards Marcel --

can we not just fix IWL_ERROR to always append the newline? Regards Marcel --

Best not to quote an entire long message when only a little bit of it is needed to provide context for the reply. It forces all readers to scan down many pages trying to find the useful reply. I agree with Max's reply to this ... his comment explaining why checking dattr is not NULL looks good. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214 --

can you enable CONFIG_IDE and CONFIG_BLK_DEV_PIIX like 2.6.25 YH --

Then mmconfig is not the problem. Must be something else. In the worst case you can always bisect I guess. -Andi --

2008/8/11 Andi Kleen <andi@firstfloor.org>: [...] It doesn't help -- Maciej Rutecki http://www.maciek.unixy.pl --

looks like you are using ata driver for pata device instead of ide driver. so could be caused by bug in ata_piix... YH --

[Empty message]

---- So in debugging mysterious 'lockups' where I've, at least once, noticed a hangcheck_timer elapse, this lock-checking stuff is just nonsensical? It is very frustrating trying to turn on debug tools in the kernel and get so many false positives. Would it be possible or, perhaps, desirable to eliminate the buggy lock-checks in the xfs code? Meanwhile...back to finding reasons for the semi-random, periodic hanging... ;^/ --

Wouldn't surprise me. Have you considered doing profiles? e.g. just oprofiling the benchmark on the different kernels and see if there's some obvious difference in the CPU consumers? -Andi --

Committing a transaction would means writing rest of the meta-data in the transaction. And that would imply forcing most of the buffer_heads to disk in ordered mode. This can result a lot of seeks and make take more thatn 120 seconds. -aneesh --

Now I've tried to use kdump to catch the panic, but it doesn't help :-( At boot, I have this: Reserving 64MB of memory at 16MB for crashkernel (System RAM: 1023MB) Loading the dump-capture kernel succeeds: # build/sbin/kexec -p --initrd=/boot/initrd-2.6.23.8-34.fc7.img --append="ro root=/dev/VolGroup00/LogVol00 rhgb console=tty0 console=ttyS0,115200 nmi_watchdog=1 panic=30 sysrq_always_enabled maxcpus=1 irqpoll reset_devices 3" /boot/testing/bzImage ...but after pulling the ...

Actually, I just forgot earlyprintk=...,keep. Now I modified the printk() to use early_printk() if oops_in_progress is set. This does actually give some result, but again the text is garbled, this time for real, and I don't understand why. But this is what I get on the serial console: <0>BUG: NMI Watchdog detected LOCKUP on CPU1, ip c010ae8c, registers: Pid: 0, comm: swapper Not tainted (2.6.27-rc2-00325-g796aade-dirty #3) EIP: 0060:[<c010ae8c>] EFLAGS: 00000246 CPU: 1 EIP is at ...

Hi Luis, On Mon, 11 Aug 2008 09:46:57 -0700 "Luis R. Rodriguez" <lrodriguez@atheros.= That is only the first application of the patch, my patch is a fix of a second instance of the same code. See Adrian's post. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

Christoph, I'm dropping this patch from my tree. --

Please update this patch as per my last comment. Cheers, Dave. -- Dave Chinner david@fromorbit.com --

Hi Arnd, This won't be portable across architectures as .align is sometimes in bytes and sometimes a power of two. You can use .balign or .p2align portably on gas, though.=20 --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

This makes it possible to export symbols from assembly files, instead of having to export them through an extra ksyms.c file. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- Ok, this version uses the .balign as suggested by rusty, and also fixes building with modversions turned on, which did not work in the first version. Arnd <>< --- a/include/linux/module.h +++ b/include/linux/module.h @@ -1,5 +1,7 @@ #ifndef _LINUX_MODULE_H #define _LINUX_MODULE_H + +#ifndef ...

Yes, we have a softirq thread per CPU. We should have a test in the smp_processor_id for rt to not bug if it is called by known "per_cpu" threads. -- Steve --

On Mon, 11 Aug 2008 15:37:33 +0530 This patch applies to mainline, 2.6.27-rc2 and even 2.6.26. Against which kernel/patch is it actually applicable? (If the answer was "all of the above" then please don't go embedding mainline bugfixes in the middle of a -mm-only patch series!) Thanks. --

On Mon, Aug 11, 2008 at 5:31 PM, Andrew Morton The main thing this fixes is the memrlimit controller, which is only in -mm. But there's also a dereference of mm->owner in memcontrol.c - and I think that needs to be fixed to handle a possible NULL mm->owner too, since in the case of a swapoff racing with the last user of an mm exiting, I suspect that the swapoff code could try to pull in a page that gets charged to the mm after its owner has been set to NULL. Paul --

--

I think it is a great idea.. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Hi, thanks for working. I got a linkage error, next; arch/um/drivers/built-in.o: In function `line_ioctl': /data/kernel/mainline/workdir/next/.branches/um/linux/arch/um/drivers/line.c:306: undefined reference to `tioclinux' collect2: ld returned 1 exit status KSYM .tmp_kallsyms1.S nm: '.tmp_vmlinux1': No such file No valid symbol. make: *** [.tmp_kallsyms1.S] Error 1 The tioclinux() is in drivers/char/vt.c and this is compiled when CONFIG_HW_CONSOLE is enabled. I think this config ...

Hi David, On Tue, 12 Aug 2008 10:27:08 +0100 David Howells <dhowells@redhat.com> wrot= One step at a time ... the rename is clearly necessary, but adding "struct cred" can wait. We may not be able to get all the conflicts solved by adding stuff to Linus' tree early. My aim is just to reduce my pain level. :-) --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

On Mon, 11 Aug 2008 17:08:03 -0700 This is old chipset and the error is since kernel 2.6.8 when the untested support was introduced. I would skip stable branches as I used it only few days for now. In fact, it is like adding new hardware which was previously not supported. Regards, Krzysztof --

The nice thing about git is that it doesn't care one whit how something gets moved. So you can - just send me a regular patch (as a git user, it can be the "git shorthand" kind of patch that has explicit renames, but it can be a traditional patch with delete/create pairs too, and git won't care AT ALL because the end result is the same) - or just send me a shell script to do the renames along with a small patch to fix up any other issues that happen as a result of the ...

On Sun, 10 Aug 2008 15:01:07 -0400 This patch will cause me some pain, because people will occasionally change those headers and the plain-old-patch will break. Some better options are a) merge it into Sam's git tree, then he merges it into 2.6.28-rc1 b) you resend the pull request into Linus during the 2.6.28-rc1 merge window c) merge it into mainline immediately Sam, any suggestions here? --

Yes, the code is patched at runtime. But AFAIK markers already provide this stuff (called "immediate values"). Mathieu's tracepoints also do it. But it's not available on all arches. x86 and x86-64 work as far as I remember. --

Oh, good. I'm also thinking to add a macro that expands to simple inline when Sure. Will get back soon. --

Applied, thanks! --

I agree. Any idea how to debug it? Marcin --

Some opcodes are only in <linux/cdrom.h> while the other ones only in <scsi/scsi.h> so it is not that simple without additional effort. I don't have a time for it at the moment (+ I consider it a low-prio task). However if you would like to look into it, please go ahead. Thanks, Bart --

the patch went into linus -git today, you can close this. Thanks, Eric --

This patch was superceeded by a newer version: http://marc.info/?l=linux-kernel&m=121819389913563&w=2 Currently this is in -mm, awaiting merge. -apw --

Please define "boot". E.g. for your harddisk driver alone the probability of not having it included in a randconfig kernel is definitely > 10%. Same goes for the network driver. 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 --

The Berkshire PC-Watchdog card is indeed allready isafied. This is (just like the mixcom and the ICS WDT50x watchdog cards) an ISA card that can be inserted into an ISA slot. (The other two will be isafied also). The shutdown notifier does the same thing then the reboot_notifier. Most of the other drivers (except the 2 PCI cards and 1 USB card) are however directly attached to the motherboard of the system. These are thus in my opinion more platform devices then isa device drivers. The ...

WTF? You are expecting randconfig kernels to boot? 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 --

On Sun, 10 Aug 2008 19:30:28 +0200 Yes, that's better. Acked-by: Stephen Hemminger <shemminger@vyatta.com> --

Yes, latter I'd feel with the thing most against it that there aren't actually many that need it. Here's the list that was posted: http://lkml.org/lkml/2008/8/1/96 Three legacy ISA driver from that list can now be stricken. Hurrah. There's always going to be at least a few that'll remain though. For example, what are you going to do with: --- linux.orig/drivers/ide/Kconfig +++ linux/drivers/ide/Kconfig @@ -9,6 +9,11 @@ config HAVE_IDE menuconfig IDE tristate "ATA/ATAPI/MFM/RLL ...

What happens if another option selects FOO? As soon as you mix select's with dependencies and tristates you are at It is something that would only be used by a handful of kernel developers. It's like randconfig, where having to force CONFIG_STANDALONE=y never 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. ...

Oh, how very, very important. s/RANDOM/!SPECIFIC/ then (and I meant "if RANDOM" ofcourse). The point is just that such a tristate would be a one-stop mark for drivers/options that you want to be specifically selected for builtin use since they're not necessarily expected to boot on general PCs. Rene. --

I think the boot option is the way, if at all. Because the config option isn't very usable. What's to stop someone from doing `make allyesconfig' and then menually editing the .config so it's no longer truly an allyesconfig .config? otoh, if is't purely a manual setting rather than some automagic thing then it might be workable. CONFIG_INGO :) --

The dependencies we express in kconfig are already pretty complicated, and that is continuously causing problems. Stuffing more stuff into kconfig for such an exotic developer-only use case is not a good idea. And as already said, tomorrow someone might want to boot an allyesconfig 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. ...

No, it doesn't indicate a functional regression. In 2.6.26 the WARN_ON() was artificially silenced by USB, but that stopped working after the PM core had changed in 2.6.27-rc. Thanks, Rafael --

The commit e0426e6a09954d205da2d674a3d368d2715e3afd fixes a real race but still isn't enough to prevent these: kobject_add_internal failed for vcs7 with -EEXIST, don't try to register things with the same name in the same direc. Pid: 2967, comm: vcs_stress Not tainted 2.6.25 #10 [<c04e852e>] kobject_add_internal+0x137/0x149 [<c04e85d4>] kobject_add_varg+0x35/0x41 [<c04e8645>] kobject_add+0x43/0x49 [<c055e54f>] device_add+0x91/0x4b4 [<c055e984>] device_register+0x12/0x15 [<c055e9f6>] ...

On Tue, 12 Aug 2008 10:04:14 -0700 Yeah, from a quick look, seems that this patch wrongly handles sg_count. This patch sets scsi_sg_count(sc) to sg_count, right? for_each_sg is expected to be used with a return value of pci_map_sg. Then this patch can simply do something like: for_each_sg(sg, sg, sg_count, i) { pt[i].high = cpu_to_be32(sg_dma_len(sg) << 16); pt[i].low = cpu_to_be32(sg_dma_address(sg)); } --

We really do need to get credentials patch in to common store all this permission/secuirty data.. With a section for integrity related entries. Anti-Virus Passes and fails, signed running programs support and so on. Lot of different things need ways of recording integrity status's. Users also need to know if a application does not work is it TPM is it Anti-virus is it lack of signature. A common way of extracting what the blockage has to be the way forward. Since then this can be ...

Peter, please read up what the credentials patches do, or how struct cred/ucred is used in SVR4 and BSD for the last 20 years. It is useful, but it's not going to help with any of the strange thigns the AV or Integrity people are doing. --

And what happens when the chip simply goes away due to a hotplug action? Or not even the actual chip goes away but just the chip driver and you now dereference freed memory? --

Being a TCG/TPM person, I can only address the first question. The intent is that the TPM is soldered to the planar/motherboard (the TCG uses the phrase "bound to the platform"). I can't imagine any manufacturer designing a pluggable TPM. It would subvert PCR measurements and thus attestation, data sealing, etc. --

Hi, Vivek, On Mon, 2008-08-11 at 09:51 -0400, Vivek Goyal wrote: Not from optimization point of view. machine_kexec() may be called from crash_kexec(), where it is not permitted to take and release a lock. Best Regards, Huang Ying --

Driver in general works after this, error path(s) not tested. -- "rm -rf" only sounds scary if you don't have backups --

Except we don't really want to export all the info you need for a complete restartable checkpoint. And especially not make it generally writable. We have also started down that path using ptrace (see cryo, at git://git.sr71.net/~hallyn/cryodev.git). Right before the containers mini-summit, where the general agreement was that a complete in-kernel solution ought to be pursued, I had tried a restart using a binary format that read a checkpoint file and used cryo (userspace using ptrace) for ...

All true. Hard stuff. The IBM product works partly by limiting migrations to occurring on a single physical ethernet network. Each container gets its own IP and MAC address. The socket state is checkpointed quite fully and moved Me, personally, I think I'd probably "re-link" the thing, mark it as such, ship it across like a normal file, then unlink it after the I respectfully disagree. The number one prerequisite for checkpoint/restart is isolation. Xen just happens to get this for ...

Dave is right on the money: in Zap (the equivalent of) cr_get_fname() may be called with a buffer smaller than PATH_MAX (one page) and hence the need to allocate ad-hoc. Indeed in the current code this is not the One way to reduce the risk is to use an intermediate representation to kernel native data and properties (e.g. classify VMAs during checkpoint instead of relying blindly on the flags). The problem is not so much in restarting a checkpoint image from old kernel on a new kernel - ...

Ok, so there's a mistake in my patch. It should return the loopback MAC address instead. I'm wondering if the fix should be related to initialising rt6i_idev in addrconf_init routine like in the upstream commit: c62dba9011b93fd88fde929848582b2a98309878. The code changed quite a lot. Eugene --

With the patch I posted, this is the behaviour I get: $ ip -f inet6 route get fec0::1 unreachable fec0::1 dev lo table unspec proto none src fe80::214:4fff:fe0f:7332 metric -1 error -101 hoplimit 255 John emailed me that he will be testing this patch. I have not tested Thanks for letting me know. I wasn't familiar, but I welcome the hint. Thanks, Eugene --

Folks I've enclosed patch from Eugene just so we all know which patch we're talking about. It 'works' according to the following definition: a) Fixed OOPS b) runs overnight in our test network. This run doesn't do much specific ipv6 testing - but clearly what's there is catching stuff :-; cheers John -----Original Message----- From: Eugene Teo [mailto:eugeneteo@kernel.sg]=20 Sent: 11 August 2008 12:04 To: Brian Haley Cc: Alexey Dobriyan; John Gumb; ...

Probably not. if FB_SIS is selected at all, DRM_SIS should match it, if FB_SIS isn't selected, DRM_SIS should not select it. Dave. --

Ok. In the real world usage, where we use these instructions both from process and softirq context, we will probably not see much penality, as the process context's first access will always endup doing full fp restore (and also we kick in the context switch FP optimization, which will As there are no further objections, Herbert/Ingo not sure who among you will push this patch to Linus tree and 2.6.26 -stable tree aswell. thanks, suresh --

Yes, I'll test that tomorrow. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leiter EDV Leopoldstraße 15 80802 München Tel: +49 89 38196-276 Fax: +49 89 38196-144 wolfgang.walter@stwm.de http://www.studentenwerk-muenchen.de/ --

I'll push this one along. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

No, there you are actually using the FPU state (which includes the SSE state.) -hpa --

Sorry, the kernel TS state is what I meant. I'm definitely not advocating the saving of the kernel FPU state. This is only for things like the VIA (which also exists for other processors, see the xor SSE stuff in include/asm-x86). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

Yes, it's a fix for PATCH 3/5 -Peter -- | AMD Saxony Limited Liability Company & Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System | Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: Center | AMD Saxony LLC (Wilmington, Delaware, US) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy --

Hi, I see exactly the same on my x60s, but during upgrade to 2.6.26.2. I found that (at least in my case) the problem is, that in 2.6.25 the core frequency drop to 1GHz (instead of 1.67GHz) when the temperature is above some limit. Now, the CPU cores remains on 1.67GHz and fan is unable to cool them properly under heavy load (even if I set "level disengaged" through thinkpad fan control, temperature sensor shows after a while 128 C (probably not real temp, I expect some critical flag => ...

Does this mean you can easily reproduce it? Ok it was just a long shot anyways. -Andi --

Pavel, can you check if the state of the fan(s) change while the thermal trip points are being passed? As I said in http://bugzilla.kernel.org/show_bug.cgi?id=11281, I suspect that this mechanism may be broken. Thanks, Rafael --

and this seems to fix it for me: -- Do not use unsigned int if there is test for negative number... See drivers/acpi/processor_perflib.c static unsigned int ignore_ppc = -1; ... if (event == CPUFREQ_START && ignore_ppc <= 0) { ignore_ppc = 0; ... Signed-off-by: Milan Broz <mbroz@redhat.com> --- drivers/acpi/processor_perflib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: ...

How do you control fans? I could not get anything but -EINVAL from IBM Hmmm... that's seriously strange. I definitely don't see it in 2.6.26. Maybe it is config dependend?! (Attaching my 2.6.27-rc2 failing config.) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

yes. maybe some userspace tool controlling frequency is involved, no idea yet. No, it is not ok. you need add fan_control=1 to thinkpad_acpi module http://www.thinkwiki.org/wiki/How_to_control_fan_speed hm. strange, I'll try this config too... Milan --

I didn't know that, sorry. --

Is the complete patch available anywhere? I need a link to it for the list of regressions. Thanks, Rafael --

On Mon, Aug 11, 2008 at 11:17:34PM -0600, dann frazier wrote: | This is readily reproducible - a simple kernel compile was all it | took. git bisecting suggests that this issue was introduced by [1] | and unmasked by [2] during 2.6.26 devlopment. It was later fixed | during 2.6.27 development by [3]. | | [1] 35605a1027ac630f85a1b95684f7e86b82498cd6 | [2] 8d539108560ec121d59eee05160236488266221c | [3] 8004dd965b13b01a96def054d420f6df7ff22d53 See http://bugs.debian.org/494365 for ...

OK I got this to work, will send patches soon. Luis --

Are you looking at -mm or linux-next? In my tree I see: arch/ia64/mm/contig.c: for (i = 0; i < num_rsvd_regions; i++) { arch/ia64/mm/contig.c: range_end = min(end, rsvd_region[i].start & PAGE_MASK); arch/ia64/mm/contig.c: free_start = PAGE_ALIGN(rsvd_region[i].end); -Tony --

Yep, that should work. When it does not, it means BIOS is not returning to our real mode code :-(. You may want to try disabling APIC and similar stuff, in hope of working around BIOS bug you are hitting, but ... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Hi Matthew, OK, so your regression is something else then. Well, thanks for testing! --

Thank you for the heads-up. - Fernando --

Wow! Didn't mean to start a "tech war" here (point's at the long I don't remember installing any special driver for Windows XP. Since you claim that as a possibility, is there something that I can look for to check if this is the case? The reason I'm questioning this so much is because I plan to contact Shuttle tech support and try to get them to fix this if it really is a BIOS issue. But I need valid points to make sure they don't pass on the blame and slip away. They do seem to release BIOS ...

Sorry, I was a bit too surprised after your description. 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 --

Dave, Would it be possible to pull this kernel into gdb and show me the output of: gdb> li *0xffffffff81094d61 and a gdb> disass 0xffffffff81094d61 Thanks, --

Well, there is demand for accerated iscsi out there, which is the driving Herbert requested some benchmark numbers, I consequently obliged. Cheers, Divy --

From: Steve Wise <swise@opengridcomputing.com> When I say shape I mean apply any packet scheduler, any netfilter module, and any other feature we support. --

From: Divy Le Ray <divy@chelsio.com> So, WHAT?! There are TOE pieces of crap out there too. It's strictly not our problem. Like Herbert said, this is the TOE discussion all over again. The results will be the same, and as per our decisions wrt. TOE, history speaks for itself. --

[stable@kernel.org added to CC] The 2.6.27 version of the patch has already been pushed upstream, this one is for 2.6.26-stable since this fixes a regression introduced after 2.6.25. --

thank you for the remark. I have changed the mdelay to msleep in my patch, reapplied it to the current Linus tree, built a kernel, installed it on my computer and tested it. It works perfectly as you surely expected. The corrected patch is included here. BTW: I have noticed that some other drivers in video/backlight still use mdelay: ili9320.c, locomolcd.c and vgg2432a4.c. claudio Signed-off-by: Claudio Nieder <private@claudio.ch> --- drivers/video/backlight/Kconfig | 7 + ...

Hi Thomas, any news on that so far? Cheers, Johannes --

I would say this will be the wrong usage of deadline, atleast with the two timer and no round off implementation. For this example, it will probably be better to use round_jiffies to round the timer to second level and make it go in sync with all other round timers on this CPU, rather than setting two timers with hard timer not in sync with other timers on the CPU. - if there are other timers (rounded or otherwise) on this CPU that goes off between 5-10 seconds, we are paying penalty for ...

The cursor really really needs to be steady to within a few frames or you will notice it. Not using blinking cursors would of course be even better (or sneaking the blink into the graphics hardware ;)) Your API also needs to use some kind of internal time concept that can be shared between virtual machines because the end product of this done right has to be to push timer scheduling at the basic level into the hypervisor because it needs to merge timer events across guests. Anything less and ...

I'm printing the values of the two config registers into the string buffer, separated by tabs, and terminated by an EOL. Is there a prefered way to do that instead of what I have? -Mark Langsdorf Operating System Research Center AMD --

Not sure, lets ask greg. And it probably should have few lines in Documentation going with it, so we know new interface is added and So you print "buf" few times? Why? And you use both \t and \n as deliminer... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Yes, two different files, one for each config register. thanks, greg k-h --

On Mon, 11 Aug 2008 21:23:01 +0200 (CEST) This code adds new kernel->userspace interfaces? Please fully document those interfaces so that we can review the proposed design. What follows is a low-level review. I didn't really address the higher-level design aspects because even having read it, I don't know what all this code does, because I wasn't told. I could work that out, but I'd prefer not to have to, because that means that everyone else who wishes to maintain this code would need ...

I would disagree. We use ERR_PTR() and other macros with errors. Using See "diddums" message above. You mess up tools like strace if you don't fix this and strace is more important than some minor driver detail caused by not upstreaming code earlier. The non unlocked version of ioctl() is going away and the BKL will in time follow so you might as well deal with that now too. --

OK, I could work on this machine again and have some news. I had another bug on 2.6.26 causing hang at almost the same place and fixed by a0176e2485ce6468f9b74264a2fd6c19811f027a. I can confirm that pcie_noaspm is now enough to boot on this machine and will try to identify the faulty device --

So close, can I have a good changelog comment with the patch so people know what it is when they look in the logs? Care to resend it with that? thanks, greg k-h --

Base infrastructure to enable per-module debug messages. I've introduced CONFIG_DYNAMIC_PRINTK_DEBUG, which when enabled centralizes control of debugging statements on a per-module basis in one /proc file, currently, <debugfs>/dynamic_printk/modules. When, CONFIG_DYNAMIC_PRINTK_DEBUG, is not set, debugging statements can still be enabled as before, often by defining 'DEBUG' for the proper compilation unit. Thus, this patch set has no affect when CONFIG_DYNAMIC_PRINTK_DEBUG is not set. The ...

This pacth is wrong it causes that all IBSS traffic is transmitted rate of BEACON (1MBit) , which is pretty bad performance like. We are working on possible fixes. --

Any updates on this bug. Thanks and Regards R.Nageswara Sastry --

Hi Nageswara, Sorry. I was just looking into it again and still see no resolution. Added Venkatesh and Alexey to CC. To summarize again: The problem we have is that cpufreq_ondemand has a self-rearming worker function which we should but can not cancel synchroneously with the current code. The locking order is like this: store() policy_rwsem write cpufreq_governor_dbs() dbs_mutex work lock do_dbs_timer() policy_rwsem write which gives a locking hierarchy ...

From: David Miller <davem@davemloft.net> This patch, on top of my original IRQSTACKS patch for sparc64, seems to get things working for me. diff --git a/arch/sparc64/lib/mcount.S b/arch/sparc64/lib/mcount.S index 9e4534b..24e6a3c 100644 --- a/arch/sparc64/lib/mcount.S +++ b/arch/sparc64/lib/mcount.S @@ -45,11 +45,47 @@ _mcount: sub %g3, STACK_BIAS, %g3 cmp %sp, %g3 bg,pt %xcc, 1f - sethi %hi(panicstring), %g3 + nop +#ifdef CONFIG_IRQSTACKS + lduh [%g6 + TI_CPU], ...

From: Adrian Bunk <bunk@kernel.org> This patch makes the following needlessly global functions static: - ibft_attr_show_initiator() - ibft_attr_show_nic() - ibft_attr_show_target() Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Konrad Rzeszutek <ketuzsezr@darnok.org> --- drivers/firmware/iscsi_ibft.c | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/firmware/iscsi_ibft.c b/drivers/firmware/iscsi_ibft.c index 8024e3b..8523811 ...

Greg, Please at your convience include this patch in your update to the drivers/firmware directory if it is not too much trouble. Thank you, Konrad Rzeszutek iscsi_ibft.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) --