* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Christoph Lameter @ 2008-03-04 20:01 UTC (permalink / raw)
To: Pekka Enberg
Cc: linux-mm, Mel Gorman, Kamalesh Babulal, linuxppc-dev,
Andrew Morton
In-Reply-To: <84144f020803041141x5bb55832r495d7fde92356e27@mail.gmail.com>
On Tue, 4 Mar 2008, Pekka Enberg wrote:
> > > >> [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
> > > >> [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
> > > >> [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
> > > >> [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144
Ahh! This is SLAB. slub does not suffer this problem since new_slab()
masks the bits correctly.
So we need to fix SLAB.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Christoph Lameter @ 2008-03-04 20:02 UTC (permalink / raw)
To: Pekka J Enberg
Cc: linux-mm, Mel Gorman, Kamalesh Babulal, linuxppc-dev,
Andrew Morton
In-Reply-To: <Pine.LNX.4.64.0803042200410.8545@sbz-30.cs.Helsinki.FI>
On Tue, 4 Mar 2008, Pekka J Enberg wrote:
> On Tue, 4 Mar 2008, Christoph Lameter wrote:
> > Slab allocations should never be passed these flags since the slabs do
> > their own thing there.
> >
> > The following patch would clear these in slub:
>
> Here's the same fix for SLAB:
That is an immediate fix ok. But there must be some location where SLAB
does the masking of the gfp bits where things go wrong. Looking for that.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Christoph Lameter @ 2008-03-04 20:07 UTC (permalink / raw)
To: Pekka J Enberg
Cc: linux-mm, Mel Gorman, Kamalesh Babulal, linuxppc-dev,
Andrew Morton
In-Reply-To: <Pine.LNX.4.64.0803042200410.8545@sbz-30.cs.Helsinki.FI>
I think this is the correct fix.
The NUMA fallback logic should be passing local_flags to kmem_get_pages()
and not simply the flags.
Maybe a stable candidate since we are now simply
passing on flags to the page allocator on the fallback path.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
---
mm/slab.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.25-rc3-mm1/mm/slab.c
===================================================================
--- linux-2.6.25-rc3-mm1.orig/mm/slab.c 2008-03-04 12:01:07.430911920 -0800
+++ linux-2.6.25-rc3-mm1/mm/slab.c 2008-03-04 12:04:54.449857145 -0800
@@ -3277,7 +3277,7 @@ retry:
if (local_flags & __GFP_WAIT)
local_irq_enable();
kmem_flagcheck(cache, flags);
- obj = kmem_getpages(cache, flags, -1);
+ obj = kmem_getpages(cache, local_flags, -1);
if (local_flags & __GFP_WAIT)
local_irq_disable();
if (obj) {
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Pekka Enberg @ 2008-03-04 20:08 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-mm, Mel Gorman, Kamalesh Babulal, linuxppc-dev,
Andrew Morton
In-Reply-To: <Pine.LNX.4.64.0803041205370.18277@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> I think this is the correct fix.
>
> The NUMA fallback logic should be passing local_flags to kmem_get_pages()
> and not simply the flags.
>
> Maybe a stable candidate since we are now simply
> passing on flags to the page allocator on the fallback path.
>
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
Indeed, good catch. I spotted the same thing just few seconds ago.
Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>
Was it you Kamalesh that reported this? Can you please re-test?
^ permalink raw reply
* Re: V4L2: __ucmpdi2 undefined on ppc
From: Segher Boessenkool @ 2008-03-04 20:32 UTC (permalink / raw)
To: David Woodhouse; +Cc: paulus, henrik.sorensen, Stephane Marchesin, linuxppc-dev
In-Reply-To: <1204648648.3891.439.camel@pmac.infradead.org>
>> Every occurrence of r7 here is wrong (and some of the r6).
>
> Can you elucidate?
Sure! It should read either "7" or "cr7".
>> Is there any reason to do this in assembler code at all?
>
> Is there any particular reason not to?
1) If written in assembler, it needs to be written for every
architecture
separately, and sometimes even for every architecture variant (32 vs. 64
bit is only the tip of the iceberg).
2) As shown here as well as in the recent strncmp() patch, it is a lot
harder
to write correct assembler code than it is to write correct C code(*),
and
the C code isn't less efficient either.
Segher
(*) Well, the generic C strncmp() code in the kernel is broken too, bad
example perhaps :-)
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Andrew Morton @ 2008-03-04 20:34 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linux-mm, mel, kamalesh, linuxppc-dev, penberg, stable
In-Reply-To: <Pine.LNX.4.64.0803041205370.18277@schroedinger.engr.sgi.com>
On Tue, 4 Mar 2008 12:07:39 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:
> I think this is the correct fix.
>
> The NUMA fallback logic should be passing local_flags to kmem_get_pages()
> and not simply the flags.
>
> Maybe a stable candidate since we are now simply
> passing on flags to the page allocator on the fallback path.
Do we know why this is only reported in 2.6.25-rc3-mm1?
Why does this need fixing in 2.6.24.x?
Thanks.
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
>
> ---
> mm/slab.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6.25-rc3-mm1/mm/slab.c
> ===================================================================
> --- linux-2.6.25-rc3-mm1.orig/mm/slab.c 2008-03-04 12:01:07.430911920 -0800
> +++ linux-2.6.25-rc3-mm1/mm/slab.c 2008-03-04 12:04:54.449857145 -0800
> @@ -3277,7 +3277,7 @@ retry:
> if (local_flags & __GFP_WAIT)
> local_irq_enable();
> kmem_flagcheck(cache, flags);
> - obj = kmem_getpages(cache, flags, -1);
> + obj = kmem_getpages(cache, local_flags, -1);
> if (local_flags & __GFP_WAIT)
> local_irq_disable();
> if (obj) {
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: Segher Boessenkool @ 2008-03-04 20:39 UTC (permalink / raw)
To: benh; +Cc: kvm-ppc-devel, linuxppc-dev, Stefan Roese, Hollis Blanchard
In-Reply-To: <1204612384.21545.50.camel@pasglop>
>> Using '8' is correct. PCI interrupts are *always* level sensitive and
>> active
>> low.
>
> Unless you use one of those strange bridges that stick not gates on the
> PCI IRQ inputs :-) But I don't think that's the case on the 440EP.
More generally, the target interrupt descriptors (sense values, in
particular) in a device tree interrupt map describe the interrupts as
seen on the target interrupt controller, *not* as seen on this (source)
interrupt domain. This should be obvious, but since the source
interrupt
descriptor for PCI doesn't have a sense value (it's always level low,
after all), it can be confusing. Well, interrupts always are confusing
:-)
Segher
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: Benjamin Herrenschmidt @ 2008-03-04 20:41 UTC (permalink / raw)
To: Segher Boessenkool
Cc: kvm-ppc-devel, linuxppc-dev, Stefan Roese, Hollis Blanchard
In-Reply-To: <9eeb7e8e1acf8a9217a5121fe4ec69d8@kernel.crashing.org>
On Tue, 2008-03-04 at 21:39 +0100, Segher Boessenkool wrote:
> >> Using '8' is correct. PCI interrupts are *always* level sensitive and
> >> active
> >> low.
> >
> > Unless you use one of those strange bridges that stick not gates on the
> > PCI IRQ inputs :-) But I don't think that's the case on the 440EP.
>
> More generally, the target interrupt descriptors (sense values, in
> particular) in a device tree interrupt map describe the interrupts as
> seen on the target interrupt controller, *not* as seen on this (source)
> interrupt domain. This should be obvious, but since the source
> interrupt
> descriptor for PCI doesn't have a sense value (it's always level low,
> after all), it can be confusing. Well, interrupts always are confusing
> :-)
Sure. But if your stupid bridge sticks a not gate between the PIRQ input
and the UIC (interrupt controller), effectively, the UIC sees a reversed
polarity. Thus you need to put in your interrupt map a reversed polarity
information for the UIC interrupt specifiers.
Ben.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Pekka Enberg @ 2008-03-04 20:44 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, mel, kamalesh, linuxppc-dev, stable, Christoph Lameter
In-Reply-To: <20080304123459.364f879b.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Tue, 4 Mar 2008 12:07:39 -0800 (PST)
> Christoph Lameter <clameter@sgi.com> wrote:
>
>> I think this is the correct fix.
>>
>> The NUMA fallback logic should be passing local_flags to kmem_get_pages()
>> and not simply the flags.
>>
>> Maybe a stable candidate since we are now simply
>> passing on flags to the page allocator on the fallback path.
>
> Do we know why this is only reported in 2.6.25-rc3-mm1?
>
> Why does this need fixing in 2.6.24.x?
Looking at the code, it's triggerable in 2.6.24.3 at least. Why we don't
have a report yet, probably because (1) the default allocator is SLUB
which doesn't suffer from this and (2) you need a big honkin' NUMA box
that causes fallback allocations to happen to trigger it.
Pekka
^ permalink raw reply
* Re: [PATCH] [POWERPC] (testers ?) Fix sleep on some powerbooks
From: Gaudenz Steinlin @ 2008-03-04 20:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <20080304161518.GA4523@localhost>
Hi Ben
On Tue, Mar 04, 2008 at 05:15:18PM +0100, Wolfgang Pfeiffer wrote:
> Hi Ben, Gaudenz - Hi All
>
> On Mon, Mar 03 2008, at 17:27 +1100, Benjamin Herrenschmidt wrote:
> > The PMU backlight code would kick in during sleep/resume even on
> > machines that use a different backlight method. This appears to
> > break sleep on my PowerBook, though I can't test that patch at
> > the moment as the machine died while I was bisecting.
> >
> > So if anybody around has one of those latest revision PowerPC
> > PowerBooks, the one just before they went to Intel,
>
> yes, I think so:
>
> $ cat /proc/cpuinfo
> processor : 0
> cpu : 7447A, altivec supported
> clock : 1666.666000MHz
> revision : 0.5 (pvr 8003 0105)
> bogomips : 33.15
> timebase : 8320000
> platform : PowerMac
> machine : PowerBook5,8
> motherboard : PowerBook5,8 MacRISC3 Power Macintosh
> detected as : 287 (PowerBook G4 15")
> pmac flags : 00000019
> L2 cache : 512K unified
> pmac-generation : NewWorld
>
>
> > and have a
> > problem with suspend/resume, please test this and let me know
> > if it helps.
>
> It helps. Thanks a lot .. :) ...
For me it fixes the problem too. I have the same machine.
Gaudenz
--
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: Segher Boessenkool @ 2008-03-04 20:59 UTC (permalink / raw)
To: benh; +Cc: kvm-ppc-devel, linuxppc-dev, Stefan Roese, Hollis Blanchard
In-Reply-To: <1204663317.21545.73.camel@pasglop>
>> More generally, the target interrupt descriptors (sense values, in
>> particular) in a device tree interrupt map describe the interrupts as
>> seen on the target interrupt controller, *not* as seen on this
>> (source)
>> interrupt domain. This should be obvious, but since the source
>> interrupt
>> descriptor for PCI doesn't have a sense value (it's always level low,
>> after all), it can be confusing. Well, interrupts always are
>> confusing
>> :-)
>
> Sure. But if your stupid bridge sticks a not gate between the PIRQ
> input
> and the UIC (interrupt controller), effectively, the UIC sees a
> reversed
> polarity. Thus you need to put in your interrupt map a reversed
> polarity
> information for the UIC interrupt specifiers.
That's what I said, isn't it? :-)
Segher
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: Benjamin Herrenschmidt @ 2008-03-04 21:01 UTC (permalink / raw)
To: Segher Boessenkool
Cc: kvm-ppc-devel, linuxppc-dev, Stefan Roese, Hollis Blanchard
In-Reply-To: <1a852cd10d2aab54aaa7d810649ab1b3@kernel.crashing.org>
On Tue, 2008-03-04 at 21:59 +0100, Segher Boessenkool wrote:
> >> More generally, the target interrupt descriptors (sense values, in
> >> particular) in a device tree interrupt map describe the interrupts as
> >> seen on the target interrupt controller, *not* as seen on this
> >> (source)
> >> interrupt domain. This should be obvious, but since the source
> >> interrupt
> >> descriptor for PCI doesn't have a sense value (it's always level low,
> >> after all), it can be confusing. Well, interrupts always are
> >> confusing
> >> :-)
> >
> > Sure. But if your stupid bridge sticks a not gate between the PIRQ
> > input
> > and the UIC (interrupt controller), effectively, the UIC sees a
> > reversed
> > polarity. Thus you need to put in your interrupt map a reversed
> > polarity
> > information for the UIC interrupt specifiers.
>
> That's what I said, isn't it? :-)
Maybe, I wasn't sure I decrypted you properly :-)
Ben.
^ permalink raw reply
* Re: [PATCH] [POWERPC] (testers ?) Fix sleep on some powerbooks
From: Wolfgang Pfeiffer @ 2008-03-04 21:28 UTC (permalink / raw)
To: debian-powerpc; +Cc: linuxppc-dev
In-Reply-To: <20080304161518.GA4523@localhost>
On Tue, Mar 04 2008, at 17:15 +0100, Wolfgang Pfeiffer wrote:
>
>
> [ ... ]
> I uploaded this fresh kernel .deb, patched with your code, up to
> rapidshare:
> http://rapidshare.com/files/96992135/linux-image-2.6.25-rc3-g7704a8b-with-ben.s-pmu-patch_2008.02.29_powerpc.deb.html
>
> md5sum for the file above is 7a7613e0c52e179acf7caacaa3890901
"the file" should say:
linux-image-2.6.25-rc3-g7704a8b-with-ben.s-pmu-patch_2008.02.29_powerpc.deb
Sorry for the overhead ...
Regards
--
Wolfgang
http://heelsbroke.blogspot.com/
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: V4L2: __ucmpdi2 undefined on ppc
From: Paul Mackerras @ 2008-03-04 21:44 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, henrik.sorensen, Stephane Marchesin,
David Woodhouse
In-Reply-To: <15d7ac5a7542b05fb9b9abb5d4c7a22d@kernel.crashing.org>
Segher Boessenkool writes:
> Every occurrence of r7 here is wrong (and some of the r6). Is there
> any reason to do this in assembler code at all?
The fact that the obvious C code generates ... a call to __ucmpdi2? :)
Paul.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Christoph Lameter @ 2008-03-04 21:44 UTC (permalink / raw)
To: Pekka Enberg; +Cc: linux-mm, mel, kamalesh, linuxppc-dev, Andrew Morton, stable
In-Reply-To: <47CDB498.6040003@cs.helsinki.fi>
On Tue, 4 Mar 2008, Pekka Enberg wrote:
> Looking at the code, it's triggerable in 2.6.24.3 at least. Why we don't have
> a report yet, probably because (1) the default allocator is SLUB which doesn't
> suffer from this and (2) you need a big honkin' NUMA box that causes fallback
> allocations to happen to trigger it.
Plus the issue only became a problem after the antifrag stuff went in.
That came with SLUB as the default.
^ permalink raw reply
* Re: V4L2: __ucmpdi2 undefined on ppc
From: Scott Wood @ 2008-03-04 21:47 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, henrik.sorensen, Stephane Marchesin,
David Woodhouse
In-Reply-To: <18381.49853.255430.142431@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Segher Boessenkool writes:
>
>> Every occurrence of r7 here is wrong (and some of the r6). Is there
>> any reason to do this in assembler code at all?
>
> The fact that the obvious C code generates ... a call to __ucmpdi2? :)
So use the correct C code, not the obvious C code. :-)
-Scott
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel bug while running libhugetlbfs
From: Adam Litke @ 2008-03-04 22:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, balbir, linux-kernel, Kamalesh Babulal
In-Reply-To: <20080304115158.505f33eb.akpm@linux-foundation.org>
On Tue, 2008-03-04 at 11:51 -0800, Andrew Morton wrote:
> hugetlb-correct-page-count-for-surplus-huge-pages.patch adds:
>
> if (page) {
> /*
> * This page is now managed by the hugetlb allocator and has
> * no users -- drop the buddy allocator's reference.
> */
> int page_count = put_page_testzero(page);
> BUG_ON(page_count != 0);
>
>
Ugh I got bitten by put_page_testzero(). When it returns 1, the page
count is zero (not the page count).
My initial version had a BUG_ON() with side-effects. When a reviewer
pointed it out, I thought I could fix the patch up on its way out the
door. I have self-administered my punishment. This patch will fix it:
Signed-off-by: Adam Litke <agl@us.ibm.com>
--- mm/hugetlb.c.orig 2008-03-04 13:36:30.000000000 -0800
+++ mm/hugetlb.c 2008-03-04 13:39:30.000000000 -0800
@@ -291,8 +291,8 @@ static struct page *alloc_buddy_huge_pag
* This page is now managed by the hugetlb allocator and has
* no users -- drop the buddy allocator's reference.
*/
- int page_count = put_page_testzero(page);
- BUG_ON(page_count != 0);
+ put_page_testzero(page);
+ VM_BUG_ON(page_count(page));
nid = page_to_nid(page);
set_compound_page_dtor(page, free_huge_page);
/*
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
^ permalink raw reply
* Unable to set cache write-thru on 7447A
From: Matthew Clark @ 2008-03-04 21:56 UTC (permalink / raw)
To: Linuxppc-dev
I'm trying to run my 2.6.14 Gentoo distro on a 7447A system I have
with different cache configurations (ie, write back vs write thru) for
both the kernel, system apps (sshd, etc) and user apps. I first
wanted to run entirely in Write-Thru to get a worst-case benchmark,
but after discovering (to my chagrin) that the 7447A doesn't honor the
L2CR_L2WT bit, I tried something a bit more adventurous by setting the
WIMG bits on the linux PTE's in the arch/ppc files.
Rather, I thought I would. Nothing I've tried seems to work.
In arch/ppc/mm/ppc_mmu.c
Adding _PAGE_WRITETHRU to the _PAGE_RAM flag in the setbat calls at
lines 112 & 120 results in a kernel that won't go past the
"Uncompressing" step.
In arch/ppc/mm/pgtables.c
If I add _PAGE_WRITETHRU to the _PAGE_RAM flag in mapin_ram and
map_page allows the kernel to boot, and in fact shows no noticable
performance difference.
I found in arch/ppc/mm/hashtable.S that the linux PTE's aren't
entirely transferred into the HPTE's of the PPC, so with some
reluctance, I tried adding a line turning on WRITETHRU at line 350 in
create_hpte:
ori r8,r8,_PAGE_WRITETHRU
The kernel will come up, but init promptly dies with Signal 11.
There's little documentation on PPC Memory management & the linux
kernel, so I'm not sure what do to from here. Can anyone help me out
here? Thanks.
Matt
^ permalink raw reply
* Re: V4L2: __ucmpdi2 undefined on ppc
From: Segher Boessenkool @ 2008-03-04 22:43 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, henrik.sorensen, Stephane Marchesin,
David Woodhouse
In-Reply-To: <18381.49853.255430.142431@cargo.ozlabs.ibm.com>
>> Every occurrence of r7 here is wrong (and some of the r6). Is there
>> any reason to do this in assembler code at all?
>
> The fact that the obvious C code generates ... a call to __ucmpdi2? :)
Hrm? Here's the "obvious" C code, portable to all architectures
(modulo the specific types used, this isn't a proposed patch):
unsigned int ucmpdi2(unsigned long long a, unsigned long long b)
{
unsigned long ahi, bhi, alo, blo;
ahi = a >> 32;
bhi = b >> 32;
if (ahi < bhi)
return 0;
if (ahi > bhi)
return 2;
alo = a;
blo = b;
if (alo < blo)
return 0;
if (alo > blo)
return 2;
return 1;
}
(libgcc does it a bit differently, with unions and stuff).
Segher
^ permalink raw reply
* Re: [PATCH 3/4] Emerson KSI8560 device tree
From: David Gibson @ 2008-03-04 23:29 UTC (permalink / raw)
To: Alexandr Smirnov; +Cc: linuxppc-dev
In-Reply-To: <20080304163540.GD19634@ru.mvista.com>
On Tue, Mar 04, 2008 at 07:35:40PM +0300, Alexandr Smirnov wrote:
> Add device tree file for Emerson KSI8560 board.
>
> Signed-off-by: Alexandr Smirnov <asmirnov@ru.mvista.com>
[snip]
> + enet0: ethernet@24000 {
> + linux,network-index = <0>;
We're trying to get rid of this. Since I assume you're using u-boot,
I'm not sure why you'd need it now anyway.
> + device_type = "network";
> + model = "TSEC";
> + compatible = "gianfar";
This still looks like the old binding.
[snip]
> + cpld@4,0 {
> + compatible = "altera,maxii";
I'm guessing an Altera Maxii is just the name of the FPGA chip into
which the CPLD is programmed? If so, it's not a suitable "comaptible"
value, because that needs to describe the register interface. You
probably want something like
compatible = "emerson,KSI8560-cpld";
here.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Virtual device hdlc0 asks to que packet!
From: Russell McGuire @ 2008-03-04 23:33 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.1516.1204637021.17968.linuxppc-embedded@ozlabs.org>
All,
Background MPC8360, using a T1 PHY as an HDLC device.
Developing my hdlc driver, and was writing a simple send utility. To test it
out. Things seem well when I had massive delays in between the write() or
sendot(), and I was able to attain 100+Kbytes/sec. However, when I replaced
the simple usleeps(xxx) with select statements, suddenly I started getting a
ton of these messages.
"Virtual device hdlc0 asks to que packet!"
Along with dropped or non-sent data.
In my driver I am tracking the available TX buffers, and issue a
netif_stop_que() statement inside the start_xmit() call, with a
corresponding netif_wake_que() in the tx_handler.
Is there something else that needs to be done in order to make a select
statement wait for the socket to not be busy? It seems that it always
returns immediately with no timeout.
I guess the other pieces of the scenario are as follows:
* Using 'sethdlc hdlc0 hdlc' for the mode, so no IP stack is used.
* Opening the socket to the hdlc device directly to the device itself, i.e.
no port number socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
I have used both sendto() and write() to pass data down, and they both
return as if all the data has been sent, i.e. I never get an error.
-Russ
^ permalink raw reply
* Re: dtc: Make some functions local to parser
From: David Gibson @ 2008-03-05 0:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080304191844.GA7810@loki.buserror.net>
On Tue, Mar 04, 2008 at 01:18:44PM -0600, Scott Wood wrote:
> On Tue, Mar 04, 2008 at 03:37:00PM +1100, David Gibson wrote:
> > * The Bison documentation explicitly permits yyerror() to be a
> > variadic function, so fold yyerror() and yyerrorf() into a single
> > printf-style function.
>
> Then the bison documentation is not consistent with the bison
> implementation when verbose error messages are enabled. How can it possibly
> know whether to put % or %% in the string when an unexpected % is
> encountered?
Ah crap. I'd forgotten the specific case you mentioned before.
> Reading bison internals makes my head hurt...
>
> > The combined function is defined and used
> > only in the parse, so make it static.
>
> Static-izing something that is used externally in a posted patch where
> you've provided no alternate to use is rather bad form...
IIRC, I already asked you *not* to use it externally, though. And a
lot of these patches I've been posting lately are yak-shaving leading
up to a generally available error function.
Still, forget this patch for now.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* dtc: Make eval_literal() static
From: David Gibson @ 2008-03-05 0:47 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
eval_literal() is used only in the parser, so make it a static
function.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
dtc-parser.y | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Applies instead of the earlier patch that also localised yyerror().
Index: dtc/dtc-parser.y
===================================================================
--- dtc.orig/dtc-parser.y 2008-03-05 11:45:54.000000000 +1100
+++ dtc/dtc-parser.y 2008-03-05 11:46:07.000000000 +1100
@@ -24,12 +24,12 @@
#include "dtc.h"
#include "srcpos.h"
-int yylex(void);
-unsigned long long eval_literal(const char *s, int base, int bits);
+extern int yylex(void);
extern struct boot_info *the_boot_info;
extern int treesource_error;
+static unsigned long long eval_literal(const char *s, int base, int bits);
%}
%union {
@@ -330,7 +330,7 @@
yyerrorf("%s", s);
}
-unsigned long long eval_literal(const char *s, int base, int bits)
+static unsigned long long eval_literal(const char *s, int base, int bits)
{
unsigned long long val;
char *e;
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: [PATCH 11/17] Add memory mapping driver to RapidIO.
From: Zhang Wei @ 2008-03-05 1:59 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080304213735.c77d6203.sfr@canb.auug.org.au>
Hi, Stephen,
Thanks! I'm considering to commit a updated patch or new code cleaning
patch.
How about your idea?
Cheers!
Wei=20
> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]=20
> Sent: Tuesday, March 04, 2008 6:38 PM
> To: Zhang Wei
> Cc: mporter@kernel.crashing.org; galak@kernel.crashing.org;=20
> linuxppc-dev@ozlabs.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 11/17] Add memory mapping driver to RapidIO.
>=20
> On Wed, 5 Mar 2008 00:29:56 +0800 Zhang Wei=20
> <wei.zhang@freescale.com> wrote:
> >
> > + if (!(rmem->virt =3D dma_alloc_coherent(NULL, rmem->size,
> > + &rmem->iores.start, GFP_KERNEL))) {
>=20
> Please separate assignments from tests.
>=20
> > + if ((ret =3D rio_space_claim(rmem))) {
>=20
> Again.
>=20
> --=20
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>=20
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Kamalesh Babulal @ 2008-03-05 2:28 UTC (permalink / raw)
To: Pekka Enberg
Cc: linux-mm, Mel Gorman, linuxppc-dev, Andrew Morton,
Christoph Lameter
In-Reply-To: <47CDAC58.6090207@cs.helsinki.fi>
Pekka Enberg wrote:
> Christoph Lameter wrote:
>> I think this is the correct fix.
>>
>> The NUMA fallback logic should be passing local_flags to kmem_get_pages()
>> and not simply the flags.
>>
>> Maybe a stable candidate since we are now simply
>> passing on flags to the page allocator on the fallback path.
>>
>> Signed-off-by: Christoph Lameter <clameter@sgi.com>
>
> Indeed, good catch. I spotted the same thing just few seconds ago.
>
> Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>
>
> Was it you Kamalesh that reported this? Can you please re-test?
Thanks the patch fixes the kernel bug.
Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox