headers
Andrew Worsley | 1 Jun 2011 01:04
Picon

Re: [PATCH] init, calibrate: Drop annoying warning

I can see your point - it's useful when debugging the bogomips issue -
but if it's working it's not relevant.
Would be nice to have an extra level of verbose debug or a debug
branch of the file or perhaps just a relevant comment
that would easily allow it to be found and reverted to re-enable debug
if people want to debug this stuff again.

That said I would suggest just changing the comment (I don't know how
to just submit a comment change?) to something like:

"Drop calibrate_delay_direct() KERN_DEBUG printk related to bogomips
calculation as it appears when booting
every core on setups with 'ignore_loglevel' for people who want to
test latest kernels and scan dmesg for possible issues.
and this information isn't very useful to the widest audience of
kernel boot message gazers."

which would allow an easy revert locally when ever it was deemed useful.

On 1 June 2011 04:29, Borislav Petkov <bp <at> amd64.org> wrote:
> From: Borislav Petkov <borislav.petkov <at> amd.com>
>
> Even though the error message is KERN_DEBUG, it appears when booting
> every core on setups with 'ignore_loglevel' for people who want to test
> latest kernels and scan dmesg for possible issues. Also, it doesn't show
> very useful information to the widest audience of kernel boot message
> gazers so drop it.
>
> Introduced by d2b463135f84d15808163cd15638b108e323d3e7.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joel Becker | 1 Jun 2011 01:07

Re: [PATCH] ocfs2: use proper little-endian bitops

On Tue, May 31, 2011 at 03:57:13PM -0700, Mark Fasheh wrote:
> On Mon, May 30, 2011 at 09:58:05PM +0900, Akinobu Mita wrote:
> > Using __test_and_{set,clear}_bit_le() with ignoring its return value
> > can be replaced with __{set,clear}_bit_le().
> > 
> > Signed-off-by: Akinobu Mita <akinobu.mita <at> gmail.com>
> > Cc: Joel Becker <jlbec <at> evilplan.org>
> > Cc: Mark Fasheh <mfasheh <at> suse.com>
> > Cc: ocfs2-devel <at> oss.oracle.com
> 
> Looks reasonable to me...
> 
> Signed-off-by: Mark Fasheh <mfasheh <at> suse.com>
> 
> Joel?

	No argument here.  Akinobu, do you want me to send it with ocfs2
fixes, or are you going to push it along?

Acked-by: Joel Becker <jlbec <at> evilplan.org>

Joel

--

-- 

"Lately I've been talking in my sleep.
 Can't imagine what I'd have to say.
 Except my world will be right
 When love comes back my way."
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christian Kujau | 1 Jun 2011 01:50
Picon

3.0-rc1: powerpc hangs at Kernel virtual memory layout

Hi,

trying to boot 3.0-rc1 on powerpc32 only progresses until:

  > Kernel virtual memory layout:
  >   * 0xfffcf000..0xfffff000  : fixmap

And then the system hangs, does not respond to keyboard (sysrq does not 
seem to work on this PowerBook G4). But after a while the system reboots 
itself, so I guess the machine panicked but did not print anything on the 
screen.

Full messages (picture), config & (working) dmesg:

   http://nerdbynature.de/bits/3.0-rc1/

I'm currently trying to bisect this, so far I have:

----------------------
git bisect start
# good: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
git bisect good 61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf
# bad: [55922c9d1b84b89cb946c777fddccb3247e7df2c] Linux 3.0-rc1
git bisect bad 55922c9d1b84b89cb946c777fddccb3247e7df2c
# bad: [c44dead70a841d90ddc01968012f323c33217c9e] Merge branch 'usb-next' 
of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6
git bisect bad c44dead70a841d90ddc01968012f323c33217c9e
# bad: [d93515611bbc70c2fe4db232e5feb448ed8e4cc9] macvlan: fix panic if 
lowerdev in a bond
git bisect bad d93515611bbc70c2fe4db232e5feb448ed8e4cc9
(Continue reading)

