* Re: [PATCH][resend] udbg_printf() formatting attribute
From: Michael Ellerman @ 2006-05-22 6:33 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <68EF7C38-A8DB-445A-BC7F-439102E19BB9@watson.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
On Thu, 2006-05-18 at 12:52 -0400, Jimi Xenidis wrote:
> On May 18, 2006, at 11:56 AM, Michael Ellerman wrote:
> >
> > I'm actually hoping to get rid of udbg_printf(), but if I can't we
> > should stick this in I guess. The real problem IMHO is that debug
> > printks rot because they're rarely compiled, not sure what to do about
> > that.
>
> Yeah, debug code always has that problem. But I must say, whenever I
> work with the x86 guys and I see how long they are _blind_ when they
> boot it blows my mind. Lets hope we don't go there.
Yeah nuts. Don't worry, when I say "get rid of udbg_printf()" I mean
"replace with printk".
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Mel Gorman @ 2006-05-21 22:23 UTC (permalink / raw)
To: Andrew Morton
Cc: davej, tony.luck, linux-mm, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <20060521120843.43babdc7.akpm@osdl.org>
On Sun, 21 May 2006, Andrew Morton wrote:
> Mel Gorman <mel@csn.ul.ie> wrote:
>>
>
>>> Anyway, I just don't get how this code can work. We have an e820 map with
>>> up to 128 entries (this machine has ten) and we're trying to scrunch that
>>> all into the four-entry early_node_map[].
>>>
>>
>> Missing E820MAX was a mistake. On x86_64, CONFIG_MAX_ACTIVE_REGIONS should
>> have been used. I didn't expect x86_64 to have so many memory holes.
>
> x86 uses 128 e820 slots too.
>
That is true, but with x86, I am not expecting many regions. For flatmem,
only one region will be registered. For NUMA, I would expect one
registration per node *unless* SRAT is being used. With SRAT, MAXCHUNKS
regions at most with is 4 * MAX_NUMNODES.
>>
>>> On my little x86 PC:
>>>
>>> BIOS-provided physical RAM map:
>>> BIOS-e820: 0000000000000000 - 000000000009bc00 (usable)
>>> BIOS-e820: 000000000009bc00 - 000000000009c000 (reserved)
>>> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
>>> BIOS-e820: 0000000000100000 - 000000000ffc0000 (usable)
>>> BIOS-e820: 000000000ffc0000 - 000000000fff8000 (ACPI data)
>>> BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
>>> BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
>>> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>>> BIOS-e820: 00000000ffb80000 - 00000000ffc00000 (reserved)
>>> BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
>>> 0MB HIGHMEM available.
>>> 255MB LOWMEM available.
>>> found SMP MP-table at 000ff780
>>> Range (nid 0) 0 -> 65472, max 4
>>> On node 0 totalpages: 65472
>>> DMA zone: 4096 pages, LIFO batch:0
>>> Normal zone: 61376 pages, LIFO batch:15
>>>
>>> So here, the architecture code only called add_active_range() the once, for
>>> the entire memory map.
>>
>> Because in this case, the architecture reported that there was just one
>> range of available pages with no holes.
>
> So.. we're registering a simgle blob of pfns which includes the "reserved"
> memory as well as the "ACPI data" and the "ACPI NVS" (with an apparent
> off-by-one here).
>
The off-by-one is a surprise. On this machine, it must be because the
arch-specific code calculated highend_pfn wrong. I don't use the e820 on
i386 because it didn't seem necessary.
> How come the machine still works? I guess the architecture went and marked
> those pfns reserved.
>
Yes, that is what I'd expect to happen. The ranges are registered and a
memmap allocated but the freeing of memory from bootmem is still the same
on i386. For i386, my patchset reports the same size of zones and
start_pfn on each node so there should be no difference in the end result
between my code and the arch-specific initialisation.
>>> If so, perhaps the bug is that the x86_64 code isn't doing that. And that
>> > x86 isn't doing it for some people either.
>> >
>>
>> I'm hoping in this case that having MAX_ACTIVE_REGIONS match E820MAX will
>> fix the issue on your machine.
>
> I expect it will.
>
> One does wonder whether it's worth all this fuss though. It's only a
> 24-byte structure and it's all thrown away in free_initmem(). One _could_
> just go and do
>
> #define MAX_ACTIVE_REGIONS 10000
>
> and be happy.
>
I could, but I thought I'd be shot for trying something like that. A fixed
value of 128 would cover the largest tables I'm aware of on all
architectures. Should I just set that fixed value?
>> I'm still confused why Christian's failed
>> to boot with the patch backed out though.
>
> He didn't get any "Too many memory regions" messages, so it's something
> different.
>
> Maybe he hit my off-by-one on his "ACPI data"?
>
Possibly but the off-by-one error for you was on x86 not x86_64 and I
suspect that highend_pfn was wrong in this case. I'll be checking tomorrow
where I can see an off-by-one error.
> hm, I didn't mention this in the earlier email. On my x86 I have
>
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009bc00 (usable)
> BIOS-e820: 000000000009bc00 - 000000000009c000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000000ffc0000 (usable)
> BIOS-e820: 000000000ffc0000 - 000000000fff8000 (ACPI data)
> BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
> BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> BIOS-e820: 00000000ffb80000 - 00000000ffc00000 (reserved)
> BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
>
> I added some debug and saw that add_active_range() was getting a
> start_pfn=0 and an end_pfn which corresponds with 0x0fffc000. So my "ACPI
> NVS" is getting chopped off.
>
Yes. However, this just means that the memory for that the PFN range will
not be backed by memmap. This would only be a problem if free_bootmem() is
called on those range of pages. If that was happening, I would be
expecting oops early or bad_page reports during the boot process.
> If Christian is seeing a similar thing then his "ACPI data" will be getting
> only part-registered.
>
> I'd suggest that the next rev be liberal in its printking. This is the
> debug patch I used:
>
I also have an old debug patch that was very printk happy. I will dust it
off and add it with the additional information from your patch.
> mm/page_alloc.c | 25 +++++++++++++++++++++----
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff -puN mm/page_alloc.c~a mm/page_alloc.c
> --- devel/mm/page_alloc.c~a 2006-05-20 13:19:58.000000000 -0700
> +++ devel-akpm/mm/page_alloc.c 2006-05-20 13:20:42.000000000 -0700
> @@ -2463,22 +2463,36 @@ void __init add_active_range(unsigned in
> unsigned long end_pfn)
> {
> unsigned int i;
> - printk(KERN_DEBUG "Range (%d) %lu -> %lu\n", nid, start_pfn, end_pfn);
> +
> + printk("Range (nid %d) %lu -> %lu, max %d\n",
> + nid, start_pfn, end_pfn, MAX_ACTIVE_REGIONS - 1);
>
> /* Merge with existing active regions if possible */
> for (i = 0; early_node_map[i].end_pfn; i++) {
> - if (early_node_map[i].nid != nid)
> + printk("i=%d early_node_map[i].nid=%d "
> + "early_node_map[i].start_pfn=%lu "
> + "early_node_map[i].end_pfn=%lu",
> + i, early_node_map[i].nid,
> + early_node_map[i].start_pfn,
> + early_node_map[i].end_pfn);
> +
> + if (early_node_map[i].nid != nid) {
> + printk(" continue 1\n");
> continue;
> + }
>
> /* Skip if an existing region covers this new one */
> if (start_pfn >= early_node_map[i].start_pfn &&
> - end_pfn <= early_node_map[i].end_pfn)
> + end_pfn <= early_node_map[i].end_pfn) {
> + printk(" return 1\n");
> return;
> + }
>
> /* Merge forward if suitable */
> if (start_pfn <= early_node_map[i].end_pfn &&
> end_pfn > early_node_map[i].end_pfn) {
> early_node_map[i].end_pfn = end_pfn;
> + printk(" return 2\n");
> return;
> }
>
> @@ -2486,13 +2500,16 @@ void __init add_active_range(unsigned in
> if (start_pfn < early_node_map[i].end_pfn &&
> end_pfn >= early_node_map[i].start_pfn) {
> early_node_map[i].start_pfn = start_pfn;
> + printk(" return 3\n");
> return;
> }
> + printk("\n");
> }
>
> /* Leave last entry NULL, we use range.end_pfn to terminate the walk */
> if (i >= MAX_ACTIVE_REGIONS - 1) {
> - printk(KERN_ERR "Too many memory regions, truncating\n");
> + printk(KERN_ERR "More than %d memory regions, truncating\n",
> + MAX_ACTIVE_REGIONS - 1);
> return;
> }
>
> _
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH] powerpc: Fix ide-pmac sysfs entry
From: Benjamin Herrenschmidt @ 2006-05-21 21:46 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Andrew Morton, Pete Popov, B.Zolnierkiewicz, linuxppc-dev, paulus,
Alan Cox
In-Reply-To: <20060521213056.GA25721@iram.es>
On Sun, 2006-05-21 at 23:30 +0200, Gabriel Paubert wrote:
> On Mon, May 15, 2006 at 06:52:36PM +1000, Benjamin Herrenschmidt wrote:
> >
> > > Actually I have one of these, and regularly use it and update
> > > the kernel to the latest git once or twice per month, but I
> > > typically have two batteries and have not swapped in the
> > > media bay under Linux for a long time.
> > >
> > > If you are interested, I could test the patch when I find
> > > some time (not today: my 8 year old son went to the hospital
> > > for an emergency last Thursday, he is cured now and should
> > > come out today).
> >
> > Any test is welcome, glad to know your son is well !
>
> The one liner works here, I can no more solidly hang
> the machine. There is still a bunch of error messages
> on drive removal though:
Yes, I noticed those. Looks like the IDE driver is trying to much around
with the drive when unregistered. In our case, it's not a very good idea
as we unregister it after we detect it's been physically removed :)
Seems harmless so far though.
Ben.
> mediabay0: switching to 7
> mediabay0: powering down
> media bay 0 is empty
> Unregistering mb 0 ide, index:2
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: DMA disabled
> hde: ATAPI reset complete
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: ATAPI reset complete
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: ATAPI reset complete
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hde: ATAPI reset complete
> hde: status error: status=0x00 { }
> ide: failed opcode was: unknown
> mediabay0: end of power down
>
> On insertion there are also a few messages
> but they seem normal:
>
> mediabay0: switching to 3
> mediabay0: powering up
> mediabay0: enabling (kind:3)
> mediabay0: waiting reset (kind:3)
> mediabay0: waiting IDE reset (kind:3)
> mediabay0: waiting IDE ready (kind:3)
> mediabay 0, registering IDE...
> Probing IDE interface ide2...
> hde: LG DVD-ROM DRN-8080B, ATAPI CD/DVD-ROM drive
> hde: Enabling MultiWord DMA 2
> ide2 at 0xf1022000-0xf1022007,0xf1022160 on irq 20
> hde: ATAPI 24X DVD-ROM drive, 512kB Cache, DMA
> media-bay 0 is ide2
> mediabay 0 IDE ready
>
> Regards,
> Gabriel
^ permalink raw reply
* Re: [PATCH] powerpc: Fix ide-pmac sysfs entry
From: Gabriel Paubert @ 2006-05-21 21:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, Pete Popov, B.Zolnierkiewicz, linuxppc-dev, paulus,
Alan Cox
In-Reply-To: <1147683156.21291.118.camel@localhost.localdomain>
On Mon, May 15, 2006 at 06:52:36PM +1000, Benjamin Herrenschmidt wrote:
>
> > Actually I have one of these, and regularly use it and update
> > the kernel to the latest git once or twice per month, but I
> > typically have two batteries and have not swapped in the
> > media bay under Linux for a long time.
> >
> > If you are interested, I could test the patch when I find
> > some time (not today: my 8 year old son went to the hospital
> > for an emergency last Thursday, he is cured now and should
> > come out today).
>
> Any test is welcome, glad to know your son is well !
The one liner works here, I can no more solidly hang
the machine. There is still a bunch of error messages
on drive removal though:
mediabay0: switching to 7
mediabay0: powering down
media bay 0 is empty
Unregistering mb 0 ide, index:2
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: DMA disabled
hde: ATAPI reset complete
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: ATAPI reset complete
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: ATAPI reset complete
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
hde: ATAPI reset complete
hde: status error: status=0x00 { }
ide: failed opcode was: unknown
mediabay0: end of power down
On insertion there are also a few messages
but they seem normal:
mediabay0: switching to 3
mediabay0: powering up
mediabay0: enabling (kind:3)
mediabay0: waiting reset (kind:3)
mediabay0: waiting IDE reset (kind:3)
mediabay0: waiting IDE ready (kind:3)
mediabay 0, registering IDE...
Probing IDE interface ide2...
hde: LG DVD-ROM DRN-8080B, ATAPI CD/DVD-ROM drive
hde: Enabling MultiWord DMA 2
ide2 at 0xf1022000-0xf1022007,0xf1022160 on irq 20
hde: ATAPI 24X DVD-ROM drive, 512kB Cache, DMA
media-bay 0 is ide2
mediabay 0 IDE ready
Regards,
Gabriel
^ permalink raw reply
* Re: HDLC synchronous
From: Wolfgang Denk @ 2006-05-21 19:55 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200605211925.49946.antonio.dibacco@aruba.it>
In message <200605211925.49946.antonio.dibacco@aruba.it> you wrote:
> I had a look to hdlc_enet.c in 8xx_io and it seems to me that it only supports
> asynchronous HDLC (speaks about cts rts). Is this true?
Our hdlc_enet.c driver is a custom driver that is designed to work in
a pretty specific environment. You can use it as a model for your own
implementation, but unless you understand exactly what it's doing you
better be careful.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
No, I'm not going to explain it. If you can't figure it out, you
didn't want to know anyway... :-)
- Larry Wall in <1991Aug7.180856.2854@netlabs.com>
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Andrew Morton @ 2006-05-21 19:08 UTC (permalink / raw)
To: Mel Gorman
Cc: davej, tony.luck, linux-mm, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0605211528390.16327@skynet.skynet.ie>
Mel Gorman <mel@csn.ul.ie> wrote:
>
> > Anyway, I just don't get how this code can work. We have an e820 map with
> > up to 128 entries (this machine has ten) and we're trying to scrunch that
> > all into the four-entry early_node_map[].
> >
>
> Missing E820MAX was a mistake. On x86_64, CONFIG_MAX_ACTIVE_REGIONS should
> have been used. I didn't expect x86_64 to have so many memory holes.
x86 uses 128 e820 slots too.
>
> > On my little x86 PC:
> >
> > BIOS-provided physical RAM map:
> > BIOS-e820: 0000000000000000 - 000000000009bc00 (usable)
> > BIOS-e820: 000000000009bc00 - 000000000009c000 (reserved)
> > BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> > BIOS-e820: 0000000000100000 - 000000000ffc0000 (usable)
> > BIOS-e820: 000000000ffc0000 - 000000000fff8000 (ACPI data)
> > BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
> > BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> > BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> > BIOS-e820: 00000000ffb80000 - 00000000ffc00000 (reserved)
> > BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
> > 0MB HIGHMEM available.
> > 255MB LOWMEM available.
> > found SMP MP-table at 000ff780
> > Range (nid 0) 0 -> 65472, max 4
> > On node 0 totalpages: 65472
> > DMA zone: 4096 pages, LIFO batch:0
> > Normal zone: 61376 pages, LIFO batch:15
> >
> > So here, the architecture code only called add_active_range() the once, for
> > the entire memory map.
>
> Because in this case, the architecture reported that there was just one
> range of available pages with no holes.
So.. we're registering a simgle blob of pfns which includes the "reserved"
memory as well as the "ACPI data" and the "ACPI NVS" (with an apparent
off-by-one here).
How come the machine still works? I guess the architecture went and marked
those pfns reserved.
> > If so, perhaps the bug is that the x86_64 code isn't doing that. And that
> > x86 isn't doing it for some people either.
> >
>
> I'm hoping in this case that having MAX_ACTIVE_REGIONS match E820MAX will
> fix the issue on your machine.
I expect it will.
One does wonder whether it's worth all this fuss though. It's only a
24-byte structure and it's all thrown away in free_initmem(). One _could_
just go and do
#define MAX_ACTIVE_REGIONS 10000
and be happy.
> I'm still confused why Christian's failed
> to boot with the patch backed out though.
He didn't get any "Too many memory regions" messages, so it's something
different.
Maybe he hit my off-by-one on his "ACPI data"?
hm, I didn't mention this in the earlier email. On my x86 I have
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009bc00 (usable)
BIOS-e820: 000000000009bc00 - 000000000009c000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000ffc0000 (usable)
BIOS-e820: 000000000ffc0000 - 000000000fff8000 (ACPI data)
BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffb80000 - 00000000ffc00000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
I added some debug and saw that add_active_range() was getting a
start_pfn=0 and an end_pfn which corresponds with 0x0fffc000. So my "ACPI
NVS" is getting chopped off.
If Christian is seeing a similar thing then his "ACPI data" will be getting
only part-registered.
I'd suggest that the next rev be liberal in its printking. This is the
debug patch I used:
mm/page_alloc.c | 25 +++++++++++++++++++++----
1 file changed, 21 insertions(+), 4 deletions(-)
diff -puN mm/page_alloc.c~a mm/page_alloc.c
--- devel/mm/page_alloc.c~a 2006-05-20 13:19:58.000000000 -0700
+++ devel-akpm/mm/page_alloc.c 2006-05-20 13:20:42.000000000 -0700
@@ -2463,22 +2463,36 @@ void __init add_active_range(unsigned in
unsigned long end_pfn)
{
unsigned int i;
- printk(KERN_DEBUG "Range (%d) %lu -> %lu\n", nid, start_pfn, end_pfn);
+
+ printk("Range (nid %d) %lu -> %lu, max %d\n",
+ nid, start_pfn, end_pfn, MAX_ACTIVE_REGIONS - 1);
/* Merge with existing active regions if possible */
for (i = 0; early_node_map[i].end_pfn; i++) {
- if (early_node_map[i].nid != nid)
+ printk("i=%d early_node_map[i].nid=%d "
+ "early_node_map[i].start_pfn=%lu "
+ "early_node_map[i].end_pfn=%lu",
+ i, early_node_map[i].nid,
+ early_node_map[i].start_pfn,
+ early_node_map[i].end_pfn);
+
+ if (early_node_map[i].nid != nid) {
+ printk(" continue 1\n");
continue;
+ }
/* Skip if an existing region covers this new one */
if (start_pfn >= early_node_map[i].start_pfn &&
- end_pfn <= early_node_map[i].end_pfn)
+ end_pfn <= early_node_map[i].end_pfn) {
+ printk(" return 1\n");
return;
+ }
/* Merge forward if suitable */
if (start_pfn <= early_node_map[i].end_pfn &&
end_pfn > early_node_map[i].end_pfn) {
early_node_map[i].end_pfn = end_pfn;
+ printk(" return 2\n");
return;
}
@@ -2486,13 +2500,16 @@ void __init add_active_range(unsigned in
if (start_pfn < early_node_map[i].end_pfn &&
end_pfn >= early_node_map[i].start_pfn) {
early_node_map[i].start_pfn = start_pfn;
+ printk(" return 3\n");
return;
}
+ printk("\n");
}
/* Leave last entry NULL, we use range.end_pfn to terminate the walk */
if (i >= MAX_ACTIVE_REGIONS - 1) {
- printk(KERN_ERR "Too many memory regions, truncating\n");
+ printk(KERN_ERR "More than %d memory regions, truncating\n",
+ MAX_ACTIVE_REGIONS - 1);
return;
}
_
^ permalink raw reply
* TI_LOCAL_FLAGS definition wrong?
From: Guennadi Liakhovetski @ 2006-05-21 18:36 UTC (permalink / raw)
To: Linuxppc-dev
Hi all,
Is this define in arch/ppc/kernel/asm-offsets.c (as of 2.6.17-rc3):
DEFINE(TI_LOCAL_FLAGS, offsetof(struct thread_info, flags));
correct? Or should it be local_flags? Or is it already fixed in later
versions?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: HDLC synchronous
From: Antonio Di Bacco @ 2006-05-21 18:06 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200605211925.49946.antonio.dibacco@aruba.it>
I 've understood well, the hdlc_enet.c driver provided in denk kernel works
if the hdlc controller can use cts and rts but my board has only INPUT,
OUTPUT, CLK_INPUT and CLOCK_OUPUT pins. I imagine this is a synchronous
interface, isn't it?
Bye,
Antonio.
On Sunday 21 May 2006 19:25, Antonio Di Bacco wrote:
> I had a look to hdlc_enet.c in 8xx_io and it seems to me that it only
> supports asynchronous HDLC (speaks about cts rts). Is this true?
>
> Bye,
> Antonio.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* HDLC synchronous
From: Antonio Di Bacco @ 2006-05-21 17:25 UTC (permalink / raw)
To: linuxppc-embedded
I had a look to hdlc_enet.c in 8xx_io and it seems to me that it only supports
asynchronous HDLC (speaks about cts rts). Is this true?
Bye,
Antonio.
^ permalink raw reply
* HDLC ENET over SCC3
From: Antonio Di Bacco @ 2006-05-21 16:57 UTC (permalink / raw)
To: linuxppc-embedded
I'm using Denk kernel 2.4.25 and eldk 3.1.1
Is is supporting HDLC over SCC3?
Bye,
Antonio.
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Mel Gorman @ 2006-05-21 16:20 UTC (permalink / raw)
To: Andi Kleen
Cc: Andrew Morton, davej, tony.luck, linux-mm, linux-kernel,
bob.picco, linuxppc-dev
In-Reply-To: <200605202327.19606.ak@suse.de>
On Sat, 20 May 2006, Andi Kleen wrote:
>
>> Anyway. From the implementation I can see what the code is doing. But I
>> see no description of what it is _supposed_ to be doing. (The process of
>> finding differences between these two things is known as "debugging"). I
>> could kludge things by setting MAX_ACTIVE_REGIONS to 1000000, but enough.
>> I look forward to the next version ;)
>
> Or we could just keep the working old code.
>
> Can somebody remind me what this patch kit was supposed to fix or
> improve again?
>
The current code for discovering the zone sizes and holes is sometimes
very hairy despite there being some similaries in each arch. This patch
kit will eliminiate some of the uglier code and have one place where zones
and holes can be sized. To me, that is a good idea once the bugs are
rattled out.
On a related note, parts of the current zone-based anti-fragmentation
implementation are an architecture-specific mess because changing how
zones are sized is tricky with the current code. With this patch kit,
sizing zones for easily reclaimable pages is relatively straight-forward.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Mel Gorman @ 2006-05-21 15:50 UTC (permalink / raw)
To: Andrew Morton
Cc: davej, tony.luck, linux-mm, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <20060520135922.129a481d.akpm@osdl.org>
On Sat, 20 May 2006, Andrew Morton wrote:
> Mel Gorman <mel@csn.ul.ie> wrote:
>>
>>
>> Size zones and holes in an architecture independent manner for x86_64.
>>
>>
>
> I found a .config which triggers the cant-map-acpitables problem.
>
>
> With that .config, and without this patch:
>
> Linux version 2.6.17-rc4-mm2 (akpm@box) (gcc version 4.1.0 20060304 (Red Hat 4.6
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000ca605000 (usable)
> BIOS-e820: 00000000ca605000 - 00000000ca680000 (ACPI NVS)
> BIOS-e820: 00000000ca680000 - 00000000cb5ef000 (usable)
> BIOS-e820: 00000000cb5ef000 - 00000000cb5fc000 (reserved)
> BIOS-e820: 00000000cb5fc000 - 00000000cb6a2000 (usable)
> BIOS-e820: 00000000cb6a2000 - 00000000cb6eb000 (ACPI NVS)
> BIOS-e820: 00000000cb6eb000 - 00000000cb6ef000 (usable)
> BIOS-e820: 00000000cb6ef000 - 00000000cb6ff000 (ACPI data)
> BIOS-e820: 00000000cb6ff000 - 00000000cb700000 (usable)
> BIOS-e820: 00000000cb700000 - 00000000cc000000 (reserved)
> BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
> DMI 2.4 present.
> ACPI: PM-Timer IO Port: 0x408
> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> Processor #0 6:15 APIC version 20
> ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> Processor #1 6:15 APIC version 20
> ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
> ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
> ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
> ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
> ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
> ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
>
>
> With that .config, and with this patch:
>
> Bootdata ok (command line is ro root=LABEL=/ earlyprintk=serial,ttyS0,9600,keep netconsole=4444@192.168.2.4/eth0,5147@192.168.2.33/00:0D:56:C6:C6:CC)
> Linux version 2.6.17-rc4-mm2 (akpm@box) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #33 SMP Sat May 20 12:08:03 PDT 2006
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000ca605000 (usable)
> BIOS-e820: 00000000ca605000 - 00000000ca680000 (ACPI NVS)
> BIOS-e820: 00000000ca680000 - 00000000cb5ef000 (usable)
> BIOS-e820: 00000000cb5ef000 - 00000000cb5fc000 (reserved)
> BIOS-e820: 00000000cb5fc000 - 00000000cb6a2000 (usable)
> BIOS-e820: 00000000cb6a2000 - 00000000cb6eb000 (ACPI NVS)
> BIOS-e820: 00000000cb6eb000 - 00000000cb6ef000 (usable)
> BIOS-e820: 00000000cb6ef000 - 00000000cb6ff000 (ACPI data)
> BIOS-e820: 00000000cb6ff000 - 00000000cb700000 (usable)
> BIOS-e820: 00000000cb700000 - 00000000cc000000 (reserved)
> BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
> Too many memory regions, truncating
> Too many memory regions, truncating
> Too many memory regions, truncating
> DMI 2.4 present.
> ACPI: Unable to map RSDT header
> Intel MultiProcessor Specification v1.4
> Virtual Wire compatibility mode.
> OEM ID: Product ID: APIC at: 0xFEE00000
>
> ACPI disables itself.
>
ok, not good but at least it's certain. I had been lulled into a false
sense of security when Christian's machine was still not able to boot with
the patch backed out. I still have not reproduced the problem locally, but
I don't have an x86_64 with so many holes either.
> Good .config: http://www.zip.com.au/~akpm/linux/patches/stuff/config-good
> Bad .config: http://www.zip.com.au/~akpm/linux/patches/stuff/config-bad
>
>
> The handling of MAX_ACTIVE_REGIONS is unpleasing, sorry. In my setup it is
> 5. But we _really_ only support 4 regions. So for a start it is misnamed.
> The maximum number of regions we support is actually MAX_ACTIVE_REGIONS-1.
> And this is a config option too! So the user must specify
> CONFIG_MAX_ACTIVE_REGIONS as the number of active regions plus one, for the
> terminating region which has end_pfn=0. It's weird.
>
That's a fair comment. I'll put more thought into the definition of
MAX_ACTIVE_REGIONS and how it is used.
> I would not consider this code to be adequately commented. Please raise a
> patch which comments the major functions - what they do, why they do it,
> any caveats or implementations details. A few lines each - don't overdo
> it. Details such as whether the various end_pfn's are inclusive or
> exclusive are important, as is a description of the return value.
>
Understood. Right now, the closest thing to an explanation is a comment in
include/linux/mm.h but it is not very detailed.
> Anyway, I just don't get how this code can work. We have an e820 map with
> up to 128 entries (this machine has ten) and we're trying to scrunch that
> all into the four-entry early_node_map[].
>
Missing E820MAX was a mistake. On x86_64, CONFIG_MAX_ACTIVE_REGIONS should
have been used. I didn't expect x86_64 to have so many memory holes.
> With config-good we're set up for NUMA, CONFIG_NODES_SHIFT=6. So
> MAX_ACTIVE_REGIONS is enormous. But it's quite wrong that we're using
> number-of-zones*number-of-nodes to size a data structure which has to
> accommodate all the entries in the e820 map. These things aren't related.
>
Very true.
>
> On my little x86 PC:
>
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009bc00 (usable)
> BIOS-e820: 000000000009bc00 - 000000000009c000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000000ffc0000 (usable)
> BIOS-e820: 000000000ffc0000 - 000000000fff8000 (ACPI data)
> BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
> BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> BIOS-e820: 00000000ffb80000 - 00000000ffc00000 (reserved)
> BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
> 0MB HIGHMEM available.
> 255MB LOWMEM available.
> found SMP MP-table at 000ff780
> Range (nid 0) 0 -> 65472, max 4
> On node 0 totalpages: 65472
> DMA zone: 4096 pages, LIFO batch:0
> Normal zone: 61376 pages, LIFO batch:15
>
> So here, the architecture code only called add_active_range() the once, for
> the entire memory map.
Because in this case, the architecture reported that there was just one
range of available pages with no holes.
> But on the x86_64 add_active_range() was called once per e820 entry.
> I'm dimly starting to realise that this is perhaps the problem - the
> weird-looking definition of MAX_ACTIVE_REGIONS _expects_ the
> architecture to call add_active_range() with a start_pfn/end_pfn which
> describes the entire range of pfns for each zone in each node. Even if
> that span includes not-present pfns. Would that be correct?
Not quite and the confusion is because of how I defined
MAX_ACTIVE_REGIONS. The calculation for it is similar to how i386 using
SRAT calculates MAX_CHUNKS;
#define MAX_CHUNKS_PER_NODE 4
#define MAXCHUNKS (MAX_CHUNKS_PER_NODE * MAX_NUMNODES)
which has little bearing on any other arch.
What is meant to happen is that add_active_range() is called for every
range of physical page frames where real memory is, regardless of what
zone they are in. On x86_64, the ranges are discovered by walking the e820
map in e820_register_active_ranges(). Once it is known where physical
memory is, the holes can be figured out. If I have;
Range (nid 0) 0 -> 100
Range (nid 0) 200 -> 400
I know there is a memory hole of 100 pages. The end PFN of each zone is
passed to free_area_init_nodes(). By walking the early_node_map[], it can
be discovered what the size of the zone and the holes are.
> I didn't see
> a comment in there describing this design (I do go on).
>
I'll address that issue.
> If so, perhaps the bug is that the x86_64 code isn't doing that. And that
> x86 isn't doing it for some people either.
>
I'm hoping in this case that having MAX_ACTIVE_REGIONS match E820MAX will
fix the issue on your machine. I'm still confused why Christian's failed
to boot with the patch backed out though.
> Anyway. From the implementation I can see what the code is doing. But I
> see no description of what it is _supposed_ to be doing. (The process of
> finding differences between these two things is known as "debugging"). I
> could kludge things by setting MAX_ACTIVE_REGIONS to 1000000, but enough.
> I look forward to the next version ;)
>
I'll start working on it. Thanks a lot.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Benjamin Herrenschmidt @ 2006-05-20 23:59 UTC (permalink / raw)
To: Benjamin Berg; +Cc: linuxppc-dev, debian-powerpc, charles-debian-nospam
In-Reply-To: <1148137032.3407.12.camel@localhost>
On Sat, 2006-05-20 at 16:57 +0200, Benjamin Berg wrote:
> On Thu, 2006-18-05 at 09:41 +0900, Charles Plessy wrote:
> > Hi all,
> >
> > just a "me too" mail:
> >
> > Le Thu, May 18, 2006 at 12:02:01AM +0200, Børge Holen a écrit :
> > > I can also remember half way throught a ogg/mp3 playlist when it also
> > > scrambled the output, this has only happened ONCE.
> >
> > I experience the same on my 8,1 powermac, but more systematically. It
> > takes usually more than one hour of continuous listening before it
> > happens, and then it happens sort of stochastically. I am not using
> > anything else than xmms, so I did not figure out if it is a xmms or a
> > driver problem. Stop/Starting the listening stops the scrambling.
>
> This is exactly the problem that I have experienced since a while now.
> The problem is that some interrupts get lost. This results in a broken
> address calculation and the new data is written to the wrong place.
See my other mail about that. Worth tracking down. As far as the DBDMA
handling is concerned, I think walking the descriptors and harvesting
status bits is a better approach as it also allows you to get error
status if you ever get any. Now, if you can have some reliable frame
counter, that's definitely something to look into passing userland too.
> The attached patch fixes this by checking the 'frame_count'.
> What I don't really understand is, that the first time the interrupt
> gets executed, the frame_count is 8 _less_ of what I would have expected
> My guess is that the dma controller reads the last 32 bytes, and then
> the interrupt gets fired.
The DBDMA definitely has a fifo. By the time you get the IRQ, it may
have started pumping the "next" packet. 32 bytes sounds about right for
the DBDMA fifo... old DBDMAs had 16 bits iirc but I could imagine Apple
improving that.
> diff --git a/soundbus/i2sbus/i2sbus-pcm.c b/soundbus/i2sbus/i2sbus-pcm.c
> index 9eadf83..8511234 100644
> --- a/soundbus/i2sbus/i2sbus-pcm.c
> +++ b/soundbus/i2sbus/i2sbus-pcm.c
> @@ -440,6 +440,11 @@ static int i2sbus_pcm_trigger(struct i2s
> return -ENXIO;
> }
>
> + /* get the current frame_count - 32 bytes. This is just guessed,
> + but it seems that the interrupt triggers as soon as the last 32 bytes
> + are cached or something. */
> + pi->frame_count = in_le32(&i2sdev->intfregs->frame_count) - 0x20 / (pi->substream->runtime->sample_bits / 8);
> +
> /* wake up the chip with the next descriptor */
> out_le32(&pi->dbdma->control, (RUN|WAKE) | ((RUN|WAKE)<<16));
> /* off you go! */
> @@ -488,13 +493,29 @@ static snd_pcm_uframes_t i2sbus_pcm_poin
> static inline void handle_interrupt(struct i2sbus_dev *i2sdev, int in)
> {
> struct pcm_info *pi;
> + u32 fc;
> + u32 delta;
>
> get_pcm_info(i2sdev, in, &pi, NULL);
> if (!pi->substream) {
> printk(KERN_INFO "i2sbus: got %s irq while not active!\n", in?"rx":"tx");
> return;
> }
> - pi->current_period = (pi->current_period+1) % (pi->periods);
> +
> + fc = in_le32(&i2sdev->intfregs->frame_count);
> + /* a counter overflow does not change the calculation. */
> + delta = fc - pi->frame_count;
> +
> + if (delta <= pi->substream->runtime->period_size) {
> + pi->current_period = pi->current_period + 1;
> + delta = 0;
> + } else while (delta >= pi->substream->runtime->period_size) {
> + pi->current_period = pi->current_period + 1;
> + delta = delta - pi->substream->runtime->period_size;
> + }
> +
> + pi->frame_count = fc - delta;
> + pi->current_period = pi->current_period % pi->periods;
> snd_pcm_period_elapsed(pi->substream);
> }
>
> diff --git a/soundbus/i2sbus/i2sbus.h b/soundbus/i2sbus/i2sbus.h
> index b054e02..f5d16aa 100644
> --- a/soundbus/i2sbus/i2sbus.h
> +++ b/soundbus/i2sbus/i2sbus.h
> @@ -41,6 +41,7 @@ struct pcm_info {
> struct snd_pcm_substream *substream;
> int current_period;
> int periods;
> + u32 frame_count;
> struct dbdma_command_mem dbdma_ring;
> volatile struct dbdma_regs __iomem *dbdma;
> };
>
>
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Benjamin Herrenschmidt @ 2006-05-20 23:56 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Benjamin Berg, debian-powerpc
In-Reply-To: <1148034127.15507.178.camel@johannes>
> Alternatively we could use the register just to detect if we lost
> interrupts, i.e. calculate how many frames we have per period and then
> see if the frame count increased approximately by that much (I've seen
> +- a few frames probably due to timing, with higher samplerates we'll
> probably see a bit more error) and if it increased by much more we could
> estimate how many interrupts we lost. What do you think?
What do you mean by lost interrupts ?
DBDMA sends edge interrupts. Thus, if it emits interrupts A, then B and
C, and for any reason, your kenrel is not able to service interrupts (is
doing something with IRQs disabled) from before B happens to after C
happens, you'll indeed get called only twice (A and C) and "B" will be
sort-of lost.
First thing about that is: what the heck is causing us to have such a
latency !!! that would be useful to figure out. A way to do that would
be maybe to "detect" when C happens that we missed B (see below how to
do that) and print something along with the regs->nip & lr (or even a
backtrace). That might give us an idea of there interrupts are
re-enabled after the long latency which could perhaps lead us to the
cause of the latency.
Now for detecting lost interrupts (and for being immune to them), the
technique is not to just assume IRQ -> 1 period completed, but instead,
when an irq happens, to go read the DBDMA descriptors in memory to see
which ones have actually been completed. Their status field should be
updated as their get comleted. Thus, you keep track of the "previous"
last completed descriptor and you walk from that to recycle them.
Since we can only update the framecounter on a per-period basis, the
driver would benefit from having lots of very small periods. I don't
know if we can provide "hints" to userland about that though. Using the
i2s frame counter means we need some kind of calibration... it might
still be counting if for the reason the DBDMA "misses" something or gets
stopped....
Ben.
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Andrew Morton @ 2006-05-20 22:54 UTC (permalink / raw)
To: Andi Kleen
Cc: davej, tony.luck, linux-mm, mel, linux-kernel, bob.picco,
linuxppc-dev
In-Reply-To: <200605210017.59984.ak@suse.de>
Andi Kleen <ak@suse.de> wrote:
>
>
> > Well, it creates arch-neutral common code, teaches various architectures
> > use it. It's the sort of thing we do all the time.
> >
> > These things are opportunities to eliminate crufty arch code which few
> > people understand and replace them with new, clean common code which lots
> > of people understand. That's not a bad thing to be doing.
>
> I'm not fundamentally against that, but so far it seems to just generate lots of
> new bugs? I'm not sure it's really worth the pain.
>
It is a bit disproportionate. But in some ways that's a commentary on the
current code. All this numa/sparse/flat/discontig/holes-in-zones/
virt-memmap/ stuff is pretty hairy, especially in its initalisation.
I'm willing to go through the pain if it ends up with something cleaner
which more people understand a little bit.
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Andi Kleen @ 2006-05-20 22:17 UTC (permalink / raw)
To: Andrew Morton
Cc: davej, tony.luck, linux-mm, mel, linux-kernel, bob.picco,
linuxppc-dev
In-Reply-To: <20060520144043.22f993b1.akpm@osdl.org>
> Well, it creates arch-neutral common code, teaches various architectures
> use it. It's the sort of thing we do all the time.
>
> These things are opportunities to eliminate crufty arch code which few
> people understand and replace them with new, clean common code which lots
> of people understand. That's not a bad thing to be doing.
I'm not fundamentally against that, but so far it seems to just generate lots of
new bugs? I'm not sure it's really worth the pain.
-Andi
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Andrew Morton @ 2006-05-20 21:40 UTC (permalink / raw)
To: Andi Kleen
Cc: davej, tony.luck, linux-mm, mel, linux-kernel, bob.picco,
linuxppc-dev
In-Reply-To: <200605202327.19606.ak@suse.de>
Andi Kleen <ak@suse.de> wrote:
>
>
> > Anyway. From the implementation I can see what the code is doing. But I
> > see no description of what it is _supposed_ to be doing. (The process of
> > finding differences between these two things is known as "debugging"). I
> > could kludge things by setting MAX_ACTIVE_REGIONS to 1000000, but enough.
> > I look forward to the next version ;)
>
> Or we could just keep the working old code.
>
> Can somebody remind me what this patch kit was supposed to fix or improve again?
>
Well, it creates arch-neutral common code, teaches various architectures
use it. It's the sort of thing we do all the time.
These things are opportunities to eliminate crufty arch code which few
people understand and replace them with new, clean common code which lots
of people understand. That's not a bad thing to be doing.
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Andi Kleen @ 2006-05-20 21:27 UTC (permalink / raw)
To: Andrew Morton
Cc: davej, tony.luck, linux-mm, Mel Gorman, linux-kernel, bob.picco,
linuxppc-dev
In-Reply-To: <20060520135922.129a481d.akpm@osdl.org>
> Anyway. From the implementation I can see what the code is doing. But I
> see no description of what it is _supposed_ to be doing. (The process of
> finding differences between these two things is known as "debugging"). I
> could kludge things by setting MAX_ACTIVE_REGIONS to 1000000, but enough.
> I look forward to the next version ;)
Or we could just keep the working old code.
Can somebody remind me what this patch kit was supposed to fix or improve again?
-Andi
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Andrew Morton @ 2006-05-20 20:59 UTC (permalink / raw)
To: Mel Gorman
Cc: davej, tony.luck, linux-mm, mel, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <20060508141151.26912.15976.sendpatchset@skynet>
Mel Gorman <mel@csn.ul.ie> wrote:
>
>
> Size zones and holes in an architecture independent manner for x86_64.
>
>
I found a .config which triggers the cant-map-acpitables problem.
With that .config, and without this patch:
Linux version 2.6.17-rc4-mm2 (akpm@box) (gcc version 4.1.0 20060304 (Red Hat 4.6
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000ca605000 (usable)
BIOS-e820: 00000000ca605000 - 00000000ca680000 (ACPI NVS)
BIOS-e820: 00000000ca680000 - 00000000cb5ef000 (usable)
BIOS-e820: 00000000cb5ef000 - 00000000cb5fc000 (reserved)
BIOS-e820: 00000000cb5fc000 - 00000000cb6a2000 (usable)
BIOS-e820: 00000000cb6a2000 - 00000000cb6eb000 (ACPI NVS)
BIOS-e820: 00000000cb6eb000 - 00000000cb6ef000 (usable)
BIOS-e820: 00000000cb6ef000 - 00000000cb6ff000 (ACPI data)
BIOS-e820: 00000000cb6ff000 - 00000000cb700000 (usable)
BIOS-e820: 00000000cb700000 - 00000000cc000000 (reserved)
BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
DMI 2.4 present.
ACPI: PM-Timer IO Port: 0x408
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:15 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 6:15 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
With that .config, and with this patch:
Bootdata ok (command line is ro root=LABEL=/ earlyprintk=serial,ttyS0,9600,keep netconsole=4444@192.168.2.4/eth0,5147@192.168.2.33/00:0D:56:C6:C6:CC)
Linux version 2.6.17-rc4-mm2 (akpm@box) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #33 SMP Sat May 20 12:08:03 PDT 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000ca605000 (usable)
BIOS-e820: 00000000ca605000 - 00000000ca680000 (ACPI NVS)
BIOS-e820: 00000000ca680000 - 00000000cb5ef000 (usable)
BIOS-e820: 00000000cb5ef000 - 00000000cb5fc000 (reserved)
BIOS-e820: 00000000cb5fc000 - 00000000cb6a2000 (usable)
BIOS-e820: 00000000cb6a2000 - 00000000cb6eb000 (ACPI NVS)
BIOS-e820: 00000000cb6eb000 - 00000000cb6ef000 (usable)
BIOS-e820: 00000000cb6ef000 - 00000000cb6ff000 (ACPI data)
BIOS-e820: 00000000cb6ff000 - 00000000cb700000 (usable)
BIOS-e820: 00000000cb700000 - 00000000cc000000 (reserved)
BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
Too many memory regions, truncating
Too many memory regions, truncating
Too many memory regions, truncating
DMI 2.4 present.
ACPI: Unable to map RSDT header
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: Product ID: APIC at: 0xFEE00000
ACPI disables itself.
Good .config: http://www.zip.com.au/~akpm/linux/patches/stuff/config-good
Bad .config: http://www.zip.com.au/~akpm/linux/patches/stuff/config-bad
The handling of MAX_ACTIVE_REGIONS is unpleasing, sorry. In my setup it is
5. But we _really_ only support 4 regions. So for a start it is misnamed.
The maximum number of regions we support is actually MAX_ACTIVE_REGIONS-1.
And this is a config option too! So the user must specify
CONFIG_MAX_ACTIVE_REGIONS as the number of active regions plus one, for the
terminating region which has end_pfn=0. It's weird.
I would not consider this code to be adequately commented. Please raise a
patch which comments the major functions - what they do, why they do it,
any caveats or implementations details. A few lines each - don't overdo
it. Details such as whether the various end_pfn's are inclusive or
exclusive are important, as is a description of the return value.
Anyway, I just don't get how this code can work. We have an e820 map with
up to 128 entries (this machine has ten) and we're trying to scrunch that
all into the four-entry early_node_map[].
With config-good we're set up for NUMA, CONFIG_NODES_SHIFT=6. So
MAX_ACTIVE_REGIONS is enormous. But it's quite wrong that we're using
number-of-zones*number-of-nodes to size a data structure which has to
accommodate all the entries in the e820 map. These things aren't related.
On my little x86 PC:
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009bc00 (usable)
BIOS-e820: 000000000009bc00 - 000000000009c000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000ffc0000 (usable)
BIOS-e820: 000000000ffc0000 - 000000000fff8000 (ACPI data)
BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffb80000 - 00000000ffc00000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
255MB LOWMEM available.
found SMP MP-table at 000ff780
Range (nid 0) 0 -> 65472, max 4
On node 0 totalpages: 65472
DMA zone: 4096 pages, LIFO batch:0
Normal zone: 61376 pages, LIFO batch:15
So here, the architecture code only called add_active_range() the once, for
the entire memory map. But on the x86_64 add_active_range() was called
once per e820 entry. I'm dimly starting to realise that this is perhaps
the problem - the weird-looking definition of MAX_ACTIVE_REGIONS _expects_
the architecture to call add_active_range() with a start_pfn/end_pfn which
describes the entire range of pfns for each zone in each node. Even if
that span includes not-present pfns. Would that be correct? I didn't see
a comment in there describing this design (I do go on).
If so, perhaps the bug is that the x86_64 code isn't doing that. And that
x86 isn't doing it for some people either.
Anyway. From the implementation I can see what the code is doing. But I
see no description of what it is _supposed_ to be doing. (The process of
finding differences between these two things is known as "debugging"). I
could kludge things by setting MAX_ACTIVE_REGIONS to 1000000, but enough.
I look forward to the next version ;)
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Benjamin Berg @ 2006-05-20 14:57 UTC (permalink / raw)
To: charles-debian-nospam; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <20060518004141.GC1552@kunpuu.plessy.org>
On Thu, 2006-18-05 at 09:41 +0900, Charles Plessy wrote:=20
> Hi all,
>=20
> just a "me too" mail:
>=20
> Le Thu, May 18, 2006 at 12:02:01AM +0200, B=C3=B8rge Holen a =C3=A9crit :
> > I can also remember half way throught a ogg/mp3 playlist when it also=20
> > scrambled the output, this has only happened ONCE.
>=20
> I experience the same on my 8,1 powermac, but more systematically. It
> takes usually more than one hour of continuous listening before it
> happens, and then it happens sort of stochastically. I am not using
> anything else than xmms, so I did not figure out if it is a xmms or a
> driver problem. Stop/Starting the listening stops the scrambling.
This is exactly the problem that I have experienced since a while now.
The problem is that some interrupts get lost. This results in a broken
address calculation and the new data is written to the wrong place.
The attached patch fixes this by checking the 'frame_count'.
What I don't really understand is, that the first time the interrupt
gets executed, the frame_count is 8 _less_ of what I would have expected
My guess is that the dma controller reads the last 32 bytes, and then
the interrupt gets fired.
diff --git a/soundbus/i2sbus/i2sbus-pcm.c b/soundbus/i2sbus/i2sbus-pcm.c
index 9eadf83..8511234 100644
--- a/soundbus/i2sbus/i2sbus-pcm.c
+++ b/soundbus/i2sbus/i2sbus-pcm.c
@@ -440,6 +440,11 @@ static int i2sbus_pcm_trigger(struct i2s
return -ENXIO;
}
=20
+ /* get the current frame_count - 32 bytes. This is just guessed,
+ but it seems that the interrupt triggers as soon as the last 32 bytes
+ are cached or something. */
+ pi->frame_count =3D in_le32(&i2sdev->intfregs->frame_count) - 0x20 / (pi=
->substream->runtime->sample_bits / 8);
+
/* wake up the chip with the next descriptor */
out_le32(&pi->dbdma->control, (RUN|WAKE) | ((RUN|WAKE)<<16));
/* off you go! */
@@ -488,13 +493,29 @@ static snd_pcm_uframes_t i2sbus_pcm_poin
static inline void handle_interrupt(struct i2sbus_dev *i2sdev, int in)
{
struct pcm_info *pi;
+ u32 fc;
+ u32 delta;
=20
get_pcm_info(i2sdev, in, &pi, NULL);
if (!pi->substream) {
printk(KERN_INFO "i2sbus: got %s irq while not active!\n", in?"rx":"tx")=
;
return;
}
- pi->current_period =3D (pi->current_period+1) % (pi->periods);
+=09
+ fc =3D in_le32(&i2sdev->intfregs->frame_count);
+ /* a counter overflow does not change the calculation. */
+ delta =3D fc - pi->frame_count;
+=09
+ if (delta <=3D pi->substream->runtime->period_size) {
+ pi->current_period =3D pi->current_period + 1;
+ delta =3D 0;
+ } else while (delta >=3D pi->substream->runtime->period_size) {
+ pi->current_period =3D pi->current_period + 1;
+ delta =3D delta - pi->substream->runtime->period_size;
+ }
+=09
+ pi->frame_count =3D fc - delta;
+ pi->current_period =3D pi->current_period % pi->periods;
snd_pcm_period_elapsed(pi->substream);
}
=20
diff --git a/soundbus/i2sbus/i2sbus.h b/soundbus/i2sbus/i2sbus.h
index b054e02..f5d16aa 100644
--- a/soundbus/i2sbus/i2sbus.h
+++ b/soundbus/i2sbus/i2sbus.h
@@ -41,6 +41,7 @@ struct pcm_info {
struct snd_pcm_substream *substream;
int current_period;
int periods;
+ u32 frame_count;
struct dbdma_command_mem dbdma_ring;
volatile struct dbdma_regs __iomem *dbdma;
};
^ permalink raw reply related
* input/powermac: Cleanup of mac_hid and support for ctrl+click and command+click
From: Michael Hanselmann @ 2006-05-20 14:12 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-input, linuxppc-dev
This patch cleans up mac_hid and adds support for Ctrl+Click (right
click) and Command+Click (middle click) emulation. The latter is similar
to Mac OS X.
Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
---
diff -Nrup --exclude-from linux-exclude-from linux-2.6.17-rc4.orig/drivers/char/keyboard.c linux-2.6.17-rc4/drivers/char/keyboard.c
--- linux-2.6.17-rc4.orig/drivers/char/keyboard.c 2006-05-13 12:33:45.000000000 +0200
+++ linux-2.6.17-rc4/drivers/char/keyboard.c 2006-05-19 23:33:17.000000000 +0200
@@ -40,6 +40,10 @@
#include <linux/sysrq.h>
#include <linux/input.h>
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+#include <asm/mac_hid.h>
+#endif
+
static void kbd_disconnect(struct input_handle *handle);
extern void ctrl_alt_del(void);
@@ -1052,10 +1056,6 @@ static unsigned short x86_keycodes[256]
308,310,313,314,315,317,318,319,320,357,322,323,324,325,276,330,
332,340,365,342,343,344,345,346,356,270,341,368,369,370,371,372 };
-#ifdef CONFIG_MAC_EMUMOUSEBTN
-extern int mac_hid_mouse_emulate_buttons(int, int, int);
-#endif /* CONFIG_MAC_EMUMOUSEBTN */
-
#ifdef CONFIG_SPARC
static int sparc_l1_a_state = 0;
extern void sun_do_break(void);
@@ -1151,7 +1151,7 @@ static void kbd_keycode(unsigned int key
rep = (down == 2);
#ifdef CONFIG_MAC_EMUMOUSEBTN
- if (mac_hid_mouse_emulate_buttons(1, keycode, down))
+ if (mac_hid_mouse_emulate_buttons(keycode, down))
return;
#endif /* CONFIG_MAC_EMUMOUSEBTN */
diff -Nrup --exclude-from linux-exclude-from linux-2.6.17-rc4.orig/drivers/input/input.c linux-2.6.17-rc4/drivers/input/input.c
--- linux-2.6.17-rc4.orig/drivers/input/input.c 2006-05-13 12:33:45.000000000 +0200
+++ linux-2.6.17-rc4/drivers/input/input.c 2006-05-20 13:43:41.000000000 +0200
@@ -24,6 +24,10 @@
#include <linux/device.h>
#include <linux/mutex.h>
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+#include <asm/mac_hid.h>
+#endif
+
MODULE_AUTHOR("Vojtech Pavlik <vojtech@suse.cz>");
MODULE_DESCRIPTION("Input core");
MODULE_LICENSE("GPL");
@@ -194,8 +198,16 @@ static void input_repeat_key(unsigned lo
if (!test_bit(dev->repeat_key, dev->key))
return;
- input_event(dev, EV_KEY, dev->repeat_key, 2);
- input_sync(dev);
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+ if (!mac_hid_repeat_key(dev->repeat_key)) {
+#endif
+
+ input_event(dev, EV_KEY, dev->repeat_key, 2);
+ input_sync(dev);
+
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+ }
+#endif
if (dev->rep[REP_PERIOD])
mod_timer(&dev->timer, jiffies + msecs_to_jiffies(dev->rep[REP_PERIOD]));
diff -Nrup --exclude-from linux-exclude-from linux-2.6.17-rc4.orig/drivers/input/mousedev.c linux-2.6.17-rc4/drivers/input/mousedev.c
--- linux-2.6.17-rc4.orig/drivers/input/mousedev.c 2006-05-13 12:33:46.000000000 +0200
+++ linux-2.6.17-rc4/drivers/input/mousedev.c 2006-05-20 00:48:58.000000000 +0200
@@ -27,6 +27,9 @@
#ifdef CONFIG_INPUT_MOUSEDEV_PSAUX
#include <linux/miscdevice.h>
#endif
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+#include <asm/mac_hid.h>
+#endif
MODULE_AUTHOR("Vojtech Pavlik <vojtech@ucw.cz>");
MODULE_DESCRIPTION("Mouse (ExplorerPS/2) device interfaces");
@@ -316,8 +319,12 @@ static void mousedev_event(struct input_
if (value != 2) {
if (code == BTN_TOUCH && test_bit(BTN_TOOL_FINGER, handle->dev->keybit))
mousedev_touchpad_touch(mousedev, value);
- else
+ else {
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+ code = mac_hid_mouse_click(code, value);
+#endif
mousedev_key_event(mousedev, code, value);
+ }
}
break;
diff -Nrup --exclude-from linux-exclude-from linux-2.6.17-rc4.orig/drivers/macintosh/Kconfig linux-2.6.17-rc4/drivers/macintosh/Kconfig
--- linux-2.6.17-rc4.orig/drivers/macintosh/Kconfig 2006-05-13 12:33:46.000000000 +0200
+++ linux-2.6.17-rc4/drivers/macintosh/Kconfig 2006-05-20 13:29:07.000000000 +0200
@@ -144,6 +144,10 @@ config MAC_EMUMOUSEBTN
/proc/sys/dev/mac_hid/mouse_button_emulation
/proc/sys/dev/mac_hid/mouse_button2_keycode
/proc/sys/dev/mac_hid/mouse_button3_keycode
+ /proc/sys/dev/mac_hid/key_click
+
+ When key_click is enabled by writing a value other than 0 into it,
+ Ctrl+Click is for right click and Command+Click for middle click.
If you have an Apple machine with a 1-button mouse, say Y here.
diff -Nrup --exclude-from linux-exclude-from linux-2.6.17-rc4.orig/drivers/macintosh/mac_hid.c linux-2.6.17-rc4/drivers/macintosh/mac_hid.c
--- linux-2.6.17-rc4.orig/drivers/macintosh/mac_hid.c 2006-05-13 12:33:46.000000000 +0200
+++ linux-2.6.17-rc4/drivers/macintosh/mac_hid.c 2006-05-20 14:03:20.000000000 +0200
@@ -4,8 +4,7 @@
* HID support stuff for Macintosh computers.
*
* Copyright (C) 2000 Franz Sirl.
- *
- * This file will soon be removed in favor of an uinput userspace tool.
+ * Copyright (C) 2006 Michael Hanselmann <linux-kernel@hansmi.ch>
*/
#include <linux/config.h>
@@ -14,16 +13,19 @@
#include <linux/sysctl.h>
#include <linux/input.h>
#include <linux/module.h>
-
+#include <asm/mac_hid.h>
static struct input_dev *emumousebtn;
-static int emumousebtn_input_register(void);
-static int mouse_emulate_buttons = 0;
+static int mouse_emulate_buttons;
static int mouse_button2_keycode = KEY_RIGHTCTRL; /* right control key */
static int mouse_button3_keycode = KEY_RIGHTALT; /* right option key */
-static int mouse_last_keycode = 0;
+static int key_click;
+static int key_click_active;
+static int key_click_button;
+static int key_pressed;
+static int inside_mouse_click;
-#if defined(CONFIG_SYSCTL)
+#ifdef CONFIG_SYSCTL
/* file(s) in /proc/sys/dev/mac_hid */
ctl_table mac_hid_files[] = {
{
@@ -50,6 +52,14 @@ ctl_table mac_hid_files[] = {
.mode = 0644,
.proc_handler = &proc_dointvec,
},
+ {
+ .ctl_name = DEV_MAC_HID_KEY_CLICK,
+ .procname = "key_click",
+ .data = &key_click,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
{ .ctl_name = 0 }
};
@@ -79,33 +89,91 @@ ctl_table mac_hid_root_dir[] = {
static struct ctl_table_header *mac_hid_sysctl_header;
-#endif /* endif CONFIG_SYSCTL */
+#endif /* CONFIG_SYSCTL */
-int mac_hid_mouse_emulate_buttons(int caller, unsigned int keycode, int down)
+/* Emulate mouse buttons with keys */
+int mac_hid_mouse_emulate_buttons(unsigned int keycode, int down)
{
- switch (caller) {
- case 1:
- /* Called from keyboard.c */
- if (mouse_emulate_buttons
- && (keycode == mouse_button2_keycode
- || keycode == mouse_button3_keycode)) {
- if (mouse_emulate_buttons == 1) {
- input_report_key(emumousebtn,
- keycode == mouse_button2_keycode ? BTN_MIDDLE : BTN_RIGHT,
- down);
+ if (inside_mouse_click)
+ return 0;
+
+ if (key_click &&
+ (keycode == KEY_LEFTCTRL || keycode == KEY_RIGHTCTRL ||
+ keycode == KEY_LEFTMETA || keycode == KEY_RIGHTMETA)) {
+ if (down && !key_pressed && !key_click_active)
+ key_pressed = keycode;
+ else if (!down && keycode == key_pressed) {
+ key_pressed = 0;
+
+ if (key_click_active > 0) {
+ input_report_key(emumousebtn, key_click_active, 0);
input_sync(emumousebtn);
- return 1;
+
+ key_click_active = -1;
}
- mouse_last_keycode = down ? keycode : 0;
}
- break;
}
+
+ if (mouse_emulate_buttons) {
+ if (keycode == mouse_button2_keycode)
+ input_report_key(emumousebtn, BTN_RIGHT, down);
+ else if (keycode == mouse_button3_keycode)
+ input_report_key(emumousebtn, BTN_MIDDLE, down);
+
+ input_sync(emumousebtn);
+
+ return 1;
+ }
+
return 0;
}
-EXPORT_SYMBOL(mac_hid_mouse_emulate_buttons);
+/* Modify mouse button value if the Control key is pressed */
+int mac_hid_mouse_click(unsigned int code, int value)
+{
+ if (!key_click || code != BTN_LEFT || inside_mouse_click)
+ return code;
+
+ inside_mouse_click = 1;
+
+ if (value && key_pressed && !key_click_active) {
+ key_click_active = key_pressed;
+
+ input_report_key(emumousebtn, key_click_active, 0);
+ input_sync(emumousebtn);
+
+ if (key_click_active == KEY_LEFTMETA ||
+ key_click_active == KEY_RIGHTMETA)
+ code = BTN_MIDDLE;
+ else
+ code = BTN_RIGHT;
+
+ key_click_button = code;
+ } else if (!value && key_click_active) {
+ if (key_click_active > 0) {
+ input_report_key(emumousebtn, key_click_active, 1);
+ input_sync(emumousebtn);
+ }
-static int emumousebtn_input_register(void)
+ key_click_active = 0;
+
+ code = key_click_button;
+ }
+
+ inside_mouse_click = 0;
+
+ return code;
+}
+
+/* This function returns true if the given keycode should not
+ * be repeated.
+ */
+int mac_hid_repeat_key(unsigned int keycode)
+{
+ return (key_click && key_click_active == keycode);
+}
+
+int __init mac_hid_init(void)
{
emumousebtn = input_allocate_device();
if (!emumousebtn)
@@ -121,24 +189,22 @@ static int emumousebtn_input_register(vo
emumousebtn->keybit[LONG(BTN_MOUSE)] = BIT(BTN_LEFT) | BIT(BTN_MIDDLE) | BIT(BTN_RIGHT);
emumousebtn->relbit[0] = BIT(REL_X) | BIT(REL_Y);
- input_register_device(emumousebtn);
-
- return 0;
-}
+ set_bit(KEY_LEFTCTRL, emumousebtn->keybit);
+ set_bit(KEY_RIGHTCTRL, emumousebtn->keybit);
+ set_bit(KEY_LEFTMETA, emumousebtn->keybit);
+ set_bit(KEY_RIGHTMETA, emumousebtn->keybit);
-int __init mac_hid_init(void)
-{
- int err;
-
- err = emumousebtn_input_register();
- if (err)
- return err;
+ input_register_device(emumousebtn);
-#if defined(CONFIG_SYSCTL)
+#ifdef CONFIG_SYSCTL
mac_hid_sysctl_header = register_sysctl_table(mac_hid_root_dir, 1);
-#endif /* CONFIG_SYSCTL */
+#endif
return 0;
}
device_initcall(mac_hid_init);
+
+EXPORT_SYMBOL(mac_hid_mouse_emulate_buttons);
+EXPORT_SYMBOL_GPL(mac_hid_mouse_click);
+EXPORT_SYMBOL_GPL(mac_hid_repeat_key);
diff -Nrup --exclude-from linux-exclude-from linux-2.6.17-rc4.orig/include/asm-powerpc/mac_hid.h linux-2.6.17-rc4/include/asm-powerpc/mac_hid.h
--- linux-2.6.17-rc4.orig/include/asm-powerpc/mac_hid.h 1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.17-rc4/include/asm-powerpc/mac_hid.h 2006-05-20 00:49:22.000000000 +0200
@@ -0,0 +1,13 @@
+/*
+ * HID support stuff for Macintosh computers.
+ */
+#ifndef __ASM_POWERPC_MAC_HID_H
+#define __ASM_POWERPC_MAC_HID_H
+#ifdef __KERNEL__
+
+extern int mac_hid_mouse_emulate_buttons(unsigned int keycode, int down);
+extern int mac_hid_mouse_click(unsigned int code, int value);
+extern int mac_hid_repeat_key(unsigned int keycode);
+
+#endif
+#endif
diff -Nrup --exclude-from linux-exclude-from linux-2.6.17-rc4.orig/include/linux/sysctl.h linux-2.6.17-rc4/include/linux/sysctl.h
--- linux-2.6.17-rc4.orig/include/linux/sysctl.h 2006-05-13 12:34:00.000000000 +0200
+++ linux-2.6.17-rc4/include/linux/sysctl.h 2006-05-20 12:31:23.000000000 +0200
@@ -870,7 +870,8 @@ enum {
DEV_MAC_HID_MOUSE_BUTTON_EMULATION=3,
DEV_MAC_HID_MOUSE_BUTTON2_KEYCODE=4,
DEV_MAC_HID_MOUSE_BUTTON3_KEYCODE=5,
- DEV_MAC_HID_ADB_MOUSE_SENDS_KEYCODES=6
+ DEV_MAC_HID_ADB_MOUSE_SENDS_KEYCODES=6,
+ DEV_MAC_HID_KEY_CLICK=7,
};
/* /proc/sys/dev/scsi */
^ permalink raw reply
* RE: Information for setting up SMT related parameters on linux 2.6.16 on POWER5
From: Meswani, Mitesh @ 2006-05-20 0:25 UTC (permalink / raw)
To: Segher Boessenkool, will_schmidt; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <18583972-9E29-4B52-BF2E-53102F1794EB@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]
Hello Segher and Will
I tried using these macros on some applications and they dont seem to have any effect. I am running everything as root, and have been using bind processor commands to ensure that a task is assigned to a logical cpu. Since I am running SPEC CPU benchmarks I was exepecting to see a difference in run times, CPI when running two seperate SPEC apps on SMT threads.
Is there some thing else I need to do to make sure that the processor takes the hint to "lower the HMT priority " , I am executing them from a regular shell which I assume has user level priority.
Thanks
Mitesh
Mitesh R. Meswani
Ph.D. Candidate
Research Associate, PLS2 Group
Room 106 F, Department of Computer Science
The University of Texas at El Paso,
El Paso, Texas 79968
Tel: 915 747 8012 (O)
Email: mmeswani@utep.edu
________________________________
From: Segher Boessenkool [mailto:segher@kernel.crashing.org]
Sent: Mon 5/8/2006 5:04 PM
To: will_schmidt@vnet.ibm.com
Cc: Meswani, Mitesh; linuxppc-dev@ozlabs.org; Arnd Bergmann; linux-kernel@vger.kernel.org; cbe-oss-dev@ozlabs.org
Subject: Re: Information for setting up SMT related parameters on linux 2.6.16 on POWER5
> the HMT_* macros are telling firmware that "this processor thread
> should
> run at this priority". Typically used when we're waiting on a
> spinlock.
> I.e. When we are waiting on a spinlock, we hit the HMT_low macro to
> drop
> our threads priority, allowing the other thread to use those extra
> cycles finish it's stuff quicker, and maybe even release the lock
> we're
> waiting for. HMT_* is all within the kernel though, no
> exposure
> to userspace apps.
Actually, those macros translate straight into a single machine insn.
No firmware is involved. See include/asm-powerpc/processor.h. For
example:
#define HMT_very_low() asm volatile("or 31,31,31 # very low
priority")
You can use those same macros from user space, although it is CPU
implementation dependent which priorities you can actually set (you
probably can do low and medium priority).
Segher
[-- Attachment #2: Type: text/html, Size: 3507 bytes --]
^ permalink raw reply
* Re: PPC host with a PCI root-complex
From: Linas Vepstas @ 2006-05-19 23:00 UTC (permalink / raw)
To: Srinivas Murthy; +Cc: linuxppc-dev
In-Reply-To: <7cb1293c0605191428n57c18a60h5b86863d729cd9b9@mail.gmail.com>
On Fri, May 19, 2006 at 02:28:29PM -0700, Srinivas Murthy wrote:
>
> On a PPC (44x) platform, following an error such as parity error detected by
> the PCI root complex, should we cause a bus error (causing a machine-check
> exception) or complete the bus transaction normally but trigger a critical
> interrupt? Note that these are two diff types of interrupts as seen by the
> CPU with the machine check having the highest NMI priority.
I can't answer that question; I'd say that's a platform implementation
question that each platform has to decide on thier own. If you have a
recoverable machine check, and can take it and recover from it, then
I suppose that's a reasonable choice. But I've never dealt with that.
> If the parity error detection was a result of say a memory read operation by
> the core to a PCI device, there might be a several cycle diff between the
> read and the cpu being interrupted (with the critical interrupt handler).
> This may result in data corruption, etc. Is this a valid concern to have?
Yes. Sort of. Maybe. In the early days of getting pci error handling
to work, it became clear that there were lots of pci devices with weak
firmware or buggy hardware that were dma'ing to all sorts of wild adresses,
and/or doing other bad things (mangled PCI split transactions, etc).
We became painfully aware of this, because our pci bridges flagged any DMA
to any page that hadn't been expressly mapped (as well as a bunch of
other PCI errors). Seems that these devices had been busy corrupting
memory and whatever else for years, and no one noticed before, because
no one had a stringent, error checking PCI bridge. Is data corruption
important? Yes. Have you been living with it for years, and not noticing
it? Yes.
(Most of those I dealt with have been fixed, either in the Linux device
driver, the device firmware, or in one case, a hardware change, (I assume
some gate array fixup)).
> What is the normal approach to deal with this issue in an "enterprise" or
> high-end environment?
On IBM pSeries, the PCI-Host bridge stops the transaction; I don't know
the details at the hardware level; I presume its some abort or termination.
In principle, the corrupted data never makes it to system memory or CPU.
If the CPU is reading, 0xffffffff is returned, as are all future reads.
All writes are dropped on the floor. DMA's are also cut off.
On pSeries, there's no interrupt generated on error. Rather, if the
device gets an unexpected 0xffffff on read, it can query the firmware
for the PCI bridge state, and proceed from there. Typical scenario
is that an error occurred during DMA, long ago; the device driver gets
a dma-complete interrupt from pci device, and discovers upon reading
that the device interrupt status register is all 0xffff... During
recovery, that hunk of incomplete dma data is discarded.
The point here is that its potentially OK to allow corrupted data into
systm memory, as long as its at the right address, and as long as the
device driver can nuke it before it has gotten to other consumers.
If you ar getting parity erorrs on DMA addresses, then ... :-)
PCI Express does something else, and I don't quite understand what.
Part of thier mechanism involves an interrupt, although its somehow
wired that on MMIO read, the interrupt gets to the CPU before the
MMIO read completes. Some chunk of it seems x86/itanium-centric.
The Intel guys have been trying to figure out how to implement this,
but haven't done so yet.
--linas
^ permalink raw reply
* Re: Cell and new CPU feature bits
From: Paul Mackerras @ 2006-05-19 22:33 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list, cbe-oss-dev, Arnd Bergmann
In-Reply-To: <20060519161822.GL8220@pb15.lixom.net>
Olof Johansson writes:
> (My patch to rename the existing POWER* bits to ARCH_2_* wasn't picked
> up, I'll resend)
The problem is that those names are now part of the API. I'll need an
ack from the glibc developers before I apply your patch to change them.
Paul.
^ permalink raw reply
* Re: PPC host with a PCI root-complex
From: Srinivas Murthy @ 2006-05-19 21:28 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev
In-Reply-To: <20060519162310.GI12135@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]
Thanks for the reply.
I have a couple of concerns here. I would appreciate if you could provide
your thoughts.
On a PPC (44x) platform, following an error such as parity error detected by
the PCI root complex, should we cause a bus error (causing a machine-check
exception) or complete the bus transaction normally but trigger a critical
interrupt? Note that these are two diff types of interrupts as seen by the
CPU with the machine check having the highest NMI priority.
If the parity error detection was a result of say a memory read operation by
the core to a PCI device, there might be a several cycle diff between the
read and the cpu being interrupted (with the critical interrupt handler).
This may result in data corruption, etc. Is this a valid concern to have?
What is the normal approach to deal with this issue in an "enterprise" or
high-end environment?
On 5/19/06, Linas Vepstas <linas@austin.ibm.com> wrote:
>
> On Thu, May 18, 2006 at 02:56:31PM -0700, Srinivas Murthy wrote:
> > Hi,
> >
> > We have a ppc host with a PCI root-complex across which there are
> multiple
> > PCI end points.
> >
> > An application running on the ppc host reading one of the device memory
> > regions (not DMA access but direct CPU read) causes a parity error on
> the
> > PCI interface controller.
> >
> > We think that the error should be propagated up as a machine-check which
> is
> > considered a non-recoverable system-wide error. However with multiple
> PCI
> > devices present we think that this is too generic and could be reduced
> to be
> > a critical-error which could be recovered from.
>
> The "PCI Error Recovery" API was created to deal with this kind of a
> situation. See Documentation/pci-error-recovery.txt
>
> In breif: if something like a PCI parity error is detected by the
> hardware, then some arch-specific code runs; for example,
> arch/powerpc/platforms/pseries/eeh.c.
>
> This code notifies the PCI device driver (via generic callbacks in
> include/linux/pci.h) about the error. The device driver may ask the
> arch to have the pci device/bus/link/etc/ get reset, or not. If/when
> the PCI bus/link is back to normal, the PCI device driver is notified
> via callback, and resumes normal operation.
>
> If you have questions/suggestions, let me know, I've been maintaining
> this code, and am interested in seeing how well it can be adapted
> to a broader range of hardware.
>
> --linas
>
[-- Attachment #2: Type: text/html, Size: 3062 bytes --]
^ 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