* Re: MPC5200B panics with high ethernet rx traffic
From: Grant Likely @ 2009-10-14 17:07 UTC (permalink / raw)
To: Asier Llano Palacios; +Cc: linuxppc-dev
In-Reply-To: <1255538154.26753.13.camel@allano>
On Wed, Oct 14, 2009 at 10:35 AM, Asier Llano Palacios <a.llano@ziv.es> wrote:
> Hi,
>
> I've found a very simple way to create a kernel panic, that's happening
> to our MPC5200B based boards. The issue was that when our boards
> received a burst of ethernet packets had a kernel panic.
This looks familiar. Look in drivers/net/fec_mpc52xx.c and find the
function mpc52xx_fec_reset(). Remove the calls to phy_stop(),
phy_write() and phy_start(). See if that helps.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 5/8] 8xx: dcbst sets store bit in DTLB error, workaround.
From: Scott Wood @ 2009-10-14 17:02 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <1255278912-8042-6-git-send-email-Joakim.Tjernlund@transmode.se>
On Sun, Oct 11, 2009 at 06:35:09PM +0200, Joakim Tjernlund wrote:
> DARFix: /* Return from dcbx instruction bug workaround, r10 holds value of DAR */
[snip]
> + b DARfix /* Nope, go back to normal TLB processing */
arch/powerpc/kernel/head_8xx.S:577: undefined reference to `DARfix'
-Scott
^ permalink raw reply
* Re: [PATCH 2/8] 8xx: Update TLB asm so it behaves as linux mm expects.
From: Scott Wood @ 2009-10-14 16:57 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <1255278912-8042-3-git-send-email-Joakim.Tjernlund@transmode.se>
On Sun, Oct 11, 2009 at 06:35:06PM +0200, Joakim Tjernlund wrote:
> + mfspr r11, SRR1
> + /* clear all error bits as TLB Miss
> + * sets a few unconditionally
> + */
> + rlwinm r11, r11, 0, 0xffff
> + mtspr SRR1, r11
arch/powerpc/kernel/head_8xx.S:369: Error: unsupported relocation against SRR1
arch/powerpc/kernel/head_8xx.S:374: Error: unsupported relocation against SRR1
-Scott
^ permalink raw reply
* Re: [PATCH 1/8] 8xx: invalidate non present TLBs
From: Scott Wood @ 2009-10-14 16:56 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <1255278912-8042-2-git-send-email-Joakim.Tjernlund@transmode.se>
On Sun, Oct 11, 2009 at 06:35:05PM +0200, Joakim Tjernlund wrote:
> 8xx sometimes need to load a invalid/non-present TLBs in
> it DTLB asm handler.
> These must be invalidated separaly as linux mm don't.
> ---
> arch/powerpc/mm/fault.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 7699394..72941c7 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -39,7 +39,7 @@
> #include <asm/uaccess.h>
> #include <asm/tlbflush.h>
> #include <asm/siginfo.h>
> -
> +#include <mm/mmu_decl.h>
>
> #ifdef CONFIG_KPROBES
> static inline int notify_page_fault(struct pt_regs *regs)
> @@ -243,6 +243,12 @@ good_area:
> goto bad_area;
> #endif /* CONFIG_6xx */
> #if defined(CONFIG_8xx)
> + /* 8xx sometimes need to load a invalid/non-present TLBs.
> + * These must be invalidated separately as linux mm don't.
> + */
> + if (error_code & 0x40000000) /* no translation? */
> + _tlbil_va(address);
arch/powerpc/mm/fault.c:253: error: too few arguments to function ‘_tlbil_va’
-Scott
^ permalink raw reply
* MPC5200B panics with high ethernet rx traffic
From: Asier Llano Palacios @ 2009-10-14 16:35 UTC (permalink / raw)
To: linuxppc-dev, Grant Likely
[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]
Hi,
I've found a very simple way to create a kernel panic, that's happening
to our MPC5200B based boards. The issue was that when our boards
received a burst of ethernet packets had a kernel panic.
It does also happen to a lite5200b evaluation board, and it is really
simple to reproduce:
Step 1: Configure the jumpers of the board as:
CFG 4: L
CFG 3: L
CFG 2: H
CFG 1: L
CFG 0: L
--------
XLB: L
SYS: L
FVCO: L
MG: L
LF: L
HI/LO: L (but it depends on where do you have the bootloader)
WAIT: H
SWAP: L
WIDE: L
MUXED: L
Step 2: Connect an ethernet cable from the board to a 100Mbit
ethernet switch.
Step 3: Make a loop in the switch connecting two other ports together
(I know this is weird but it is the simplest way I know
to generate an intensive traffic).
Step 4: Power up the board
Step 5: ifconfig 192.168.0.1
Step 6: ping 192.168.0.123
The ping generates an ARP packet (which is broadcast), then with the
loop of the switch the board will receive a storm of ARP packets
(probably near 100Mbits). Then the board configured with 266MHz core
will panic.
It happens to me in Linux versions from 2.6.22 to 2.6.28, with
bootloaders from 1.1.6 to 2009.08. It doesn't happen if you change the
jumpers (CFG 3: H, CFG 1: H) increasing the Core frequency. I'm planning
to test it with 2.6.31 but I still have another issues to test this.
I provide a log with the kernel panic.
We could assume that the CPU usage goes really high. We could also
assume that the packets that cannot be processed are dropped. We cannot
assume a kernel panic because during one second the reception traffic in
the ethernet was too high.
If you want more information or want us to perform more testing I would
gladly try to help. Maybe you can test it with your versions of software
and your board.
Your help would be greatly appreciated,
Asier
----------------------------------------- PLEASE NOTE -------------------------------------------
This message, along with any attachments, may be confidential or legally privileged.
It is intended only for the named person(s), who is/are the only authorized recipients.
If this message has reached you in error, kindly destroy it without review and notify the sender immediately.
Thank you for your help.
ZIV uses virus scanning software but excludes any liability for viruses contained in any attachment.
------------------------------------ ROGAMOS LEA ESTE TEXTO -------------------------------
Este mensaje y sus anexos pueden contener información confidencial y/o con derecho legal.
Está dirigido únicamente a la/s persona/s o entidad/es reseñadas como único destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elimínelo sin revisarlo ni reenviarlo y notifíquelo inmediatamente al remitente. Gracias por su colaboración.
ZIV utiliza software antivirus, pero no se hace responsable de los virus contenidos en los ficheros anexos.
[-- Attachment #2: kernel_log.txt --]
[-- Type: text/plain, Size: 7486 bytes --]
U-Boot 2009.08 (oct 14 2009 - 13:00:56)
CPU: MPC5200B v2.2, Core v1.4 at 330 MHz
Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
Board: Freescale Lite5200B
I2C: 85 kHz, ready
DRAM: 256 MB
FLASH: 32 MB
*** Warning - bad CRC, using default environment
PCI: Bus Dev VenId DevId Class Int
00 1a 1057 5809 0680 00
In: serial
Out: serial
Err: serial
Net: FEC ETHERNET
IDE: Bus 0: OK
Device 0: not available
Device 1: not available
Type "run flash_nfs" to mount root filesystem over NFS
Hit any key to stop autoboot: 0
## Booting kernel from Legacy Image at ff042000 ...
Image Name: linux-2.6.28.10
Created: 2009-10-14 11:01:27 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1045251 Bytes = 1020.8 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at ff040000
Booting using the fdt blob at 0xff040000
Uncompressing Kernel Image ... OK
Loading Device Tree to 007fb000, end 007ff68d ... OK
Using lite5200 machine description
Linux version 2.6.28.10-uSysCom (asier@allano) (gcc version 4.3.4 (GCC) ) #7 PREEMPT Wed Oct 14 13:01:26 CEST 2009
Top of RAM: 0x1000000, Total RAM: 0x1000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x00000000 -> 0x00001000
Normal 0x00001000 -> 0x00001000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00001000
On node 0 totalpages: 4096
free_area_init_node: node 0, pgdat c0231850, node_mem_map c025c000
DMA zone: 32 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 4064 pages, LIFO batch:0
Normal zone: 0 pages used for memmap
Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
Kernel command line: console=ttyPSC0,115200 root=/dev/mtdblock3 rw irqpoll mtdparts=physmap-flash.0:192k(boot),64k(conf),1280k(linux),-(root)
Misrouted IRQ fixup and polling support enabled
This may significantly impact system performance
MPC52xx PIC is up and running!
PID hash table entries: 64 (order: 6, 256 bytes)
time_init: decrementer frequency = 33.000000 MHz
time_init: processor frequency = 330.000000 MHz
clocksource: timebase mult[79364d9] shift[22] registered
clockevent: decrementer mult[872] shift[16] cpu[0]
console [ttyPSC0] enabled
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 13808k/16384k available (2136k kernel code, 2576k reserved, 116k data, 120k bss, 148k init)
Calibrating delay loop... 65.79 BogoMIPS (lpj=32896)
Mount-cache hash table entries: 512
net_namespace: 480 bytes
NET: Registered protocol family 16
DMA: MPC52xx BestComm driver
DMA: MPC52xx BestComm engine @f0001200 ok !
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 512 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 512 bind 512)
TCP reno registered
NET: Registered protocol family 1
mpc5200_gpio_legacy: Freescale MPC5200 GPIO legacy Driver
MPC5200 WKUP GPIOs mapped
MPC5200 Simple GPIOs mapped
MPC5200 GPT0 GPIO mapped
MPC5200 GPT1 GPIO mapped
MPC5200 GPT2 GPIO mapped
MPC5200 GPT3 GPIO mapped
MPC5200 GPT4 GPIO mapped
MPC5200 GPT5 GPIO mapped
MPC5200 GPT6 GPIO mapped
MPC5200 GPT7 GPIO mapped
mpc5200_gpio_legacy: got dynamic major 254
squashfs: version 3.4 (2008/08/26) Phillip Lougher
msgmni has been set to 26
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler deadline registered (default)
Serial: MPC52xx PSC UART driver
f0002000.serial: ttyPSC0 at MMIO 0xf0002000 (irq = 129) is a MPC52xx PSC
brd: module loaded
loop: module loaded
mpc52xx MII bus: probed
mpc52xx-fec: miibus_handle found
mpc52xx-fec: miibus_node found
net eth0: Fixed speed MII link: 100FD
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
physmap platform flash device: 01000000 at ff000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
physmap-flash.0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
4 cmdlinepart partitions found on MTD device physmap-flash.0
Creating 4 MTD partitions on "physmap-flash.0":
0x00000000-0x00030000 : "boot"
mtd: partition "boot" doesn't end on an erase block -- force read-only
0x00030000-0x00040000 : "conf"
mtd: partition "conf" doesn't start on an erase block boundary -- force read-only
0x00040000-0x00180000 : "linux"
0x00180000-0x01000000 : "root"
i2c /dev entries driver
Driver for 1-wire Dallas network protocol.
MC33701 Watchdog Timer Driver v0.1
i2c-adapter i2c-0: Invalid probe address 0x78
i2c-adapter i2c-1: Invalid probe address 0x78
nf_conntrack version 0.5.0 (256 buckets, 1024 max)
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
VFS: Mounted root (squashfs filesystem) readonly.
Freeing unused kernel memory: 148k init
init started: BusyBox v1.14.4 (2009-09-29 12:25:23 CEST)
starting pid 202, tty '/dev/ttyPSC0': '/etc/rcS'
+ /bin/sleep 5
+ /sbin/ifconfig eth0 192.168.0.1 up
mpc52xx-fec: Trying ot access the MDIO bus
+ /bin/ping 192.168.0.5
PING 192.168.0.5 (192.168.0.5): 56 data bytes
net eth0: FEC_IEVENT_RFIFO_ERROR
Unable to handle kernel paging request for data at address 0x000001b8
Faulting instruction address: 0xc01adfe8
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT lite5200
Modules linked in:
NIP: c01adfe8 LR: c00f7a64 CTR: c000fb88
REGS: c0235ad0 TRAP: 0300 Not tainted (2.6.28.10-uSysCom)
MSR: 00009032 <EE,ME,IR,DR> CR: 22008082 XER: 20000000
DAR: 000001b8, DSISR: 20000000
TASK = c0218580[0] 'swapper' THREAD: c0234000
GPR00: c00fa928 c0235b80 c0218580 000001b8 c0d0bec0 00000000 00000002 00000000
GPR08: 000005f8 c208a000 000000c0 c025c000 42008084 7ffffdff 0ffb9000 0ffae948
GPR16: 0ffae96c 0ff45ccc 0ff45dcc 0ff45be9 c0246ed0 c01d24d4 c021a9cc c023c21c
GPR24: c07ee2bc c0219598 c07ee380 c07ee000 c07ee380 c208a000 000001b8 00000000
Call Trace:
[c0235b80] [c208a000] 0xc208a000 (unreliable)
[c0235b90] [c00fa928] 0xc00fa928
[c0235bb0] [c00fab14] 0xc00fab14
[c0235bc8] [c00436e8] 0xc00436e8
[c0235be0] [c0045694] 0xc0045694
[c0235bf8] [c0006160] 0xc0006160
[c0235c08] [c0010a34] 0xc0010a34
--- Exception: 501 at 0xc00645b8
LR = 0xc00645a8
[c0235ce0] [c0126fdc] 0xc0126fdc
[c0235d00] [c0127a20] 0xc0127a20
[c0235d08] [c00fb630] 0xc00fb630
[c0235d50] [c00436e8] 0xc00436e8
[c0235d68] [c0045694] 0xc0045694
[c0235d80] [c0006160] 0xc0006160
[c0235d90] [c0010a34] 0xc0010a34
--- Exception: 501 at 0xc012bd50
LR = 0xc0023104
[c0235e50] [00000102] 0x000102 (unreliable)
[c0235e70] [c0023104] 0xc0023104
[c0235ea8] [c00060d0] 0xc00060d0
[c0235eb8] [c0022d78] 0xc0022d78
[c0235ec0] [c000d63c] 0xc000d63c
[c0235ed0] [c0010a34] 0xc0010a34
--- Exception: 901 at 0xc0008f70
LR = 0xc0008f70
[c0235f90] [c0008fb8] 0xc0008fb8 (unreliable)
[c0235fa8] [c01af91c] 0xc01af91c
[c0235fc0] [c01f177c] 0xc01f177c
[c0235ff0] [00003438] 0x003438
Instruction dump:
812b000c 3929ffff 912b000c 800b0034 70090004 41a20008 4bfff4c9 8001003c
bb21001c 38210038 7c0803a6 4e800020 <7c001828> 3000ffff 7c00192d 40a2fff4
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 180 seconds..
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Adrian Hunter @ 2009-10-14 16:44 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org
In-Reply-To: <4AD5D053.9000901@embedded-sol.com>
Felix Radensky wrote:
> Adrian Hunter wrote:
>> Felix Radensky wrote:
>>> Hi,
>>>
>>> I have a strange problem in linux-2.6.31 running on MPC8536DS board.
>>> It is 100% reproducible, by opening a 350MB tar file into ubifs volume
>>> on NAND flash, and starting erase of NOR flash partition right after
>>> that.
>>>
>>> If I don't start NOR erase, everything works fine. Also, If I run
>>> sync after
>>> tar, no problem occurs. The NOR flash is 32MB Spansion, NAND is
>>> 4GB Samsung.
>>>
>>> The error messages are as follows:
>>>
>>> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
>>> 5812:12288, written 0 bytes
>>> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5812
>>> UBI: recover PEB 5812, move data to PEB 19400
>>> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
>>> 5812:512, read 512 bytes
>>> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
>>> 19400:512, written 0 bytes
>>> UBI warning: recover_peb: failed to write to PEB 19400
>>> UBI: try again
>>> UBI: recover PEB 5812, move data to PEB 19401
>>> UBI: run torture test for PEB 19400
>>> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
>>> 19401:512, written 0 bytes
>>> UBI warning: recover_peb: failed to write to PEB 19401
>>> UBI: try again
>>> UBI: recover PEB 5812, move data to PEB 19402
>>> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
>>> 19402:512, written 0 bytes
>>> UBI warning: recover_peb: failed to write to PEB 19402
>>> UBI: try again
>>> UBI: recover PEB 5812, move data to PEB 19403
>>> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
>>> 19403:512, written 0 bytes
>>> UBI warning: recover_peb: failed to write to PEB 19403
>>> UBI warning: ubi_ro_mode: switch to read-only mode
>>> UBIFS error (pid 1149): ubifs_wbuf_write_nolock: cannot write 2522
>>> bytes to LEB 389:10240, error -5
>>> UBIFS warning (pid 1149): ubifs_ro_mode: switched to read-only mode,
>>> error -5
>>> UBIFS error (pid 1149): do_writepage: cannot write page 0 of inode
>>> 30708, error -5
>>> UBIFS error (pid 1149): make_reservation: cannot reserve 858 bytes in
>>> jhead 2, error -30
>>> UBIFS error (pid 1149): do_writepage: cannot write page 2 of inode
>>> 29486, error -30
>>> UBIFS error (pid 1149): make_reservation: cannot reserve 721 bytes in
>>> jhead 2, error -30
>>> UBIFS error (pid 1149): do_writepage: cannot write page 1 of inode
>>> 30070, error -30
>>> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
>>> 5022:88064, written 0 bytes
>>> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5022
>>> UBI: recover PEB 5022, move data to PEB 19404
>>> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
>>> 5022:512, read 512 bytes
>>> UBI error: ubi_io_write: read-only mode
>>> UBI warning: recover_peb: failed to write to PEB 19404
>>> UBI: try again
>>> UBI: recover PEB 5022, move data to PEB 19405
>>> UBI error: ubi_io_write: read-only mode
>>> UBI warning: recover_peb: failed to write to PEB 19405
>>> UBI: try again
>>> UBI: recover PEB 5022, move data to PEB 19406
>>> UBI error: ubi_io_write: read-only mode
>>> UBI warning: recover_peb: failed to write to PEB 19406
>>> UBI: try again
>>> UBI: recover PEB 5022, move data to PEB 19407
>>> UBI error: ubi_io_write: read-only mode
>>> UBI warning: recover_peb: failed to write to PEB 19407
>>> UBIFS error (pid 1044): ubifs_wbuf_sync_nolock: cannot write 2048
>>> bytes to LEB 788:86016
>>> UBIFS error (pid 1044): ubifs_bg_wbufs_sync: cannot sync
>>> write-buffer, error -30
>>> UBIFS warning (pid 1044): ubifs_ro_mode: switched to read-only mode,
>>> error -30
>>> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
>>> 5817:26624, written 0 bytes
>>> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5817
>>> UBI: recover PEB 5817, move data to PEB 19408
>>> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
>>> 5817:512, read 512 bytes
>>> UBI error: ubi_io_write: read-only mode
>>> UBI warning: recover_peb: failed to write to PEB 19408
>>> UBI: try again
>>> UBI: recover PEB 5817, move data to PEB 19409
>>> UBI error: ubi_io_write: read-only mode
>>> UBI warning: recover_peb: failed to write to PEB 19409
>>> UBI: try again
>>> UBI: recover PEB 5817, move data to PEB 19410
>>> UBI error: ubi_io_write: read-only mode
>>> UBI warning: recover_peb: failed to write to PEB 19410
>>> UBI: try again
>>> UBI: recover PEB 5817, move data to PEB 19411
>>> UBI error: ubi_io_write: read-only mode
>>> UBI warning: recover_peb: failed to write to PEB 19411
>>> UBIFS error (pid 1047): ubifs_wbuf_sync_nolock: cannot write 2048
>>> bytes to LEB 385:24576
>>> UBIFS error (pid 1047): ubifs_bg_wbufs_sync: cannot sync
>>> write-buffer, error -30
>>> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
>>> jhead 1, error -30
>>> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30709,
>>> error -30
>>> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
>>> jhead 1, error -30
>>> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30710,
>>> error -30
>>> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
>>> jhead 1, error -30
>>> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30698,
>>> error -30
>>> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
>>> jhead 1, error -30
>>> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30711,
>>> error -30
>>>
>>> I'd appreciate any hints on what can cause this. Is it a hardware
>>> problem, mtd layer problem
>>> or UBI problem ?
>> It sounds like you are saying one MTD partition somehow affects another.
>> You should check the MTD partitions are set up correctly. Are you using
>> tools that make assumptions about which mtd partition is which?
>>
>> How do you erase the NOR flash? Is the device node (/dev/mtd...)
>> correct?
> I can also reproduce the problem by reading from NOR, i.e.
>
> dd if=/dev/mtd4 of=/dev/null
I doubt the problem is in UBI or UBIFS, and plenty of people use multiple
MTD partitions with no problem.
Do the NAND and NOR use the same memory controller?
I don't think I can be much help I'm afraid.
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] spufs: Fix test in spufs_switch_log_read()
From: Roel Kluin @ 2009-10-14 15:32 UTC (permalink / raw)
To: Arnd Bergmann
Cc: cbe-oss-dev, linuxppc-dev, Jeremy Kerr, Andrew Morton,
linuxppc-dev, cbe-oss-dev
In-Reply-To: <200910131531.45726.arnd@arndb.de>
size_t len cannot be less than 0.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
>>> Or can this test be removed?
>>
>> I'd prefer just to remove the test.
>
> Yes, sounds good.
If you meant only the left-hand part, here you go:
diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c
index 884e8bc..64a4c2d 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -2494,7 +2494,7 @@ static ssize_t spufs_switch_log_read(struct file *file, char __user *buf,
struct spu_context *ctx = SPUFS_I(inode)->i_ctx;
int error = 0, cnt = 0;
- if (!buf || len < 0)
+ if (!buf)
return -EINVAL;
error = spu_acquire(ctx);
^ permalink raw reply related
* [PATCH] therm_adt746x: Don't access non-existing register
From: Jean Delvare @ 2009-10-14 15:31 UTC (permalink / raw)
To: Colin Leroy, Tim Shepard; +Cc: linuxppc-dev, Paul Mackerras
The ADT746x don't have any register at sub-address 0, so better use an
existing register for the initial test read.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Colin Leroy <colin@colino.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
---
Tim, I don't really expect this to solve your problem, but who knows...
Care to give it a try, just in case?
drivers/macintosh/therm_adt746x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.32-rc4.orig/drivers/macintosh/therm_adt746x.c 2009-10-12 11:53:59.000000000 +0200
+++ linux-2.6.32-rc4/drivers/macintosh/therm_adt746x.c 2009-10-14 17:27:46.000000000 +0200
@@ -387,7 +387,7 @@ static int probe_thermostat(struct i2c_c
i2c_set_clientdata(client, th);
th->clt = client;
- rc = read_reg(th, 0);
+ rc = read_reg(th, CONFIG_REG);
if (rc < 0) {
dev_err(&client->dev, "Thermostat failed to read config!\n");
kfree(th);
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Scott Wood @ 2009-10-14 15:27 UTC (permalink / raw)
To: Richard Cochran
Cc: 'linuxppc-dev@lists.ozlabs.org', 'Roland Lezuo'
In-Reply-To: <95DC1AA8EC908B48939B72CF375AA5E30E220693@alice.at.omicron.at>
On Wed, Oct 14, 2009 at 09:41:33AM +0200, Richard Cochran wrote:
> >-----Original Message-----
> >From: linuxppc-dev-bounces On Behalf Of Scott Wood
> >Sent: Wednesday, September 09, 2009 8:22 PM
> >To: Roland Lezuo
> >Cc: linuxppc-dev@lists.ozlabs.org
> >Subject: Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
> >
> >On Fri, Sep 04, 2009 at 12:31:25PM +0200, Roland Lezuo wrote:
> >> The following patch is needed to correctly assign the IRQs for the
> >> gianfar driver on the MPC8313ERDB-revc boards. ERR and TX are swapped
> >> as well as the interrupt lines for the two devices.
> >
> >And it will incorrectly assign them on older revisions of the chip.
> >
> >We really should have a u-boot fixup based on SVR.
>
> Why not just offer different dts files, one for each board revision?
>
> Something like:
> mpc8313erdb-revA.dts
> mpc8313erdb-revB.dts
> mpc8313erdb-revC.dts
Because that would be three times the device trees to maintain, and a
source of user confusion.
-Scott
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Felix Radensky @ 2009-10-14 13:21 UTC (permalink / raw)
To: Adrian Hunter; +Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org
In-Reply-To: <4AD5C5B4.3060303@nokia.com>
Adrian Hunter wrote:
> Felix Radensky wrote:
>> Hi,
>>
>> I have a strange problem in linux-2.6.31 running on MPC8536DS board.
>> It is 100% reproducible, by opening a 350MB tar file into ubifs volume
>> on NAND flash, and starting erase of NOR flash partition right after
>> that.
>>
>> If I don't start NOR erase, everything works fine. Also, If I run
>> sync after
>> tar, no problem occurs. The NOR flash is 32MB Spansion, NAND is
>> 4GB Samsung.
>>
>> The error messages are as follows:
>>
>> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
>> 5812:12288, written 0 bytes
>> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5812
>> UBI: recover PEB 5812, move data to PEB 19400
>> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
>> 5812:512, read 512 bytes
>> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
>> 19400:512, written 0 bytes
>> UBI warning: recover_peb: failed to write to PEB 19400
>> UBI: try again
>> UBI: recover PEB 5812, move data to PEB 19401
>> UBI: run torture test for PEB 19400
>> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
>> 19401:512, written 0 bytes
>> UBI warning: recover_peb: failed to write to PEB 19401
>> UBI: try again
>> UBI: recover PEB 5812, move data to PEB 19402
>> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
>> 19402:512, written 0 bytes
>> UBI warning: recover_peb: failed to write to PEB 19402
>> UBI: try again
>> UBI: recover PEB 5812, move data to PEB 19403
>> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
>> 19403:512, written 0 bytes
>> UBI warning: recover_peb: failed to write to PEB 19403
>> UBI warning: ubi_ro_mode: switch to read-only mode
>> UBIFS error (pid 1149): ubifs_wbuf_write_nolock: cannot write 2522
>> bytes to LEB 389:10240, error -5
>> UBIFS warning (pid 1149): ubifs_ro_mode: switched to read-only mode,
>> error -5
>> UBIFS error (pid 1149): do_writepage: cannot write page 0 of inode
>> 30708, error -5
>> UBIFS error (pid 1149): make_reservation: cannot reserve 858 bytes in
>> jhead 2, error -30
>> UBIFS error (pid 1149): do_writepage: cannot write page 2 of inode
>> 29486, error -30
>> UBIFS error (pid 1149): make_reservation: cannot reserve 721 bytes in
>> jhead 2, error -30
>> UBIFS error (pid 1149): do_writepage: cannot write page 1 of inode
>> 30070, error -30
>> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
>> 5022:88064, written 0 bytes
>> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5022
>> UBI: recover PEB 5022, move data to PEB 19404
>> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
>> 5022:512, read 512 bytes
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19404
>> UBI: try again
>> UBI: recover PEB 5022, move data to PEB 19405
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19405
>> UBI: try again
>> UBI: recover PEB 5022, move data to PEB 19406
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19406
>> UBI: try again
>> UBI: recover PEB 5022, move data to PEB 19407
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19407
>> UBIFS error (pid 1044): ubifs_wbuf_sync_nolock: cannot write 2048
>> bytes to LEB 788:86016
>> UBIFS error (pid 1044): ubifs_bg_wbufs_sync: cannot sync
>> write-buffer, error -30
>> UBIFS warning (pid 1044): ubifs_ro_mode: switched to read-only mode,
>> error -30
>> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
>> 5817:26624, written 0 bytes
>> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5817
>> UBI: recover PEB 5817, move data to PEB 19408
>> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
>> 5817:512, read 512 bytes
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19408
>> UBI: try again
>> UBI: recover PEB 5817, move data to PEB 19409
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19409
>> UBI: try again
>> UBI: recover PEB 5817, move data to PEB 19410
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19410
>> UBI: try again
>> UBI: recover PEB 5817, move data to PEB 19411
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19411
>> UBIFS error (pid 1047): ubifs_wbuf_sync_nolock: cannot write 2048
>> bytes to LEB 385:24576
>> UBIFS error (pid 1047): ubifs_bg_wbufs_sync: cannot sync
>> write-buffer, error -30
>> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
>> jhead 1, error -30
>> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30709,
>> error -30
>> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
>> jhead 1, error -30
>> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30710,
>> error -30
>> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
>> jhead 1, error -30
>> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30698,
>> error -30
>> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
>> jhead 1, error -30
>> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30711,
>> error -30
>>
>> I'd appreciate any hints on what can cause this. Is it a hardware
>> problem, mtd layer problem
>> or UBI problem ?
>
> It sounds like you are saying one MTD partition somehow affects another.
> You should check the MTD partitions are set up correctly. Are you using
> tools that make assumptions about which mtd partition is which?
>
> How do you erase the NOR flash? Is the device node (/dev/mtd...)
> correct?
I can also reproduce the problem by reading from NOR, i.e.
dd if=/dev/mtd4 of=/dev/null
Felix.
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* MPC5200B and USB
From: FIXED-TERM Seeh Thomas (BEG/EMS1) @ 2009-10-14 12:57 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
Hello everyone,
I'm working on a project to get USB ready on a MPC5200B based board.
On this board I'm not using Linux (but MQX), but my question is not related to Linux.
It's more specific to USB and OHCI.
I will communicate with a Mass Storage Device and therefor the control transfer works fine.
The Mass Storage Device has two endpoints for bulk transfer, one IN (from device to host) and
one OUT (from host to device).
If I want to communicate with the device should I have two endpoints on the host side too?
This would mean one endpoint which is associated with the IN endpoint to the device and one endpoint which
is associated with OUT endpoint to the device. Is that right?
For example I want to send a INQUIRY command to the device. Which endpoint must I use
to send the command and on which endpoint do I receive the question?
Best regards
Thomas
[-- Attachment #2: Type: text/html, Size: 1544 bytes --]
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Felix Radensky @ 2009-10-14 13:02 UTC (permalink / raw)
To: Adrian Hunter; +Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org
In-Reply-To: <4AD5C5B4.3060303@nokia.com>
Hi, Adrian
Adrian Hunter wrote:
> Felix Radensky wrote:
>> Hi,
>>
>> I have a strange problem in linux-2.6.31 running on MPC8536DS board.
>> It is 100% reproducible, by opening a 350MB tar file into ubifs volume
>> on NAND flash, and starting erase of NOR flash partition right after
>> that.
>>
>> If I don't start NOR erase, everything works fine. Also, If I run
>> sync after
>> tar, no problem occurs. The NOR flash is 32MB Spansion, NAND is
>> 4GB Samsung.
>>
>> The error messages are as follows:
>>
>> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
>> 5812:12288, written 0 bytes
>> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5812
>> UBI: recover PEB 5812, move data to PEB 19400
>> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
>> 5812:512, read 512 bytes
>> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
>> 19400:512, written 0 bytes
>> UBI warning: recover_peb: failed to write to PEB 19400
>> UBI: try again
>> UBI: recover PEB 5812, move data to PEB 19401
>> UBI: run torture test for PEB 19400
>> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
>> 19401:512, written 0 bytes
>> UBI warning: recover_peb: failed to write to PEB 19401
>> UBI: try again
>> UBI: recover PEB 5812, move data to PEB 19402
>> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
>> 19402:512, written 0 bytes
>> UBI warning: recover_peb: failed to write to PEB 19402
>> UBI: try again
>> UBI: recover PEB 5812, move data to PEB 19403
>> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
>> 19403:512, written 0 bytes
>> UBI warning: recover_peb: failed to write to PEB 19403
>> UBI warning: ubi_ro_mode: switch to read-only mode
>> UBIFS error (pid 1149): ubifs_wbuf_write_nolock: cannot write 2522
>> bytes to LEB 389:10240, error -5
>> UBIFS warning (pid 1149): ubifs_ro_mode: switched to read-only mode,
>> error -5
>> UBIFS error (pid 1149): do_writepage: cannot write page 0 of inode
>> 30708, error -5
>> UBIFS error (pid 1149): make_reservation: cannot reserve 858 bytes in
>> jhead 2, error -30
>> UBIFS error (pid 1149): do_writepage: cannot write page 2 of inode
>> 29486, error -30
>> UBIFS error (pid 1149): make_reservation: cannot reserve 721 bytes in
>> jhead 2, error -30
>> UBIFS error (pid 1149): do_writepage: cannot write page 1 of inode
>> 30070, error -30
>> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
>> 5022:88064, written 0 bytes
>> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5022
>> UBI: recover PEB 5022, move data to PEB 19404
>> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
>> 5022:512, read 512 bytes
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19404
>> UBI: try again
>> UBI: recover PEB 5022, move data to PEB 19405
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19405
>> UBI: try again
>> UBI: recover PEB 5022, move data to PEB 19406
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19406
>> UBI: try again
>> UBI: recover PEB 5022, move data to PEB 19407
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19407
>> UBIFS error (pid 1044): ubifs_wbuf_sync_nolock: cannot write 2048
>> bytes to LEB 788:86016
>> UBIFS error (pid 1044): ubifs_bg_wbufs_sync: cannot sync
>> write-buffer, error -30
>> UBIFS warning (pid 1044): ubifs_ro_mode: switched to read-only mode,
>> error -30
>> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
>> 5817:26624, written 0 bytes
>> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5817
>> UBI: recover PEB 5817, move data to PEB 19408
>> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
>> 5817:512, read 512 bytes
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19408
>> UBI: try again
>> UBI: recover PEB 5817, move data to PEB 19409
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19409
>> UBI: try again
>> UBI: recover PEB 5817, move data to PEB 19410
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19410
>> UBI: try again
>> UBI: recover PEB 5817, move data to PEB 19411
>> UBI error: ubi_io_write: read-only mode
>> UBI warning: recover_peb: failed to write to PEB 19411
>> UBIFS error (pid 1047): ubifs_wbuf_sync_nolock: cannot write 2048
>> bytes to LEB 385:24576
>> UBIFS error (pid 1047): ubifs_bg_wbufs_sync: cannot sync
>> write-buffer, error -30
>> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
>> jhead 1, error -30
>> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30709,
>> error -30
>> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
>> jhead 1, error -30
>> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30710,
>> error -30
>> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
>> jhead 1, error -30
>> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30698,
>> error -30
>> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
>> jhead 1, error -30
>> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30711,
>> error -30
>>
>> I'd appreciate any hints on what can cause this. Is it a hardware
>> problem, mtd layer problem
>> or UBI problem ?
>
> It sounds like you are saying one MTD partition somehow affects another.
> You should check the MTD partitions are set up correctly. Are you using
> tools that make assumptions about which mtd partition is which?
>
> How do you erase the NOR flash? Is the device node (/dev/mtd...)
> correct?
>
>
I use flash_eraseall /dev/mtd4 to erase NOR. The version of mtd-utils is
from
latest mtd-utils git tree. The device nodes for NOR (mtd4) and NAND (mtd7)
are correct:
crwxr-xr-x 1 root root 90, 8 2005-08-07 13:11 mtd4
crw-r--r-- 1 root root 90, 14 2008-07-16 18:51 mtd7
Felix.
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Adrian Hunter @ 2009-10-14 12:36 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org
In-Reply-To: <4AD5ADC9.30503@embedded-sol.com>
Felix Radensky wrote:
> Hi,
>
> I have a strange problem in linux-2.6.31 running on MPC8536DS board.
> It is 100% reproducible, by opening a 350MB tar file into ubifs volume
> on NAND flash, and starting erase of NOR flash partition right after that.
>
> If I don't start NOR erase, everything works fine. Also, If I run sync
> after
> tar, no problem occurs. The NOR flash is 32MB Spansion, NAND is
> 4GB Samsung.
>
> The error messages are as follows:
>
> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
> 5812:12288, written 0 bytes
> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5812
> UBI: recover PEB 5812, move data to PEB 19400
> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
> 5812:512, read 512 bytes
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
> 19400:512, written 0 bytes
> UBI warning: recover_peb: failed to write to PEB 19400
> UBI: try again
> UBI: recover PEB 5812, move data to PEB 19401
> UBI: run torture test for PEB 19400
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
> 19401:512, written 0 bytes
> UBI warning: recover_peb: failed to write to PEB 19401
> UBI: try again
> UBI: recover PEB 5812, move data to PEB 19402
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
> 19402:512, written 0 bytes
> UBI warning: recover_peb: failed to write to PEB 19402
> UBI: try again
> UBI: recover PEB 5812, move data to PEB 19403
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
> 19403:512, written 0 bytes
> UBI warning: recover_peb: failed to write to PEB 19403
> UBI warning: ubi_ro_mode: switch to read-only mode
> UBIFS error (pid 1149): ubifs_wbuf_write_nolock: cannot write 2522 bytes
> to LEB 389:10240, error -5
> UBIFS warning (pid 1149): ubifs_ro_mode: switched to read-only mode,
> error -5
> UBIFS error (pid 1149): do_writepage: cannot write page 0 of inode
> 30708, error -5
> UBIFS error (pid 1149): make_reservation: cannot reserve 858 bytes in
> jhead 2, error -30
> UBIFS error (pid 1149): do_writepage: cannot write page 2 of inode
> 29486, error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 721 bytes in
> jhead 2, error -30
> UBIFS error (pid 1149): do_writepage: cannot write page 1 of inode
> 30070, error -30
> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
> 5022:88064, written 0 bytes
> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5022
> UBI: recover PEB 5022, move data to PEB 19404
> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
> 5022:512, read 512 bytes
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19404
> UBI: try again
> UBI: recover PEB 5022, move data to PEB 19405
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19405
> UBI: try again
> UBI: recover PEB 5022, move data to PEB 19406
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19406
> UBI: try again
> UBI: recover PEB 5022, move data to PEB 19407
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19407
> UBIFS error (pid 1044): ubifs_wbuf_sync_nolock: cannot write 2048 bytes
> to LEB 788:86016
> UBIFS error (pid 1044): ubifs_bg_wbufs_sync: cannot sync write-buffer,
> error -30
> UBIFS warning (pid 1044): ubifs_ro_mode: switched to read-only mode,
> error -30
> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
> 5817:26624, written 0 bytes
> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5817
> UBI: recover PEB 5817, move data to PEB 19408
> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
> 5817:512, read 512 bytes
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19408
> UBI: try again
> UBI: recover PEB 5817, move data to PEB 19409
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19409
> UBI: try again
> UBI: recover PEB 5817, move data to PEB 19410
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19410
> UBI: try again
> UBI: recover PEB 5817, move data to PEB 19411
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19411
> UBIFS error (pid 1047): ubifs_wbuf_sync_nolock: cannot write 2048 bytes
> to LEB 385:24576
> UBIFS error (pid 1047): ubifs_bg_wbufs_sync: cannot sync write-buffer,
> error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
> jhead 1, error -30
> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30709,
> error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
> jhead 1, error -30
> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30710,
> error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
> jhead 1, error -30
> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30698,
> error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
> jhead 1, error -30
> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30711,
> error -30
>
> I'd appreciate any hints on what can cause this. Is it a hardware
> problem, mtd layer problem
> or UBI problem ?
It sounds like you are saying one MTD partition somehow affects another.
You should check the MTD partitions are set up correctly. Are you using
tools that make assumptions about which mtd partition is which?
How do you erase the NOR flash? Is the device node (/dev/mtd...) correct?
^ permalink raw reply
* Re: [PATCH] Ftrace : fix function_graph tracer OOPS
From: Steven Rostedt @ 2009-10-14 12:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1255500920.2347.41.camel@pasglop>
On Wed, 2009-10-14 at 17:15 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2009-10-14 at 11:43 +0530, Sachin Sant wrote:
>
> > Tested both the patches. Works fine.
>
> Thanks !
>
> Stephen, you merge these yourself or you need me to pick them up in
> -powerpc ?
>
Ben,
You can either pull from my repo (I synced with latest Linus), or you
can just suck in the patches. I can also resync with your repo if you
prefer.
Either way is fine with me. Just let me know which you did.
-- Steve
^ permalink raw reply
* [PATCH] powerpc: Prevent unsigned wrap in htab_dt_scan_page_sizes()
From: Roel Kluin @ 2009-10-14 12:12 UTC (permalink / raw)
To: paulus, benh, linuxppc-dev; +Cc: Andrew Morton
Check to prevent unsigned wrap of size before subtraction.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Is this maybe better or are we certain that size can't wrap?
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 1ade7eb..dd2d263 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -287,7 +287,7 @@ static int __init htab_dt_scan_page_sizes(unsigned long node,
DBG("Page sizes from device-tree:\n");
size /= 4;
cur_cpu_spec->cpu_features &= ~(CPU_FTR_16M_PAGE);
- while(size > 0) {
+ while(size >= 3) {
unsigned int shift = prop[0];
unsigned int slbenc = prop[1];
unsigned int lpnum = prop[2];
@@ -296,7 +296,7 @@ static int __init htab_dt_scan_page_sizes(unsigned long node,
int idx = -1;
size -= 3; prop += 3;
- while(size > 0 && lpnum) {
+ while(size >= 2 && lpnum) {
if (prop[0] == shift)
lpenc = prop[1];
prop += 2; size -= 2;
^ permalink raw reply related
* UBIFS problem on MPC8536DS
From: Felix Radensky @ 2009-10-14 10:54 UTC (permalink / raw)
To: linux-mtd, linuxppc-dev
Hi,
I have a strange problem in linux-2.6.31 running on MPC8536DS board.
It is 100% reproducible, by opening a 350MB tar file into ubifs volume
on NAND flash, and starting erase of NOR flash partition right after that.
If I don't start NOR erase, everything works fine. Also, If I run sync
after
tar, no problem occurs. The NOR flash is 32MB Spansion, NAND is
4GB Samsung.
The error messages are as follows:
UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
5812:12288, written 0 bytes
UBI warning: ubi_eba_write_leb: failed to write data to PEB 5812
UBI: recover PEB 5812, move data to PEB 19400
UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
5812:512, read 512 bytes
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
19400:512, written 0 bytes
UBI warning: recover_peb: failed to write to PEB 19400
UBI: try again
UBI: recover PEB 5812, move data to PEB 19401
UBI: run torture test for PEB 19400
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
19401:512, written 0 bytes
UBI warning: recover_peb: failed to write to PEB 19401
UBI: try again
UBI: recover PEB 5812, move data to PEB 19402
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
19402:512, written 0 bytes
UBI warning: recover_peb: failed to write to PEB 19402
UBI: try again
UBI: recover PEB 5812, move data to PEB 19403
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
19403:512, written 0 bytes
UBI warning: recover_peb: failed to write to PEB 19403
UBI warning: ubi_ro_mode: switch to read-only mode
UBIFS error (pid 1149): ubifs_wbuf_write_nolock: cannot write 2522 bytes
to LEB 389:10240, error -5
UBIFS warning (pid 1149): ubifs_ro_mode: switched to read-only mode,
error -5
UBIFS error (pid 1149): do_writepage: cannot write page 0 of inode
30708, error -5
UBIFS error (pid 1149): make_reservation: cannot reserve 858 bytes in
jhead 2, error -30
UBIFS error (pid 1149): do_writepage: cannot write page 2 of inode
29486, error -30
UBIFS error (pid 1149): make_reservation: cannot reserve 721 bytes in
jhead 2, error -30
UBIFS error (pid 1149): do_writepage: cannot write page 1 of inode
30070, error -30
UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
5022:88064, written 0 bytes
UBI warning: ubi_eba_write_leb: failed to write data to PEB 5022
UBI: recover PEB 5022, move data to PEB 19404
UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
5022:512, read 512 bytes
UBI error: ubi_io_write: read-only mode
UBI warning: recover_peb: failed to write to PEB 19404
UBI: try again
UBI: recover PEB 5022, move data to PEB 19405
UBI error: ubi_io_write: read-only mode
UBI warning: recover_peb: failed to write to PEB 19405
UBI: try again
UBI: recover PEB 5022, move data to PEB 19406
UBI error: ubi_io_write: read-only mode
UBI warning: recover_peb: failed to write to PEB 19406
UBI: try again
UBI: recover PEB 5022, move data to PEB 19407
UBI error: ubi_io_write: read-only mode
UBI warning: recover_peb: failed to write to PEB 19407
UBIFS error (pid 1044): ubifs_wbuf_sync_nolock: cannot write 2048 bytes
to LEB 788:86016
UBIFS error (pid 1044): ubifs_bg_wbufs_sync: cannot sync write-buffer,
error -30
UBIFS warning (pid 1044): ubifs_ro_mode: switched to read-only mode,
error -30
UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
5817:26624, written 0 bytes
UBI warning: ubi_eba_write_leb: failed to write data to PEB 5817
UBI: recover PEB 5817, move data to PEB 19408
UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
5817:512, read 512 bytes
UBI error: ubi_io_write: read-only mode
UBI warning: recover_peb: failed to write to PEB 19408
UBI: try again
UBI: recover PEB 5817, move data to PEB 19409
UBI error: ubi_io_write: read-only mode
UBI warning: recover_peb: failed to write to PEB 19409
UBI: try again
UBI: recover PEB 5817, move data to PEB 19410
UBI error: ubi_io_write: read-only mode
UBI warning: recover_peb: failed to write to PEB 19410
UBI: try again
UBI: recover PEB 5817, move data to PEB 19411
UBI error: ubi_io_write: read-only mode
UBI warning: recover_peb: failed to write to PEB 19411
UBIFS error (pid 1047): ubifs_wbuf_sync_nolock: cannot write 2048 bytes
to LEB 385:24576
UBIFS error (pid 1047): ubifs_bg_wbufs_sync: cannot sync write-buffer,
error -30
UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
jhead 1, error -30
UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30709,
error -30
UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
jhead 1, error -30
UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30710,
error -30
UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
jhead 1, error -30
UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30698,
error -30
UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
jhead 1, error -30
UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30711,
error -30
I'd appreciate any hints on what can cause this. Is it a hardware
problem, mtd layer problem
or UBI problem ?
Thanks a lot in advance.
Felix.
^ permalink raw reply
* RE: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Richard Cochran @ 2009-10-14 7:41 UTC (permalink / raw)
To: 'Scott Wood', 'Roland Lezuo'
Cc: 'linuxppc-dev@lists.ozlabs.org'
In-Reply-To: <20090909182227.GA8215@b07421-ec1.am.freescale.net>
>-----Original Message-----
>From: linuxppc-dev-bounces On Behalf Of Scott Wood
>Sent: Wednesday, September 09, 2009 8:22 PM
>To: Roland Lezuo
>Cc: linuxppc-dev@lists.ozlabs.org
>Subject: Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
>
>On Fri, Sep 04, 2009 at 12:31:25PM +0200, Roland Lezuo wrote:
>> The following patch is needed to correctly assign the IRQs for the
>> gianfar driver on the MPC8313ERDB-revc boards. ERR and TX are swapped
>> as well as the interrupt lines for the two devices.
>
>And it will incorrectly assign them on older revisions of the chip.
>
>We really should have a u-boot fixup based on SVR.
Why not just offer different dts files, one for each board revision?
Something like:
mpc8313erdb-revA.dts
mpc8313erdb-revB.dts
mpc8313erdb-revC.dts
Richard
^ permalink raw reply
* Re: [v8 PATCH 2/8]: cpuidle: implement a list based approach to register a set of idle routines.
From: Andi Kleen @ 2009-10-14 7:18 UTC (permalink / raw)
To: Arun R Bharadwaj
Cc: linux-arch, Peter Zijlstra, linux-kernel, linux-acpi, Andi Kleen,
Ingo Molnar, linuxppc-dev, Arjan van de Ven
In-Reply-To: <20091014061727.GA8605@linux.vnet.ibm.com>
> How about something like this..
> If the arch does not enable CONFIG_CPU_IDLE, the cpuidle_idle_call
> which is called from cpu_idle() should call default_idle without
> involving the registering cpuidle steps. This should prevent bloating
> up of the kernel for archs which dont want to use cpuidle.
On x86 some people want small kernel too, so selecting it on a architecture
granuality is not good. Also you can make it default, you just need
to slim it down first.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* [PATCH] Xilinx LL-TEMAC: Add Netpoll controller support
From: santosh shukla @ 2009-10-14 6:39 UTC (permalink / raw)
To: linuxppc-dev
From: Santosh Shukla <sshukla@sh.mvista.com>
Date: Tue, 13 Oct 2009 18:55:57 +0530
Subject: [PATCH] Xilinx LL-TEMAC: Add Netpoll controller support
Adding Netpoll controller support to Xilinx LL-TEMAC ethernet
driver.Replaced Rx, Tx tasklet schedule call with their handlers,
Added correct version of call which can execute interrupt on/off
context i.e. dev_kfree_skb_any().
---
drivers/net/xilinx_lltemac/xlltemac_main.c | 41 +++++++++++++++++++++++++++-
1 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/drivers/net/xilinx_lltemac/xlltemac_main.c b/drivers/net/xilinx_lltemac/xlltemac_main.c
index b245422..697f474 100644
--- a/drivers/net/xilinx_lltemac/xlltemac_main.c
+++ b/drivers/net/xilinx_lltemac/xlltemac_main.c
@@ -87,11 +87,18 @@
#define BUFFER_ALIGNSEND_PERF(adr) ((ALIGNMENT_SEND_PERF - ((u32) adr)) % 32)
#define BUFFER_ALIGNRECV(adr) ((ALIGNMENT_RECV - ((u32) adr)) % 32)
+#ifndef CONFIG_NET_POLL_CONTROLLER
/* Default TX/RX Threshold and waitbound values for SGDMA mode */
#define DFT_TX_THRESHOLD 24
#define DFT_TX_WAITBOUND 254
#define DFT_RX_THRESHOLD 4
#define DFT_RX_WAITBOUND 254
+#else
+#define DFT_TX_THRESHOLD 1
+#define DFT_TX_WAITBOUND 0
+#define DFT_RX_THRESHOLD 1
+#define DFT_RX_WAITBOUND 0
+#endif
#define XTE_AUTOSTRIPPING 1
@@ -1097,7 +1104,11 @@ static irqreturn_t xenet_dma_rx_interrupt(int irq, void *dev_id)
list_add_tail(&lp->rcv, &receivedQueue);
XLlDma_mBdRingIntDisable(&lp->Dma.RxBdRing,
XLLDMA_CR_IRQ_ALL_EN_MASK);
+#ifndef CONFIG_NET_POLL_CONTROLLER
tasklet_schedule(&DmaRecvBH);
+#else
+ DmaRecvHandlerBH(0);
+#endif
}
spin_unlock_irqrestore(&receivedQueueSpin, flags);
}
@@ -1134,7 +1145,11 @@ static irqreturn_t xenet_dma_tx_interrupt(int irq, void *dev_id)
list_add_tail(&lp->xmit, &sentQueue);
XLlDma_mBdRingIntDisable(&lp->Dma.TxBdRing,
XLLDMA_CR_IRQ_ALL_EN_MASK);
+#ifndef CONFIG_NET_POLL_CONTROLLER
tasklet_schedule(&DmaSendBH);
+#else
+ DmaSendHandlerBH(0);
+#endif
}
spin_unlock_irqrestore(&sentQueueSpin, flags);
}
@@ -1711,11 +1726,15 @@ static int xenet_DmaSend(struct sk_buff *skb, struct net_device *dev)
* SgAlloc, SgCommit sequence, which also exists in DmaSendHandlerBH Bottom
* Half, or triggered by other processor in SMP case.
*/
+#ifndef CONFIG_NET_POLL_CONTROLLER
spin_lock_bh(&XTE_tx_spinlock);
+#endif
xenet_DmaSend_internal(skb, dev);
+#ifndef CONFIG_NET_POLL_CONTROLLER
spin_unlock_bh(&XTE_tx_spinlock);
+#endif
return 0;
}
@@ -1764,7 +1783,7 @@ static void DmaSendHandlerBH(unsigned long p)
skb = (struct sk_buff *)
XLlDma_mBdGetId(BdCurPtr);
if (skb)
- dev_kfree_skb(skb);
+ dev_kfree_skb_any(skb);
/* reset BD id */
XLlDma_mBdSetId(BdCurPtr, NULL);
@@ -3220,6 +3239,23 @@ static int detect_phy(struct net_local *lp, char *dev_name)
return 0; /* default to zero */
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void
+lltemac_poll_controller(struct net_device *ndev)
+{
+ struct net_local *lp = netdev_priv(ndev);
+
+ disable_irq(lp->dma_irq_s);
+ disable_irq(lp->dma_irq_r);
+
+ xenet_dma_tx_interrupt(lp->dma_irq_s, ndev);
+ xenet_dma_rx_interrupt(lp->dma_irq_r, ndev);
+
+ enable_irq(lp->dma_irq_s);
+ enable_irq(lp->dma_irq_r);
+}
+#endif
+
static struct net_device_ops xilinx_netdev_ops;
/* From include/linux/ethtool.h */
@@ -3491,6 +3527,9 @@ static struct net_device_ops xilinx_netdev_ops = {
.ndo_change_mtu = xenet_change_mtu,
.ndo_tx_timeout = xenet_tx_timeout,
.ndo_get_stats = xenet_get_stats,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = lltemac_poll_controller,
+#endif
};
static struct of_device_id xtenet_fifo_of_match[] = {
--
1.6.3.3.220.g609a0
^ permalink raw reply related
* Xilinx LL-TEMAC: Add Netpoll controller support
From: santosh shukla @ 2009-10-14 5:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Srikanth Krishnakar, john.linn
From: Santosh Shukla <sshukla@sh.mvista.com>
Date: Tue, 13 Oct 2009 18:55:57 +0530
Subject: [PATCH] Xilinx LL-TEMAC: Add Netpoll controller support
Adding Netpoll controller support to Xilinx LL-TEMAC ethernet
driver. Replaced Rx, Tx tasklets schedule call with their handlers,
Added correct version of call which can execute interrupt on/off
context i.e. dev_kfree_skb_any().
---
drivers/net/xilinx_lltemac/xlltemac_main.c | 41 +++++++++++++++++++++++++++-
1 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/drivers/net/xilinx_lltemac/xlltemac_main.c b/drivers/net/xilinx_lltemac/xlltemac_main.c
index b245422..697f474 100644
--- a/drivers/net/xilinx_lltemac/xlltemac_main.c
+++ b/drivers/net/xilinx_lltemac/xlltemac_main.c
@@ -87,11 +87,18 @@
#define BUFFER_ALIGNSEND_PERF(adr) ((ALIGNMENT_SEND_PERF - ((u32) adr)) % 32)
#define BUFFER_ALIGNRECV(adr) ((ALIGNMENT_RECV - ((u32) adr)) % 32)
+#ifndef CONFIG_NET_POLL_CONTROLLER
/* Default TX/RX Threshold and waitbound values for SGDMA mode */
#define DFT_TX_THRESHOLD 24
#define DFT_TX_WAITBOUND 254
#define DFT_RX_THRESHOLD 4
#define DFT_RX_WAITBOUND 254
+#else
+#define DFT_TX_THRESHOLD 1
+#define DFT_TX_WAITBOUND 0
+#define DFT_RX_THRESHOLD 1
+#define DFT_RX_WAITBOUND 0
+#endif
#define XTE_AUTOSTRIPPING 1
@@ -1097,7 +1104,11 @@ static irqreturn_t xenet_dma_rx_interrupt(int irq, void *dev_id)
list_add_tail(&lp->rcv, &receivedQueue);
XLlDma_mBdRingIntDisable(&lp->Dma.RxBdRing,
XLLDMA_CR_IRQ_ALL_EN_MASK);
+#ifndef CONFIG_NET_POLL_CONTROLLER
tasklet_schedule(&DmaRecvBH);
+#else
+ DmaRecvHandlerBH(0);
+#endif
}
spin_unlock_irqrestore(&receivedQueueSpin, flags);
}
@@ -1134,7 +1145,11 @@ static irqreturn_t xenet_dma_tx_interrupt(int irq, void *dev_id)
list_add_tail(&lp->xmit, &sentQueue);
XLlDma_mBdRingIntDisable(&lp->Dma.TxBdRing,
XLLDMA_CR_IRQ_ALL_EN_MASK);
+#ifndef CONFIG_NET_POLL_CONTROLLER
tasklet_schedule(&DmaSendBH);
+#else
+ DmaSendHandlerBH(0);
+#endif
}
spin_unlock_irqrestore(&sentQueueSpin, flags);
}
@@ -1711,11 +1726,15 @@ static int xenet_DmaSend(struct sk_buff *skb, struct net_device *dev)
* SgAlloc, SgCommit sequence, which also exists in DmaSendHandlerBH Bottom
* Half, or triggered by other processor in SMP case.
*/
+#ifndef CONFIG_NET_POLL_CONTROLLER
spin_lock_bh(&XTE_tx_spinlock);
+#endif
xenet_DmaSend_internal(skb, dev);
+#ifndef CONFIG_NET_POLL_CONTROLLER
spin_unlock_bh(&XTE_tx_spinlock);
+#endif
return 0;
}
@@ -1764,7 +1783,7 @@ static void DmaSendHandlerBH(unsigned long p)
skb = (struct sk_buff *)
XLlDma_mBdGetId(BdCurPtr);
if (skb)
- dev_kfree_skb(skb);
+ dev_kfree_skb_any(skb);
/* reset BD id */
XLlDma_mBdSetId(BdCurPtr, NULL);
@@ -3220,6 +3239,23 @@ static int detect_phy(struct net_local *lp, char *dev_name)
return 0; /* default to zero */
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void
+lltemac_poll_controller(struct net_device *ndev)
+{
+ struct net_local *lp = netdev_priv(ndev);
+
+ disable_irq(lp->dma_irq_s);
+ disable_irq(lp->dma_irq_r);
+
+ xenet_dma_tx_interrupt(lp->dma_irq_s, ndev);
+ xenet_dma_rx_interrupt(lp->dma_irq_r, ndev);
+
+ enable_irq(lp->dma_irq_s);
+ enable_irq(lp->dma_irq_r);
+}
+#endif
+
static struct net_device_ops xilinx_netdev_ops;
/* From include/linux/ethtool.h */
@@ -3491,6 +3527,9 @@ static struct net_device_ops xilinx_netdev_ops = {
.ndo_change_mtu = xenet_change_mtu,
.ndo_tx_timeout = xenet_tx_timeout,
.ndo_get_stats = xenet_get_stats,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = lltemac_poll_controller,
+#endif
};
static struct of_device_id xtenet_fifo_of_match[] = {
--
1.6.3.3.220.g609a0
^ permalink raw reply related
* Re: [v8 PATCH 1/8]: cpuidle: cleanup drivers/cpuidle/cpuidle.c
From: Arun R Bharadwaj @ 2009-10-14 6:24 UTC (permalink / raw)
To: Balbir Singh
Cc: linux-arch, Peter Zijlstra, linux-kernel, linux-acpi,
Arun Bharadwaj, Ingo Molnar, linuxppc-dev, Arjan van de Ven
In-Reply-To: <20091012113602.GC3007@balbir.in.ibm.com>
* Balbir Singh <balbir@linux.vnet.ibm.com> [2009-10-12 17:06:02]:
> * Arun R B <arun@linux.vnet.ibm.com> [2009-10-08 15:19:42]:
>
> > * Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-10-08 15:18:28]:
> >
> > This patch cleans up drivers/cpuidle/cpuidle.c
> > Earlier cpuidle assumed pm_idle as the default idle loop. Break that
> > assumption and make it more generic. cpuidle_idle_call() which is the
> > main idle loop of cpuidle is to be called by architectures which have
> > registered to cpuidle.
> >
> > Remove routines cpuidle_install/uninstall_idle_handler() which are not
> > needed anymore.
> >
> >
>
> [snip]
>
> /**
> > - * cpuidle_install_idle_handler - installs the cpuidle idle loop handler
> > - */
> > -void cpuidle_install_idle_handler(void)
> > -{
> > - if (enabled_devices && (pm_idle != cpuidle_idle_call)) {
> > - /* Make sure all changes finished before we switch to new idle */
> > - smp_wmb();
> > - pm_idle = cpuidle_idle_call;
> > - }
> > -}
> > -
> > -/**
> > - * cpuidle_uninstall_idle_handler - uninstalls the cpuidle idle loop handler
> > - */
> > -void cpuidle_uninstall_idle_handler(void)
> > -{
> > - if (enabled_devices && pm_idle_old && (pm_idle != pm_idle_old)) {
> > - pm_idle = pm_idle_old;
> > - cpuidle_kick_cpus();
> > - }
> > -}
> > -
>
> I see the routines above being called in from
> cpuidle_pause/resume_and_lock/unlock below and they are entries from
> ACPI on ACPI_PROCESSOR_NOTIFY_POWER and from the hotplug path, could
> you test them to make sure they are not broken. We also seem to be
> missing a cpuidle_kick_cpus() in cpuidle_pause_and_lock()
>
> [snip]
>
Hi Balbir,
yes, we definitely need a cpuidle_kick_cpus() in
cpuidle_pause_and_lock() since this is used while disabling the
cpuidle_device and the cpus need to be kicked out of the idle states.
I will test this modified code and see if it breaks hotplug.
thanks,
arun
> --
> Balbir
^ permalink raw reply
* Re: [PATCH] powerpc: tracing: Add powerpc tracepoints for interrupt entry and exit
From: Benjamin Herrenschmidt @ 2009-10-14 6:17 UTC (permalink / raw)
To: Anton Blanchard
Cc: Frederic Weisbecker, Ingo Molnar, linuxppc-dev, Steven Rostedt
In-Reply-To: <20091006040554.GD16073@kryten>
On Tue, 2009-10-06 at 15:05 +1100, Anton Blanchard wrote:
> This patch adds powerpc specific tracepoints for interrupt entry and exit.
.../....
Breaks 6xx_defconfig:
In file included from /home/benh/linux-powerpc-test/include/linux/device.h:23,
from /home/benh/linux-powerpc-test/arch/powerpc/include/asm/io.h:21,
from /home/benh/linux-powerpc-test/arch/powerpc/include/asm/pgtable-ppc32.h:9,
from /home/benh/linux-powerpc-test/arch/powerpc/include/asm/pgtable.h:25,
from /home/benh/linux-powerpc-test/include/linux/mm.h:39,
from /home/benh/linux-powerpc-test/include/linux/ring_buffer.h:5,
from /home/benh/linux-powerpc-test/include/linux/ftrace_event.h:4,
from /home/benh/linux-powerpc-test/include/trace/ftrace.h:19,
from /home/benh/linux-powerpc-test/include/trace/define_trace.h:61,
from /home/benh/linux-powerpc-test/arch/powerpc/include/asm/trace.h:53,
from /home/benh/linux-powerpc-test/arch/powerpc/kernel/trace-events.c:3:
/home/benh/linux-powerpc-test/include/linux/module.h: In function ‘__module_get’:
/home/benh/linux-powerpc-test/include/linux/module.h:471: error: implicit declaration of function ‘trace_module_get’
Cheers,
Ben.
> While we already have generic irq_handler_entry and irq_handler_exit
> tracepoints there are cases on our virtualised powerpc machines where an
> interrupt is presented to the OS, but subsequently handled by the hypervisor.
> This means no OS interrupt handler is invoked.
>
> Here is an example on a POWER6 machine with the patch below applied:
>
> <idle>-0 [006] 3243.949840744: irq_entry: pt_regs=c0000000ce31fb10
> <idle>-0 [006] 3243.949850520: irq_exit: pt_regs=c0000000ce31fb10
>
> <idle>-0 [007] 3243.950218208: irq_entry: pt_regs=c0000000ce323b10
> <idle>-0 [007] 3243.950224080: irq_exit: pt_regs=c0000000ce323b10
>
> <idle>-0 [000] 3244.021879320: irq_entry: pt_regs=c000000000a63aa0
> <idle>-0 [000] 3244.021883616: irq_handler_entry: irq=87 handler=eth0
> <idle>-0 [000] 3244.021887328: irq_handler_exit: irq=87 return=handled
> <idle>-0 [000] 3244.021897408: irq_exit: pt_regs=c000000000a63aa0
>
> Here we see two phantom interrupts (no handler was invoked), followed
> by a real interrupt for eth0. Without the tracepoints in this patch we
> would have missed the phantom interrupts.
>
> Since these would be the first arch specific tracepoints, I'd like to make
> sure we agree on naming. The tracepoints live in events/powerpc/*, but I'm
> wondering if the tracepoint name should also contain the arch name, eg
> powerpc_irq_entry/powerpc_irq_exit. Thoughts?
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> --
>
> Index: linux.trees.git/arch/powerpc/include/asm/trace.h
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ linux.trees.git/arch/powerpc/include/asm/trace.h 2009-10-06 14:54:25.000000000 +1100
> @@ -0,0 +1,53 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM powerpc
> +
> +#if !defined(_TRACE_POWERPC_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_POWERPC_H
> +
> +#include <linux/tracepoint.h>
> +
> +struct pt_regs;
> +
> +TRACE_EVENT(irq_entry,
> +
> + TP_PROTO(struct pt_regs *regs),
> +
> + TP_ARGS(regs),
> +
> + TP_STRUCT__entry(
> + __field(struct pt_regs *, regs)
> + ),
> +
> + TP_fast_assign(
> + __entry->regs = regs;
> + ),
> +
> + TP_printk("pt_regs=%p", __entry->regs)
> +);
> +
> +TRACE_EVENT(irq_exit,
> +
> + TP_PROTO(struct pt_regs *regs),
> +
> + TP_ARGS(regs),
> +
> + TP_STRUCT__entry(
> + __field(struct pt_regs *, regs)
> + ),
> +
> + TP_fast_assign(
> + __entry->regs = regs;
> + ),
> +
> + TP_printk("pt_regs=%p", __entry->regs)
> +);
> +
> +#endif /* _TRACE_POWERPC_H */
> +
> +#undef TRACE_INCLUDE_PATH
> +#undef TRACE_INCLUDE_FILE
> +
> +#define TRACE_INCLUDE_PATH asm
> +#define TRACE_INCLUDE_FILE trace
> +
> +#include <trace/define_trace.h>
> Index: linux.trees.git/arch/powerpc/kernel/Makefile
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/kernel/Makefile 2009-10-06 14:02:03.000000000 +1100
> +++ linux.trees.git/arch/powerpc/kernel/Makefile 2009-10-06 14:38:51.000000000 +1100
> @@ -115,6 +115,8 @@ ifneq ($(CONFIG_XMON)$(CONFIG_KEXEC),)
> obj-y += ppc_save_regs.o
> endif
>
> +obj-$(CONFIG_TRACEPOINTS) += trace-events.o
> +
> # Disable GCOV in odd or sensitive code
> GCOV_PROFILE_prom_init.o := n
> GCOV_PROFILE_ftrace.o := n
> Index: linux.trees.git/arch/powerpc/kernel/trace-events.c
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ linux.trees.git/arch/powerpc/kernel/trace-events.c 2009-10-06 14:44:57.000000000 +1100
> @@ -0,0 +1,3 @@
> +#include <linux/slab.h>
> +#define CREATE_TRACE_POINTS
> +#include <asm/trace.h>
> Index: linux.trees.git/arch/powerpc/kernel/irq.c
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/kernel/irq.c 2009-10-06 14:02:15.000000000 +1100
> +++ linux.trees.git/arch/powerpc/kernel/irq.c 2009-10-06 14:13:08.000000000 +1100
> @@ -54,6 +54,7 @@
> #include <linux/pci.h>
> #include <linux/debugfs.h>
> #include <linux/perf_event.h>
> +#include <asm/trace.h>
>
> #include <asm/uaccess.h>
> #include <asm/system.h>
> @@ -325,6 +326,8 @@ void do_IRQ(struct pt_regs *regs)
> struct pt_regs *old_regs = set_irq_regs(regs);
> unsigned int irq;
>
> + trace_irq_entry(regs);
> +
> irq_enter();
>
> check_stack_overflow();
> @@ -348,6 +351,8 @@ void do_IRQ(struct pt_regs *regs)
> timer_interrupt(regs);
> }
> #endif
> +
> + trace_irq_exit(regs);
> }
>
> void __init init_IRQ(void)
^ permalink raw reply
* Re: [v8 PATCH 2/8]: cpuidle: implement a list based approach to register a set of idle routines.
From: Arun R Bharadwaj @ 2009-10-14 6:17 UTC (permalink / raw)
To: Andi Kleen
Cc: linux-arch, Peter Zijlstra, linux-kernel, linux-acpi,
Arun Bharadwaj, Ingo Molnar, linuxppc-dev, Arjan van de Ven
In-Reply-To: <8763akh4re.fsf@basil.nowhere.org>
* Andi Kleen <andi@firstfloor.org> [2009-10-12 20:00:05]:
> Peter Zijlstra <a.p.zijlstra@chello.nl> writes:
> >
> > So does it make sense to have a set of sets?
> >
> > Why not integrate them all into one set to be ruled by this governor
> > thing?
>
> cpuidle is currently optional, that is why the two level hierarchy
> is there so that you can still have simple idle selection without it.
>
> % size drivers/cpuidle/*.o
> text data bss dec hex filename
> 5514 1416 44 6974 1b3e drivers/cpuidle/built-in.o
>
> Adding it unconditionally would add ~7k to everyone who wants idle functions.
>
> I think making it unconditional would require putting it on a serious
> diet first.
>
Hi Andi,
Yes, this is a valid point.
How about something like this..
If the arch does not enable CONFIG_CPU_IDLE, the cpuidle_idle_call
which is called from cpu_idle() should call default_idle without
involving the registering cpuidle steps. This should prevent bloating
up of the kernel for archs which dont want to use cpuidle.
--arun
> -Andi
> --
> ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH] Ftrace : fix function_graph tracer OOPS
From: Benjamin Herrenschmidt @ 2009-10-14 6:15 UTC (permalink / raw)
To: Sachin Sant; +Cc: linuxppc-dev, rostedt
In-Reply-To: <4AD56C05.9030602@in.ibm.com>
On Wed, 2009-10-14 at 11:43 +0530, Sachin Sant wrote:
> Tested both the patches. Works fine.
Thanks !
Stephen, you merge these yourself or you need me to pick them up in
-powerpc ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Ftrace : fix function_graph tracer OOPS
From: Sachin Sant @ 2009-10-14 6:13 UTC (permalink / raw)
To: rostedt; +Cc: linuxppc-dev
In-Reply-To: <1255489284.7113.3121.camel@gandalf.stny.rr.com>
Steven Rostedt wrote:
> On Thu, 2009-10-08 at 20:21 +0530, Sachin Sant wrote:
>
>> Switch to LOAD_REG_ADDR().
>>
>> Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
>> ---
>> diff -Naurp old/arch/powerpc/kernel/entry_64.S
>> new/arch/powerpc/kernel/entry_64.S
>> --- old/arch/powerpc/kernel/entry_64.S 2009-10-08 18:37:44.000000000
>> +0530
>> +++ new/arch/powerpc/kernel/entry_64.S 2009-10-08 18:34:33.000000000
>> +0530
>> @@ -1038,8 +1038,8 @@ _GLOBAL(mod_return_to_handler)
>> * We are in a module using the module's TOC.
>> * Switch to our TOC to run inside the core kernel.
>> */
>> - LOAD_REG_IMMEDIATE(r4,ftrace_return_to_handler)
>> - ld r2, 8(r4)
>> + ld r2, PACATOC(r13)
>> + LOAD_REG_ADDR(r4,ftrace_return_to_handler)
>>
>
> Actually, the loading of this register is not needed. The original used
> the loading to get the r2.
>
> I actually wrote a fix for this a month ago. I never sent it out because
> I was distracted by other issues.
>
> I'll send out the two patches I had now.
>
> Could yo test them?
>
Tested both the patches. Works fine.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox