* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Nick Piggin @ 2006-05-16 0:31 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: akpm, davej, tony.luck, linuxppc-dev, mel, linux-kernel,
bob.picco, ak, linux-mm
In-Reply-To: <20060515192918.c3e2e895.kamezawa.hiroyu@jp.fujitsu.com>
KAMEZAWA Hiroyuki wrote:
>On Mon, 15 May 2006 11:19:27 +0100
>Andy Whitcroft <apw@shadowen.org> wrote:
>
>>>
>>>Recently arrived? Over a year ago with the no-buddy-bitmap patches,
>>>right? Just checking because I that's what I'm assuming broke it...
>>>
>>Yep, sorry I forget I was out of the game for 6 months! And yes that
>>was when the requirements were altered.
>>
>>
>When no-bitmap-buddy patches was included,
>
>1. bad_range() is not covered by CONFIG_VM_DEBUG. It always worked.
>==
>static int bad_range(struct zone *zone, struct page *page)
>{
> if (page_to_pfn(page) >= zone->zone_start_pfn + zone->spanned_pages)
> return 1;
> if (page_to_pfn(page) < zone->zone_start_pfn)
> return 1;
>==
>And , this code
>==
> buddy = __page_find_buddy(page, page_idx, order);
>
> if (bad_range(zone, buddy))
> break;
>==
>
>checked whether buddy is in zone and guarantees it to have page struct.
>
Ah, my mistake indeed. Sorry.
>But clean-up/speed-up codes vanished these checks. (I don't know when this occurs)
>Sorry for misses these things.
>
I think if anything they should be moved into page_is_buddy, however
page_to_pfn
is expensive on some architectures, so it is something we want to be
able to opt
out of if we do the correct alignment.
--
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: KAMEZAWA Hiroyuki @ 2006-05-16 1:34 UTC (permalink / raw)
To: Nick Piggin
Cc: akpm, davej, tony.luck, linuxppc-dev, mel, linux-kernel,
bob.picco, ak, linux-mm
In-Reply-To: <44691D7C.5060208@yahoo.com.au>
On Tue, 16 May 2006 10:31:56 +1000
Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> >But clean-up/speed-up codes vanished these checks. (I don't know when this occurs)
> >Sorry for misses these things.
> >
>
> I think if anything they should be moved into page_is_buddy, however
> page_to_pfn
> is expensive on some architectures, so it is something we want to be
> able to opt
> out of if we do the correct alignment.
>
yes. It's expensive.
I received following e-Mail from Dave Hansen in past.
==
There are some ppc64 machines which have memory laid out like this:
0-100 MB Node0
100-200 MB Node1
200-300 MB Node0
==
I didn't imagine above (strange) configration.
So, simple range check will not work for all configration anyway.
(above example is aligned and has no problem. Moreover, ppc uses SPARSEMEM.)
Andy's page_zone(page) == page_zone(buddy) check is good, I think.
Making alignment is a difficult problem, I think. It complecates many things.
We can avoid above check only when memory layout is ideal.
BTW, How about following patch ?
I don't want to say "Oh, you have to re-compile your kernel with
CONFIG_UNALIGNED_ZONE on your new machine. you are unlucky." to users.
==
Index: linux-2.6.17-rc4-mm1/mm/page_alloc.c
===================================================================
--- linux-2.6.17-rc4-mm1.orig/mm/page_alloc.c
+++ linux-2.6.17-rc4-mm1/mm/page_alloc.c
@@ -58,6 +58,7 @@ unsigned long totalhigh_pages __read_mos
unsigned long totalreserve_pages __read_mostly;
long nr_swap_pages;
int percpu_pagelist_fraction;
+int unaligned_zone;
static void __free_pages_ok(struct page *page, unsigned int order);
@@ -296,12 +297,12 @@ static inline void rmv_page_order(struct
*
* Assumption: *_mem_map is contigious at least up to MAX_ORDER
*/
-static inline struct page *
+static inline long *
__page_find_buddy(struct page *page, unsigned long page_idx, unsigned int order)
{
unsigned long buddy_idx = page_idx ^ (1 << order);
- return page + (buddy_idx - page_idx);
+ return (buddy_idx - page_idx);
}
static inline unsigned long
@@ -310,6 +311,23 @@ __find_combined_index(unsigned long page
return (page_idx & ~(1 << order));
}
+static inline struct page *
+buddy_in_range(struct zone *zone, struct page *page, long buddy_idx)
+{
+ unsigned long pfn;
+ struct page *buddy;
+ if (!unaligned_zone)
+ return page + buddy_idx;
+ pfn = page_to_pfn(page);
+ if (!pfn_valid(pfn + buddy_idx))
+ return NULL;
+ buddy = page + buddy_idx;
+ if (page_zone_id(page) != page_zone_id(buddy))
+ return NULL;
+ return buddy;
+}
+
+
/*
* This function checks whether a page is free && is the buddy
* we can do coalesce a page and its buddy if
@@ -326,15 +344,10 @@ __find_combined_index(unsigned long page
static inline int page_is_buddy(struct page *page, struct page *buddy,
int order)
{
-#ifdef CONFIG_HOLES_IN_ZONE
+#if defined(CONFIG_HOLES_IN_ZONE)
if (!pfn_valid(page_to_pfn(buddy)))
return 0;
#endif
-#ifdef CONFIG_UNALIGNED_ZONE_BOUNDRIES
- if (page_zone_id(page) != page_zone_id(buddy))
- return 0;
-#endif
-
if (PageBuddy(buddy) && page_order(buddy) == order) {
BUG_ON(page_count(buddy) != 0);
return 1;
@@ -383,10 +396,14 @@ static inline void __free_one_page(struc
zone->free_pages += order_size;
while (order < MAX_ORDER-1) {
unsigned long combined_idx;
+ long buddy_idx;
struct free_area *area;
struct page *buddy;
- buddy = __page_find_buddy(page, page_idx, order);
+ buddy_idx = __page_find_buddy(page, page_idx, order);
+ buddy = buddy_in_zone(zone, page, buddy_idx);
+ if (unlikely(!buddy))
+ break;
if (!page_is_buddy(page, buddy, order))
break; /* Move the buddy up one level. */
@@ -2434,10 +2451,9 @@ static void __meminit free_area_init_cor
struct zone *zone = pgdat->node_zones + j;
unsigned long size, realsize;
- if (zone_boundary_align_pfn(zone_start_pfn) != zone_start_pfn)
- printk(KERN_CRIT "node %d zone %s missaligned "
- "start pfn, enable UNALIGNED_ZONE_BOUNDRIES\n",
- nid, zone_names[j]);
+ if (zone_boundary_align_pfn(zone_start_pfn) != zone_start_pfn) {
+ unaligned_zone = 1;
+ }
size = zone_present_pages_in_node(nid, j, zones_size);
realsize = size - zone_absent_pages_in_node(nid, j,
Index: linux-2.6.17-rc4-mm1/include/linux/mmzone.h
===================================================================
--- linux-2.6.17-rc4-mm1.orig/include/linux/mmzone.h
+++ linux-2.6.17-rc4-mm1/include/linux/mmzone.h
@@ -399,11 +399,7 @@ static inline int is_dma(struct zone *zo
static inline unsigned long zone_boundary_align_pfn(unsigned long pfn)
{
-#ifdef CONFIG_UNALIGNED_ZONE_BOUNDRIES
- return pfn;
-#else
return pfn & ~((1 << MAX_ORDER) - 1);
-#endif
}
/* These two functions are used to setup the per zone pages min values */
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Nick Piggin @ 2006-05-16 2:11 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: akpm, davej, tony.luck, linuxppc-dev, mel, linux-kernel,
bob.picco, ak, linux-mm
In-Reply-To: <20060516103415.ad964bdf.kamezawa.hiroyu@jp.fujitsu.com>
KAMEZAWA Hiroyuki wrote:
>
>Andy's page_zone(page) == page_zone(buddy) check is good, I think.
>
>Making alignment is a difficult problem, I think. It complecates many things.
>We can avoid above check only when memory layout is ideal.
>
>BTW, How about following patch ?
>I don't want to say "Oh, you have to re-compile your kernel with
>CONFIG_UNALIGNED_ZONE on your new machine. you are unlucky." to users.
>
No, this is a function of the architecture code, not the specific
machine it is running on.
So if the architecture ensures alignment and no holes, then they don't
need the overhead of CONFIG_UNALIGNED_ZONE or CONFIG_HOLES_IN_ZONE.
If they do not ensure correct alignment, then they must enable
CONFIG_UNALIGNED_ZONE, even if there may be actual systems which do
result in aligned zones.
--
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: ppc32 kernel boot problem (pmu related?)
From: Nathan Pilatzke @ 2006-05-16 4:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1147658309.21291.73.camel@localhost.localdomain>
Ok, here is the new log:
time_init: processor frequency =3D 700.000000 MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7,524288 bytes)
Inode-cache hash table entries: 65536 (order: 6,262144 bytes)
Memory: 643456k/655360k available (2908k kernel code, 11564k reserved,
272k data, 131k bss, 156k init)
Mount-cache hash table entries: 512
device-tree: Duplicate name in /cpus/PowerPC,G4@0, renamed to "l2-cache#1"
NET: Registered protocol family 16
KeyWest i2c @0xf8001003 irq 42 /uni-n@f8000000/i2c@f8001000
channel 0 bus <multibus>
channel 1 bus <multibus>
KeyWest i2c @0x80018000 irq 26 /pci@f2000000/mac-io@17/i2c@18000
channel 0 bus <multibus>
PMU i2c /pci@f2000000/mac-io@17/via-pmu@16000/pmu-i2c
channel 1 bus <multibus>
channel 2 bus <multibus>
PCI: Probing PCI hardware
And that's where is locks hard. Just as an alternative I tried
compiling without i2c support, but the kernel locks hard at the exact
same point. Compiling without the pmu code is the only way I can get
the kernel to boot. There are some kernel messages missing from a
kernel compiled with pmu versus a kernel without pmu, namely:
On node 0 total pages: 163840
DMA zone: 163840 pages, LIFO batch: 31
and
Calibrating delay loop... 49.79 BogoMIPS (lpj=3D99584)
but they do not seem to be anything serious. Where to go from here?
Thanks for the debugging suggestions so far, keep them coming please.
On 5/14/06, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> Hrm... that's pretty much when console_init() gets called, which means
> no message until the fbdev kicks in, thus we just "miss" the messages
> from there to the crash.... Can you edit arch/powerpc/kernel/udbg.c,
> there is a function called disable_early_printk() which contains a #if
> 1, turn that into #if 0 and tell me if you get a more useful log after
> the time_init thing. Thanks !
>
>
>
^ permalink raw reply
* Re: ppc32 kernel boot problem (pmu related?)
From: Benjamin Herrenschmidt @ 2006-05-16 4:43 UTC (permalink / raw)
To: Nathan Pilatzke; +Cc: linuxppc-dev
In-Reply-To: <98889dd30605152106m9090ba3ga1a4c7706aace3ef@mail.gmail.com>
> And that's where is locks hard. Just as an alternative I tried
> compiling without i2c support, but the kernel locks hard at the exact
> same point. Compiling without the pmu code is the only way I can get
> the kernel to boot. There are some kernel messages missing from a
> kernel compiled with pmu versus a kernel without pmu, namely:
>
> On node 0 total pages: 163840
> DMA zone: 163840 pages, LIFO batch: 31
>
> and
>
> Calibrating delay loop... 49.79 BogoMIPS (lpj=99584)
>
> but they do not seem to be anything serious. Where to go from here?
> Thanks for the debugging suggestions so far, keep them coming please.
Can you try editing arch/powerpc/platforms/powermac/low_i2c.c, in
function pmac_i2c_init(), comment out the call to pmac_i2c_devscan() and
tell me if that makes a difference.
Thanks,
Ben.
^ permalink raw reply
* Re: ppc32 kernel boot problem (pmu related?)
From: Benjamin Herrenschmidt @ 2006-05-16 4:44 UTC (permalink / raw)
To: Nathan Pilatzke; +Cc: linuxppc-dev
In-Reply-To: <98889dd30605152106m9090ba3ga1a4c7706aace3ef@mail.gmail.com>
Oh and also send me a tarball of /proc/device-tree
Ben.
^ permalink raw reply
* "Need help to configure DNS on the Embedded system"
From: nreddy @ 2006-05-16 12:10 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I am working on implementing wget future on my Embedded device.
So i downloaded free wget sources (version 1.10.2) and compiled for my
system.
My system is walnut based one(IBM405EP processor). But wget is working if
i specify IP when i try to download some file from my support site(i gave
IP of support site), but when i specify like www.support.netenrich.com, it
is not able to resolve.
I Modified /etc/resolve.conf, but still it says unable to resolve .
I am using MontaVista Linux Kernel 2.4.20.
can some one let me know how to configure the DNS on any embedded systems.
I have gone through some of the meterial available on the net, but could
not resolve it.
Thanks in Advance,
Nagi Reddy.C
^ permalink raw reply
* [RFC] alsa integer control ranges
From: Johannes Berg @ 2006-05-16 12:02 UTC (permalink / raw)
To: ALSA development; +Cc: linuxppc-dev list
Apparently all alsa userspace programs including alsamixer suck. Hence,
this patch is required to make them work properly. Why is it so hard to
do these additions/subtractions in the program or maybe even in the alsa
library? The alsa libraries already think they know better and mess up
all kinds of things.
What are your opinions on this? Should this be required? And if so, why
do we even have the value.integer.min when we can't use it anyway?
The code this patch applies against is in
http://johannes.sipsolutions.net/snd-aoa.git/ but that isn't all too
relevant, the patch serves just as an illustration of what is wrong
here.
Thanks,
johannes
--- snd-aoa.orig/aoa/codecs/onyx/snd-aoa-codec-onyx.c 2006-05-16 12:13:39.663950213 +0200
+++ snd-aoa/aoa/codecs/onyx/snd-aoa-codec-onyx.c 2006-05-16 12:14:13.698643898 +0200
@@ -102,8 +102,8 @@ static int onyx_snd_vol_info(struct snd_
{
uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
uinfo->count = 2;
- uinfo->value.integer.min = -128;
- uinfo->value.integer.max = -1;
+ uinfo->value.integer.min = -128+128;
+ uinfo->value.integer.max = -1+128;
return 0;
}
@@ -115,8 +115,8 @@ static int onyx_snd_vol_get(struct snd_k
onyx_read_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, &l);
onyx_read_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, &r);
- ucontrol->value.integer.value[0] = l;
- ucontrol->value.integer.value[1] = r;
+ ucontrol->value.integer.value[0] = l+128;
+ ucontrol->value.integer.value[1] = r+128;
return 0;
}
@@ -125,8 +125,8 @@ static int onyx_snd_vol_put(struct snd_k
{
struct onyx *onyx = snd_kcontrol_chip(kcontrol);
- onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, ucontrol->value.integer.value[0]);
- onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, ucontrol->value.integer.value[1]);
+ onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, ucontrol->value.integer.value[0]-128);
+ onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, ucontrol->value.integer.value[1]-128);
/* FIXME: we could be checking if anything changed */
return 1;
}
@@ -145,8 +145,8 @@ static int onyx_snd_inputgain_info(struc
{
uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
uinfo->count = 1;
- uinfo->value.integer.min = 3;
- uinfo->value.integer.max = 28;
+ uinfo->value.integer.min = 3-3;
+ uinfo->value.integer.max = 28-3;
return 0;
}
@@ -157,7 +157,7 @@ static int onyx_snd_inputgain_get(struct
u8 ig;
onyx_read_register(onyx, ONYX_REG_ADC_CONTROL, &ig);
- ucontrol->value.integer.value[0] = ig & ONYX_ADC_PGA_GAIN_MASK;
+ ucontrol->value.integer.value[0] = (ig & ONYX_ADC_PGA_GAIN_MASK)-3;
return 0;
}
@@ -169,7 +169,7 @@ static int onyx_snd_inputgain_put(struct
onyx_read_register(onyx, ONYX_REG_ADC_CONTROL, &val);
val &= ~ONYX_ADC_PGA_GAIN_MASK;
- val |= ucontrol->value.integer.value[0] & ONYX_ADC_PGA_GAIN_MASK;
+ val |= (ucontrol->value.integer.value[0]+3) & ONYX_ADC_PGA_GAIN_MASK;
onyx_write_register(onyx, ONYX_REG_ADC_CONTROL, val);
return 1;
}
^ permalink raw reply
* Re: [Alsa-devel] [RFC] alsa integer control ranges
From: Takashi Iwai @ 2006-05-16 12:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, ALSA development
In-Reply-To: <1147780945.29795.110.camel@johannes>
At Tue, 16 May 2006 14:02:20 +0200,
Johannes Berg wrote:
>
> Apparently all alsa userspace programs including alsamixer suck. Hence,
> this patch is required to make them work properly. Why is it so hard to
> do these additions/subtractions in the program or maybe even in the alsa
> library? The alsa libraries already think they know better and mess up
> all kinds of things.
It's a pretty stupid question to ask why you are stupid :)
I don't think it's alsa-lib that prevents the negative or non-zero
integer range. The fact amixer works implies that it's an
app-specific bug. But I'm not 100% sure and need more
inside-looking.
> What are your opinions on this? Should this be required? And if so, why
> do we even have the value.integer.min when we can't use it anyway?
Right now, the range 0-max would make your life easier, I guess.
The min value is an API definition, and implemented and worked once.
But no drivers used yet. So, there might be a breakage. It's of
course to be fixed.
Takashi
^ permalink raw reply
* please pull powerpc.git 'merge' branch
From: Paul Mackerras @ 2006-05-16 12:35 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from the "merge" branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
Two more small bug-fixes for powerpc. I have put the full commit
messages and patches below.
Thanks,
Paul.
commit 3de620e8394406fd01f450b8c6e3e74464e81a78
Author: Anton Blanchard <anton@samba.org>
Date: Wed May 10 13:05:54 2006 +1000
[PATCH] powerpc: fix kernel version display on pseries boxes
We are displaying the wrong thing on the operator panel (2x40
character LCD). This got broken in commit cebb21b5, when UTS_RELEASE
got changed to system_utsname.version.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 5eb55ef..5f79f01 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -255,7 +255,7 @@ static int __init pSeries_init_panel(voi
{
/* Manually leave the kernel version on the panel. */
ppc_md.progress("Linux ppc64\n", 0);
- ppc_md.progress(system_utsname.version, 0);
+ ppc_md.progress(system_utsname.release, 0);
return 0;
}
commit cb6b2eb9bcf2f61e84dc0b55ef7e3d4923842313
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Mon May 15 15:46:03 2006 +1000
[PATCH] Fix pSeries identification in prom_init.c
The OF trampoline code prom_init.c still needs to identify IBM pSeries
(PAPR) machines in order to run some platform specific code on them like
instanciating the TCE tables. The code doing that detection was changed
recently in 2.6.17 early stages but was done slightly incorrectly. It
should be testing for an exact match of "chrp" and it currently tests
for anything that begins with "chrp". That means it will incorrectly
match with platforms using Maple-like device-trees and have open
firmware. This fixes it by using strcmp instead of strncmp to match what
the actual platform detection code does.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 078fb55..2d80653 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1636,7 +1636,7 @@ #ifdef CONFIG_PPC64
compat, sizeof(compat)-1);
if (len <= 0)
return PLATFORM_GENERIC;
- if (strncmp(compat, RELOC("chrp"), 4))
+ if (strcmp(compat, RELOC("chrp")))
return PLATFORM_GENERIC;
/* Default to pSeries. We need to know if we are running LPAR */
^ permalink raw reply related
* Re: [Alsa-devel] [RFC] alsa integer control ranges
From: Jaroslav Kysela @ 2006-05-16 12:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, ALSA development
In-Reply-To: <1147780945.29795.110.camel@johannes>
On Tue, 16 May 2006, Johannes Berg wrote:
> Apparently all alsa userspace programs including alsamixer suck. Hence,
> this patch is required to make them work properly. Why is it so hard to
> do these additions/subtractions in the program or maybe even in the alsa
> library? The alsa libraries already think they know better and mess up
> all kinds of things.
It's better to fix apps, if they are broken.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
^ permalink raw reply
* Re: "Need help to configure DNS on the Embedded system"
From: Eberhard Stoll @ 2006-05-16 13:36 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <34616.61.95.208.2.1147781429.squirrel@61.95.208.2>
Which C library do you use?
Did you setup /etc/hosts.conf correctly?
It should look like this:
---
order hosts, bind
multi on
---
If you use glibc you shold add 'dns' to /etc/nsswitch.conf file like that:
---
...
hosts: files dns
networks: files dns
...
---
This will tell glibc to look for hostnames in /etc/hosts and via dns.
Additionally glibc needs the two libraries libresolv and libnss_dns for
this setting to work!
Good luck
Eberhard
^ permalink raw reply
* Re: [Alsa-devel] [RFC] alsa integer control ranges
From: Johannes Berg @ 2006-05-16 14:55 UTC (permalink / raw)
To: Lee Revell; +Cc: linuxppc-dev list, ALSA development
In-Reply-To: <1147791186.13948.109.camel@mindpipe>
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
On Tue, 2006-05-16 at 10:53 -0400, Lee Revell wrote:
> Ummm... what problem is this patch fixing?
The problems that
(a) kmix, gnome-alsamixer, gnome-volume-control and others can't
properly use the playback volume control because it has a range
that doesn't start at 0
and
(b) alsamixer can't properly control the capture volume control for
apparently the same reason
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [Alsa-devel] [RFC] alsa integer control ranges
From: Lee Revell @ 2006-05-16 14:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, ALSA development
In-Reply-To: <1147780945.29795.110.camel@johannes>
On Tue, 2006-05-16 at 14:02 +0200, Johannes Berg wrote:
> Apparently all alsa userspace programs including alsamixer suck. Hence,
> this patch is required to make them work properly. Why is it so hard to
> do these additions/subtractions in the program or maybe even in the alsa
> library? The alsa libraries already think they know better and mess up
> all kinds of things.
>
> What are your opinions on this? Should this be required? And if so, why
> do we even have the value.integer.min when we can't use it anyway?
>
> The code this patch applies against is in
> http://johannes.sipsolutions.net/snd-aoa.git/ but that isn't all too
> relevant, the patch serves just as an illustration of what is wrong
> here.
>
Ummm... what problem is this patch fixing?
Lee
^ permalink raw reply
* Re: ppc32 kernel boot problem (pmu related?)
From: Nathan Pilatzke @ 2006-05-16 15:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1147754594.13588.17.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
On 5/16/06, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> Can you try editing arch/powerpc/platforms/powermac/low_i2c.c, in
> function pmac_i2c_init(), comment out the call to pmac_i2c_devscan() and
> tell me if that makes a difference.
>
> Thanks,
> Ben.
>
>
Commenting out the call to pmac_i2c_devscan() in function
pmac_i2c_init() allowed the kernel to boot. I am typing this email
booted under it. The kernel messages were printed a bit strangely
though. There was no scrolling or clearing of the screen. The kernel
messages would start at the top and overwrite old messages, with the
cursor jumping back to the top of the screen every so often. The
/proc/device-tree is attached for the booting 2.6.17-rc3 kernel with
pmu enabled, as is the new dmesg output. If you need the
/proc/device-tree from a 2.6.15 working kernel with pmu enabled
instead, let me know.
Is this kernel fairly safe/stable to use? What can be done next?
Nathan
[-- Attachment #2: device-tree_2.6.17-rc3-pmuworking.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 15848 bytes --]
[-- Attachment #3: dmesg_2.6.17-rc3-pmuworking.bz2 --]
[-- Type: application/x-bzip2, Size: 3942 bytes --]
^ permalink raw reply
* Re: MPC8248 goes berserk when printing messages on the SMC console
From: Laurent Pinchart @ 2006-05-16 15:09 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200605151828.22727.laurent.pinchart@tbox.biz>
Hi,
after further investigation, I found out that my SMC problem is probably=20
caused by cache issues.
> The SMC console works fine in U-Boot. 115200 8N1, no problem there.
>
> When booting a Linux 2.6.16 kernel, the processor doesn't print anything =
on
> the console and seems to hang. Further analysis with a BDI2000 reveals the
> following.
>
> - The CPU is stuck in cpm_uart_console_write, checking for
>
> while ((bdp->cbd_sc & BD_SC_READY) !=3D 0);
>
> At that point, most of the external and internal memory read as 0 (SDRA=
M,
> flash, ...). A few memory locations contain values different than 0, and I
> suspect those to come directly from the cache.
The only memory locations that aren't filled with 0 when read from the BDI =
are=20
the ones present in D-cache lines. Accessing unmapped memory doesn't fail a=
nd=20
returns 0.
> - If I break right before setting the BD_SC_READY flag and run using step=
i,
> random characters are sent on the serial port. Measuring the baudrate usi=
ng
> an oscilloscope confirms that it has been correctly configured. Only the
> data is wrong.
=46rom http://www.freescale.com/webapp/sps/utils/SingleFaq.jsp?FAQ-19683.xml
"Note. If the core is in the debug mode then the cache content will not be=
=20
updated by the snooping."
I tried to clear the GBL bit in the SMC TFCR register to disable memory=20
snooping. This solved part of the problem, as the CPU doesn't hang anymore,=
=20
but the data sent on the serial port are garbage. I suppose that's a normal=
=20
behaviour once the D-cache is enabled.
This leads me to believe that I have a cache issue. Has anyone experienced =
the=20
same problem ?
Laurent Pinchart
^ permalink raw reply
* Unable to boot a kernel on a MPC8560
From: CORVELLER Mickael @ 2006-05-16 15:12 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
first of all, I am a newbie in embedded linux systems.
I'm trying to boot a board based on a MPC8560 (with a e500 core).
I'm using a RS232 console via a debug module connected to the SCC1 port of
the 8560.
The boot loader is U-Boot.
It appears that the transfert of the kernel from the host to target is OK
(I'm using TFTP).
Problems begin when I try to execute the kernel. The system appears to be
frozen.
I don't know if the board is really frozen or if I have "only" lost the
console.
I suspect that my error is situated in the load/execution addresses.
I've tried different couples of values : 0/0, 100000/100000, 10000/10000,
200000/200000, etc...
I've also tried different file format (uImage, zImage.elf, zImage.s ...)
I've tried two distributions : ELINOS and DENX.
I don't know what's happened because I lose the console .
Here is the result of one of my tests :
-> niot 0
Client IP Address (0 for unknown) = 192.168.001.126 ?
Client address mask (0 for unknown) = 255.255.255.000 ?
Server IP Address (0 for unknown) = 192.168.001.127 ?
File Format S(rec)/I(ntel)/B(in)/E(lf) = B ? e
Boot File Name (NULL for unknown) = pimage ? zimage.elf
Boot File Load address = 80000 ? 0
Boot File Execution address = 80000 ? 100000
Data update in progress...
-> nbo 0
Initialize ETH 0 in progress...
Physical link is up at 100f.
TFTP parameters :
Client IP Address 192.168.001.126
Server IP Address 192.168.001.127
Boot File Format E
Boot File Name zimage.elf
Boot File Load address 0
Boot File Execution address 100000
TFTP load in progress...
Packets : 2065
ELF information :
Loading .text @ 0x00800000 : 18620 bytes
Loading .data @ 0x00805000 : 966656 bytes
Clearing .bss @ 0x008F1000 : 8500 bytes
Bytes received = 1057082, Bytes loaded = 0
Low address = 800000, High address = 7FFFFF
After that, the console is died !
I could use some help in trying to understand what's going on.
Regards,
Mickaël
^ permalink raw reply
* what does this mean?
From: Steve Iribarne (GMail) @ 2006-05-16 16:51 UTC (permalink / raw)
To: linuxppc-embedded
My code is hitting in sched.c ->
=09if (unlikely(in_interrupt())) {
=09=09printk("Scheduling in interrupt\n");
=09=09BUG();
=09}
It is hitting this printk. So is this telling me I'm calling schedule
from within an interrupt? How can this be? Has anyone else seen
something like this and can anyone give me a hint as to what to look
for.
Thanks.
-stv
^ permalink raw reply
* Re: what does this mean?
From: Walter L. Wimer III @ 2006-05-16 17:38 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: linuxppc-embedded
In-Reply-To: <b4b98b690605160951o5cefddd8t6b19a91a708f0431@mail.gmail.com>
On Tue, 2006-05-16 at 09:51 -0700, Steve Iribarne (GMail) wrote:
> My code is hitting in sched.c ->
>
> if (unlikely(in_interrupt())) {
> printk("Scheduling in interrupt\n");
> BUG();
> }
> It is hitting this printk. So is this telling me I'm calling schedule
> from within an interrupt? How can this be? Has anyone else seen
> something like this and can anyone give me a hint as to what to look
> for.
Check to make sure that in your interrupt handler you are not calling
something that can sleep. E.g. sleep(), usleep(), kmalloc(), vmalloc(),
etc.
> Thanks.
> -stv
Best regards,
Walt Wimer
TimeSys Corporation
^ permalink raw reply
* Re: what does this mean?
From: Walter L. Wimer III @ 2006-05-16 17:42 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: linuxppc-embedded
In-Reply-To: <1147801106.14881.2.camel@excalibur.timesys.com>
On Tue, 2006-05-16 at 13:38 -0400, Walter L. Wimer III wrote:
> Check to make sure that in your interrupt handler you are not calling
> something that can sleep. E.g. sleep(), usleep(), kmalloc(),
> vmalloc(), etc.
Also watch out for semaphore operations such as down() and
down_interruptible(). They can sleep too.
Walt
^ permalink raw reply
* Re: what does this mean?
From: Steve Iribarne (GMail) @ 2006-05-16 18:04 UTC (permalink / raw)
To: Walter L. Wimer III; +Cc: linuxppc-embedded
In-Reply-To: <1147801367.14881.4.camel@excalibur.timesys.com>
Thanks. That's what I think it is, but I didn't write this code so
I'm trying to track down
who is calling down at interrupt time.
On 5/16/06, Walter L. Wimer III <walt.wimer@timesys.com> wrote:
> On Tue, 2006-05-16 at 13:38 -0400, Walter L. Wimer III wrote:
> > Check to make sure that in your interrupt handler you are not calling
> > something that can sleep. E.g. sleep(), usleep(), kmalloc(),
> > vmalloc(), etc.
>
> Also watch out for semaphore operations such as down() and
> down_interruptible(). They can sleep too.
>
>
> Walt
>
>
>
^ permalink raw reply
* Re: Unable to boot a kernel on a MPC8560
From: Greg Weeks @ 2006-05-16 18:09 UTC (permalink / raw)
To: pito50; +Cc: linuxppc-embedded
In-Reply-To: <BAY105-F10857BC9DB3B958AC19C8D8EA00@phx.gbl>
CORVELLER Mickael wrote:
> Hello,
>
> first of all, I am a newbie in embedded linux systems.
>
> I'm trying to boot a board based on a MPC8560 (with a e500 core).
>
> I'm using a RS232 console via a debug module connected to the SCC1 port of
> the 8560.
>
> The boot loader is U-Boot.
>
>
What version of u-boot do you have? At some point I had a u-boot with
the value of CCSRBAR set different from what the current kernels use. It
caused a failure like this.
Greg Weeks
^ permalink raw reply
* Re: Unable to boot a kernel on a MPC8560
From: Walter L. Wimer III @ 2006-05-16 18:39 UTC (permalink / raw)
To: pito50; +Cc: linuxppc-embedded
In-Reply-To: <BAY105-F10857BC9DB3B958AC19C8D8EA00@phx.gbl>
On Tue, 2006-05-16 at 15:12 +0000, CORVELLER Mickael wrote:
> The boot loader is U-Boot.
>
[...]
>
> Here is the result of one of my tests :
> -> niot 0
> Client IP Address (0 for unknown) = 192.168.001.126 ?
> Client address mask (0 for unknown) = 255.255.255.000 ?
> Server IP Address (0 for unknown) = 192.168.001.127 ?
> File Format S(rec)/I(ntel)/B(in)/E(lf) = B ? e
> Boot File Name (NULL for unknown) = pimage ? zimage.elf
> Boot File Load address = 80000 ? 0
> Boot File Execution address = 80000 ? 100000
> Data update in progress...
> -> nbo 0
> Initialize ETH 0 in progress...
> Physical link is up at 100f.
>
> TFTP parameters :
> Client IP Address 192.168.001.126
> Server IP Address 192.168.001.127
> Boot File Format E
> Boot File Name zimage.elf
> Boot File Load address 0
> Boot File Execution address 100000
> TFTP load in progress...
> Packets : 2065
> ELF information :
> Loading .text @ 0x00800000 : 18620 bytes
> Loading .data @ 0x00805000 : 966656 bytes
> Clearing .bss @ 0x008F1000 : 8500 bytes
> Bytes received = 1057082, Bytes loaded = 0
> Low address = 800000, High address = 7FFFFF
>
> After that, the console is died !
Um, this doesn't look like U-Boot. This looks like an old Motorola
bootloader like MOTLoad....
Walt Wimer
TimeSys Corporation
^ permalink raw reply
* Re: [PATCH] yaboot: enable boot from iscsi target via ethernet devices on js20.
From: Paul Nasrat @ 2006-05-16 20:20 UTC (permalink / raw)
To: Doug Maxey; +Cc: yaboot-devel, Doug Maxey, Linux PowerPC List
In-Reply-To: <200604280605.k3S65tjv012348@bebe.enoyolf.org>
On Fri, 2006-04-28 at 01:05 -0500, Doug Maxey wrote:
> Certain levels of JS20 firmware will allow the system to boot from an
> iscsi target. System OFW accomplishes this by setting up a virtual
> disk device with parameters. These parameters, when passed back to
> OFW by yaboot, directs the FW to use virtual device over the ethernet
> port that will then access iscsi target as a block device. This patch
> extracts those parameters from the property of the virtual device and
> passes them back to OFW to indicate the kernel is to be retrieved via
> the iscsi protocol.
>
> Signed-off-by: Doug Maxey <dwm@austin.ibm.com>
Sorry for the delay in getting back to you - a few initial questions:
> diff --git a/second/file.c b/second/file.c
> @@ -185,16 +188,45 @@ parse_device_path(char *imagepath, char
>
> if (!imagepath)
> return 0;
> +
> + /*
> + * Do preliminary checking for an iscsi device; it may appear as
> + * pure a network device (device_type == "network") if this is
> + * ISWI. This is the case on IBM systems doing an iscsi OFW
> + * boot.
> + */
> + if (strstr(imagepath, ",iscsi"))
Is the , always guaranteed to be there - eg if I have boot
eth1:iscsi,ISCSIARGS won't this check fail.
> diff --git a/second/prom.c b/second/prom.c
> index 5ec06b8..9bc5415 100644
> --- a/second/prom.c
> +++ b/second/prom.c
> @@ -174,6 +174,9 @@ prom_get_devtype (char *device)
> int result;
> char tmp[64];
>
> + if (strstr(device, ",iscsi"))
> + device = strcpy(tmp, "/vdevice/gscsi/disk");
> +
Ditto here.
Paul
^ permalink raw reply
* Re: Unable to boot a kernel on a MPC8560
From: Wolfgang Denk @ 2006-05-16 20:26 UTC (permalink / raw)
To: pito50; +Cc: linuxppc-embedded
In-Reply-To: <BAY105-F10857BC9DB3B958AC19C8D8EA00@phx.gbl>
In message <BAY105-F10857BC9DB3B958AC19C8D8EA00@phx.gbl> you wrote:
>
> first of all, I am a newbie in embedded linux systems.
Seems you are also a newbie when it comes to posting to mailing lists
in general. Posting the same question several times to several
mailing lists is not a good idea. Please read
http://www.catb.org/%7eesr/faqs/smart-questions.html
> The boot loader is U-Boot.
...
> Here is the result of one of my tests :
> -> niot 0
...
> -> nbo 0
These are definitely no U-Boot commands.
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
He's dead, Jim
-- McCoy, "The Devil in the Dark", stardate 3196.1
^ 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