* Re: [NEWBIE] Interrupt-problem mpc5200
From: Matt Sealey @ 2007-09-14 13:29 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, S. Fricke
In-Reply-To: <fa686aa40709111205n5d9f9654m6f2b96d468dfd017@mail.gmail.com>
Grant!
I have a newbie question which I never had properly answered. On the
MPC52xx and specifically regarding the device tree, how are interrupt
numbers assigned?
On Efika (and in the DT docs) it's basically the X Y Z where X is the
type (critical, main, peripheral, sdma), Y is the number of the
interrupt, and Z is it's sense level.
However while X and Z are easy to derive, how do you work out what Y
is meant to be given a device? Is it a bit number in the interrupt
register, or the value of the encoded interrupt register or something
else algorithmically determined?
I am just finding the code in Linux that derives this number fairly
elusive (the irq setup function for the mpc52xx platform is truly
sparse, irq_of_find_and_map isn't much help). Maybe I am just not
looking in the right place but not being an MPC52xx PIC Expert I
wouldn't even know where to start...
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Grant Likely wrote:
> On 9/11/07, S. Fricke <silvio.fricke@googlemail.com> wrote:
>> Hello,
>>
>>>> [...]
>>>> intr = mpc52xx_find_and_map("mpc52xx-pic");
>>>> if(!intr) {
>>>> panic(__FILE__ ": mpc52xx-pic - MAP failed");
>>>> }
>>>>
>>>> set_irq_chip(MPC52xx_IRQ2, &my_irq_chip);
>>> You probably don't want to do this (unless you are cascading IRQs to
>>> custom external hardware). All you should need is the call to
>>> request_irq() to register your irq handler, and code in your ISR
>>> handler to clear the interrupt condition.
>>>
>>> You do *NOT* want to program the interrupt controller directly. The
>>> mpc5200 interrupt controller already has a driver. Don't go twiddling
>>> the registers manually.
>> OK!
>>
>> I have tried it before and i get a "-ENOSYS" returned.
>>
>> My code was/is now:
>> --==>
>> request_irq(MPC52xx_IRQ2, intmod_isr, IRQF_DISABLED , "intmod",
>> INTMOD_IRQ_BOARD);
>> <==--
>>
>> I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
>> "setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
>>
>> THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per copy
>> paste), but mpc52xx is (now) a powerpc-arch. What is the desired value for
>> IRQ-2 on a mpc5200b?
>
> The irq number you pass into request_irq is a system-wide irq number;
> it doesn't necessarily map directly onto the MPC52xx irq number.
> Typically, you'd have a node for your device in the device tree which
> has a phandle back to the interrupt node and you would use
> irq_of_parse_and_map() to map it back to a system-wide irq number.
>
> Otherwise, you need to call of_irq_map_raw with the pointer to the
> 52xx interrupt controller node and the interrupt number in the form
> expected by the device tree. (But adding a device tree node for your
> device is far easier).
>
> Cheers,
> g.
>
^ permalink raw reply
* Re: [PATCH 04/22] [POWERPC] Update mpc7448hpc2 device tree to be compatible for tsi109 chip
From: Kumar Gala @ 2007-09-14 13:28 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <7a05156b54e7de9c2c24a146e7826699@kernel.crashing.org>
On Sep 13, 2007, at 5:54 PM, Segher Boessenkool wrote:
>> Update mpc7448hpc2 device tree to be compatible for tsi109 chip.
>
> Do all those boards have a tsi109? If not, this patch is
> incorrect. If they do, is tsi109 actually backward-compatible
> to tsi108? That is, will a driver that knows about tsi108
> only work correctly on a tsi109?
I believe its a tsi108 and thus am going to drop this patch since I
agree with you. Unless Roy tells me otherwise.
> Also, all those names really should have a manufacturer
> prefix ("XXX,...").
More cleanup for someone :)
- k
^ permalink raw reply
* Re: [PATCH] adds support for Micrel KS8721BL PHY
From: Kumar Gala @ 2007-09-14 13:26 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-embedded
In-Reply-To: <1189761900.5113.8.camel@p60635-ste.ids.de>
On Sep 14, 2007, at 4:25 AM, Sergej Stepanov wrote:
> The patch adds the support for Micrel KS8721BL PHY
>
> Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
> --
Such patches should be sent to the netdev list.
- k
^ permalink raw reply
* Re: [PATCH 22/22] [POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE, register mmc_spi stub
From: Kumar Gala @ 2007-09-14 13:21 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <18154.32614.502824.264341@cargo.ozlabs.ibm.com>
On Sep 14, 2007, at 7:32 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> From: Anton Vorontsov <avorontsov@ru.mvista.com>
>>
>> mmc_spi already tested to work. When it will hit mainline
>> the only change that will be needed is replacing "spidev"
>> with "mmc_spi".
>
> That's a *remarkably* uninformative commit message. And what's the
> use of putting in something about "when it will hit mainline" when
> this is the point where it hits mainline?
Yeah, I was afraid of that when I glanced at Anton's patches.
I think the comment is in reference to a mainline SPI subsystem
change intended for 2.6.24.
- k
^ permalink raw reply
* Re: STK5200 pci_enable_device problem
From: Oliver Rutsch @ 2007-09-14 12:53 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <7B9A8FF57DBB524190E98CABF6E56F078FB151@itri.bte.mam.gov.tr>
Mustafa,
It would have been nice, if you would *NOT* repost my private mails I'd
send to you on the mailing list. At least you could have cut off my
footer from your mail!
As I thought that it is not of general interest I wrote directly to you
- but not too see my mails back again on the list. That's really bad style.
Bye,
--
Dipl. Ing. Oliver Rutsch
^ permalink raw reply
* Re: [PATCH 22/22] [POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE, register mmc_spi stub
From: Paul Mackerras @ 2007-09-14 12:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <11897177143496-git-send-email-galak@kernel.crashing.org>
Kumar Gala writes:
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> mmc_spi already tested to work. When it will hit mainline
> the only change that will be needed is replacing "spidev"
> with "mmc_spi".
That's a *remarkably* uninformative commit message. And what's the
use of putting in something about "when it will hit mainline" when
this is the point where it hits mainline?
Paul.
^ permalink raw reply
* Re: Section mismatch warning
From: Josh Boyer @ 2007-09-14 12:15 UTC (permalink / raw)
To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <12673863.post@talk.nabble.com>
On Fri, 14 Sep 2007 05:01:14 -0700 (PDT)
sivaji <rameshmrm@gmail.com> wrote:
>
> Hi,
> When compiling the kernel 2.6.23-rc4 for our custom board based on
> MPC8641, I got following warning messages
>
> WARNING: vmlinux.o(.text+0x169f6): Section mismatch: reference to
> .init.data:boot_command_line (between 'note_bootable_part' and
> 'pmac_restart')
> WARNING: vmlinux.o(.text+0x16a02): Section mismatch: reference to
> .init.data:boot_command_line (between 'note_bootable_part' and
> 'pmac_restart')
> WARNING: vmlinux.o(.text+0x16a12): Section mismatch: reference to
> .init.data:boot_command_line (between 'note_bootable_part' and
> 'pmac_restart')
>
> Give some idea to fix these warnings.
These should be fixed for 2.6.24
josh
^ permalink raw reply
* Section mismatch warning
From: sivaji @ 2007-09-14 12:01 UTC (permalink / raw)
To: linuxppc-dev
Hi,
When compiling the kernel 2.6.23-rc4 for our custom board based on
MPC8641, I got following warning messages
WARNING: vmlinux.o(.text+0x169f6): Section mismatch: reference to
.init.data:boot_command_line (between 'note_bootable_part' and
'pmac_restart')
WARNING: vmlinux.o(.text+0x16a02): Section mismatch: reference to
.init.data:boot_command_line (between 'note_bootable_part' and
'pmac_restart')
WARNING: vmlinux.o(.text+0x16a12): Section mismatch: reference to
.init.data:boot_command_line (between 'note_bootable_part' and
'pmac_restart')
Give some idea to fix these warnings.
by
Sivaji
--
View this message in context: http://www.nabble.com/Section-mismatch-warning-tf4442060.html#a12673863
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* RE: STK5200 pci_enable_device problem
From: Mustafa Cayır @ 2007-09-14 11:38 UTC (permalink / raw)
To: Oliver Rutsch; +Cc: linuxppc-embedded
Hi,
i get the latest kernel sources and u-boot sources directly=20
from the git archives from www.denx.de.
My kernel version is Linux-2.6.23-rc5-gaa8ddd08
u-boot version is U-Boot 1.2.0-ge251e00d-dirty
i use dtc compiler with following command:
dtc -O dtb -o tqm5200.dtb -b 0 tqm5200.dts
TQM5200 doesn't boot and gives following error. Any help would be =
approciated.
Thanks a lot.
=3D> run net_nfs_fdt
Using FEC ETHERNET device
TFTP from server 10.18.2.83; our IP address is 10.18.5.44
Filename 'uImage'.
Load address: 0x200000
Loading: =
#################################################################
###################################
done
Bytes transferred =3D 1461683 (164db3 hex)
Using FEC ETHERNET device
TFTP from server 10.18.2.83; our IP address is 10.18.5.44
Filename 'tqm5200.dtb'.
Load address: 0x400000
Loading: #
done
Bytes transferred =3D 3507 (db3 hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.23-rc5-gaa8ddd08
Created: 2007-09-14 6:44:52 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1461619 Bytes =3D 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x400000
WARNING: could not create /chosen FDT_ERR_NOSPACE.
ERROR: /chosen node create failed - must RESET the board to recover.
=
=20
-----Original Message-----
From: Oliver Rutsch [mailto:orutsch@sympatec.com]=20
Sent: Friday, August 31, 2007 12:35 PM
To: Mustafa Cay=FDr
Subject: Re: STK5200 pci_enable_device problem
Hi Mustafa,
> Hello Oliver,
>=20
> My problems continue, could you summarize your steps to bring up the =
board?
> which u-boot version is used?
> how build tqm5200.dts file?
> did you test pci bus?
>=20
> Thanks.
You should get the latest kernel sources and u-boot sources directly=20
from the git archives from www.denx.de.
Only use the native git protocol, not the HTTP git protocol.
E.g. "git-clone git://www.denx.de/git/linux-2.6-denx linux-2.6-denx"
Build u-boot with the configuration for your board. If your card is NOT=20
a 66 MHz PCI-card, then undefine CFG_PCICLK_EQUALS_IPBCLK_DIV2 in the=20
u-boot configuration to get a 33 MHz PCI bus.
Build u-boot and flash it to the module. Then install the dtc compiler=20
from the git archive (git://www.jdl.com/software/dtc.git). Do NOT use=20
the tar archive on the web, it is out of date. Compile a dtb file out of =
the tqm5200.dts file you find in the kernel sources.
Build the kernel with tqm5200_defconfig.
Boot your module and load the kernel and the dtb file in u-boot. E.g.=20
"tftp 200000 mykernel" and "tftp 400000 mydevicetree.dtb".
Don't forget to change the serial console output. On the 2.4 kernel the=20
internal mpc5200 uarts had the name ttyS0/ttyS1/ttyS2. On the 2.6 they=20
are called ttyPSC0 up to ttyPSC2. So type in u-boot
"set addcons 'setenv bootargs ${bootargs} =
console=3DttyPSC0,${baudrate}'"
"save" (don't forget the single quotes in line above!).
Boot now with "bootm 200000 - 400000".
Now it should boot fine.
I've tested a Korenix Jetcard 1404 (Oxford 16mPCI954 chip) with this=20
kernel and it runs fine. I had no luck with the 2.4 kernel as it failed=20
to give the card an interrupt.
Bye,
--=20
Dipl. Ing. Oliver Rutsch
EMail: orutsch@sympatec.com =B7 Tel.:+49 5323 717514
Sympatec GmbH =B7 Am Pulverhaus 1 =B7 D-38678 Clausthal-Zellerfeld =B7 =
Germany
Geschaeftsfuehrer: Dr.-Ing. E.h. Stephan Roethele =B7 Handelsregister:=20
Amtsgericht Braunschweig, HRB 110809
^ permalink raw reply
* Re: [BUG][2.6.23-rc6] Badness at arch/powerpc/kernel/smp.c:202
From: Andy Whitcroft @ 2007-09-14 11:03 UTC (permalink / raw)
To: Satyam Sharma
Cc: mel, linux-kernel, Kamalesh Babulal, linuxppc-dev, paulus, anton,
Balbir Singh
In-Reply-To: <a781481a0709140337u2c26f770h2af6d457bc39f280@mail.gmail.com>
Anton, this seems a little reminicient of that bug which popped up in
2.6.23-rc3 so do with SLB loading (if memory serves), with machine
checks and signal 7's. Of course that is _supposed_ to be fixed by this
time ...
I believe it was Paul who fixed up that one, and he is already copied.
-apw
On Fri, Sep 14, 2007 at 04:07:37PM +0530, Satyam Sharma wrote:
> > With 2.6.23-rc6 running on the ppc64 box, following oops is hit
> >
> > Oops: Machine check, sig: 7 [#1]
> >
> > SMP NR_CPUS=128 pSeries
> >
> > Modules linked in: binfmt_misc ipv6 dm_mod ehci_hcd ohci_hcd usbcore
> >
> > NIP: c0000000000ed560 LR: c0000000000efc7c CTR: c0000000000ed504
> >
> > REGS: c00000000ffef680 TRAP: 0200 Not tainted (2.6.23-rc6-autokern1)
> >
> > MSR: 8000000000109032 <EE,ME,IR,DR> CR: 28002042 XER: 00000010
> >
> > TASK = c0000000ecf9f000[0] 'swapper' THREAD: c00000000ff8c000 CPU: 2
> >
> > GPR00: 0000000000000000 c00000000ffef900 c0000000006fe598 c0000000d7a8f200
> >
> > GPR04: 0000000000001000 0000000000000000 0000000000001000 8000000000c26393
> >
> > GPR08: c0000000006b43d0 0000000000000001 0000000000001000 0000000000000000
> >
> > GPR12: 0000000048000048 c0000000005f1700 0000000000000000 0000000007a8dcd0
> >
> > GPR16: 0000000000000002 0000000000000000 0000000000000000 0000000000000000
> >
> > GPR20: 0000000000000000 0000000000001000 0000000000001000 0000000000000000
> >
> > GPR24: 0000000000000000 0000000000000000 0000000000001000 c0000000063234e8
> >
> > GPR28: 0000000000001000 0000000000000000 c000000000689c08 c00000000ff3a480
> >
> > NIP [c0000000000ed560] .end_bio_bh_io_sync+0x5c/0xac
> >
> > LR [c0000000000efc7c] .bio_endio+0xb4/0xd4
> >
> > Call Trace:
> >
> > [c00000000ffef900] [c00000000ffef990] 0xc00000000ffef990 (unreliable)
> >
> > [c00000000ffef980] [c0000000000efc7c] .bio_endio+0xb4/0xd4
> >
> > [c00000000ffefa10] [c000000000290060] .__end_that_request_first+0x154/0x548
> >
> > [c00000000ffefae0] [c00000000035af10] .scsi_end_request+0x40/0x138
> >
> > [c00000000ffefb80] [c00000000035b234] .scsi_io_completion+0x188/0x454
> >
> > [c00000000ffefc60] [c000000000372a24] .sd_rw_intr+0x2e4/0x338
> >
> > [c00000000ffefd30] [c000000000354548] .scsi_finish_command+0xbc/0xe0
> >
> > [c00000000ffefdc0] [c00000000035bdf0] .scsi_softirq_done+0x140/0x188
> >
> > [c00000000ffefe60] [c000000000293184] .blk_done_softirq+0xa0/0xd0
> >
> > [c00000000ffefef0] [c000000000055e1c] .__do_softirq+0xa8/0x164
> >
> > [c00000000ffeff90] [c000000000023f14] .call_do_softirq+0x14/0x24
> >
> > [c00000000ff8f960] [c00000000000bd30] .do_softirq+0x68/0xac
> >
> > [c00000000ff8f9f0] [c000000000055f70] .irq_exit+0x54/0x6c
> >
> > [c00000000ff8fa70] [c00000000000c358] .do_IRQ+0x170/0x1ac
> >
> > [c00000000ff8fb00] [c000000000004780] hardware_interrupt_entry+0x18/0x98
> >
> > --- Exception: 501 at .pseries_dedicated_idle_sleep+0xe0/0x194
> >
> > LR = .pseries_dedicated_idle_sleep+0xd0/0x194
> >
> > [c00000000ff8fdf0] [0000000000000000] .__start+0x4000000000000000/0x8 (unreliable)
> >
> > [c00000000ff8fe80] [c000000000010bd4] .cpu_idle+0x104/0x1d8
> >
> > [c00000000ff8ff00] [c00000000002672c] .start_secondary+0x160/0x184
> >
> > [c00000000ff8ff90] [c000000000008364] .start_secondary_prolog+0xc/0x10
> >
> > Instruction dump:
> >
> > 409a0030 393f0018 38000080 7d6048a8 7d6b0378 7d6049ad 40a2fff4 38002000
> >
> > 7d2018a8 7d290378 7d2019ad 40a2fff4 <e9230038> e89f0018 e9690000 f8410028
> >
> > Kernel panic - not syncing: Fatal exception in interrupt
>
> This oops is the real bug here, but is that a machine check exception?
> If so, it could be a hardware failure what you saw there instead, and not
> really a kernel bug ...
^ permalink raw reply
* Re: [PATCH] pcmcia: Convert io_req_t to use kio_addr_t
From: Andrew Morton @ 2007-09-14 10:48 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, linux-pcmcia, linux-kernel, hch
In-Reply-To: <20070905142742.GA1760@lixom.net>
On Wed, 5 Sep 2007 09:27:43 -0500 Olof Johansson <olof@lixom.net> wrote:
> Convert the io_req_t members to kio_addr_t, to allow use on machines with
> more than 16 bits worth of IO port address space (ppc64 in this case,
> but it applies to others as well).
drivers/usb/host/sl811_cs.c: In function 'sl811_cs_config':
drivers/usb/host/sl811_cs.c:263: warning: format '%04x' expects type 'unsigned int', but argument 2 has type 'kio_addr_t'
drivers/usb/host/sl811_cs.c:263: warning: format '%04x' expects type 'unsigned int', but argument 3 has type 'long unsigned int'
That's not just a cosmetic thing - the printk can print junk and if there's
a %s in the control string after the %x's, printk() will crash.
I don't know how many instances of this are in the tree, but they'll all
need to be found and fixed.
^ permalink raw reply
* Re: [BUG][2.6.23-rc6] Badness at arch/powerpc/kernel/smp.c:202
From: Satyam Sharma @ 2007-09-14 10:37 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, paulus, linux-kernel, Balbir Singh
In-Reply-To: <46EA5CEB.7020104@linux.vnet.ibm.com>
Hi Kamalesh,
There's two things at work here ...
On 9/14/07, Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi,
>
> With 2.6.23-rc6 running on the ppc64 box, following oops is hit
>
> Oops: Machine check, sig: 7 [#1]
>
> SMP NR_CPUS=128 pSeries
>
> Modules linked in: binfmt_misc ipv6 dm_mod ehci_hcd ohci_hcd usbcore
>
> NIP: c0000000000ed560 LR: c0000000000efc7c CTR: c0000000000ed504
>
> REGS: c00000000ffef680 TRAP: 0200 Not tainted (2.6.23-rc6-autokern1)
>
> MSR: 8000000000109032 <EE,ME,IR,DR> CR: 28002042 XER: 00000010
>
> TASK = c0000000ecf9f000[0] 'swapper' THREAD: c00000000ff8c000 CPU: 2
>
> GPR00: 0000000000000000 c00000000ffef900 c0000000006fe598 c0000000d7a8f200
>
> GPR04: 0000000000001000 0000000000000000 0000000000001000 8000000000c26393
>
> GPR08: c0000000006b43d0 0000000000000001 0000000000001000 0000000000000000
>
> GPR12: 0000000048000048 c0000000005f1700 0000000000000000 0000000007a8dcd0
>
> GPR16: 0000000000000002 0000000000000000 0000000000000000 0000000000000000
>
> GPR20: 0000000000000000 0000000000001000 0000000000001000 0000000000000000
>
> GPR24: 0000000000000000 0000000000000000 0000000000001000 c0000000063234e8
>
> GPR28: 0000000000001000 0000000000000000 c000000000689c08 c00000000ff3a480
>
> NIP [c0000000000ed560] .end_bio_bh_io_sync+0x5c/0xac
>
> LR [c0000000000efc7c] .bio_endio+0xb4/0xd4
>
> Call Trace:
>
> [c00000000ffef900] [c00000000ffef990] 0xc00000000ffef990 (unreliable)
>
> [c00000000ffef980] [c0000000000efc7c] .bio_endio+0xb4/0xd4
>
> [c00000000ffefa10] [c000000000290060] .__end_that_request_first+0x154/0x548
>
> [c00000000ffefae0] [c00000000035af10] .scsi_end_request+0x40/0x138
>
> [c00000000ffefb80] [c00000000035b234] .scsi_io_completion+0x188/0x454
>
> [c00000000ffefc60] [c000000000372a24] .sd_rw_intr+0x2e4/0x338
>
> [c00000000ffefd30] [c000000000354548] .scsi_finish_command+0xbc/0xe0
>
> [c00000000ffefdc0] [c00000000035bdf0] .scsi_softirq_done+0x140/0x188
>
> [c00000000ffefe60] [c000000000293184] .blk_done_softirq+0xa0/0xd0
>
> [c00000000ffefef0] [c000000000055e1c] .__do_softirq+0xa8/0x164
>
> [c00000000ffeff90] [c000000000023f14] .call_do_softirq+0x14/0x24
>
> [c00000000ff8f960] [c00000000000bd30] .do_softirq+0x68/0xac
>
> [c00000000ff8f9f0] [c000000000055f70] .irq_exit+0x54/0x6c
>
> [c00000000ff8fa70] [c00000000000c358] .do_IRQ+0x170/0x1ac
>
> [c00000000ff8fb00] [c000000000004780] hardware_interrupt_entry+0x18/0x98
>
> --- Exception: 501 at .pseries_dedicated_idle_sleep+0xe0/0x194
>
> LR = .pseries_dedicated_idle_sleep+0xd0/0x194
>
> [c00000000ff8fdf0] [0000000000000000] .__start+0x4000000000000000/0x8 (unreliable)
>
> [c00000000ff8fe80] [c000000000010bd4] .cpu_idle+0x104/0x1d8
>
> [c00000000ff8ff00] [c00000000002672c] .start_secondary+0x160/0x184
>
> [c00000000ff8ff90] [c000000000008364] .start_secondary_prolog+0xc/0x10
>
> Instruction dump:
>
> 409a0030 393f0018 38000080 7d6048a8 7d6b0378 7d6049ad 40a2fff4 38002000
>
> 7d2018a8 7d290378 7d2019ad 40a2fff4 <e9230038> e89f0018 e9690000 f8410028
>
> Kernel panic - not syncing: Fatal exception in interrupt
This oops is the real bug here, but is that a machine check exception?
If so, it could be a hardware failure what you saw there instead, and not
really a kernel bug ...
> ------------[ cut here ]------------
>
> Badness at arch/powerpc/kernel/smp.c:202
This one is not the real issue at all -- it's just a sad problem in the powerpc
panic() -> smp_send_stop() -> smp_call_function() -> smp_call_function_map()
call chain. The thing is, smp_call_function() cannot be allowed from interrupt
disabled contexts, hence the WARN_ON() there. But panic() is a special case,
and so we must *not* complain when called from panic -- doing so will only
scroll away the real call trace / oops log from the screen (thankfully you had
a serial cable there?) and distract from the real bug, like what
happened here ...
The fix is to define an alternative __smp_call_function(), that calls into
smp_call_function_map(), and is itself called from
smp_call_function(), and then:
1. Use the inner __smp_call_function() in smp_send_stop(), and,
2. Move the WARN_ON() to the smp_call_function() wrapper instead.
I'd be back at my desk only by Tuesday, so don't expect a patch before then,
unless Paul fixes this up by himself before that.
Cheers,
Satyam
^ permalink raw reply
* [BUG][2.6.23-rc6] Badness at arch/powerpc/kernel/smp.c:202
From: Kamalesh Babulal @ 2007-09-14 10:05 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: paulus, Balbir Singh
Hi,
With 2.6.23-rc6 running on the ppc64 box, following oops is hit
Oops: Machine check, sig: 7 [#1]
SMP NR_CPUS=128 pSeries
Modules linked in: binfmt_misc ipv6 dm_mod ehci_hcd ohci_hcd usbcore
NIP: c0000000000ed560 LR: c0000000000efc7c CTR: c0000000000ed504
REGS: c00000000ffef680 TRAP: 0200 Not tainted (2.6.23-rc6-autokern1)
MSR: 8000000000109032 <EE,ME,IR,DR> CR: 28002042 XER: 00000010
TASK = c0000000ecf9f000[0] 'swapper' THREAD: c00000000ff8c000 CPU: 2
GPR00: 0000000000000000 c00000000ffef900 c0000000006fe598 c0000000d7a8f200
GPR04: 0000000000001000 0000000000000000 0000000000001000 8000000000c26393
GPR08: c0000000006b43d0 0000000000000001 0000000000001000 0000000000000000
GPR12: 0000000048000048 c0000000005f1700 0000000000000000 0000000007a8dcd0
GPR16: 0000000000000002 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000001000 0000000000001000 0000000000000000
GPR24: 0000000000000000 0000000000000000 0000000000001000 c0000000063234e8
GPR28: 0000000000001000 0000000000000000 c000000000689c08 c00000000ff3a480
NIP [c0000000000ed560] .end_bio_bh_io_sync+0x5c/0xac
LR [c0000000000efc7c] .bio_endio+0xb4/0xd4
Call Trace:
[c00000000ffef900] [c00000000ffef990] 0xc00000000ffef990 (unreliable)
[c00000000ffef980] [c0000000000efc7c] .bio_endio+0xb4/0xd4
[c00000000ffefa10] [c000000000290060] .__end_that_request_first+0x154/0x548
[c00000000ffefae0] [c00000000035af10] .scsi_end_request+0x40/0x138
[c00000000ffefb80] [c00000000035b234] .scsi_io_completion+0x188/0x454
[c00000000ffefc60] [c000000000372a24] .sd_rw_intr+0x2e4/0x338
[c00000000ffefd30] [c000000000354548] .scsi_finish_command+0xbc/0xe0
[c00000000ffefdc0] [c00000000035bdf0] .scsi_softirq_done+0x140/0x188
[c00000000ffefe60] [c000000000293184] .blk_done_softirq+0xa0/0xd0
[c00000000ffefef0] [c000000000055e1c] .__do_softirq+0xa8/0x164
[c00000000ffeff90] [c000000000023f14] .call_do_softirq+0x14/0x24
[c00000000ff8f960] [c00000000000bd30] .do_softirq+0x68/0xac
[c00000000ff8f9f0] [c000000000055f70] .irq_exit+0x54/0x6c
[c00000000ff8fa70] [c00000000000c358] .do_IRQ+0x170/0x1ac
[c00000000ff8fb00] [c000000000004780] hardware_interrupt_entry+0x18/0x98
--- Exception: 501 at .pseries_dedicated_idle_sleep+0xe0/0x194
LR = .pseries_dedicated_idle_sleep+0xd0/0x194
[c00000000ff8fdf0] [0000000000000000] .__start+0x4000000000000000/0x8 (unreliable)
[c00000000ff8fe80] [c000000000010bd4] .cpu_idle+0x104/0x1d8
[c00000000ff8ff00] [c00000000002672c] .start_secondary+0x160/0x184
[c00000000ff8ff90] [c000000000008364] .start_secondary_prolog+0xc/0x10
Instruction dump:
409a0030 393f0018 38000080 7d6048a8 7d6b0378 7d6049ad 40a2fff4 38002000
7d2018a8 7d290378 7d2019ad 40a2fff4 <e9230038> e89f0018 e9690000 f8410028
Kernel panic - not syncing: Fatal exception in interrupt
------------[ cut here ]------------
Badness at arch/powerpc/kernel/smp.c:202
NIP: c000000000026024 LR: c00000000004e378 CTR: 800000000013f270
REGS: c00000000ffef120 TRAP: 0700 Tainted: G D (2.6.23-rc6-autokern1)
MSR: 8000000000021032 <ME,IR,DR> CR: 22002022 XER: 0000000a
TASK = c0000000ecf9f000[0] 'swapper' THREAD: c00000000ff8c000 CPU: 2
GPR00: 0000000000000001 c00000000ffef3a0 c0000000006fe598 c00000000069ffb8
GPR04: 0000000000000000 0000000000000001 0000000000000000 0000000000000007
GPR08: 0000000000000000 c000000000739818 c000000000742998 c00000000069ffb8
GPR12: 0000000000004000 c0000000005f1700 0000000000000000 0000000007a8dcd0
GPR16: 0000000000000002 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000001000 0000000000001000 0000000000000000
GPR24: 0000000000000000 0000000000000000 0000000000001000 0000000000000007
GPR28: c0000000004e3190 0000000000000000 c000000000685b80 0000000000000000
NIP [c000000000026024] .smp_call_function_map+0x34/0x28c
LR [c00000000004e378] .panic+0x98/0x1b0
Call Trace:
[c00000000ffef3a0] [c0000000006943e8] 0xc0000000006943e8 (unreliable)
[c00000000ffef450] [c00000000004e378] .panic+0x98/0x1b0
[c00000000ffef4f0] [c00000000002213c] .die+0x224/0x264
[c00000000ffef590] [c0000000000231f0] .machine_check_exception+0x210/0x240
[c00000000ffef610] [c000000000003480] machine_check_common+0x100/0x180
--- Exception: 200 at .end_bio_bh_io_sync+0x5c/0xac
LR = .bio_endio+0xb4/0xd4
[c00000000ffef900] [c00000000ffef990] 0xc00000000ffef990 (unreliable)
[c00000000ffef980] [c0000000000efc7c] .bio_endio+0xb4/0xd4
[c00000000ffefa10] [c000000000290060] .__end_that_request_first+0x154/0x548
[c00000000ffefae0] [c00000000035af10] .scsi_end_request+0x40/0x138
[c00000000ffefb80] [c00000000035b234] .scsi_io_completion+0x188/0x454
[c00000000ffefc60] [c000000000372a24] .sd_rw_intr+0x2e4/0x338
[c00000000ffefd30] [c000000000354548] .scsi_finish_command+0xbc/0xe0
[c00000000ffefdc0] [c00000000035bdf0] .scsi_softirq_done+0x140/0x188
[c00000000ffefe60] [c000000000293184] .blk_done_softirq+0xa0/0xd0
[c00000000ffefef0] [c000000000055e1c] .__do_softirq+0xa8/0x164
[c00000000ffeff90] [c000000000023f14] .call_do_softirq+0x14/0x24
[c00000000ff8f960] [c00000000000bd30] .do_softirq+0x68/0xac
[c00000000ff8f9f0] [c000000000055f70] .irq_exit+0x54/0x6c
[c00000000ff8fa70] [c00000000000c358] .do_IRQ+0x170/0x1ac
[c00000000ff8fb00] [c000000000004780] hardware_interrupt_entry+0x18/0x98
--- Exception: 501 at .pseries_dedicated_idle_sleep+0xe0/0x194
LR = .pseries_dedicated_idle_sleep+0xd0/0x194
[c00000000ff8fdf0] [0000000000000000] .__start+0x4000000000000000/0x8 (unreliable)
[c00000000ff8fe80] [c000000000010bd4] .cpu_idle+0x104/0x1d8
[c00000000ff8ff00] [c00000000002672c] .start_secondary+0x160/0x184
[c00000000ff8ff90] [c000000000008364] .start_secondary_prolog+0xc/0x10
Instruction dump:
fba1ffe8 fbc1fff0 fbe1fff8 7c6b1b78 f8010010 f821ff51 7cdd3378 f8e10100
f9010108 880d01da 7c000074 7800d182 <0b000000> e922a500 3860ffff e8090000
I tired googling for similar bug and found two which where earlier reported one
at linuxppc-dev mailing list on 2.6.23-rc1 kernel
http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039905.html
and other on 2.6.22-rc1 kernel
http://lkml.org/lkml/2007/5/22/390
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* [PATCH] adds support for Micrel KS8721BL PHY
From: Sergej Stepanov @ 2007-09-14 9:25 UTC (permalink / raw)
To: linuxppc-embedded
The patch adds the support for Micrel KS8721BL PHY
Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
--
diff -ruN linux-2.6.22.1/drivers/net/phy/Kconfig linux-2.6.22.1_ids8247/drivers/net/phy/Kconfig
--- linux-2.6.22.1/drivers/net/phy/Kconfig 2007-07-10 20:56:30.000000000 +0200
+++ linux-2.6.22.1_ids8247/drivers/net/phy/Kconfig 2007-08-02 10:54:34.000000000 +0200
@@ -55,6 +55,11 @@
---help---
Currently supports the BCM5411, BCM5421 and BCM5461 PHYs.
+config MICREL_PHY
+ tristate "Drivers for MICREL KS8721BL PHYs"
+ ---help---
+ Currently supports on MPC82xx_IDS8247 board.
+
config FIXED_PHY
tristate "Drivers for PHY emulation on fixed speed/link"
---help---
diff -ruN linux-2.6.22.1/drivers/net/phy/Makefile linux-2.6.22.1_ids8247/drivers/net/phy/Makefile
--- linux-2.6.22.1/drivers/net/phy/Makefile 2007-07-10 20:56:30.000000000 +0200
+++ linux-2.6.22.1_ids8247/drivers/net/phy/Makefile 2007-08-02 10:54:34.000000000 +0200
@@ -11,4 +11,5 @@
obj-$(CONFIG_SMSC_PHY) += smsc.o
obj-$(CONFIG_VITESSE_PHY) += vitesse.o
obj-$(CONFIG_BROADCOM_PHY) += broadcom.o
+obj-$(CONFIG_MICREL_PHY) += micrel.o
obj-$(CONFIG_FIXED_PHY) += fixed.o
diff -ruN linux-2.6.22.1/drivers/net/phy/micrel.c linux-2.6.22.1_ids8247/drivers/net/phy/micrel.c
--- linux-2.6.22.1/drivers/net/phy/micrel.c 1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.22.1_ids8247/drivers/net/phy/micrel.c 2007-08-02 10:54:34.000000000 +0200
@@ -0,0 +1,109 @@
+/*
+ * drivers/net/phy/micrel.c
+ *
+ * Driver for Micrel KS8721BL PHY
+ * based on drivers/net/phy/lxt.c from Andy Fleming
+ *
+ * Author: Sergej Stepanov, IDS GmbH, Germany
+ * Copyright (c) 2007 IDS GmbH, Germany
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/string.h>
+#include <linux/errno.h>
+#include <linux/unistd.h>
+#include <linux/slab.h>
+#include <linux/interrupt.h>
+#include <linux/init.h>
+#include <linux/delay.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/skbuff.h>
+#include <linux/spinlock.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/mii.h>
+#include <linux/ethtool.h>
+#include <linux/phy.h>
+
+#include <asm/io.h>
+#include <asm/irq.h>
+#include <asm/uaccess.h>
+
+
+#define MII_KS8721BL_RXERCR 0x15
+#define MII_KS8721BL_ICSR 0x1B
+#define MII_KS8721BL_PHYCR 0x1F
+
+
+MODULE_DESCRIPTION("Micrel KS8721BL driver");
+MODULE_AUTHOR("Sergej Stepanov");
+MODULE_LICENSE("GPL");
+
+
+static int ks8721bl_config_intr(struct phy_device *phydev)
+{
+ int err1;
+
+ if(phydev->interrupts == PHY_INTERRUPT_ENABLED)
+ {
+ err1 = phy_write(phydev, MII_KS8721BL_ICSR, 0xFF00);
+ err1 = phy_write(phydev, 0, 0x1200); /* control register */
+ }
+ else
+ err1 = phy_write(phydev, MII_KS8721BL_ICSR, 0);
+
+ return err1;
+}
+
+static int ks8721bl_config_init(struct phy_device *phydev)
+{
+ phy_write(phydev, MII_KS8721BL_ICSR, 0);
+ return 0;
+}
+
+
+static int ks8721bl_ack_interrupt(struct phy_device *phydev)
+{
+ int err = phy_read(phydev, MII_KS8721BL_ICSR);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static struct phy_driver ks8721bl_driver = {
+ .phy_id = 0x000221619,
+ .name = "KS8721BL",
+ .phy_id_mask = 0xfffffff0,
+ .features = PHY_BASIC_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = ks8721bl_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = ks8721bl_ack_interrupt,
+ .config_intr = ks8721bl_config_intr,
+ .driver = { .owner = THIS_MODULE,},
+};
+
+static int __init ks8721_init(void)
+{
+ int ret;
+
+ ret = phy_driver_register(&ks8721bl_driver);
+ if (ret)
+ goto err1;
+
+ return 0;
+ err1:
+ return ret;
+}
+
+static void __exit ks8721_exit(void)
+{
+ phy_driver_unregister(&ks8721bl_driver);
+}
+
+module_init(ks8721_init);
+module_exit(ks8721_exit);
^ permalink raw reply
* RTC class drivers and powerpc arch
From: Gerhard Pircher @ 2007-09-14 8:39 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Since todc was removed from arch/powerpc I wonder how to use the rtc-cmos
RTC class driver for my AmigaOne with its VIA southbridge. Do I have to
define a platform device and the get/set_rtc_time hook functions or can
the driver probe for and access the hardware automatically, if there's a
device node for the RTC in the device tree?
Thanks!
regards,
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
^ permalink raw reply
* Re: [PATCH 2/9] 8xx: Infrastructure code cleanup.
From: Vitaly Bordug @ 2007-09-14 8:21 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070914040934.GK481@localhost.localdomain>
Hello David,
On Fri, 14 Sep 2007 14:09:34 +1000
David Gibson wrote:
> On Thu, Sep 13, 2007 at 12:16:40PM +0400, Vitaly Bordug wrote:
> [snip]
> > > This looks bogus. You're replacing the old crap immr_map() functions,
> > > which ioremap()ed the registers every time, with a much simpler
> > > version which uses an established-once mapping of the register
> > > region. AFAICT, anywah.
> > >
> > > So far, so good - but your immr_unmap() still does an iounmap() which
> > > is surely wrong - it should now be a no-op, leaving the mpc8xx_immr
> > > mapping intact. You probably get away with it by accident, because I
> > > imagine attempting to unmap an unaligned chunk of the region will just
> > > fail.
> > >
> >
> > yes, it should do nop instead of iounmap.
> > > In fact, with this patch in place, I'd like to see another patch which
> > > removes all calls to immr_map() and immr_unmap(), simply accessing the
> > > common mapping directly.
> > >
> > Sorry, but originally, that stuff was created to get rid of BSP
> > ifdefs in drivers. For PQ family, it is a common practice to have
> > single driver handling all 3 CPU families, which use the same logic,
> > but immr structure differs a little bit.
> >
> > At this point it's clear case-by-case ioremapping does not have firm
> > benefit, but getting back to the way it was is useless either. In
> > ideal world, we'd have all those stuff put into dts and have
> > specific drivers be a shim layer between core hw and IO drivers.
>
> Err.. I don't understand what you're getting at. As the code stands
> after Scott's cleanup, the map() and unmap() calls can certainly be
> trivially removed, regardless of the history for them.
>
I don't argue if they can be removed, but if we aught to do that. Direct immr
dereference adds plenty of mess into driver code. I would like to keep the
situation when immr accesses factored out as a starting point, rather then turn them back to
&immap-> or cpm2_immr-> refs.
> And, yes, the drivers should certainly uses addresses from the device
> tree, rather than that revolting structure covering all the inbuilt
> device retgisters.
hehe, then you prolly know, that this structure does not fin well into device/driver model, either platform_ or
of_device. And I am going to sort it out at some point...
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 19/25] spufs: Internal __spufs_get_foo() routines should take a spu_context *
From: Christoph Hellwig @ 2007-09-14 7:43 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev
In-Reply-To: <1189751574.109563.102927754470.19.gpush@pokey>
On Fri, Sep 14, 2007 at 04:32:54PM +1000, Jeremy Kerr wrote:
> From: Michael Ellerman <michael@ellerman.id.au>
>
> The SPUFS attribute get routines take a void * because the generic attribute
> code doesn't know what sort of data it's passing around.
>
> However our internal __spufs_get_foo() routines can take a spu_context *
> directly, which saves plonking it in and out of a void * again.
Looks good.
^ permalink raw reply
* Re: [PATCH 10/25] spusched: fix null pointer dereference in find_victim
From: Christoph Hellwig @ 2007-09-14 7:44 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev
In-Reply-To: <1189751574.104447.719838727251.10.gpush@pokey>
On Fri, Sep 14, 2007 at 04:32:54PM +1000, Jeremy Kerr wrote:
> From: Christoph Hellwig <hch@lst.de>
>
> find_victim can dereference a NULL pointer when iterating over the list
> of victim spus because list_mutex only guarantees spu->ct to be stable,
> but of course not to be non-NULL.
>
> Also fix find_victim to not call spu_unbind_context without list_mutex
> because that violates the above guarantee.
Didn't we want to try to get this into 2.6.23? It's a quite emberassing
bug with a trivial fix. And a regression vs 2.6.22.
^ permalink raw reply
* Re: [PATCH 02/25] spufs: remove asmlinkage from do_spu_create
From: Christoph Hellwig @ 2007-09-14 7:44 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev
In-Reply-To: <1189751574.99308.205878694122.2.gpush@pokey>
On Fri, Sep 14, 2007 at 04:32:54PM +1000, Jeremy Kerr wrote:
> do_spu_create doesn't need the asmlinkage qualifier; remove it.
Ah, okay it's solved here. Drop my earlier comment then.
^ permalink raw reply
* Re: [PATCH 09/25] cell: remove DEBUG for spu callbacks
From: Christoph Hellwig @ 2007-09-14 7:43 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev
In-Reply-To: <1189751574.103973.353120224453.9.gpush@pokey>
On Fri, Sep 14, 2007 at 04:32:54PM +1000, Jeremy Kerr wrote:
> We don't want SPE programs to be able to flood the kernel log by
> invoking the SPE callback handler, so don't enable DEBUG for
> spu_callbacks.c by default.
Yeah, sounds sane.
^ permalink raw reply
* Re: [PATCH 01/25] spufs: staticify file-internal functions & variables
From: Christoph Hellwig @ 2007-09-14 7:42 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev
In-Reply-To: <1189751574.98527.127994196313.1.gpush@pokey>
On Fri, Sep 14, 2007 at 04:32:54PM +1000, Jeremy Kerr wrote:
> From: Sebastian Siewior <cbe-oss-dev@ml.breakpoint.cc>
>
> There are a few symbols used only in one file within spufs; this change
> makes them static where suitable.
>
> Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Looks good.
> +static asmlinkage long do_spu_create(const char __user *pathname,
> + unsigned int flags, mode_t mode, struct file *neighbor)
please drop the unessecary asmlinkage here, though.
^ permalink raw reply
* [PATCH 07/25] spufs: remove asmlinkage from spufs_calls
From: Jeremy Kerr @ 2007-09-14 6:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1189751574.98527.127994196313.1.gpush@pokey>
spu_create and spu_run are wrapped by the cell syscall layer, so
we don't need the asmlinkage.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
include/asm-powerpc/spu.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/spu.h b/include/asm-powerpc/spu.h
index 383ecfd..eb1159c 100644
--- a/include/asm-powerpc/spu.h
+++ b/include/asm-powerpc/spu.h
@@ -239,10 +239,10 @@ extern long spu_sys_callback(struct spu_syscall_block *s);
/* syscalls implemented in spufs */
struct file;
struct spufs_calls {
- asmlinkage long (*create_thread)(const char __user *name,
+ long (*create_thread)(const char __user *name,
unsigned int flags, mode_t mode,
struct file *neighbor);
- asmlinkage long (*spu_run)(struct file *filp, __u32 __user *unpc,
+ long (*spu_run)(struct file *filp, __u32 __user *unpc,
__u32 __user *ustatus);
struct module *owner;
};
^ permalink raw reply related
* [PATCH 01/25] spufs: staticify file-internal functions & variables
From: Jeremy Kerr @ 2007-09-14 6:32 UTC (permalink / raw)
To: linuxppc-dev
From: Sebastian Siewior <cbe-oss-dev@ml.breakpoint.cc>
There are a few symbols used only in one file within spufs; this change
makes them static where suitable.
Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/platforms/cell/spu_base.c | 2 +-
arch/powerpc/platforms/cell/spu_callbacks.c | 2 +-
arch/powerpc/platforms/cell/spufs/file.c | 6 +++---
arch/powerpc/platforms/cell/spufs/run.c | 4 ++--
arch/powerpc/platforms/cell/spufs/syscalls.c | 4 ++--
5 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spu_base.c b/arch/powerpc/platforms/cell/spu_base.c
index 106d292..b5a2117 100644
--- a/arch/powerpc/platforms/cell/spu_base.c
+++ b/arch/powerpc/platforms/cell/spu_base.c
@@ -458,7 +458,7 @@ static int spu_shutdown(struct sys_device *sysdev)
return 0;
}
-struct sysdev_class spu_sysdev_class = {
+static struct sysdev_class spu_sysdev_class = {
set_kset_name("spu"),
.shutdown = spu_shutdown,
};
diff --git a/arch/powerpc/platforms/cell/spu_callbacks.c b/arch/powerpc/platforms/cell/spu_callbacks.c
index 47ec3be..ab39e22 100644
--- a/arch/powerpc/platforms/cell/spu_callbacks.c
+++ b/arch/powerpc/platforms/cell/spu_callbacks.c
@@ -33,7 +33,7 @@
* mbind, mq_open, ipc, ...
*/
-void *spu_syscall_table[] = {
+static void *spu_syscall_table[] = {
#define SYSCALL(func) sys_ni_syscall,
#define COMPAT_SYS(func) sys_ni_syscall,
#define PPC_SYS(func) sys_ni_syscall,
diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c
index 4100ddc..a4a8770 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -199,9 +199,9 @@ static int spufs_mem_mmap(struct file *file, struct vm_area_struct *vma)
}
#ifdef CONFIG_SPU_FS_64K_LS
-unsigned long spufs_get_unmapped_area(struct file *file, unsigned long addr,
- unsigned long len, unsigned long pgoff,
- unsigned long flags)
+static unsigned long spufs_get_unmapped_area(struct file *file,
+ unsigned long addr, unsigned long len, unsigned long pgoff,
+ unsigned long flags)
{
struct spu_context *ctx = file->private_data;
struct spu_state *csa = &ctx->csa;
diff --git a/arch/powerpc/platforms/cell/spufs/run.c b/arch/powerpc/platforms/cell/spufs/run.c
index 958f10e..1ce5e22 100644
--- a/arch/powerpc/platforms/cell/spufs/run.c
+++ b/arch/powerpc/platforms/cell/spufs/run.c
@@ -205,7 +205,7 @@ static int spu_reacquire_runnable(struct spu_context *ctx, u32 *npc,
* This means we can only do a very rough approximation of POSIX
* signal semantics.
*/
-int spu_handle_restartsys(struct spu_context *ctx, long *spu_ret,
+static int spu_handle_restartsys(struct spu_context *ctx, long *spu_ret,
unsigned int *npc)
{
int ret;
@@ -241,7 +241,7 @@ int spu_handle_restartsys(struct spu_context *ctx, long *spu_ret,
return ret;
}
-int spu_process_callback(struct spu_context *ctx)
+static int spu_process_callback(struct spu_context *ctx)
{
struct spu_syscall_block s;
u32 ls_pointer, npc;
diff --git a/arch/powerpc/platforms/cell/spufs/syscalls.c b/arch/powerpc/platforms/cell/spufs/syscalls.c
index 43f0fb8..3d8c328 100644
--- a/arch/powerpc/platforms/cell/spufs/syscalls.c
+++ b/arch/powerpc/platforms/cell/spufs/syscalls.c
@@ -76,8 +76,8 @@ asmlinkage long sys_spu_run(int fd, __u32 __user *unpc, __u32 __user *ustatus)
}
#endif
-asmlinkage long do_spu_create(const char __user *pathname, unsigned int flags,
- mode_t mode, struct file *neighbor)
+static asmlinkage long do_spu_create(const char __user *pathname,
+ unsigned int flags, mode_t mode, struct file *neighbor)
{
char *tmp;
int ret;
^ permalink raw reply related
* [PATCH 17/25] spufs: Don't return -ENOSYS as extra notes size if spufs is not loaded
From: Jeremy Kerr @ 2007-09-14 6:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1189751574.98527.127994196313.1.gpush@pokey>
From: Michael Ellerman <michael@ellerman.id.au>
Because the SPU coredump code might be built as part of a module (spufs),
we have a stub which is called by the coredump code, this routine then calls
into spufs if it's loaded.
Unfortunately the stub returns -ENOSYS if spufs is not loaded, which is
interpreted by the coredump code as an extra note size of -38 bytes. This
leads to a corrupt core dump.
If spufs is not loaded there will be no SPU ELF notes to write, and so the
extra notes size will be == 0.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
arch/powerpc/platforms/cell/spu_coredump.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spu_coredump.c b/arch/powerpc/platforms/cell/spu_coredump.c
index 4fd37ff..656a8c5 100644
--- a/arch/powerpc/platforms/cell/spu_coredump.c
+++ b/arch/powerpc/platforms/cell/spu_coredump.c
@@ -31,15 +31,19 @@ static DEFINE_MUTEX(spu_coredump_mutex);
int arch_notes_size(void)
{
- long ret;
+ int ret;
- ret = -ENOSYS;
mutex_lock(&spu_coredump_mutex);
+
if (spu_coredump_calls && try_module_get(spu_coredump_calls->owner)) {
ret = spu_coredump_calls->arch_notes_size();
module_put(spu_coredump_calls->owner);
+ } else {
+ ret = 0;
}
+
mutex_unlock(&spu_coredump_mutex);
+
return ret;
}
^ permalink raw reply related
* [PATCH 24/25] spufs: Respect RLIMIT_CORE in spu coredump code
From: Jeremy Kerr @ 2007-09-14 6:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1189751574.98527.127994196313.1.gpush@pokey>
From: Michael Ellerman <michael@ellerman.id.au>
Currently the spu coredump code doesn't respect the ulimit, it should.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/platforms/cell/spufs/coredump.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/platforms/cell/spufs/coredump.c b/arch/powerpc/platforms/cell/spufs/coredump.c
index 6b8aef6..80f6236 100644
--- a/arch/powerpc/platforms/cell/spufs/coredump.c
+++ b/arch/powerpc/platforms/cell/spufs/coredump.c
@@ -53,8 +53,12 @@ static ssize_t do_coredump_read(int num, struct spu_context *ctx, void *buffer,
*/
static int spufs_dump_write(struct file *file, const void *addr, int nr, loff_t *foffset)
{
+ unsigned long limit = current->signal->rlim[RLIMIT_CORE].rlim_cur;
ssize_t written;
+ if (*foffset + nr > limit)
+ return -EIO;
+
written = file->f_op->write(file, addr, nr, &file->f_pos);
*foffset += written;
^ permalink raw reply related
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