Permalink | Reply | 36 comments |
headers
Akinobu Mita | 1 Jun 2011 01:52
Picon

Re: [PATCH] ocfs2: use proper little-endian bitops

>        No argument here.  Akinobu, do you want me to send it with ocfs2
> fixes, or are you going to push it along?
>
> Acked-by: Joel Becker <jlbec <at> evilplan.org>

Thanks. Please add it to ocfs2 tree.
Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Jun 2011 01:56

[PATCH] block: blkdev_get() should acess ->bd_disk only after success

d4dc210f69 (block: don't block events on excl write for non-optical
devices) added dereferencing of bdev->bd_disk to test
GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE; however, bdev->bd_disk can be
%NULL if open failed which can lead to an oops.

Test the flag after testing open was successful, not before.

Signed-off-by: Tejun Heo <tj <at> kernel.org>
Reported-by: David Miller <davem <at> davemloft.net>
Tested-by: David Miller <davem <at> davemloft.net>
Cc: stable <at> kernel.org
---
 fs/block_dev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index 1f2b199..1a2421f 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
 <at>  <at>  -1272,8 +1272,8  <at>  <at>  int blkdev_get(struct block_device *bdev, fmode_t mode, void *holder)
 		 * individual writeable reference is too fragile given the
 		 * way  <at> mode is used in blkdev_get/put().
 		 */
-		if ((disk->flags & GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE) &&
-		    !res && (mode & FMODE_WRITE) && !bdev->bd_write_holder) {
+		if (!res && (mode & FMODE_WRITE) && !bdev->bd_write_holder &&
+		    (disk->flags & GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE)) {
 			bdev->bd_write_holder = true;
 			disk_block_events(disk);
 		}
(Continue reading)

Permalink | Reply | 1 comment |
headers
Maarten Lankhorst | 1 Jun 2011 01:57
Picon

Re: [PATCH] [RFC] usb: Do not attempt to reset the device while it is disabled

Op 01-06-11 00:35, Sarah Sharp schreef:
> On Tue, May 31, 2011 at 09:07:32PM +0200, Maarten Lankhorst wrote:
>> Op 31-05-11 20:18, Sarah Sharp schreef:
>>> On Tue, May 31, 2011 at 07:41:14PM +0200, Maarten Lankhorst wrote:
>> My xhci controller is this one:
>> 04:00.0 USB Controller: Device 1b6f:7023 (rev 01) (prog-if 30 [XHCI])
>> Subsystem: ASRock Incorporation Device 7023
> Ok, the PCI SIGG says that vendor ID is assigned to Etron.  Congrats,
> that's the first xHCI host controller I've seen from that company. :)
Hooray.
> Ok, so the xHCI driver does successfully get a slot from the host
> controller.
>
>> [  545.664041] xhci_hcd 0000:04:00.0: Allocating ring at ffff8801c7d7ccc0
>> [  545.664044] xhci_hcd 0000:04:00.0: Allocating priv segment structure at ffff8801e2e26c40
>> [  545.664047] xhci_hcd 0000:04:00.0: // Allocating segment at ffff8800bac3f800 (virtual)
0xbac3f800 (DMA)
>> [  545.664053] xhci_hcd 0000:04:00.0: Linking segment 0xbac3f800 to segment 0xbac3f800 (DMA)
>> [  545.664056] xhci_hcd 0000:04:00.0: Wrote link toggle flag to segment ffff8801e2e26c40 (virtual),
0xbac3f800 (DMA)
>> [  545.664059] xhci_hcd 0000:04:00.0: Set slot id 1 dcbaa entry ffff8800bac3e008 to 0xbac21000
>> [  545.664070] xhci_hcd 0000:04:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90001ce0420, 32'h2f1, 4'hf);
> But I don't see an Address Device command complete here.  The command
> submission probably caused that memory write, but there really should be
> more debugging here.  I'll have to look through the hub initialization
> and see if there is any error path that would make it skip setting the
> device address.
>
> Have you tried on Linux 3.0-rc1?
Same problem with 3.0rc1 it seems. Just look at hub_port_init, that appears to be where it's going wrong:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frederic Weisbecker | 1 Jun 2011 02:00
Picon

