* [PATCH] iSeries: Don't leak if allocations fail in mf_getSrcHistory
From: Jesper Juhl @ 2010-10-30 17:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, linux-kernel
Hi,
If memory is tight and a dynamic allocation fails there's no reason to
make a bad situation worse by leaking memory.
mf_getSrcHistory potentially leaks pages[0-3]. I believe the right thing
to do is to free that memory again before returning -ENOMEM - which is
what this patch does.
I realize that the function is under '#if 0' so this probably doesn't
matter much, but I assume that the function is still there for a reason
(but I could be wrong, I don't know the powerpc code).
Anyway, I suggest we remove the leak.
Please keep me on CC when replying.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
mf.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/iseries/mf.c b/arch/powerpc/platforms/iseries/mf.c
index 42d0a88..f67522a 100644
--- a/arch/powerpc/platforms/iseries/mf.c
+++ b/arch/powerpc/platforms/iseries/mf.c
@@ -1058,8 +1058,13 @@ static void mf_getSrcHistory(char *buffer, int size)
pages[2] = kmalloc(4096, GFP_ATOMIC);
pages[3] = kmalloc(4096, GFP_ATOMIC);
if ((ev == NULL) || (pages[0] == NULL) || (pages[1] == NULL)
- || (pages[2] == NULL) || (pages[3] == NULL))
+ || (pages[2] == NULL) || (pages[3] == NULL)) {
+ kfree(pages[3]);
+ kfree(pages[2]);
+ kfree(pages[1]);
+ kfree(pages[0]);
return -ENOMEM;
+ }
return_stuff.xType = 0;
return_stuff.xRc = 0;
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please http://www.expita.com/nomime.html
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply related
* [PATCH] PowerPC/Cell: use vzalloc rather than vmalloc and memset in spu_alloc_lscsa_std
From: Jesper Juhl @ 2010-10-30 18:10 UTC (permalink / raw)
To: linux-kernel; +Cc: cbe-oss-dev, Paul Mackerras, linuxppc-dev, Arnd Bergmann
Hi,
We can get rid of a memset in
arch/powerpc/platforms/cell/spufs/lscsa_alloc.c::spu_alloc_lscsa_std() by
using vzalloc() rather than vmalloc()+memset().
Completely untested patch below since I have no hardware nor tools to
compile this.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
lscsa_alloc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c b/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c
index a101abf..3b894f5 100644
--- a/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c
+++ b/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c
@@ -36,10 +36,9 @@ static int spu_alloc_lscsa_std(struct spu_state *csa)
struct spu_lscsa *lscsa;
unsigned char *p;
- lscsa = vmalloc(sizeof(struct spu_lscsa));
+ lscsa = vzalloc(sizeof(struct spu_lscsa));
if (!lscsa)
return -ENOMEM;
- memset(lscsa, 0, sizeof(struct spu_lscsa));
csa->lscsa = lscsa;
/* Set LS pages reserved to allow for user-space mapping. */
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please http://www.expita.com/nomime.html
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply related
* [PATCH v2] powerpc: kvm: powerpc: fix information leak to userland
From: Vasiliy Kulikov @ 2010-10-30 18:55 UTC (permalink / raw)
To: kernel-janitors
Cc: kvm, Marcelo Tosatti, Alexander Graf, kvm-ppc, linux-kernel,
Paul Mackerras, Avi Kivity, linuxppc-dev
Structure kvm_ppc_pvinfo is copied to userland with "flags" and "pad"
fields unitialized. It leads to leaking of contents of kernel stack
memory. We have to initialize them to zero.
In patch v1 Jan Kiszka suggested to fill reserved fields with zeros
instead of memset'ting the whole struct. It makes sense as these
fields are explicitly marked as padding. No more fields need zeroing.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
---
arch/powerpc/kvm/powerpc.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 2f87a16..5962336 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -604,6 +604,8 @@ static int kvm_vm_ioctl_get_pvinfo(struct kvm_ppc_pvinfo *pvinfo)
pvinfo->hcall[1] = inst_ori | (KVM_SC_MAGIC_R0 & inst_imm_mask);
pvinfo->hcall[2] = inst_sc;
pvinfo->hcall[3] = inst_nop;
+ pvinfo->flags = 0;
+ memset(&pvinfo->pad, 0, sizeof(pvinfo->pad));
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v2] powerpc: kvm: powerpc: fix information leak to userland
From: Alexander Graf @ 2010-10-30 19:16 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: kvm, Marcelo Tosatti, kernel-janitors, linux-kernel, kvm-ppc,
Paul Mackerras, Avi Kivity, linuxppc-dev
In-Reply-To: <1288464922-8812-1-git-send-email-segooon@gmail.com>
On 30.10.2010, at 11:55, Vasiliy Kulikov wrote:
> Structure kvm_ppc_pvinfo is copied to userland with "flags" and "pad"
> fields unitialized. It leads to leaking of contents of kernel stack
> memory. We have to initialize them to zero.
>=20
> In patch v1 Jan Kiszka suggested to fill reserved fields with zeros
> instead of memset'ting the whole struct. It makes sense as these
> fields are explicitly marked as padding. No more fields need zeroing.
>=20
> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
> ---
> arch/powerpc/kvm/powerpc.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 2f87a16..5962336 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -604,6 +604,8 @@ static int kvm_vm_ioctl_get_pvinfo(struct =
kvm_ppc_pvinfo *pvinfo)
> pvinfo->hcall[1] =3D inst_ori | (KVM_SC_MAGIC_R0 & =
inst_imm_mask);
> pvinfo->hcall[2] =3D inst_sc;
> pvinfo->hcall[3] =3D inst_nop;
> + pvinfo->flags =3D 0;
> + memset(&pvinfo->pad, 0, sizeof(pvinfo->pad));
This should only be memset(pvinfo->pad), no? It's an array after all =
which automatically translates to a pointer when referenced.
Alex
^ permalink raw reply
* Re: [MPC8xx] Initial MMU too low
From: Benjamin Herrenschmidt @ 2010-10-30 20:47 UTC (permalink / raw)
To: LEROY christophe; +Cc: linuxppc-dev
In-Reply-To: <4CCC06F8.3020506@c-s.fr>
On Sat, 2010-10-30 at 13:52 +0200, LEROY christophe wrote:
> Hello,
>
> When I build a kernel with DEBUG_LOCK_ALLOC set, I get a kernel which
> has __bss_stop above the C0800000 limit, and then I get a bad page
> exception during the zeroize of the __bss at startup, because the
> initial MMU only maps the first 8Mbytes.
>
> What can I do to fix that ?
Not much... maybe pin more initial TLBs ?
Ben.
^ permalink raw reply
* [PATCH 00/39] Cleanup WARN #defines
From: Joe Perches @ 2010-10-30 21:08 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-fbdev, alsa-devel, dri-devel, socketcan-core, linux-mm,
devel, linux1394-devel, devel, linux-scsi, linux-acpi, linux-pm,
linux-media, linux-arch, intel-gfx, linux-tegra, linux-omap,
linux-arm-kernel, discuss, linux-nfs, netdev, linux-usb,
linux-wireless, linux-kernel, linux-alpha, linux-fsdevel,
linuxppc-dev
WARN uses sometimes use KERN_<level> but mostly don't
have any prefix.
Change the WARN macros and the warn_slowpath function to preface
KERN_WARNING and remove all the KERN_<level> uses from WARN sites.
Neatening clean up of include/asm-generic/bug.h
Update WARN macros
Add KERN_WARNING to WARN output
Remove any KERN_<level> from WARN uses
Coalesce formats
Align WARN arguments
Add some missing newlines to WARN uses
Add some missing first test argument (1, fmt, args) to WARN uses
Joe Perches (39):
include/asm-generic/bug.h: Update WARN macros
arch/alpha: Update WARN uses
arch/arm: Update WARN uses
arch/powerpc: Update WARN uses
arch/x86: Update WARN uses
drivers/acpi: Update WARN uses
drivers/base: Update WARN uses
drivers/block: Update WARN uses
drivers/cpuidle: Update WARN uses
drivers/firewire: Update WARN uses
drivers/firmware: Update WARN uses
drivers/gpio: Update WARN uses
drivers/gpu/drm: Update WARN uses
drivers/media/video: Update WARN uses
drivers/mfd: Update WARN uses
drivers/net/can: Update WARN uses
drivers/net/usb: Update WARN uses
drivers/net/wireless/iwlwifi: Update WARN uses
drivers/regulator: Update WARN uses
drivers/scsi/fcoe: Update WARN uses
drivers/staging: Update WARN uses
drivers/usb/musb: Update WARN uses
drivers/video/omap2/dss: Update WARN uses
fs/nfsd: Update WARN uses
fs/notify/inotify: Update WARN uses
fs/sysfs: Update WARN uses
fs/proc: Update WARN uses
fs: Update WARN uses
include/linux/device.h: Update WARN uses
kernel/irq: Update WARN uses
kernel/panic.c: Update warn_slowpath to use %pV
kernel: Update WARN uses
lib: Update WARN uses
mm: Update WARN uses
net/core/dev.c: Update WARN uses
net/ipv4/tcp.c: Update WARN uses
net/mac80211: Update WARN uses
net/rfkill/input.c: Update WARN uses
sound/soc/codecs/wm_hubs.c: Update WARN uses
arch/alpha/kernel/pci-sysfs.c | 14 ++--
arch/arm/mach-davinci/clock.c | 4 +-
arch/arm/mach-davinci/da830.c | 2 +-
arch/arm/mach-davinci/da850.c | 12 ++--
arch/arm/mach-omap2/clkt_clksel.c | 12 ++--
arch/arm/mach-omap2/clock.c | 16 ++--
arch/arm/mach-omap2/devices.c | 4 +-
arch/arm/mach-omap2/omap_hwmod.c | 47 +++++++-----
arch/arm/mach-omap2/pm34xx.c | 7 +-
arch/arm/mach-omap2/serial.c | 2 +-
arch/arm/mach-omap2/timer-gp.c | 3 +-
arch/arm/mach-tegra/clock.c | 3 +-
arch/arm/mach-tegra/timer.c | 2 +-
arch/arm/mach-u300/padmux.c | 14 +---
arch/arm/plat-omap/omap-pm-noop.c | 10 ++--
arch/powerpc/kernel/hw_breakpoint.c | 4 +-
arch/x86/kernel/acpi/boot.c | 2 +-
arch/x86/kernel/apic/apic.c | 2 +-
arch/x86/kernel/apic/es7000_32.c | 2 +-
arch/x86/kernel/cpu/perf_event.c | 4 +-
arch/x86/kernel/pci-calgary_64.c | 4 +-
arch/x86/kernel/tsc_sync.c | 4 +-
arch/x86/kernel/xsave.c | 2 +-
arch/x86/mm/ioremap.c | 5 +-
arch/x86/mm/pageattr-test.c | 2 +-
arch/x86/mm/pageattr.c | 5 +-
arch/x86/platform/sfi/sfi.c | 4 +-
drivers/acpi/ec.c | 4 +-
drivers/base/class.c | 4 +-
drivers/base/core.c | 5 +-
drivers/base/memory.c | 4 +-
drivers/base/sys.c | 10 +--
drivers/block/floppy.c | 2 +-
drivers/cpuidle/driver.c | 2 +-
drivers/firewire/core-transaction.c | 6 +-
drivers/firmware/dmi_scan.c | 2 +-
drivers/gpio/gpiolib.c | 4 +-
drivers/gpio/it8761e_gpio.c | 2 +-
drivers/gpu/drm/drm_crtc_helper.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 3 +-
drivers/gpu/drm/radeon/evergreen.c | 2 +-
drivers/gpu/drm/radeon/r100.c | 4 +-
drivers/gpu/drm/radeon/r300.c | 2 +-
drivers/gpu/drm/radeon/r600.c | 4 +-
drivers/gpu/drm/radeon/radeon_fence.c | 3 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 3 +-
drivers/gpu/drm/radeon/rs400.c | 2 +-
drivers/gpu/drm/radeon/rs600.c | 4 +-
drivers/media/video/s5p-fimc/fimc-core.c | 2 +-
drivers/media/video/sr030pc30.c | 2 +-
drivers/mfd/ezx-pcap.c | 5 +-
drivers/net/can/mscan/mscan.c | 2 +-
drivers/net/usb/ipheth.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-agn-sta.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 6 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
drivers/regulator/core.c | 3 +-
drivers/scsi/fcoe/libfcoe.c | 2 +-
drivers/staging/memrar/memrar_allocator.c | 2 +-
drivers/staging/solo6x10/solo6010-v4l2-enc.c | 2 +-
drivers/usb/musb/musb_host.c | 6 +-
drivers/video/omap2/dss/core.c | 3 +-
fs/bio.c | 2 +-
fs/buffer.c | 2 +-
fs/nfsd/nfs4state.c | 3 +-
fs/notify/inotify/inotify_fsnotify.c | 4 +-
fs/proc/generic.c | 9 +--
fs/super.c | 5 +-
fs/sysfs/dir.c | 3 +-
fs/sysfs/file.c | 4 +-
fs/sysfs/group.c | 4 +-
fs/sysfs/symlink.c | 10 +--
include/asm-generic/bug.h | 101 ++++++++++++++++----------
include/linux/device.h | 2 +-
kernel/irq/chip.c | 2 +-
kernel/irq/manage.c | 2 +-
kernel/notifier.c | 2 +-
kernel/panic.c | 40 +++++------
kernel/pm_qos_params.c | 6 +-
lib/debugobjects.c | 21 +++---
lib/iomap.c | 2 +-
lib/kobject.c | 9 +--
lib/kobject_uevent.c | 4 +-
lib/list_debug.c | 24 +++----
lib/plist.c | 12 ++--
mm/percpu.c | 4 +-
mm/vmalloc.c | 5 +-
net/core/dev.c | 3 +-
net/ipv4/tcp.c | 16 ++---
net/mac80211/agg-tx.c | 5 +-
net/mac80211/iface.c | 4 +-
net/mac80211/mlme.c | 2 +-
net/mac80211/rx.c | 4 +-
net/mac80211/tx.c | 4 +-
net/mac80211/util.c | 4 +-
net/mac80211/work.c | 4 +-
net/rfkill/input.c | 5 +-
sound/soc/codecs/wm_hubs.c | 2 +-
99 files changed, 319 insertions(+), 330 deletions(-)
--
1.7.3.1.g432b3.dirty
^ permalink raw reply
* [PATCH 04/39] arch/powerpc: Update WARN uses
From: Joe Perches @ 2010-10-30 21:08 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <cover.1288471897.git.joe@perches.com>
Coalesce long formats.
Align arguments.
Add missing newlines.
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/powerpc/kernel/hw_breakpoint.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
index 5ecd040..d7343a7 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -270,8 +270,8 @@ int __kprobes hw_breakpoint_handler(struct die_args *args)
* message to let the user know about it.
*/
if (!stepped) {
- WARN(1, "Unable to handle hardware breakpoint. Breakpoint at "
- "0x%lx will be disabled.", info->address);
+ WARN(1, "Unable to handle hardware breakpoint. Breakpoint at 0x%lx will be disabled.\n",
+ info->address);
perf_event_disable(bp);
goto out;
}
--
1.7.3.1.g432b3.dirty
^ permalink raw reply related
* Re: [Cbe-oss-dev] [PATCH] PowerPC/Cell: use vzalloc rather than vmalloc and memset in spu_alloc_lscsa_std
From: Jeremy Kerr @ 2010-10-30 21:25 UTC (permalink / raw)
To: cbe-oss-dev
Cc: Arnd Bergmann, linux-kernel, Jesper Juhl, Paul Mackerras,
linuxppc-dev
In-Reply-To: <alpine.LNX.2.00.1010302004290.1572@swampdragon.chaosbits.net>
Jesper,
> We can get rid of a memset in
> arch/powerpc/platforms/cell/spufs/lscsa_alloc.c::spu_alloc_lscsa_std() by
> using vzalloc() rather than vmalloc()+memset().
Looks good to me.
Acked-By: Jeremy Kerr <jk@ozlabs.org>
Ben, could you apply this to the powerpc tree?
Cheers,
Jeremy
^ permalink raw reply
* Re: [PATCH] PowerPC/Cell: use vzalloc rather than vmalloc and memset in spu_alloc_lscsa_std
From: Arnd Bergmann @ 2010-10-30 21:41 UTC (permalink / raw)
To: Jesper Juhl; +Cc: cbe-oss-dev, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1010302004290.1572@swampdragon.chaosbits.net>
On Saturday 30 October 2010, Jesper Juhl wrote:
> We can get rid of a memset in
> arch/powerpc/platforms/cell/spufs/lscsa_alloc.c::spu_alloc_lscsa_std() by
> using vzalloc() rather than vmalloc()+memset().
>
> Completely untested patch below since I have no hardware nor tools to
> compile this.
>
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* PowerMac G4 RAM
From: kevin diggs @ 2010-10-31 3:48 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I have a G4 that has 1.25 G of ram. Under Linux I only get 768M?
Anyone know why? It is a GiGE with a dual 7455 PowerLogix cpu upgrade.
Kernel is 2.6.28.
Thanks!
kevin
^ permalink raw reply
* Re: [PATCH 1/1] powerpc: Fix initramfs size in PPC32 build
From: Geert Uytterhoeven @ 2010-10-31 10:14 UTC (permalink / raw)
To: Kerstin Jonsson, Hendrik Brueckner, Linus Torvalds
Cc: linux-arch, Michal Marek, linux-mmc, Linux Kernel Development,
Paul Mackerras, H. Peter Anvin, WANG Cong, Andrew Morton,
Michael Holzheu, linuxppc-dev
In-Reply-To: <1287742675-7614-1-git-send-email-kerstin.jonsson@ericsson.com>
On Fri, 22 Oct 2010, Kerstin Jonsson wrote:
> commit ffe8018c3424892c9590048fc36caa6c3e0c8a76 of the -mm tree
> fixes the initramfs size calculation for e.g. s390 but breaks it
> for 32bit architectures which do not define CONFIG_32BIT.
>
> This patch fix the problem for PPC32 which will elsewise end up
> with a __initramfs_size of 0.
>
> Signed-off-by: Kerstin Jonsson <kerstin.jonsson@ericsson.com>
> Cc: Paul Mackerras <paulus@samba.org>
> ---
> arch/powerpc/Kconfig | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 50cc5d9..d536fe4 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -4,6 +4,10 @@ config PPC32
> bool
> default y if !PPC64
>
> +config 32BIT
> + bool
> + default y if PPC32
> +
> config 64BIT
> bool
> default y if PPC64
> --
> 1.7.1
Thanks for the hint!
In the future, please CC linux-arch, or at least lkml, for things like this,
as it broke allmost all 32-bit arches.
Only mips, s390, and score set CONFIG_32BIT for 32-bit builds.
Would have saved me a bisection on m68k...
I came up with the alternative patch below to fix it in a single place.
---
>From d51254ca020a23050f1641d92d68113e55cc0467 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Sun, 31 Oct 2010 10:56:23 +0100
Subject: [PATCH] initramfs: Fix initramfs size for 32-bit arches
commit ffe8018c3424892c9590048fc36caa6c3e0c8a76 ("initramfs: fix initramfs size
calculation") broke 32-bit arches like (on ARAnyM):
VFS: Cannot open root device "hda1" or unknown-block(3,1)
Please append a correct "root=" boot option; here are the available partitions:
fe80 1059408 nfhd8 (driver?)
fe81 921600 nfhd8p1 00000000-0000-0000-0000-000000000nfhd8p1
fe82 137807 nfhd8p2 00000000-0000-0000-0000-000000000nfhd8p2
0200 3280 fd0 (driver?)
0201 3280 fd1 (driver?)
0300 1059408 hda driver: ide-gd
0301 921600 hda1 00000000-0000-0000-0000-000000000hda1
0302 137807 hda2 00000000-0000-0000-0000-000000000hda2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,1)
As pointed out by Kerstin Jonsson <kerstin.jonsson@ericsson.com>, this is due
to CONFIG_32BIT not being defined.
Only mips, s390, and score set CONFIG_32BIT for 32-bit builds, so fix it for
all other 32-bit arches by inverting the logic and testing for CONFIG_64BIT,
which should be defined on all 64-bit arches.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
usr/initramfs_data.S | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/usr/initramfs_data.S b/usr/initramfs_data.S
index b9efed5..792a750 100644
--- a/usr/initramfs_data.S
+++ b/usr/initramfs_data.S
@@ -30,8 +30,8 @@ __irf_end:
.section .init.ramfs.info,"a"
.globl __initramfs_size
__initramfs_size:
-#ifdef CONFIG_32BIT
- .long __irf_end - __irf_start
-#else
+#ifdef CONFIG_64BIT
.quad __irf_end - __irf_start
+#else
+ .long __irf_end - __irf_start
#endif
--
1.7.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply related
* Re: PowerMac G4 RAM
From: Benjamin Herrenschmidt @ 2010-10-31 11:28 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTi=+kF+c=RC09_4V2wqw61xFhFHnvqYHAKbA0TpQ@mail.gmail.com>
On Sat, 2010-10-30 at 22:48 -0500, kevin diggs wrote:
> Hi,
>
> I have a G4 that has 1.25 G of ram. Under Linux I only get 768M?
> Anyone know why? It is a GiGE with a dual 7455 PowerLogix cpu upgrade.
> Kernel is 2.6.28.
Tried enabling CONFIG_HIGHMEM ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2 02/22] bitops: rename generic little-endian bitops functions
From: Hans-Christian Egtvedt @ 2010-10-31 14:02 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-arch, linux-m68k, kvm, Arnd Bergmann, David S. Miller,
Marcelo Tosatti, linux-kernel, rds-devel, Christoph Hellwig,
Andy Grover, netdev, Geert Uytterhoeven, Avi Kivity, Greg Ungerer,
Andreas Schwab, Andrew Morton, linuxppc-dev,
Hans-Christian Egtvedt, Paul Mackerras
In-Reply-To: <1287672077-5797-3-git-send-email-akinobu.mita@gmail.com>
Around Thu 21 Oct 2010 23:40:57 +0900 or thereabout, Akinobu Mita wrote:
> As a preparation for providing little-endian bitops for all architectures,
> This removes generic_ prefix from little-endian bitops function names
> in asm-generic/bitops/le.h.
>
> s/generic_find_next_le_bit/find_next_le_bit/
> s/generic_find_next_zero_le_bit/find_next_zero_le_bit/
> s/generic_find_first_zero_le_bit/find_first_zero_le_bit/
> s/generic___test_and_set_le_bit/__test_and_set_le_bit/
> s/generic___test_and_clear_le_bit/__test_and_clear_le_bit/
> s/generic_test_le_bit/test_le_bit/
> s/generic___set_le_bit/__set_le_bit/
> s/generic___clear_le_bit/__clear_le_bit/
> s/generic_test_and_set_le_bit/test_and_set_le_bit/
> s/generic_test_and_clear_le_bit/test_and_clear_le_bit/
>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Cc: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Roman Zippel <zippel@linux-m68k.org>
> Cc: Andreas Schwab <schwab@linux-m68k.org>
> Cc: linux-m68k@lists.linux-m68k.org
> Cc: Greg Ungerer <gerg@uclinux.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Andy Grover <andy.grover@oracle.com>
> Cc: rds-devel@oss.oracle.com
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> Cc: Avi Kivity <avi@redhat.com>
> Cc: Marcelo Tosatti <mtosatti@redhat.com>
> Cc: kvm@vger.kernel.org
> ---
> No change from previous submission
>
> arch/avr32/kernel/avr32_ksyms.c | 4 ++--
> arch/avr32/lib/findbit.S | 4 ++--
For the AVR32 changes.
Acked-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
<snipp patch>
--
Best regards, Hans-Christian Egtvedt
^ permalink raw reply
* eabi supported
From: Oliver Kowalke @ 2010-10-31 18:54 UTC (permalink / raw)
To: linuxppc-dev
Hi,
could you tell me which Linux distribution does support powerpc with
eabi (embedded abi)?
I tried 'T2 Project' but it doesn't offer ABI selection in its config
script.
thx,
Oliver
^ permalink raw reply
* Re: [PATCH] OF device tree: Move of_get_mac_address() to a common source file.
From: Grant Likely @ 2010-11-01 5:17 UTC (permalink / raw)
To: David Daney
Cc: linux-mips, Corey Minyard, Anton Vorontsov, Paul Mackerras,
Sadanand Mutyala, Sergey Matyukevich, Sean MacLennan,
Wolfgang Denk, microblaze-uclinux, devicetree-discuss,
Andres Salomon, Michal Simek, Anatolij Gustschin, Eric Dumazet,
Jiri Pirko, netdev, linux-kernel, ralf, Sandeep Gopalpet,
Vitaly Bordug, linuxppc-dev, David S. Miller
In-Reply-To: <1288130833-16421-1-git-send-email-ddaney@caviumnetworks.com>
On Tue, Oct 26, 2010 at 03:07:13PM -0700, David Daney wrote:
> There are two identical implementations of of_get_mac_address(), one
> each in arch/powerpc/kernel/prom_parse.c and
> arch/microblaze/kernel/prom_parse.c. Move this function to a new
> common file of_net.{c,h} and adjust all the callers to include the new
> header.
Applied, thanks; but made some changes to protect this code because it
does not work on little endian (it can be fixed in a separate patch)
Also...
>
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
> Cc: Michal Simek <monstr@monstr.eu>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Corey Minyard <cminyard@mvista.com>
> Cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
> Cc: Vitaly Bordug <vbordug@ru.mvista.com>
> Cc: Anatolij Gustschin <agust@denx.de>
> Cc: John Rigby <jcrigby@gmail.com>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Anton Vorontsov <avorontsov@mvista.com>
> Cc: Sandeep Gopalpet <Sandeep.Kumar@freescale.com>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: Li Yang <leoli@freescale.com>
> Cc: Sergey Matyukevich <geomatsi@gmail.com>
> Cc: Jiri Pirko <jpirko@redhat.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Sean MacLennan <smaclennan@pikatech.com>
> Cc: Sadanand Mutyala <Sadanand.Mutyala@xilinx.com>
> Cc: Andres Salomon <dilinger@queued.net>
> Cc: microblaze-uclinux@itee.uq.edu.au
> Cc: linux-kernel@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: netdev@vger.kernel.org
> Cc: devicetree-discuss@lists.ozlabs.org
You don't need to believe everything that get_maintainers is telling
you. When you get a large list like this, don't Cc everyone, but
apply some educated guesses. You can guess that the PowerPC and
Microblaze maintainers care because it touches their trees, and you
can guess that I care because I'm the dt maintainer. David Miller
isn't a bad guess because of networking. But 22 people is excessive.
g.
^ permalink raw reply
* Re:
From: Michal Simek @ 2010-11-01 6:29 UTC (permalink / raw)
To: microblaze-uclinux; +Cc: nacc, linuxppc-dev, miltonm
In-Reply-To: <1287422825-14999-2-git-send-email-nacc@us.ibm.com>
Hi,
Nishanth Aravamudan wrote:
> Use set_dma_ops and remove now used-once oddly named temp pointer sd.
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> Cc: benh@kernel.crashing.org
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> arch/microblaze/pci/pci-common.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
Is there any reason why you are sending me this patch again and again?
Please STOP doing this!
This patch was added to the mainline last week.
Regards,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH 04/39] arch/powerpc: Update WARN uses
From: Michael Ellerman @ 2010-11-01 11:02 UTC (permalink / raw)
To: Joe Perches; +Cc: Paul Mackerras, Jiri Kosina, linuxppc-dev, linux-kernel
In-Reply-To: <c6c46b5924e1cc9720d3ad76e6c11e982bd661e5.1288471898.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
On Sat, 2010-10-30 at 14:08 -0700, Joe Perches wrote:
> Coalesce long formats.
> Align arguments.
> Add missing newlines.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> arch/powerpc/kernel/hw_breakpoint.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
> index 5ecd040..d7343a7 100644
> --- a/arch/powerpc/kernel/hw_breakpoint.c
> +++ b/arch/powerpc/kernel/hw_breakpoint.c
> @@ -270,8 +270,8 @@ int __kprobes hw_breakpoint_handler(struct die_args *args)
> * message to let the user know about it.
> */
> if (!stepped) {
> - WARN(1, "Unable to handle hardware breakpoint. Breakpoint at "
> - "0x%lx will be disabled.", info->address);
> + WARN(1, "Unable to handle hardware breakpoint. Breakpoint at 0x%lx will be disabled.\n",
> + info->address);
That appears to have done nothing other than turn a short line into one
that is now > 80 columns. Is that the latest fad?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] iSeries: Don't leak if allocations fail in mf_getSrcHistory
From: Michael Ellerman @ 2010-11-01 11:10 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel, Stephen Rothwell
In-Reply-To: <alpine.LNX.2.00.1010301911220.1572@swampdragon.chaosbits.net>
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
On Sat, 2010-10-30 at 19:20 +0200, Jesper Juhl wrote:
> Hi,
>
> If memory is tight and a dynamic allocation fails there's no reason to
> make a bad situation worse by leaking memory.
>
> mf_getSrcHistory potentially leaks pages[0-3]. I believe the right thing
> to do is to free that memory again before returning -ENOMEM - which is
> what this patch does.
>
> I realize that the function is under '#if 0' so this probably doesn't
> matter much, but I assume that the function is still there for a reason
> (but I could be wrong, I don't know the powerpc code).
> Anyway, I suggest we remove the leak.
Stephen is the iSeries maintainer, and I think he #if 0'ed the code. But
I don't think it will ever be un-ifdef'ed, so should probably just be
removed.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] OF device tree: Move of_get_mac_address() to a common source file.
From: Timur Tabi @ 2010-11-01 12:04 UTC (permalink / raw)
To: Grant Likely
Cc: linux-mips, netdev, devicetree-discuss, David Daney, linux-kernel,
microblaze-uclinux, linuxppc-dev
In-Reply-To: <20101101051734.GB17587@angua.secretlab.ca>
On Mon, Nov 1, 2010 at 12:17 AM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
>> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
>> Cc: Michal Simek <monstr@monstr.eu>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Wolfram Sang <w.sang@pengutronix.de>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Corey Minyard <cminyard@mvista.com>
>> Cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
>> Cc: Vitaly Bordug <vbordug@ru.mvista.com>
>> Cc: Anatolij Gustschin <agust@denx.de>
>> Cc: John Rigby <jcrigby@gmail.com>
>> Cc: Wolfgang Denk <wd@denx.de>
>> Cc: Anton Vorontsov <avorontsov@mvista.com>
>> Cc: Sandeep Gopalpet <Sandeep.Kumar@freescale.com>
>> Cc: Kumar Gala <galak@kernel.crashing.org>
>> Cc: Li Yang <leoli@freescale.com>
>> Cc: Sergey Matyukevich <geomatsi@gmail.com>
>> Cc: Jiri Pirko <jpirko@redhat.com>
>> Cc: Eric Dumazet <eric.dumazet@gmail.com>
>> Cc: Sean MacLennan <smaclennan@pikatech.com>
>> Cc: Sadanand Mutyala <Sadanand.Mutyala@xilinx.com>
>> Cc: Andres Salomon <dilinger@queued.net>
>> Cc: microblaze-uclinux@itee.uq.edu.au
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Cc: netdev@vger.kernel.org
>> Cc: devicetree-discuss@lists.ozlabs.org
>
> You don't need to believe everything that get_maintainers is telling
> you. =A0When you get a large list like this, don't Cc everyone, but
> apply some educated guesses. =A0You can guess that the PowerPC and
> Microblaze maintainers care because it touches their trees, and you
> can guess that I care because I'm the dt maintainer. David Miller
> isn't a bad guess because of networking. =A0But 22 people is excessive.
And ironically, he left out the person who wrote the function -- me.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: eabi supported
From: Josh Boyer @ 2010-11-01 13:17 UTC (permalink / raw)
To: Oliver Kowalke; +Cc: linuxppc-dev
In-Reply-To: <4CCDBB78.7000600@gmx.de>
On Sun, Oct 31, 2010 at 07:54:48PM +0100, Oliver Kowalke wrote:
>Hi,
>
>could you tell me which Linux distribution does support powerpc with
>eabi (embedded abi)?
>
>I tried 'T2 Project' but it doesn't offer ABI selection in its config
>script.
eabi isn't really used all that much on powerpc. I don't know of a
community distro that supports powerpc in general, much less with eabi.
You might be able to get it from one of the embedded linux vendors, but
you'd have to contact them.
josh
^ permalink raw reply
* Re: All Applied micro boards are failing with current mainline kernel
From: Josh Boyer @ 2010-11-01 13:22 UTC (permalink / raw)
To: Rupjyoti Sarmah; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <6631e123845856ac20423c25e07844c8@mail.gmail.com>
On Fri, Oct 29, 2010 at 11:06 PM, Rupjyoti Sarmah <rsarmah@apm.com> wrote:
> Hi ,
>
> APM boards Canyonlands/Kilauea/Glacier/Katmai/Sequoia are all failing
> during booting.
What kernel version? What config? Have you tried a git bisect to see
when it broke? Etc, etc.
Also, CC'ing linuxppc-dev would have been a good idea. Not many on
lkml are even going to know what you're talking about with such sparse
details.
josh
>
> Call trace is same for all
>
>
> Call Trace:
>
> [df835d70] [c02d27cc] emac_probe+0xf28/0x12a8 (unreliable)
>
> [df835e50] [c023c7cc] platform_driver_probe_shim+0x40/0x54
>
> [df835e60] [c01bf354] platform_drv_probe+0x20/0x30
>
> [df835e70] [c01bde68] driver_probe_device+0x148/0x1ac
>
> [df835e90] [c01be17c] __driver_attach+0xa4/0xa8
>
> [df835eb0] [c01bcfa4] bus_for_each_dev+0x60/0x9c
>
> [df835ee0] [c01bdbbc] driver_attach+0x24/0x34
>
> [df835ef0] [c01bd94c] bus_add_driver+0x1b8/0x274
>
> [df835f20] [c01be3d8] driver_register+0x6c/0x160
>
> [df835f40] [c01bf6c4] platform_driver_register+0x68/0x78
>
> [df835f50] [c023c998] of_register_platform_driver+0xa8/0xc4
>
> [df835f60] [c0393e88] emac_init+0x1ac/0x1dc
>
> [df835fa0] [c0001574] do_one_initcall+0x160/0x1a8
>
> [df835fd0] [c037a1e8] kernel_init+0xcc/0x174
>
> [df835ff0] [c000c5b0] kernel_thread+0x4c/0x68
>
> Instruction dump:
>
> 419e016c 2f800007 419e0164 38130774 901a00d0 381306b0 901a00d4 7f43d378
>
> 4bf91d89 817a01a0 39200001 380b0008 <7d400028> 7d4a4b78 7d40012d 40a2fff4
>
> ---[ end trace dac0cf4779f83901 ]---
>
>
> Regards,
> Rup
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
n
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at =A0http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH 04/39] arch/powerpc: Update WARN uses
From: Joe Perches @ 2010-11-01 14:41 UTC (permalink / raw)
To: michael; +Cc: Paul Mackerras, Jiri Kosina, linuxppc-dev, linux-kernel
In-Reply-To: <1288609334.10671.4.camel@concordia>
On Mon, 2010-11-01 at 22:02 +1100, Michael Ellerman wrote:
> On Sat, 2010-10-30 at 14:08 -0700, Joe Perches wrote:
> > Coalesce long formats.
> > Align arguments.
> > Add missing newlines.
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
> > ---
> > arch/powerpc/kernel/hw_breakpoint.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
> > index 5ecd040..d7343a7 100644
> > --- a/arch/powerpc/kernel/hw_breakpoint.c
> > +++ b/arch/powerpc/kernel/hw_breakpoint.c
> > @@ -270,8 +270,8 @@ int __kprobes hw_breakpoint_handler(struct die_args *args)
> > * message to let the user know about it.
> > */
> > if (!stepped) {
> > - WARN(1, "Unable to handle hardware breakpoint. Breakpoint at "
> > - "0x%lx will be disabled.", info->address);
> > + WARN(1, "Unable to handle hardware breakpoint. Breakpoint at 0x%lx will be disabled.\n",
> > + info->address);
>
> That appears to have done nothing other than turn a short line into one
> that is now > 80 columns.
Added '\n'.
The series was done for a few reasons:
o to add missing newlines at the end of messages as was done here
o to convert a couple of misuses of WARN(msg) to WARN(1, msg)
o to remove KERN_ prefixes from WARN(test, KERN_<level> msg)
> Is that the latest fad?
Pretty much. Format coalescing is generally preferred for grep.
Some consider it churn.
cheers, Joe
^ permalink raw reply
* Re: All Applied micro boards are failing with current mainline kernel
From: Josh Boyer @ 2010-11-01 15:05 UTC (permalink / raw)
To: Rupjyoti Sarmah, Tom Herbert, Eric Dumazet, David S. Miller
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <AANLkTikWWGpAM8+_z9fnngYuYSpT3NWgM7xeGkOzZ3jg@mail.gmail.com>
On Mon, Nov 1, 2010 at 9:22 AM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Fri, Oct 29, 2010 at 11:06 PM, Rupjyoti Sarmah <rsarmah@apm.com> wrote=
:
>> Hi ,
>>
>> APM boards Canyonlands/Kilauea/Glacier/Katmai/Sequoia are all failing
>> during booting.
>
> What kernel version? =A0What config? =A0Have you tried a git bisect to se=
e
> when it broke? =A0Etc, etc.
>>
>> Call trace is same for all
>>
>>
>> Call Trace:
>>
>> [df835d70] [c02d27cc] emac_probe+0xf28/0x12a8 (unreliable)
>>
>> [df835e50] [c023c7cc] platform_driver_probe_shim+0x40/0x54
>>
>> [df835e60] [c01bf354] platform_drv_probe+0x20/0x30
>>
>> [df835e70] [c01bde68] driver_probe_device+0x148/0x1ac
>>
>> [df835e90] [c01be17c] __driver_attach+0xa4/0xa8
>>
>> [df835eb0] [c01bcfa4] bus_for_each_dev+0x60/0x9c
>>
>> [df835ee0] [c01bdbbc] driver_attach+0x24/0x34
>>
>> [df835ef0] [c01bd94c] bus_add_driver+0x1b8/0x274
>>
>> [df835f20] [c01be3d8] driver_register+0x6c/0x160
>>
>> [df835f40] [c01bf6c4] platform_driver_register+0x68/0x78
>>
>> [df835f50] [c023c998] of_register_platform_driver+0xa8/0xc4
>>
>> [df835f60] [c0393e88] emac_init+0x1ac/0x1dc
>>
>> [df835fa0] [c0001574] do_one_initcall+0x160/0x1a8
>>
>> [df835fd0] [c037a1e8] kernel_init+0xcc/0x174
>>
>> [df835ff0] [c000c5b0] kernel_thread+0x4c/0x68
>>
>> Instruction dump:
>>
>> 419e016c 2f800007 419e0164 38130774 901a00d0 381306b0 901a00d4 7f43d378
>>
>> 4bf91d89 817a01a0 39200001 380b0008 <7d400028> 7d4a4b78 7d40012d 40a2fff=
4
>>
>> ---[ end trace dac0cf4779f83901 ]---
A git bisect between 2.6.36 (working) and Linus tip (traceback) points to:
e6484930d7c73d324bccda7d43d131088da697b9 net: allocate tx queues in
register_netdevice
as causing this. I'm not entirely sure why yet, but the commit
message seems slightly off to me. It claims to make TX queue
allocation identical to RX, but from what I can tell, most of the RX
queue logic is hidden behind CONFIG_RPS, which is not set in my config
at all (and can't be due to a dep on CONFIG_SMP). This change doesn't
guard anything behind that.
A few hints would be appreciated.
josh
^ permalink raw reply
* Re: All Applied micro boards are failing with current mainline kernel
From: Stephen Rothwell @ 2010-11-01 15:36 UTC (permalink / raw)
To: Josh Boyer
Cc: Eric Dumazet, Rupjyoti Sarmah, linux-kernel, linuxppc-dev,
David S. Miller, Tom Herbert
In-Reply-To: <AANLkTikQuUcAMZKqZ3Rz5HVzOs+63-Y4VYUo5-3EM30H@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
Hi Josh,
On Mon, 1 Nov 2010 11:05:53 -0400 Josh Boyer <jwboyer@gmail.com> wrote:
>
> A few hints would be appreciated.
Remove the call to netif_stop_queue() from emac_probe(). Apparently,
calling this before register_netdev() is now wrong (maybe always was).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: All Applied micro boards are failing with current mainline kernel
From: Josh Boyer @ 2010-11-01 15:39 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Eric Dumazet, Rupjyoti Sarmah, linux-kernel, linuxppc-dev,
David S. Miller, Tom Herbert
In-Reply-To: <20101102023650.bc553e74.sfr@canb.auug.org.au>
On Mon, Nov 1, 2010 at 11:36 AM, Stephen Rothwell <sfr@canb.auug.org.au> wr=
ote:
> Hi Josh,
>
> On Mon, 1 Nov 2010 11:05:53 -0400 Josh Boyer <jwboyer@gmail.com> wrote:
>>
>> A few hints would be appreciated.
>
> Remove the call to netif_stop_queue() from emac_probe(). =A0Apparently,
> calling this before register_netdev() is now wrong (maybe always was).
Yeah, I just discovered that myself. I'm wondering
1) why we do that in that function?
2) If it needs to be removed entirely, or moved to after the
register_netdev call
3) If the call to netif_carrier_off also needs similar attention.
I can whip up a patch to remove those calls or move them after the
register, but I don't want to do that without knowing which one is
"right".
josh
^ 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