Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity
On 03/30/2016 03:38 PM, Tim Harvey wrote:
> On Wed, Mar 30, 2016 at 5:50 AM, Roberto Fichera <ker...@tekno-soft.it> wrote:
>> On 03/30/2016 12:10 PM, Arnd Bergmann wrote:
>>> On Wednesday 30 March 2016 10:00:33 Roberto Fichera wrote:
>>>>> Check your XIO2001 routing and insure the following for proper IRQ
>>>>> mapping:
>>>>> Slot12: IDSEL A28: socket INTA = XIO2001 INTA
>>>>> Slot13: IDSEL A29: socket INTA = XIO2001 INTB
>>>>> Slot14: IDSEL A30: socket INTA = XIO2001 INTC
>>>>> Slot15: IDSEL A31: socket INTA = XIO2001 INTD
>>>> After crosschecking with our hardware designer the PCB IRQ mapping is the
>>>> following:
>>>>
>>>> J2 : IDSEL A16: => Device 0 : socket INTA = XIO2001 INTA
>>>> J3 : IDSEL A18: => Device 2 : socket INTA = XIO2001 INTA* **(This should
>>>> be INTC)*
>>>> J11: IDSEL A20: => Device 4 : socket INTA = XIO2001 INTA
>>>>
>>>> The interrupt routing for J3 is wrong. The XIO2001 driver may expect
>>>> Device 2 to interrupt on INTC - but it will
>>>> interrupt on INTA.
>>> What does your interrupt-map property look like then?
>> Unfortunately it seems that J3 slot doesn't work anymore. Inserting a card
>> there, PCIe link will not come up anymore.
>> Likely I broke it. Looking at some spare logs I have, a card inserted in J3
>> will get another interrupt, was 291 however
>> unfortunately I don't have an usefull lspci -vv output, sorry! Will check in
>> it against another PCB when I can.
>>
>>> Note that you have to override both map and map-mask in this case.
>> Can you please give more details where should I have a look?
>>
>>> Arnd
>>>
> Robert,
>
> The interrupt-map / interrupt-map-mask properties are the ones that
> dictate irq mapping. In most cases they are defined at the host
> controller only and the kernel will assume standard interrupt
> swizzling (aka barber pole'ing) through bridges and will rotate
> interrupts (swizzle) for each bridge you go through. It is only if the
> interrupts are 'not' mapped properly (as in your case, and as was mine
> on a specific add-in card) that you need to define interrupt-map /
> interrupt-map-mask for the actual bridge with the interrupt mapping
> issue. So in other words, you won't have an interrupt-map/mask for
> your TI XIO2001 'currently', but you need to add one to describe its
> non-standard mapping.
>
> If you look at imx6qdl.dtsi you'll see the interrupt-map/mask for
> standard mapping is:
>
> interrupt-map-mask = <0 0 0 0x7>;
> interrupt-map = <0 0 0 1 GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
> <0 0 0 2 GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> <0 0 0 3 GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
> <0 0 0 4 GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
>
> This is because on the IMX6 INTA=GIC_123, INTB=GIC_122, INTC=GIC_121,
> INTD=GIC_120. The interrupt-map-mask is important because it decribes
> which bits of the 'unit interrupt specifier' each map pertains to. For
> the standard mapping above only the pin is important because this is
> the mapping for each slot so only the last three bits of the 'unit
> interrupt specifier' which has four cells is specified in the mask
> (0x7).
>
> In your case you will need to describe a map that depends not only on
> pin but on slot. The first 32bit cell in the 'unit interrupt
> specifier' defines the bus/domain/function (BDF) as: bus << 16 | dev
> << 11 | func <<8. This is also the same format for the first cell in
> the 'reg' property that describes each PCI device.
>
> If you are saying that your hardware did not swizzle the interrupts
> for the various slots then that means the above mapping needs to be
> applied to each slot the same. I
>
> You need to nest PCI devices as they appear on the bus, specifying reg
> properly. So, in your case you have a XIO2001 bridge hanging off of
> the IMX6 root complex. The root complex is at BDF 0:00.0, the XIO2001
> is at BDF 1:00.0, and its sockets are at bus=2. So you will need to
> add the following to your device-tree (fixing pinctrl and reset-gpio
> per your board specifics):
>
> {
> pinctrl-names = "default";
> pinctrl-0 = <_pcie>;
> reset-gpio = < 29 GPIO_ACTIVE_LOW>;
> status = "okay";
>
>/* 0:00.0 root complex */
>pcie@0,0,0 {
>reg = <0 0 0 0 0>; /* bus=0, dev=0, func=0 */
>
>/* 1:00.0 TI bridge with reversed IR
Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity
On 03/30/2016 03:38 PM, Tim Harvey wrote:
> On Wed, Mar 30, 2016 at 5:50 AM, Roberto Fichera wrote:
>> On 03/30/2016 12:10 PM, Arnd Bergmann wrote:
>>> On Wednesday 30 March 2016 10:00:33 Roberto Fichera wrote:
>>>>> Check your XIO2001 routing and insure the following for proper IRQ
>>>>> mapping:
>>>>> Slot12: IDSEL A28: socket INTA = XIO2001 INTA
>>>>> Slot13: IDSEL A29: socket INTA = XIO2001 INTB
>>>>> Slot14: IDSEL A30: socket INTA = XIO2001 INTC
>>>>> Slot15: IDSEL A31: socket INTA = XIO2001 INTD
>>>> After crosschecking with our hardware designer the PCB IRQ mapping is the
>>>> following:
>>>>
>>>> J2 : IDSEL A16: => Device 0 : socket INTA = XIO2001 INTA
>>>> J3 : IDSEL A18: => Device 2 : socket INTA = XIO2001 INTA* **(This should
>>>> be INTC)*
>>>> J11: IDSEL A20: => Device 4 : socket INTA = XIO2001 INTA
>>>>
>>>> The interrupt routing for J3 is wrong. The XIO2001 driver may expect
>>>> Device 2 to interrupt on INTC - but it will
>>>> interrupt on INTA.
>>> What does your interrupt-map property look like then?
>> Unfortunately it seems that J3 slot doesn't work anymore. Inserting a card
>> there, PCIe link will not come up anymore.
>> Likely I broke it. Looking at some spare logs I have, a card inserted in J3
>> will get another interrupt, was 291 however
>> unfortunately I don't have an usefull lspci -vv output, sorry! Will check in
>> it against another PCB when I can.
>>
>>> Note that you have to override both map and map-mask in this case.
>> Can you please give more details where should I have a look?
>>
>>> Arnd
>>>
> Robert,
>
> The interrupt-map / interrupt-map-mask properties are the ones that
> dictate irq mapping. In most cases they are defined at the host
> controller only and the kernel will assume standard interrupt
> swizzling (aka barber pole'ing) through bridges and will rotate
> interrupts (swizzle) for each bridge you go through. It is only if the
> interrupts are 'not' mapped properly (as in your case, and as was mine
> on a specific add-in card) that you need to define interrupt-map /
> interrupt-map-mask for the actual bridge with the interrupt mapping
> issue. So in other words, you won't have an interrupt-map/mask for
> your TI XIO2001 'currently', but you need to add one to describe its
> non-standard mapping.
>
> If you look at imx6qdl.dtsi you'll see the interrupt-map/mask for
> standard mapping is:
>
> interrupt-map-mask = <0 0 0 0x7>;
> interrupt-map = <0 0 0 1 GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
> <0 0 0 2 GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> <0 0 0 3 GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
> <0 0 0 4 GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
>
> This is because on the IMX6 INTA=GIC_123, INTB=GIC_122, INTC=GIC_121,
> INTD=GIC_120. The interrupt-map-mask is important because it decribes
> which bits of the 'unit interrupt specifier' each map pertains to. For
> the standard mapping above only the pin is important because this is
> the mapping for each slot so only the last three bits of the 'unit
> interrupt specifier' which has four cells is specified in the mask
> (0x7).
>
> In your case you will need to describe a map that depends not only on
> pin but on slot. The first 32bit cell in the 'unit interrupt
> specifier' defines the bus/domain/function (BDF) as: bus << 16 | dev
> << 11 | func <<8. This is also the same format for the first cell in
> the 'reg' property that describes each PCI device.
>
> If you are saying that your hardware did not swizzle the interrupts
> for the various slots then that means the above mapping needs to be
> applied to each slot the same. I
>
> You need to nest PCI devices as they appear on the bus, specifying reg
> properly. So, in your case you have a XIO2001 bridge hanging off of
> the IMX6 root complex. The root complex is at BDF 0:00.0, the XIO2001
> is at BDF 1:00.0, and its sockets are at bus=2. So you will need to
> add the following to your device-tree (fixing pinctrl and reset-gpio
> per your board specifics):
>
> {
> pinctrl-names = "default";
> pinctrl-0 = <_pcie>;
> reset-gpio = < 29 GPIO_ACTIVE_LOW>;
> status = "okay";
>
>/* 0:00.0 root complex */
>pcie@0,0,0 {
>reg = <0 0 0 0 0>; /* bus=0, dev=0, func=0 */
>
>/* 1:00.0 TI bridge with reversed IRQ mapping */
>
Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity
On 03/30/2016 12:10 PM, Arnd Bergmann wrote: > On Wednesday 30 March 2016 10:00:33 Roberto Fichera wrote: >>> Check your XIO2001 routing and insure the following for proper IRQ mapping: >>> Slot12: IDSEL A28: socket INTA = XIO2001 INTA >>> Slot13: IDSEL A29: socket INTA = XIO2001 INTB >>> Slot14: IDSEL A30: socket INTA = XIO2001 INTC >>> Slot15: IDSEL A31: socket INTA = XIO2001 INTD >> After crosschecking with our hardware designer the PCB IRQ mapping is the >> following: >> >> J2 : IDSEL A16: => Device 0 : socket INTA = XIO2001 INTA >> J3 : IDSEL A18: => Device 2 : socket INTA = XIO2001 INTA* **(This should be >> INTC)* >> J11: IDSEL A20: => Device 4 : socket INTA = XIO2001 INTA >> >> The interrupt routing for J3 is wrong. The XIO2001 driver may expect Device >> 2 to interrupt on INTC - but it will >> interrupt on INTA. > What does your interrupt-map property look like then? Unfortunately it seems that J3 slot doesn't work anymore. Inserting a card there, PCIe link will not come up anymore. Likely I broke it. Looking at some spare logs I have, a card inserted in J3 will get another interrupt, was 291 however unfortunately I don't have an usefull lspci -vv output, sorry! Will check in it against another PCB when I can. > Note that you have to override both map and map-mask in this case. Can you please give more details where should I have a look? > > Arnd >
Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity
On 03/30/2016 12:10 PM, Arnd Bergmann wrote: > On Wednesday 30 March 2016 10:00:33 Roberto Fichera wrote: >>> Check your XIO2001 routing and insure the following for proper IRQ mapping: >>> Slot12: IDSEL A28: socket INTA = XIO2001 INTA >>> Slot13: IDSEL A29: socket INTA = XIO2001 INTB >>> Slot14: IDSEL A30: socket INTA = XIO2001 INTC >>> Slot15: IDSEL A31: socket INTA = XIO2001 INTD >> After crosschecking with our hardware designer the PCB IRQ mapping is the >> following: >> >> J2 : IDSEL A16: => Device 0 : socket INTA = XIO2001 INTA >> J3 : IDSEL A18: => Device 2 : socket INTA = XIO2001 INTA* **(This should be >> INTC)* >> J11: IDSEL A20: => Device 4 : socket INTA = XIO2001 INTA >> >> The interrupt routing for J3 is wrong. The XIO2001 driver may expect Device >> 2 to interrupt on INTC - but it will >> interrupt on INTA. > What does your interrupt-map property look like then? Unfortunately it seems that J3 slot doesn't work anymore. Inserting a card there, PCIe link will not come up anymore. Likely I broke it. Looking at some spare logs I have, a card inserted in J3 will get another interrupt, was 291 however unfortunately I don't have an usefull lspci -vv output, sorry! Will check in it against another PCB when I can. > Note that you have to override both map and map-mask in this case. Can you please give more details where should I have a look? > > Arnd >
Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity
On 03/29/2016 07:31 PM, Tim Harvey wrote: > On Tue, Mar 29, 2016 at 9:44 AM, Roberto Fichera <ker...@tekno-soft.it> wrote: >>> >>> Roberto, >>> >>> What board/platform is this and what does /proc/interrupts look like? >> It's a custom board >> >> root@voneus-janas-imx6q:~# cat /proc/interrupts >>CPU0 CPU1 CPU2 CPU3 >> 16:936637 2057938 GIC 29 Edge twd >> 17: 0 0 0 0 GPC 55 Level >> i.MX Timer Tick >> 22:247 0 0 0 GPC 26 Level >> 202.serial >> 34: 0 0 0 0 gpio-mxc 6 Edge >> Factory Reset Button >> 267: 0 0 0 0 GPC 49 Level >> imx_thermal >> 272: 0 0 0 0 GPC 19 Level rtc >> alarm >> 278: 0 0 0 0 GPC 2 Level sdma >> 281:361 0 0 0 GIC 150 Level >> 2188000.ethernet >> 282: 0 0 0 0 GIC 151 Level >> 2188000.ethernet >> 283: 2882 0 0 0 GPC 25 Level mmc0 >> 284: 95 0 0 0 GPC 37 Level >> 21a4000.i2c >> 290: 36546 0 0 0 GPC 123 Level >> PCIe PME, b4xxp >> 291: 2 0 0 0 GIC 137 Level >> 2101000.jr0 >> 292: 0 0 0 0 GIC 138 Level >> 2102000.jr1 >> IPI0: 0 0 0 0 CPU wakeup interrupts >> IPI1: 0 0 0 0 Timer broadcast interrupts >> IPI2: 1642 1038 1626 1781 Rescheduling interrupts >> IPI3: 95 95122119 Function call interrupts >> IPI4: 3 0 2 0 Single function call >> interrupts >> IPI5: 0 0 0 0 CPU stop interrupts >> IPI6: 0 0 0 0 IRQ work interrupts >> IPI7: 0 0 0 0 completion interrupts >> Err: 0 >> >> >>> This sounds like what would happen if the downstream interrupts on the >>> PCIe-to-PCI bridge are not mapped properly as was the case with a >>> board I support (in which case I had to work out a bootloader fixup >>> that placed a non-standard interrupt-map in the device-tree for the >>> bridge). What bridge are you using? >> PCIe-to-PCI bridge is a Ti XIO2001 where we are using INTA/B only wired 1:1 >> > Roberto, > > That's right, we've talked about your bridge on IMX community. > > I don't see anything in your proc/interrupts other than GPC 123 - you > probably only had one device populated when you did that. Yep! That was the case > Put devices > in all for slots then show me 'cat /proc/interrupts' as well as 'lspci > -vv' (so that I can see what interrupt was given to pin1 and what > interrupt that maps to on the IMX6). GPC 123 is serving J2 and J1, and looks ok root@voneus-janas-imx6q:~# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 16: 7409 25043 2869 71444 GIC 29 Edge twd 17: 0 0 0 0 GPC 55 Level i.MX Timer Tick 22:526 0 0 0 GPC 26 Level 202.serial 34: 0 0 0 0 gpio-mxc 6 Edge Factory Reset Button 267: 0 0 0 0 GPC 49 Level imx_thermal 272: 0 0 0 0 GPC 19 Level rtc alarm 278: 0 0 0 0 GPC 2 Level sdma 281: 8808 0 0 0 GIC 150 Level 2188000.ethernet 282: 0 0 0 0 GIC 151 Level 2188000.ethernet 283: 2529 0 0 0 GPC 25 Level mmc0 284: 95 0 0 0 GPC 37 Level 21a4000.i2c 290:2391578 0 0 0 GPC 123 Level PCIe PME, b4xxp, b4xxp 291: 2 0 0 0 GIC 137 Level 2101000.jr0 292: 0 0 0 0 GIC 138 Level 2102000.jr1 IPI0: 0 0 0 0 CPU wakeup interrupts IPI1: 0 0 0 0 Timer broadcas
Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity
On 03/29/2016 07:31 PM, Tim Harvey wrote: > On Tue, Mar 29, 2016 at 9:44 AM, Roberto Fichera wrote: >>> >>> Roberto, >>> >>> What board/platform is this and what does /proc/interrupts look like? >> It's a custom board >> >> root@voneus-janas-imx6q:~# cat /proc/interrupts >>CPU0 CPU1 CPU2 CPU3 >> 16:936637 2057938 GIC 29 Edge twd >> 17: 0 0 0 0 GPC 55 Level >> i.MX Timer Tick >> 22:247 0 0 0 GPC 26 Level >> 202.serial >> 34: 0 0 0 0 gpio-mxc 6 Edge >> Factory Reset Button >> 267: 0 0 0 0 GPC 49 Level >> imx_thermal >> 272: 0 0 0 0 GPC 19 Level rtc >> alarm >> 278: 0 0 0 0 GPC 2 Level sdma >> 281:361 0 0 0 GIC 150 Level >> 2188000.ethernet >> 282: 0 0 0 0 GIC 151 Level >> 2188000.ethernet >> 283: 2882 0 0 0 GPC 25 Level mmc0 >> 284: 95 0 0 0 GPC 37 Level >> 21a4000.i2c >> 290: 36546 0 0 0 GPC 123 Level >> PCIe PME, b4xxp >> 291: 2 0 0 0 GIC 137 Level >> 2101000.jr0 >> 292: 0 0 0 0 GIC 138 Level >> 2102000.jr1 >> IPI0: 0 0 0 0 CPU wakeup interrupts >> IPI1: 0 0 0 0 Timer broadcast interrupts >> IPI2: 1642 1038 1626 1781 Rescheduling interrupts >> IPI3: 95 95122119 Function call interrupts >> IPI4: 3 0 2 0 Single function call >> interrupts >> IPI5: 0 0 0 0 CPU stop interrupts >> IPI6: 0 0 0 0 IRQ work interrupts >> IPI7: 0 0 0 0 completion interrupts >> Err: 0 >> >> >>> This sounds like what would happen if the downstream interrupts on the >>> PCIe-to-PCI bridge are not mapped properly as was the case with a >>> board I support (in which case I had to work out a bootloader fixup >>> that placed a non-standard interrupt-map in the device-tree for the >>> bridge). What bridge are you using? >> PCIe-to-PCI bridge is a Ti XIO2001 where we are using INTA/B only wired 1:1 >> > Roberto, > > That's right, we've talked about your bridge on IMX community. > > I don't see anything in your proc/interrupts other than GPC 123 - you > probably only had one device populated when you did that. Yep! That was the case > Put devices > in all for slots then show me 'cat /proc/interrupts' as well as 'lspci > -vv' (so that I can see what interrupt was given to pin1 and what > interrupt that maps to on the IMX6). GPC 123 is serving J2 and J1, and looks ok root@voneus-janas-imx6q:~# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 16: 7409 25043 2869 71444 GIC 29 Edge twd 17: 0 0 0 0 GPC 55 Level i.MX Timer Tick 22:526 0 0 0 GPC 26 Level 202.serial 34: 0 0 0 0 gpio-mxc 6 Edge Factory Reset Button 267: 0 0 0 0 GPC 49 Level imx_thermal 272: 0 0 0 0 GPC 19 Level rtc alarm 278: 0 0 0 0 GPC 2 Level sdma 281: 8808 0 0 0 GIC 150 Level 2188000.ethernet 282: 0 0 0 0 GIC 151 Level 2188000.ethernet 283: 2529 0 0 0 GPC 25 Level mmc0 284: 95 0 0 0 GPC 37 Level 21a4000.i2c 290:2391578 0 0 0 GPC 123 Level PCIe PME, b4xxp, b4xxp 291: 2 0 0 0 GIC 137 Level 2101000.jr0 292: 0 0 0 0 GIC 138 Level 2102000.jr1 IPI0: 0 0 0 0 CPU wakeup interrupts IPI1: 0 0 0 0 Timer broadcast interrupts IPI2:
Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity
On 03/29/2016 06:40 PM, Tim Harvey wrote: > On Tue, Mar 29, 2016 at 9:13 AM, Roberto Fichera <ker...@tekno-soft.it> wrote: >> On 03/29/2016 05:10 PM, Tim Harvey wrote: >>> Arnd, >>> >>> Right, on the IMX the MSI interrupt is GIC-120 which is also the >>> legacy INTD and I do see that if I happen to put a radio in a slot >>> where due to swizzling its pin1 becomes INTD (GIC-120) the interrupt >>> does fire and the device works. Any other slot using GIC-123 (INTA), >>> GIC-122 (INTB), or GIC-121 (INTC) never fires so its very possible >>> that something in the designware core is masking out the legacy irqs. >>> I would also think this was something IMX specific, but I really don't >>> see any codepaths in pci-imx6.c that would cause that: a driver >>> requesting a legacy PCI would get a GIC interrupt which is handled by >>> the IMX6 gpc interrupt controller. >>> >>> Any dra7xxx, exynos, spear13xx, keystone, layerscape, hisi, qcom SoC >>> users of designware PCIe core out there that can verify PCI MSI and >>> legacy are both working at the same time? >>> >>> Lucas is the expert here and I believe he has the documentation for >>> the designware core that Freescale doens't provide with the IMX6 >>> documentation so hopefully he can provide some insight. He's the one >>> that has authored all the MSI support and has been using it. >>> >>> I typically advise our users to 'not' enable MSI because >>> architecturally you can spread 4 distinct legacy irq's across CPU's >>> better than a single shared irq. >> Don't know if I'm facing similar problem, however devices connected in >> miniPCI slot behind >> a PCIe-to-PCI bridge (MSI is disabled) using INTA all is working ok, >> including shared IRQ. >> In case of INTB will not work, and the GIC irq quite often get stuck. >> > Roberto, > > What board/platform is this and what does /proc/interrupts look like? It's a custom board root@voneus-janas-imx6q:~# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 16:936637 2057938 GIC 29 Edge twd 17: 0 0 0 0 GPC 55 Level i.MX Timer Tick 22:247 0 0 0 GPC 26 Level 202.serial 34: 0 0 0 0 gpio-mxc 6 Edge Factory Reset Button 267: 0 0 0 0 GPC 49 Level imx_thermal 272: 0 0 0 0 GPC 19 Level rtc alarm 278: 0 0 0 0 GPC 2 Level sdma 281:361 0 0 0 GIC 150 Level 2188000.ethernet 282: 0 0 0 0 GIC 151 Level 2188000.ethernet 283: 2882 0 0 0 GPC 25 Level mmc0 284: 95 0 0 0 GPC 37 Level 21a4000.i2c 290: 36546 0 0 0 GPC 123 Level PCIe PME, b4xxp 291: 2 0 0 0 GIC 137 Level 2101000.jr0 292: 0 0 0 0 GIC 138 Level 2102000.jr1 IPI0: 0 0 0 0 CPU wakeup interrupts IPI1: 0 0 0 0 Timer broadcast interrupts IPI2: 1642 1038 1626 1781 Rescheduling interrupts IPI3: 95 95122119 Function call interrupts IPI4: 3 0 2 0 Single function call interrupts IPI5: 0 0 0 0 CPU stop interrupts IPI6: 0 0 0 0 IRQ work interrupts IPI7: 0 0 0 0 completion interrupts Err: 0 > > This sounds like what would happen if the downstream interrupts on the > PCIe-to-PCI bridge are not mapped properly as was the case with a > board I support (in which case I had to work out a bootloader fixup > that placed a non-standard interrupt-map in the device-tree for the > bridge). What bridge are you using? PCIe-to-PCI bridge is a Ti XIO2001 where we are using INTA/B only wired 1:1 > > Tim >
Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity
On 03/29/2016 06:40 PM, Tim Harvey wrote: > On Tue, Mar 29, 2016 at 9:13 AM, Roberto Fichera wrote: >> On 03/29/2016 05:10 PM, Tim Harvey wrote: >>> Arnd, >>> >>> Right, on the IMX the MSI interrupt is GIC-120 which is also the >>> legacy INTD and I do see that if I happen to put a radio in a slot >>> where due to swizzling its pin1 becomes INTD (GIC-120) the interrupt >>> does fire and the device works. Any other slot using GIC-123 (INTA), >>> GIC-122 (INTB), or GIC-121 (INTC) never fires so its very possible >>> that something in the designware core is masking out the legacy irqs. >>> I would also think this was something IMX specific, but I really don't >>> see any codepaths in pci-imx6.c that would cause that: a driver >>> requesting a legacy PCI would get a GIC interrupt which is handled by >>> the IMX6 gpc interrupt controller. >>> >>> Any dra7xxx, exynos, spear13xx, keystone, layerscape, hisi, qcom SoC >>> users of designware PCIe core out there that can verify PCI MSI and >>> legacy are both working at the same time? >>> >>> Lucas is the expert here and I believe he has the documentation for >>> the designware core that Freescale doens't provide with the IMX6 >>> documentation so hopefully he can provide some insight. He's the one >>> that has authored all the MSI support and has been using it. >>> >>> I typically advise our users to 'not' enable MSI because >>> architecturally you can spread 4 distinct legacy irq's across CPU's >>> better than a single shared irq. >> Don't know if I'm facing similar problem, however devices connected in >> miniPCI slot behind >> a PCIe-to-PCI bridge (MSI is disabled) using INTA all is working ok, >> including shared IRQ. >> In case of INTB will not work, and the GIC irq quite often get stuck. >> > Roberto, > > What board/platform is this and what does /proc/interrupts look like? It's a custom board root@voneus-janas-imx6q:~# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 16:936637 2057938 GIC 29 Edge twd 17: 0 0 0 0 GPC 55 Level i.MX Timer Tick 22:247 0 0 0 GPC 26 Level 202.serial 34: 0 0 0 0 gpio-mxc 6 Edge Factory Reset Button 267: 0 0 0 0 GPC 49 Level imx_thermal 272: 0 0 0 0 GPC 19 Level rtc alarm 278: 0 0 0 0 GPC 2 Level sdma 281:361 0 0 0 GIC 150 Level 2188000.ethernet 282: 0 0 0 0 GIC 151 Level 2188000.ethernet 283: 2882 0 0 0 GPC 25 Level mmc0 284: 95 0 0 0 GPC 37 Level 21a4000.i2c 290: 36546 0 0 0 GPC 123 Level PCIe PME, b4xxp 291: 2 0 0 0 GIC 137 Level 2101000.jr0 292: 0 0 0 0 GIC 138 Level 2102000.jr1 IPI0: 0 0 0 0 CPU wakeup interrupts IPI1: 0 0 0 0 Timer broadcast interrupts IPI2: 1642 1038 1626 1781 Rescheduling interrupts IPI3: 95 95122119 Function call interrupts IPI4: 3 0 2 0 Single function call interrupts IPI5: 0 0 0 0 CPU stop interrupts IPI6: 0 0 0 0 IRQ work interrupts IPI7: 0 0 0 0 completion interrupts Err: 0 > > This sounds like what would happen if the downstream interrupts on the > PCIe-to-PCI bridge are not mapped properly as was the case with a > board I support (in which case I had to work out a bootloader fixup > that placed a non-standard interrupt-map in the device-tree for the > bridge). What bridge are you using? PCIe-to-PCI bridge is a Ti XIO2001 where we are using INTA/B only wired 1:1 > > Tim >
Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity
On 03/29/2016 05:10 PM, Tim Harvey wrote: > Arnd, > > Right, on the IMX the MSI interrupt is GIC-120 which is also the > legacy INTD and I do see that if I happen to put a radio in a slot > where due to swizzling its pin1 becomes INTD (GIC-120) the interrupt > does fire and the device works. Any other slot using GIC-123 (INTA), > GIC-122 (INTB), or GIC-121 (INTC) never fires so its very possible > that something in the designware core is masking out the legacy irqs. > I would also think this was something IMX specific, but I really don't > see any codepaths in pci-imx6.c that would cause that: a driver > requesting a legacy PCI would get a GIC interrupt which is handled by > the IMX6 gpc interrupt controller. > > Any dra7xxx, exynos, spear13xx, keystone, layerscape, hisi, qcom SoC > users of designware PCIe core out there that can verify PCI MSI and > legacy are both working at the same time? > > Lucas is the expert here and I believe he has the documentation for > the designware core that Freescale doens't provide with the IMX6 > documentation so hopefully he can provide some insight. He's the one > that has authored all the MSI support and has been using it. > > I typically advise our users to 'not' enable MSI because > architecturally you can spread 4 distinct legacy irq's across CPU's > better than a single shared irq. Don't know if I'm facing similar problem, however devices connected in miniPCI slot behind a PCIe-to-PCI bridge (MSI is disabled) using INTA all is working ok, including shared IRQ. In case of INTB will not work, and the GIC irq quite often get stuck.
Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity
On 03/29/2016 05:10 PM, Tim Harvey wrote: > Arnd, > > Right, on the IMX the MSI interrupt is GIC-120 which is also the > legacy INTD and I do see that if I happen to put a radio in a slot > where due to swizzling its pin1 becomes INTD (GIC-120) the interrupt > does fire and the device works. Any other slot using GIC-123 (INTA), > GIC-122 (INTB), or GIC-121 (INTC) never fires so its very possible > that something in the designware core is masking out the legacy irqs. > I would also think this was something IMX specific, but I really don't > see any codepaths in pci-imx6.c that would cause that: a driver > requesting a legacy PCI would get a GIC interrupt which is handled by > the IMX6 gpc interrupt controller. > > Any dra7xxx, exynos, spear13xx, keystone, layerscape, hisi, qcom SoC > users of designware PCIe core out there that can verify PCI MSI and > legacy are both working at the same time? > > Lucas is the expert here and I believe he has the documentation for > the designware core that Freescale doens't provide with the IMX6 > documentation so hopefully he can provide some insight. He's the one > that has authored all the MSI support and has been using it. > > I typically advise our users to 'not' enable MSI because > architecturally you can spread 4 distinct legacy irq's across CPU's > better than a single shared irq. Don't know if I'm facing similar problem, however devices connected in miniPCI slot behind a PCIe-to-PCI bridge (MSI is disabled) using INTA all is working ok, including shared IRQ. In case of INTB will not work, and the GIC irq quite often get stuck.
iMX6 SSI in TDM master mode and SDMA
i_private->tx_buffer_len = buffer_len;
ssi_private->tx_buffer_count = buffer_len;
ssi_private->tx_buf = dma_alloc_coherent(NULL, buffer_len,
_private->tx_dmaaddr, GFP_KERNEL);
if (!ssi_private->tx_buf) {
printk("cannot alloc TX DMA buffer.\n");
return -ENOMEM;
}
desc = dmaengine_prep_dma_cyclic(ssi_private->tx_chan,
ssi_private->tx_dmaaddr,
buffer_len, ssi_private->tdm_real_slots*4,
DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT);
if (!desc) {
printk("Prepare for the TX slave dma failed!\n");
return -EINVAL;
}
desc->callback = dma_tx_callback;
desc->callback_param = ssi_private;
printk("TX: prepare for the DMA.\n");
dmaengine_submit(desc);
dma_async_issue_pending(ssi_private->tx_chan);
}
Once I'll enable the SSI clock to enable the TDM, I'm getting only 2000 or so
interrupts and then everything freeze.
Below some log related to the imx-sdma reporting correctly all wml, shp_addr
and 2 entry having 8 bytes each
dmaengine: private_candidate: wrong capabilities
dmaengine: __dma_request_channel: success (dma1chan0)
imx-sdma 20ec000.sdma: load_address = 960
imx-sdma 20ec000.sdma: wml = 0x0008
imx-sdma 20ec000.sdma: shp_addr = 0x02028000
imx-sdma 20ec000.sdma: per_addr = 0x
imx-sdma 20ec000.sdma: event_mask0 = 0x
imx-sdma 20ec000.sdma: event_mask1 = 0x0040
dmaengine: private_candidate: wrong capabilities
dmaengine: private_candidate: dma1chan0 busy
dmaengine: __dma_request_channel: success (dma1chan1)
imx-sdma 20ec000.sdma: load_address = 891
imx-sdma 20ec000.sdma: wml = 0x0008
imx-sdma 20ec000.sdma: shp_addr = 0x02028008
imx-sdma 20ec000.sdma: per_addr = 0x
imx-sdma 20ec000.sdma: event_mask0 = 0x
imx-sdma 20ec000.sdma: event_mask1 = 0x0020
si3217x_ssi_probe: SSI base is 0xa0b1 clock rate is 2048000Hz, TDM Frame
rate 8000Hz, channels 8 having 8 bits word
length
si3217x_audmux_probe: AUDMUX base is 0xa0b18000
si3217x_probe: SPI setup mode 3, 8 bits/w, 1000 Hz max
imx-sdma 20ec000.sdma: sdma_prep_dma_cyclic channel: 2
imx-sdma 20ec000.sdma: load_address = 891
imx-sdma 20ec000.sdma: wml = 0x0008
imx-sdma 20ec000.sdma: shp_addr = 0x02028008
imx-sdma 20ec000.sdma: per_addr = 0x
imx-sdma 20ec000.sdma: event_mask0 = 0x
imx-sdma 20ec000.sdma: event_mask1 = 0x0020
imx-sdma 20ec000.sdma: entry 0: count: 8 dma: 0x9c4a intr
imx-sdma 20ec000.sdma: entry 1: count: 8 dma: 0x9c4a0008 wrap intr
RX: prepare for the DMA.
imx-sdma 20ec000.sdma: sdma_prep_dma_cyclic channel: 1
imx-sdma 20ec000.sdma: load_address = 960
imx-sdma 20ec000.sdma: wml = 0x0008
imx-sdma 20ec000.sdma: shp_addr = 0x02028000
imx-sdma 20ec000.sdma: per_addr = 0x
imx-sdma 20ec000.sdma: event_mask0 = 0x
imx-sdma 20ec000.sdma: event_mask1 = 0x0040
imx-sdma 20ec000.sdma: entry 0: count: 8 dma: 0x9c495000 intr
imx-sdma 20ec000.sdma: entry 1: count: 8 dma: 0x9c495008 wrap intr
TX: prepare for the DMA.
si3217x_ssi_setup: tdm_slots_enabled=0x0003, 0xfffc
si3217x_ssi_setup: SSI_STMSK=0x00fc,SSI_SRMSK=0x00fc
si3217x_ssi_set_clock: BIT_CLK=53248000
Finally the SSI1 registers are set like this:
ssi_scr=0x00bf
ssi_sier=0x01d005f5
ssi_stcr=0x02e8
ssi_srcr=0x0288
ssi_stccr=0x670b
ssi_srccr=0x670b
ssi_sfcsr=0x0088f088
ssi_stmsk=0xfffc
ssi_srmsk=0xfffc
and the statistics related to DMA freeze as
RX DMA frame count=1001
RX DMA addr=0x9c659000
RX DMA buffer len=16
TX DMA frame count=1003
TX DMA addr=0x9c658000
TX DMA buffer len=16
Does anyone can suggest how to make the DMA working?
Thanks in advance,
Roberto Fichera.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
iMX6 SSI in TDM master mode and SDMA
i_private->tx_buffer_len = buffer_len;
ssi_private->tx_buffer_count = buffer_len;
ssi_private->tx_buf = dma_alloc_coherent(NULL, buffer_len,
_private->tx_dmaaddr, GFP_KERNEL);
if (!ssi_private->tx_buf) {
printk("cannot alloc TX DMA buffer.\n");
return -ENOMEM;
}
desc = dmaengine_prep_dma_cyclic(ssi_private->tx_chan,
ssi_private->tx_dmaaddr,
buffer_len, ssi_private->tdm_real_slots*4,
DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT);
if (!desc) {
printk("Prepare for the TX slave dma failed!\n");
return -EINVAL;
}
desc->callback = dma_tx_callback;
desc->callback_param = ssi_private;
printk("TX: prepare for the DMA.\n");
dmaengine_submit(desc);
dma_async_issue_pending(ssi_private->tx_chan);
}
Once I'll enable the SSI clock to enable the TDM, I'm getting only 2000 or so
interrupts and then everything freeze.
Below some log related to the imx-sdma reporting correctly all wml, shp_addr
and 2 entry having 8 bytes each
dmaengine: private_candidate: wrong capabilities
dmaengine: __dma_request_channel: success (dma1chan0)
imx-sdma 20ec000.sdma: load_address = 960
imx-sdma 20ec000.sdma: wml = 0x0008
imx-sdma 20ec000.sdma: shp_addr = 0x02028000
imx-sdma 20ec000.sdma: per_addr = 0x
imx-sdma 20ec000.sdma: event_mask0 = 0x
imx-sdma 20ec000.sdma: event_mask1 = 0x0040
dmaengine: private_candidate: wrong capabilities
dmaengine: private_candidate: dma1chan0 busy
dmaengine: __dma_request_channel: success (dma1chan1)
imx-sdma 20ec000.sdma: load_address = 891
imx-sdma 20ec000.sdma: wml = 0x0008
imx-sdma 20ec000.sdma: shp_addr = 0x02028008
imx-sdma 20ec000.sdma: per_addr = 0x
imx-sdma 20ec000.sdma: event_mask0 = 0x
imx-sdma 20ec000.sdma: event_mask1 = 0x0020
si3217x_ssi_probe: SSI base is 0xa0b1 clock rate is 2048000Hz, TDM Frame
rate 8000Hz, channels 8 having 8 bits word
length
si3217x_audmux_probe: AUDMUX base is 0xa0b18000
si3217x_probe: SPI setup mode 3, 8 bits/w, 1000 Hz max
imx-sdma 20ec000.sdma: sdma_prep_dma_cyclic channel: 2
imx-sdma 20ec000.sdma: load_address = 891
imx-sdma 20ec000.sdma: wml = 0x0008
imx-sdma 20ec000.sdma: shp_addr = 0x02028008
imx-sdma 20ec000.sdma: per_addr = 0x
imx-sdma 20ec000.sdma: event_mask0 = 0x
imx-sdma 20ec000.sdma: event_mask1 = 0x0020
imx-sdma 20ec000.sdma: entry 0: count: 8 dma: 0x9c4a intr
imx-sdma 20ec000.sdma: entry 1: count: 8 dma: 0x9c4a0008 wrap intr
RX: prepare for the DMA.
imx-sdma 20ec000.sdma: sdma_prep_dma_cyclic channel: 1
imx-sdma 20ec000.sdma: load_address = 960
imx-sdma 20ec000.sdma: wml = 0x0008
imx-sdma 20ec000.sdma: shp_addr = 0x02028000
imx-sdma 20ec000.sdma: per_addr = 0x
imx-sdma 20ec000.sdma: event_mask0 = 0x
imx-sdma 20ec000.sdma: event_mask1 = 0x0040
imx-sdma 20ec000.sdma: entry 0: count: 8 dma: 0x9c495000 intr
imx-sdma 20ec000.sdma: entry 1: count: 8 dma: 0x9c495008 wrap intr
TX: prepare for the DMA.
si3217x_ssi_setup: tdm_slots_enabled=0x0003, 0xfffc
si3217x_ssi_setup: SSI_STMSK=0x00fc,SSI_SRMSK=0x00fc
si3217x_ssi_set_clock: BIT_CLK=53248000
Finally the SSI1 registers are set like this:
ssi_scr=0x00bf
ssi_sier=0x01d005f5
ssi_stcr=0x02e8
ssi_srcr=0x0288
ssi_stccr=0x670b
ssi_srccr=0x670b
ssi_sfcsr=0x0088f088
ssi_stmsk=0xfffc
ssi_srmsk=0xfffc
and the statistics related to DMA freeze as
RX DMA frame count=1001
RX DMA addr=0x9c659000
RX DMA buffer len=16
TX DMA frame count=1003
TX DMA addr=0x9c658000
TX DMA buffer len=16
Does anyone can suggest how to make the DMA working?
Thanks in advance,
Roberto Fichera.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] Development release 0.1 of the LatencyTOP tool
At 18.36 18/01/2008, Arjan van de Ven wrote:
>The Intel Open Source Technology Center is pleased to announce the
>release of version 0.1 of LatencyTOP, a tool for developers to visualize
>system latencies.
>
>http://www.latencytop.org
>
[...snip...]
>
>The most basic annotation looks like this (in the patches more complex
>versions can be seen):
>
> asmlinkage long sys_sync(void)
> {
>+ struct latency_entry reason;
>+ set_latency_reason("sync system call", );
> do_sync(1);
>+ restore_latency_reason();
>+
> return 0;
> }
>
I really like this patch :-)! Just a little note, why don't make
the parameter 'char *reason' as simple integer (reason_t)?
Making it as integer will automatically drop the strncmp()
and speeding up all the things. Could be also interesting to
define _externally_ the mapping of the reason so the
userspace tool could handle it easily.
Roberto Fichera.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] Development release 0.1 of the LatencyTOP tool
At 19.35 18/01/2008, Arjan van de Ven wrote:
>Roberto Fichera wrote:
>> At 18.36 18/01/2008, Arjan van de Ven wrote:
>>> The Intel Open Source Technology Center is pleased to announce the
>>> release of version 0.1 of LatencyTOP, a tool for developers to visualize
>>> system latencies.
>>>
>>> http://www.latencytop.org
>>>
>>
>> [...snip...]
>>
>>> The most basic annotation looks like this (in the patches more complex
>>> versions can be seen):
>>>
>>> asmlinkage long sys_sync(void)
>>> {
>>> + struct latency_entry reason;
>>> + set_latency_reason("sync system call", );
>>> do_sync(1);
>>> + restore_latency_reason();
>>> +
>>> return 0;
>>> }
>>>
>>
>> I really like this patch :-)! Just a little note, why don't make
>> the parameter 'char *reason' as simple integer (reason_t)?
>> Making it as integer will automatically drop the strncmp()
>> and speeding up all the things. Could be also interesting to
>> define _externally_ the mapping of the reason so the
>> userspace tool could handle it easily.
>>
>
>I thought about that, but the strncmp is still somewhat needed to deal
>with the argument
>(the instrumentation above doesn't use that, but the mutex one does
>for example)
>If we get rid of the argument entirely it'd be easier
>(but then we get "blocking on mutex" rather than "blocking on inode->mutex")
Duh! I didn't notice it! Now I see ;-)!
>
Roberto Fichera.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] Development release 0.1 of the LatencyTOP tool
At 19.35 18/01/2008, Arjan van de Ven wrote:
Roberto Fichera wrote:
At 18.36 18/01/2008, Arjan van de Ven wrote:
The Intel Open Source Technology Center is pleased to announce the
release of version 0.1 of LatencyTOP, a tool for developers to visualize
system latencies.
http://www.latencytop.org
[...snip...]
The most basic annotation looks like this (in the patches more complex
versions can be seen):
asmlinkage long sys_sync(void)
{
+ struct latency_entry reason;
+ set_latency_reason(sync system call, reason);
do_sync(1);
+ restore_latency_reason(reason);
+
return 0;
}
I really like this patch :-)! Just a little note, why don't make
the parameter 'char *reason' as simple integer (reason_t)?
Making it as integer will automatically drop the strncmp()
and speeding up all the things. Could be also interesting to
define _externally_ the mapping of the reason so the
userspace tool could handle it easily.
I thought about that, but the strncmp is still somewhat needed to deal
with the argument
(the instrumentation above doesn't use that, but the mutex one does
for example)
If we get rid of the argument entirely it'd be easier
(but then we get blocking on mutex rather than blocking on inode-mutex)
Duh! I didn't notice it! Now I see ;-)!
Roberto Fichera.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Soft lockup detected on CPU#X
Hi All, I'm experiencing some soft lockup problem on fedora core 5 v2.6.19-1.2288.fc5 x86_64 with a dual HT Xeon 3.2GHz EMT in ASUS NCT-D mobo. This problem still happening everytime I switch on the box, but disappear if I reboot the box by a Ctrl-Alt-Canc just after the BIOS startup and without booting the kernel. The box stay up without any problem so far. Furthermore booting with noapic the box doesn't show any problem. The bios on the motherboard has been already updated to the last available. Does anyone have some tips to suggest? Feb 16 13:06:14 spargi kernel: EXT3 FS on sda1, internal journal Feb 16 13:06:14 spargi kernel: EXT3-fs: mounted filesystem with ordered data mode. Feb 16 13:06:14 spargi kernel: Adding 4192956k swap on /dev/sda2. Priority:-1 extents:1 across:4192956k Feb 16 13:06:14 spargi kernel: IA-32 Microcode Update Driver: v1.14a <[EMAIL PROTECTED]> Feb 16 13:06:14 spargi kernel: ip_tables: (C) 2000-2006 Netfilter Core Team Feb 16 13:06:14 spargi kernel: Netfilter messages via NETLINK v0.30. Feb 16 13:06:14 spargi kernel: ip_conntrack version 2.4 (8192 buckets, 65536 max) - 312 bytes per conntrack Feb 16 13:06:14 spargi kernel: skge eth0: enabling interface Feb 16 13:06:14 spargi kernel: skge eth0: Link is up at 100 Mbps, full duplex, flow control both Feb 16 13:06:29 spargi kernel: BUG: soft lockup detected on CPU#3! Feb 16 13:06:29 spargi kernel: Feb 16 13:06:29 spargi kernel: Call Trace: Feb 16 13:06:29 spargi kernel: [] show_trace+0x34/0x47 Feb 16 13:06:29 spargi kernel: [] dump_stack+0x12/0x17 Feb 16 13:06:29 spargi kernel: [] softlockup_tick+0xdb/0xf6 Feb 16 13:06:29 spargi kernel: [] update_process_times+0x42/0x68 Feb 16 13:06:29 spargi kernel: [] smp_local_timer_interrupt+0x34/0x55 Feb 16 13:06:29 spargi kernel: [] smp_apic_timer_interrupt+0x51/0x69 Feb 16 13:06:29 spargi kernel: [] apic_timer_interrupt+0x66/0x70 Feb 16 13:06:29 spargi kernel: [] mwait_idle_with_hints+0x44/0x45 Feb 16 13:06:29 spargi kernel: [] mwait_idle+0xc/0x20 Feb 16 13:06:29 spargi kernel: [] cpu_idle+0x8b/0xae Feb 16 13:06:29 spargi kernel: [] start_secondary+0x462/0x471 Feb 16 13:06:29 spargi kernel: Feb 16 13:06:29 spargi kernel: BUG: soft lockup detected on CPU#1! Feb 16 13:06:29 spargi kernel: Feb 16 13:06:29 spargi kernel: Call Trace: Feb 16 13:06:29 spargi kernel: [] show_trace+0x34/0x47 Feb 16 13:06:29 spargi kernel: [] dump_stack+0x12/0x17 Feb 16 13:06:29 spargi kernel: [] softlockup_tick+0xdb/0xf6 Feb 16 13:06:29 spargi kernel: [] update_process_times+0x42/0x68 Feb 16 13:06:29 spargi kernel: [] smp_local_timer_interrupt+0x34/0x55 Feb 16 13:06:29 spargi kernel: [] smp_apic_timer_interrupt+0x51/0x69 Feb 16 13:06:29 spargi kernel: [] apic_timer_interrupt+0x66/0x70 Feb 16 13:06:29 spargi kernel: [] mwait_idle_with_hints+0x44/0x45 Feb 16 13:06:29 spargi kernel: [] mwait_idle+0xc/0x20 Feb 16 13:06:29 spargi kernel: [] cpu_idle+0x8b/0xae Feb 16 13:06:29 spargi kernel: [] start_secondary+0x462/0x471 Feb 16 13:06:29 spargi kernel: Feb 16 13:06:29 spargi kernel: BUG: soft lockup detected on CPU#0! Feb 16 13:06:29 spargi kernel: Feb 16 13:06:29 spargi kernel: Call Trace: Feb 16 13:06:29 spargi kernel: [] show_trace+0x34/0x47 Feb 16 13:06:29 spargi kernel: [] dump_stack+0x12/0x17 Feb 16 13:06:29 spargi kernel: [] softlockup_tick+0xdb/0xf6 Feb 16 13:06:29 spargi kernel: [] update_process_times+0x42/0x68 Feb 16 13:06:29 spargi kernel: [] smp_local_timer_interrupt+0x34/0x55 Feb 16 13:06:29 spargi kernel: [] smp_apic_timer_interrupt+0x51/0x69 Feb 16 13:06:29 spargi kernel: [] apic_timer_interrupt+0x66/0x70 Feb 16 13:06:29 spargi kernel: [] mwait_idle_with_hints+0x44/0x45 Feb 16 13:06:29 spargi kernel: [] mwait_idle+0xc/0x20 Feb 16 13:06:29 spargi kernel: [] cpu_idle+0x8b/0xae Feb 16 13:06:29 spargi kernel: [] start_kernel+0x240/0x245 Feb 16 13:06:29 spargi kernel: [] _sinittext+0x15a/0x15e Feb 16 13:06:29 spargi kernel: Roberto Fichera. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Soft lockup detected on CPU#X
Hi All, I'm experiencing some soft lockup problem on fedora core 5 v2.6.19-1.2288.fc5 x86_64 with a dual HT Xeon 3.2GHz EMT in ASUS NCT-D mobo. This problem still happening everytime I switch on the box, but disappear if I reboot the box by a Ctrl-Alt-Canc just after the BIOS startup and without booting the kernel. The box stay up without any problem so far. Furthermore booting with noapic the box doesn't show any problem. The bios on the motherboard has been already updated to the last available. Does anyone have some tips to suggest? Feb 16 13:06:14 spargi kernel: EXT3 FS on sda1, internal journal Feb 16 13:06:14 spargi kernel: EXT3-fs: mounted filesystem with ordered data mode. Feb 16 13:06:14 spargi kernel: Adding 4192956k swap on /dev/sda2. Priority:-1 extents:1 across:4192956k Feb 16 13:06:14 spargi kernel: IA-32 Microcode Update Driver: v1.14a [EMAIL PROTECTED] Feb 16 13:06:14 spargi kernel: ip_tables: (C) 2000-2006 Netfilter Core Team Feb 16 13:06:14 spargi kernel: Netfilter messages via NETLINK v0.30. Feb 16 13:06:14 spargi kernel: ip_conntrack version 2.4 (8192 buckets, 65536 max) - 312 bytes per conntrack Feb 16 13:06:14 spargi kernel: skge eth0: enabling interface Feb 16 13:06:14 spargi kernel: skge eth0: Link is up at 100 Mbps, full duplex, flow control both Feb 16 13:06:29 spargi kernel: BUG: soft lockup detected on CPU#3! Feb 16 13:06:29 spargi kernel: Feb 16 13:06:29 spargi kernel: Call Trace: Feb 16 13:06:29 spargi kernel: [802699c5] show_trace+0x34/0x47 Feb 16 13:06:29 spargi kernel: [802699ea] dump_stack+0x12/0x17 Feb 16 13:06:29 spargi kernel: [802b536e] softlockup_tick+0xdb/0xf6 Feb 16 13:06:29 spargi kernel: [802921d8] update_process_times+0x42/0x68 Feb 16 13:06:29 spargi kernel: [80274322] smp_local_timer_interrupt+0x34/0x55 Feb 16 13:06:29 spargi kernel: [802749d6] smp_apic_timer_interrupt+0x51/0x69 Feb 16 13:06:29 spargi kernel: [8025ccf6] apic_timer_interrupt+0x66/0x70 Feb 16 13:06:29 spargi kernel: [8026911d] mwait_idle_with_hints+0x44/0x45 Feb 16 13:06:29 spargi kernel: [80255eee] mwait_idle+0xc/0x20 Feb 16 13:06:29 spargi kernel: [80247ec6] cpu_idle+0x8b/0xae Feb 16 13:06:29 spargi kernel: [8027412f] start_secondary+0x462/0x471 Feb 16 13:06:29 spargi kernel: Feb 16 13:06:29 spargi kernel: BUG: soft lockup detected on CPU#1! Feb 16 13:06:29 spargi kernel: Feb 16 13:06:29 spargi kernel: Call Trace: Feb 16 13:06:29 spargi kernel: [802699c5] show_trace+0x34/0x47 Feb 16 13:06:29 spargi kernel: [802699ea] dump_stack+0x12/0x17 Feb 16 13:06:29 spargi kernel: [802b536e] softlockup_tick+0xdb/0xf6 Feb 16 13:06:29 spargi kernel: [802921d8] update_process_times+0x42/0x68 Feb 16 13:06:29 spargi kernel: [80274322] smp_local_timer_interrupt+0x34/0x55 Feb 16 13:06:29 spargi kernel: [802749d6] smp_apic_timer_interrupt+0x51/0x69 Feb 16 13:06:29 spargi kernel: [8025ccf6] apic_timer_interrupt+0x66/0x70 Feb 16 13:06:29 spargi kernel: [8026911d] mwait_idle_with_hints+0x44/0x45 Feb 16 13:06:29 spargi kernel: [80255eee] mwait_idle+0xc/0x20 Feb 16 13:06:29 spargi kernel: [80247ec6] cpu_idle+0x8b/0xae Feb 16 13:06:29 spargi kernel: [8027412f] start_secondary+0x462/0x471 Feb 16 13:06:29 spargi kernel: Feb 16 13:06:29 spargi kernel: BUG: soft lockup detected on CPU#0! Feb 16 13:06:29 spargi kernel: Feb 16 13:06:29 spargi kernel: Call Trace: Feb 16 13:06:29 spargi kernel: [802699c5] show_trace+0x34/0x47 Feb 16 13:06:29 spargi kernel: [802699ea] dump_stack+0x12/0x17 Feb 16 13:06:29 spargi kernel: [802b536e] softlockup_tick+0xdb/0xf6 Feb 16 13:06:29 spargi kernel: [802921d8] update_process_times+0x42/0x68 Feb 16 13:06:29 spargi kernel: [80274322] smp_local_timer_interrupt+0x34/0x55 Feb 16 13:06:29 spargi kernel: [802749d6] smp_apic_timer_interrupt+0x51/0x69 Feb 16 13:06:29 spargi kernel: [8025ccf6] apic_timer_interrupt+0x66/0x70 Feb 16 13:06:29 spargi kernel: [8026911d] mwait_idle_with_hints+0x44/0x45 Feb 16 13:06:29 spargi kernel: [80255eee] mwait_idle+0xc/0x20 Feb 16 13:06:29 spargi kernel: [80247ec6] cpu_idle+0x8b/0xae Feb 16 13:06:29 spargi kernel: [806627a0] start_kernel+0x240/0x245 Feb 16 13:06:29 spargi kernel: [8066215a] _sinittext+0x15a/0x15e Feb 16 13:06:29 spargi kernel: Roberto Fichera. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
HDD Errors ?!
Hi All,
today I found this in my /var/log/messages:
Jun 1 05:26:47 radius kernel: hda: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 1 05:26:47 radius kernel: hda: read_intr: error=0x40 {
UncorrectableError }, LBAsect=25358813, sector=25165970
Jun 1 05:26:47 radius kernel: end_request: I/O error, dev 03:06 (hda),
sector 25165970
Jun 1 05:26:47 radius kernel: EXT2-fs error (device ide0(3,6)):
ext2_read_inode: unable to read inode block - inode=1570229, block=3145746
Jun 1 05:26:53 radius kernel: hda: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 1 05:26:53 radius kernel: hda: read_intr: error=0x40 {
UncorrectableError }, LBAsect=25358813, sector=25165970
Jun 1 05:26:53 radius kernel: end_request: I/O error, dev 03:06 (hda),
sector 25165970
Jun 1 05:26:53 radius kernel: EXT2-fs error (device ide0(3,6)):
ext2_write_inode: unable to read inode block - inode=1570229, block=3145746
Jun 1 05:27:18 radius kernel: hda: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 1 05:27:18 radius kernel: hda: read_intr: error=0x40 {
UncorrectableError }, LBAsect=25096667, sector=24903824
Jun 1 05:27:18 radius kernel: end_request: I/O error, dev 03:06 (hda),
sector 24903824
Jun 1 05:27:18 radius kernel: EXT2-fs error (device ide0(3,6)):
ext2_read_inode: unable to read inode block - inode=1553880, block=3112978
Jun 1 05:27:23 radius kernel: hda: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 1 05:27:23 radius kernel: hda: read_intr: error=0x40 {
UncorrectableError }, LBAsect=25096667, sector=24903824
Jun 1 05:27:23 radius kernel: end_request: I/O error, dev 03:06 (hda),
sector 24903824
Jun 1 05:27:23 radius kernel: EXT2-fs error (device ide0(3,6)):
ext2_write_inode: unable to read inode block - inode=1553880, block=3112978
It's a disk error or a FS error ? What can I do to fix the problem ? I
500Km distant from this machine :-(
and I want made some check remotely before reboot it.
Any suggestion ?
Thanks in advance.
Roberto Fichera.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
HDD Errors ?!
Hi All,
today I found this in my /var/log/messages:
Jun 1 05:26:47 radius kernel: hda: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 1 05:26:47 radius kernel: hda: read_intr: error=0x40 {
UncorrectableError }, LBAsect=25358813, sector=25165970
Jun 1 05:26:47 radius kernel: end_request: I/O error, dev 03:06 (hda),
sector 25165970
Jun 1 05:26:47 radius kernel: EXT2-fs error (device ide0(3,6)):
ext2_read_inode: unable to read inode block - inode=1570229, block=3145746
Jun 1 05:26:53 radius kernel: hda: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 1 05:26:53 radius kernel: hda: read_intr: error=0x40 {
UncorrectableError }, LBAsect=25358813, sector=25165970
Jun 1 05:26:53 radius kernel: end_request: I/O error, dev 03:06 (hda),
sector 25165970
Jun 1 05:26:53 radius kernel: EXT2-fs error (device ide0(3,6)):
ext2_write_inode: unable to read inode block - inode=1570229, block=3145746
Jun 1 05:27:18 radius kernel: hda: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 1 05:27:18 radius kernel: hda: read_intr: error=0x40 {
UncorrectableError }, LBAsect=25096667, sector=24903824
Jun 1 05:27:18 radius kernel: end_request: I/O error, dev 03:06 (hda),
sector 24903824
Jun 1 05:27:18 radius kernel: EXT2-fs error (device ide0(3,6)):
ext2_read_inode: unable to read inode block - inode=1553880, block=3112978
Jun 1 05:27:23 radius kernel: hda: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 1 05:27:23 radius kernel: hda: read_intr: error=0x40 {
UncorrectableError }, LBAsect=25096667, sector=24903824
Jun 1 05:27:23 radius kernel: end_request: I/O error, dev 03:06 (hda),
sector 24903824
Jun 1 05:27:23 radius kernel: EXT2-fs error (device ide0(3,6)):
ext2_write_inode: unable to read inode block - inode=1553880, block=3112978
It's a disk error or a FS error ? What can I do to fix the problem ? I
500Km distant from this machine :-(
and I want made some check remotely before reboot it.
Any suggestion ?
Thanks in advance.
Roberto Fichera.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec Array1000
At 10.51 26/03/01 -0700, Justin T. Gibbs wrote: > >Hi all, > > > >Does anyone know how to configure this controller (chipset AAA-133U2 > >aka AIC-78xx) with one RAID5 hardware volume ? The kernel 2.2.16 see > >all the disks (4x18Gb) but don't see the unique volume. > >These boards are not currently supported in RAID mode. Your >best bet is Linux MD. Ok! As I was thinking, I must configure it with Linux MD. Thanks. Roberto Fichera. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Adaptec Array1000
Hi all, Does anyone know how to configure this controller (chipset AAA-133U2 aka AIC-78xx) with one RAID5 hardware volume ? The kernel 2.2.16 see all the disks (4x18Gb) but don't see the unique volume. Thanks in advance. Roberto Fichera. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Adaptec Array1000
Hi all, Does anyone know how to configure this controller (chipset AAA-133U2 aka AIC-78xx) with one RAID5 hardware volume ? The kernel 2.2.16 see all the disks (4x18Gb) but don't see the unique volume. Thanks in advance. Roberto Fichera. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec Array1000
At 10.51 26/03/01 -0700, Justin T. Gibbs wrote: Hi all, Does anyone know how to configure this controller (chipset AAA-133U2 aka AIC-78xx) with one RAID5 hardware volume ? The kernel 2.2.16 see all the disks (4x18Gb) but don't see the unique volume. These boards are not currently supported in RAID mode. Your best bet is Linux MD. Ok! As I was thinking, I must configure it with Linux MD. Thanks. Roberto Fichera. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm->rss is modified without page_table_lock held
At 07.00 09/12/00 -0800, David S. Miller wrote:
>Date: Sat, 09 Dec 2000 16:07:03 +0100
>From: Roberto Fichera <[EMAIL PROTECTED]>
>
>8 bits for a spinlock ? What kind of use we have here ?
>
>Sparc32 (like some other older architectures) do not have a
>word atomic update instruction, but it does have a byte spinlock.
>To conserve space and implement the atomic update properly, we
>use a spinlock in the top byte of the word.
There's any possibility ;-) to define it as
typedef struct { volatile char spinlock, volatile long counter } atomic_t;
>Also, this sematic was decided upon many eons ago, changing it a month
>before 2.4.0 just to deal with this mm->rss atomicity issue is not
>going to happen. The spinlock patch exists, and if nothing better
>comes up, we should just use it.
Indeed! You are right! I was thinking to optimize it, using a
spinlock/unlock we spent
several time for a inc.
Roberto Fichera.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm->rss is modified without page_table_lock held
At 06.42 09/12/00 -0800, David S. Miller wrote: >Date: Sat, 09 Dec 2000 15:48:05 +0100 >From: Roberto Fichera <[EMAIL PROTECTED]> > >>atomic_t does not guarentee a large enough range necessary for mm->rss > >If we haven't some atomic_t that can be negative we could define atomic_t >as unsigned long for all arch, >this is sufficient to fitting all the range for the mm->rss. > >32-bit Sparc has unsigned long as 32-bit, and the top 8 bits of the >atomic_t are used for a spinlock, thus a 27-bit atomic_t, there >is not enough precision. 8 bits for a spinlock ? What kind of use we have here ? All arch except Sparc32 don't have this trick. Roberto Fichera. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm->rss is modified without page_table_lock held
At 13.43 09/12/00 +0100, Rasmus Andersen wrote: >On Sat, Dec 09, 2000 at 11:25:09AM +0100, Roberto Fichera wrote: >[...] > > >+ spin_lock(>page_table_lock); > > > mm->rss++; > > >+ spin_unlock(>page_table_lock); > > > > > > > [...snip...] > > > > Why we couldn't use atomic_inc(>rss) here and below, avoiding to wrap > > the inc with a spin_lock()/spin_unlock() ? > > > >AFAIR, because for some architectures we can't rely on mm->rss fitting in >an atomic_t. See davem's (somewhat short) post in this thread. Otherwise >search the archives for the original thread treating this problem. and At 04.32 09/12/00 -0800, David S. Miller wrote: >Date:Sat, 09 Dec 2000 11:25:09 +0100 >From: Roberto Fichera <[EMAIL PROTECTED]> > >Why we couldn't use atomic_inc(>rss) here and below, avoiding to wrap >the inc with a spin_lock()/spin_unlock() ? > >atomic_t does not guarentee a large enough range necessary for mm->rss If we haven't some atomic_t that can be negative we could define atomic_t as unsigned long for all arch, this is sufficient to fitting all the range for the mm->rss. Roberto Fichera. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm->rss is modified without page_table_lock held
At 21.29 08/12/00 +0100, Rasmus Andersen wrote: >Hi. > >The following patch moves the page_table_lock in mm/* to cover the >modification of mm->rss in 240-test12-pre7. It was inspired by a >similar patch from davej(?) which covered too much, AFAIR. The item >is on Tytso's ToDo list. [...snip...] >@@ -1076,7 +1076,9 @@ > flush_icache_page(vma, page); > } > >+ spin_lock(>page_table_lock); > mm->rss++; >+ spin_unlock(>page_table_lock); > [...snip...] Why we couldn't use atomic_inc(>rss) here and below, avoiding to wrap the inc with a spin_lock()/spin_unlock() ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm-rss is modified without page_table_lock held
At 21.29 08/12/00 +0100, Rasmus Andersen wrote: Hi. The following patch moves the page_table_lock in mm/* to cover the modification of mm-rss in 240-test12-pre7. It was inspired by a similar patch from davej(?) which covered too much, AFAIR. The item is on Tytso's ToDo list. [...snip...] @@ -1076,7 +1076,9 @@ flush_icache_page(vma, page); } + spin_lock(mm-page_table_lock); mm-rss++; + spin_unlock(mm-page_table_lock); [...snip...] Why we couldn't use atomic_inc(mm-rss) here and below, avoiding to wrap the inc with a spin_lock()/spin_unlock() ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm-rss is modified without page_table_lock held
At 13.43 09/12/00 +0100, Rasmus Andersen wrote: On Sat, Dec 09, 2000 at 11:25:09AM +0100, Roberto Fichera wrote: [...] + spin_lock(mm-page_table_lock); mm-rss++; + spin_unlock(mm-page_table_lock); [...snip...] Why we couldn't use atomic_inc(mm-rss) here and below, avoiding to wrap the inc with a spin_lock()/spin_unlock() ? AFAIR, because for some architectures we can't rely on mm-rss fitting in an atomic_t. See davem's (somewhat short) post in this thread. Otherwise search the archives for the original thread treating this problem. and At 04.32 09/12/00 -0800, David S. Miller wrote: Date:Sat, 09 Dec 2000 11:25:09 +0100 From: Roberto Fichera [EMAIL PROTECTED] Why we couldn't use atomic_inc(mm-rss) here and below, avoiding to wrap the inc with a spin_lock()/spin_unlock() ? atomic_t does not guarentee a large enough range necessary for mm-rss If we haven't some atomic_t that can be negative we could define atomic_t as unsigned long for all arch, this is sufficient to fitting all the range for the mm-rss. Roberto Fichera. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm-rss is modified without page_table_lock held
At 06.42 09/12/00 -0800, David S. Miller wrote: Date: Sat, 09 Dec 2000 15:48:05 +0100 From: Roberto Fichera [EMAIL PROTECTED] atomic_t does not guarentee a large enough range necessary for mm-rss If we haven't some atomic_t that can be negative we could define atomic_t as unsigned long for all arch, this is sufficient to fitting all the range for the mm-rss. 32-bit Sparc has unsigned long as 32-bit, and the top 8 bits of the atomic_t are used for a spinlock, thus a 27-bit atomic_t, there is not enough precision. 8 bits for a spinlock ? What kind of use we have here ? All arch except Sparc32 don't have this trick. Roberto Fichera. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm-rss is modified without page_table_lock held
At 07.00 09/12/00 -0800, David S. Miller wrote:
Date: Sat, 09 Dec 2000 16:07:03 +0100
From: Roberto Fichera [EMAIL PROTECTED]
8 bits for a spinlock ? What kind of use we have here ?
Sparc32 (like some other older architectures) do not have a
word atomic update instruction, but it does have a byte spinlock.
To conserve space and implement the atomic update properly, we
use a spinlock in the top byte of the word.
There's any possibility ;-) to define it as
typedef struct { volatile char spinlock, volatile long counter } atomic_t;
Also, this sematic was decided upon many eons ago, changing it a month
before 2.4.0 just to deal with this mm-rss atomicity issue is not
going to happen. The spinlock patch exists, and if nothing better
comes up, we should just use it.
Indeed! You are right! I was thinking to optimize it, using a
spinlock/unlock we spent
several time for a inc.
Roberto Fichera.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Ext2 & Performances
At 19.00 21/11/00 +0100, Jakob Østergaard wrote: >On Tue, Nov 21, 2000 at 05:58:58PM +0100, Roberto Fichera wrote: > > Hi All, > > > > I need to know if there are some differences, in performances, between > > a ext2 filesystem in a 10Gb partition and another that reside in a 130Gb, > > each one have 4Kb block size. > > > > I'm configuring a Compaq ML350 2x800PIII, 1Gb RAM, 5x36Gb UWS3 RAID 5 > > with Smart Array 4300, as database SQL server. So I need to chose > between a > > single > > partition of 130Gb or multiple small partitions, depending by the > performances. > >Does your database *require* a filesystem ? At least Oracle can do without, >but I don't know about others... Currently I'm using PostgreSQL. >Usually, if you want performance, you let the database use the block device >without putting a filesystem on top of it. Yes! I know! Oracle should be a good choice for that. >You probably don't want a 130G ext2 if there is any chance that a power >surge etc. can cause the machine to reboot without umount()'ing the >filesystem. A fsck on a 130G filesystem is going to take a *long* time. Yes! I know :-((!!! I'm looking for other fs that are journaled like ext3 or raiserfs but I don't know which are a good choice for stability and performances. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Ext2 & Performances
Hi All, I need to know if there are some differences, in performances, between a ext2 filesystem in a 10Gb partition and another that reside in a 130Gb, each one have 4Kb block size. I'm configuring a Compaq ML350 2x800PIII, 1Gb RAM, 5x36Gb UWS3 RAID 5 with Smart Array 4300, as database SQL server. So I need to chose between a single partition of 130Gb or multiple small partitions, depending by the performances. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Ext2 Performances
Hi All, I need to know if there are some differences, in performances, between a ext2 filesystem in a 10Gb partition and another that reside in a 130Gb, each one have 4Kb block size. I'm configuring a Compaq ML350 2x800PIII, 1Gb RAM, 5x36Gb UWS3 RAID 5 with Smart Array 4300, as database SQL server. So I need to chose between a single partition of 130Gb or multiple small partitions, depending by the performances. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Ext2 Performances
At 19.00 21/11/00 +0100, Jakob Østergaard wrote: On Tue, Nov 21, 2000 at 05:58:58PM +0100, Roberto Fichera wrote: Hi All, I need to know if there are some differences, in performances, between a ext2 filesystem in a 10Gb partition and another that reside in a 130Gb, each one have 4Kb block size. I'm configuring a Compaq ML350 2x800PIII, 1Gb RAM, 5x36Gb UWS3 RAID 5 with Smart Array 4300, as database SQL server. So I need to chose between a single partition of 130Gb or multiple small partitions, depending by the performances. Does your database *require* a filesystem ? At least Oracle can do without, but I don't know about others... Currently I'm using PostgreSQL. Usually, if you want performance, you let the database use the block device without putting a filesystem on top of it. Yes! I know! Oracle should be a good choice for that. You probably don't want a 130G ext2 if there is any chance that a power surge etc. can cause the machine to reboot without umount()'ing the filesystem. A fsck on a 130G filesystem is going to take a *long* time. Yes! I know :-((!!! I'm looking for other fs that are journaled like ext3 or raiserfs but I don't know which are a good choice for stability and performances. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Lists problems ?
At 11.10 23/10/00 +0300, Matti Aarnio wrote: >On Mon, Oct 23, 2000 at 10:56:15AM +0100, Roberto Fichera wrote: > > I'm receiving duplicated email from Linux-Kernel, Linux-Net and Linux-SMP. > > There's some problems ? > >Yes, yours. Double subscription. (Except the linux-smp) >Which you want removed ? > >linux-kernel: [EMAIL PROTECTED] >linux-kernel: [EMAIL PROTECTED] >linux-net:[EMAIL PROTECTED] >linux-net:[EMAIL PROTECTED] >linux-smp:[EMAIL PROTECTED] > > > > Thanks. > >/Matti Aarnio Oopss!!! You can remove [EMAIL PROTECTED] Sorry for the noise ! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Lists problems ?
I'm receiving duplicated email from Linux-Kernel, Linux-Net and Linux-SMP. There's some problems ? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Lists problems ?
I'm receiving duplicated email from Linux-Kernel, Linux-Net and Linux-SMP. There's some problems ? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Lists problems ?
At 11.10 23/10/00 +0300, Matti Aarnio wrote: On Mon, Oct 23, 2000 at 10:56:15AM +0100, Roberto Fichera wrote: I'm receiving duplicated email from Linux-Kernel, Linux-Net and Linux-SMP. There's some problems ? Yes, yours. Double subscription. (Except the linux-smp) Which you want removed ? linux-kernel: [EMAIL PROTECTED] linux-kernel: [EMAIL PROTECTED] linux-net:[EMAIL PROTECTED] linux-net:[EMAIL PROTECTED] linux-smp:[EMAIL PROTECTED] Thanks. /Matti Aarnio Oopss!!! You can remove [EMAIL PROTECTED] Sorry for the noise ! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
