* Re: DTC/dts modifications
From: Gabriel Paubert @ 2006-05-01 22:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, jdl
In-Reply-To: <00CD15B8-F448-4985-8EEC-3BBF61C0110B@kernel.crashing.org>
On Mon, May 01, 2006 at 03:28:34PM -0500, Kumar Gala wrote:
>
> Cool, here's an invocation that seems to work well. Not sure what
> causes linux = 1 (thus I need the -U linux). Also address the line
> information that is normally spit out.
>
> cpp -U linux -P -x assembler-with-cpp foo.dts
Try to add the -undef parameter:
`-undef'
Do not predefine any system-specific or GCC-specific macros. The
standard predefined macros remain defined.
On this machine, the number of lines from:
cpp -dM -x assembler-with-cpp /dev/null
drops from 83 (among which linux, unix, PPC, and powerpc do not start
with underscores) to 5(!) when I add the -undef option. The only ones
left are:
#define __linux__ 1
#define __STDC_HOSTED__ 1
#define __unix__ 1
#define __gnu_linux__ 1
#define __ASSEMBLER__ 1
but at least they all have leading and trailing double underscores.
Regards,
Gabriel
^ permalink raw reply
* Re: DTC/dts modifications
From: Segher Boessenkool @ 2006-05-01 21:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, jdl
In-Reply-To: <00CD15B8-F448-4985-8EEC-3BBF61C0110B@kernel.crashing.org>
> Cool, here's an invocation that seems to work well. Not sure what
> causes linux = 1 (thus I need the -U linux). Also address the line
> information that is normally spit out.
>
> cpp -U linux -P -x assembler-with-cpp foo.dts
Try -undef instead. You will *still* have some predefined
symbols, but at least all of those will have plenty of underscores.
It's still a really bad idea to run non-C code through the C
pre-processor; have you considered using m4 or similar instead?
Segher
^ permalink raw reply
* ioremap
From: Srinivas Murthy @ 2006-05-01 21:25 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 431 bytes --]
Hi,
Why does ioremap() not allow normal system RAM to be mapped in using
ioremap().
We have a need to access a portion of the normal system RAM to be mapped in
non-cached.
To simulate, I used kmalloc() to allocate the memory and then passed the
virt_to_phys() of the memory to ioremap() but then noticed that ioremap()
wont allow it.
Is there another way to access this memory non-cached?
Regards,
_Srinivas
[-- Attachment #2: Type: text/html, Size: 616 bytes --]
^ permalink raw reply
* Re: [PATCH] convert powermac ide blink to new led infrastructure
From: Johannes Berg @ 2006-05-01 21:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1146476158.30710.51.camel@localhost.localdomain>
On Mon, 2006-05-01 at 19:35 +1000, Benjamin Herrenschmidt wrote:
> No need to schedule work, it should work fine to re-queue
Untested because I haven't rebooted. Does this look good to you?
I don't see how I could get away without locking, especially with
handling the outstanding requests (though loosing one there might not be
too bad).
johannes
Index: wireless-dev/drivers/ide/Kconfig
===================================================================
--- wireless-dev.orig/drivers/ide/Kconfig 2006-04-30 22:17:49.201535187 +0200
+++ wireless-dev/drivers/ide/Kconfig 2006-04-30 22:17:51.911535187 +0200
@@ -773,13 +773,6 @@ config BLK_DEV_IDEDMA_PMAC
to transfer data to and from memory. Saying Y is safe and improves
performance.
-config BLK_DEV_IDE_PMAC_BLINK
- bool "Blink laptop LED on drive activity"
- depends on BLK_DEV_IDE_PMAC && ADB_PMU
- help
- This option enables the use of the sleep LED as a hard drive
- activity LED.
-
config BLK_DEV_IDE_SWARM
tristate "IDE for Sibyte evaluation boards"
depends on SIBYTE_SB1xxx_SOC
Index: wireless-dev/drivers/ide/ppc/pmac.c
===================================================================
--- wireless-dev.orig/drivers/ide/ppc/pmac.c 2006-04-30 22:17:49.221535187 +0200
+++ wireless-dev/drivers/ide/ppc/pmac.c 2006-04-30 22:17:51.911535187 +0200
@@ -421,107 +421,6 @@ static void pmac_ide_kauai_selectproc(id
#endif /* CONFIG_BLK_DEV_IDEDMA_PMAC */
/*
- * Below is the code for blinking the laptop LED along with hard
- * disk activity.
- */
-
-#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
-
-/* Set to 50ms minimum led-on time (also used to limit frequency
- * of requests sent to the PMU
- */
-#define PMU_HD_BLINK_TIME (HZ/50)
-
-static struct adb_request pmu_blink_on, pmu_blink_off;
-static spinlock_t pmu_blink_lock;
-static unsigned long pmu_blink_stoptime;
-static int pmu_blink_ledstate;
-static struct timer_list pmu_blink_timer;
-static int pmu_ide_blink_enabled;
-
-
-static void
-pmu_hd_blink_timeout(unsigned long data)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&pmu_blink_lock, flags);
-
- /* We may have been triggered again in a racy way, check
- * that we really want to switch it off
- */
- if (time_after(pmu_blink_stoptime, jiffies))
- goto done;
-
- /* Previous req. not complete, try 100ms more */
- if (pmu_blink_off.complete == 0)
- mod_timer(&pmu_blink_timer, jiffies + PMU_HD_BLINK_TIME);
- else if (pmu_blink_ledstate) {
- pmu_request(&pmu_blink_off, NULL, 4, 0xee, 4, 0, 0);
- pmu_blink_ledstate = 0;
- }
-done:
- spin_unlock_irqrestore(&pmu_blink_lock, flags);
-}
-
-static void
-pmu_hd_kick_blink(void *data, int rw)
-{
- unsigned long flags;
-
- pmu_blink_stoptime = jiffies + PMU_HD_BLINK_TIME;
- wmb();
- mod_timer(&pmu_blink_timer, pmu_blink_stoptime);
- /* Fast path when LED is already ON */
- if (pmu_blink_ledstate == 1)
- return;
- spin_lock_irqsave(&pmu_blink_lock, flags);
- if (pmu_blink_on.complete && !pmu_blink_ledstate) {
- pmu_request(&pmu_blink_on, NULL, 4, 0xee, 4, 0, 1);
- pmu_blink_ledstate = 1;
- }
- spin_unlock_irqrestore(&pmu_blink_lock, flags);
-}
-
-static int
-pmu_hd_blink_init(void)
-{
- struct device_node *dt;
- const char *model;
-
- /* Currently, I only enable this feature on KeyLargo based laptops,
- * older laptops may support it (at least heathrow/paddington) but
- * I don't feel like loading those venerable old machines with so
- * much additional interrupt & PMU activity...
- */
- if (pmu_get_model() != PMU_KEYLARGO_BASED)
- return 0;
-
- dt = of_find_node_by_path("/");
- if (dt == NULL)
- return 0;
- model = (const char *)get_property(dt, "model", NULL);
- if (model == NULL)
- return 0;
- if (strncmp(model, "PowerBook", strlen("PowerBook")) != 0 &&
- strncmp(model, "iBook", strlen("iBook")) != 0) {
- of_node_put(dt);
- return 0;
- }
- of_node_put(dt);
-
- pmu_blink_on.complete = 1;
- pmu_blink_off.complete = 1;
- spin_lock_init(&pmu_blink_lock);
- init_timer(&pmu_blink_timer);
- pmu_blink_timer.function = pmu_hd_blink_timeout;
-
- return 1;
-}
-
-#endif /* CONFIG_BLK_DEV_IDE_PMAC_BLINK */
-
-/*
* N.B. this can't be an initfunc, because the media-bay task can
* call ide_[un]register at any time.
*/
@@ -1190,23 +1089,6 @@ pmac_ide_do_suspend(ide_hwif_t *hwif)
pmif->timings[0] = 0;
pmif->timings[1] = 0;
-#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
- /* Note: This code will be called for every hwif, thus we'll
- * try several time to stop the LED blinker timer, but that
- * should be harmless
- */
- if (pmu_ide_blink_enabled) {
- unsigned long flags;
-
- /* Make sure we don't hit the PMU blink */
- spin_lock_irqsave(&pmu_blink_lock, flags);
- if (pmu_blink_ledstate)
- del_timer(&pmu_blink_timer);
- pmu_blink_ledstate = 0;
- spin_unlock_irqrestore(&pmu_blink_lock, flags);
- }
-#endif /* CONFIG_BLK_DEV_IDE_PMAC_BLINK */
-
disable_irq(pmif->irq);
/* The media bay will handle itself just fine */
@@ -1374,13 +1256,6 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
hwif->selectproc = pmac_ide_selectproc;
hwif->speedproc = pmac_ide_tune_chipset;
-#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
- pmu_ide_blink_enabled = pmu_hd_blink_init();
-
- if (pmu_ide_blink_enabled)
- hwif->led_act = pmu_hd_kick_blink;
-#endif
-
printk(KERN_INFO "ide%d: Found Apple %s controller, bus ID %d%s, irq %d\n",
hwif->index, model_name[pmif->kind], pmif->aapl_bus_id,
pmif->mediabay ? " (mediabay)" : "", hwif->irq);
Index: wireless-dev/drivers/macintosh/Kconfig
===================================================================
--- wireless-dev.orig/drivers/macintosh/Kconfig 2006-04-30 22:17:49.301535187 +0200
+++ wireless-dev/drivers/macintosh/Kconfig 2006-05-01 22:39:34.951534234 +0200
@@ -78,6 +78,17 @@ config ADB_PMU
this device; you should do so if your machine is one of those
mentioned above.
+config ADB_PMU_LED
+ bool "Support for the Power/iBook front LED"
+ depends on ADB_PMU
+ select LEDS_CLASS
+ help
+ Support the front LED on Power/iBooks as a generic LED that can
+ be triggered by any of the supported triggers. To get the
+ behaviour of the old CONFIG_BLK_DEV_IDE_PMAC_BLINK, select this
+ and the ide-disk LED trigger and configure appropriately through
+ sysfs.
+
config PMAC_SMU
bool "Support for SMU based PowerMacs"
depends on PPC_PMAC64
Index: wireless-dev/drivers/macintosh/Makefile
===================================================================
--- wireless-dev.orig/drivers/macintosh/Makefile 2006-04-30 22:17:49.311535187 +0200
+++ wireless-dev/drivers/macintosh/Makefile 2006-05-01 22:36:32.871534234 +0200
@@ -12,6 +12,7 @@ obj-$(CONFIG_INPUT_ADBHID) += adbhid.o
obj-$(CONFIG_ANSLCD) += ans-lcd.o
obj-$(CONFIG_ADB_PMU) += via-pmu.o
+obj-$(CONFIG_ADB_PMU_LED) += via-pmu-led.o
obj-$(CONFIG_ADB_CUDA) += via-cuda.o
obj-$(CONFIG_PMAC_APM_EMU) += apm_emu.o
obj-$(CONFIG_PMAC_SMU) += smu.o
Index: wireless-dev/drivers/macintosh/via-pmu-led.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ wireless-dev/drivers/macintosh/via-pmu-led.c 2006-05-01 23:18:41.001534234 +0200
@@ -0,0 +1,120 @@
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/leds.h>
+#include <linux/adb.h>
+#include <linux/pmu.h>
+#include <asm/prom.h>
+
+static spinlock_t pmu_blink_lock;
+static struct adb_request pmu_blink_req;
+/* -1: no change, 0: request off, 1: request on */
+static int requested_change;
+static int sleeping;
+
+static void pmu_req_done(struct adb_request * req)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&pmu_blink_lock, flags);
+ /* if someone requested a change in the meantime
+ * (we only see the last one which is fine)
+ * then apply it now */
+ if (requested_change != -1 && !sleeping)
+ pmu_request(&pmu_blink_req, NULL, 4, 0xee, 4, 0, requested_change);
+ /* reset requested change */
+ requested_change = -1;
+ spin_unlock_irqrestore(&pmu_blink_lock, flags);
+}
+
+static void pmu_led_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&pmu_blink_lock, flags);
+ switch (brightness) {
+ case LED_OFF:
+ requested_change = 0;
+ break;
+ case LED_FULL:
+ requested_change = 1;
+ break;
+ default:
+ goto out;
+ break;
+ }
+ /* if request isn't done, then don't do anything */
+ if (pmu_blink_req.complete && !sleeping)
+ pmu_request(&pmu_blink_req, NULL, 4, 0xee, 4, 0, requested_change);
+ out:
+ spin_unlock_irqrestore(&pmu_blink_lock, flags);
+}
+
+static struct led_classdev pmu_led = {
+ .name = "pmu-front-led",
+ .brightness_set = pmu_led_set,
+};
+
+#ifdef CONFIG_PM
+static int pmu_led_sleep_call(struct pmu_sleep_notifier *self, int when)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&pmu_blink_lock, flags);
+
+ switch (when) {
+ case PBOOK_SLEEP_REQUEST:
+ sleeping = 1;
+ break;
+ case PBOOK_WAKE:
+ sleeping = 0;
+ break;
+ default:
+ /* do nothing */
+ break;
+ }
+ spin_unlock_irqrestore(&pmu_blink_lock, flags);
+
+ return PBOOK_SLEEP_OK;
+}
+
+static struct pmu_sleep_notifier pmu_led_sleep_notif = {
+ .notifier_call = pmu_led_sleep_call,
+};
+#endif
+
+static __init int pmu_led_init(void)
+{
+ struct device_node *dt;
+ const char *model;
+
+ /* only do this on keylargo based models */
+ if (pmu_get_model() != PMU_KEYLARGO_BASED)
+ return -ENODEV;
+
+ dt = of_find_node_by_path("/");
+ if (dt == NULL)
+ return -ENODEV;
+ model = (const char *)get_property(dt, "model", NULL);
+ if (model == NULL)
+ return -ENODEV;
+ if (strncmp(model, "PowerBook", strlen("PowerBook")) != 0 &&
+ strncmp(model, "iBook", strlen("iBook")) != 0) {
+ of_node_put(dt);
+ /* silently ignore */
+ return 0;
+ }
+ of_node_put(dt);
+
+ spin_lock_init(&pmu_blink_lock);
+ /* no outstanding req */
+ pmu_blink_req.complete = 1;
+ pmu_blink_req.done = pmu_req_done;
+#ifdef CONFIG_PM
+ pmu_register_sleep_notifier(&pmu_led_sleep_notif);
+#endif
+ return led_classdev_register(NULL, &pmu_led);
+}
+
+late_initcall(pmu_led_init);
^ permalink raw reply
* Re: DTC/dts modifications
From: Kumar Gala @ 2006-05-01 20:28 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev, jdl
In-Reply-To: <20060501150728.04694488.kim.phillips@freescale.com>
On May 1, 2006, at 3:07 PM, Kim Phillips wrote:
> On Mon, 1 May 2006 14:52:23 -0500
> Kumar Gala <galak@kernel.crashing.org> wrote:
>
>> [snip]
>>
>>>> Try running a current .dts through cpp today. You will get errors
>>>> like:
>>>>
>>>> oftree.dts:15:3: error: invalid preprocessing directive #address
>>>
>>>> Because of props like:
>>>>
>>>> #cpus = <1>;
>>>> #address-cells = <1>;
>>>> #size-cells = <0>;
>>>>
>>>> If these used some other symbol instead of '#' cpp will be happy
>>>> and
>>>> we can use it to create macros for us.
>>>
>>> Yeah, we're not going to be able to change those; they
>>> are "By The Book".
>>
>> By what book? It would seem to me that BNF for dtc is completely
>> under our control and if we want to change it we can. I understand
>> that there is some correspondence to Open Firmware, but it seems that
>> if its people are ok with the dts format changing that's a lot easier
>> than implementing tons of support in dtc for features that cpp
>> gives us.
>>
>> [I'm also guessing no one's really got time to go and implement these
>> features in dtc]
>>
> cpp -x assembler-with-cpp seems to not produce the above errors,
> and still honours preprocessing directives like #define. Don't
> know what else is messes with, and whether you want to add CPPFLAGS.
Cool, here's an invocation that seems to work well. Not sure what
causes linux = 1 (thus I need the -U linux). Also address the line
information that is normally spit out.
cpp -U linux -P -x assembler-with-cpp foo.dts
With a 8349 dts I'm using I'm able to run it through cpp then dts and
get the exact same dtb.
- kumar
^ permalink raw reply
* Re: DTC/dts modifications
From: Kim Phillips @ 2006-05-01 20:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, jdl
In-Reply-To: <55FD11DB-54AF-4284-9E9A-C313F4232105@kernel.crashing.org>
On Mon, 1 May 2006 14:52:23 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
> [snip]
>
> >> Try running a current .dts through cpp today. You will get errors
> >> like:
> >>
> >> oftree.dts:15:3: error: invalid preprocessing directive #address
> >
> >> Because of props like:
> >>
> >> #cpus = <1>;
> >> #address-cells = <1>;
> >> #size-cells = <0>;
> >>
> >> If these used some other symbol instead of '#' cpp will be happy and
> >> we can use it to create macros for us.
> >
> > Yeah, we're not going to be able to change those; they
> > are "By The Book".
>
> By what book? It would seem to me that BNF for dtc is completely
> under our control and if we want to change it we can. I understand
> that there is some correspondence to Open Firmware, but it seems that
> if its people are ok with the dts format changing that's a lot easier
> than implementing tons of support in dtc for features that cpp gives us.
>
> [I'm also guessing no one's really got time to go and implement these
> features in dtc]
>
cpp -x assembler-with-cpp seems to not produce the above errors, and still honours preprocessing directives like #define. Don't know what else is messes with, and whether you want to add CPPFLAGS.
Kim
> > Instead, we'll have to make the lexical analysis conscious
> > of something like a <newline> context sensitive token or so.
> > Or throw some flag to cpp to not emit location markers.
>
> - kumar
^ permalink raw reply
* Re: DTC/dts modifications
From: Kumar Gala @ 2006-05-01 19:52 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Jon Loeliger, linuxppc-dev@ozlabs.org list
In-Reply-To: <1146512732.24239.34.camel@cashmere.sps.mot.com>
[snip]
>> Try running a current .dts through cpp today. You will get errors
>> like:
>>
>> oftree.dts:15:3: error: invalid preprocessing directive #address
>
>> Because of props like:
>>
>> #cpus = <1>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> If these used some other symbol instead of '#' cpp will be happy and
>> we can use it to create macros for us.
>
> Yeah, we're not going to be able to change those; they
> are "By The Book".
By what book? It would seem to me that BNF for dtc is completely
under our control and if we want to change it we can. I understand
that there is some correspondence to Open Firmware, but it seems that
if its people are ok with the dts format changing that's a lot easier
than implementing tons of support in dtc for features that cpp gives us.
[I'm also guessing no one's really got time to go and implement these
features in dtc]
> Instead, we'll have to make the lexical analysis conscious
> of something like a <newline> context sensitive token or so.
> Or throw some flag to cpp to not emit location markers.
- kumar
^ permalink raw reply
* Re: DTC/dts modifications
From: Jon Loeliger @ 2006-05-01 19:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: Jon Loeliger, linuxppc-dev@ozlabs.org list
In-Reply-To: <695BB790-1E64-4B53-91DD-7DD88305F201@kernel.crashing.org>
On Mon, 2006-05-01 at 14:39, Kumar Gala wrote:
>
> Comment aren't the issue.
Ah, ok.
> > I think to get CPP to be usable, it will need to handle
> > the # emitted line-location markers, "# <line> <file> <level>".
>
> Don't follow you here.
The pre-processor emits crap like this:
# 1 "cmd_load.c"
# 1 "/proj/ppc/sysperf/sw/u/jdl/86xx/u-boot-86xx/common//"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "cmd_load.c"
# 27 "cmd_load.c"
# 1 "/proj/ppc/sysperf/sw/u/jdl/86xx/u-boot-86xx/include/common.h" 1
# 30 "/proj/ppc/sysperf/sw/u/jdl/86xx/u-boot-86xx/include/common.h"
typedef unsigned char uchar;
typedef volatile unsigned long vu_long;
typedef volatile unsigned short vu_short;
typedef volatile unsigned char vu_char;
> Try running a current .dts through cpp today. You will get errors like:
>
> oftree.dts:15:3: error: invalid preprocessing directive #address
> Because of props like:
>
> #cpus = <1>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> If these used some other symbol instead of '#' cpp will be happy and
> we can use it to create macros for us.
Yeah, we're not going to be able to change those; they
are "By The Book".
Instead, we'll have to make the lexical analysis conscious
of something like a <newline> context sensitive token or so.
Or throw some flag to cpp to not emit location markers.
Or something.
jdl
^ permalink raw reply
* Re: DTC/dts modifications
From: Kumar Gala @ 2006-05-01 19:39 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Jon Loeliger, linuxppc-dev@ozlabs.org list
In-Reply-To: <1146512012.24239.28.camel@cashmere.sps.mot.com>
On May 1, 2006, at 2:33 PM, Jon Loeliger wrote:
> On Sat, 2006-04-29 at 11:00, Kumar Gala wrote:
>> All,
>>
>> What evilness would it be to change the use of '#' in the .dts format
>> to some other character like '$' or '%'.
>
> Uh, use of '#' for what? Current comment style is
> either C or C++, ie, /* ... */ or //.
Comment aren't the issue.
>> The problem is the use of
>> '#' prevents use from using cpp which would make some aspects of
>> building up .dts for boards far more useful.
>
> I think to get CPP to be usable, it will need to handle
> the # emitted line-location markers, "# <line> <file> <level>".
Don't follow you here.
>> We can easily provide a one line script to convert people's .dts to
>> the new format.
>
> I don't think there is a conversion necessary yet.
> Did I miss something here?
Try running a current .dts through cpp today. You will get errors like:
oftree.dts:15:3: error: invalid preprocessing directive #address
oftree.dts:16:3: error: invalid preprocessing directive #size
oftree.dts:20:4: error: invalid preprocessing directive #cpus
oftree.dts:21:4: error: invalid preprocessing directive #address
oftree.dts:22:4: error: invalid preprocessing directive #size
oftree.dts:25:2: error: invalid preprocessing directive #foobar
Because of props like:
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
If these used some other symbol instead of '#' cpp will be happy and
we can use it to create macros for us.
- k
^ permalink raw reply
* Re: DTC/dts modifications
From: Jon Loeliger @ 2006-05-01 19:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: Jon Loeliger, linuxppc-dev@ozlabs.org list
In-Reply-To: <5CA113BC-1614-4551-87E5-6926E14C2225@kernel.crashing.org>
On Sat, 2006-04-29 at 11:00, Kumar Gala wrote:
> All,
>
> What evilness would it be to change the use of '#' in the .dts format
> to some other character like '$' or '%'.
Uh, use of '#' for what? Current comment style is
either C or C++, ie, /* ... */ or //.
> The problem is the use of
> '#' prevents use from using cpp which would make some aspects of
> building up .dts for boards far more useful.
I think to get CPP to be usable, it will need to handle
the # emitted line-location markers, "# <line> <file> <level>".
> We can easily provide a one line script to convert people's .dts to
> the new format.
I don't think there is a conversion necessary yet.
Did I miss something here?
Thanks,
jdl
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Andi Kleen @ 2006-05-01 18:34 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Andrew Morton, linuxppc64-dev, linux-kernel
In-Reply-To: <44561A1E.7000103@google.com>
On Monday 01 May 2006 16:24, Martin J. Bligh wrote:
> double fault: 0000 [1] SMP
> last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> CPU 0
> Modules linked in:
> Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> RSP: 0000:0000000000000000 EFLAGS: 00010082
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
> ffff8100db12c0d0)
> Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
> 0000000000000000 ffffffff80485520
> Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
> <ffffffff8020bba6>{do_double_fault+115}
> <ffffffff8020aa91>{double_fault+125}
> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
That's really strange - i wonder why the backtracer can't find the original
stack. Should probably add some printk diagnosis here.
Can you send the output with this patch?
Index: linux/arch/x86_64/kernel/traps.c
===================================================================
--- linux.orig/arch/x86_64/kernel/traps.c
+++ linux/arch/x86_64/kernel/traps.c
@@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
HANDLE_STACK (stack < estack_end);
i += printk(" <EOE>");
stack = (unsigned long *) estack_end[-2];
+ printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1], estack_end[-2], estack_end[-3], estack_end[-4]);
continue;
}
if (irqstack_end) {
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Andy Whitcroft @ 2006-05-01 18:32 UTC (permalink / raw)
To: Martin Bligh; +Cc: Andrew Morton, linuxppc64-dev, Badari Pulavarty, lkml, ak
In-Reply-To: <44564BEC.1040803@google.com>
Martin Bligh wrote:
> Badari Pulavarty wrote:
>
>> On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
>>
>>>> I ran mtest01 multiple times with various options on my 4-way AMD64
>>>> box.
>>>> So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>>>>
>>>> Are there any special config or test options you are testing with ?
>>>
>>>
>>> Config is here:
>>>
>>> http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>>>
>>> It's just doing "runalltests", I think.
>>
>>
>>
>> FWIW, I tried your config file on my 4-way AMD64 (melody) box and ran
>> latest "mtest01" fine.
>>
>> I am now trying runalltests. I guess, its time to bi-sect :(
>
>
> There was a panic on PPC64 during LTP too, but it seems to have gone
> away with rc3-mm1. Not sure if it was really fixed, or just intermittent.
>
> http://test.kernel.org/abat/29675/debug/console.log
I think its more intermittant than gone. I've got another machine which
runs the same tests, and she threw a very similar failure on 2.6.18-rc3-mm1.
-apw
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Martin Bligh @ 2006-05-01 17:57 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: Andrew Morton, linuxppc64-dev, ak, lkml
In-Reply-To: <1146506105.317.4.camel@dyn9047017100.beaverton.ibm.com>
Badari Pulavarty wrote:
> On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
>
>>>I ran mtest01 multiple times with various options on my 4-way AMD64 box.
>>>So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>>>
>>>Are there any special config or test options you are testing with ?
>>
>>Config is here:
>>
>>http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>>
>>It's just doing "runalltests", I think.
>
>
> FWIW, I tried your config file on my 4-way AMD64 (melody) box
> and ran latest "mtest01" fine.
>
> I am now trying runalltests. I guess, its time to bi-sect :(
There was a panic on PPC64 during LTP too, but it seems to have gone
away with rc3-mm1. Not sure if it was really fixed, or just intermittent.
http://test.kernel.org/abat/29675/debug/console.log
M.
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Badari Pulavarty @ 2006-05-01 17:55 UTC (permalink / raw)
To: Martin Bligh; +Cc: Andrew Morton, linuxppc64-dev, ak, lkml
In-Reply-To: <445644B7.7060807@google.com>
On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
> > I ran mtest01 multiple times with various options on my 4-way AMD64 box.
> > So far couldn't reproduce the problem (2.6.17-rc3-mm1).
> >
> > Are there any special config or test options you are testing with ?
>
> Config is here:
>
> http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>
> It's just doing "runalltests", I think.
FWIW, I tried your config file on my 4-way AMD64 (melody) box
and ran latest "mtest01" fine.
I am now trying runalltests. I guess, its time to bi-sect :(
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH] powerpc: Export flat device tree via debugfs for debugging
From: Kumar Gala @ 2006-05-01 17:54 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060501074044.D552967B55@ozlabs.org>
On May 1, 2006, at 2:40 AM, Michael Ellerman wrote:
> If DEBUG is turned on in prom.c, export the flat device tree via
> debugfs.
> This has been handy on several occasions.
>
> To look at it:
> # mount -t debugfs none /sys/kernel/debug
> # od -a /sys/kernel/debug/powerpc/flat-device-tree
> and/or
> # dtc -fI dtb /sys/kernel/debug/powerpc/flat-device-tree -O dts
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
>
> arch/powerpc/kernel/prom.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> Index: to-merge/arch/powerpc/kernel/prom.c
> ===================================================================
> --- to-merge.orig/arch/powerpc/kernel/prom.c
> +++ to-merge/arch/powerpc/kernel/prom.c
> @@ -30,6 +30,7 @@
> #include <linux/bitops.h>
> #include <linux/module.h>
> #include <linux/kexec.h>
> +#include <linux/debugfs.h>
>
> #include <asm/prom.h>
> #include <asm/rtas.h>
> @@ -2009,3 +2010,27 @@ void kdump_move_device_tree(void)
> /* XXX should we unreserve the old DT? */
> }
> #endif /* CONFIG_KEXEC */
> +
> +#ifdef DEBUG
Shouldn't this also depend on DEBUGFS being built in.
> +static struct debugfs_blob_wrapper flat_dt_blob;
> +
> +static int __init export_flat_device_tree(void)
> +{
> + struct dentry *d;
> +
> + d = debugfs_create_dir("powerpc", NULL);
> + if (!d)
> + return 1;
> +
> + flat_dt_blob.data = initial_boot_params;
> + flat_dt_blob.size = initial_boot_params->totalsize;
> +
> + d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
> + d, &flat_dt_blob);
> + if (!d)
> + return 1;
> +
> + return 0;
> +}
> +__initcall(export_flat_device_tree);
> +#endif
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Large Page Support, 2.6 kernel , PPC440
From: moris dong @ 2006-05-01 17:35 UTC (permalink / raw)
To: linuxppc-embedded
Friends,
My PPC440 (32bit) MMU supports multiple page sizes.
For the default 4K pages, my 2.6.11 kernel compiles and boots just fine.
I want to re-build it with large pages, to improve my application
performance.
I tried modifying PAGE_SHIFT in "page.h" to 13 (8K pages) and re-build my
kernel.
Compilation worked out fine, but my kernel does NOT boot, nor it prints
anything to the console.
Has anyone successfully compiled & booted a 2.6 kernel with pages larger
than 4K ?
What am I doing wrong ?
Thanks a lot.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply
* Large Page Support, 2.6 kernel , PPC440
From: moris dong @ 2006-05-01 17:34 UTC (permalink / raw)
To: linuxppc-dev
Friends,
My PPC440 (32bit) MMU supports multiple page sizes.
For the default 4K pages, my 2.6.11 kernel compiles and boots just fine.
I want to re-build it with large pages, to improve my application
performance.
I tried modifying PAGE_SHIFT in "page.h" to 13 (8K pages) and re-build my
kernel.
Compilation worked out fine, but my kernel does NOT boot, nor it prints
anything to the console.
Has anyone successfully compiled & booted a 2.6 kernel with pages larger
than 4K ?
What am I doing wrong ?
Thanks a lot.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Martin Bligh @ 2006-05-01 17:26 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: Andrew Morton, linuxppc64-dev, ak, lkml
In-Reply-To: <1146503960.317.1.camel@dyn9047017100.beaverton.ibm.com>
> I ran mtest01 multiple times with various options on my 4-way AMD64 box.
> So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>
> Are there any special config or test options you are testing with ?
Config is here:
http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
It's just doing "runalltests", I think.
M.
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Badari Pulavarty @ 2006-05-01 17:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc64-dev, ak, lkml, Martin J. Bligh
In-Reply-To: <20060501100731.051f4eff.akpm@osdl.org>
On Mon, 2006-05-01 at 10:07 -0700, Andrew Morton wrote:
> "Martin J. Bligh" <mbligh@google.com> wrote:
> >
> > Andrew Morton wrote:
> > > (I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
> > >
> > > Martin Bligh <mbligh@google.com> wrote:
> > >
> > >>Still crashes in LTP on x86_64:
> > >>(introduced in previous release)
> > >>
> > >>http://test.kernel.org/abat/29674/debug/console.log
> > >
> > >
> > > What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
> > > hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
> > > be stuck in flush_tlb_others. One of these could be a consequence of the
> > > other, or both could be a consequence of something else.
> >
> > OK, well the latest one seems cleaner, on -rc3-mm1.
> > http://test.kernel.org/abat/30007/debug/console.log
> >
> > Just has the double fault, with no NMI watchdog timeouts. Not that
> > it means any more to me, but still ;-) mtest01 seems to be able to
> > reproduce this every time, but I don't have an appropriate box here
> > to diagnose it with (this was a 4x Opteron inside IBM), and it's
> > definitely something in -mm that's not in mainline.
> >
> > M.
> >
> > double fault: 0000 [1] SMP
> > last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> > CPU 0
> > Modules linked in:
> > Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> > RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> > RSP: 0000:0000000000000000 EFLAGS: 00010082
> > RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> > RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> > RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> > R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> > FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> > CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
> > CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> > Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
> > ffff8100db12c0d0)
> > Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
> > 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
> > 0000000000000000 ffffffff80485520
> > Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
> > <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
> > <ffffffff8020bba6>{do_double_fault+115}
> > <ffffffff8020aa91>{double_fault+125}
> > <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
> >
> > Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
> > RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
> > -- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
>
> I was not able to reproduce this on the 4-way EMT64 machine. Am a bit stuck.
I ran mtest01 multiple times with various options on my 4-way AMD64 box.
So far couldn't reproduce the problem (2.6.17-rc3-mm1).
Are there any special config or test options you are testing with ?
Thanks,
Badari
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Martin Bligh @ 2006-05-01 17:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc64-dev, ak, linux-kernel
In-Reply-To: <20060501100731.051f4eff.akpm@osdl.org>
>>double fault: 0000 [1] SMP
>>last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
>>CPU 0
>>Modules linked in:
>>Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
>>RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
>>RSP: 0000:0000000000000000 EFLAGS: 00010082
>>RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
>>RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
>>RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
>>R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>>R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
>>FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
>>CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
>>CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
>>Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
>>ffff8100db12c0d0)
>>Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
>> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
>> 0000000000000000 ffffffff80485520
>>Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
>> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
>> <ffffffff8020bba6>{do_double_fault+115}
>><ffffffff8020aa91>{double_fault+125}
>> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
>>
>>Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
>>RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
>> -- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
>
>
> I was not able to reproduce this on the 4-way EMT64 machine. Am a bit stuck.
OK, is there anything we could run this with that'd dump more info?
(eg debug patches or something). There's bugger all of use that I
can see in that stack (and why does __sched_text_start come up anyway,
is that an x86_64-ism ?). I suppose if we're really desperate, we can
play chop search, but that's very boring to try to do remotely ...
It's a couple-of-year-old 4x newisys box.
M.
^ permalink raw reply
* Re: [openib-general] Re: [PATCH 00/16] ehca: IBM eHCA InfiniBand Device Driver
From: Roland Dreier @ 2006-05-01 17:03 UTC (permalink / raw)
To: Heiko Joerg Schick; +Cc: linuxppc-dev, linux-kernel, openib-general
In-Reply-To: <e2r7a0$fo2$1@sea.gmane.org>
Heiko> I don't like the idea to put the whole driver in one patch
Heiko> file. I would propose to put the patch "ehca: integration
Heiko> in Linux kernel" last instead of first, as Arnd
Heiko> mentioned. With that change we leave the kernel in a
Heiko> working state when applying the patches.
Yes, that makes sense.
And I can fold the patches into a single git changeset when we finally
merge it, since I don't see any advantage to having the driver split
into pieces. (No one is going to git biset a half-applied driver or
anything like that)
- R.
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Andrew Morton @ 2006-05-01 17:07 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: linuxppc64-dev, ak, linux-kernel
In-Reply-To: <44561A1E.7000103@google.com>
"Martin J. Bligh" <mbligh@google.com> wrote:
>
> Andrew Morton wrote:
> > (I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
> >
> > Martin Bligh <mbligh@google.com> wrote:
> >
> >>Still crashes in LTP on x86_64:
> >>(introduced in previous release)
> >>
> >>http://test.kernel.org/abat/29674/debug/console.log
> >
> >
> > What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
> > hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
> > be stuck in flush_tlb_others. One of these could be a consequence of the
> > other, or both could be a consequence of something else.
>
> OK, well the latest one seems cleaner, on -rc3-mm1.
> http://test.kernel.org/abat/30007/debug/console.log
>
> Just has the double fault, with no NMI watchdog timeouts. Not that
> it means any more to me, but still ;-) mtest01 seems to be able to
> reproduce this every time, but I don't have an appropriate box here
> to diagnose it with (this was a 4x Opteron inside IBM), and it's
> definitely something in -mm that's not in mainline.
>
> M.
>
> double fault: 0000 [1] SMP
> last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> CPU 0
> Modules linked in:
> Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> RSP: 0000:0000000000000000 EFLAGS: 00010082
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
> ffff8100db12c0d0)
> Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
> 0000000000000000 ffffffff80485520
> Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
> <ffffffff8020bba6>{do_double_fault+115}
> <ffffffff8020aa91>{double_fault+125}
> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
>
> Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
> RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
> -- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
I was not able to reproduce this on the 4-way EMT64 machine. Am a bit stuck.
^ permalink raw reply
* Re: PPC 405GPr support in linux 2.4.32
From: Stephen Williams @ 2006-05-01 15:21 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Willy Tarreau
In-Reply-To: <20060430164013.GA4631@dmt>
Marcelo Tosatti wrote:
> Folks,
>
> The v2.4 patch acceptance policy has been shifting gradually from
> "accept new features" to "critical fixes only", and at this point in
> time the goal is to have a minimal amount of modifications as possible.
>
> There should be no need for major patch reworking with reference to new
> v2.4 releases.
>
> Willy Tarreau created a repository of useful v2.4 patches for this sort
> of situations. Stephen, Eugene, I think the 405GPr patches are good candidates.
>
> http://w.ods.org/linux/kernel/2.4/lkup/hardware.html
This (and things like it) needs to be *much* better advertised.
I had no idea it existed, or where I would look for such a thing.
It does no one any good if no one thinks to look for it;-)
If course the next major question is how does one submit patches
to this system?
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Martin J. Bligh @ 2006-05-01 14:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc64-dev, Andi Kleen, linux-kernel
In-Reply-To: <20060428012022.7b73c77b.akpm@osdl.org>
Andrew Morton wrote:
> (I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
>
> Martin Bligh <mbligh@google.com> wrote:
>
>>Still crashes in LTP on x86_64:
>>(introduced in previous release)
>>
>>http://test.kernel.org/abat/29674/debug/console.log
>
>
> What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
> hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
> be stuck in flush_tlb_others. One of these could be a consequence of the
> other, or both could be a consequence of something else.
OK, well the latest one seems cleaner, on -rc3-mm1.
http://test.kernel.org/abat/30007/debug/console.log
Just has the double fault, with no NMI watchdog timeouts. Not that
it means any more to me, but still ;-) mtest01 seems to be able to
reproduce this every time, but I don't have an appropriate box here
to diagnose it with (this was a 4x Opteron inside IBM), and it's
definitely something in -mm that's not in mainline.
M.
double fault: 0000 [1] SMP
last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
CPU 0
Modules linked in:
Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
RSP: 0000:0000000000000000 EFLAGS: 00010082
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
ffff8100db12c0d0)
Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
0000000000000000 ffffffff80485520
Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
<ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
<ffffffff8020bba6>{do_double_fault+115}
<ffffffff8020aa91>{double_fault+125}
<ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
-- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
^ permalink raw reply
* [PATCH 7/7] Print out debugging information during initialisation
From: Mel Gorman @ 2006-05-01 13:37 UTC (permalink / raw)
To: akpm, davej, tony.luck, linux-mm, linux-kernel, bob.picco, ak,
linuxppc-dev
Cc: Mel Gorman
In-Reply-To: <20060501133530.6379.66000.sendpatchset@skynet>
The zone and hole sizing code is new and unexpected problems showed up
during early releases on machines that were not covered by the pre-release
tests. This patch prints out useful information when those unexpected
situations occur.
It is not expected that this patch become a permanent part of the set.
mem_init.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 58 insertions(+), 4 deletions(-)
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc3-mm1-106-breakout_mem_init/mm/mem_init.c linux-2.6.17-rc3-mm1-107-debug/mm/mem_init.c
--- linux-2.6.17-rc3-mm1-106-breakout_mem_init/mm/mem_init.c 2006-05-01 11:51:50.000000000 +0100
+++ linux-2.6.17-rc3-mm1-107-debug/mm/mem_init.c 2006-05-01 11:51:50.000000000 +0100
@@ -341,6 +341,9 @@ void __meminit memmap_init_zone(unsigned
unsigned long end_pfn = start_pfn + size;
unsigned long pfn;
+ printk("memmap_init_zone(size %lu, nid %d, zone %lu, start_pfn %lu)\n",
+ size, nid, zone, start_pfn);
+
for (pfn = start_pfn; pfn < end_pfn; pfn++) {
if (!early_pfn_valid(pfn))
continue;
@@ -661,6 +664,7 @@ __meminit int init_currently_empty_zone(
}
#ifdef CONFIG_ARCH_POPULATES_NODE_MAP
+
/* Note: nid == MAX_NUMNODES returns first region */
static int __init first_active_region_index_in_nid(int nid)
{
@@ -713,13 +717,24 @@ void __init free_bootmem_with_active_reg
for_each_active_range_index_in_nid(i, nid) {
unsigned long size_pages = 0;
unsigned long end_pfn = early_node_map[i].end_pfn;
- if (early_node_map[i].start_pfn >= max_low_pfn)
+ if (early_node_map[i].start_pfn >= max_low_pfn) {
+ printk("start_pfn %lu >= %lu\n", early_node_map[i].start_pfn,
+ max_low_pfn);
continue;
+ }
- if (end_pfn > max_low_pfn)
+ if (end_pfn > max_low_pfn) {
+ printk("end_pfn %lu going back to %lu\n", early_node_map[i].end_pfn,
+ max_low_pfn);
end_pfn = max_low_pfn;
+ }
size_pages = end_pfn - early_node_map[i].start_pfn;
+ printk("free_bootmem_node(%d, %lu, %lu) :::: pfn ranges (%d, %lu, %lu)\n",
+ early_node_map[i].nid,
+ PFN_PHYS(early_node_map[i].start_pfn),
+ PFN_PHYS(size_pages),
+ early_node_map[i].nid, early_node_map[i].start_pfn, end_pfn);
free_bootmem_node(NODE_DATA(early_node_map[i].nid),
PFN_PHYS(early_node_map[i].start_pfn),
size_pages << PAGE_SHIFT);
@@ -729,10 +744,15 @@ void __init free_bootmem_with_active_reg
void __init sparse_memory_present_with_active_regions(int nid)
{
unsigned int i;
- for_each_active_range_index_in_nid(i, nid)
+ for_each_active_range_index_in_nid(i, nid) {
+ printk("memory_present(%d, %lu, %lu)\n",
+ early_node_map[i].nid,
+ early_node_map[i].start_pfn,
+ early_node_map[i].end_pfn);
memory_present(early_node_map[i].nid,
early_node_map[i].start_pfn,
early_node_map[i].end_pfn);
+ }
}
void __init get_pfn_range_for_nid(unsigned int nid,
@@ -785,6 +805,8 @@ unsigned long __init __absent_pages_in_r
unsigned long prev_end_pfn = 0, hole_pages = 0;
unsigned long start_pfn;
+ printk("__absent_pages_in_range(%d, %lu, %lu) = ", nid,
+ range_start_pfn, range_end_pfn);
/* Find the end_pfn of the first active range of pfns in the node */
i = first_active_region_index_in_nid(nid);
if (i == MAX_ACTIVE_REGIONS)
@@ -811,6 +833,8 @@ unsigned long __init __absent_pages_in_r
prev_end_pfn = early_node_map[i].end_pfn;
}
+ printk("%lu\n", hole_pages);
+
return hole_pages;
}
@@ -975,6 +999,9 @@ void __init add_active_range(unsigned in
{
unsigned int i;
+ printk("add_active_range(%d, %lu, %lu): ",
+ nid, start_pfn, end_pfn);
+
/* Merge with existing active regions if possible */
for (i = 0; early_node_map[i].end_pfn; i++) {
if (early_node_map[i].nid != nid)
@@ -982,12 +1009,15 @@ void __init add_active_range(unsigned in
/* 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("Existing\n");
return;
+ }
/* Merge forward if suitable */
if (start_pfn <= early_node_map[i].end_pfn &&
end_pfn > early_node_map[i].end_pfn) {
+ printk("Merging forward\n");
early_node_map[i].end_pfn = end_pfn;
return;
}
@@ -995,6 +1025,7 @@ void __init add_active_range(unsigned in
/* Merge backward if suitable */
if (start_pfn < early_node_map[i].end_pfn &&
end_pfn >= early_node_map[i].start_pfn) {
+ printk("Merging backwards\n");
early_node_map[i].start_pfn = start_pfn;
return;
}
@@ -1006,6 +1037,7 @@ void __init add_active_range(unsigned in
return;
}
+ printk("New\n");
early_node_map[i].nid = nid;
early_node_map[i].start_pfn = start_pfn;
early_node_map[i].end_pfn = end_pfn;
@@ -1017,16 +1049,22 @@ void __init shrink_active_range(unsigned
unsigned int i;
/* Find the old active region end and shrink */
+ printk("Shrinking %u from %lu to %lu: ",
+ nid, old_end_pfn, new_end_pfn);
for_each_active_range_index_in_nid(i, nid) {
if (early_node_map[i].end_pfn == old_end_pfn) {
+ printk("Done\n");
early_node_map[i].end_pfn = new_end_pfn;
break;
}
}
+
+ printk("Not found\n");
}
void __init remove_all_active_ranges()
{
+ printk("remove_all_active_ranges()\n");
memset(early_node_map, 0, sizeof(early_node_map));
}
@@ -1054,6 +1092,14 @@ static void __init sort_node_map(void)
sort(early_node_map, num, sizeof(struct node_active_region),
cmp_node_active_region, NULL);
+
+ printk("Dumping sorted node map\n");
+ for (num = 0; early_node_map[num].end_pfn; num++) {
+ printk("entry %lu: %d %lu -> %lu\n", num,
+ early_node_map[num].nid,
+ early_node_map[num].start_pfn,
+ early_node_map[num].end_pfn);
+ }
}
/* Find the lowest pfn for a node. This depends on a sorted early_node_map */
@@ -1069,6 +1115,7 @@ unsigned long __init find_min_pfn_for_no
return 0;
}
+
unsigned long __init find_min_pfn_with_active_regions(void)
{
return find_min_pfn_for_node(MAX_NUMNODES);
@@ -1082,6 +1129,7 @@ unsigned long __init find_max_pfn_with_a
for (i = 0; early_node_map[i].end_pfn; i++)
max_pfn = max(max_pfn, early_node_map[i].end_pfn);
+ printk("find_max_pfn_with_active_regions() == %lu\n", max_pfn);
return max_pfn;
}
@@ -1093,6 +1141,10 @@ void __init free_area_init_nodes(unsigne
unsigned long nid;
int zone_index;
+ printk("free_area_init_nodes(%lu, %lu, %lu, %lu)\n",
+ arch_max_dma_pfn, arch_max_dma32_pfn,
+ arch_max_low_pfn, arch_max_high_pfn);
+
/* Record where the zone boundaries are */
memset(arch_zone_lowest_possible_pfn, 0,
sizeof(arch_zone_lowest_possible_pfn));
@@ -1109,6 +1161,8 @@ void __init free_area_init_nodes(unsigne
arch_zone_highest_possible_pfn[zone_index-1];
}
+ printk("free_area_init_nodes(): find_min_pfn = %lu\n", find_min_pfn_with_active_regions());
+
/* Regions in the early_node_map can be in any order */
sort_node_map();
^ 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