* 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
* [PATCH 05/25] spufs: fix race condition on gang->aff_ref_spu
From: Jeremy Kerr @ 2007-09-14 6:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1189751574.98527.127994196313.1.gpush@pokey>
From: Andre Detsch <adetsch@br.ibm.com>
Affinity reference point location (gang->aff_ref_spu) is reset
when the whole gang is descheduled. However, the last member of
a gang can be descheduled while we are trying to schedule another
member of the gang. This was leading to a race condition, and
the code was using gang->aff_ref_spu in an unsafe manner.
By holding the gang->aff_mutex a little bit longer, and increment
gang->aff_sched_count (which controls when gang->aff_ref_spu
should be reset) a little bit earlier, the problem is fixed.
Signed-off-by: Andre Detsch <adetsch@br.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/platforms/cell/spufs/sched.c | 49 +++++++++++++++++++-----------
1 file changed, 32 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/sched.c b/arch/powerpc/platforms/cell/spufs/sched.c
index c784edd..17806e0 100644
--- a/arch/powerpc/platforms/cell/spufs/sched.c
+++ b/arch/powerpc/platforms/cell/spufs/sched.c
@@ -230,8 +230,6 @@ static void spu_bind_context(struct spu *spu, struct spu_context *ctx)
if (ctx->flags & SPU_CREATE_NOSCHED)
atomic_inc(&cbe_spu_info[spu->node].reserved_spus);
- if (!list_empty(&ctx->aff_list))
- atomic_inc(&ctx->gang->aff_sched_count);
ctx->stats.slb_flt_base = spu->stats.slb_flt;
ctx->stats.class2_intr_base = spu->stats.class2_intr;
@@ -392,7 +390,6 @@ static int has_affinity(struct spu_context *ctx)
if (list_empty(&ctx->aff_list))
return 0;
- mutex_lock(&gang->aff_mutex);
if (!gang->aff_ref_spu) {
if (!(gang->aff_flags & AFF_MERGED))
aff_merge_remaining_ctxs(gang);
@@ -400,7 +397,6 @@ static int has_affinity(struct spu_context *ctx)
aff_set_offsets(gang);
aff_set_ref_point_location(gang);
}
- mutex_unlock(&gang->aff_mutex);
return gang->aff_ref_spu != NULL;
}
@@ -418,9 +414,16 @@ static void spu_unbind_context(struct spu *spu, struct spu_context *ctx)
if (spu->ctx->flags & SPU_CREATE_NOSCHED)
atomic_dec(&cbe_spu_info[spu->node].reserved_spus);
- if (!list_empty(&ctx->aff_list))
- if (atomic_dec_and_test(&ctx->gang->aff_sched_count))
- ctx->gang->aff_ref_spu = NULL;
+
+ if (ctx->gang){
+ mutex_lock(&ctx->gang->aff_mutex);
+ if (has_affinity(ctx)) {
+ if (atomic_dec_and_test(&ctx->gang->aff_sched_count))
+ ctx->gang->aff_ref_spu = NULL;
+ }
+ mutex_unlock(&ctx->gang->aff_mutex);
+ }
+
spu_switch_notify(spu, NULL);
spu_unmap_mappings(ctx);
spu_save(&ctx->csa, spu);
@@ -511,20 +514,32 @@ static void spu_prio_wait(struct spu_context *ctx)
static struct spu *spu_get_idle(struct spu_context *ctx)
{
- struct spu *spu;
+ struct spu *spu, *aff_ref_spu;
int node, n;
- if (has_affinity(ctx)) {
- node = ctx->gang->aff_ref_spu->node;
+ if (ctx->gang) {
+ mutex_lock(&ctx->gang->aff_mutex);
+ if (has_affinity(ctx)) {
+ aff_ref_spu = ctx->gang->aff_ref_spu;
+ atomic_inc(&ctx->gang->aff_sched_count);
+ mutex_unlock(&ctx->gang->aff_mutex);
+ node = aff_ref_spu->node;
- mutex_lock(&cbe_spu_info[node].list_mutex);
- spu = ctx_location(ctx->gang->aff_ref_spu, ctx->aff_offset, node);
- if (spu && spu->alloc_state == SPU_FREE)
- goto found;
- mutex_unlock(&cbe_spu_info[node].list_mutex);
- return NULL;
- }
+ mutex_lock(&cbe_spu_info[node].list_mutex);
+ spu = ctx_location(aff_ref_spu, ctx->aff_offset, node);
+ if (spu && spu->alloc_state == SPU_FREE)
+ goto found;
+ mutex_unlock(&cbe_spu_info[node].list_mutex);
+ mutex_lock(&ctx->gang->aff_mutex);
+ if (atomic_dec_and_test(&ctx->gang->aff_sched_count))
+ ctx->gang->aff_ref_spu = NULL;
+ mutex_unlock(&ctx->gang->aff_mutex);
+
+ return NULL;
+ }
+ mutex_unlock(&ctx->gang->aff_mutex);
+ }
node = cpu_to_node(raw_smp_processor_id());
for (n = 0; n < MAX_NUMNODES; n++, node++) {
node = (node < MAX_NUMNODES) ? node : 0;
^ permalink raw reply related
* [PATCH 15/25] spufs: Write some SPU coredump values as ASCII
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>
Unfortunately GDB expects some of the SPU coredump values to be identical
in format to what is found in spufs. This means we need to dump some of
the values as ASCII strings, not the actual values.
Because we don't know what the values will be, we always print the values
with the format "0x%.16lx", that way we know the result will be 19 bytes.
do_coredump_read() doesn't take a __user buffer, so remove the annotation,
and because we know that it's safe to just snprintf() directly to it.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/platforms/cell/spufs/coredump.c | 8 +++++---
arch/powerpc/platforms/cell/spufs/file.c | 14 +++++++-------
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/coredump.c b/arch/powerpc/platforms/cell/spufs/coredump.c
index 21283f6..c65b717 100644
--- a/arch/powerpc/platforms/cell/spufs/coredump.c
+++ b/arch/powerpc/platforms/cell/spufs/coredump.c
@@ -31,7 +31,7 @@
#include "spufs.h"
-static ssize_t do_coredump_read(int num, struct spu_context *ctx, void __user *buffer,
+static ssize_t do_coredump_read(int num, struct spu_context *ctx, void *buffer,
size_t size, loff_t *off)
{
u64 data;
@@ -41,8 +41,10 @@ static ssize_t do_coredump_read(int num, struct spu_context *ctx, void __user *b
return spufs_coredump_read[num].read(ctx, buffer, size, off);
data = spufs_coredump_read[num].get(ctx);
- ret = copy_to_user(buffer, &data, 8);
- return ret ? -EFAULT : 8;
+ ret = snprintf(buffer, size, "0x%.16lx", data);
+ if (ret >= size)
+ return size;
+ return ++ret; /* count trailing NULL */
}
/*
diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c
index 18ddde8..85edbec 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -2233,16 +2233,16 @@ struct tree_descr spufs_dir_nosched_contents[] = {
struct spufs_coredump_reader spufs_coredump_read[] = {
{ "regs", __spufs_regs_read, NULL, sizeof(struct spu_reg128[128])},
{ "fpcr", __spufs_fpcr_read, NULL, sizeof(struct spu_reg128) },
- { "lslr", NULL, __spufs_lslr_get, 11 },
- { "decr", NULL, __spufs_decr_get, 11 },
- { "decr_status", NULL, __spufs_decr_status_get, 11 },
+ { "lslr", NULL, __spufs_lslr_get, 19 },
+ { "decr", NULL, __spufs_decr_get, 19 },
+ { "decr_status", NULL, __spufs_decr_status_get, 19 },
{ "mem", __spufs_mem_read, NULL, LS_SIZE, },
{ "signal1", __spufs_signal1_read, NULL, sizeof(u32) },
- { "signal1_type", NULL, __spufs_signal1_type_get, 2 },
+ { "signal1_type", NULL, __spufs_signal1_type_get, 19 },
{ "signal2", __spufs_signal2_read, NULL, sizeof(u32) },
- { "signal2_type", NULL, __spufs_signal2_type_get, 2 },
- { "event_mask", NULL, __spufs_event_mask_get, 8 },
- { "event_status", NULL, __spufs_event_status_get, 8 },
+ { "signal2_type", NULL, __spufs_signal2_type_get, 19 },
+ { "event_mask", NULL, __spufs_event_mask_get, 19 },
+ { "event_status", NULL, __spufs_event_status_get, 19 },
{ "mbox_info", __spufs_mbox_info_read, NULL, sizeof(u32) },
{ "ibox_info", __spufs_ibox_info_read, NULL, sizeof(u32) },
{ "wbox_info", __spufs_wbox_info_read, NULL, 4 * sizeof(u32)},
^ 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