* linux 2.4.25: loading usbcore.o gives segmentation fault
From: Josef Angermeier @ 2006-04-24 12:06 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am using linux 2.4.25 for a custom MPC875 based board. When adding
general usb support as module (-> usbcore.o), loading usbcore.o gives a
segmentation fault., while compiling it builtin seems to work. How can
i find out what could be the reasons for that ?
thanks in advance, best regards
Josef
^ permalink raw reply
* [PATCH] Reserve crashkernel memory region
From: Mohan Kumar M @ 2006-04-24 6:10 UTC (permalink / raw)
To: fastboot, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
Hi,
Now kexec'ed kernel in a PPC64 machine does not reserve memory for crashkernel region. So kexec'ed kernel can not load kdump kernel reliably.
Attached kexec-tools patch reserves memory for kdump kernel by adding an entry in the reserve memory table. So while kexec'ed kernel is booting, it reserves memory for crashkernel region.
Regards,
Mohan.
[-- Attachment #2: reserve-crashkernel.patch --]
[-- Type: text/plain, Size: 6290 bytes --]
In PPC64, kexec'ed kernel does not reserve memory for crashkernel. So
kexec'ed kernel can not load kdump kernel reliably.
reserve-crashkernel-mem patch adds a reserve entry for crashkernel to the
reserve memory list, so that kexec'ed kernel reserves memory for kdump kernel.
This is done when user passes --append="crashkernel=X@Y" parameter to
kexec command. If user does not pass crashkernel option, memory is not
reserved for kdump kernel.
Signed-off-by: Mohan <mohan@in.ibm.com>
---
kexec-tools-1.101-kdump9/kexec/arch/ppc64/fs2dt.c | 135 ++++++++++++----
kexec-tools-1.101-kdump9/kexec/arch/ppc64/kexec-ppc64.h | 2
2 files changed, 107 insertions(+), 30 deletions(-)
diff -puN kexec-tools-1.101-kdump9/kexec/arch/ppc64/fs2dt.c~reserve-crashkernel kexec-tools-1.101-kdump9/kexec/arch/ppc64/fs2dt.c
--- patch/kexec-tools-1.101-kdump9/kexec/arch/ppc64/fs2dt.c~reserve-crashkernel 2006-04-19 18:49:06.000000000 +0530
+++ patch-mohan/kexec-tools-1.101-kdump9/kexec/arch/ppc64/fs2dt.c 2006-04-19 18:55:48.000000000 +0530
@@ -64,8 +64,7 @@ char propnames[NAMESPACE];
dvt dtstruct[TREEWORDS], *dt;
unsigned long long mem_rsrv[2*MEMRESERVE];
-static int initrd_found = 0;
-static int crash_param = 0;
+static unsigned long crashk_base = 0, crashk_size = 0;
char local_cmdline[COMMAND_LINE_SIZE] = { "" };
dvt *dt_len; /* changed len of modified cmdline in flat device-tree */
extern mem_rgns_t usablemem_rgns;
@@ -191,6 +190,50 @@ void add_usable_mem_property(int fd, int
dt += (rlen + 3)/4;
}
+unsigned long mem_parse(const char *ptr, const char **retptr)
+{
+ unsigned long ret = strtoul(ptr, (char **)retptr,10);
+
+ switch (**retptr) {
+ case 'G':
+ case 'g':
+ ret <<= 30;
+ (*retptr)++;
+ break;
+ case 'M':
+ case 'm':
+ ret <<= 20;
+ (*retptr)++;
+ break;
+ case 'K':
+ case 'k':
+ ret <<= 10;
+ (*retptr)++;
+ break;
+ }
+
+ return ret;
+}
+
+void parse_crash_param(char *param)
+{
+ char *cbase, *csize;
+ param += 12;
+ crashk_size = mem_parse(param, (const char **)&csize);
+
+ if (ALIGN(crashk_size, 0x1000000) != crashk_size)
+ printf("Warning: crashkernel size is not aligned to 16MB\n");
+
+ if (*csize == '@') {
+ csize++;
+ crashk_base = mem_parse(csize, (const char **)&cbase);
+ if (crashk_base != 0x2000000)
+ printf("Warning: PPC64 kdump kernel always runs at "
+ "32 MB\n");
+ }
+ crashk_base = 0x2000000;
+}
+
/* put all properties (files) in the property structure */
void putprops(char *fn, struct dirent **nlist, int numlist)
{
@@ -207,12 +250,6 @@ void putprops(char *fn, struct dirent **
if (lstat(pathname, statbuf))
err(pathname, ERR_STAT);
- if (!crash_param && !strcmp(fn,"linux,crashkernel-base"))
- continue;
-
- if (!crash_param && !strcmp(fn,"linux,crashkernel-size"))
- continue;
-
/*
* This property will be created for each node during kexec
* boot. So, ignore it.
@@ -230,6 +267,13 @@ void putprops(char *fn, struct dirent **
!strcmp(dp->d_name, "linux,initrd-end"))
continue;
+ /* This property will be created/modified later in putnode()
+ * So ignore it.
+ */
+ if (!strcmp(dp->d_name, "linux,crashkernel-base") ||
+ !strcmp(dp->d_name, "linux,crashkernel-size"))
+ continue;
+
if (S_ISREG(statbuf[0].st_mode)) {
int fd, len = statbuf[0].st_size;
@@ -260,7 +304,7 @@ void putprops(char *fn, struct dirent **
param = strstr(local_cmdline,
"crashkernel=");
if (param)
- crash_param = 1;
+ parse_crash_param(param);
param = strstr(local_cmdline, "root=");
}
if (!param) {
@@ -347,35 +391,66 @@ void putnode(void)
putprops(dn, namelist, numlist);
- /* Add initrd entries to the second kernel if first kernel does not
- * have and second kernel needs.
- */
- if (initrd_base && !initrd_found && !strcmp(basename,"/chosen/")) {
+ if (!strcmp(basename,"/chosen/")) {
int len = 8;
unsigned long long initrd_end;
- *dt++ = 3;
- *dt++ = len;
- *dt++ = propnum("linux,initrd-start");
- if ((len >= 8) && ((unsigned long)dt & 0x4))
- dt++;
+ /* Add initrd entries to the second kernel if first
+ * kernel does not have and second kernel needs.
+ */
+ if (initrd_base) {
+ *dt++ = 3;
+ *dt++ = len;
+ *dt++ = propnum("linux,initrd-start");
+
+ if ((len >= 8) && ((unsigned long)dt & 0x4))
+ dt++;
+
+ memcpy(dt,&initrd_base,len);
+ dt += (len + 3)/4;
+
+ len = 8;
+ *dt++ = 3;
+ *dt++ = len;
+ *dt++ = propnum("linux,initrd-end");
+
+ initrd_end = initrd_base + initrd_size;
+ if ((len >= 8) && ((unsigned long)dt & 0x4))
+ dt++;
+
+ memcpy(dt,&initrd_end,len);
+ dt += (len + 3)/4;
+
+ reserve(initrd_base, initrd_size);
+ }
+
+ /* Add crashkernel details to the second kernel if first
+ * kernel does not have and reserve memory for that
+ */
+ if (crashk_base) {
+ *dt++ = 3;
+ *dt++ = len;
+ *dt++ = propnum("linux,crashkernel-base");
- memcpy(dt,&initrd_base,len);
- dt += (len + 3)/4;
+ if ((len >= 8) && ((unsigned long)dt & 0x4))
+ dt++;
- len = 8;
- *dt++ = 3;
- *dt++ = len;
- *dt++ = propnum("linux,initrd-end");
+ memcpy(dt,&crashk_base,len);
+ dt += (len + 3)/4;
- initrd_end = initrd_base + initrd_size;
- if ((len >= 8) && ((unsigned long)dt & 0x4))
- dt++;
+ len = 8;
+ *dt++ = 3;
+ *dt++ = len;
+ *dt++ = propnum("linux,crashkernel-size");
+
+ if ((len >= 8) && ((unsigned long)dt & 0x4))
+ dt++;
- memcpy(dt,&initrd_end,len);
- dt += (len + 3)/4;
+ memcpy(dt,&crashk_size,len);
+ dt += (len + 3)/4;
- reserve(initrd_base, initrd_size);
+ reserve(crashk_base, crashk_size);
+ }
}
for (i=0; i < numlist; i++) {
diff -puN kexec-tools-1.101-kdump9/kexec/arch/ppc64/kexec-ppc64.h~reserve-crashkernel kexec-tools-1.101-kdump9/kexec/arch/ppc64/kexec-ppc64.h
--- patch/kexec-tools-1.101-kdump9/kexec/arch/ppc64/kexec-ppc64.h~reserve-crashkernel 2006-04-19 18:49:54.000000000 +0530
+++ patch-mohan/kexec-tools-1.101-kdump9/kexec/arch/ppc64/kexec-ppc64.h 2006-04-19 18:50:29.000000000 +0530
@@ -7,6 +7,8 @@
#define CORE_TYPE_ELF32 1
#define CORE_TYPE_ELF64 2
+#define ALIGN(val,align) (((val) + ((align) - 1)) & ~((align) - 1))
+
int setup_memory_ranges(unsigned long kexec_flags);
int elf_ppc64_probe(const char *buf, off_t len);
_
^ permalink raw reply
* sns-aoa more PM
From: Benjamin Herrenschmidt @ 2006-04-24 3:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
(resending including the list in case somebody else is interested :)
Hi Johannes. The patch below adds mute of amps along with other changes.
In random order:
- Removed the sound_bus list that seemed useless to me and use the
normal "remove" mecanism to unregister the soundbus_dev from i2sbus. I
don't know if I ended up breaking something here, we'll have to check :)
We might need to test...
- Set proper parent so i2sbus created soundbus_dev hangs off macio-dev,
thus makes it get suspend/resume with proper ordering (that is suspend
before i2sbus and resume after).
- Renamed bits & pieces in layout fabric
- Add suspend/resume hooks to layout fabric to mure/restore amps
- Add code in onyx to restore all codec registers on wakeup
With that, I now get nicely working suspend/resume without "clacs" on my
onyx based laptop. I tried Amarok and it properly stops playing on
suspend and resumes on wakeup without a glitch.
my own little todo list:
- Cleanup printk junk, use dev_* for debug * info stuff etc...
- Look into i2s probing issues (resources on some macs etc...)
- i2s has a weird address in macio node in the device-tree, look at
this
- Get TAS working on dual g5
- Do some basic topaz for dual g5
- do a pre-layout fabric for snapper/tumbler/daca
- whatever ...
diff -urN snd-aoa/aoa/codecs/onyx/snd-aoa-codec-onyx.c snd-aoa.ben/aoa/codecs/onyx/snd-aoa-codec-onyx.c
--- snd-aoa/aoa/codecs/onyx/snd-aoa-codec-onyx.c 2006-04-07 21:22:59.000000000 +1000
+++ snd-aoa.ben/aoa/codecs/onyx/snd-aoa-codec-onyx.c 2006-04-24 12:08:00.000000000 +1000
@@ -616,10 +616,32 @@
case CLOCK_SWITCH_SLAVE:
onyx->codec.gpio->methods->all_amps_restore(onyx->codec.gpio);
break;
+ default: /* silence warning */
+ break;
}
return 0;
}
+#ifdef CONFIG_PM
+
+static int onyx_suspend(struct codec_info_item *cii, pm_message_t state)
+{
+ /* TODO */
+
+ return 0;
+}
+
+static int onyx_resume(struct codec_info_item *cii)
+{
+ struct onyx *onyx = cii->codec_data;
+
+ onyx_register_init(onyx);
+
+ return 0;
+}
+
+#endif /* CONFIG_PM */
+
static struct codec_info onyx_codec_info = {
.transfers = onyx_transfers,
.sysclock_factor = 256,
@@ -630,6 +652,10 @@
.open = onyx_open,
.close = onyx_close,
.switch_clock = onyx_switch_clock,
+#ifdef CONFIG_PM
+ .suspend = onyx_suspend,
+ .resume = onyx_resume,
+#endif
};
static int onyx_init_codec(struct aoa_codec *codec)
diff -urN snd-aoa/aoa/fabrics/snd-aoa-fabric-layout.c snd-aoa.ben/aoa/fabrics/snd-aoa-fabric-layout.c
--- snd-aoa/aoa/fabrics/snd-aoa-fabric-layout.c 2006-04-07 21:22:59.000000000 +1000
+++ snd-aoa.ben/aoa/fabrics/snd-aoa-fabric-layout.c 2006-04-24 11:51:15.000000000 +1000
@@ -225,14 +225,18 @@
struct snd_ctl_elem_value *ucontrol) \
{ \
struct gpio_runtime *gpio = snd_kcontrol_chip(kcontrol); \
- ucontrol->value.integer.value[0] = gpio->methods->get_##n(gpio);\
+ if (gpio->methods && gpio->methods->get_##n) \
+ ucontrol->value.integer.value[0] = \
+ gpio->methods->get_##n(gpio); \
return 0; \
} \
static int n##_control_put(struct snd_kcontrol *kcontrol, \
struct snd_ctl_elem_value *ucontrol) \
{ \
struct gpio_runtime *gpio = snd_kcontrol_chip(kcontrol); \
- gpio->methods->set_##n(gpio, ucontrol->value.integer.value[0]); \
+ if (gpio->methods && gpio->methods->get_##n) \
+ gpio->methods->set_##n(gpio, \
+ ucontrol->value.integer.value[0]); \
return 1; \
} \
static struct snd_kcontrol_new n##_ctl = { \
@@ -328,7 +332,7 @@
.remove_codec = layout_remove_codec,
};
-static int soundbus_probe(struct soundbus_dev *sdev)
+static int aoa_fabric_layout_probe(struct soundbus_dev *sdev)
{
struct device_node *sound = NULL;
unsigned int *layout_id;
@@ -401,7 +405,7 @@
return -ENODEV;
}
-static int soundbus_remove(struct soundbus_dev *sdev)
+static int aoa_fabric_layout_remove(struct soundbus_dev *sdev)
{
struct layout_dev *ldev = sdev->ofdev.dev.driver_data;
int i;
@@ -423,11 +427,39 @@
return 0;
}
+static int aoa_fabric_layout_suspend(struct soundbus_dev *sdev, pm_message_t state)
+{
+ struct layout_dev *ldev = sdev->ofdev.dev.driver_data;
+
+ printk("aoa_fabric_layout_suspend()\n");
+
+ if (ldev->gpio.methods && ldev->gpio.methods->all_amps_off)
+ ldev->gpio.methods->all_amps_off(&ldev->gpio);
+
+ return 0;
+}
+
+static int aoa_fabric_layout_resume(struct soundbus_dev *sdev)
+{
+ struct layout_dev *ldev = sdev->ofdev.dev.driver_data;
+
+ printk("aoa_fabric_layout_resume()\n");
+
+ if (ldev->gpio.methods && ldev->gpio.methods->all_amps_off)
+ ldev->gpio.methods->all_amps_restore(&ldev->gpio);
+
+ return 0;
+}
+
static struct soundbus_driver aoa_soundbus_driver = {
.name = "snd_aoa_soundbus_drv",
.owner = THIS_MODULE,
- .probe = soundbus_probe,
- .remove = soundbus_remove,
+ .probe = aoa_fabric_layout_probe,
+ .remove = aoa_fabric_layout_remove,
+#ifdef CONFIG_PM
+ .suspend = aoa_fabric_layout_suspend,
+ .resume = aoa_fabric_layout_resume,
+#endif
};
int __init aoa_fabric_layout_init(void)
diff -urN snd-aoa/soundbus/core.c snd-aoa.ben/soundbus/core.c
--- snd-aoa/soundbus/core.c 2006-03-31 07:56:03.000000000 +1100
+++ snd-aoa.ben/soundbus/core.c 2006-04-24 11:45:59.000000000 +1000
@@ -173,6 +173,8 @@
drv->shutdown(soundbus_dev);
}
+#ifdef CONFIG_PM
+
static int soundbus_device_suspend(struct device *dev, pm_message_t state)
{
struct soundbus_dev * soundbus_dev = to_soundbus_device(dev);
@@ -193,6 +195,8 @@
return 0;
}
+#endif /* CONFIG_PM */
+
extern struct device_attribute soundbus_dev_attrs[];
static struct bus_type soundbus_bus_type = {
@@ -201,8 +205,10 @@
.uevent = soundbus_uevent,
.remove = soundbus_device_remove,
.shutdown = soundbus_device_shutdown,
+#ifdef CONFIG_PM
.suspend = soundbus_device_suspend,
.resume = soundbus_device_resume,
+#endif
.dev_attrs = soundbus_dev_attrs,
};
@@ -216,37 +222,30 @@
bus_unregister(&soundbus_bus_type);
}
-int soundbus_device_add(struct soundbus_dev *dev)
+int soundbus_add_one(struct soundbus_dev *dev)
{
static int devcount;
/* sanity checks */
if (!dev->attach_codec ||
!dev->ofdev.node ||
- !dev->bus ||
dev->pcmname ||
dev->pcmid != -1) {
printk(KERN_ERR "soundbus: adding device failed sanity check!\n");
return -EINVAL;
}
- list_add(&dev->onbuslist, &dev->bus->devices);
-
snprintf(dev->ofdev.dev.bus_id, BUS_ID_SIZE, "soundbus:%x", ++devcount);
dev->ofdev.dev.bus = &soundbus_bus_type;
return of_device_register(&dev->ofdev);
}
-EXPORT_SYMBOL_GPL(soundbus_device_add);
+EXPORT_SYMBOL_GPL(soundbus_add_one);
-void soundbus_unregister_soundbus(struct sound_bus *soundbus)
+void soundbus_remove_one(struct soundbus_dev *dev)
{
- struct soundbus_dev *dev, *tmp;
-
- list_for_each_entry_safe(dev, tmp, &soundbus->devices, onbuslist) {
- of_device_unregister(&dev->ofdev);
- }
+ of_device_unregister(&dev->ofdev);
}
-EXPORT_SYMBOL_GPL(soundbus_unregister_soundbus);
+EXPORT_SYMBOL_GPL(soundbus_remove_one);
int soundbus_register_driver(struct soundbus_driver *drv)
{
diff -urN snd-aoa/soundbus/i2sbus/i2sbus-core.c snd-aoa.ben/soundbus/i2sbus/i2sbus-core.c
--- snd-aoa/soundbus/i2sbus/i2sbus-core.c 2006-04-24 11:01:30.000000000 +1000
+++ snd-aoa.ben/soundbus/i2sbus/i2sbus-core.c 2006-04-24 12:01:30.000000000 +1000
@@ -33,9 +33,6 @@
{ }
};
-static struct sound_bus i2s_soundbus = {
-};
-
static int alloc_dbdma_descriptor_ring(struct i2sbus_dev *i2sdev,
struct dbdma_command_mem *r, int numcmds)
{
@@ -137,11 +134,10 @@
}
}
- dev->sound.bus = &i2s_soundbus;
dev->sound.ofdev.node = np;
dev->sound.ofdev.dma_mask = macio->ofdev.dma_mask;
dev->sound.ofdev.dev.dma_mask = &dev->sound.ofdev.dma_mask;
- dev->sound.ofdev.dev.parent = NULL;
+ dev->sound.ofdev.dev.parent = &macio->ofdev.dev;
dev->sound.ofdev.dev.release = i2sbus_release_dev;
dev->sound.attach_codec = i2sbus_attach_codec;
dev->sound.detach_codec = i2sbus_detach_codec;
@@ -190,7 +186,7 @@
if (alloc_dbdma_descriptor_ring(dev, &dev->in.dbdma_ring, MAX_DBDMA_COMMANDS))
goto err;
- if (soundbus_device_add(&dev->sound)) {
+ if (soundbus_add_one(&dev->sound)) {
printk(KERN_DEBUG "i2sbus: device registration error!\n");
goto err;
}
@@ -254,6 +250,9 @@
static int i2sbus_remove(struct macio_dev* dev)
{
+ struct i2sbus_dev* i2sdev = (struct i2sbus_dev*)dev->ofdev.dev.driver_data;
+ soundbus_remove_one(&i2sdev->sound);
+
return 0;
}
@@ -267,6 +266,8 @@
/* TODO: Notify fabric so that it can mute all amps */
+ printk("i2sbus_suspend()\n");
+
/* Notify Alsa */
if (i2sdev->sound.pcm) {
/* Suspend PCM streams */
@@ -289,6 +290,8 @@
struct i2sbus_dev* i2sdev = (struct i2sbus_dev*)dev->ofdev.dev.driver_data;
int err, ret = 0;
+ printk("i2sbus_resume()\n");
+
/* Notify codecs so they can re-initialize */
list_for_each_entry(cii, &i2sdev->sound.codec_list, list) {
err = 0;
@@ -332,13 +335,11 @@
static int __init soundbus_i2sbus_init(void)
{
- INIT_LIST_HEAD(&i2s_soundbus.devices);
return macio_register_driver(&i2sbus_drv);
}
static void __exit soundbus_i2sbus_exit(void)
{
- soundbus_unregister_soundbus(&i2s_soundbus);
macio_unregister_driver(&i2sbus_drv);
}
diff -urN snd-aoa/soundbus/soundbus.h snd-aoa.ben/soundbus/soundbus.h
--- snd-aoa/soundbus/soundbus.h 2006-04-16 10:44:24.000000000 +1000
+++ snd-aoa.ben/soundbus/soundbus.h 2006-04-24 11:46:06.000000000 +1000
@@ -12,12 +12,6 @@
#include <sound/pcm.h>
#include <linux/list.h>
-/*
- * the sound_bus structure is used to describe the virtual sound bus.
- */
-struct sound_bus {
- struct list_head devices;
-};
/* When switching from master to slave or the other way around,
* you don't want to have the codec chip acting as clock source
@@ -142,7 +136,6 @@
/* information on a soundbus device */
struct soundbus_dev {
/* the bus it belongs to */
- struct sound_bus *bus;
struct list_head onbuslist;
/* the of device it represents */
@@ -178,8 +171,8 @@
#define to_soundbus_device(d) container_of(d, struct soundbus_dev, ofdev.dev)
#define of_to_soundbus_device(d) container_of(d, struct soundbus_dev, ofdev)
-extern int soundbus_device_add(struct soundbus_dev *dev);
-extern void soundbus_unregister_soundbus(struct sound_bus *soundbus);
+extern int soundbus_add_one(struct soundbus_dev *dev);
+extern void soundbus_remove_one(struct soundbus_dev *dev);
extern struct soundbus_dev *soundbus_dev_get(struct soundbus_dev *dev);
extern void soundbus_dev_put(struct soundbus_dev *dev);
^ permalink raw reply
* RE: question about Linux 2.6 with Xilinx ML-403
From: Chang Sun @ 2006-04-23 19:00 UTC (permalink / raw)
To: Grant Likely, Martin, Tim; +Cc: linuxppc-embedded
Grant,=20
I checked both Torvalds' tree and Paul's tree. I see the defconfig file
for both ml300 and ml403, but I don't see any source files related to
either ml300 or ml403 under the <platforms> subdirectory. Have you done
a complete BSP for either ml300 or ml403?
Thanks,=20
Chang
-----Original Message-----
From: linuxppc-embedded-bounces+chang.sun=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+chang.sun=3Dxilinx.com@ozlabs.org] On
Behalf Of Grant Likely
Sent: Wednesday, April 12, 2006 11:45 AM
To: Martin, Tim
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: question about Linux 2.6 with Xilinx ML-403
On 4/12/06, Martin, Tim <tim.martin@viasat.com> wrote:
> Grant,
>
> I know I could probably figure this out by looking at the GIT tree
> directly (which I'm planning to do) but could you summarize how much
> (which devices) of the ML-403 is supported by your patches?
>
> Serial? (which Xilinx core)
Yes, full uart
>
> Ethernet? (Hard-Core PLB TEMAC?, Soft-Core PLB EMAC? Localink TEMAC?
Is
> 10/100/1000 supported, or is there only 1 rate e.g. 1000 supported?)
No. I've ported the 2.4 driver, but I haven't got permission to
release it yet. (I'm a contractor; I don't own any of the work I do)
>
> Anything else (GPIO buttons/switches?)
I've got drivers for the PS/2 & VGA, but I'm still trying to get them
released.
Cheers,
g.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] snd_pmac_toonie_init should to be __init
From: Andreas Schwab @ 2006-04-23 18:32 UTC (permalink / raw)
To: linuxppc-dev
snd_pmac_toonie_init is only called by __init code and calls __init code
itself.
Signed-off-by: Andreas Schwab <schwab@suse.de>
---
sound/ppc/toonie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.17-rc2/sound/ppc/toonie.c
===================================================================
--- linux-2.6.17-rc2.orig/sound/ppc/toonie.c 2006-04-19 21:46:39.000000000 +0200
+++ linux-2.6.17-rc2/sound/ppc/toonie.c 2006-04-19 22:56:30.000000000 +0200
@@ -335,7 +335,7 @@ static void toonie_cleanup(struct snd_pm
chip->mixer_data = NULL;
}
-int snd_pmac_toonie_init(struct snd_pmac *chip)
+int __init snd_pmac_toonie_init(struct snd_pmac *chip)
{
struct pmac_toonie *mix;
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* please pull powerpc-merge.git
From: Paul Mackerras @ 2006-04-23 1:15 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
to get the following powerpc bug-fixes, and a defconfig update.
Thanks,
Paul.
Arnd Bergmann:
powerpc/cell: remove BUILD_BUG_ON and add sys_tee to spu_syscall_table
Becky Bruce:
ppc: Fix powersave code on arch/ppc
Benjamin Herrenschmidt:
powermac: Fix i2c on keywest based chips
powerpc: fix oops in alsa powermac driver
Kumar Gala:
powerpc/ppc: export strncasecmp
Olof Johansson:
powerpc: IOMMU support for honoring dma_mask
powerpc: Lower threshold for DART enablement to 1GB
Paul Mackerras:
powerpc: Fix define_machine so machine_is() works from modules
Will Schmidt:
powerpc: update {g5,iseries,pseries}_defconfigs
arch/powerpc/configs/g5_defconfig | 58 ++++++++++----------
arch/powerpc/configs/iseries_defconfig | 43 +++++++++------
arch/powerpc/configs/pseries_defconfig | 54 +++++++++----------
arch/powerpc/kernel/iommu.c | 38 +++++++++----
arch/powerpc/kernel/pci_iommu.c | 42 +++++++++++++--
arch/powerpc/kernel/ppc_ksyms.c | 1
arch/powerpc/kernel/prom.c | 2 -
arch/powerpc/kernel/systbl.S | 5 ++
arch/powerpc/kernel/vio.c | 6 +-
arch/powerpc/platforms/cell/spu_callbacks.c | 5 +-
arch/powerpc/platforms/powermac/low_i2c.c | 78 ++++++++++++---------------
arch/powerpc/sysdev/dart_iommu.c | 12 +++-
arch/ppc/kernel/asm-offsets.c | 1
arch/ppc/kernel/entry.S | 35 ++++++------
arch/ppc/kernel/ppc_ksyms.c | 1
drivers/macintosh/therm_adt746x.c | 4 +
include/asm-powerpc/iommu.h | 7 +-
include/asm-powerpc/machdep.h | 6 ++
sound/oss/dmasound/tas_common.c | 4 +
sound/ppc/daca.c | 2 -
sound/ppc/tumbler.c | 2 -
21 files changed, 234 insertions(+), 172 deletions(-)
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Tolunay Orkun @ 2006-04-22 19:53 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200604212332.55123.antonio.dibacco@aruba.it>
Antonio Di Bacco wrote:
> Little bit off topic:
> I decided to adopt a different strategy, the sw download web page will contain
> a java applet that will act as a tftp server, then the board will be rebooted
> and an environment variable will instruct the u-boot to tftp the new software
> from the applet. What do you think? I know that applets cannot read local
> files on the PC, unless they have a valid certificate but the user should
> trust me.
>
> Bye,
> Antonio.
>
If this approach hits a roadblock for some reason (user resistance,
firewall issues with tftp etc.), think about the following...
During the update you can use a small ram based file system (tempfs)
holding everything you need, kill all unneeded processes, fill your ram
based file system. Once this ram file system is filled you will
pivot_root to it making it new root fs and proceed to update from it.
Once update is down you can reboot.
I have not done this so it is very likely there are some details that I
cannot foresee at this very moment.
Best regards,
Tolunay
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)I
From: Antonio Di Bacco @ 2006-04-22 19:21 UTC (permalink / raw)
To: Stefan Eletzhofer; +Cc: linuxppc-embedded
In-Reply-To: <27FB8E28-233C-42CF-9C2A-696C70BF45C1@inquant.de>
I'm going to develop it if I don't find elsewhere.
Bye.
On Saturday 22 April 2006 13:40, Stefan Eletzhofer wrote:
> Hi,
>
> Am 21.04.2006 um 23:32 schrieb Antonio Di Bacco:
> > Little bit off topic:
> > I decided to adopt a different strategy, the sw download web page
> > will contain
> > a java applet that will act as a tftp server, then the board will
> > be rebooted
> > and an environment variable will instruct the u-boot to tftp the
> > new software
> > from the applet. What do you think? I know that applets cannot read
> > local
> > files on the PC, unless they have a valid certificate but the user
> > should
> > trust me.
>
> nice idea IMHO. Is that applet available somewhere? That would surely
> fit my needs
> (and others probably, too).
>
> Cheers,
> Stefan.
>
> > Bye,
> > Antonio.
> >
> > On Friday 21 April 2006 22:23, Wolfgang Denk wrote:
> >> In message <200604210853.32860.david.jander@protonic.nl> you wrote:
> >>> What do you mean with "something bad could happen"?
> >>
> >> System crashes.
> >>
> >>> The only thing I can think of is pulling the power plug while
> >>> flash is
> >>> being erased or written. What else could go wrong?
> >>
> >> The kernel may try to (re-) load some pages of a running executable
> >> or library which is no longer available (at least not at the
> >> addresses where they used to be). The kernel will either stumble over
> >> what it believes to be a corrupted file system, or load the wrong
> >> data -> kaboom.
> >>
> >>> We do the following: system running from read-only jffs2 partition.
> >>> Sometimes that partition is remounted read-write and single files
> >>> are
> >>> replaced, but in some occasions we need to upgrade the whole fs.
> >>> In that
> >>> case a CGI lodas the image into a ramdisk, and the upgrade
> >>> process is
> >>> started. For upgrade,
> >>
> >> You *have* to unmount the old file system here.
> >>
> >>> partition, and then "dd" again to copy the image. At that point no
> >>> critical flash-read access should be requested since dd is
> >>> already in
> >>> cache (it's
> >>
> >> The kernel might reload any page of any running executable or
> >> library.
> >>
> >> Best regards,
> >>
> >> Wolfgang Denk
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Tolunay Orkun @ 2006-04-22 19:07 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: White, linuxppc-embedded
In-Reply-To: <20060421165732.CD0EB3526B7@atlas.denx.de>
Wolfgang Denk wrote:
> In message <20060421055142.11025.qmail@mx1.aruba.it> you wrote:
>
>> No, I have a cramfs on flash and the kernel uses it directly from flash,
>> extracting what it needs to execute. I'm not using initrd then, I have to
>> update in situ, while running.
>>
>
> This cannot be done reliably. You have to make the file system idle,
> i. e. unmount it.
>
I agree, even if you make the executables involved in the update
statically linked (so library dependencies are removed), kernel can
choose to reload any running executables page and it would end up with a
bogus page in memory. This is particularly true if you do not have swap
which you could try to lock executable in swap. Also, you cannot
reliably depend on file system cache to contain all the executable code
you would need to complete update either.
Regards,
Tolunay
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Tolunay Orkun @ 2006-04-22 18:50 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: White, linuxppc-embedded
In-Reply-To: <20060421165548.A03E53526B7@atlas.denx.de>
Wolfgang Denk wrote:
> In message <44485B3F.8080308@orkun.us> you wrote:
>
>> If your bootloader is U-Boot and you are using standard bootm command to
>> boot, U-Boot decompresses the initrd image to RAM before passing the
>> file system to Linux. So, you are not working with flash copy and
>> updating the flash copy is not a problem at all. This applies to ext2,
>> cramfs or squashfs based initrd.
>>
>
> But it makes no sense to use cramfs or squashfs on a ramdisk.
> You *want* to run these directly from flash.
> But then, of course, you need alternate images (or other tricks)
> for full image updates.
>
Well, we lose a couple of MB of RAM but squashfs as initrd has been
reliable, very compact and since the file system is in RAM, it is faster
and we can tune a bit for smaller cache etc.
Image updates have been extremely easy as a result, we did not need to
resort to alternate images and other tricks as a result. If you have
more flexibility in RAM than in flash, our approach makes sense without
complicating the matter much. I understand that not everyone might have
this option.
> [Single file updates can be done using overlay file systems; see the
> DULG for details.]
I know about the overlay fs. There is also unionfs that works similarly.
Best regards,
Tolunay
^ permalink raw reply
* Re: Fedora 5 on POWER5
From: David Woodhouse @ 2006-04-22 12:57 UTC (permalink / raw)
To: Josef Mádl; +Cc: linuxppc-dev
In-Reply-To: <001201c6650b$e507b110$0c01a8c0@KTSJMXP>
On Fri, 2006-04-21 at 08:21 +0200, Josef Mádl wrote:
> I am trying to install fedora 5 on IBM i5 system. Instalation start,
> all seems to good to partitioning disk.
> Fedora see two disks /dev/sda (real disk - virtual disk prepared with
> CRTNWSSTG) and /dev/sdb (booting disk of instalation - Prep).
> I choise /dev/sda for creating linux partitions, fedora show me how it
> will be parted but try to write to /dev/sdb - it ends with error.
>
> Do anybody know how solved this problem ?
I'm fairly sure I saw Paul helping someone work around this on Freenode
#fedora-ppc a couple of weeks ago.
--
dwmw2
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Stefan Eletzhofer @ 2006-04-22 11:40 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200604212332.55123.antonio.dibacco@aruba.it>
Hi,
Am 21.04.2006 um 23:32 schrieb Antonio Di Bacco:
> Little bit off topic:
> I decided to adopt a different strategy, the sw download web page
> will contain
> a java applet that will act as a tftp server, then the board will
> be rebooted
> and an environment variable will instruct the u-boot to tftp the
> new software
> from the applet. What do you think? I know that applets cannot read
> local
> files on the PC, unless they have a valid certificate but the user
> should
> trust me.
nice idea IMHO. Is that applet available somewhere? That would surely
fit my needs
(and others probably, too).
Cheers,
Stefan.
>
> Bye,
> Antonio.
>
> On Friday 21 April 2006 22:23, Wolfgang Denk wrote:
>> In message <200604210853.32860.david.jander@protonic.nl> you wrote:
>>> What do you mean with "something bad could happen"?
>>
>> System crashes.
>>
>>> The only thing I can think of is pulling the power plug while
>>> flash is
>>> being erased or written. What else could go wrong?
>>
>> The kernel may try to (re-) load some pages of a running executable
>> or library which is no longer available (at least not at the
>> addresses where they used to be). The kernel will either stumble over
>> what it believes to be a corrupted file system, or load the wrong
>> data -> kaboom.
>>
>>> We do the following: system running from read-only jffs2 partition.
>>> Sometimes that partition is remounted read-write and single files
>>> are
>>> replaced, but in some occasions we need to upgrade the whole fs.
>>> In that
>>> case a CGI lodas the image into a ramdisk, and the upgrade
>>> process is
>>> started. For upgrade,
>>
>> You *have* to unmount the old file system here.
>>
>>> partition, and then "dd" again to copy the image. At that point no
>>> critical flash-read access should be requested since dd is
>>> already in
>>> cache (it's
>>
>> The kernel might reload any page of any running executable or
>> library.
>>
>> Best regards,
>>
>> Wolfgang Denk
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: [PATCH] kdump-ppc64-xmon-stop-cpu
From: Paul Mackerras @ 2006-04-22 8:43 UTC (permalink / raw)
To: David Wilder; +Cc: akpm, linuxppc-dev, mchintage, fastboot
In-Reply-To: <443ADCF5.60702@us.ibm.com>
David Wilder writes:
> - During CPU(s) hang scenarios, kdump could not stop these CPUs.
> However, the user could invoke soft-reset to shoot down CPUs reliably.
> But, when the debugger is enabled, these CPUs are returned to hang state
> after they exited from the debugger. This patch fixes this issue by
> calling crash_kexec_secondary() before returns to previous state.
All three of your patches need a good 1-line description in the
subject and better description - one which is comprehensible to
someone who doesn't know all the internals of kdump, and with correct
English grammar. I had to read this one about 4 times before I got
much of an idea what it was supposed to be about. Please resubmit all
three patches in your series.
Paul.
^ permalink raw reply
* Re: [PATCH 2/2]: Spider ethernet driver -- protect chain head
From: Linas Vepstas @ 2006-04-22 1:03 UTC (permalink / raw)
To: utz.bacher, Arnd Bergmann, Maxim Shchetynin, linuxppc-dev,
linux-kernel
In-Reply-To: <20060422001140.GA12826@gate.ebshome.net>
On Fri, Apr 21, 2006 at 05:11:40PM -0700, Eugene Surovegin wrote:
> On Fri, Apr 21, 2006 at 06:45:51PM -0500, Linas Vepstas wrote:
> > Prevent a potential race. If two threads are both calling
> > the transmit routine, both can potentially try to grab the
> > same dma descriptor. Serialize access to the head of the
> > tx ring with spinlocks.
>
> Two threads cannot be in spider_net_xmit() simultaneosuly because
> hard_start_xmit entry point is already protected by net_device
> xmit_lock, see Documentation/net/netdevices.txt
Ahh, thank you. I was wondering why I never semmed to see this
this happen in "real life".
--linas
^ permalink raw reply
* Re: [PATCH 2/2]: Spider ethernet driver -- protect chain head
From: Eugene Surovegin @ 2006-04-22 0:11 UTC (permalink / raw)
To: Linas Vepstas; +Cc: Maxim Shchetynin, Arnd Bergmann, linux-kernel, linuxppc-dev
In-Reply-To: <20060421234551.GI7242@austin.ibm.com>
On Fri, Apr 21, 2006 at 06:45:51PM -0500, Linas Vepstas wrote:
> Prevent a potential race. If two threads are both calling
> the transmit routine, both can potentially try to grab the
> same dma descriptor. Serialize access to the head of the
> tx ring with spinlocks.
Two threads cannot be in spider_net_xmit() simultaneosuly because
hard_start_xmit entry point is already protected by net_device
xmit_lock, see Documentation/net/netdevices.txt
--
Eugene
^ permalink raw reply
* [PATCH 2/2]: Spider ethernet driver -- protect chain head
From: Linas Vepstas @ 2006-04-21 23:45 UTC (permalink / raw)
To: utz.bacher, Arnd Bergmann; +Cc: Maxim Shchetynin, linuxppc-dev, linux-kernel
In-Reply-To: <20060421232942.GG7242@austin.ibm.com>
Please review/apply/ack/forward upstream.
--linas
Prevent a potential race. If two threads are both calling
the transmit routine, both can potentially try to grab the
same dma descriptor. Serialize access to the head of the
tx ring with spinlocks.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/net/spider_net.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
Index: linux-2.6.17-rc1/drivers/net/spider_net.c
===================================================================
--- linux-2.6.17-rc1.orig/drivers/net/spider_net.c 2006-04-21 18:32:46.000000000 -0500
+++ linux-2.6.17-rc1/drivers/net/spider_net.c 2006-04-21 18:39:12.000000000 -0500
@@ -806,13 +806,19 @@ spider_net_stop(struct net_device *netde
static struct spider_net_descr *
spider_net_get_next_tx_descr(struct spider_net_card *card)
{
+ struct spider_net_descr *descr;
+ spin_lock(&card->tx_chain_lock);
+
+ descr = card->tx_chain.head;
/* check, if head points to not-in-use descr */
if ( spider_net_get_descr_status(card->tx_chain.head) ==
SPIDER_NET_DESCR_NOT_IN_USE ) {
- return card->tx_chain.head;
+ card->tx_chain.head = descr->next;
} else {
- return NULL;
+ descr = NULL;
}
+ spin_unlock(&card->tx_chain_lock);
+ return descr;
}
/**
@@ -932,8 +938,6 @@ spider_net_xmit(struct sk_buff *skb, str
if (result)
goto error;
- card->tx_chain.head = card->tx_chain.head->next;
-
if (spider_net_get_descr_status(descr->prev) !=
SPIDER_NET_DESCR_CARDOWNED) {
/* make sure the current descriptor is in memory. Then
^ permalink raw reply
* [PATCH 1/2]: Spider ethernet driver spinlocks
From: Linas Vepstas @ 2006-04-21 23:29 UTC (permalink / raw)
To: utz.bacher, Arnd Bergmann; +Cc: Maxim Shchetynin, linux-kernel, linuxppc-dev
Please review/apply/ack/forward upstream.
--linas
The spider network driver currently uses hand-rolled spinlocks
in a few places. Replace these with industry standard spinlocks.
In particular, this should add some safety if multiple threads
are touching the tx and rx chain pointers.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/net/spider_net.c | 18 ++++++++----------
drivers/net/spider_net.h | 4 ++--
2 files changed, 10 insertions(+), 12 deletions(-)
Index: linux-2.6.17-rc1/drivers/net/spider_net.c
===================================================================
--- linux-2.6.17-rc1.orig/drivers/net/spider_net.c 2006-04-20 17:22:04.000000000 -0500
+++ linux-2.6.17-rc1/drivers/net/spider_net.c 2006-04-21 11:52:39.000000000 -0500
@@ -335,8 +335,6 @@ spider_net_init_chain(struct spider_net_
struct spider_net_descr *descr;
dma_addr_t buf;
- atomic_set(&card->rx_chain_refill,0);
-
descr = start_descr;
memset(descr, 0, sizeof(*descr) * no);
@@ -509,15 +507,15 @@ spider_net_refill_rx_chain(struct spider
* and omitting it) is ok. If called by NAPI, we'll be called again
* as spider_net_decode_one_descr is called several times. If some
* interrupt calls us, the NAPI is about to clean up anyway. */
- if (atomic_inc_return(&card->rx_chain_refill) == 1)
+ if (spin_trylock(&card->rx_chain_lock)) {
while (spider_net_get_descr_status(chain->head) ==
SPIDER_NET_DESCR_NOT_IN_USE) {
if (spider_net_prepare_rx_descr(card, chain->head))
break;
chain->head = chain->head->next;
}
-
- atomic_dec(&card->rx_chain_refill);
+ spin_unlock(&card->rx_chain_lock);
+ }
}
/**
@@ -596,10 +594,8 @@ spider_net_release_tx_chain(struct spide
struct spider_net_descr_chain *tx_chain = &card->tx_chain;
enum spider_net_descr_status status;
- if (atomic_inc_return(&card->tx_chain_release) != 1) {
- atomic_dec(&card->tx_chain_release);
+ if (!spin_trylock(&card->tx_chain_lock))
return 1;
- }
for (;;) {
status = spider_net_get_descr_status(tx_chain->tail);
@@ -633,7 +629,7 @@ spider_net_release_tx_chain(struct spide
tx_chain->tail = tx_chain->tail->next;
}
out:
- atomic_dec(&card->tx_chain_release);
+ spin_unlock(&card->tx_chain_lock);
netif_wake_queue(card->netdev);
@@ -2072,7 +2068,9 @@ spider_net_setup_netdev(struct spider_ne
pci_set_drvdata(card->pdev, netdev);
- atomic_set(&card->tx_chain_release,0);
+ spin_lock_init(&card->rx_chain_lock);
+ spin_lock_init(&card->tx_chain_lock);
+
card->rxram_full_tl.data = (unsigned long) card;
card->rxram_full_tl.func =
(void (*)(unsigned long)) spider_net_handle_rxram_full;
Index: linux-2.6.17-rc1/drivers/net/spider_net.h
===================================================================
--- linux-2.6.17-rc1.orig/drivers/net/spider_net.h 2006-04-20 17:22:04.000000000 -0500
+++ linux-2.6.17-rc1/drivers/net/spider_net.h 2006-04-21 11:47:17.000000000 -0500
@@ -451,8 +451,8 @@ struct spider_net_card {
struct spider_net_descr_chain tx_chain;
struct spider_net_descr_chain rx_chain;
- atomic_t rx_chain_refill;
- atomic_t tx_chain_release;
+ spinlock_t rx_chain_lock;
+ spinlock_t tx_chain_lock;
struct net_device_stats netdev_stats;
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Benjamin Herrenschmidt @ 2006-04-21 21:51 UTC (permalink / raw)
To: Brent Cook; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <200604210933.10888.bcook@bpointsys.com>
> not claiming to understand all of the issues here, but I have some
> MV64460 / MPC7448-based systems, and they only boot if
> CONFIG_NOT_COHERENT_CACHE=y
That is strange... Pegasos uses a Marvell bridge and it works with
coherent cache. Do you have some kernel patches in addition to what is
in mainstream to make CONFIG_NOT_COHERENT_CACHE work at all on
CONFIG_6xx ? At the moment, it doesn't do much ...
Ben.
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Antonio Di Bacco @ 2006-04-21 21:32 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: David Jander
In-Reply-To: <20060421202308.D508F3526B7@atlas.denx.de>
Little bit off topic:
I decided to adopt a different strategy, the sw download web page will contain
a java applet that will act as a tftp server, then the board will be rebooted
and an environment variable will instruct the u-boot to tftp the new software
from the applet. What do you think? I know that applets cannot read local
files on the PC, unless they have a valid certificate but the user should
trust me.
Bye,
Antonio.
On Friday 21 April 2006 22:23, Wolfgang Denk wrote:
> In message <200604210853.32860.david.jander@protonic.nl> you wrote:
> > What do you mean with "something bad could happen"?
>
> System crashes.
>
> > The only thing I can think of is pulling the power plug while flash is
> > being erased or written. What else could go wrong?
>
> The kernel may try to (re-) load some pages of a running executable
> or library which is no longer available (at least not at the
> addresses where they used to be). The kernel will either stumble over
> what it believes to be a corrupted file system, or load the wrong
> data -> kaboom.
>
> > We do the following: system running from read-only jffs2 partition.
> > Sometimes that partition is remounted read-write and single files are
> > replaced, but in some occasions we need to upgrade the whole fs. In that
> > case a CGI lodas the image into a ramdisk, and the upgrade process is
> > started. For upgrade,
>
> You *have* to unmount the old file system here.
>
> > partition, and then "dd" again to copy the image. At that point no
> > critical flash-read access should be requested since dd is already in
> > cache (it's
>
> The kernel might reload any page of any running executable or library.
>
> Best regards,
>
> Wolfgang Denk
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Wolfgang Denk @ 2006-04-21 20:23 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200604210853.32860.david.jander@protonic.nl>
In message <200604210853.32860.david.jander@protonic.nl> you wrote:
>
> What do you mean with "something bad could happen"?
System crashes.
> The only thing I can think of is pulling the power plug while flash is being
> erased or written. What else could go wrong?
The kernel may try to (re-) load some pages of a running executable
or library which is no longer available (at least not at the
addresses where they used to be). The kernel will either stumble over
what it believes to be a corrupted file system, or load the wrong
data -> kaboom.
> We do the following: system running from read-only jffs2 partition. Sometimes
> that partition is remounted read-write and single files are replaced, but in
> some occasions we need to upgrade the whole fs. In that case a CGI lodas the
> image into a ramdisk, and the upgrade process is started. For upgrade,
You *have* to unmount the old file system here.
> partition, and then "dd" again to copy the image. At that point no critical
> flash-read access should be requested since dd is already in cache (it's
The kernel might reload any page of any running executable or library.
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
"Logic and practical information do not seem to apply here."
"You admit that?"
"To deny the facts would be illogical, Doctor"
-- Spock and McCoy, "A Piece of the Action", stardate unknown
^ permalink raw reply
* Re: [patch] powerpc: move PAGE_SIZE outside #ifdef __KERNEL__
From: Christoph Hellwig @ 2006-04-21 17:03 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4447C3BA.6050709@am.sony.com>
On Thu, Apr 20, 2006 at 10:24:10AM -0700, Geoff Levand wrote:
> The procps package needs PAGE_SIZE, defined in asm-powerpc/page.h,
> but it is defined inside "#ifdef __KERNEL__".
>
> This moves the PAGE_SIZE definition outside of "#ifdef __KERNEL__".
NACK.
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Wolfgang Denk @ 2006-04-21 16:57 UTC (permalink / raw)
To: antonio.dibacco; +Cc: White, linuxppc-embedded
In-Reply-To: <20060421055142.11025.qmail@mx1.aruba.it>
In message <20060421055142.11025.qmail@mx1.aruba.it> you wrote:
> No, I have a cramfs on flash and the kernel uses it directly from flash,
> extracting what it needs to execute. I'm not using initrd then, I have to
> update in situ, while running.
This cannot be done reliably. You have to make the file system idle,
i. e. unmount it.
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
Change is the essential process of all existence.
-- Spock, "Let That Be Your Last Battlefield",
stardate 5730.2
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Wolfgang Denk @ 2006-04-21 16:55 UTC (permalink / raw)
To: Tolunay Orkun; +Cc: White, linuxppc-embedded
In-Reply-To: <44485B3F.8080308@orkun.us>
In message <44485B3F.8080308@orkun.us> you wrote:
>
> If your bootloader is U-Boot and you are using standard bootm command to
> boot, U-Boot decompresses the initrd image to RAM before passing the
> file system to Linux. So, you are not working with flash copy and
> updating the flash copy is not a problem at all. This applies to ext2,
> cramfs or squashfs based initrd.
But it makes no sense to use cramfs or squashfs on a ramdisk.
You *want* to run these directly from flash.
But then, of course, you need alternate images (or other tricks)
for full image updates.
[Single file updates can be done using overlay file systems; see the
DULG for details.]
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
Just about every computer on the market today runs Unix, except the
Mac (and nobody cares about it). - Bill Joy 6/21/85
^ permalink raw reply
* Choices of 2.4 Kernel for PPC
From: Stephen Williams @ 2006-04-21 16:32 UTC (permalink / raw)
To: linuxppc-embedded
I'd been using the BK tree (I know, old old) but it's been stable
for me for a while. But I'm starting to see so problems and I want
to work with a recent kernel tree. I'm using a PPC405GPr processor.
I downloaded the linux-2.4.32 tree from kernel.org, but it has
none of the Xilinx stuff so I immediately wonder about other things
it lacks for embedded PPC.
I downloaded the linux 2.4 .git tree from Denx, but the makefile
in top says it's based on 2.4.25, which is even older then what
I've got now.
I've looked on the penguinppc.org page, but it points me back
to the kernel.org distribution and possibly the bk repository.
Hmm...
So what tree is most universally accepted as current so far as
embedded PPC goes? And can the penguinppc.org pages be updated
to reflect the consensus?
--
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: [PATCH] powerpc/pseries: avoid crash in PCI code if mem system not up.
From: Linas Vepstas @ 2006-04-21 16:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, johnrose, linux-kernel
In-Reply-To: <17480.51661.41707.53706@cargo.ozlabs.ibm.com>
On Fri, Apr 21, 2006 at 10:02:21PM +1000, Paul Mackerras wrote:
> Linas Vepstas writes:
>
> > Please apply and forward upstream. And a question: once
> > upon a time, the arch PCI subsystem was inited after mem init
> > was done; currently, it seems to be happening before mem init.
> > Is this intentional?
>
> No, and it is bogus if it is. Do you have the full backtrace from the
> crash?
Yes, below.
The relevant bits are this:
start_kernel() {
setup_arch() {
pSeries_setup_arch () {
eeh_init () {
... if err kmalloc()
crash.
}
}
}
mem_init()
// are there other appropriate arch init points
// ater mem_init() where we can do arch-dependent
// i/o bridge initialization ??
}
I also remember there being some nastiness re kmalloc
when initializing dlpar/hot-plug PCI slots before
mem_init was done. Basically, if the hotplug slots
are present at boot time, we can't use kmalloc/kfree
to manage them.
If the arch dependent I/O bridges/subsystem init could
be moved later, maybe this could be fixed as well.
--linas
Linux zImage starting: loaded at 0x00010000-0x00849cbc
(0x0/0x0/0x00c39a48; sp: 0x0181ffd0)
uncompressing ELF header done. (0x00000100 bytes)
Allocated 0x009f9020 bytes for kernel @ 0x02000000
Allocated 0x005f389c bytes for initrd @ 0x029fa000
uncompressing kernel done. (0x0063d538 bytes)
entering kernel at 0x02010000(29fa000/5f389c/00c39a48)
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line:
memory layout at init:
memory_limit : 0000000000000000 (16 MB aligned)
alloc_bottom : 0000000002fee000
alloc_top : 0000000010000000
alloc_top_hi : 00000003b0000000
rmo_top : 0000000010000000
ram_top : 00000003b0000000
Looking for displays
instantiating rtas at 0x000000000f702000 ...RTAS Code version:
bPF060322
rtas_ram_size = 5a1000
fixed_base_addr = f702000
code_base_addr = f99f000
done
0000000000000000 : boot cpu 0000000000000000
0000000000000002 : starting cpu hw idx 0000000000000002... done
0000000000000004 : starting cpu hw idx 0000000000000004... done
0000000000000006 : starting cpu hw idx 0000000000000006... done
0000000000000008 : starting cpu hw idx 0000000000000008... done
000000000000000a : starting cpu hw idx 000000000000000a... done
000000000000000c : starting cpu hw idx 000000000000000c... done
000000000000000e : starting cpu hw idx 000000000000000e... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000002fef000 -> 0x0000000002ff0428
Device tree struct 0x0000000002ff1000 -> 0x000000000300a000
Calling quiesce ...
returning from prom_init
Page orders: linear mapping = 24, others = 12
Found initrd at 0xc0000000029fa000:0xc000000002fed89c
cpu 0x0: Vector: 300 (Data Access) at [c0000000004434d0]
pc: c0000000000c06b4: .kmem_cache_alloc+0x8c/0xf4
lr: c00000000004ad6c: .eeh_send_failure_event+0x48/0xfc
sp: c000000000443750
msr: 8000000000001032
dar: 0
dsisr: 40000000
current = 0xc00000000048e660
paca = 0xc00000000048ee80
pid = 0, comm = swapper
enter ? for help
[c0000000004437e0] c00000000004ad6c .eeh_send_failure_event+0x48/0xfc
[c000000000443880] c000000000049dfc .eeh_dn_check_failure+0x250/0x2a8
[c000000000443930] c00000000001da6c .rtas_read_config+0x100/0x13c
[c0000000004439d0] c0000000000497a8 .early_enable_eeh+0x25c/0x2ac
[c000000000443a90] c00000000002ba4c .traverse_pci_devices+0x84/0x100
[c000000000443b30] c00000000041ae7c .eeh_init+0x1a8/0x204
[c000000000443bd0] c00000000041a308 .pSeries_setup_arch+0x1e8/0x2b8
[c000000000443e60] c00000000040a6a0 .setup_arch+0x20c/0x25c
[c000000000443ef0] c00000000040252c .start_kernel+0x40/0x288
[c000000000443f90] c000000000008594 .start_here_common+0x88/0x8c
^ 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