Re: Gianfar driver failing on MPC8641D based board
Martyn Welch wrote: I have recently attempted to boot an 8641D based board from an NFS root. The boot process grinds to a halt not long after the first access of the NFS root and I receive multiple nfs: server 192.168.0.1 not responding, still trying messages. Wireshark suggests that there is no further traffic from this board at this point on. The NFS server seems to eventually try sending duplicate packets it's already sent, which results in nfs: server 192.168.0.1 OK messages, but the not responding messages resume with no further traffic from the board. I am able to boot to a ramdisk fine and the network seems to work - though I haven't really pushed the interface from it. I have attempted to git bisect, though I wasn't able to get much further than discovering the problem was introduced in the 2.6.33 merge window - at which point the gianfar network driver fails to compile (I have tried to git bisect skip many, many times to no avail). NFS booting fails for this board on todays linux-next, the master branch of Kumar's PPC tree and the head of the main tree. I have also been able to NFS boot from a random x86 based board that I have, using the head of the main tree and the linux-next tree. Copying the gianfar drivers from 2.6.32 into the head of the main tree restores the correct behaviour and I'm able to NFS boot. I have heard from others that the latest drivers work on 83xx and 85xx based boards, but it seems to be broken on at least the 8641D. I can see there has been a fair amount of work done on the gianfar driver, I assume that this is a bug introduced by the multiple queue support, but I'm way out of my depth on this. I have just compiled 2.6.33 for the Freescale MPC8641_HPCN demo board and am having still experiencing the problems outlined in my previous email, though I have noticed that I tend to be able to boot from cold, but my boot fails on reboot. Hitting the reset button doesn't help, I need to actually power the machine on and off again for it to work. As before, I'm way out of my depth in this, any one have any ideas? Below is a dump of the failed boot process: U-Boot 2009.01-00181-gc1b7c70 (Jan 30 2009 - 11:17:31) Freescale PowerPC CPU: Core: E600 Core 0, Version: 0.2, (0x80040202) System: Unknown, Version: 2.0, (0x80900120) Clocks: CPU:1000 MHz, MPX: 400 MHz, DDR: 200 MHz, LBC: 25 MHz L2: Enabled Board: MPC8641HPCN, System ID: 0x10, System Version: 0x10, FPGA Version: 0x22 I2C: ready DRAM: DDR: 1 GB FLASH: 8 MB Invalid ID (ff ff ff ff) Scanning PCI bus 01 PCI-EXPRESS 1 on bus 00 - 02 PCI-EXPRESS 2 on bus 03 - 03 Video: No radeon video card found! In:serial Out: serial Err: serial SCSI: AHCI 0001. 32 slots 4 ports 3 Gbps 0xf impl IDE mode flags: ncq ilck pm led clo pmp pio slum part scanning bus for devices... Net: eTSEC1, eTSEC2, eTSEC3, eTSEC4 = tftp 400 hpcn/uImage-torvalds-linux-2.6 Speed: 1000, full duplex Using eTSEC1 device TFTP from server 192.168.0.1; our IP address is 192.168.0.30 Filename 'hpcn/uImage-torvalds-linux-2.6'. Load address: 0x400 Loading: # # ### done Bytes transferred = 2709050 (29563a hex) = tftp 500 hpcn/mpc8641_hpcn-torvalds-linux-2.6.dtb Speed: 1000, full duplex Using eTSEC1 device TFTP from server 192.168.0.1; our IP address is 192.168.0.30 Filename 'hpcn/mpc8641_hpcn-torvalds-linux-2.6.dtb'. Load address: 0x500 Loading: # done Bytes transferred = 11523 (2d03 hex) = setenv bootargs root=/dev/nfs rw nfsroot=192.168.0.1:/tftpboot/hpcn/root/ i = bootm 400 - 500 WARNING: adjusting available memory to 1000 ## Booting kernel from Legacy Image at 0400 ... Image Name: Linux-2.6.33-1-gbaac35c Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:2708986 Bytes = 2.6 MB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 0500 Booting using the fdt blob at 0x500 Uncompressing Kernel Image ... OK Loading Device Tree to 007fa000, end 007ffd02 ... OK Using MPC86xx HPCN machine description Total memory = 1024MB; using 2048kB for hash table (at cfe0) Linux version 2.6.33-1-gbaac35c (welc...@es-j7s4d2j) (gcc version 4.1.2) #20 CPU maps initialized for 1 thread per core bootconsole [udbg0] enabled setup_arch: bootmem mpc86xx_hpcn_setup_arch() Found FSL PCI host bridge at 0xffe08000. Firmware bus number: 0-2 PCI host bridge /p...@ffe08000 (primary) ranges: MEM 0x8000..0x9fff - 0x8000 IO 0xffc0..0xffc0 - 0x /p...@ffe08000: PCICSRBAR @ 0xfff0 Found FSL PCI host bridge at 0xffe09000. Firmware bus number: 0-0 PCI host bridge
Re: PCI on 834x
On 02/24/2010 04:08 PM, Gary Thomas wrote: On 02/24/2010 03:25 PM, Kumar Gala wrote: On Feb 24, 2010, at 4:14 PM, Gary Thomas wrote: On 02/24/2010 01:51 PM, Anton Vorontsov wrote: On Wed, Feb 24, 2010 at 02:26:20PM -0600, Scott Wood wrote: Gary Thomas wrote: Yes, I'm using the exact same kernel with these two different PCI setups (done by the boot loader). Restricting the memory via mem=128M has no effect - the PCI layout is the same. I think the outbound window size is required because of how the Linux PCI remaps the space (note in my dumps that it put the MMIO of the boards starting at 0xD000 when the inbound window is 0x1000) I see where the amount of RAM is mattering -- Linux is assigning outbound I/O space to the PCI controller itself (device 00:00.0) and the amount that it asks for seems to differ based on memory size. Linux ought to skip that device when assigning resources. Some platforms do this (search for pci_exclude_device), but it seems to be missing on 83xx. Actually, 83xx had these exclude_device hooks, but they were removed: commit d8f1324a5063c833862328ceafabc53ac3cc4f71 Author: Kumar Galaga...@kernel.crashing.org Date: Wed Sep 12 22:14:10 2007 -0500 [POWERPC] 83xx: Removed PCI exclude of PHB Now that the generic code doesn't assign resources for Freescale PHBs we dont have to explicitly exclude it. Signed-off-by: Kumar Galaga...@kernel.crashing.org May be the generic code started to assign the resources again? That cracked it; I re-enabled the exclusion of the bridge and now it's all working fine. Thanks for the help Note: I'm working with a fairly old kernel, so these results would have to be reworked against the latest. Odd that the generic code isn't dealing with that for you. Remember it's an old kernel (2.6.28), so who knows the status. As I said, I'll revisit this when I move to a newer kernel. I may have been too hasty pronouncing this fixed. Indeed, the SATA interface now works, but my video card (Fujitsu Coral-P) does not work when it's mapped at the bottom of the PCI space :-( With the bridge mapped, the video ends up at a non-zero address (0xC800..0xCFFF). If it gets mapped to 0xC000, it fails to respond to MMIO accesses. Any ideas how I might get around this? Is there a way to force the PCI allocator to start somewhere other than [relative] zero? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar driver failing on MPC8641D based board
Martyn Welch wrote: Martyn Welch wrote: I have recently attempted to boot an 8641D based board from an NFS root. The boot process grinds to a halt not long after the first access of the NFS root and I receive multiple nfs: server 192.168.0.1 not responding, still trying messages. Wireshark suggests that there is no further traffic from this board at this point on. The NFS server seems to eventually try sending duplicate packets it's already sent, which results in nfs: server 192.168.0.1 OK messages, but the not responding messages resume with no further traffic from the board. I am able to boot to a ramdisk fine and the network seems to work - though I haven't really pushed the interface from it. I have attempted to git bisect, though I wasn't able to get much further than discovering the problem was introduced in the 2.6.33 merge window - at which point the gianfar network driver fails to compile (I have tried to git bisect skip many, many times to no avail). NFS booting fails for this board on todays linux-next, the master branch of Kumar's PPC tree and the head of the main tree. I have also been able to NFS boot from a random x86 based board that I have, using the head of the main tree and the linux-next tree. Copying the gianfar drivers from 2.6.32 into the head of the main tree restores the correct behaviour and I'm able to NFS boot. I have heard from others that the latest drivers work on 83xx and 85xx based boards, but it seems to be broken on at least the 8641D. I can see there has been a fair amount of work done on the gianfar driver, I assume that this is a bug introduced by the multiple queue support, but I'm way out of my depth on this. I have just compiled 2.6.33 for the Freescale MPC8641_HPCN demo board and am having still experiencing the problems outlined in my previous email, though I have noticed that I tend to be able to boot from cold, but my boot fails on reboot. Hitting the reset button doesn't help, I need to actually power the machine on and off again for it to work. As before, I'm way out of my depth in this, any one have any ideas? Below is a dump of the failed boot process: U-Boot 2009.01-00181-gc1b7c70 (Jan 30 2009 - 11:17:31) Freescale PowerPC CPU: Core: E600 Core 0, Version: 0.2, (0x80040202) System: Unknown, Version: 2.0, (0x80900120) Clocks: CPU:1000 MHz, MPX: 400 MHz, DDR: 200 MHz, LBC: 25 MHz L2: Enabled Board: MPC8641HPCN, System ID: 0x10, System Version: 0x10, FPGA Version: 0x22 I2C: ready DRAM: DDR: 1 GB FLASH: 8 MB Invalid ID (ff ff ff ff) Scanning PCI bus 01 PCI-EXPRESS 1 on bus 00 - 02 PCI-EXPRESS 2 on bus 03 - 03 Video: No radeon video card found! In:serial Out: serial Err: serial SCSI: AHCI 0001. 32 slots 4 ports 3 Gbps 0xf impl IDE mode flags: ncq ilck pm led clo pmp pio slum part scanning bus for devices... Net: eTSEC1, eTSEC2, eTSEC3, eTSEC4 = tftp 400 hpcn/uImage-torvalds-linux-2.6 Speed: 1000, full duplex Using eTSEC1 device TFTP from server 192.168.0.1; our IP address is 192.168.0.30 Filename 'hpcn/uImage-torvalds-linux-2.6'. Load address: 0x400 Loading: # # ### done Bytes transferred = 2709050 (29563a hex) = tftp 500 hpcn/mpc8641_hpcn-torvalds-linux-2.6.dtb Speed: 1000, full duplex Using eTSEC1 device TFTP from server 192.168.0.1; our IP address is 192.168.0.30 Filename 'hpcn/mpc8641_hpcn-torvalds-linux-2.6.dtb'. Load address: 0x500 Loading: # done Bytes transferred = 11523 (2d03 hex) = setenv bootargs root=/dev/nfs rw nfsroot=192.168.0.1:/tftpboot/hpcn/root/ i = bootm 400 - 500 WARNING: adjusting available memory to 1000 ## Booting kernel from Legacy Image at 0400 ... Image Name: Linux-2.6.33-1-gbaac35c Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:2708986 Bytes = 2.6 MB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 0500 Booting using the fdt blob at 0x500 Uncompressing Kernel Image ... OK Loading Device Tree to 007fa000, end 007ffd02 ... OK Using MPC86xx HPCN machine description Total memory = 1024MB; using 2048kB for hash table (at cfe0) Linux version 2.6.33-1-gbaac35c (welc...@es-j7s4d2j) (gcc version 4.1.2) #20 CPU maps initialized for 1 thread per core bootconsole [udbg0] enabled setup_arch: bootmem mpc86xx_hpcn_setup_arch() Found FSL PCI host bridge at 0xffe08000. Firmware bus number: 0-2 PCI host bridge /p...@ffe08000 (primary) ranges: MEM 0x8000..0x9fff - 0x8000 IO 0xffc0..0xffc0 - 0x /p...@ffe08000: PCICSRBAR @
Re: Gianfar driver failing on MPC8641D based board
On Thu, Feb 25, 2010 at 04:46:54PM +, Martyn Welch wrote: [...] nfs: server 192.168.0.1 not responding, still trying Further testing has shown that this isn't restricted to warm reboots, it happens from cold as well. In addition, the exact timing of the failure seems to vary, some boots have got further before failing. Unfortunately I don't have any 8641 boards near me, so I can't debug this myself. Though, I tested gianfar on MPC8568E-MDS with 2.6.33 kernel, and it seems to work just fine. I see you use SMP. Can you try to turn it off? If that will fix the issue, then it'll be a good data point. Meanwhile, I'll try SMP kernel on MPC8568 (UP), and let you know the results. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] powerpc/85xx: Fix the RapidIO maintenance access functions
Bounine, Alexandre wrote: Hi Micha, I tested it on my setup - it works. Maybe Thomas may give more details on this change. Did you (for fun) try once to decrease the maintenance window to say, 4 kB? Then you really need these high bits to work properly. Or did you try with some register at offset 4MB? The Tundra's have registers going up to 0x14000 or so? So don't need 16MB addressing for that. Thanks, Micha -Original Message- From: Micha Nelissen [mailto:mi...@neli.hopto.org] Sent: Wednesday, February 24, 2010 3:21 PM To: Alexandre Bounine Subject: Re: [PATCH 7/7] powerpc/85xx: Fix the RapidIO maintenance access functions Alexandre Bounine wrote: out_be32(priv-maint_atmu_regs-rowtar, -(destid 22) | (hopcount 12) | ((offset ~0x3) 9)); +(destid 22) | (hopcount 12) | (offset 12)); + out_be32(priv-maint_atmu_regs-rowtear, (destid 10)); Did this actually work for you? The (offset 12) is due to the 4MB window size right? Micha ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [async_tx-next PATCH 1/2] fsldma: Fix cookie issues
On Mon, Feb 22, 2010 at 11:40:31AM -0600, Steven J. Magnani wrote: fsl_dma_tx_submit() only sets the cookie on the first descriptor of a transaction. It should set the cookie on all. Signed-off-by: Steven J. Magnani st...@digidescorp.com --- diff -uprN a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c --- a/drivers/dma/fsldma.c2010-02-22 11:16:36.0 -0600 +++ b/drivers/dma/fsldma.c2010-02-22 11:24:01.0 -0600 @@ -362,7 +362,7 @@ static dma_cookie_t fsl_dma_tx_submit(st if (cookie 0) cookie = 1; - desc-async_tx.cookie = cookie; + child-async_tx.cookie = cookie; } chan-common.cookie = cookie; This looks correct to me. I'm not sure I ever tested the driver with a chained struct dma_async_tx_descriptor. Ira ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[async_tx-next PATCH v2 1/2] fsldma: Fix cookie issues
fsl_dma_tx_submit() only sets the cookie on the first descriptor of a transaction. It should set the cookie on all. Signed-off-by: Steven J. Magnani st...@digidescorp.com --- diff -uprN a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c --- a/drivers/dma/fsldma.c 2010-02-22 11:16:36.0 -0600 +++ b/drivers/dma/fsldma.c 2010-02-22 11:24:01.0 -0600 @@ -362,7 +362,7 @@ static dma_cookie_t fsl_dma_tx_submit(st if (cookie 0) cookie = 1; - desc-async_tx.cookie = cookie; + child-async_tx.cookie = cookie; } chan-common.cookie = cookie; ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [async_tx-next PATCH 2/2] fsldma: Fix cookie issues
On Mon, Feb 22, 2010 at 09:26:13PM +0100, Guennadi Liakhovetski wrote: On Mon, 22 Feb 2010, Steven J. Magnani wrote: diff -uprN a/include/linux/dmaengine.h b/include/linux/dmaengine.h --- a/include/linux/dmaengine.h 2010-02-22 11:18:11.0 -0600 +++ b/include/linux/dmaengine.h 2010-02-22 11:18:30.0 -0600 @@ -31,6 +31,8 @@ * if dma_cookie_t is 0 it's a DMA request cookie, 0 it's an error code */ typedef s32 dma_cookie_t; +#define DMA_MIN_COOKIE 1 +#define DMA_MAX_COOKIE 2147483647 Taking into account, that dma_cookie_t is 32 bits: +#define DMA_MAX_COOKIE ((1 31) - 1) Steven, After you take Guennadi's comment into acount, the rest of the patch looks good. I'm sure I've never rolled the cookie around during testing. Ira ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar driver failing on MPC8641D based board
On Feb 25, 2010, at 10:46 AM, Martyn Welch wrote: Further testing has shown that this isn't restricted to warm reboots, it happens from cold as well. In addition, the exact timing of the failure seems to vary, some boots have got further before failing. what mechanism do you use for warm resets? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
CONFIG_ISA_DMA_API without CONFIG_GENERIC_ISA_DMA
I tried building a kernel using mpc85xx_smp_defconfig, but with all platforms but p4080ds removed. This was the result: LD .tmp_vmlinux1 sound/built-in.o: In function `claim_dma_lock': /home/scott/git/fsl/linux/upstream/arch/powerpc/include/asm/dma.h:179: undefined reference to `dma_spin_lock' /home/scott/git/fsl/linux/upstream/arch/powerpc/include/asm/dma.h:179: undefined reference to `dma_spin_lock' /home/scott/git/fsl/linux/upstream/arch/powerpc/include/asm/dma.h:179: undefined reference to `dma_spin_lock' /home/scott/git/fsl/linux/upstream/arch/powerpc/include/asm/dma.h:179: undefined reference to `dma_spin_lock' /home/scott/git/fsl/linux/upstream/arch/powerpc/include/asm/dma.h:179: undefined reference to `dma_spin_lock' sound/built-in.o:/home/scott/git/fsl/linux/upstream/arch/powerpc/include/asm/dma.h:179: more undefined references to `dma_spin_lock' follow make: *** [.tmp_vmlinux1] Error 1 Commit fb4f0e8832e0075849b41b65f6bb9fdfa7593b99 (Enable GENERIC_ISA_DMA if FSL_ULI1575 to fix compile issue) tries to deal with this, but it ties it to CONFIG_FSL_ULI1575, which is not selected in a p4080ds-only config. It seems that ULI isn't really relevant to the actual problem, which is that we enable ISA DMA API support without selecting an implementation. Whether a certain chip is on the board that has an actual ISA interface is irrelevant to the build breakage. Where did the dependency list for GENERIC_ISA_DMA come from? Are there any legitimate cases on powerpc where we want to select ISA_DMA_API but not GENERIC_ISA_DMA (i.e. we have an alternate implementation)? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI on 834x
On Thu, 2010-02-25 at 07:25 -0700, Gary Thomas wrote: I may have been too hasty pronouncing this fixed. Indeed, the SATA interface now works, but my video card (Fujitsu Coral-P) does not work when it's mapped at the bottom of the PCI space :-( With the bridge mapped, the video ends up at a non-zero address (0xC800..0xCFFF). If it gets mapped to 0xC000, it fails to respond to MMIO accesses. Any ideas how I might get around this? Is there a way to force the PCI allocator to start somewhere other than [relative] zero? I'm not familiar with the way the FSL bridge works, but it would be possible to invert MMIO and DMA on your PCI bus. IE. Have MMIO go from 02G and DMA from 2G..4G for example. Provided the FSL bridge can offset the DMA back down to 0 (memory). Can it ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] RapidIO: Add Port-Write handling for EM
Bounine, Alexandre wrote: Micha Nelissen wrote: Alexandre Bounine wrote: /** + * rio_em_set_ops- Sets Error Managment operations for a particular vendor switch + * @rdev: RIO device + * + * Searches the RIO EM ops table for known switch types. If the vid + * and did match a switch table entry, then set the em_init() and + * em_handle() ops to the table entry values. Shouldn't any RIO device be able to support error management, not just switches? Only if a device reports this capability by having Error Management Extended Features block. Ideally, we have to provide default handler for every such device (I am planning it for some future updates). It should be the same as for routing operations - if the standard feature exists, it has to be used unless something else takes over. Yes, therefore I thought that: or the EM_OPS are per driver, or they can be integrated in the switch hooks list. For now I keep all port-write messages from end-points serviced by their individual drivers. One of reasons for this: the EM PW message format Maybe have a generic rio function that can be called by any driver that knows a particular port-write was due to error management causes? This function would read the standard defined EF block registers. Then the driver part can be quite small. + if (port-ops-pwenable) + port-ops-pwenable(port, enable); +} + Maybe this can be done by switch-init function? This is not per-switch function. This function enables mport to receive incoming PW messages. Per-switch PW enable is done in switch-init as for Tsi57x. Oops, I meant this comment for the em_init function call. + rio_mport_write_config_32(mport, destid, hopcount, + rdev-phys_efptr + + RIO_PORT_N_ACK_STS_CSR(portnum), + RIO_PORT_N_ACK_CLEAR); This doesn't work for the 568; but the 568 has no special handling? Tsi568 will not send EM PW message. Tsi568 PWs are disabled in its em_init(). Why? +DECLARE_RIO_EM_OPS(RIO_VID_TUNDRA, RIO_DID_TSI578, tsi57x_em_init, tsi57x_em_handler); Why not declare these along with the other ops? Because the EM extensions is a separate capability. It is not guaranteed to be in every switch. They might initialize them with NULL to indicate they don't support it? Micha ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI on 834x
Benjamin Herrenschmidt wrote: On Thu, 2010-02-25 at 07:25 -0700, Gary Thomas wrote: I may have been too hasty pronouncing this fixed. Indeed, the SATA interface now works, but my video card (Fujitsu Coral-P) does not work when it's mapped at the bottom of the PCI space :-( With the bridge mapped, the video ends up at a non-zero address (0xC800..0xCFFF). If it gets mapped to 0xC000, it fails to respond to MMIO accesses. Any ideas how I might get around this? Is there a way to force the PCI allocator to start somewhere other than [relative] zero? I'm not familiar with the way the FSL bridge works, but it would be possible to invert MMIO and DMA on your PCI bus. IE. Have MMIO go from 02G and DMA from 2G..4G for example. Provided the FSL bridge can offset the DMA back down to 0 (memory). Can it ? It can, but I don't see how that would help, if the problem is that the video card doesn't like the low 30 bits of its MMIO address being zero. Gary, can you check that the MMIO addresses are going to the PCI bus as-is, and aren't being translated down to zero? I.e. POTARn should equal POBARn, and likewise in the device tree's pci node's ranges. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] perf_event: Build callchain code regardless of hardware event support.
It's also useful for software events, as well as future support for other types of hardware counters. Signed-off-by: Scott Wood scottw...@freescale.com --- arch/powerpc/kernel/Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index c002b04..93fd162 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -98,7 +98,8 @@ obj64-$(CONFIG_AUDIT) += compat_audit.o obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o obj-$(CONFIG_FUNCTION_GRAPH_TRACER)+= ftrace.o -obj-$(CONFIG_PPC_PERF_CTRS)+= perf_event.o perf_callchain.o +obj-$(CONFIG_PERF_EVENTS) += perf_callchain.o +obj-$(CONFIG_PPC_PERF_CTRS)+= perf_event.o obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o power5-pmu.o \ power5+-pmu.o power6-pmu.o power7-pmu.o obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o -- 1.6.4.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: TBI interface
Did you check your power on reset resistor values to make sure the
correct phy management interface is selected?
On Feb 25, 2010, at 1:21 AM, Hillery, Nathan nhill...@sixisinc.com
wrote:
I have a system with an SGMII interface on an MPC8536E, attached to
a Marvel 88E6152 Ethernet switch chip. I can access Ethernet from u-
boot, if I initially configure the MII “phy” and the switch port
PHY to disable auto-negotiation and assert link up. The link speed
is 10Mbps and it is half-duplex. When u-boot starts, reports that i
t didn’t recognize a PHY 0x id, and says it will assume a generi
c phy.
Obviously, I’d like to run without having to manually configure and
have it run at 1gbps, full-duplex.
However, I am not able to get linux to recognize the device – it rep
orts that a ten-bit interface (TBI) is required for SGMII and it can
’t find one. I have a tbi-phy entry in the device-tree file.
Here’s the relevant snippet:
m...@24520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-tbi;
reg = 0x24520 0x20;
phy0: ethernet-...@0x10 {
interrupt-parent = mpic;
interrupts = 10 0x1;
reg = 0x10;
device_type = ethernet-phy;
};
tbi0: tbi-...@4 {
reg = 0x4;
device_type = tbi-phy;
};
};
enet0: ether...@24000 {
cell-index = 0;
device_type =
network;
model = eTSEC;
compatible =
gianfar;
reg = 0x24000
0x1000;
local-mac-address =
[ 00 00 00 00 00 00 ];
interrupts = 29 2 30 2 34 2
;
interrupt-parent =
mpic;
tbi-handle = tbi0;
phy-handle = phy0;
phy-connection-type
= sgmii;
fsl,magic-packet;
fsl,wake-on-filer;
};
The processor has an MDIO interface to the switch. The switch port
PHYs are 0x10, 0x11, 0x12, 0x13, 0x17, and 0x19. I picked 4 for the
TBI arbitrarily (but seeking to avoid conflicting a PHY address).
Any hints will be appreciated.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/7] RapidIO: Add IDT CPS/TSI switches
Micha Nelissen wrote: Alexandre Bounine wrote: @@ -369,6 +380,10 @@ static struct rio_dev __devinit *rio_set rdev-rswitch-switchid); rio_route_set_ops(rdev); + if (do_enum rdev-rswitch-clr_table) + rdev-rswitch-clr_table(port, destid, hopcount, +RIO_GLOBAL_TABLE); + list_add_tail(rswitch-node, rio_switches); } else Why clear the tables here, why not in rio_enum_peer? I prefer to keep it together with route table image initialization. +DECLARE_RIO_ROUTE_OPS(RIO_VID_TUNDRA, RIO_DID_TSI572, tsi57x_route_add_entry, tsi57x_route_get_entry, tsi57x_route_clr_table); +DECLARE_RIO_ROUTE_OPS(RIO_VID_TUNDRA, RIO_DID_TSI574, tsi57x_route_add_entry, tsi57x_route_get_entry, tsi57x_route_clr_table); +DECLARE_RIO_ROUTE_OPS(RIO_VID_TUNDRA, RIO_DID_TSI577, tsi57x_route_add_entry, tsi57x_route_get_entry, tsi57x_route_clr_table); +DECLARE_RIO_ROUTE_OPS(RIO_VID_TUNDRA, RIO_DID_TSI578, tsi57x_route_add_entry, tsi57x_route_get_entry, tsi57x_route_clr_table); Can the 568 and 578 driver be shared? Have a 5xx driver? For route table operations this will work. But there are Error Management functions added in follow-up patches, which are different for Tsi568. I prefer to keep them in different files to avoid hiding the differences. Plus, it makes easier for end-user to remove from the build drivers for switches that are not used in their system. I do not want to add new configuration options for switch selection at this moment but we may consider it later. Alex. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/7] RapidIO: Add switch locking during discovery
Micha Nelissen wrote:
Alexandre Bounine wrote:
+ /* Attempt to acquire device lock */
+ rio_mport_write_config_32(port, destid,
+ hopcount,
+
RIO_HOST_DID_LOCK_CSR,
+
port-host_deviceid);
+ rio_mport_read_config_32(port, destid,
hopcount,
+ RIO_HOST_DID_LOCK_CSR, result);
+ while (result != port-host_deviceid) {
It's better to abstract the locking of a device into a new function,
rio_lock_device / rio_unlock_device.
Then you can use those in rio_get_route_entry and rio_add_route_entry.
Agree. Plus, adding a lock parameter to
rio_get_route_entry/rio_add_route_entry to avoid excessive locking
requests when scanning entire table. I will do it in next version or as
additional patch: I have to address locking anyway for future changes.
@@ -1027,6 +1090,13 @@ int __devinit rio_disc_mport(struct rio_
+
+ /* Read DestID assigned by enumerator */
+ rio_local_read_config_32(mport, RIO_DID_CSR,
+mport-host_deviceid);
+ mport-host_deviceid = RIO_GET_DID(mport-sys_size,
+
mport-host_deviceid);
+
This fixes something else, should be a separate patch.
This sets an ID used for locking during discovery. On a startup only
enumerator's ID is set to the specified value. All discovering agents
have this ID set to -1. After enumeration is completed it is safe to
initialize host_deviceid for agents as well.
Alex.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/7] RapidIO: Add Port-Write handling for EM
Micha Nelissen wrote:
Alexandre Bounine wrote:
/**
+ * rio_em_set_ops- Sets Error Managment operations for a particular
vendor switch
+ * @rdev: RIO device
+ *
+ * Searches the RIO EM ops table for known switch types. If the vid
+ * and did match a switch table entry, then set the em_init() and
+ * em_handle() ops to the table entry values.
Shouldn't any RIO device be able to support error management, not just
switches?
Only if a device reports this capability by having Error Management
Extended Features block.
Ideally, we have to provide default handler for every such device (I am
planning it for some future updates). It should be the same as for
routing operations - if the standard feature exists, it has to be used
unless something else takes over.
For now I keep all port-write messages from end-points serviced by their
individual drivers. One of reasons for this: the EM PW message format
definitions lacks any hint that allows to identify type of the message.
In theory endpoints may send port-writes of any format (up to max size
of 64 bytes), what makes unifying handling of endpoints more difficult
(at least at this stage of SRIO evolution).
+/**
+ * rio_pw_enable - Enables/disables port-write handling by a master
port
+ * @port: Master port associated with port-write handling
+ * @enable: 1=enable, 0=disable
+ */
+static void rio_pw_enable(struct rio_mport *port, int enable)
+{
+ if (port-ops-pwenable)
+ port-ops-pwenable(port, enable);
+}
+
Maybe this can be done by switch-init function?
This is not per-switch function. This function enables mport to receive
incoming PW messages. Per-switch PW enable is done in switch-init as
for Tsi57x.
+/**
+ * rio_inb_pwrite_handler - process inbound port-write message
+ * @pw_msg: pointer to inbound port-write message
+ *
+ * Processes an inbound port-write message. Returns 0 if the
request
+ * has been satisfied.
+ */
+int rio_inb_pwrite_handler(u32 *pw_msg)
+{
Perhaps map this pw_msg to a struct? Or read it into named variables?
Agree - this is not nice. The best way may be defining it as a union
which combines different message formats (EM at this point) and raw
array. Will change for next update.
+ /* Clear Port Errors */
+ rio_mport_write_config_32(mport, destid, hopcount,
+ rdev-phys_efptr +
RIO_PORT_N_ERR_STS_CSR(portnum),
+ err_status 0x07120204);
Hardcoded value!
Agree. Tagged for next drop.
+
+ if (rdev-rswitch-port_ok (1 portnum)) {
+ if (err_status RIO_PORT_N_ERR_STS_PORT_UNINIT) {
+ rdev-rswitch-port_ok = ~(1 portnum);
+ rio_mport_read_config_32(mport, destid,
hopcount,
+ rdev-phys_efptr +
RIO_PORT_N_CTL_CSR(portnum),
+ regval);
+ rio_mport_write_config_32(mport, destid,
hopcount,
+ rdev-phys_efptr +
RIO_PORT_N_CTL_CSR(portnum),
+ regval | RIO_PORT_N_CTL_LOCKOUT);
You have a function for this?
Yes, I do. Will be fixed for the next drop.
+ rio_mport_write_config_32(mport, destid,
hopcount,
+ rdev-phys_efptr +
+ RIO_PORT_N_ACK_STS_CSR(portnum),
+ RIO_PORT_N_ACK_CLEAR);
This doesn't work for the 568; but the 568 has no special handling?
Tsi568 will not send EM PW message. Tsi568 PWs are disabled in its
em_init().
+ /* Clear Port-Write Pending bit */
+ rio_mport_write_config_32(mport, destid, hopcount,
+ rdev-phys_efptr +
RIO_PORT_N_ERR_STS_CSR(portnum),
+ RIO_PORT_N_ERR_STS_PW_PEND);
+DECLARE_RIO_EM_OPS(RIO_VID_TUNDRA, RIO_DID_TSI572, tsi57x_em_init,
tsi57x_em_handler);
+DECLARE_RIO_EM_OPS(RIO_VID_TUNDRA, RIO_DID_TSI574, tsi57x_em_init,
tsi57x_em_handler);
+DECLARE_RIO_EM_OPS(RIO_VID_TUNDRA, RIO_DID_TSI577, tsi57x_em_init,
tsi57x_em_handler);
+DECLARE_RIO_EM_OPS(RIO_VID_TUNDRA, RIO_DID_TSI578, tsi57x_em_init,
tsi57x_em_handler);
Why not declare these along with the other ops?
Because the EM extensions is a separate capability. It is not guaranteed
to be in every switch.
Alex.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] perf_event: e500 support
This implements perf_event support for the Freescale embedded performance
monitor, based on the existing perf_event.c that supports server/classic
chips.
Some limitations:
- Performance monitor interrupts are regular EE interrupts, and thus you
can't profile places with interrupts disabled. We may want to implement
soft IRQ-disabling, with perfmon interrupts exempted and treated as NMIs.
- When trying to schedule multiple event groups at once, and using
restricted events, situations could arise where scheduling fails even
though it would be possible. Consider three groups, each with two events.
One group has restricted events, the others don't. The two non-restricted
groups are scheduled, then one is removed, which happens to occupy the two
counters that can't do restricted events. The remaining non-restricted
group will not be moved to the non-restricted-capable counters to make
room if the restricted group tries to be scheduled.
Signed-off-by: Scott Wood scottw...@freescale.com
---
Changes from previous version:
- Factored out callchain makefile patch
- Split up header files
- Renamed pmu struct
- Added threshold support
arch/powerpc/include/asm/perf_event.h | 133 +
arch/powerpc/include/asm/perf_event_fsl_emb.h | 50 ++
.../asm/{perf_event.h = perf_event_server.h} |4 +-
arch/powerpc/include/asm/reg_fsl_emb.h |2 +-
arch/powerpc/kernel/Makefile |4 +
arch/powerpc/kernel/cputable.c |2 +-
arch/powerpc/kernel/e500-pmu.c | 129
arch/powerpc/kernel/perf_event_fsl_emb.c | 654
arch/powerpc/platforms/Kconfig.cputype | 10 +
9 files changed, 874 insertions(+), 114 deletions(-)
rewrite arch/powerpc/include/asm/perf_event.h (92%)
create mode 100644 arch/powerpc/include/asm/perf_event_fsl_emb.h
rename arch/powerpc/include/asm/{perf_event.h = perf_event_server.h} (98%)
create mode 100644 arch/powerpc/kernel/e500-pmu.c
create mode 100644 arch/powerpc/kernel/perf_event_fsl_emb.c
diff --git a/arch/powerpc/include/asm/perf_event.h
b/arch/powerpc/include/asm/perf_event.h
dissimilarity index 92%
index 3288ce3..e6d4ce6 100644
--- a/arch/powerpc/include/asm/perf_event.h
+++ b/arch/powerpc/include/asm/perf_event.h
@@ -1,110 +1,23 @@
-/*
- * Performance event support - PowerPC-specific definitions.
- *
- * Copyright 2008-2009 Paul Mackerras, IBM Corporation.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-#include linux/types.h
-
-#include asm/hw_irq.h
-
-#define MAX_HWEVENTS 8
-#define MAX_EVENT_ALTERNATIVES 8
-#define MAX_LIMITED_HWCOUNTERS 2
-
-/*
- * This struct provides the constants and functions needed to
- * describe the PMU on a particular POWER-family CPU.
- */
-struct power_pmu {
- const char *name;
- int n_counter;
- int max_alternatives;
- unsigned long add_fields;
- unsigned long test_adder;
- int (*compute_mmcr)(u64 events[], int n_ev,
- unsigned int hwc[], unsigned long mmcr[]);
- int (*get_constraint)(u64 event_id, unsigned long *mskp,
- unsigned long *valp);
- int (*get_alternatives)(u64 event_id, unsigned int flags,
- u64 alt[]);
- void(*disable_pmc)(unsigned int pmc, unsigned long mmcr[]);
- int (*limited_pmc_event)(u64 event_id);
- u32 flags;
- int n_generic;
- int *generic_events;
- int (*cache_events)[PERF_COUNT_HW_CACHE_MAX]
- [PERF_COUNT_HW_CACHE_OP_MAX]
- [PERF_COUNT_HW_CACHE_RESULT_MAX];
-};
-
-/*
- * Values for power_pmu.flags
- */
-#define PPMU_LIMITED_PMC5_61 /* PMC5/6 have limited function */
-#define PPMU_ALT_SIPR 2 /* uses alternate posn for SIPR/HV */
-
-/*
- * Values for flags to get_alternatives()
- */
-#define PPMU_LIMITED_PMC_OK1 /* can put this on a limited PMC */
-#define PPMU_LIMITED_PMC_REQD 2 /* have to put this on a limited PMC */
-#define PPMU_ONLY_COUNT_RUN4 /* only counting in run state */
-
-extern int register_power_pmu(struct power_pmu *);
-
-struct pt_regs;
-extern unsigned long perf_misc_flags(struct pt_regs *regs);
-extern unsigned long perf_instruction_pointer(struct pt_regs *regs);
-
-#define PERF_EVENT_INDEX_OFFSET1
-
-/*
- * Only override the default definitions in include/linux/perf_event.h
- * if we have hardware PMU support.
- */
-#ifdef CONFIG_PPC_PERF_CTRS
-#define perf_misc_flags(regs) perf_misc_flags(regs)
Re: [PATCH 1/2] perf_event: Build callchain code regardless of hardware event support.
On Thu, Feb 25, 2010 at 06:04:33PM -0600, Scott Wood wrote: It's also useful for software events, as well as future support for other types of hardware counters. Signed-off-by: Scott Wood scottw...@freescale.com Acked-by: Paul Mackerras pau...@samba.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar driver failing on MPC8641D based board
On Thu, Feb 25, 2010 at 12:49 PM, Anton Vorontsov avoront...@ru.mvista.com wrote: On Thu, Feb 25, 2010 at 07:51:41PM +0300, Anton Vorontsov wrote: On Thu, Feb 25, 2010 at 04:46:54PM +, Martyn Welch wrote: [...] nfs: server 192.168.0.1 not responding, still trying Further testing has shown that this isn't restricted to warm reboots, it happens from cold as well. In addition, the exact timing of the failure seems to vary, some boots have got further before failing. Unfortunately I don't have any 8641 boards near me, so I can't debug this myself. Though, I tested gianfar on MPC8568E-MDS with 2.6.33 kernel, and it seems to work just fine. I see you use SMP. Can you try to turn it off? If that will fix the issue, then it'll be a good data point. Meanwhile, I'll try SMP kernel on MPC8568 (UP), and let you know the results. Nope, no luck. Can't trigger the issue. :-/ Tested with NFS boot, TCP and UDP netperf tests. I was able to reproduce it on an 8641D and bisected it down to this: --- commit a3bc1f11e9b867a4f49505ecac486a33af248b2e Author: Anton Vorontsov avoront...@ru.mvista.com Date: Tue Nov 10 14:11:10 2009 + gianfar: Revive SKB recycling Before calling gfar_clean_tx_ring() the driver grabs an irqsave spinlock, and then tries to recycle skbs. But since skb_recycle_check() returns 0 with IRQs disabled, we'll never recycle any skbs. It appears that gfar_clean_tx_ring() and gfar_start_xmit() are mostly idependent and can work in parallel, except when they modify num_txbdfree. So we can drop the lock from most sections and thus fix the skb recycling. --- ...which probably explains why you weren't seeing it on non-SMP. I'd imagine it would show up on any of the e500mc boards too. I'd done a rev-list on gianfar.[ch] from 32 to 33-rc1, and then cherry-picked those onto a 32 baseline to reduce the scale of the bisection, but I don't think that should impact the final result I got in any meaningful way. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
On Mon, Feb 22, 2010 at 06:47:46PM +0530, K.Prasad wrote:
The 'name' field here is actually a legacy inherited from x86 code. It
is part of x86's arch-specific hw-breakpoint structure since:
- inspired by the kprobe implementation which accepts symbol name as
input.
- kallsyms_lookup_name() was 'unexported' and a module could not resolve
symbol names externally, so the core-infrastructure had to provide
such facilities.
- I wasn't sure about the discussions behind 'unexporting' of
kallsyms_lookup_name(), so did not venture to export them again (which
you rightfully did :-)
Having said that, I'll be glad to remove this field (along with that in
x86),
Cool, I'll integrate the x86 name field removal to the .24 series
provided we know that there's a way for the user to resolve symbol
names on its own i.e. routines like kallsyms_lookup_name() will remain
exported.
Yeah, I guess it's fine to keep kallsyms_lookup_name() exported.
Also, do you think addr/len/type is enough to abstract out
any ppc breakpoints?
This looks enough to me to express range breakpoints and
simple breakpoints. But what about value comparison?
(And still, there may be other trickier implementations
I don't know in ppc).
The above implementation is for PPC64 architecture that supports only
'simple' breakpoints of fixed length (no range breakpoints, no value
comparison). More on that below.
Ok. I was just a bit confused in the middle of the several PPC breakpoint
implementations :)
+ /*
+ * As a policy, the callback is invoked in a 'trigger-after-execute'
+ * fashion
+ */
+ (bp-overflow_handler)(bp, 0, NULL, regs);
Why are you calling this explicitly instead of using the perf_bp_event()
thing? This looks like it won't work with perf as the event won't
be recorded by perf.
Yes, should have invoked perf_bp_event() for perf to work well (on a
side note, it makes me wonder at the amount of 'extra' code that each
breakpoint exception would execute if it were not called through perf
sys-call...well, the costs of integrating with a generic infrastructure!)
It has the benefit of not adding extra checks in the breakpoint handler,
like checking the callback. Every breakpoint is treated the same way, which
makes the code more simple.
+void ptrace_triggered(struct perf_event *bp, int nmi,
+ struct perf_sample_data *data, struct pt_regs *regs)
+{
+ struct perf_event_attr attr;
+
+ /*
+ * Disable the breakpoint request here since ptrace has defined a
+ * one-shot behaviour for breakpoint exceptions in PPC64.
+ * The SIGTRAP signal is generated automatically for us in do_dabr().
+ * We don't have to do anything about that here
+ */
Oh, why does ptrace use a one-shot behaviour in ppc? Breakpoints
only trigger once?
Yes, ptrace breakpoints on PPC64 are designed to trigger once and this
patch retains that behaviour. It is very convenient to use one-shot
behaviour on archs where exceptions are triggered-before-execute.
Ah, Why?
This looks fine for basic breakpoints. And this can probably be
improved to integrate ranges.
But I think we did something wrong with the generic breakpoint
interface. We are translating the arch values to generic
attributes. Then this all will be translated back to arch
values.
Having generic attributes is necessary for any perf event
use from userspace. But it looks like a waste for ptrace
that already gives us arch values. And the problem
is the same for x86.
So I think we should implement a register_ptrace_breakpoint()
that doesn't take perf_event_attr but specific arch informations,
so that we don't need to pass through a generic conversion, which:
I agree that the layers of conversion from generic to arch-specific
breakpoint constants is wasteful.
Can't the arch_bp_generic_fields() function be moved to
arch/x86/kernel/ptrace.c instead of a new interface?
I'll answer in your subsequent mail :)
- is wasteful
- won't be able to express 100% of any arch capabilities. We
can certainly express most arch breakpoints features through
the generic interface, but not all of them (given how tricky
the data value comparison features can be)
I will rework that during the next cycle.
Thanks.
Thank you for the comments. I will re-send a new version of the patch
with the perf_bp_event() substitution.
Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Does Linux 2.6.32 support NAND flash connect with MPC8247 through localbus with GPCM mode?
I'm recently porting Linux 2.6.32 to our custom board with MPC8247. We have a NAND flash connected using GPCM mode of local bus. But after I search through the Linux source, there is no compatible like fsl,gpcm-nand. And I can not find any driver that seems works for our scene. Does Linux 2.6.32 has the support for such nand device or I need to construct my own NAND driver using generic platform NAND driver? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar driver failing on MPC8641D based board
On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote: [...] I was able to reproduce it on an 8641D and bisected it down to this: --- commit a3bc1f11e9b867a4f49505ecac486a33af248b2e Author: Anton Vorontsov avoront...@ru.mvista.com Date: Tue Nov 10 14:11:10 2009 + gianfar: Revive SKB recycling Thanks for the bisect. I have a guess why tx hangs in SMP case. Could anyone try the patch down below? [...] ...which probably explains why you weren't seeing it on non-SMP. I'd imagine it would show up on any of the e500mc boards too. Yeah.. Pity, I don't have SMP boards anymore. I'll try to get one though. diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index 8bd3c9f..3ff3bd0 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -2614,6 +2614,8 @@ static int gfar_poll(struct napi_struct *napi, int budget) tx_queue = priv-tx_queue[rx_queue-qindex]; tx_cleaned += gfar_clean_tx_ring(tx_queue); + if (!tx_cleaned !tx_queue-num_txbdfree) + tx_cleaned += 1; /* don't complete napi */ rx_cleaned_per_queue = gfar_clean_rx_ring(rx_queue, budget_per_queue); rx_cleaned += rx_cleaned_per_queue; ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Gianfar driver failing on MPC8641D based board
-Original Message- From: Anton Vorontsov [mailto:avoront...@ru.mvista.com] Sent: Friday, February 26, 2010 8:45 AM To: Paul Gortmaker Cc: Martyn Welch; linuxppc-dev list; net...@vger.kernel.org; linux-ker...@vger.kernel.org; Kumar Gopalpet-B05799; da...@davemloft.net; Kumar Gala Subject: Re: Gianfar driver failing on MPC8641D based board On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote: [...] I was able to reproduce it on an 8641D and bisected it down to this: --- commit a3bc1f11e9b867a4f49505ecac486a33af248b2e Author: Anton Vorontsov avoront...@ru.mvista.com Date: Tue Nov 10 14:11:10 2009 + gianfar: Revive SKB recycling Thanks for the bisect. I have a guess why tx hangs in SMP case. Could anyone try the patch down below? [...] ...which probably explains why you weren't seeing it on non-SMP. I'd imagine it would show up on any of the e500mc boards too. Yeah.. Pity, I don't have SMP boards anymore. I'll try to get one though. diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index 8bd3c9f..3ff3bd0 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -2614,6 +2614,8 @@ static int gfar_poll(struct napi_struct *napi, int budget) tx_queue = priv-tx_queue[rx_queue-qindex]; tx_cleaned += gfar_clean_tx_ring(tx_queue); + if (!tx_cleaned !tx_queue-num_txbdfree) + tx_cleaned += 1; /* don't complete napi */ rx_cleaned_per_queue = gfar_clean_rx_ring(rx_queue, budget_per_queue); rx_cleaned += rx_cleaned_per_queue; Anton, There is also one more issue that I have been observing with the patch gianfar: Revive SKB recycling. The issue is when I do a IPV4 forwarding test scenario with bidirectional flows (SMP environment). I am using Spirent smart bits (smartflow) for automation testing and I frequently observe smart flow reporting Rx packet counte greater than Tx packet count. Duplicate packets might have been received. To just get over the issue I have removed this patch and I didn't see the issue. To a certain extent I could get over the problem by using atomic_t for num_txbdfree (atomic_add and atomic_dec instructions for updating the num_txbdfree) and completely removing the spin_locks in the tx routines. Also, I feel we might want to make some more changes to the gfar_clean_tx_ring( ) and gfar_start_xmit() routines so that they can operate parallely. I am really sorry for not posting it a bit earlier as I am caught up with some urgent issues. -- Thanks Sandeep ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
powerpc: bump SECTION_SIZE_BITS from 16MB to 256MB
The current setting for SECTION_SIZE_BITS is quite small compared to
everyone else:
arch/powerpc/include/asm/sparsemem.h:#define SECTION_SIZE_BITS 24
arch/sparc/include/asm/sparsemem.h:#define SECTION_SIZE_BITS30
arch/ia64/include/asm/sparsemem.h:#define SECTION_SIZE_BITS (30)
arch/s390/include/asm/sparsemem.h:#define SECTION_SIZE_BITS 28
arch/x86/include/asm/sparsemem.h:# define SECTION_SIZE_BITS 27
And it has proven to be an issue during boot on very large machines.
If hotplug memory is enabled, drivers/base/memory.c does this:
for (i = 0; i NR_MEM_SECTIONS; i++) {
if (!present_section_nr(i))
continue;
err = add_memory_block(0, __nr_to_section(i), MEM_ONLINE,
0, BOOT);
if (!ret)
ret = err;
}
Which creates a sysfs directory for every 16MB of memory. As a result
I'm seeing up to 30 minutes spent here during boot:
c0248ee0 .__sysfs_add_one+0x28/0x128
c02492a8 .sysfs_add_one+0x38/0x188
c0249c88 .create_dir+0x70/0x138
c0249d98 .sysfs_create_dir+0x48/0x78
c032bad8 .kobject_add_internal+0x140/0x308
c032beb4 .kobject_init_and_add+0x4c/0x68
c046c2c0 .sysdev_register+0xa0/0x220
c047b1dc .add_memory_block+0x124/0x1e8
c08d1f28 .memory_dev_init+0xf4/0x168
c08d1b64 .driver_init+0x50/0x64
c0890378 .do_basic_setup+0x40/0xd4
I assume there are some O(n^2) issues in sysfs as we add all the memory
nodes. Bumping SECTION_SIZE_BITS to 256 MB drops the time to about 10
seconds and results in a much smaller /sys.
Signed-off-by: Anton Blanchard an...@samba.org
---
--- linux-2.6.33/arch/powerpc/include/asm/sparsemem.h~ 2010-02-25
22:53:54.0 -0600
+++ linux-2.6.33/arch/powerpc/include/asm/sparsemem.h 2010-02-25
22:54:06.0 -0600
@@ -8,7 +8,7 @@
* MAX_PHYSADDR_BITS 2^N: how much physical address space we have
* MAX_PHYSMEM_BITS2^N: how much memory we can have in that space
*/
-#define SECTION_SIZE_BITS 24
+#define SECTION_SIZE_BITS 28
#define MAX_PHYSADDR_BITS 44
#define MAX_PHYSMEM_BITS44
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix lwsync feature fixup vs. modules on 64-bit
Anton's commit enabling the use of the lwsync fixup mechanism on 64-bit
breaks modules. The lwsync fixup section uses .long instead of the
FTR_ENTRY_OFFSET macro used by other fixups sections, and thus will
generate 32-bit relocations that our module loader cannot resolve.
This changes it to use the same type as other feature sections.
Note however that we might want to consider using 32-bit for all the
feature fixup offsets and add support for R_PPC_REL32 to module_64.c
instead as that would reduce the size of the kernel image. I'll leave
that as an exercise for the reader for now...
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/feature-fixups.h |2 +-
arch/powerpc/lib/feature-fixups.c |3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/feature-fixups.h
b/arch/powerpc/include/asm/feature-fixups.h
index cbd4dfa..96a7d06 100644
--- a/arch/powerpc/include/asm/feature-fixups.h
+++ b/arch/powerpc/include/asm/feature-fixups.h
@@ -165,7 +165,7 @@ label##2: \
.pushsection sect,a; \
.align 2; \
label##3: \
- .long label##1b-label##3b; \
+ FTR_ENTRY_OFFSET label##1b-label##3b; \
.popsection;
#endif /* __ASM_POWERPC_FEATURE_FIXUPS_H */
diff --git a/arch/powerpc/lib/feature-fixups.c
b/arch/powerpc/lib/feature-fixups.c
index 4dee652..e640175 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -112,7 +112,8 @@ void do_feature_fixups(unsigned long value, void
*fixup_start, void *fixup_end)
void do_lwsync_fixups(unsigned long value, void *fixup_start, void *fixup_end)
{
- int *start, *end, *dest;
+ long *start, *end;
+ unsigned int *dest;
if (!(value CPU_FTR_LWSYNC))
return ;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