Re: [PATCH v2] trace: Add x86 irq vector entry/exit tracepoints

On Tue, May 31, 2011 at 02:28:18PM -0700, Vaibhav Nagarnaik wrote:
> From: Jiaying Zhang <jiayingz <at> google.com>
> 
> The current interrupt trace of irq_handler_entry and irq_handler_exit
> give traces of when an interrupt is handled. They provide good data
> about when the system is running in kernel space and how it affects the
> currently running applications.
> 
> Apart from this, they are IRQ vectors which trigger the system into
> kernel space. Tracing such events gives us the trace of where the system
> is spending its time. We want to know which cores are handling
> interrupts and how they are affecting other processes in the system.
> Also, the trace provides information about when the cores are idle and
> which interrupts are changing that state.
> 
> The following patch adds the event definition and trace instrumentation
> for interrupt vectors. For x86, a lookup table is provided to print out
> readable IRQ vector names. The template can be used to provide interrupt
> vector lookup tables on other architectures.
> 
> With this patch, following interrupt vectors are logged by ftrace
> (when enabled):
> 
> Interrupt as in /proc/interrupts        Name as it appears in ftrace log
> NMI: Non-maskable interrupts           : NMI_VECTOR
> LOC: Local timer interrupts            : LOCAL_TIMER_VECTOR
> SPU: Spurious interrupts               : SPURIOUS_APIC_VECTOR
> PMI: Performance monitoring interrupts : <not added>
> IWI: IRQ work interrupts               : IRQ_WORK_VECTOR
> RES: Rescheduling interrupts           : RESCHEDULE_VECTOR
(Continue reading)

Permalink | Reply | 13 comments |
headers
lkml | 1 Jun 2011 02:28

bdi_min_ratio never shrinks, ultimately preventing valid setting of min_ratio

mm/page-writeback.c
There is a static global bdi_min_ratio used for policing the setting of
per-bdi min_ratio's, to ensure the sum doesn't cross 100.

There is no place in this listing where the value is decremented by the
respective bdi's min_ratio when a bdi is torn down.  This looks like a bug
to me, and I have a situation where I'm unable to set a min_ratio to 1
where the sum of /sys/class/bdi/*/min_ratio does not add up to 100, which
is what triggered this investigation.

Regards,
Vito Caputo
Permalink | Reply | 6 comments |
headers
Christoph Hellwig | 1 Jun 2011 02:36
Favicon

Re: [PATCH 2/14] mm: move vmtruncate_range to truncate.c

On Mon, May 30, 2011 at 05:36:57PM -0700, Hugh Dickins wrote:
> You would expect to find vmtruncate_range() next to vmtruncate()
> in mm/truncate.c: move it there.

Sounds fine to me.
Permalink | Reply | 0 comments |
headers
Christian Kujau | 1 Jun 2011 02:48
Picon

Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout

On Wed, 1 Jun 2011 at 10:25, Benjamin Herrenschmidt wrote:
> Hrm, I had it working on a pair of powerbooks yesterday. Can you try
> something like "udbg-immortal" on your kernel command line to see if
> that makes a difference in the output ?

I'll try in a minute.

In the meantime, "git bisect" behaves kinda weird, I don't know what went 
wrong here:

 $ git bisect start
 $ git bisect good         # Linux 2.6.39
 $ git bisect bad v3.0-rc1 # Linux 3.0-rc1
 $ git bisect bad          # c44dead70a...
 $ git bisect bad          # d93515611b..

...yet the ./Makefile shows[0] that I'm already way behind: 2.6.39-rc2. 
Maybe "git bisect" got confused with that whole 2.6.x -> 3.0 renaming?

Christian.

[0] http://nerdbynature.de/bits/3.0-rc1/
--

-- 
BOFH excuse #383:

Your processor has taken a ride to Heaven's Gate on the UFO behind Hale-Bopp's comet.
Permalink | Reply | 6 comments |

Gmane