* Re: [PATCH] synchronize_irq needs a barrier
From: Benjamin Herrenschmidt @ 2007-10-20 4:06 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linuxppc-dev list, akpm, Linus Torvalds, Linux Kernel list
In-Reply-To: <200710200510.01409.maximlevitsky@gmail.com>
> > - even when you ignore the interrupt (because the driver doesn't care,
> > it's suspending), you need to make sure the hardware gets shut up by
> > reading (or writing) the proper interrupt status register.
> I agree, but while device is powered off, its registers can't be accessed
> Thus, if I ack the IRQ every time the handler is called, I will access the
> powered off device (this is probably won't hurt a lot, but a bit incorrectly)
It will actually crash your machine on some platforms. So no, best is to
-not- ack. The masking is enough, the IRQ will go down eventually.
Ben.
^ permalink raw reply
* Re: [PATCH] synchronize_irq needs a barrier
From: Benjamin Herrenschmidt @ 2007-10-20 4:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, akpm, Maxim Levitsky, Linux Kernel list
In-Reply-To: <alpine.LFD.0.999.0710191924520.3794@woody.linux-foundation.org>
On Fri, 2007-10-19 at 19:25 -0700, Linus Torvalds wrote:
>
> On Sat, 20 Oct 2007, Maxim Levitsky wrote:
> >
> > and the interrupt handler:
> >
> > smp_rmb();
> > if (dev->insuspend)
> > goto out;
>
> Something like that can work, yes. However, you need to make sure that:
>
> - even when you ignore the interrupt (because the driver doesn't care,
> it's suspending), you need to make sure the hardware gets shut up by
> reading (or writing) the proper interrupt status register.
>
> Otherwise, with a level interrupt, the interrupt will continue to be
> held active ("screaming") and the CPU will get interrupted over and
> over again, until the irq subsystem will just turn the irq off
> entirely.
His suspend routine wrote to the IRQ mask (or equivalent) register in
his code example, thus the HW should shut up eventually, thus that isn't
strictly necessary, the IRQ in that case is just a "short
interrupt" (noticed by the PIC and delivered but possibly not asserted
anymore at this stage or about to go down).
We have many scenario generating such short interrupts (pretty much any
time we use interrupt disable/enable on the chip, for example it's
common with NAPI).
This is one of the reasons why we used to have a "timebomb" causing an
IRQ to erroneously get disabled by the IRQ core assuming the IRQ was
stuck, just because we accumulated too many short interrupts on that
line. A recent patch by Alan fixed that to use some more sensible
algorithm checking the time since the last spurrious interrupt, though I
suspect he's being too optimistic on his timeout value and some
scenario, such as NAPI with just the wrong packet rate, can still
trigger the bug. I need to find a piece of HW slow enough in
de-asserting the IRQ to try to make a repro-case one of these days.
> - when you resume, make sure that you get the engine going again, with
> the understanding that some interrupts may have gotten ignored.
And you forgot that he still needs synchronize_irq(), or his IRQ handler
might well be in the middle of doing something on another CPU, past the
point where it tested "insuspend", which will do no good when a
simultaneous pci_set_power_state() puts the chip into D3. On some
machines, this will machine check. Either that or he needs a spinlock in
his IRQ handler that he also takes around the code that sets insuspend.
> Also, in general, these kinds of things shouldn't always even be
> neicessary. If you use the suspend_late()/resume_early() hooks, those will
> be called with interrupts off, and while they can be harder to debug (and
> may be worth avoiding for non-critical drivers), they do allow for simpler
> models partly exactly because they don't need to worry about interrupts
> etc.
Yes, this is a easier way to deal with devices that are on a directly
mapped bus (path to them isn't gone by the time you hit suspend_late)
and don't need to do fancy things involing waiting for a queue to drain
using interrupts etc... (at one stage of HW complexity, having to
re-implement polled versions of everything is just not worth the
benefit). In general, suspend_late should cover the need of most PCI
devices I suppose.
Ben.
^ permalink raw reply
* Re: [PATCH] synchronize_irq needs a barrier
From: Benjamin Herrenschmidt @ 2007-10-20 3:56 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linuxppc-dev list, akpm, Linus Torvalds, Linux Kernel list
In-Reply-To: <200710200402.43106.maximlevitsky@gmail.com>
> I have read this thread and I concluded few things:
>
> 1) It is impossible to know that the card won't send more interrupts:
> Even if I do a read from the device, the IRQ can be pending in the bus/APIC
> It is even possible (and likely) that the IRQ line will be shared, thus the
> handler can be called by non-relevant device.
>
> 2) the synchronize_irq(); in .suspend is useless:
> an IRQ can happen immediately after this synchronize_irq();
> and interrupt even the .suspend()
> (At least theoretically)
It's not totally useless not. It guarantees that by the time your
are out of your suspend(), a simultaneous instance of the IRQ handler
is either finished, or it (or any subsequent occurence) have seen
your insuspend flag set to 1.
> Thus I now understand that .suspend() should do:
>
> saa_writel(SAA7134_IRQ1, 0);
> saa_writel(SAA7134_IRQ2, 0);
> saa_writel(SAA7134_MAIN_CTRL, 0);
>
> dev->insuspend = 1;
> smp_wmb();
>
> /* at that point the _request to disable card's IRQs was issued, we don't know
> that there will be no irqs anymore.
> the smp_mb(); guaranties that the IRQ handler will bail out in that case. */
>
> /* .......*/
>
> pci_save_state(pci_dev);
> pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state));
> return 0;
The above doesn't handle the case where the IRQ handle just passed the
if (insuspend) test. You may end up calling pci_set_power_state() while
in the middle of some further HW accesses in the handler.
You still need synchronize_irq() for that reason. Or use a spinlock.
> and the interrupt handler:
>
> smp_rmb();
> if (dev->insuspend)
> goto out;
>
> Am I right?
Not quite :-)
Also not that the work we are doing with synchronize_irq, if it gets
merged, renders it unnecessary for you to add those two memory barriers,
synchronize_irq will pretty much do the ordering for you.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] synchronize_irq needs a barrier
From: Herbert Xu @ 2007-10-20 3:37 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: akpm, Linus Torvalds, Linux Kernel list, linuxppc-dev list
In-Reply-To: <200710200402.43106.maximlevitsky@gmail.com>
On Sat, Oct 20, 2007 at 02:02:42AM +0000, Maxim Levitsky wrote:
>
> Thus I now understand that .suspend() should do:
>
> saa_writel(SAA7134_IRQ1, 0);
> saa_writel(SAA7134_IRQ2, 0);
> saa_writel(SAA7134_MAIN_CTRL, 0);
>
> dev->insuspend = 1;
> smp_wmb();
If we patch synchronize_irq() as discussed here then you can
use it in place of smp_wmb() and remove the smp_rmb from the
interrupt handler (the latter is the path that matters).
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] fix build break in arch/ppc/syslib/m8260_setup.c
From: Olof Johansson @ 2007-10-20 3:39 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, paulus
Fix build break and warnings in current mainline git:
arch/ppc/syslib/m8260_setup.c: In function 'm8260_setup_arch':
arch/ppc/syslib/m8260_setup.c:63: error: implicit declaration of function 'identify_ppc_sys_by_name_and_id'
arch/ppc/syslib/m8260_setup.c:64: warning: passing argument 1 of 'in_be32' makes pointer from integer without a cast
arch/ppc/syslib/m8260_setup.c: In function 'm8260_show_cpuinfo':
arch/ppc/syslib/m8260_setup.c:158: warning: format '%08x' expects type 'unsigned int', but argument 5 has type 'long unsigned int'
arch/ppc/syslib/m8260_setup.c:158: warning: format '%d' expects type 'int', but argument 6 has type 'long unsigned int'
arch/ppc/syslib/m8260_setup.c:158: warning: format '%u' expects type 'unsigned int', but argument 7 has type 'long unsigned int'
arch/ppc/syslib/m8260_setup.c:158: warning: format '%u' expects type 'unsigned int', but argument 8 has type 'long unsigned int'
arch/ppc/syslib/m8260_setup.c:158: warning: format '%u' expects type 'unsigned int', but argument 9 has type 'long unsigned int'
make[1]: *** [arch/ppc/syslib/m8260_setup.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/ppc/syslib/m8260_setup.c b/arch/ppc/syslib/m8260_setup.c
index 15f0d73..46588fa 100644
--- a/arch/ppc/syslib/m8260_setup.c
+++ b/arch/ppc/syslib/m8260_setup.c
@@ -25,6 +25,7 @@
#include <asm/machdep.h>
#include <asm/bootinfo.h>
#include <asm/time.h>
+#include <asm/ppc_sys.h>
#include "cpm2_pic.h"
@@ -61,7 +62,7 @@ m8260_setup_arch(void)
#endif
identify_ppc_sys_by_name_and_id(BOARD_CHIP_NAME,
- in_be32(CPM_MAP_ADDR + CPM_IMMR_OFFSET));
+ in_be32((void *)CPM_MAP_ADDR + CPM_IMMR_OFFSET));
m82xx_board_setup();
}
@@ -147,12 +148,12 @@ m8260_show_cpuinfo(struct seq_file *m)
seq_printf(m, "vendor\t\t: %s\n"
"machine\t\t: %s\n"
"\n"
- "mem size\t\t: 0x%08x\n"
- "console baud\t\t: %d\n"
+ "mem size\t\t: 0x%08lx\n"
+ "console baud\t\t: %ld\n"
"\n"
- "core clock\t: %u MHz\n"
- "CPM clock\t: %u MHz\n"
- "bus clock\t: %u MHz\n",
+ "core clock\t: %lu MHz\n"
+ "CPM clock\t: %lu MHz\n"
+ "bus clock\t: %lu MHz\n",
CPUINFO_VENDOR, CPUINFO_MACHINE, bp->bi_memsize,
bp->bi_baudrate, bp->bi_intfreq / 1000000,
bp->bi_cpmfreq / 1000000, bp->bi_busfreq / 1000000);
^ permalink raw reply related
* Re: [PATCH] synchronize_irq needs a barrier
From: Maxim Levitsky @ 2007-10-20 3:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: akpm, Linux Kernel list, linuxppc-dev list
In-Reply-To: <alpine.LFD.0.999.0710191924520.3794@woody.linux-foundation.org>
On Saturday 20 October 2007 04:25:34 Linus Torvalds wrote:
>
> On Sat, 20 Oct 2007, Maxim Levitsky wrote:
> >
> > and the interrupt handler:
> >
> > smp_rmb();
> > if (dev->insuspend)
> > goto out;
>
> Something like that can work, yes. However, you need to make sure that:
>
> - even when you ignore the interrupt (because the driver doesn't care,
> it's suspending), you need to make sure the hardware gets shut up by
> reading (or writing) the proper interrupt status register.
I agree, but while device is powered off, its registers can't be accessed
Thus, if I ack the IRQ every time the handler is called, I will access the
powered off device (this is probably won't hurt a lot, but a bit incorrectly)
>
> Otherwise, with a level interrupt, the interrupt will continue to be
> held active ("screaming") and the CPU will get interrupted over and
> over again, until the irq subsystem will just turn the irq off
> entirely.
>
> - when you resume, make sure that you get the engine going again, with
> the understanding that some interrupts may have gotten ignored.
Here it isn't a problem, this is a video capture card, and I suspend it by just stopping dma
on all active buffers even if in the middle of capture, and I send those buffers to card again
to fill them from the beginning during the resume.
>
> Also, in general, these kinds of things shouldn't always even be
> neicessary. If you use the suspend_late()/resume_early() hooks, those will
> be called with interrupts off, and while they can be harder to debug (and
> may be worth avoiding for non-critical drivers), they do allow for simpler
> models partly exactly because they don't need to worry about interrupts
> etc.
Exactly, I am aware of suspend_late , but I don't want to abuse it.
>
> Linus
>
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [PATCH] Fix build break in tsi108.c
From: Jeff Garzik @ 2007-10-20 3:04 UTC (permalink / raw)
To: Olof Johansson; +Cc: joe, netdev, linuxppc-dev
In-Reply-To: <20071020020420.GA20073@lixom.net>
Olof Johansson wrote:
> Fix build break:
>
> drivers/net/tsi108_eth.c: In function 'tsi108_init_one':
> drivers/net/tsi108_eth.c:1633: error: expected ')' before 'dev'
> drivers/net/tsi108_eth.c:1633: warning: too few arguments for format
> make[2]: *** [drivers/net/tsi108_eth.o] Error 1
>
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
> diff --git a/drivers/net/tsi108_eth.c b/drivers/net/tsi108_eth.c
> index df10af7..35d15e8 100644
> --- a/drivers/net/tsi108_eth.c
> +++ b/drivers/net/tsi108_eth.c
> @@ -1629,7 +1629,7 @@ tsi108_init_one(struct platform_device *pdev)
> goto register_fail;
> }
>
> - printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n"
> + printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n",
> dev->name, print_mac(mac, dev->dev_addr));
> #ifdef DEBUG
applied
^ permalink raw reply
* Re: [PATCH] phy/bitbang: missing MODULE_LICENSE
From: Jeff Garzik @ 2007-10-20 3:03 UTC (permalink / raw)
To: Randy Dunlap; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071018122021.2acd128d.randy.dunlap@oracle.com>
Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Missing MODULE_LICENSE(), loading this module taints the kernel.
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> ---
> drivers/net/phy/mdio-bitbang.c | 2 ++
> 1 file changed, 2 insertions(+)
applied this and the NAPI_Howto Kconfig patch
^ permalink raw reply
* ep88xc_defconfig doesn't build
From: Olof Johansson @ 2007-10-20 2:43 UTC (permalink / raw)
To: scott.wood; +Cc: linuxppc-dev
Hi,
Did it ever?! I get this with current mainline when building default target:
WRAP arch/powerpc/boot/cuImage.8xx
DTC: dts->dtb on file "/work/work/linux/k.org/arch/powerpc/boot/dts/ep88xc.dts"
ERROR: Missing /chosen node
Input tree has errors
WRAP arch/powerpc/boot/zImage.ep88xc
make[1]: *** [arch/powerpc/boot/cuImage.8xx] Error 1
make[1]: *** Waiting for unfinished jobs....
DTC: dts->dtb on file "/work/work/linux/k.org/arch/powerpc/boot/dts/ep88xc.dts"
ERROR: Missing /chosen node
Input tree has errors
make[1]: *** [arch/powerpc/boot/zImage.ep88xc] Error 1
make: *** [zImage] Error 2
-Olof
^ permalink raw reply
* Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
From: Michal Simek @ 2007-10-20 2:28 UTC (permalink / raw)
To: microblaze-uclinux
Cc: Leonid, Arnd Bergmann, linuxppc-dev, Wolfgang Reissnegger
In-Reply-To: <20071019234347.38C1111C006B@mail3-dub.bigfish.com>
Hi Steve and all,
>Here's a full .dts generated using an updated version of
>gen_mhs_devtree.py, following the proposal.
>It happens to be a microblaze system, but you get the idea.
I think that is no good idea generate dts with all information.
Especially information about PVR - number 2 means - Full PVR and you can
obtain information directly from PVR. It is waste of memory space.
xilinx,pvr = <2>;
In my opinion will be better generate only parameters which you want not all.
That smells with unusable parameters.
Michal Simek
^ permalink raw reply
* Re: [PATCH] synchronize_irq needs a barrier
From: Linus Torvalds @ 2007-10-20 2:25 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: akpm, Linux Kernel list, linuxppc-dev list
In-Reply-To: <200710200402.43106.maximlevitsky@gmail.com>
On Sat, 20 Oct 2007, Maxim Levitsky wrote:
>
> and the interrupt handler:
>
> smp_rmb();
> if (dev->insuspend)
> goto out;
Something like that can work, yes. However, you need to make sure that:
- even when you ignore the interrupt (because the driver doesn't care,
it's suspending), you need to make sure the hardware gets shut up by
reading (or writing) the proper interrupt status register.
Otherwise, with a level interrupt, the interrupt will continue to be
held active ("screaming") and the CPU will get interrupted over and
over again, until the irq subsystem will just turn the irq off
entirely.
- when you resume, make sure that you get the engine going again, with
the understanding that some interrupts may have gotten ignored.
Also, in general, these kinds of things shouldn't always even be
neicessary. If you use the suspend_late()/resume_early() hooks, those will
be called with interrupts off, and while they can be harder to debug (and
may be worth avoiding for non-critical drivers), they do allow for simpler
models partly exactly because they don't need to worry about interrupts
etc.
Linus
^ permalink raw reply
* Re: [PATCH] synchronize_irq needs a barrier
From: Maxim Levitsky @ 2007-10-20 2:02 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list, akpm, Linus Torvalds, Linux Kernel list
In-Reply-To: <1192670742.12879.5.camel@pasglop>
On Thursday 18 October 2007 03:25:42 Benjamin Herrenschmidt wrote:
> synchronize_irq needs at the very least a compiler barrier and a
> read barrier on SMP, but there are enough cases around where a
> write barrier is also needed and it's not a hot path so I prefer
> using a full smp_mb() here.
>
> It will degrade to a compiler barrier on !SMP.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Index: linux-work/kernel/irq/manage.c
> ===================================================================
> --- linux-work.orig/kernel/irq/manage.c 2007-10-18 11:22:16.000000000 +1000
> +++ linux-work/kernel/irq/manage.c 2007-10-18 11:22:20.000000000 +1000
> @@ -33,6 +33,7 @@ void synchronize_irq(unsigned int irq)
> if (irq >= NR_IRQS)
> return;
>
> + smp_mb();
> while (desc->status & IRQ_INPROGRESS)
> cpu_relax();
> }
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Hi,
I have read this thread and I concluded few things:
1) It is impossible to know that the card won't send more interrupts:
Even if I do a read from the device, the IRQ can be pending in the bus/APIC
It is even possible (and likely) that the IRQ line will be shared, thus the
handler can be called by non-relevant device.
2) the synchronize_irq(); in .suspend is useless:
an IRQ can happen immediately after this synchronize_irq();
and interrupt even the .suspend()
(At least theoretically)
Thus I now understand that .suspend() should do:
saa_writel(SAA7134_IRQ1, 0);
saa_writel(SAA7134_IRQ2, 0);
saa_writel(SAA7134_MAIN_CTRL, 0);
dev->insuspend = 1;
smp_wmb();
/* at that point the _request to disable card's IRQs was issued, we don't know
that there will be no irqs anymore.
the smp_mb(); guaranties that the IRQ handler will bail out in that case. */
/* .......*/
pci_save_state(pci_dev);
pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state));
return 0;
and the interrupt handler:
smp_rmb();
if (dev->insuspend)
goto out;
Am I right?
Best regards,
Maxim Levitsky
^ permalink raw reply
* [PATCH] Fix build break in tsi108.c
From: Olof Johansson @ 2007-10-20 2:04 UTC (permalink / raw)
To: jgarzik; +Cc: joe, netdev, linuxppc-dev
Fix build break:
drivers/net/tsi108_eth.c: In function 'tsi108_init_one':
drivers/net/tsi108_eth.c:1633: error: expected ')' before 'dev'
drivers/net/tsi108_eth.c:1633: warning: too few arguments for format
make[2]: *** [drivers/net/tsi108_eth.o] Error 1
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/drivers/net/tsi108_eth.c b/drivers/net/tsi108_eth.c
index df10af7..35d15e8 100644
--- a/drivers/net/tsi108_eth.c
+++ b/drivers/net/tsi108_eth.c
@@ -1629,7 +1629,7 @@ tsi108_init_one(struct platform_device *pdev)
goto register_fail;
}
- printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n"
+ printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n",
dev->name, print_mac(mac, dev->dev_addr));
#ifdef DEBUG
data->msg_enable = DEBUG;
^ permalink raw reply related
* Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Benjamin Herrenschmidt @ 2007-10-20 1:29 UTC (permalink / raw)
To: Linas Vepstas
Cc: Michael Ellerman, netdev, mcarlson, linuxppc-dev, mchan,
linux-pci, David Miller
In-Reply-To: <20071020004610.GR29903@austin.ibm.com>
> I'm cc'ing the powerpc mailing list to point this out:
> it looks like only cell/axon_msi.c and mpic_u3msi.c
> bother do do anything. I guess that there aren't any old
> macintosh laptops that have msi on them? Because without
> this, suspend and resume breaks.
The only macs that can do any form of MSIs are the G5s using
mpic_u3msi.c
> Paul,
> On the off chance your reading this, I'll send a pseries
> patch on Monday, with luck (and some other patches too).
> I'm not touching any of the other plaforms, you and benh
> would know those better.
Or rather Michael as he wrote the ppc MSI support. I'll check with him
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: mpic: minor optimization of ipi handler
From: Benjamin Herrenschmidt @ 2007-10-20 1:23 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus, jgarzik
In-Reply-To: <20071019234950.GA18112@lixom.net>
On Fri, 2007-10-19 at 18:49 -0500, Olof Johansson wrote:
> Optimize MPIC IPIs, by passing in the IPI number as the argument to the
> handler, since all we did was translate it back based on which mpic
> the interrupt came though on (and that was always the primary mpic).
>
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
> Oh, I see what you mean. You didn't make it easy to parse. :)
>
> This should actually do the work.
>
> -Olof
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index e479388..a8d7c68 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -614,10 +614,9 @@ static inline void mpic_eoi(struct mpic *mpic)
> #ifdef CONFIG_SMP
> static irqreturn_t mpic_ipi_action(int irq, void *data)
> {
> - struct mpic *mpic;
> + long ipi = (long)data;
>
> - mpic = mpic_find(irq, NULL);
> - smp_message_recv(mpic_irq_to_hw(irq) - mpic->ipi_vecs[0]);
> + smp_message_recv(ipi);
>
> return IRQ_HANDLED;
> }
> @@ -1457,7 +1456,7 @@ unsigned int mpic_get_irq(void)
> void mpic_request_ipis(void)
> {
> struct mpic *mpic = mpic_primary;
> - int i, err;
> + long i, err;
> static char *ipi_names[] = {
> "IPI0 (call function)",
> "IPI1 (reschedule)",
> @@ -1472,14 +1471,14 @@ void mpic_request_ipis(void)
> unsigned int vipi = irq_create_mapping(mpic->irqhost,
> mpic->ipi_vecs[0] + i);
> if (vipi == NO_IRQ) {
> - printk(KERN_ERR "Failed to map IPI %d\n", i);
> + printk(KERN_ERR "Failed to map IPI %ld\n", i);
> break;
> }
> err = request_irq(vipi, mpic_ipi_action,
> IRQF_DISABLED|IRQF_PERCPU,
> - ipi_names[i], mpic);
> + ipi_names[i], (void *)i);
> if (err) {
> - printk(KERN_ERR "Request of irq %d for IPI %d failed\n",
> + printk(KERN_ERR "Request of irq %d for IPI %ld failed\n",
> vipi, i);
> break;
> }
^ permalink raw reply
* Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: David Miller @ 2007-10-20 0:53 UTC (permalink / raw)
To: linas; +Cc: netdev, mcarlson, linuxppc-dev, mchan, linux-pci
In-Reply-To: <20071020004610.GR29903@austin.ibm.com>
From: linas@austin.ibm.com (Linas Vepstas)
Date: Fri, 19 Oct 2007 19:46:10 -0500
> FWIW, it looks like not all that many arches do this; the output
> for grep -r address_hi * is pretty thin. Then, looking at
> i386/kernel/io_apic.c as an example, one can see that the
> msi state save happens "by accident" if CONFIG_SMP is enabled;
> and so its surely broekn on uniprocesor machines.
I don't see this, in all cases write_msi_msg() will transfer
the given "*msg" to entry->msg by this assignment in
drivers/pci/msi.c:
void write_msi_msg(unsigned int irq, struct msi_msg *msg)
{
...
entry->msg = *msg;
}
So as long as write_msi_msg() is invoked, it will be saved
properly.
Platforms need not do this explicitly.
^ permalink raw reply
* [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Linas Vepstas @ 2007-10-20 0:46 UTC (permalink / raw)
To: David Miller, linuxppc-dev; +Cc: netdev, linux-pci, mcarlson, mchan
In-Reply-To: <20071019.172706.57467960.davem@davemloft.net>
Hi,
On Fri, Oct 19, 2007 at 05:27:06PM -0700, David Miller wrote:
> From: linas@austin.ibm.com (Linas Vepstas)
> Date: Fri, 19 Oct 2007 19:04:21 -0500
>
> > I'm working in linux-2.6.23-rc8-mm1 at the moment, and I don't see
> > that happening. viz. read_msi_msg() is not called anywhere, and I need
> > to have valid msg->address_lo and msg->address_hi and msg->data
> > in order to be able to restore.
>
> See the pci_restore_msi_state() call done from pci_restore_state()
> in drivers/pci/pci.c, that pci_restore_msi_state() code in
> drivers/pci/msi.c very much relies upon the entry->msg values
> being uptodate and valid.
>
> The MSI arch layer code is supposed to fill the entry->msg values in
> via arch_setup_msi_irq(). Perhaps the pseries code is forgetting to
> do that.
Yep. Thank you for confirming the correct location for the fix.
FWIW, it looks like not all that many arches do this; the output
for grep -r address_hi * is pretty thin. Then, looking at
i386/kernel/io_apic.c as an example, one can see that the
msi state save happens "by accident" if CONFIG_SMP is enabled;
and so its surely broekn on uniprocesor machines.
I'm cc'ing the powerpc mailing list to point this out:
it looks like only cell/axon_msi.c and mpic_u3msi.c
bother do do anything. I guess that there aren't any old
macintosh laptops that have msi on them? Because without
this, suspend and resume breaks.
Paul,
On the off chance your reading this, I'll send a pseries
patch on Monday, with luck (and some other patches too).
I'm not touching any of the other plaforms, you and benh
would know those better.
--linas
^ permalink raw reply
* Re: [PATCH] bestcomm: Restrict disabling of bus prefetch to original mpc5200 silicon.
From: Matt Sealey @ 2007-10-19 23:58 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Domen Puncer
In-Reply-To: <fa686aa40710190609jebd4e31q9240d2ff5b4a5d47@mail.gmail.com>
Grant Likely wrote:
> On 10/19/07, Domen Puncer <domen.puncer@telargo.com> wrote:
>> On 17/10/07 10:36 -0600, Grant Likely wrote:
>>> From: Grant Likely <grant.likely@secretlab.ca>
>>>
>>> Only the MPC5200 needs this bug fix. MPC5200B is okay.
>>>
>>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>>> ---
>>>
>>> Sven, Domen;
>>>
>>> Can you please test this patch?
>> I found no obvious problems with it on Efika (mpc5200b)
>
> Cool, I'll add it to my list of patches for Paulus to pull
See now that wasn't so hard was it? :D
You earned a cookie :D
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* RE: [PATCH v3] Device tree bindings for Xilinx devices
From: Stephen Neuendorffer @ 2007-10-19 23:42 UTC (permalink / raw)
To: Stephen Neuendorffer, Grant Likely
Cc: linuxppc-dev, Leonid, Wolfgang Reissnegger, Arnd Bergmann,
microblaze-uclinux
In-Reply-To: <20071018190555.8EE7177805F@mail76-sin.bigfish.com>
Here's a full .dts generated using an updated version of
gen_mhs_devtree.py, following the proposal.
It happens to be a microblaze system, but you get the idea.
Grant: Is this pretty what you intend?
Steve
/ {
#address-cells =3D <1>;
#size-cells =3D <1>;
compatible =3D "ibm,plb4";
model =3D "system.mhs";
Ethernet_MAC {
compatible =3D
"xilinx,opb-ethernet-1.04.a\0xilinx,opb-ethernet";
device_type =3D "opb_ethernet";
interrupt-parent =3D <101>;
interrupts =3D < 1 0 >;
reg =3D < 40c00000 10000 >;
xilinx,cam-exist =3D <0>;
xilinx,dev-blk-id =3D <0>;
xilinx,dev-mir-enable =3D <0>;
xilinx,dma-present =3D <1>;
xilinx,include-dev-pencoder =3D <0>;
xilinx,ipif-rdfifo-depth =3D <4000>;
xilinx,ipif-wrfifo-depth =3D <4000>;
xilinx,jumbo-exist =3D <0>;
xilinx,mac-fifo-depth =3D <10>;
xilinx,mii-exist =3D <1>;
xilinx,opb-clk-period-ps =3D <2710>;
xilinx,reset-present =3D <1>;
xilinx,rx-dre-type =3D <0>;
xilinx,rx-include-csum =3D <0>;
xilinx,tx-dre-type =3D <0>;
xilinx,tx-include-csum =3D <0>;
} ;
IIC_EEPROM {
compatible =3D "xilinx,opb-iic-1.02.a\0xilinx,opb-iic";
device_type =3D "opb_iic";
interrupt-parent =3D <101>;
interrupts =3D < 2 0 >;
reg =3D < 40800000 10000 >;
xilinx,clk-freq =3D <5f5e100>;
xilinx,iic-freq =3D <186a0>;
xilinx,ten-bit-adr =3D <0>;
} ;
RS232_Uart_1 {
compatible =3D
"xilinx,opb-uartlite-1.00.b\0xilinx,opb-uartlite";
device_type =3D "opb_uartlite";
interrupt-parent =3D <101>;
interrupts =3D < 3 0 >;
reg =3D < 40600000 10000 >;
xilinx,baudrate =3D <2580>;
xilinx,clk-freq =3D <5f5e100>;
xilinx,data-bits =3D <8>;
xilinx,odd-parity =3D <0>;
xilinx,use-parity =3D <0>;
} ;
chosen {
bootargs =3D "root=3D/dev/xsysace/disc0/part2";
interrupt-controller =3D <101>;
linux,platform =3D <600>;
} ;
cpus {
#address-cells =3D <1>;
#cpus =3D <1>;
#size-cells =3D <0>;
microblaze_0,6.00. {
32-bit;
clock-frequency =3D <5f5e1000>;
d-cache-line-size =3D <10>;
d-cache-size =3D <4000>;
device_type =3D "cpu";
i-cache-line-size =3D <10>;
i-cache-size =3D <4000>;
linux,boot-cpu;
reg =3D <0>;
timebase-frequency =3D <1fca055>;
xilinx,cache-byte-size =3D <4000>;
xilinx,dcache-baseaddr =3D <50000000>;
xilinx,dcache-byte-size =3D <4000>;
xilinx,dcache-highaddr =3D <5fffffff>;
xilinx,debug-enabled =3D <1>;
xilinx,div-zero-exception =3D <1>;
xilinx,dopb-bus-exception =3D <1>;
xilinx,fpu-exception =3D <1>;
xilinx,icache-baseaddr =3D <50000000>;
xilinx,icache-highaddr =3D <5fffffff>;
xilinx,ill-opcode-exception =3D <1>;
xilinx,iopb-bus-exception =3D <1>;
xilinx,number-of-pc-brk =3D <2>;
xilinx,pvr =3D <2>;
xilinx,unaligned-exceptions =3D <1>;
xilinx,use-barrel =3D <1>;
xilinx,use-dcache =3D <1>;
xilinx,use-div =3D <1>;
xilinx,use-fpu =3D <1>;
xilinx,use-icache =3D <1>;
xilinx,use-msr-instr =3D <1>;
xilinx,use-pcmp-instr =3D <1>;
} ;
} ;
debug_module {
compatible =3D "xilinx,opb-mdm-2.00.a\0xilinx,opb-mdm";
device_type =3D "opb_mdm";
reg =3D < 41400000 10000 >;
xilinx,mb-dbg-ports =3D <1>;
xilinx,uart-width =3D <8>;
xilinx,use-uart =3D <1>;
} ;
memory@50000000 {
device_type =3D "memory";
edk_name =3D "DDR2_SDRAM_32Mx32";
memreg:reg =3D < 50000000 10000000 >;
} ;
opb_hwicap_0 {
compatible =3D
"xilinx,opb-hwicap-1.10.a\0xilinx,opb-hwicap";
device_type =3D "opb_hwicap";
reg =3D < 41300000 10000 >;
} ;
opb_intc_0 {
#interrupt-cells =3D <2>;
compatible =3D "xilinx,opb-intc-1.00.c\0xilinx,opb-intc";
device_type =3D "opb_intc";
interrupt-controller;
linux,phandle =3D <101>;
reg =3D < 41200000 10000 >;
} ;
opb_timer_1 {
compatible =3D
"xilinx,opb-timer-1.00.b\0xilinx,opb-timer";
device_type =3D "opb_timer";
interrupt-parent =3D <101>;
interrupts =3D < 0 0 >;
reg =3D < 41c00000 10000 >;
xilinx,count-width =3D <20>;
xilinx,one-timer-only =3D <1>;
} ;
} ;=20
^ permalink raw reply
* Re: [PATCH] powerpc: mpic: minor optimization of ipi handler
From: Olof Johansson @ 2007-10-19 23:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, jgarzik
In-Reply-To: <20071019233134.GA17851@lixom.net>
Optimize MPIC IPIs, by passing in the IPI number as the argument to the
handler, since all we did was translate it back based on which mpic
the interrupt came though on (and that was always the primary mpic).
Signed-off-by: Olof Johansson <olof@lixom.net>
---
On Fri, Oct 19, 2007 at 06:31:34PM -0500, Olof Johansson wrote:
> On Sat, Oct 20, 2007 at 09:17:39AM +1000, Benjamin Herrenschmidt wrote:
> >
> > On Fri, 2007-10-19 at 13:51 -0500, Olof Johansson wrote:
> > > Jeff Garzik pointed out that we don't actually have to lookup the mpic
> > > instance since it's passed in as the interrupt handler data for IPIs.
> >
> > Note that's typically one of the annoying case where we use "irq"
> > for a good reasons, getting the way of Jeff attempt at removing
> > this argument.
> >
> > I suppose a working approach would be to have 4 mpic IPI handlers...
>
> We still need the _irq_, but we don't need to lookup the mpic based on it.
>
> We knew the mpic pointer at irq setup time, and passed it in as the
> argument to pass to the handler. Doing a second lookup is just extra
> overhead, it should return the same controller:
Oh, I see what you mean. You didn't make it easy to parse. :)
This should actually do the work.
-Olof
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index e479388..a8d7c68 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -614,10 +614,9 @@ static inline void mpic_eoi(struct mpic *mpic)
#ifdef CONFIG_SMP
static irqreturn_t mpic_ipi_action(int irq, void *data)
{
- struct mpic *mpic;
+ long ipi = (long)data;
- mpic = mpic_find(irq, NULL);
- smp_message_recv(mpic_irq_to_hw(irq) - mpic->ipi_vecs[0]);
+ smp_message_recv(ipi);
return IRQ_HANDLED;
}
@@ -1457,7 +1456,7 @@ unsigned int mpic_get_irq(void)
void mpic_request_ipis(void)
{
struct mpic *mpic = mpic_primary;
- int i, err;
+ long i, err;
static char *ipi_names[] = {
"IPI0 (call function)",
"IPI1 (reschedule)",
@@ -1472,14 +1471,14 @@ void mpic_request_ipis(void)
unsigned int vipi = irq_create_mapping(mpic->irqhost,
mpic->ipi_vecs[0] + i);
if (vipi == NO_IRQ) {
- printk(KERN_ERR "Failed to map IPI %d\n", i);
+ printk(KERN_ERR "Failed to map IPI %ld\n", i);
break;
}
err = request_irq(vipi, mpic_ipi_action,
IRQF_DISABLED|IRQF_PERCPU,
- ipi_names[i], mpic);
+ ipi_names[i], (void *)i);
if (err) {
- printk(KERN_ERR "Request of irq %d for IPI %d failed\n",
+ printk(KERN_ERR "Request of irq %d for IPI %ld failed\n",
vipi, i);
break;
}
^ permalink raw reply related
* Re: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
From: David Miller @ 2007-10-19 23:41 UTC (permalink / raw)
To: Emilian.Medve; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270168520B@az33exm24.fsl.freescale.net>
From: "Medve Emilian-EMMEDVE1" <Emilian.Medve@freescale.com>
Date: Fri, 19 Oct 2007 06:39:12 -0700
> For the current situation, 32-bit QE, 32-bit PowerPC, do you find
> the patch acceptable?
No piece of code in the kernel should live in a vacuum.
In order to improve overall code quality, every piece of
driver code should avoid assuming things about pointer
sizes and things of this nature.
Then the driver can get enabled into the build on every
platform, and therefore nobody will break the build of
this driver again since it will get hit by "allmodconfig"
et al. builds even on platforms other than the one it is
meant for.
This hack fix is not acceptable, really.
^ permalink raw reply
* Re: [PATCH] powerpc: mpic: minor optimization of ipi handler
From: Olof Johansson @ 2007-10-19 23:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, jgarzik
In-Reply-To: <1192835859.17235.12.camel@pasglop>
On Sat, Oct 20, 2007 at 09:17:39AM +1000, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-10-19 at 13:51 -0500, Olof Johansson wrote:
> > Jeff Garzik pointed out that we don't actually have to lookup the mpic
> > instance since it's passed in as the interrupt handler data for IPIs.
>
> Note that's typically one of the annoying case where we use "irq"
> for a good reasons, getting the way of Jeff attempt at removing
> this argument.
>
> I suppose a working approach would be to have 4 mpic IPI handlers...
We still need the _irq_, but we don't need to lookup the mpic based on it.
We knew the mpic pointer at irq setup time, and passed it in as the
argument to pass to the handler. Doing a second lookup is just extra
overhead, it should return the same controller:
void mpic_request_ipis(void)
{
struct mpic *mpic = mpic_primary;
int i, err;
static char *ipi_names[] = {
"IPI0 (call function)",
"IPI1 (reschedule)",
"IPI2 (unused)",
"IPI3 (debugger break)",
};
BUG_ON(mpic == NULL);
printk(KERN_INFO "mpic: requesting IPIs ... \n");
for (i = 0; i < 4; i++) {
unsigned int vipi = irq_create_mapping(mpic->irqhost,
mpic->ipi_vecs[0] + i);
if (vipi == NO_IRQ) {
printk(KERN_ERR "Failed to map IPI %d\n", i);
break;
}
err = request_irq(vipi, mpic_ipi_action,
IRQF_DISABLED|IRQF_PERCPU,
ipi_names[i], mpic);
if (err) {
printk(KERN_ERR "Request of irq %d for IPI %d failed\n",
vipi, i);
break;
}
}
}
-Olof
^ permalink raw reply
* Re: [PATCH] powerpc: mpic: minor optimization of ipi handler
From: Benjamin Herrenschmidt @ 2007-10-19 23:17 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus, jgarzik
In-Reply-To: <20071019185110.GA11911@lixom.net>
On Fri, 2007-10-19 at 13:51 -0500, Olof Johansson wrote:
> Jeff Garzik pointed out that we don't actually have to lookup the mpic
> instance since it's passed in as the interrupt handler data for IPIs.
Note that's typically one of the annoying case where we use "irq"
for a good reasons, getting the way of Jeff attempt at removing
this argument.
I suppose a working approach would be to have 4 mpic IPI handlers...
Ben.
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index e479388..6bf56f4 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -612,11 +612,10 @@ static inline void mpic_eoi(struct mpic *mpic)
> }
>
> #ifdef CONFIG_SMP
> -static irqreturn_t mpic_ipi_action(int irq, void *dev_id)
> +static irqreturn_t mpic_ipi_action(int irq, void *data)
> {
> - struct mpic *mpic;
> + struct mpic *mpic = data;
>
> - mpic = mpic_find(irq, NULL);
> smp_message_recv(mpic_irq_to_hw(irq) - mpic->ipi_vecs[0]);
>
> return IRQ_HANDLED;
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 0/4] DTC: Introduce better DTS literal support
From: David Gibson @ 2007-10-19 22:57 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IivrG-00077n-O8@jdl.com>
On Fri, Oct 19, 2007 at 12:42:02PM -0500, Jon Loeliger wrote:
> Folks,
>
> This 4 part patch series for the DTC has:
>
> 0001-Reformat-grammar-rules-to-not-mix-language-syntax-an.patch
> 0002-Quiet-a-bogus-May-be-used-uninitialized-warning.patch
> 0003-Appease-the-printf-format-Gods-with-a-correct-typ.patch
> 0004-Begin-the-path-to-sane-literals-and-expressions.patch
>
> The first is a pure whitespace formatting cleaning.
> The second two clean compiler warnings.
> The final one introduces a versioned DTS file with
> support for C-like literals.
I certainly have some comments on these, but I'm busy today and won't
be able to comment in detail until Monday or so. Please don't apply
them to mainline before then?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [bug] block subsystem related crash on Legacy iSeries viodasd.c
From: Will Schmidt @ 2007-10-19 21:33 UTC (permalink / raw)
To: Jens Axboe, Stephen Rothwell; +Cc: linuxppc-dev, linux-kernel
Hi Jens, Stephen, and Everyone else.
I am seeing this crash on a legacy iSeries box. Bisect points at
70eb8040dc81212c884a464b75e37dca8014f3ad (Add chained sg support to
linux/scatterlist.h).
I see there were some related troubles discussed a couple days back.
I've refreshed my tree, so believe I should have pulled in all the
changes that fixed those issues by now, so this is an additional problem
(viodasd funkyness), or I've screwed something up in my pulls, or fixes
are still pending in another tree.
>From the register dump, looks like sg passed into memset was a -2.
(from blk_rq_map_sg()) if (!sg)
sg = sglist;
else
sg = sg_next(sg);
memset(sg, 0, sizeof(*sg)); <--
linux-2.6.git tree at
commit 4fa4d23fa20de67df919030c1216295664866ad7
Merge: a9e82d3... 4f1e5ba...
Author: Linus Torvalds <torvalds@woody.linux-foundation.org>
Date: Thu Oct 18 19:31:54 2007 -0700
Merge branch 'upstream-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
> git log drivers/scsi/scsi_lib.c
commit a3bec5c5aea0da263111c4d8f8eabc1f8560d7bf
Author: Jens Axboe <axboe@carl.home.kernel.dk>
Date: Wed Oct 17 19:33:05 2007 +0200
Revert "[SCSI] Remove full sg table memset()"
> > git log block/ll_rw_blk.c
commit ba951841ceb7fa5b06ad48caa5270cc2ae17941e
Author: Jens Axboe <jens.axboe@oracle.com>
Date: Wed Oct 17 19:34:11 2007 +0200
[BLOCK] blk_rq_map_sg() next_sg fixup
-- The panic is:
Freeing unused kernel memory: 224k freed
Unable to handle kernel paging request for data at address 0xfffffffffffffffe
Faulting instruction address: 0xc0000000000282f0
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 iSeries
Modules linked in:
NIP: c0000000000282f0 LR: c0000000001c772c CTR: 0000000000000000
REGS: c000000002026b00 TRAP: 0300 Not tainted (2.6.23)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 44000022 XER: 00000008
DAR: fffffffffffffffe, DSISR: 0000000042000000
TASK = c000000002022000[1] 'swapper' THREAD: c000000002024000 CPU: 1
GPR00: 0000000000000002 c000000002026d80 c0000000005168c8 fffffffffffffffe
GPR04: 0000000000000000 000000000000001e fffffffffffffffe 0000000000000000
GPR08: 0000000000000000 0000000000000001 6db6db6db6db6db7 0000000001491000
GPR12: c00000000058d000 c000000000464f80 0000000000000000 c000000002027780
GPR16: c00000000300a0c8 0000000000000001 c0000000004d4dd0 c00000000297e868
GPR20: c000000002720000 c000000002026ec0 0000000000000001 0000000000000003
GPR24: 0000000000000000 c000000002720000 0000000000001000 0000000000000003
GPR28: fffffffffffffffe c000000002a61000 c0000000004c2510 c0000000027f64b0
NIP [c0000000000282f0] .memset+0x3c/0xfc
LR [c0000000001c772c] .blk_rq_map_sg+0x154/0x1e8
Call Trace:
[c000000002026d80] [c0000000004d4ed8] 0xc0000000004d4ed8 (unreliable)
[c000000002026e50] [c0000000002283d8] .do_viodasd_request+0xb4/0x448
[c0000000020270a0] [c0000000001c8ddc] .__generic_unplug_device+0x54/0x6c
[c000000002027120] [c0000000001ca438] .generic_unplug_device+0x30/0x78
[c0000000020271b0] [c0000000001c5888] .blk_backing_dev_unplug+0x34/0x48
[c000000002027230] [c0000000000cf75c] .block_sync_page+0x78/0x90
[c0000000020272b0] [c000000000074d50] .sync_page+0x74/0x98
[c000000002027330] [c000000000344538] .__wait_on_bit_lock+0x8c/0x110
[c0000000020273d0] [c000000000074c94] .__lock_page+0x70/0x90
[c0000000020274a0] [c0000000000758b4] .do_generic_mapping_read+0x248/0x47c
[c0000000020275a0] [c000000000077644] .generic_file_aio_read+0x144/0x1d4
[c000000002027680] [c0000000000a3ad8] .do_sync_read+0xc4/0x124
[c000000002027820] [c0000000000a4350] .vfs_read+0xd8/0x1a4
[c0000000020278c0] [c0000000000a965c] .kernel_read+0x38/0x5c
[c000000002027960] [c0000000000aad18] .do_execve+0xe8/0x208
[c000000002027a10] [c00000000000e0b4] .sys_execve+0x6c/0xf0
[c000000002027ab0] [c000000000007540] syscall_exit+0x0/0x40
--- Exception: c01 at .kernel_execve+0x8/0x14
LR = .run_init_process+0x28/0x40
[c000000002027da0] [c0000000000b35ec] .sys_dup+0x2c/0x44 (unreliable)
[c000000002027e20] [c000000000007fb4] .init_post+0xc4/0xe8
[c000000002027ea0] [c000000000407978] .kernel_init+0x384/0x3b8
[c000000002027f90] [c000000000020000] .kernel_thread+0x4c/0x68
Instruction dump:
5084801e 7c850040 7884000e 7c001120 7c661b78 418400ac 41a2002c 7ca02850
409f000c 98860000 38c60001 409e000c <b0860000> 38c60002 409d000c 90860000
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..
Thanks,
--Will
^ 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