Re: FPGA access over PCI-E on MPC8536
On Sep 16, 2009, at 11:17 PM, Felix Radensky wrote: Hi, On my custom MPC8536 based board running 2.6.31 kernel FPGA is connected via x2 PCI-E lane. FPGA is identified during PCI scan and is visible via lspci. :01:00.0 Class ff00: Altera Corporation Unknown device 0004 (rev 01) Subsystem: Altera Corporation Unknown device 0004 Flags: fast devsel, IRQ 16 Memory at 9800 (32-bit, non-prefetchable) [disabled] [size=1M] Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/5 Enable- Capabilities: [78] Power Management version 3 Capabilities: [80] Express Endpoint IRQ 0 Capabilities: [100] Virtual Channel However when I attempt to access FPGA memory my mmapping it in userspace the read hangs. The same happens in kernel space. Does it happen because FPGA memory is marked as disabled, or because FPGA code is doing something wrong ? Can you access the device in u-boot? That would possible tell you if the HW is functioning or not. Another question is what can cause PCI device memory be marked as disabled. Good question, no idea how lspci decided to print [disabled]. Take a look at lspci source and see :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
FPGA access over PCI-E on MPC8536
Hi, On my custom MPC8536 based board running 2.6.31 kernel FPGA is connected via x2 PCI-E lane. FPGA is identified during PCI scan and is visible via lspci. :01:00.0 Class ff00: Altera Corporation Unknown device 0004 (rev 01) Subsystem: Altera Corporation Unknown device 0004 Flags: fast devsel, IRQ 16 Memory at 9800 (32-bit, non-prefetchable) [disabled] [size=1M] Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/5 Enable- Capabilities: [78] Power Management version 3 Capabilities: [80] Express Endpoint IRQ 0 Capabilities: [100] Virtual Channel However when I attempt to access FPGA memory my mmapping it in userspace the read hangs. The same happens in kernel space. Does it happen because FPGA memory is marked as disabled, or because FPGA code is doing something wrong ? Another question is what can cause PCI device memory be marked as disabled. Thanks a lot. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: delete UART current-speed from 4xx DTS?
On Thu, Sep 17, 2009 at 07:31:06AM +1000, Benjamin Herrenschmidt wrote: > >> Ok, so I think that is related to what I originally hit. >> >> I played around with removing the current-speed property on canyonlands >> today, >> and noticed that I would get no console output at all unless I specified a >> baudrate with console=ttyS0,115200. That was sort of contrary to what I >> found >> with bamboo, so I diffed the configs to see why. Bamboo has udbg enabled and >> hence has legacy_serial builtin, whereas canyonlands just has of_serial. >> >> So on boards where of_serial is the only serial driver, we need either an >> accurate current-speed property, or a specific baudrate on the command line. >> That makes a bit more tenuous to remove the properties entirely, because if >> people disable udbg and are relying on that behavior they get no more console >> output. Need to think on that a bit I guess. >> >> Alternatively, we could try patching of_serial.c to do the baudrate probe >> as well. > >Well, I've always wondered why we just don't put the probe in the 8250 >driver... I proposed it on the list a while back and there was no Probably because anything to do with the serial drivers or tty layer scares the living hell out of people other than Alan and Andrew. And I sometimes think even Andrew is faking... ;) >serious objection, but then forgot about it :-) > >We should do it, and check if the result is sane (looks like a standard >speed). If it is, we should then just used it. Sounds sane enough. I'm hoping to get some time in the next few days to poke at this. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PPC PCI bus registers
On Wed, 2009-09-16 at 15:11 -0700, Eddie Dawydiuk wrote: > Benjamin, > > > Out of order execution != out of order storage. ioremap() will give you > > guarded space which means it cannot be speculatively accessed for > > example, and you do get -some- guarantees but not that your stores are > > going to hit the device in order, nor that your loads are going to be > > performed until the CPU actually use the result of the load, which can > > be delayed beyond a store. > > Interesting. So IIUC if I were to use ioremap and then bit bang bus cycles > using > readN() / writeN() I would need to add memory barrier to ensure the order of > the > load and store operations does not change. Is my understanding correct? Only if you use the __raw variants. readN/writeN already provide full barriers, including barriers against leakage outside of locks and barriers vs. cacheable accesses (MMIO vs. DMA) and thus are slow. If you use the raw variants, it then depends whether your code is going to be ppc specific, in which case you can manually use things like eieio() etc... or not in which case ... it's harder :-) You can always use rmb/wmb/mb but those are more heavyweight than just an eieio There's iobarrier_r/w/rw, dunno if those are generic tho. > If so > what are the recommended macros/functions for adding memory barriers, or are > there preferred functions to use in place of ioremap() and readN()/writeN? ioremap + readN / writeN will give you fully ordered behaviour. It's only when you try to be sneaky or speedy and use the __raw variants that you have to be more careful. > PS I've looked in Documentation/ in the 2.6.30 Linux kernel tree for more > information, but I was unable to find any. If there are any example drivers > or > documentation that you know of on this topic I'd be quite interested if you > could point me to it. > > Thanks for your patience and time you've been quite helpful. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] char/hvc: adding __init macro to char/hvc_vio.c
Am Thursday 20 August 2009 23:14:06 schrieb Peter Hüwe: > From: Peter Huewe > > Trivial patch which adds the __init/__exit macros to the module_init/ > module_exit functions of char/hvc_vio.c > > Please have a look at the small patch and either pull it through > your tree, or please ack' it so Jiri can pull it through the trivial tree. > > linux version 2.6.31-rc6 - linus git tree, Do 20. Aug 22:26:06 CEST 2009 > > Signed-off-by: Peter Huewe Hi Jiri, this one got merged by Benjamin, so you can drop it from your queue :) http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=948c28fe3001f2c9d852dff2a0b2c69fe7cec91b @Benjamin: Thanks for merging. Regards, Peter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PPC PCI bus registers
Benjamin, Out of order execution != out of order storage. ioremap() will give you guarded space which means it cannot be speculatively accessed for example, and you do get -some- guarantees but not that your stores are going to hit the device in order, nor that your loads are going to be performed until the CPU actually use the result of the load, which can be delayed beyond a store. Interesting. So IIUC if I were to use ioremap and then bit bang bus cycles using readN() / writeN() I would need to add memory barrier to ensure the order of the load and store operations does not change. Is my understanding correct? If so what are the recommended macros/functions for adding memory barriers, or are there preferred functions to use in place of ioremap() and readN()/writeN? PS I've looked in Documentation/ in the 2.6.30 Linux kernel tree for more information, but I was unable to find any. If there are any example drivers or documentation that you know of on this topic I'd be quite interested if you could point me to it. Thanks for your patience and time you've been quite helpful. -- Best Regards, Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200 16525 East Laser Drive | fax:(480) 837-5300 Fountain Hills, AZ 85268| web: www.embeddedARM.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PPC PCI bus registers
On Wed, 2009-09-16 at 11:58 -0700, Eddie Dawydiuk wrote: > I'm not sure I understand. To clarify I have an FPGA connected via the > PCI bus > which implements several peripherals, I've implemented device drivers > for. > Currently I am calling ioremap() to get a virtual address > corresponding to the > PCI devices. Then I use ___raw_writeN / ___raw_readN for > reading/writing data > via the PCI bus to the FPGA registers. From looking at io.h I believe > this > method is safe with regard to out of order execution. > > "* ioremap is the standard one and provides non-cacheable guarded > mappings > * and can be hooked by the platform via ppc_md " > > Can you verify if my understanding is correct, or let me know if I > need to add > memory barriers? > Out of order execution != out of order storage. ioremap() will give you guarded space which means it cannot be speculatively accessed for example, and you do get -some- guarantees but not that your stores are going to hit the device in order, nor that your loads are going to be performed until the CPU actually use the result of the load, which can be delayed beyond a store. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: delete UART current-speed from 4xx DTS?
> Ok, so I think that is related to what I originally hit. > > I played around with removing the current-speed property on canyonlands today, > and noticed that I would get no console output at all unless I specified a > baudrate with console=ttyS0,115200. That was sort of contrary to what I found > with bamboo, so I diffed the configs to see why. Bamboo has udbg enabled and > hence has legacy_serial builtin, whereas canyonlands just has of_serial. > > So on boards where of_serial is the only serial driver, we need either an > accurate current-speed property, or a specific baudrate on the command line. > That makes a bit more tenuous to remove the properties entirely, because if > people disable udbg and are relying on that behavior they get no more console > output. Need to think on that a bit I guess. > > Alternatively, we could try patching of_serial.c to do the baudrate probe > as well. Well, I've always wondered why we just don't put the probe in the 8250 driver... I proposed it on the list a while back and there was no serious objection, but then forgot about it :-) We should do it, and check if the result is sane (looks like a standard speed). If it is, we should then just used it. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [spi-devel-general] [PATCH] mpc52xx_psc_spi: enlarge clock range
Hi, adding powerpc-list and Grant to cc. On Wed, Sep 16, 2009 at 01:07:50PM +0200, Dragos Carp wrote: > allow spi clock values bellow 78kbps down to ca. 300bps Looks like your patch converts the driver from mpc5200 to mpc5200b? If this is really all which is needed, it should support both versions, I think. Regards, Wolfram > > Signed-off-by: Dragos Carp > --- > mpc52xx_psc_spi.c | 26 +- > 1 file changed, 13 insertions(+), 13 deletions(-) > > diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c > index 1b74d5c..b15882a 100644 > --- a/drivers/spi/mpc52xx_psc_spi.c > +++ b/drivers/spi/mpc52xx_psc_spi.c > @@ -78,7 +78,8 @@ static void mpc52xx_psc_spi_activate_cs(struct spi_device > *spi) > struct mpc52xx_psc_spi *mps = spi_master_get_devdata(spi->master); > struct mpc52xx_psc __iomem *psc = mps->psc; > u32 sicr; > - u16 ccr; > + u32 ccr; > + u32 bitclkdiv; > > sicr = in_be32(&psc->sicr); > > @@ -98,17 +99,16 @@ static void mpc52xx_psc_spi_activate_cs(struct spi_device > *spi) > sicr &= ~0x1000; > out_be32(&psc->sicr, sicr); > > - /* Set clock frequency and bits per word > - * Because psc->ccr is defined as 16bit register instead of 32bit > - * just set the lower byte of BitClkDiv > - */ > - ccr = in_be16((u16 __iomem *)&psc->ccr); > - ccr &= 0xFF00; > - if (cs->speed_hz) > - ccr |= (MCLK / cs->speed_hz - 1) & 0xFF; > - else /* by default SPI Clk 1MHz */ > - ccr |= (MCLK / 100 - 1) & 0xFF; > - out_be16((u16 __iomem *)&psc->ccr, ccr); > + /* Set clock frequency */ > + bitclkdiv = MCLK / (cs->speed_hz ? cs->speed_hz : 100) - 1; > + bitclkdiv &= 0x; > + bitclkdiv |= (bitclkdiv & 0xFF) << 16; /* byte swapped */ > + bitclkdiv &= 0x0000; > + ccr = in_be32(&psc->ccr); > + ccr &= 0xFFFF; > + ccr |= bitclkdiv; > + out_be32(&psc->ccr, ccr); > + > mps->bits_per_word = cs->bits_per_word; > > if (mps->cs_control) > @@ -333,7 +333,7 @@ static int mpc52xx_psc_spi_port_config(int psc_id, struct > mpc52xx_psc_spi *mps) > /* Configure 8bit codec mode as a SPI master and use EOF flags */ > /* SICR_SIM_CODEC8|SICR_GENCLK|SICR_SPI|SICR_MSTR|SICR_USEEOF */ > out_be32(&psc->sicr, 0x0180C800); > - out_be16((u16 __iomem *)&psc->ccr, 0x070F); /* default SPI Clk 1MHz */ > + out_be32(&psc->ccr, 0x0713); /* default SPI Clk 1MHz */ > > /* Set 2ms DTL delay */ > out_8(&psc->ctur, 0x00); -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Wed, Sep 16, 2009 at 07:22:35PM +0200, Peter Zijlstra wrote: > On Wed, 2009-09-16 at 22:33 +0530, Vaidyanathan Srinivasan wrote: > > * Peter Zijlstra [2009-09-16 18:35:16]: > > > > > Now if you were to try and online the cpus in the guest, it'd fail > > > because the cpus aren't backed anymore, and the hot-plug simply > > > times-out and fails. > > > > > > And we're still good, right? > > > > The requirement differ here. If we had offlined 2 vCPUs for the > > purpose of system reconfiguration, the expected behavior with offline > > interface will work right. However the proposed cede interface is > > needed when we want them to temporarily go away but still come back > > when we do an online. We want the online to always succeed since the > > backing physical resources are not relinquished. The proposed > > interface facilitates offline without relinquishing the physical > > resources assigned to LPARs. > > Then make that the platform default and leave the lpar management to > whatever pokes at the lpar? That could have worked - however lpar management already uses the same sysfs interface to poke. The current semantics make the lpar vcpu deconfig state the platform default assuming that it will be used for lpar management. The only clean way to do this without breaking lpar management stuff is to add another state - "inactive" and retain backward compatibility. Thanks Dipankar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PPC PCI bus registers
Benjamin, Also, if you're going to access a PCI device directly, beware of other issues such as ordering. PPC is an out of order architecture, you need to ensure you add the appropriate memory barriers if you want to ensure you accesses are done in the order you write them in your program. For "standard" stuff that doesn't involve DMA or locks, an eieio after both MMIO loads and stores should do the trick. I'm not sure I understand. To clarify I have an FPGA connected via the PCI bus which implements several peripherals, I've implemented device drivers for. Currently I am calling ioremap() to get a virtual address corresponding to the PCI devices. Then I use ___raw_writeN / ___raw_readN for reading/writing data via the PCI bus to the FPGA registers. From looking at io.h I believe this method is safe with regard to out of order execution. "* ioremap is the standard one and provides non-cacheable guarded mappings * and can be hooked by the platform via ppc_md " Can you verify if my understanding is correct, or let me know if I need to add memory barriers? -- Best Regards, Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200 16525 East Laser Drive | fax:(480) 837-5300 Fountain Hills, AZ 85268| web: www.embeddedARM.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Wed, 2009-09-16 at 22:33 +0530, Vaidyanathan Srinivasan wrote: > * Peter Zijlstra [2009-09-16 18:35:16]: > > > On Wed, 2009-09-16 at 21:54 +0530, Dipankar Sarma wrote: > > > > > No, for this specific case, latency isn't an issue. The issue is - > > > how do we cede unused vcpus to hypervisor for better energy management ? > > > Yes, it can be done by a hypervisor manager telling the kernel to > > > offline and make a bunch of vcpus "inactive". It does have to choose > > > offline (release vcpu) vs. inactive (cede but guranteed if needed). > > > The problem is that long ago we exported a lot of hotplug stuff to > > > userspace through the sysfs interface and we cannot do something > > > inside the kernel without keeping the sysfs stuff consistent. > > > This seems like a sane way to do that without undoing all the > > > virtual cpu hotplug infrastructure in different supporting archs. > > > > I'm still not getting it.. > > > > Suppose we have some guest, it booted with 4 cpus. > > > > We then offline 2 of them. > > > > Apparently this LPAR binds guest cpus to physical cpus? > > So we use a hypervisor interface to reclaim these 2 offlined cpus and > > re-assign them to some other guest. > > > > So far so good, right? > > > > Now if you were to try and online the cpus in the guest, it'd fail > > because the cpus aren't backed anymore, and the hot-plug simply > > times-out and fails. > > > > And we're still good, right? > > The requirement differ here. If we had offlined 2 vCPUs for the > purpose of system reconfiguration, the expected behavior with offline > interface will work right. However the proposed cede interface is > needed when we want them to temporarily go away but still come back > when we do an online. We want the online to always succeed since the > backing physical resources are not relinquished. The proposed > interface facilitates offline without relinquishing the physical > resources assigned to LPARs. Then make that the platform default and leave the lpar management to whatever pokes at the lpar? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
* Peter Zijlstra [2009-09-16 18:35:16]: > On Wed, 2009-09-16 at 21:54 +0530, Dipankar Sarma wrote: > > > No, for this specific case, latency isn't an issue. The issue is - > > how do we cede unused vcpus to hypervisor for better energy management ? > > Yes, it can be done by a hypervisor manager telling the kernel to > > offline and make a bunch of vcpus "inactive". It does have to choose > > offline (release vcpu) vs. inactive (cede but guranteed if needed). > > The problem is that long ago we exported a lot of hotplug stuff to > > userspace through the sysfs interface and we cannot do something > > inside the kernel without keeping the sysfs stuff consistent. > > This seems like a sane way to do that without undoing all the > > virtual cpu hotplug infrastructure in different supporting archs. > > I'm still not getting it.. > > Suppose we have some guest, it booted with 4 cpus. > > We then offline 2 of them. > > Apparently this LPAR binds guest cpus to physical cpus? > So we use a hypervisor interface to reclaim these 2 offlined cpus and > re-assign them to some other guest. > > So far so good, right? > > Now if you were to try and online the cpus in the guest, it'd fail > because the cpus aren't backed anymore, and the hot-plug simply > times-out and fails. > > And we're still good, right? The requirement differ here. If we had offlined 2 vCPUs for the purpose of system reconfiguration, the expected behavior with offline interface will work right. However the proposed cede interface is needed when we want them to temporarily go away but still come back when we do an online. We want the online to always succeed since the backing physical resources are not relinquished. The proposed interface facilitates offline without relinquishing the physical resources assigned to LPARs. --Vaidy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Wed, 2009-09-16 at 21:54 +0530, Dipankar Sarma wrote: > No, for this specific case, latency isn't an issue. The issue is - > how do we cede unused vcpus to hypervisor for better energy management ? > Yes, it can be done by a hypervisor manager telling the kernel to > offline and make a bunch of vcpus "inactive". It does have to choose > offline (release vcpu) vs. inactive (cede but guranteed if needed). > The problem is that long ago we exported a lot of hotplug stuff to > userspace through the sysfs interface and we cannot do something > inside the kernel without keeping the sysfs stuff consistent. > This seems like a sane way to do that without undoing all the > virtual cpu hotplug infrastructure in different supporting archs. I'm still not getting it.. Suppose we have some guest, it booted with 4 cpus. We then offline 2 of them. Apparently this LPAR binds guest cpus to physical cpus? So we use a hypervisor interface to reclaim these 2 offlined cpus and re-assign them to some other guest. So far so good, right? Now if you were to try and online the cpus in the guest, it'd fail because the cpus aren't backed anymore, and the hot-plug simply times-out and fails. And we're still good, right? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Wed, Sep 16, 2009 at 05:32:51PM +0200, Peter Zijlstra wrote: > On Wed, 2009-09-16 at 20:58 +0530, Dipankar Sarma wrote: > > On Tue, Sep 15, 2009 at 02:11:41PM +0200, Peter Zijlstra wrote: > > > On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: > > > > This patchset contains the offline state driver implemented for > > > > pSeries. For pSeries, we define three available_hotplug_states. They > > > > are: > > > > > > > > online: The processor is online. > > > > > > > > offline: This is the the default behaviour when the cpu is > > > > offlined > > > > > > > > inactive: This cedes the vCPU to the hypervisor with a cede > > > > latency > > > > > > > > Any feedback on the patchset will be immensely valuable. > > > > > > I still think its a layering violation... its the hypervisor manager > > > that should be bothered in what state an off-lined cpu is in. > > > > The problem is that all hypervisor managers cannot figure out what sort > > of latency guest OS can tolerate under the situation. They wouldn't know > > from what context guest OS has ceded the vcpu. It has to have > > some sort of hint, which is what the guest OS provides. > > I'm missing something here, hot-unplug is a slow path and should not > ever be latency critical..? You aren't, I did :) No, for this specific case, latency isn't an issue. The issue is - how do we cede unused vcpus to hypervisor for better energy management ? Yes, it can be done by a hypervisor manager telling the kernel to offline and make a bunch of vcpus "inactive". It does have to choose offline (release vcpu) vs. inactive (cede but guranteed if needed). The problem is that long ago we exported a lot of hotplug stuff to userspace through the sysfs interface and we cannot do something inside the kernel without keeping the sysfs stuff consistent. This seems like a sane way to do that without undoing all the virtual cpu hotplug infrastructure in different supporting archs. Thanks Dipankar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Wed, 2009-09-16 at 20:58 +0530, Dipankar Sarma wrote: > On Tue, Sep 15, 2009 at 02:11:41PM +0200, Peter Zijlstra wrote: > > On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: > > > This patchset contains the offline state driver implemented for > > > pSeries. For pSeries, we define three available_hotplug_states. They are: > > > > > > online: The processor is online. > > > > > > offline: This is the the default behaviour when the cpu is > > > offlined > > > > > > inactive: This cedes the vCPU to the hypervisor with a cede > > > latency > > > > > > Any feedback on the patchset will be immensely valuable. > > > > I still think its a layering violation... its the hypervisor manager > > that should be bothered in what state an off-lined cpu is in. > > The problem is that all hypervisor managers cannot figure out what sort > of latency guest OS can tolerate under the situation. They wouldn't know > from what context guest OS has ceded the vcpu. It has to have > some sort of hint, which is what the guest OS provides. I'm missing something here, hot-unplug is a slow path and should not ever be latency critical..? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Tue, Sep 15, 2009 at 02:11:41PM +0200, Peter Zijlstra wrote: > On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: > > This patchset contains the offline state driver implemented for > > pSeries. For pSeries, we define three available_hotplug_states. They are: > > > > online: The processor is online. > > > > offline: This is the the default behaviour when the cpu is offlined > > > > inactive: This cedes the vCPU to the hypervisor with a cede latency > > > > Any feedback on the patchset will be immensely valuable. > > I still think its a layering violation... its the hypervisor manager > that should be bothered in what state an off-lined cpu is in. The problem is that all hypervisor managers cannot figure out what sort of latency guest OS can tolerate under the situation. They wouldn't know from what context guest OS has ceded the vcpu. It has to have some sort of hint, which is what the guest OS provides. Thanks Dipankar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Crash in the kernel panic linux mpc 832x
Hi, Iam getting the below crash on new board tested on MPC832x using linux-2.6.24, please let me what could be the problem on the same. Does it infer any information on the exception? # Oops: Exception in kernel mode, sig: 4 [#1] PREEMPT MPC832x RDB Modules linked in: NIP: c0048178 LR: c00463e8 CTR: c000ce44 REGS: c018dc60 TRAP: 0700 Not tainted (2.6.24) MSR: 1032 CR: 82022028 XER: TASK = c017b570[0] 'swapper' THREAD: c018c000 GPR00: 3b9ac9ff c018dd10 c017b570 c017c9f0 0016 c0192180 15cc GPR08: fd82b91c 328b73f6 328b89c2 76ef53cb 328b73f6 GPR16: c019c990 fffce4b8 392e 00ba GPR24: fffdf72b ff46 000208d5 fd41cc00 fff6 NIP [c0048178] clocksource_get_next+0x0/0xa8 LR [c00463e8] update_wall_time+0x50c/0xccc Call Trace: [c018dd10] [c0046624] update_wall_time+0x748/0xccc (unreliable) [c018ddd0] [c0031b68] do_timer+0x40/0xf0 [c018ddf0] [c004a7a4] tick_sched_timer+0x284/0x2e8 [c018de40] [c0043cc4] hrtimer_interrupt+0x1c8/0x2d4 [c018dea0] [c000d038] timer_interrupt+0x128/0x188 [c018dec0] [c0010208] ret_from_except+0x0/0x14 --- Exception: 901 at cpu_idle+0x98/0xf8 LR = cpu_idle+0x98/0xf8 [c018df80] [c00091c0] cpu_idle+0xdc/0xf8 (unreliable) [c018dfa0] [c0003e98] rest_init+0x8c/0xb4 [c018dfc0] [c015fa28] start_kernel+0x258/0x2e4 [c018dff0] [3438] 0x3438 Instruction dump: 40820028 38000a00 387e0001 b01e 7c7f1850 80010014 bbc10008 38210010 7c0803a6 4e800020 480d643d 4bd8 7c0802a6 93e1000c 90010014 Kernel panic - not syncing: Fatal exception in interrupt-- Regards, Nanda___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: delete UART current-speed from 4xx DTS?
[Re: RFC: delete UART current-speed from 4xx DTS?] On 16/09/2009 (Wed 09:19) Josh Boyer wrote: > On Wed, Sep 16, 2009 at 07:44:07AM +1000, Benjamin Herrenschmidt wrote: > >On Tue, 2009-09-15 at 11:32 -0400, Josh Boyer wrote: > >> > >> When I did the bamboo port a while ago, I recall having issues with either > >> a missing clock-frequency or current-speed (or both perhaps) and the > >> bootloader > >> on the board was the original PIBS. It might have been an issue with PIBS > >> but I'm guessing the rest of the 4xx boards copied from either Ebony or > >> Bamboo in their ports and hence contain that property. > > > >I think I recently added code to legacy_serial probe the speed from the > >HW if the property is absent, which should help. > > Ok, so I think that is related to what I originally hit. > > I played around with removing the current-speed property on canyonlands today, > and noticed that I would get no console output at all unless I specified a > baudrate with console=ttyS0,115200. That was sort of contrary to what I found > with bamboo, so I diffed the configs to see why. Bamboo has udbg enabled and > hence has legacy_serial builtin, whereas canyonlands just has of_serial. Makes sense - udbg kind of bridges the information gap in getting the baudrate that the bootloader was using carried forward. I'd have never noticed that because I've always been in the habit of recommending that people always use an explicit console=ttySn,rate for all non PC like hardware. I just saw Documentation/serial-console.txt (also somewhat PC-centric) claims that "If no console device is specified, the first device found capable of acting as a system console will be used." But I've never relied on that, or even tested if it is really a valid claim once you stray outside the realm of common PC hardware, and end user chosen baudrates. I'm pretty sure that on sbc8349, if I omit the console= and I don't have udbg enabled, I won't see anything either (and I've always implicitly filed that under "user configuration error"). > > So on boards where of_serial is the only serial driver, we need either an > accurate current-speed property, or a specific baudrate on the command line. I just took a rummage around in u-boot, and at the moment there isn't really many boards poking around with current-speed. Just for board/muas3001, and any older mpc85xx CPUs with CPM UARTs. There doesn't appear to be any real global trend there at all. (That is not to say that it couldn't be added though...) But in any case, I still don't think having something as end-user configurable as a baud rate should be hard coded in a dtb (esp. if the firmware isn't updating it on the fly...) > That makes a bit more tenuous to remove the properties entirely, because if > people disable udbg and are relying on that behavior they get no more console > output. Need to think on that a bit I guess. Would be interesting to get other input from people on how big they think that user group who would be relying on this are. I'm thinking a lot of other boards have already tossed out any such guarantee. I'll have to do some experiments to confirm that though. > Alternatively, we could try patching of_serial.c to do the baudrate probe > as well. Improving it to "do the right thing" independent of the current behaviour of other boards is probably worthwhile in terms of user friendly improvements. It always sucks to launch into a kernel and see nothing but another case of "silent boot death". Paul. > > josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[Question] Does this oops point to a hardware bug?
We have built some custom hardware based on a PPC440EPx. I saw
an oops that doesn't make much sense to me, so I'd like to ask
folks if this smells more like a hardware problem than a software
problem.
The oops is a signal 4 in kernel mode (trap 700). If I'm
interpreting this correctly, it is a "program error", which
could be a privileged instruction trap, illegal instruction
trap, or unimplemented instruction trap.
Since this is in kernel mode, I wouldn't expect any of these
traps.
The other strange thing is the addresses. NIP is 4c09e100, which
doesn't look like a kernel address.
So, I'm guessing that this exception happened in a user-space
program (SDEC-status) executing in kernel mode. To me, that
feels like a hardware bug.
I've run some stand-alone memory tests, but they don't show any
problems. This is an embedded system, so there is no swapping
to disk. The kernel is stored in NOR flash, and copied to RAM
by uboot; modules are stored on a CF card in an ext3 file system.
Suggestions / theories gladly accepted. :-)
Steve
Oops: Exception in kernel mode, sig: 4 [#1]
Hydra
Modules linked in: aemb audfpga hdird400_fe vpid saradec
aud_fpga_version vid_fpga_tse vid_fpga
NIP: 4c09e100 LR: 4c09e100 CTR: c001d710
REGS: ce84fea0 TRAP: 0700 Not tainted (2.6.28.7)
MSR: 00029000 CR: 2409a024 XER: 2001
TASK = ce804000[1162] 'SDEC-status' THREAD: ce84e000
GPR00: 4c09e100 ce84ff50 ce804000 c00c2908 c05bf860 cf043000 d7c8029c
GPR08: d7c8029c c00c2908 c03df000 001e0860 c009ab98 1005c1fc 0004 cef4b580
GPR16: 4e900f78 fff7 cef4b900 ce84ff40 c009ac10 4e901098 4c09e0d8
GPR24: 0fb27883 4e901098 4c09e100 c000d870
NIP [4c09e100] 0x4c09e100
LR [4c09e100] 0x4c09e100
Call Trace:
[ce84ff50] [4c09e100] 0x4c09e100 (unreliable)
Instruction dump:
---[ end trace 434a2d22c66cb1ce ]---
--
A: Because it makes the logic of the discussion difficult to follow.
Q: Why shouldn't I top post?
A: No.
Q: Should I top post?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][v1] powerpc/85xx: Create dts for each core in CAMPmodeforP2020RDB
> -Original Message- > From: > linuxppc-dev-bounces+poonam.aggrwal=freescale@lists.ozlabs > .org > [mailto:linuxppc-dev-bounces+poonam.aggrwal=freescale@list > s.ozlabs.org] On Behalf Of Kumar Gala > Sent: Wednesday, September 16, 2009 7:10 PM > To: Aggrwal Poonam-B10812 > Cc: linuxppc-...@ozlabs.org > Subject: Re: [PATCH][v1] powerpc/85xx: Create dts for each > core in CAMPmodeforP2020RDB > > > On Sep 11, 2009, at 6:47 AM, Aggrwal Poonam-B10812 wrote: > > >> > >> Ok, I wrongly understood protected interrupts as reserved for one > >> core. However, I still dislike two devices having the same name. > >> > >> Otherwise it may work if every interrupt is delivered to > both cores > >> although statistically only one core will actually have > some work to > >> do. Doesn't the kernel complain about unhandled irqs however? > >> > > We don't see any such messages of unhandled interrupts, although I > > checked the corresponding files for mpc8572ds, they do not have the > > interrupts property for the serial ports at all, in both > the core0 and > > core1 dts. > > Don't know the reason. > > the p2020 versions shouldn't have an interrupt property in > the serial node. The reason we removed it in the 8572 CAMP > dts is to make sure we get polling mode. As Gabriel points > out sharing the IRQ between the two OSes is not safe. While > it might seem to work it will have issues at some point. > Thanks for the explanation. Probably we are not seeing an issue, because we are protecting the int 42 in both the dts files. So probably mpic is not forwarding the interrupt to any of the cores. Anyways I will rework the patch and resend. Kind Regards Poonam > - k > ___ > 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][v1] powerpc/85xx: Create dts for each core in CAMPmodefor P2020RDB
On Sep 11, 2009, at 6:47 AM, Aggrwal Poonam-B10812 wrote: Ok, I wrongly understood protected interrupts as reserved for one core. However, I still dislike two devices having the same name. Otherwise it may work if every interrupt is delivered to both cores although statistically only one core will actually have some work to do. Doesn't the kernel complain about unhandled irqs however? We don't see any such messages of unhandled interrupts, although I checked the corresponding files for mpc8572ds, they do not have the interrupts property for the serial ports at all, in both the core0 and core1 dts. Don't know the reason. the p2020 versions shouldn't have an interrupt property in the serial node. The reason we removed it in the 8572 CAMP dts is to make sure we get polling mode. As Gabriel points out sharing the IRQ between the two OSes is not safe. While it might seem to work it will have issues at some point. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: delete UART current-speed from 4xx DTS?
On Wed, Sep 16, 2009 at 07:44:07AM +1000, Benjamin Herrenschmidt wrote: >On Tue, 2009-09-15 at 11:32 -0400, Josh Boyer wrote: >> On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote: >> >One of the guys here was getting a messed up console on a bamboo board >> >(on linux boot), which he traced to the fact that the default dts has a >> >9600 baudrate coded into it (board was running 115k2, not 9600). Either >> >deleting the line, or replacing the 9600 with zero fixed the problem. >> >> Once booted, was there a valid current-speed property in /proc/device-tree >> for the serial node? I'm curious if U-Boot created it, or if the kernel >> just used whatever baud was present already. >> >> When I did the bamboo port a while ago, I recall having issues with either >> a missing clock-frequency or current-speed (or both perhaps) and the >> bootloader >> on the board was the original PIBS. It might have been an issue with PIBS >> but I'm guessing the rest of the 4xx boards copied from either Ebony or >> Bamboo in their ports and hence contain that property. > >I think I recently added code to legacy_serial probe the speed from the >HW if the property is absent, which should help. Ok, so I think that is related to what I originally hit. I played around with removing the current-speed property on canyonlands today, and noticed that I would get no console output at all unless I specified a baudrate with console=ttyS0,115200. That was sort of contrary to what I found with bamboo, so I diffed the configs to see why. Bamboo has udbg enabled and hence has legacy_serial builtin, whereas canyonlands just has of_serial. So on boards where of_serial is the only serial driver, we need either an accurate current-speed property, or a specific baudrate on the command line. That makes a bit more tenuous to remove the properties entirely, because if people disable udbg and are relying on that behavior they get no more console output. Need to think on that a bit I guess. Alternatively, we could try patching of_serial.c to do the baudrate probe as well. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 8/9] powerpc/mm: remove duplicated #include
Remove duplicated #include('s) in
arch/powerpc/mm/tlb_low_64e.S
Signed-off-by: Huang Weiyi
---
arch/powerpc/mm/tlb_low_64e.S |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S
index ef1cccf..f288279 100644
--- a/arch/powerpc/mm/tlb_low_64e.S
+++ b/arch/powerpc/mm/tlb_low_64e.S
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
--
1.6.1.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/9] powerpc/book3e-64: remove duplicated #include
Remove duplicated #include('s) in
arch/powerpc/kernel/exceptions-64e.S
Signed-off-by: Huang Weiyi
---
arch/powerpc/kernel/exceptions-64e.S |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64e.S
b/arch/powerpc/kernel/exceptions-64e.S
index 9048f96..24dcc0e 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include
#include
#include
--
1.6.1.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Tue, Sep 15, 2009 at 08:28:34PM +0530, Balbir Singh wrote: > * Peter Zijlstra [2009-09-15 14:11:41]: > > > On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: > > > This patchset contains the offline state driver implemented for > > > pSeries. For pSeries, we define three available_hotplug_states. They are: > > > > > > online: The processor is online. > > > > > > offline: This is the the default behaviour when the cpu is > > > offlined > > > even in the absense of this driver. The CPU would call make an > > > rtas_stop_self() call and hand over the CPU back to the resource > > > pool, > > > thereby effectively deallocating that vCPU from the LPAR. > > > NOTE: This would result in a configuration change to the LPAR > > > which is visible to the outside world. > > > > > > inactive: This cedes the vCPU to the hypervisor with a cede > > > latency > > > specifier value 2. > > > NOTE: This option does not result in a configuration change > > > and the vCPU would be still entitled to the LPAR to which it > > > earlier > > > belong to. > > > > > > Any feedback on the patchset will be immensely valuable. > > > > I still think its a layering violation... its the hypervisor manager > > that should be bothered in what state an off-lined cpu is in. > > > > From a design standpoint where we stand today is > > 1. A cede indicates that the CPU is no longer needed and can be > reassigned (remember we do dedicated CPU partitions in power) > 2. What this patch is trying to do is to say "We don't need the > CPU, but please don't reassign, put it to sleep" FWIW, this sounds exactly like the same we have already on s390. But back then I didn't consider adding a common code infrastructure would make sense :) Besides the "online" attribute we have an additional "configure" attribute to which can only be written if the cpu is offline. Writing a "0" to it would mean that you currently won't need the cpu anymore and the hypervisor is free to reassign the cpu to a different LPAR. Writing a "1" to it means you want to use it. If there are enough resources you will get it. If not.. bad luck. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
