* SPI Problem
From: GSM909 @ 2006-08-01 10:00 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I´m writing a Driver for SPI. That is not working now.
I have a MPC8260 using Linux 2.6.14 (rheap patch).
My Problems and Questions
1. The Pointer in my BD to my "Buffer Pointer" is in external memory, I normaly allocated with kmalloc. Are this ok or need I a SDMA Page ?
2. My SPCOM[STR] flag isn´t cleared automatically after one clock cycle.
What here going wrong ?
I hope somebody could help. Thx
Regards
Fred
--
"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
^ permalink raw reply
* Re: XUPV2P, Kernel 2.6.17 boot problem
From: Ameet Patil @ 2006-08-01 11:21 UTC (permalink / raw)
To: Benjamin Heyne; +Cc: Linuxppc-embedded
In-Reply-To: <20060801100220.26176938@bob.dt.e-technik.uni-dortmund.de>
Try this if it helps!
http://www.linux.get2knowmore.com/
-Ameet
Benjamin Heyne wrote:
> Dear all,
> I am currently trying to get the 2.6.17.1 Linux kernel
> running on the Xilinx Virtex. I have the 2.4 kernel up
> and running - No problems there...
>
> But when using the 2.6 kernel (have copied xparameters file,
> patched for using TEMAC driver) with the same hardware configuration
> the following happens:
>
>
> loaded at: 00400000 0061813C
> board data at: 00616124 0061613C
> relocated to: 00405148 00405160
> zimage at: 0040585D 00615F42
> avail ram: 00619000 20000000
>
> Linux/PPC load: console=ttyS0,9600.....
>
> Uncompressing Linux...inflate returned FFFFFFFB
> exit
>
>
> Now, I am not really sure where to start searching for the bug
> (I just want to implement some drivers - not the kernel itself ;-).
> The zImage.elf file is about 2MB large. Did anyone encounter
> a similar error? Does anyone have some hints where to
> look at for debugging, or what might be wrong?
>
> Thanks in advance
> Best regards
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform support
From: David Brownell @ 2006-08-01 15:36 UTC (permalink / raw)
To: linux-usb-devel; +Cc: linuxppc-dev
In-Reply-To: <a0bc9bf80607191159l679ce8ddm35a30236a9d887c7@mail.gmail.com>
On Wednesday 19 July 2006 11:59 am, Li Yang wrote:
> On 7/19/06, Dan Malek <dan@embeddedalley.com> wrote:
> >
> > On Jul 19, 2006, at 9:14 AM, Kumar Gala wrote:
> >
> > > This is an incorrect assumption. Its more often that people dont
> > > post their ports to the Linux kernel for acceptance. We will
> > > accept any port that is willing to work with the community. for
> > > example
> >
> > I agree. The customers of board ports I've done over the years
> > are always eager to get these into the public sources. It just
> > seems we run out of time during the pressure of trying to get
> > the products done, and they just issue them on CDs or for
> > download afterward.
>
> But why?
Because the notion of a "board port" of a driver is usually bogus;
as a rule, a driver doesn't need board-specific knowledge, any
board using the same chip could work the same. (And probably should;
most of the time I've seen board-specfic knowledge in drivers, it's
been masking bugs.)
And once the driver for a chip is open sourced, it can be reused
on other boards, generalized, and bugfixed ... none of which is
going to happen if you don't push the driver upstream. That means
the second or third product using that chip (or its cousins) could
become more robust, faster, easier to use, and otherwise "better".
No matter how good your developers are, there will be bugs in the
code they produce. Pushing drivers upstream increases the pool
of developers who _could_ fix the bugs and otherwise improve the
code, given time and incentive.
> Most embedded products facing end-user wouldn't like users
> to modify the system by themselves. Sometimes they even put effort in
> preventing user to do so. If no one else is going to modify the code,
> what is the value of putting them in public sources? Just to show the
> compliance with GPL? The only kind of products I can think of, which
> want the users to modify the code is reference boards, IMHO. Please
> correct me if I'm wrong.
OK, you're wrong. :)
Because the "user" in this case is more like "other developers" than
dumb "end users" ... though you need to keep in mind that the "Free" in
"Free Software" refers to people being able to change from "end users"
to "developers" in the inevitable cases where an original developer
doesn't have time for basics like bug fixing older software, or adding
essential capabilities that somehow got overlooked in the original
rush to market.
And yes, that is sometimes contrary to the goals of some folk who
build embedded products. It's the usual tradeoff of whether the
product goal is to solve end user problems or make money for some
vendor. Wearing my end user hat, the answer is clear.
- Dave
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH] Fix Freescale high-speed USB hostdependency
From: David Brownell @ 2006-08-01 15:38 UTC (permalink / raw)
To: linux-usb-devel; +Cc: linuxppc-dev, gregkh
In-Reply-To: <93F26879-ECEB-4513-AA77-EE7285DF7961@kernel.crashing.org>
On Thursday 20 July 2006 5:59 am, Kumar Gala wrote:
> >
> > -#ifdef CONFIG_PPC_83xx
> > +#ifdef CONFIG_MPC834x
So at the end of all that discussion, was there a USB patch to merge?
If so, I don't see one in my mail folder.
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH] Fix Freescale high-speed USB hostdependency
From: Kumar Gala @ 2006-08-01 16:39 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, linux-usb-devel, gregkh
In-Reply-To: <200608010838.08139.david-b@pacbell.net>
On Aug 1, 2006, at 10:38 AM, David Brownell wrote:
> On Thursday 20 July 2006 5:59 am, Kumar Gala wrote:
>
>>>
>>> -#ifdef CONFIG_PPC_83xx
>>> +#ifdef CONFIG_MPC834x
>
> So at the end of all that discussion, was there a USB patch to merge?
> If so, I don't see one in my mail folder.
Not on this side of things. If we clean up the CONFIG_PPC stuff I'll
push that through the PPC maintainer. There was a patch for gadget
support for the controller, but not sure if you handle that or not.
- k
^ permalink raw reply
* [PATCH] turn on tigon3 support in maple_defconfig
From: Amos Waterland @ 2006-08-01 19:44 UTC (permalink / raw)
To: linuxppc-dev
I think that most people who use maple_defconfig are doing so for a JS21,
so it might make sense to turn Tigon3 support on by default.
Built and booted on a JS21.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
---
maple_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/configs/maple_defconfig b/arch/powerpc/configs/maple_defconfig
index 80a0db4..27b18ca 100644
--- a/arch/powerpc/configs/maple_defconfig
+++ b/arch/powerpc/configs/maple_defconfig
@@ -474,7 +474,7 @@ CONFIG_E1000=y
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
-# CONFIG_TIGON3 is not set
+CONFIG_TIGON3=y
# CONFIG_BNX2 is not set
# CONFIG_MV643XX_ETH is not set
^ permalink raw reply related
* Re: DMA buffer synchronisation with ioremap()
From: Lee Revell @ 2006-08-01 19:51 UTC (permalink / raw)
To: Phil.Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <1154351427.3203.59.camel@toby.int.avalon.com.au>
On Mon, 2006-07-31 at 22:40 +0930, Phil Nitschke wrote:
> (I go no replies last week, so I'll try again, with less explanation...)
>
> If I master a DMA from a PCI device into a main memory buffer allocated
> with dma_alloc_noncoherent(), I need to synchronise the destination
> buffer using dma_sync_single_range_for_xxx() before and after the DMA.
>
> But if the buffer is a very large chunk of memory (reserved at boot
> time) which has been ioremap()-ed into the virtual address space, do I
> need to still synchronise that memory?
Maybe it's a better question for the linux-kernel list?
Lee
^ permalink raw reply
* RFC: Location for Device Tree Sources?
From: Jon Loeliger @ 2006-08-01 20:32 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Folks,
Where should we place the sources for the OF Flat Device
Tree source files? They used to be in U-Boot, but that
isn't happening any more.
One semi-obvious place would be to co-locate them with
their corresponding Linux arch/powerpc/platform directory.
Another would be to have a new directory full of them
under, say, arch/powerpc/devtrees or so.
Are there other suggestions or better ideas?
Thanks,
jdl
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Guennadi Liakhovetski @ 2006-08-01 21:00 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154464346.19994.4.camel@cashmere.sps.mot.com>
On Tue, 1 Aug 2006, Jon Loeliger wrote:
> Folks,
>
> Where should we place the sources for the OF Flat Device
> Tree source files? They used to be in U-Boot, but that
> isn't happening any more.
>
> One semi-obvious place would be to co-locate them with
> their corresponding Linux arch/powerpc/platform directory.
> Another would be to have a new directory full of them
> under, say, arch/powerpc/devtrees or so.
>
> Are there other suggestions or better ideas?
Mark A. Greer in his patch to port sandpoint to arch/powerpc put
sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Matthew McClintock @ 2006-08-01 21:01 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <Pine.LNX.4.60.0608012258040.4041@poirot.grange>
On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
>
> Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
I believe in his latest patches he removed this part. The device trees
were not included at all and he left this point open for discussion.
-Matthew
^ permalink raw reply
* [BUG] ibm_emac: kernel panic with CONFIG_SLOB=y
From: Karol Lewandowski @ 2006-08-01 20:40 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
Hi,
I'm getting reproductible kernel panic when I use smaller SLOB
allocator (instead of SLAB). This is reproductible but very randomly
-- sometimes it happens during bootup, sometimes few minutes later.
Hardware is custom board with IBM405EP (very close to Bubingna, just
no RTC):
# cat /proc/cpuinfo
processor : 0
cpu : 405EP
clock : 200MHz
revision : 9.80 (pvr 5121 0950)
bogomips : 199.47
machine : MagicBox
plb bus clock : 100MHz
pci bus clock : 25MHz
Enabling SLAB instead of SLOB fixes this, so I assume this is driver
issue.
Full dmesg attached:
Linux version 2.6.17-magicbox2 (builder@riddly) (gcc version 3.4.5) #2 Tue Aug 1 20:58:00 CEST 2006
MagicBox port (C) 2005 Karol Lewandowski <kl@jasmine.eu.org>
Built 1 zonelists
Kernel command line: console=ttyS0,115200 root=/dev/ram rw
PID hash table entries: 256 (order: 8, 1024 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 28272k available (1544k kernel code, 508k data, 100k init, 0k highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd
Freeing initrd memory: 2020k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
TC classifier action (bugs to netdev@vger.kernel.org cc hadi@cyberus.ca)
NET: Registered protocol family
IP route cache hash table entries: 256 (order: -2, 1024 bytes)
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 1024 bind 512)
TCP reno registered
squashfs: version 3.0 (2006/03/15) Phillip Lougher
Initializing Cryptographic API
io scheduler noop registered (default)
Software Watchdog Timer: 0.07 initialized. soft_noboot=0 soft_margin=60 sec (nowayout= 0)
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
RAMDISK driver initialized: 4 RAM disks of 8192K size 1024 blocksize
PPC 4xx OCP EMAC driver, version 3.54
mal0: initialized, 4 TX channels, 2 RX channels
eth0: emac0, MAC 00:50:c2:1e:af:fe
eth0: found Generic MII PHY (0x00)
emac1: reset timeout
emac1: can't find PHY!
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Magically mapped flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
Magically mapped flash: Swapping erase regions for broken CFI table.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 4 MTD partitions on "Magically mapped flash":
0x00000000-0x000e0000 : "kernel"
0x000e0000-0x003a0000 : "ramdisk"
0x003a0000-0x003c0000 : "persistent"
0x003c0000-0x00400000 : "bootloader"
i2c /dev entries driver
IBM IIC driver v2.1
ibm-iic0: using standard (100 kHz) mode
u32 classifier
Actions configured
GRE over IPv4 tunneling driver
ip_conntrack version 2.4 (256 buckets, 2048 max) - 236 bytes per conntrack
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Bridge firewalling registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
RAMDISK: squashfs filesystem found at block 0
RAMDISK: Loading 2017KiB [1 disk] into ram disk...
VFS: Mounted root (squashfs filesystem) readonly.
Freeing unused kernel memory: 100k init
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C000BEF8 LR: C00D247C CTR: 00000006
REGS: c1993d80 TRAP: 0300 Not tainted (2.6.17-magicbox2)
MSR: 00029030 <EE,ME,IR,DR> CR: 44000024 XER: 20000000
DAR: FFFFFFFE, DSISR: 00000000
TASK = c01ef000[331] 'echo' THREAD: c1992000
GPR00: 00000006 C1993E30 C01EF000 C19D1828 FFFFFFFA 00000026 C19D1824 C19D1866
GPR08: 00000000 C19D182A 00000001 00000000 42000028 70000000 00000001 10080000
GPR16: 00000000 30014C34 00000000 30000000 00000000 00000000 00000020 00000000
GPR24: C1C7D8A4 00000001 0000003C 0000003E 00000008 C19D1770 C1951680 C1C7D800
NIP [C000BEF8] cacheable_memcpy+0x64/0x108
LR [C00D247C] emac_poll_rx+0x150/0x6e8
Call Trace:
[C1993E30] [C00D244C] emac_poll_rx+0x120/0x6e8 (unreliable)
[C1993E80] [C00D0508] mal_poll+0x90/0x284
[C1993EB0] [C00F9CB0] net_rx_action+0xb4/0x1b0
[C1993EE0] [C001D0C4] __do_softirq+0x64/0xe0
[C1993F00] [C0007AC0] do_softirq+0x50/0x74
[C1993F10] [C001D1E0] irq_exit+0x38/0x48
[C1993F20] [C0007A5C] do_IRQ+0x64/0x78
[C1993F40] [C0003478] ret_from_except+0x0/0x18
Instruction dump:
70080003 7ca02850 7d0903a6 41a20018 89240004 99260004 38840001 38c60001
4200fff0 5400f0bf 7c0903a6 41820010 <85240004> 95260004 4200fff8 54a0d97f
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
thanks
--
This signature intentionally says nothing.
^ permalink raw reply
* Re: [BUG] ibm_emac: kernel panic with CONFIG_SLOB=y
From: Eugene Surovegin @ 2006-08-01 22:13 UTC (permalink / raw)
To: Karol Lewandowski; +Cc: linuxppc-embedded
In-Reply-To: <20060801204011.GB1754@riddly.domek.prywatny>
On Tue, Aug 01, 2006 at 10:40:11PM +0200, Karol Lewandowski wrote:
> Hi,
>
> I'm getting reproductible kernel panic when I use smaller SLOB
> allocator (instead of SLAB). This is reproductible but very randomly
> -- sometimes it happens during bootup, sometimes few minutes later.
>
> Hardware is custom board with IBM405EP (very close to Bubingna, just
> no RTC):
>
> # cat /proc/cpuinfo
> processor : 0
> cpu : 405EP
> clock : 200MHz
> revision : 9.80 (pvr 5121 0950)
> bogomips : 199.47
> machine : MagicBox
> plb bus clock : 100MHz
> pci bus clock : 25MHz
>
> Enabling SLAB instead of SLOB fixes this, so I assume this is driver
> issue.
This is probably the same issue I had with SLAB debugging.
In short, those allocators aren't compatible with non-coherent cache
archs (like 4xx), because driver assumes at least L1 cache line
alignment for all allocated memory.
For more info, you can read this post:
http://ozlabs.org/pipermail/linuxppc-embedded/2006-February/022087.html
--
Eugene
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Michael Ellerman @ 2006-08-01 23:26 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, PaulMackerras
In-Reply-To: <1154379714.29826.396.camel@goblue>
[-- Attachment #1: Type: text/plain, Size: 668 bytes --]
On Mon, 2006-07-31 at 16:01 -0500, Jake Moilanen wrote:
> Here's version 3 which addresses all of Michael's comments.
Looks good, nice one.
I was thinking about disable, can you give us any more details on the
firmware bug that is blocking that?
I'm not sure what disable really needs to do, but I think drivers might
expect it to set dev->irq back to the LSI value, even if we don't free
anything internally. Not sure.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [BUG] ibm_emac: kernel panic with CONFIG_SLOB=y
From: Karol Lewandowski @ 2006-08-01 23:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060801221342.GA13171@gate.ebshome.net>
On Tue, Aug 01, 2006 at 03:13:42PM -0700, Eugene Surovegin wrote:
> On Tue, Aug 01, 2006 at 10:40:11PM +0200, Karol Lewandowski wrote:
> > Hi,
> >
> > I'm getting reproductible kernel panic when I use smaller SLOB
> > allocator (instead of SLAB). This is reproductible but very randomly
> > -- sometimes it happens during bootup, sometimes few minutes later.
> >
> > Hardware is custom board with IBM405EP (very close to Bubingna, just
> > no RTC):
> >
> > # cat /proc/cpuinfo
> > processor : 0
> > cpu : 405EP
> > clock : 200MHz
> > revision : 9.80 (pvr 5121 0950)
> > bogomips : 199.47
> > machine : MagicBox
> > plb bus clock : 100MHz
> > pci bus clock : 25MHz
> >
> > Enabling SLAB instead of SLOB fixes this, so I assume this is driver
> > issue.
>
> This is probably the same issue I had with SLAB debugging.
With SLAB debugging I get oops even faster:
Linux version 2.6.17-magicbox2 (builder@riddly) (gcc version 3.4.5) #3 Wed Aug 2 01:14:21 CEST 2006
MagicBox port (C) 2005 Karol Lewandowski <kl@jasmine.eu.org>
Built 1 zonelists
Kernel command line: console=ttyS0,115200 root=/dev/ram rw
PID hash table entries: 256 (order: 8, 1024 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 28252k available (1560k kernel code, 508k data, 104k init, 0k highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd
Freeing initrd memory: 2020k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
TC classifier action (bugs to netdev@vger.kernel.org cc hadi@cyberus.ca)
NET: Registered protocol family 2
IP route cache hash table entries: 256 (order: -2, 1024 bytes)
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 1024 bind 512)
TCP reno registered
squashfs: version 3.0 (2006/03/15) Phillip Lougher
Initializing Cryptographic API
io scheduler noop registered (default)
Software Watchdog Timer: 0.07 initialized. soft_noboot=0 soft_margin=60 sec (nowayout= 0)
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
RAMDISK driver initialized: 4 RAM disks of 8192K size 1024 blocksize
PPC 4xx OCP EMAC driver, version 3.54
mal0: initialized, 4 TX channels, 2 RX channels
eth0: emac0, MAC 00:50:c2:1e:af:fe
eth0: found Generic MII PHY (0x00)
emac1: reset timeout
emac1: can't find PHY!
slab error in cache_free_debugcheck(): cache `size-2048': double free, or memory outside object was overwritten
Call Trace:
[C1D95DC0] [C0009988] show_stack+0x58/0x180 (unreliable)
[C1D95DF0] [C004E92C] __slab_error+0x2c/0x3c
[C1D95E00] [C004F0BC] cache_free_debugcheck+0x150/0x2a8
[C1D95E30] [C004FDC0] kfree+0x74/0xf0
[C1D95E50] [C01FAB40] emac_probe+0x6a0/0x6b8
[C1D95E90] [C000C884] ocp_device_probe+0x38/0x60
[C1D95EA0] [C00CEAD8] driver_probe_device+0x64/0x108
[C1D95EC0] [C00CECA8] __driver_attach+0x80/0xe4
[C1D95EE0] [C00CDE30] bus_for_each_dev+0x54/0x94
[C1D95F10] [C00CED30] driver_attach+0x24/0x34
[C1D95F20] [C00CE424] bus_add_driver+0x74/0x148
[C1D95F40] [C00CF2C0] driver_register+0xa4/0xb8
[C1D95F70] [C000C9D8] ocp_register_driver+0x28/0x38
[C1D95F80] [C01FAB90] emac_init+0x38/0x6c
[C1D95F90] [C0002440] init+0xa4/0x27c
[C1D95FF0] [C0005054] kernel_thread+0x44/0x60
c1dc60bc: redzone 1:0x0, redzone 2:0x0.
kernel BUG in cache_free_debugcheck at mm/slab.c:2640!
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: C004F16C LR: C004F130 CTR: 00000000
REGS: c1d95d50 TRAP: 0700 Not tainted (2.6.17-magicbox2)
MSR: 00021030 <ME,IR,DR> CR: 44004022 XER: 20000000
TASK = c1d93ae0[1] 'swapper' THREAD: c1d94000
GPR00: 00000001 C1D95E00 C1D93AE0 C1DC68C4 C1DC68C8 FFFFFFFF C00CC0C4 C01C0000
GPR08: C01C0DBF 0000001B C021536C 0000001C 00000000 00000000 01FFC700 00000000
GPR16: 00000001 00000001 FFFFFFFF 007FFF00 01FF609C 00000000 00000003 C1DC63A8
GPR24: C0223A80 C01FAB40 C0200000 C1DC6080 00000000 5A2CF071 C1DC60BC C0222A80
NIP [C004F16C] cache_free_debugcheck+0x200/0x2a8
LR [C004F130] cache_free_debugcheck+0x1c4/0x2a8
Call Trace:
[C1D95E00] [C004F100] cache_free_debugcheck+0x194/0x2a8 (unreliable)
[C1D95E30] [C004FDC0] kfree+0x74/0xf0
[C1D95E50] [C01FAB40] emac_probe+0x6a0/0x6b8
[C1D95E90] [C000C884] ocp_device_probe+0x38/0x60
[C1D95EA0] [C00CEAD8] driver_probe_device+0x64/0x108
[C1D95EC0] [C00CECA8] __driver_attach+0x80/0xe4
[C1D95EE0] [C00CDE30] bus_for_each_dev+0x54/0x94
[C1D95F10] [C00CED30] driver_attach+0x24/0x34
[C1D95F20] [C00CE424] bus_add_driver+0x74/0x148
[C1D95F40] [C00CF2C0] driver_register+0xa4/0xb8
[C1D95F70] [C000C9D8] ocp_register_driver+0x28/0x38
[C1D95F80] [C01FAB90] emac_init+0x38/0x6c
[C1D95F90] [C0002440] init+0xa4/0x27c
[C1D95FF0] [C0005054] kernel_thread+0x44/0x60
Instruction dump:
7c0bf050 7f804b96 801f001c 7c00e010 38000000 7c000114 0f000000 7d29e1d6
7d6b4a14 7fcb5a78 312bffff 7c095910 <0f000000> 801f0018 700b0200 41a20024
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 180 seconds..
> In short, those allocators aren't compatible with non-coherent cache
> archs (like 4xx), because driver assumes at least L1 cache line
> alignment for all allocated memory.
>
> For more info, you can read this post:
>
> http://ozlabs.org/pipermail/linuxppc-embedded/2006-February/022087.html
This is all black magic for me, all I can do is to suggest blacklisting
these features on certain archs, i.e. adjusting Kconfigs:
--- kernel-2.6-2.6.17-magicbox2/init/Kconfig.orig 2006-08-02 01:24:04.000000000 +0200
+++ kernel-2.6-2.6.17-magicbox2/init/Kconfig 2006-08-02 01:25:49.000000000 +0200
@@ -367,7 +367,7 @@
config SLAB
default y
- bool "Use full SLAB allocator" if EMBEDDED
+ bool "Use full SLAB allocator" if (EMBEDDED && !4xx)
help
Disabling this replaces the advanced SLAB allocator and
kmalloc support with the drastically simpler SLOB allocator.
... and doing something like that for every architecture without
coherent cache (and SLAB debugging).
I'm not that sure that it's good way to go, though.
thanks
--
This signature intentionally says nothing.
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Mark A. Greer @ 2006-08-02 0:35 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <1154466094.11069.6.camel@localhost>
On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> >
> > Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
>
> I believe in his latest patches he removed this part. The device trees
> were not included at all and he left this point open for discussion.
That's correct.
TBH, I think its wrong to keep them in the kernel source at all--yes,
the same argument could be made for arch/powerpc/boot but that's been
settled.
We already have dtc kept externally to the kernel source. Why not
keep a single site where all things necessary to powerpc linux are kept?
It could house dtc, the dt attach tool, and all the dt source files.
I doesn't matter to me where as long as its highly available and has
reasonable bandwidth. jdl.com? source.mvista.com? penguinppc.org?
other?
Mark
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Mark A. Greer @ 2006-08-02 0:42 UTC (permalink / raw)
To: Matthew McClintock, linuxppc-dev@ozlabs.org,
Guennadi Liakhovetski
In-Reply-To: <20060802003504.GA20439@mag.az.mvista.com>
On Tue, Aug 01, 2006 at 05:35:04PM -0700, Mark A. Greer wrote:
> I doesn't matter to me where as long as its highly available and has
> reasonable bandwidth. jdl.com? source.mvista.com? penguinppc.org?
> other?
Er, forgot the obvious: ozlabs.org?
Mark
^ permalink raw reply
* [PATCH] Fix loop logic in irq_alloc_virt()
From: Michael Ellerman @ 2006-08-02 0:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
There's a bug in irq_alloc_virt() if it's asked for more than 1 interrupt,
if it can't find a slot it might look past the end of the irq_map.
I think this is a fix. No one in the kernel actually calls this with
count > 1, so it's not critical.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/irq.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
Index: to-merge/arch/powerpc/kernel/irq.c
===================================================================
--- to-merge.orig/arch/powerpc/kernel/irq.c
+++ to-merge/arch/powerpc/kernel/irq.c
@@ -728,7 +728,6 @@ unsigned int irq_alloc_virt(struct irq_h
{
unsigned long flags;
unsigned int i, j, found = NO_IRQ;
- unsigned int limit = irq_virq_count - count;
if (count == 0 || count > (irq_virq_count - NUM_ISA_INTERRUPTS))
return NO_IRQ;
@@ -745,14 +744,16 @@ unsigned int irq_alloc_virt(struct irq_h
/* Look for count consecutive numbers in the allocatable
* (non-legacy) space
*/
- for (i = NUM_ISA_INTERRUPTS; i <= limit; ) {
- for (j = i; j < (i + count); j++)
- if (irq_map[j].host != NULL) {
- i = j + 1;
- continue;
- }
- found = i;
- break;
+ for (i = NUM_ISA_INTERRUPTS, j = 0; i < irq_virq_count; i++) {
+ if (irq_map[i].host != NULL)
+ j = 0;
+ else
+ j++;
+
+ if (j == count) {
+ found = i - count + 1;
+ break;
+ }
}
if (found == NO_IRQ) {
spin_unlock_irqrestore(&irq_big_lock, flags);
^ permalink raw reply
* [PATCH] Make doc comments extractable
From: Michael Ellerman @ 2006-08-02 1:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
We don't have much in the way of doc comments, but some of those we do have
don't work because they start with "/***" or "/*", not "/**" which is what
kernel-doc requires.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/crash_dump.c | 2 +-
arch/powerpc/sysdev/i8259.c | 2 +-
include/asm-powerpc/irq.h | 24 ++++++++++++------------
include/asm-powerpc/prom.h | 8 ++++----
4 files changed, 18 insertions(+), 18 deletions(-)
Index: to-merge/arch/powerpc/kernel/crash_dump.c
===================================================================
--- to-merge.orig/arch/powerpc/kernel/crash_dump.c
+++ to-merge/arch/powerpc/kernel/crash_dump.c
@@ -80,7 +80,7 @@ static int __init parse_savemaxmem(char
}
__setup("savemaxmem=", parse_savemaxmem);
-/*
+/**
* copy_oldmem_page - copy one page from "oldmem"
* @pfn: page frame number to be copied
* @buf: target memory address for the copy; this can be in kernel address
Index: to-merge/arch/powerpc/sysdev/i8259.c
===================================================================
--- to-merge.orig/arch/powerpc/sysdev/i8259.c
+++ to-merge/arch/powerpc/sysdev/i8259.c
@@ -224,7 +224,7 @@ static struct irq_host_ops i8259_host_op
.xlate = i8259_host_xlate,
};
-/****
+/**
* i8259_init - Initialize the legacy controller
* @node: device node of the legacy PIC (can be NULL, but then, it will match
* all interrupts, so beware)
Index: to-merge/include/asm-powerpc/irq.h
===================================================================
--- to-merge.orig/include/asm-powerpc/irq.h
+++ to-merge/include/asm-powerpc/irq.h
@@ -137,7 +137,7 @@ struct irq_map_entry {
extern struct irq_map_entry irq_map[NR_IRQS];
-/***
+/**
* irq_alloc_host - Allocate a new irq_host data structure
* @node: device-tree node of the interrupt controller
* @revmap_type: type of reverse mapping to use
@@ -159,14 +159,14 @@ extern struct irq_host *irq_alloc_host(u
irq_hw_number_t inval_irq);
-/***
+/**
* irq_find_host - Locates a host for a given device node
* @node: device-tree node of the interrupt controller
*/
extern struct irq_host *irq_find_host(struct device_node *node);
-/***
+/**
* irq_set_default_host - Set a "default" host
* @host: default host pointer
*
@@ -178,7 +178,7 @@ extern struct irq_host *irq_find_host(st
extern void irq_set_default_host(struct irq_host *host);
-/***
+/**
* irq_set_virq_count - Set the maximum number of virt irqs
* @count: number of linux virtual irqs, capped with NR_IRQS
*
@@ -188,7 +188,7 @@ extern void irq_set_default_host(struct
extern void irq_set_virq_count(unsigned int count);
-/***
+/**
* irq_create_mapping - Map a hardware interrupt into linux virq space
* @host: host owning this hardware interrupt or NULL for default host
* @hwirq: hardware irq number in that host space
@@ -202,13 +202,13 @@ extern unsigned int irq_create_mapping(s
irq_hw_number_t hwirq);
-/***
+/**
* irq_dispose_mapping - Unmap an interrupt
* @virq: linux virq number of the interrupt to unmap
*/
extern void irq_dispose_mapping(unsigned int virq);
-/***
+/**
* irq_find_mapping - Find a linux virq from an hw irq number.
* @host: host owning this hardware interrupt
* @hwirq: hardware irq number in that host space
@@ -221,7 +221,7 @@ extern unsigned int irq_find_mapping(str
irq_hw_number_t hwirq);
-/***
+/**
* irq_radix_revmap - Find a linux virq from a hw irq number.
* @host: host owning this hardware interrupt
* @hwirq: hardware irq number in that host space
@@ -232,7 +232,7 @@ extern unsigned int irq_find_mapping(str
extern unsigned int irq_radix_revmap(struct irq_host *host,
irq_hw_number_t hwirq);
-/***
+/**
* irq_linear_revmap - Find a linux virq from a hw irq number.
* @host: host owning this hardware interrupt
* @hwirq: hardware irq number in that host space
@@ -247,7 +247,7 @@ extern unsigned int irq_linear_revmap(st
-/***
+/**
* irq_alloc_virt - Allocate virtual irq numbers
* @host: host owning these new virtual irqs
* @count: number of consecutive numbers to allocate
@@ -261,7 +261,7 @@ extern unsigned int irq_alloc_virt(struc
unsigned int count,
unsigned int hint);
-/***
+/**
* irq_free_virt - Free virtual irq numbers
* @virq: virtual irq number of the first interrupt to free
* @count: number of interrupts to free
@@ -300,7 +300,7 @@ extern unsigned int irq_of_parse_and_map
/* -- End OF helpers -- */
-/***
+/**
* irq_early_init - Init irq remapping subsystem
*/
extern void irq_early_init(void);
Index: to-merge/include/asm-powerpc/prom.h
===================================================================
--- to-merge.orig/include/asm-powerpc/prom.h
+++ to-merge/include/asm-powerpc/prom.h
@@ -259,7 +259,7 @@ struct of_irq {
u32 specifier[OF_MAX_IRQ_SPEC]; /* Specifier copy */
};
-/***
+/**
* of_irq_map_init - Initialize the irq remapper
* @flags: flags defining workarounds to enable
*
@@ -272,7 +272,7 @@ struct of_irq {
extern void of_irq_map_init(unsigned int flags);
-/***
+/**
* of_irq_map_raw - Low level interrupt tree parsing
* @parent: the device interrupt parent
* @intspec: interrupt specifier ("interrupts" property of the device)
@@ -292,7 +292,7 @@ extern int of_irq_map_raw(struct device_
const u32 *addr, struct of_irq *out_irq);
-/***
+/**
* of_irq_map_one - Resolve an interrupt for a device
* @device: the device whose interrupt is to be resolved
* @index: index of the interrupt to resolve
@@ -305,7 +305,7 @@ extern int of_irq_map_raw(struct device_
extern int of_irq_map_one(struct device_node *device, int index,
struct of_irq *out_irq);
-/***
+/**
* of_irq_map_pci - Resolve the interrupt for a PCI device
* @pdev: the device whose interrupt is to be resolved
* @out_irq: structure of_irq filled by this function
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Josh Boyer @ 2006-08-02 1:12 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Guennadi Liakhovetski, linuxppc-dev@ozlabs.org
In-Reply-To: <20060802003504.GA20439@mag.az.mvista.com>
On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> > On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> > >
> > > Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> > > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> >
> > I believe in his latest patches he removed this part. The device trees
> > were not included at all and he left this point open for discussion.
>
> That's correct.
>
> TBH, I think its wrong to keep them in the kernel source at all--yes,
> the same argument could be made for arch/powerpc/boot but that's been
> settled.
Sorry, I have to disagree. We're talking about device tree _source_
files here. I believe they should be included in the kernel source.
Where that is, I don't have a particularly strong argument but they
should be included.
>
> We already have dtc kept externally to the kernel source. Why not
> keep a single site where all things necessary to powerpc linux are kept?
> It could house dtc, the dt attach tool, and all the dt source files.
I think hosting the dtc, the dt attach tool, and pre-built dtb files for
each platform in one spot would be a good idea.
josh
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Grant Likely @ 2006-08-02 3:20 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <1154481150.2676.3.camel@vader.jdub.homelinux.org>
On 8/1/06, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
> On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> > On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> > > On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> > > >
> > > > Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> > > > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> > >
> > > I believe in his latest patches he removed this part. The device trees
> > > were not included at all and he left this point open for discussion.
> >
> > That's correct.
> >
> > TBH, I think its wrong to keep them in the kernel source at all--yes,
> > the same argument could be made for arch/powerpc/boot but that's been
> > settled.
>
> Sorry, I have to disagree. We're talking about device tree _source_
> files here. I believe they should be included in the kernel source.
> Where that is, I don't have a particularly strong argument but they
> should be included.
I have to second that opinion. The device tree is absolutely integral
with the rest of the code/drivers needed to support a board. I say
there are stronger arguments for keeping the dts files in the kernel
source than there are for the boot wrapper.
powerpc/boot/dts makes a lot of sense to me.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: RFC: Location for Device Tree Sources?
From: Li Yang-r58472 @ 2006-08-02 3:35 UTC (permalink / raw)
To: Mark A. Greer, McClintock Matthew-R56630
Cc: linuxppc-dev, Guennadi Liakhovetski
In-Reply-To: <20060802003504.GA20439@mag.az.mvista.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On =
Behalf
Of Mark A.
> Greer
> Sent: Wednesday, August 02, 2006 8:35 AM
> To: McClintock Matthew-R56630
> Cc: linuxppc-dev@ozlabs.org; Guennadi Liakhovetski
> Subject: Re: RFC: Location for Device Tree Sources?
>=20
> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> > On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> > >
> > > Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> > > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> >
> > I believe in his latest patches he removed this part. The device
trees
> > were not included at all and he left this point open for discussion.
>=20
> That's correct.
>=20
> TBH, I think its wrong to keep them in the kernel source at all--yes,
> the same argument could be made for arch/powerpc/boot but that's been
> settled.
>=20
> We already have dtc kept externally to the kernel source. Why not
> keep a single site where all things necessary to powerpc linux are
kept?
> It could house dtc, the dt attach tool, and all the dt source files.
We already have gcc out of the kernel source, but we need to have all
the source code in. :) I strongly agree to keep dts in tree, or it
will be hard to find out what the driver really does.
>=20
> I doesn't matter to me where as long as its highly available and has
> reasonable bandwidth. jdl.com? source.mvista.com? penguinppc.org?
> other?
>=20
-Leo
^ permalink raw reply
* Re: Booting Linux Kernel without bootloader
From: Parav Pandit @ 2006-08-02 3:49 UTC (permalink / raw)
To: Milton Miller, cthomas, linuxppc-embedded
In-Reply-To: <11153922785140e0f761.861021530.miltonm@bga.com>
--- Milton Miller <miltonm@bga.com> wrote:
> On Tue Jul 25 2006 05:30:39 PM CDT, Clint Thomas
> wrote:
>
> > Basically, the system I want linux running on does
> not require the
> > initialization of hardware that U-boot provides,
> or at least it does not
> > need it to boot the linux kernel. I want to load
> an uncompressed linux
> > kernel into memory and start the execution of the
> kernel, without using
> > any kind of bootloader. Is this possible? Or does
> linux need some kind
> > of firmware or other software to tell it to start
> executing? Thanks for
> > any info you might have.
>
> To run a powerpc (not ppc, which will be removed)
> kernel, in addition to the uncompressed kernel you
> will need to supply a device tree structure, point
> r3 to it, zero r5, and set r4 to the load address
> (zero as you have described). See
> Documentation/powerpc/booting-without-of.txt for
> details. Then arrange for you processor to start
> executing at address 0. Note that /vmlinux has an
> elf header, you can use objcopy to remove it or
> adjust r4 and your start point; the kernel will copy
> itself to 0, clear bss and set up the stack. The
> device tree structure must be placed above the bss
> space in memory, not just the initialized data.
Linux kernel does the bss cleaning after
start_kernel() even though boot loader does it. So one
step less.
Parav
>
> milton
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Booting Linux Kernel without bootloader
From: Grant Likely @ 2006-08-02 4:17 UTC (permalink / raw)
To: Clint Thomas; +Cc: linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA240952915DF66@bluefin.Soneticom.local>
On 7/25/06, Clint Thomas <cthomas@soneticom.com> wrote:
>
>
> Hey guys,
>
> I have gone through the Linuxppc embedded and dev lists for information
> related to what I am trying to do, but was unable to find exactly what i'm
> looking for.
>
> Basically, the system I want linux running on does not require the
> initialization of hardware that U-boot provides, or at least it does not
> need it to boot the linux kernel. I want to load an uncompressed linux
> kernel into memory and start the execution of the kernel, without using any
> kind of bootloader. Is this possible? Or does linux need some kind of
> firmware or other software to tell it to start executing? Thanks for any
> info you might have.
Loading a kernel into memory and starting execution *is* a boot loader. :)
You could use the bootwrapper that is in the kernel source tree
(zImage). If a zImage's entry point is at the execution entry point,
then it will start the Linux kernel correctly. However, it is still a
compressed image.
If you *really* need an uncompressed image, I would start with the
bootwrapper and hack it to work with an non-gzipped kernel image.
However, why do you want to do it this way? You probably won't gain
much in boot time and it will be more difficult to maintain.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] fix PMU initialization on pseries lpar
From: Sonny Rao @ 2006-08-02 4:20 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
We should not be calling power4_enable_pmcs() in
pseries_lpar_enable_pmcs(); just doing the hypercall is sufficient.
Prior to 2.6.15 we did not call power4_enable_pmcs() for an lpar.
power4_enable_pmcs() tries to read the hid0 register which is no
longer legal for an lpar in newer Power processors.
--- a/arch/powerpc/platforms/pseries/setup.c 2006-04-23 01:45:09.000000000 -0500
+++ b/arch/powerpc/platforms/pseries/setup.c~pmcfix 2006-08-01 23:12:39.000000000 -0500
@@ -182,8 +182,6 @@ static void pseries_lpar_enable_pmcs(voi
{
unsigned long set, reset;
- power4_enable_pmcs();
-
set = 1UL << 63;
reset = 0;
plpar_hcall_norets(H_PERFMON, set, reset);
^ permalink raw reply
* Re: [PATCH] Fix loop logic in irq_alloc_virt()
From: Michael Ellerman @ 2006-08-02 4:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060802004852.C66FB67B7F@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]
On Wed, 2006-08-02 at 10:48 +1000, Michael Ellerman wrote:
> There's a bug in irq_alloc_virt() if it's asked for more than 1 interrupt,
> if it can't find a slot it might look past the end of the irq_map.
>
> I think this is a fix. No one in the kernel actually calls this with
> count > 1, so it's not critical.
> Index: to-merge/arch/powerpc/kernel/irq.c
> ===================================================================
> --- to-merge.orig/arch/powerpc/kernel/irq.c
> +++ to-merge/arch/powerpc/kernel/irq.c
> @@ -745,14 +744,16 @@ unsigned int irq_alloc_virt(struct irq_h
> /* Look for count consecutive numbers in the allocatable
> * (non-legacy) space
> */
> - for (i = NUM_ISA_INTERRUPTS; i <= limit; ) {
> - for (j = i; j < (i + count); j++)
> - if (irq_map[j].host != NULL) {
> - i = j + 1;
> - continue;
> - }
> - found = i;
> - break;
To be clear: the bug is that the continue affects the inner for loop,
not the outer one, so i becomes j + 1 and then we continue the inner
loop without checking if i is still <= limit.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ 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