* Re: [PATCH] Increase the upper bound on NR_CPUS.
From: Michael Ellerman @ 2007-11-29 4:44 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20071129042314.GN24243@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]
On Thu, 2007-11-29 at 15:23 +1100, Tony Breeds wrote:
> On Thu, Nov 29, 2007 at 03:17:16PM +1100, Michael Ellerman wrote:
> > On Thu, 2007-11-29 at 15:16 +1100, Tony Breeds wrote:
> > > Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> > >
> > > ---
> > > why not?
> >
> > How big is say a pseries_defconfig with NR_CPUS = 1024 ?
>
> This is a ppc64_defconfig, with a couple of extra patches, and
> NR_CPUS=1024
>
> tony@Sprygo:~/scratch/working$ size ../working_out/arch/powerpc/boot/zImage.{pmac,pseries,iseries} ../working_out/vmlinux
> text data bss dec hex filename
> 3697092 5356 48232 3750680 393b18 ../working_out/arch/powerpc/boot/zImage.pmac
> 3697092 5356 48232 3750680 393b18 ../working_out/arch/powerpc/boot/zImage.pseries
> 8101340 4994176 815544 13911060 d44414 ../working_out/arch/powerpc/boot/zImage.iseries
> 8101340 4994176 815544 13911060 d44414 ../working_out/vmlinux
OK, not too bad for the zImage, but the vmlinux has grown a bit, we
obviously have lots of foo[NR_CPUS].
NR_CPUS = 32 vs 1024
text data bss dec hex filename
7889287 1786256 529248 10204791 9bb677 vmlinux
7901531 4946864 814432 13662827 d07a6b vmlinux
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] PPC: CELLEB - fix potential NULL pointer dereference
From: Cyrill Gorcunov @ 2007-11-29 5:41 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: olof, paulus, linux-kernel, linuxppc-dev
In-Reply-To: <20071129.122245.-1300543769.kouish@swc.toshiba.co.jp>
[-- Attachment #1: Type: text/plain, Size: 369 bytes --]
On 11/29/07, Ishizaki Kou <kou.ishizaki@toshiba.co.jp> wrote:
[...snip...]
>
> There is no problem to use Michael's part, and I also prefer simple
> one like this.
>
> Cyrill, would you please update your patch?
>
> Best regards,
> Kou Ishizaki
>
Please see updated patch enveloped. (Can't do it inline becase I'm on
my work now where I have no Linux machine)
Cyrill
[-- Attachment #2: ppc-celleb-fix-null-v2.diff --]
[-- Type: text/plain, Size: 1977 bytes --]
---
From: Cyrill Gorcunov <gorcunov@gmail.com>
Subject: [PATCH] PPC: CELLEB - fix possible NULL pointer dereference
This patch adds checking for NULL returned value to
prevent possible NULL pointer dereference.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
---
arch/powerpc/platforms/celleb/pci.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/pci.c b/arch/powerpc/platforms/celleb/pci.c
index 6bc32fd..13ec4a6 100644
--- a/arch/powerpc/platforms/celleb/pci.c
+++ b/arch/powerpc/platforms/celleb/pci.c
@@ -138,8 +138,6 @@ static void celleb_config_read_fake(unsigned char *config, int where,
*val = celleb_fake_config_readl(p);
break;
}
-
- return;
}
static void celleb_config_write_fake(unsigned char *config, int where,
@@ -158,7 +156,6 @@ static void celleb_config_write_fake(unsigned char *config, int where,
celleb_fake_config_writel(val, p);
break;
}
- return;
}
static int celleb_fake_pci_read_config(struct pci_bus *bus,
@@ -351,6 +348,10 @@ static int __init celleb_setup_fake_pci_device(struct device_node *node,
wi1 = of_get_property(node, "vendor-id", NULL);
wi2 = of_get_property(node, "class-code", NULL);
wi3 = of_get_property(node, "revision-id", NULL);
+ if (!wi0 || !wi1 || !wi2 || !wi3) {
+ printk(KERN_ERR "PCI: Missing device tree properties.\n");
+ goto error;
+ }
celleb_config_write_fake(*config, PCI_DEVICE_ID, 2, wi0[0] & 0xffff);
celleb_config_write_fake(*config, PCI_VENDOR_ID, 2, wi1[0] & 0xffff);
@@ -372,6 +373,10 @@ static int __init celleb_setup_fake_pci_device(struct device_node *node,
celleb_setup_pci_base_addrs(hose, devno, fn, num_base_addr);
li = of_get_property(node, "interrupts", &rlen);
+ if (!li) {
+ printk(KERN_ERR "PCI: interrupts not found.\n");
+ goto error;
+ }
val = li[0];
celleb_config_write_fake(*config, PCI_INTERRUPT_PIN, 1, 1);
celleb_config_write_fake(*config, PCI_INTERRUPT_LINE, 1, val);
^ permalink raw reply related
* Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Stefan Roese @ 2007-11-29 6:10 UTC (permalink / raw)
To: Dell Query; +Cc: linuxppc-embedded
In-Reply-To: <556469.76659.qm@web45605.mail.sp1.yahoo.com>
On Thursday 29 November 2007, Dell Query wrote:
> I don't know if the document that came with the PPC440EPx Sequoia Resource
> CD is right. It is odd that it is entitled "Embedded Planet 440xC" and it
> showed in page 34:
> -----------------------------------------------------------------------
> Table 4-4. Memory Map
>
> Function Start Address End Address Size Chip Select
> DDR SDRAM 0x0000 0000 0x0FFF FFFF 256 MB =E2=80=94
> PCI Memory 0x8000 0000 0xBFFF FFFF 1024 MB =E2=80=94
> BCSR 0xC000 0000 0xCFFF FFFF 256 MB CS2
> NAND FLASH Controller1 0xD000 0000 0xD00F FFFF 1 MB CS3/CS0
> NOR FLASH1 0xFC00 0000 0xFFFF FFFF 64 MB CS0/CS3
> -----------------------------------------------------------------------
> Anyway, I have seen Table 1. System Memory Address Map and it got EBC
> mapped at 0x1.c000.0000 and another one at 0x1.f000.0000. But I didn't s=
ee
> any BCSR info. Correct me if I am wrong, but should it not give me BCSR
> details like:
This is board specific information and not CPU specific. The CPLD with it's=
=20
BCSR is a Sequoia thing and can therefor not be listed in the 440EPx manual=
s.=20
It it located on the EBC though which is documented in the 440EPx manuals.
So if this chips select which is connected to the CPLD is mapped to=20
0xc000.0000 which is the case for Sequoia, then you will "find" these=20
registers at physical address 0x1.c000.0000. And should use ioremap64() to=
=20
get the virtual address to access this CPLD.
Best regards,
Stefan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
^ permalink raw reply
* Re: [PATCH] Increase the upper bound on NR_CPUS.
From: Stephen Rothwell @ 2007-11-29 6:23 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20071129041603.GM24243@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
Hi Tony, :-)
On Thu, 29 Nov 2007 15:16:03 +1100 tony@bakeyournoodle.com (Tony Breeds) wrote:
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
NAK ... you need to change the static initialisation of the paca
structures to match ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-git2 softlockup detected
From: Kamalesh Babulal @ 2007-11-29 6:31 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-scsi, LKML, Rafael J. Wysocki, linuxppc-dev, Balbir Singh
In-Reply-To: <20071127232552.ad16e95c.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Wed, 28 Nov 2007 12:47:19 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
>> Andrew Morton wrote:
>>> On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>>>
>>>> Hi,
>>> (cc linux-scsi, for sym53c8xx)
>>>
>>>> Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
>>> I assume this is a post-2.6.23 regression?
>>>
>>>> BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375]
>>>> NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
>>>> REGS: c00000077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest)
>>>> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
>>>> TASK = c00000077cbd8000[375] 'insmod' THREAD: c00000077cbec000 CPU: 1
>>>> GPR00: d0000000001414fc c00000077cbef330 c00000000052b930 d000080080002014
>>>> GPR04: d00008008000202c 0000000000000000 c00000077ca1cb00 d00000000014ce54
>>>> GPR08: c00000077ca1c63c 0000000000000000 000000000000002a c00000000002f018
>>>> GPR12: d000000000143610 c000000000473d00
>>>> NIP [c00000000002f02c] .ioread8+0x14/0x60
>>>> LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
>>>> Call Trace:
>>>> [c00000077cbef330] [c00000077cbef3c0] 0xc00000077cbef3c0 (unreliable)
>>>> [c00000077cbef3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
>>>> [c00000077cbef470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
>>>> [c00000077cbef710] [c0000000001bc118] .pci_device_probe+0x124/0x1b0
>>>> [c00000077cbef7b0] [c000000000221138] .driver_probe_device+0x144/0x20c
>>>> [c00000077cbef850] [c000000000221450] .__driver_attach+0xcc/0x154
>>>> [c00000077cbef8e0] [c00000000021ff94] .bus_for_each_dev+0x7c/0xd4
>>>> [c00000077cbef9a0] [c000000000220e9c] .driver_attach+0x28/0x40
>>>> [c00000077cbefa20] [c0000000002204d8] .bus_add_driver+0x90/0x228
>>>> [c00000077cbefac0] [c000000000221858] .driver_register+0x94/0xb0
>>>> [c00000077cbefb40] [c0000000001bc430] .__pci_register_driver+0x6c/0xcc
>>>> [c00000077cbefbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
>>>> [c00000077cbefc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
>>>> [c00000077cbefe30] [c00000000000872c] syscall_exit+0x0/0x40
>>>> Instruction dump:
>>>> 60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
>>>> f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
>>> I see no obvious lockup sites near the end of sym_hcb_attach(). Maybe it's
>>> being called lots of times from a higher level.. Do the traces all look
>>> the same?
>> Hi Andrew,
>>
>> I see this call trace twice and both looks similar and on another reboot
>> the following trace is seen twice in different cpu
>>
>> BUG: soft lockup detected on CPU#3!
>> Call Trace:
>> [C00000003FEDEDA0] [C000000000010220] .show_stack+0x68/0x1b0 (unreliable)
>> [C00000003FEDEE40] [C0000000000A061C] .softlockup_tick+0xf0/0x13c
>> [C00000003FEDEEF0] [C000000000072E2C] .run_local_timers+0x1c/0x30
>> [C00000003FEDEF70] [C000000000022FA0] .timer_interrupt+0xa8/0x488
>> [C00000003FEDF050] [C0000000000034EC] decrementer_common+0xec/0x100
>> --- Exception: 901 at .ioread8+0x14/0x60
>> LR = .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
>> [C00000003FEDF340] [D0000000002B3BC0] 0xd0000000002b3bc0 (unreliable)
>> [C00000003FEDF3B0] [D00000000029A3C0] .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
>> [C00000003FEDF480] [D000000000291D30] .sym2_probe+0x75c/0x9f8 [sym53c8xx]
>> [C00000003FEDF710] [C0000000001B65A4] .pci_device_probe+0x13c/0x1dc
>> [C00000003FEDF7D0] [C000000000219A0C] .driver_probe_device+0xa0/0x15c
>> [C00000003FEDF870] [C000000000219C64] .__driver_attach+0xb4/0x138
>> [C00000003FEDF900] [C00000000021913C] .bus_for_each_dev+0x7c/0xd4
>> [C00000003FEDF9C0] [C0000000002198B0] .driver_attach+0x28/0x40
>> [C00000003FEDFA40] [C000000000218BA4] .bus_add_driver+0x98/0x18c
>> [C00000003FEDFAE0] [C00000000021A064] .driver_register+0xa8/0xc4
>> [C00000003FEDFB60] [C0000000001B68AC] .__pci_register_driver+0x5c/0xa4
>> [C00000003FEDFBF0] [D00000000029C204] .sym2_init+0x104/0x1550 [sym53c8xx]
>> [C00000003FEDFC90] [C00000000008D1F4] .sys_init_module+0x1764/0x1998
>> [C00000003FEDFE30] [C00000000000869C] syscall_exit+0x0/0x40
>>
>
> hm, odd.
>
> Can you look up sym_hcb_attach+0x1194/0x1384 in gdb? Something like
>
Hi Andrew,
I tried with 2.6.24-rc3-git3 and got the following trace
BUG: soft lockup - CPU#2 stuck for 11s! [insmod:375]
NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
REGS: c00000077ca3b0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git3-autokern1)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
TASK = c00000077cc58000[375] 'insmod' THREAD: c00000077ca38000 CPU: 2
GPR00: d0000000001414fc c00000077ca3b330 c00000000052b880 d000080080002014
GPR04: d00008008000202c 0000000000000000 c00000077c82eb00 d00000000014ce54
GPR08: c00000077c82e63c 0000000000000000 000000000000002a c00000000002f018
GPR12: d000000000143610 c000000000473f80
NIP [c00000000002f02c] .ioread8+0x14/0x60
LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
Call Trace:
[c00000077ca3b330] [c00000077ca3b3c0] 0xc00000077ca3b3c0 (unreliable)
[c00000077ca3b3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
[c00000077ca3b470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
[c00000077ca3b710] [c0000000001bc098] .pci_device_probe+0x124/0x1b0
[c00000077ca3b7b0] [c0000000002210c4] .driver_probe_device+0x144/0x20c
[c00000077ca3b850] [c0000000002213dc] .__driver_attach+0xcc/0x154
[c00000077ca3b8e0] [c00000000021ff20] .bus_for_each_dev+0x7c/0xd4
[c00000077ca3b9a0] [c000000000220e28] .driver_attach+0x28/0x40
[c00000077ca3ba20] [c000000000220464] .bus_add_driver+0x90/0x228
[c00000077ca3bac0] [c0000000002217e4] .driver_register+0x94/0xb0
[c00000077ca3bb40] [c0000000001bc3b0] .__pci_register_driver+0x6c/0xcc
[c00000077ca3bbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
[c00000077ca3bc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
[c00000077ca3be30] [c00000000000872c] syscall_exit+0x0/0x40
Instruction dump:
60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
The gdb list the following for the above trace
0xa4fc is in sym_hcb_attach (drivers/scsi/sym53c8xx_2/sym_hipd.c:1041).
1036 OUTL_DSP(np, pc);
1037 /*
1038 * Wait 'til done (with timeout)
1039 */
1040 for (i=0; i<SYM_SNOOP_TIMEOUT; i++)
1041 if (INB(np, nc_istat) & (INTF|SIP|DIP))
1042 break;
1043 if (i>=SYM_SNOOP_TIMEOUT) {
1044 printf ("CACHE TEST FAILED: timeout.\n");
1045 return (0x20);
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Dell Query @ 2007-11-29 6:41 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200711290710.29403.sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 2546 bytes --]
I see. No wonder I couldn't get more information on BCSR. I should contact sequoia to get the proper details like the correct addresses.
I already used ioremap64(), remapping 0x1c0002000. I got a hex value for the Board ID but could figure out what it means. So I tried the USER_LED0/USER_LED1 (base address+0x2), to see if I could turn on/off the user LEDS, but still no luck.
I think I am accessing the wrong addresses so I need to verify it with them.
Thanks!
Regards,
dell
Stefan Roese <sr@denx.de> wrote: On Thursday 29 November 2007, Dell Query wrote:
> I don't know if the document that came with the PPC440EPx Sequoia Resource
> CD is right. It is odd that it is entitled "Embedded Planet 440xC" and it
> showed in page 34:
> -----------------------------------------------------------------------
> Table 4-4. Memory Map
>
> Function Start Address End Address Size Chip Select
> DDR SDRAM 0x0000 0000 0x0FFF FFFF 256 MB —
> PCI Memory 0x8000 0000 0xBFFF FFFF 1024 MB —
> BCSR 0xC000 0000 0xCFFF FFFF 256 MB CS2
> NAND FLASH Controller1 0xD000 0000 0xD00F FFFF 1 MB CS3/CS0
> NOR FLASH1 0xFC00 0000 0xFFFF FFFF 64 MB CS0/CS3
> -----------------------------------------------------------------------
> Anyway, I have seen Table 1. System Memory Address Map and it got EBC
> mapped at 0x1.c000.0000 and another one at 0x1.f000.0000. But I didn't see
> any BCSR info. Correct me if I am wrong, but should it not give me BCSR
> details like:
This is board specific information and not CPU specific. The CPLD with it's
BCSR is a Sequoia thing and can therefor not be listed in the 440EPx manuals.
It it located on the EBC though which is documented in the 440EPx manuals.
So if this chips select which is connected to the CPLD is mapped to
0xc000.0000 which is the case for Sequoia, then you will "find" these
registers at physical address 0x1.c000.0000. And should use ioremap64() to
get the virtual address to access this CPLD.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
---------------------------------
Get easy, one-click access to your favorites. Make Yahoo! your homepage.
[-- Attachment #2: Type: text/html, Size: 2947 bytes --]
^ permalink raw reply
* Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Stefan Roese @ 2007-11-29 6:56 UTC (permalink / raw)
To: Dell Query; +Cc: linuxppc-embedded
In-Reply-To: <772588.56121.qm@web45611.mail.sp1.yahoo.com>
On Thursday 29 November 2007, Dell Query wrote:
> I see. No wonder I couldn't get more information on BCSR. I should contact
> sequoia to get the proper details like the correct addresses.
>
> I already used ioremap64(), remapping 0x1c0002000. I got a hex value for
> the Board ID but could figure out what it means. So I tried the
> USER_LED0/USER_LED1 (base address+0x2), to see if I could turn on/off the
> user LEDS, but still no luck. I think I am accessing the wrong addresses so
> I need to verify it with them.
Why do think you need the offset 0x2000? I just tested on my Sequoia under
U-Boot and "see" the CPLD at address 0xc000.0000:
=> md.b c0000000 20
c0000000: 0f 00 c0 07 00 80 00 80 00 20 00 00 00 00 00 00 ......... ......
c0000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
So you should map not 0x1.c000.2000 but 0x1.c000.0000 under Linux. Please let
me know if this works.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* SCC QMC driver Compilation
From: srikanth krishnakar @ 2007-11-29 7:23 UTC (permalink / raw)
To: Linuxppc-embedded
In-Reply-To: <6213bc560711282312t6e504846hceb81162e63310c9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2841 bytes --]
Hi panto,
Good Day,
I am trying to compile the QMC driver given for 2.4 kernel. but I am getting
the IOCTL errors. Will you please let me know the solution for these.
* Below is the log of Errors generated while compilation:**
*ppc_8xx-gcc -D__KERNEL__ -I/home/TEST_QMC/linux- 2.4.20_mvl31/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-fomit-frame-pointer -I/home/TEST_QMC/linux-
2.4.20_mvl31/arch/ppc-fsigned-char -msoft-float -pipe -ffixed-r2
-Wno-uninitialized -mmultiple
-mstring -nostdinc -iwithprefix include -DKBUILD_BASENAME=qmc_core
-DEXPORT_SYMTAB -c qmc-core.c
qmc-core.c: In function `qmc_ioctl':
qmc-core.c:456: error: `QMC_IOC_MAGIC' undeclared (first use in this
function)
qmc-core.c:456: error: (Each undeclared identifier is reported only once
qmc-core.c:456: error: for each function it appears in.)
qmc-core.c:458: error: `QMC_IOC_MAXNR' undeclared (first use in this
function)
qmc-core.c:466: error: `QMC_IOCRESET' undeclared (first use in this
function)
qmc-core.c:469: error: `QMC_IOCSCONF' undeclared (first use in this
function)
qmc-core.c:470: error: `QMC_IOCGCONF' undeclared (first use in this
function)
qmc-core.c:471: error: storage size of `req' isn't known
qmc-core.c:471: warning: unused variable `req'
qmc-core.c :1012:2: #error Unknown board configuration.
qmc-core.c: In function `qmc_setup':
qmc-core.c:1311: error: `CLK_PCM_BIT' undeclared (first use in this
function)
qmc-core.c:1311: error: `X_PCMOUT1_BIT' undeclared (first use in this
function)
qmc-core.c:1311: error: `X_PCMIN1_BIT' undeclared (first use in this
function)
qmc-core.c:1313: error: `PCM_FS_BIT' undeclared (first use in this function)
qmc-core.c: In function `qmc_cleanup':
qmc-core.c :1640: error: `CLK_PCM_BIT' undeclared (first use in this
function)
qmc-core.c:1640: error: `X_PCMOUT1_BIT' undeclared (first use in this
function)
qmc-core.c:1640: error: `X_PCMIN1_BIT' undeclared (first use in this
function)
qmc-core.c: In function `devices_init':
qmc-core.c:1662: error: `QMC_MAJOR' undeclared (first use in this function)
qmc-core.c: In function `devices_cleanup':
qmc-core.c:1684: error: `QMC_MAJOR' undeclared (first use in this function)
make[3]: *** [qmc-core.o] Error 1
make[3]: Leaving directory `/home/TEST_QMC/linux-2.4.20_mvl31/drivers/qmc'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/home/TEST_QMC/linux-2.4.20_mvl31/drivers/qmc '
make[1]: *** [_subdir_qmc] Error 2
make[1]: Leaving directory `/home/TEST_QMC/linux-2.4.20_mvl31/drivers'
make: *** [_dir_drivers] Error 2
[root@smk linux-2.4.20_mvl31]# vi drivers/qmc/qmc-core.c +456 *
*
Waiting for your reply.
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 3579 bytes --]
^ permalink raw reply
* Re: The question about the high memory support on MPC8360?
From: vijay baskar @ 2007-11-29 7:29 UTC (permalink / raw)
To: 郭劲; +Cc: linuxppc-embedded
In-Reply-To: <396305910.05464@tsinghua.org.cn>
[-- Attachment #1: Type: text/html, Size: 3701 bytes --]
^ permalink raw reply
* [PATCH] PPC: CELLEB - fix possible NULL pointer dereference
From: Ishizaki Kou @ 2007-11-29 7:44 UTC (permalink / raw)
To: paulus; +Cc: gorcunov, olof, linux-kernel, linuxppc-dev
In-Reply-To: <aa79d98a0711282141l6b07569fmb925b198730a554e@mail.gmail.com>
From: Cyrill Gorcunov <gorcunov@gmail.com>
This patch adds checking for NULL returned value to
prevent possible NULL pointer dereference.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
---
Paul,
This is a resend of a patch from Cyrill. I changed it to inline style.
Cyrill,
This works good on Celleb. Thanks.
Best regards,
Kou Ishizaki
arch/powerpc/platforms/celleb/pci.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/pci.c b/arch/powerpc/platforms/celleb/pci.c
index 6bc32fd..13ec4a6 100644
--- a/arch/powerpc/platforms/celleb/pci.c
+++ b/arch/powerpc/platforms/celleb/pci.c
@@ -138,8 +138,6 @@ static void celleb_config_read_fake(unsigned char *config, int where,
*val = celleb_fake_config_readl(p);
break;
}
-
- return;
}
static void celleb_config_write_fake(unsigned char *config, int where,
@@ -158,7 +156,6 @@ static void celleb_config_write_fake(unsigned char *config, int where,
celleb_fake_config_writel(val, p);
break;
}
- return;
}
static int celleb_fake_pci_read_config(struct pci_bus *bus,
@@ -351,6 +348,10 @@ static int __init celleb_setup_fake_pci_device(struct device_node *node,
wi1 = of_get_property(node, "vendor-id", NULL);
wi2 = of_get_property(node, "class-code", NULL);
wi3 = of_get_property(node, "revision-id", NULL);
+ if (!wi0 || !wi1 || !wi2 || !wi3) {
+ printk(KERN_ERR "PCI: Missing device tree properties.\n");
+ goto error;
+ }
celleb_config_write_fake(*config, PCI_DEVICE_ID, 2, wi0[0] & 0xffff);
celleb_config_write_fake(*config, PCI_VENDOR_ID, 2, wi1[0] & 0xffff);
@@ -372,6 +373,10 @@ static int __init celleb_setup_fake_pci_device(struct device_node *node,
celleb_setup_pci_base_addrs(hose, devno, fn, num_base_addr);
li = of_get_property(node, "interrupts", &rlen);
+ if (!li) {
+ printk(KERN_ERR "PCI: interrupts not found.\n");
+ goto error;
+ }
val = li[0];
celleb_config_write_fake(*config, PCI_INTERRUPT_PIN, 1, 1);
celleb_config_write_fake(*config, PCI_INTERRUPT_LINE, 1, val);
^ permalink raw reply related
* Re: [BUG] 2.6.24-rc3-git2 softlockup detected
From: Andrew Morton @ 2007-11-29 8:35 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: linux-scsi, Matthew, Wilcox, LKML, Rafael J. Wysocki,
linuxppc-dev, Andy, Balbir Singh
In-Reply-To: <474E5CAC.9000108@linux.vnet.ibm.com>
On Thu, 29 Nov 2007 12:01:08 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Andrew Morton wrote:
> > On Wed, 28 Nov 2007 12:47:19 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> >
> >> Andrew Morton wrote:
> >>> On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> >>>
> >>>> Hi,
> >>> (cc linux-scsi, for sym53c8xx)
> >>>
> >>>> Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
> >>> I assume this is a post-2.6.23 regression?
> >>>
> >>>> BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375]
> >>>> NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
> >>>> REGS: c00000077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest)
> >>>> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
> >>>> TASK = c00000077cbd8000[375] 'insmod' THREAD: c00000077cbec000 CPU: 1
> >>>> GPR00: d0000000001414fc c00000077cbef330 c00000000052b930 d000080080002014
> >>>> GPR04: d00008008000202c 0000000000000000 c00000077ca1cb00 d00000000014ce54
> >>>> GPR08: c00000077ca1c63c 0000000000000000 000000000000002a c00000000002f018
> >>>> GPR12: d000000000143610 c000000000473d00
> >>>> NIP [c00000000002f02c] .ioread8+0x14/0x60
> >>>> LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
> >>>> Call Trace:
> >>>> [c00000077cbef330] [c00000077cbef3c0] 0xc00000077cbef3c0 (unreliable)
> >>>> [c00000077cbef3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
> >>>> [c00000077cbef470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
> >>>> [c00000077cbef710] [c0000000001bc118] .pci_device_probe+0x124/0x1b0
> >>>> [c00000077cbef7b0] [c000000000221138] .driver_probe_device+0x144/0x20c
> >>>> [c00000077cbef850] [c000000000221450] .__driver_attach+0xcc/0x154
> >>>> [c00000077cbef8e0] [c00000000021ff94] .bus_for_each_dev+0x7c/0xd4
> >>>> [c00000077cbef9a0] [c000000000220e9c] .driver_attach+0x28/0x40
> >>>> [c00000077cbefa20] [c0000000002204d8] .bus_add_driver+0x90/0x228
> >>>> [c00000077cbefac0] [c000000000221858] .driver_register+0x94/0xb0
> >>>> [c00000077cbefb40] [c0000000001bc430] .__pci_register_driver+0x6c/0xcc
> >>>> [c00000077cbefbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
> >>>> [c00000077cbefc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
> >>>> [c00000077cbefe30] [c00000000000872c] syscall_exit+0x0/0x40
> >>>> Instruction dump:
> >>>> 60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
> >>>> f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
> >>> I see no obvious lockup sites near the end of sym_hcb_attach(). Maybe it's
> >>> being called lots of times from a higher level.. Do the traces all look
> >>> the same?
> >> Hi Andrew,
> >>
> >> I see this call trace twice and both looks similar and on another reboot
> >> the following trace is seen twice in different cpu
> >>
> >> BUG: soft lockup detected on CPU#3!
> >> Call Trace:
> >> [C00000003FEDEDA0] [C000000000010220] .show_stack+0x68/0x1b0 (unreliable)
> >> [C00000003FEDEE40] [C0000000000A061C] .softlockup_tick+0xf0/0x13c
> >> [C00000003FEDEEF0] [C000000000072E2C] .run_local_timers+0x1c/0x30
> >> [C00000003FEDEF70] [C000000000022FA0] .timer_interrupt+0xa8/0x488
> >> [C00000003FEDF050] [C0000000000034EC] decrementer_common+0xec/0x100
> >> --- Exception: 901 at .ioread8+0x14/0x60
> >> LR = .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
> >> [C00000003FEDF340] [D0000000002B3BC0] 0xd0000000002b3bc0 (unreliable)
> >> [C00000003FEDF3B0] [D00000000029A3C0] .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
> >> [C00000003FEDF480] [D000000000291D30] .sym2_probe+0x75c/0x9f8 [sym53c8xx]
> >> [C00000003FEDF710] [C0000000001B65A4] .pci_device_probe+0x13c/0x1dc
> >> [C00000003FEDF7D0] [C000000000219A0C] .driver_probe_device+0xa0/0x15c
> >> [C00000003FEDF870] [C000000000219C64] .__driver_attach+0xb4/0x138
> >> [C00000003FEDF900] [C00000000021913C] .bus_for_each_dev+0x7c/0xd4
> >> [C00000003FEDF9C0] [C0000000002198B0] .driver_attach+0x28/0x40
> >> [C00000003FEDFA40] [C000000000218BA4] .bus_add_driver+0x98/0x18c
> >> [C00000003FEDFAE0] [C00000000021A064] .driver_register+0xa8/0xc4
> >> [C00000003FEDFB60] [C0000000001B68AC] .__pci_register_driver+0x5c/0xa4
> >> [C00000003FEDFBF0] [D00000000029C204] .sym2_init+0x104/0x1550 [sym53c8xx]
> >> [C00000003FEDFC90] [C00000000008D1F4] .sys_init_module+0x1764/0x1998
> >> [C00000003FEDFE30] [C00000000000869C] syscall_exit+0x0/0x40
> >>
> >
> > hm, odd.
> >
> > Can you look up sym_hcb_attach+0x1194/0x1384 in gdb? Something like
> >
> Hi Andrew,
>
> I tried with 2.6.24-rc3-git3 and got the following trace
>
> BUG: soft lockup - CPU#2 stuck for 11s! [insmod:375]
> NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
> REGS: c00000077ca3b0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git3-autokern1)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
> TASK = c00000077cc58000[375] 'insmod' THREAD: c00000077ca38000 CPU: 2
> GPR00: d0000000001414fc c00000077ca3b330 c00000000052b880 d000080080002014
> GPR04: d00008008000202c 0000000000000000 c00000077c82eb00 d00000000014ce54
> GPR08: c00000077c82e63c 0000000000000000 000000000000002a c00000000002f018
> GPR12: d000000000143610 c000000000473f80
> NIP [c00000000002f02c] .ioread8+0x14/0x60
> LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
>
> Call Trace:
> [c00000077ca3b330] [c00000077ca3b3c0] 0xc00000077ca3b3c0 (unreliable)
> [c00000077ca3b3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
> [c00000077ca3b470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
> [c00000077ca3b710] [c0000000001bc098] .pci_device_probe+0x124/0x1b0
> [c00000077ca3b7b0] [c0000000002210c4] .driver_probe_device+0x144/0x20c
> [c00000077ca3b850] [c0000000002213dc] .__driver_attach+0xcc/0x154
> [c00000077ca3b8e0] [c00000000021ff20] .bus_for_each_dev+0x7c/0xd4
> [c00000077ca3b9a0] [c000000000220e28] .driver_attach+0x28/0x40
> [c00000077ca3ba20] [c000000000220464] .bus_add_driver+0x90/0x228
> [c00000077ca3bac0] [c0000000002217e4] .driver_register+0x94/0xb0
> [c00000077ca3bb40] [c0000000001bc3b0] .__pci_register_driver+0x6c/0xcc
> [c00000077ca3bbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
> [c00000077ca3bc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
> [c00000077ca3be30] [c00000000000872c] syscall_exit+0x0/0x40
>
> Instruction dump:
> 60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
> f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
>
> The gdb list the following for the above trace
>
> 0xa4fc is in sym_hcb_attach (drivers/scsi/sym53c8xx_2/sym_hipd.c:1041).
> 1036 OUTL_DSP(np, pc);
> 1037 /*
> 1038 * Wait 'til done (with timeout)
> 1039 */
> 1040 for (i=0; i<SYM_SNOOP_TIMEOUT; i++)
> 1041 if (INB(np, nc_istat) & (INTF|SIP|DIP))
> 1042 break;
> 1043 if (i>=SYM_SNOOP_TIMEOUT) {
> 1044 printf ("CACHE TEST FAILED: timeout.\n");
> 1045 return (0x20);
>
doh, I missed that.
#define SYM_SNOOP_TIMEOUT (10000000)
ten million is close enough to infinity for me to assume that we broke the
driver and that's never going to terminate.
otoh, if that's true you should have got the "CACHE TEST FAILED: timeout"
message. Did you? And does the driver actually work OK after this?
If it is indeed expected that a ~10 second stall in there is correct
behaviour then all we need to do is do make that loop a bit smarter (10,000
msleep(1)'s, for example).
^ permalink raw reply
* [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions
From: Kamalesh Babulal @ 2007-11-29 9:00 UTC (permalink / raw)
To: Andrew Morton
Cc: samba-technical, linux-kernel, linuxppc-dev, nfs, Balbir Singh
In-Reply-To: <20071128034140.648383f0.akpm@linux-foundation.org>
Hi Andrew,
While running file system stress on nfs and cifs mounted partitions, the machine
drops to xmon
1:mon> e
cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
lr: c0000000001074d0: .vfs_link+0x204/0x298
sp: c000000080a9fb00
msr: 8000000000009032
dar: 280
dsisr: 40010000
current = 0xc0000000c8e6f670
paca = 0xc000000000512c00
pid = 2848, comm = fsstress
1:mon> t
[c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
[c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
[c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
--- Exception: c00 (System Call) at 000000000ff1bdfc
SP (ffeaed10) is in userspace
1:mon> r
R00 = c0000000001074d0 R16 = 0000000000000000
R01 = c000000080a9fb00 R17 = 0000000000000000
R02 = c00000000060c380 R18 = 0000000000000000
R03 = 0000000000000000 R19 = 0000000000000000
R04 = 0000000000000004 R20 = 0000000000000000
R05 = 0000000000000000 R21 = 0000000000000000
R06 = 0000000000000000 R22 = 0000000000000000
R07 = 0000000000000000 R23 = 0000000000000004
R08 = 0000000000000000 R24 = 0000000000000280
R09 = 0000000000000000 R25 = fffffffffffff000
R10 = 0000000000000001 R26 = c000000082827790
R11 = c0000000003963e8 R27 = c0000000828275a0
R12 = d000000000deec78 R28 = 0000000000000000
R13 = c000000000512c00 R29 = c00000007b18fcf0
R14 = 0000000000000000 R30 = c0000000005bc088
R15 = 0000000000000000 R31 = 0000000000000000
pc = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
lr = c0000000001074d0 .vfs_link+0x204/0x298
msr = 8000000000009032 cr = 24000882
ctr = c0000000003963e8 xer = 0000000000000000 trap = 300
dar = 0000000000000280 dsisr = 40010000
The gdb output shows
0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
103 * fsnotify_create - 'name' was linked in
104 */
105 static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
106 {
107 inode_dir_notify(inode, DN_CREATE);
108 inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
109 dentry->d_inode);
110 audit_inode_child(dentry->d_name.name, dentry, inode);
111 }
112
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions
From: Andrew Morton @ 2007-11-29 9:09 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: Jan Kara, samba-technical, linux-kernel, linuxppc-dev, nfs
In-Reply-To: <474E7F9E.9000601@linux.vnet.ibm.com>
On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi Andrew,
>
> While running file system stress on nfs and cifs mounted partitions, the machine
> drops to xmon
>
> 1:mon> e
> cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
> pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
> lr: c0000000001074d0: .vfs_link+0x204/0x298
> sp: c000000080a9fb00
> msr: 8000000000009032
> dar: 280
> dsisr: 40010000
> current = 0xc0000000c8e6f670
> paca = 0xc000000000512c00
> pid = 2848, comm = fsstress
> 1:mon> t
> [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
> [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
> [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
> --- Exception: c00 (System Call) at 000000000ff1bdfc
> SP (ffeaed10) is in userspace
> 1:mon> r
> R00 = c0000000001074d0 R16 = 0000000000000000
> R01 = c000000080a9fb00 R17 = 0000000000000000
> R02 = c00000000060c380 R18 = 0000000000000000
> R03 = 0000000000000000 R19 = 0000000000000000
> R04 = 0000000000000004 R20 = 0000000000000000
> R05 = 0000000000000000 R21 = 0000000000000000
> R06 = 0000000000000000 R22 = 0000000000000000
> R07 = 0000000000000000 R23 = 0000000000000004
> R08 = 0000000000000000 R24 = 0000000000000280
> R09 = 0000000000000000 R25 = fffffffffffff000
> R10 = 0000000000000001 R26 = c000000082827790
> R11 = c0000000003963e8 R27 = c0000000828275a0
> R12 = d000000000deec78 R28 = 0000000000000000
> R13 = c000000000512c00 R29 = c00000007b18fcf0
> R14 = 0000000000000000 R30 = c0000000005bc088
> R15 = 0000000000000000 R31 = 0000000000000000
> pc = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
> lr = c0000000001074d0 .vfs_link+0x204/0x298
> msr = 8000000000009032 cr = 24000882
> ctr = c0000000003963e8 xer = 0000000000000000 trap = 300
> dar = 0000000000000280 dsisr = 40010000
>
>
> The gdb output shows
>
> 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
> 103 * fsnotify_create - 'name' was linked in
> 104 */
> 105 static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
> 106 {
> 107 inode_dir_notify(inode, DN_CREATE);
> 108 inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
> 109 dentry->d_inode);
> 110 audit_inode_child(dentry->d_name.name, dentry, inode);
> 111 }
> 112
>
If it is reproducible can you please try reverting
inotify-send-in_attrib-events-when-link-count-changes.patch?
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-git2 softlockup detected
From: Kamalesh Babulal @ 2007-11-29 9:13 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-scsi, Matthew Wilcox, LKML, Rafael J. Wysocki, linuxppc-dev,
Balbir Singh
In-Reply-To: <20071129003533.54b4b20e.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Thu, 29 Nov 2007 12:01:08 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
>> Andrew Morton wrote:
>>> On Wed, 28 Nov 2007 12:47:19 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>>>
>>>> Andrew Morton wrote:
>>>>> On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>>>>>
>>>>>> Hi,
>>>>> (cc linux-scsi, for sym53c8xx)
>>>>>
>>>>>> Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
>>>>> I assume this is a post-2.6.23 regression?
>>>>>
>>>>>> BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375]
>>>>>> NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
>>>>>> REGS: c00000077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest)
>>>>>> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
>>>>>> TASK = c00000077cbd8000[375] 'insmod' THREAD: c00000077cbec000 CPU: 1
>>>>>> GPR00: d0000000001414fc c00000077cbef330 c00000000052b930 d000080080002014
>>>>>> GPR04: d00008008000202c 0000000000000000 c00000077ca1cb00 d00000000014ce54
>>>>>> GPR08: c00000077ca1c63c 0000000000000000 000000000000002a c00000000002f018
>>>>>> GPR12: d000000000143610 c000000000473d00
>>>>>> NIP [c00000000002f02c] .ioread8+0x14/0x60
>>>>>> LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
>>>>>> Call Trace:
>>>>>> [c00000077cbef330] [c00000077cbef3c0] 0xc00000077cbef3c0 (unreliable)
>>>>>> [c00000077cbef3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
>>>>>> [c00000077cbef470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
>>>>>> [c00000077cbef710] [c0000000001bc118] .pci_device_probe+0x124/0x1b0
>>>>>> [c00000077cbef7b0] [c000000000221138] .driver_probe_device+0x144/0x20c
>>>>>> [c00000077cbef850] [c000000000221450] .__driver_attach+0xcc/0x154
>>>>>> [c00000077cbef8e0] [c00000000021ff94] .bus_for_each_dev+0x7c/0xd4
>>>>>> [c00000077cbef9a0] [c000000000220e9c] .driver_attach+0x28/0x40
>>>>>> [c00000077cbefa20] [c0000000002204d8] .bus_add_driver+0x90/0x228
>>>>>> [c00000077cbefac0] [c000000000221858] .driver_register+0x94/0xb0
>>>>>> [c00000077cbefb40] [c0000000001bc430] .__pci_register_driver+0x6c/0xcc
>>>>>> [c00000077cbefbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
>>>>>> [c00000077cbefc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
>>>>>> [c00000077cbefe30] [c00000000000872c] syscall_exit+0x0/0x40
>>>>>> Instruction dump:
>>>>>> 60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
>>>>>> f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
>>>>> I see no obvious lockup sites near the end of sym_hcb_attach(). Maybe it's
>>>>> being called lots of times from a higher level.. Do the traces all look
>>>>> the same?
>>>> Hi Andrew,
>>>>
>>>> I see this call trace twice and both looks similar and on another reboot
>>>> the following trace is seen twice in different cpu
>>>>
>>>> BUG: soft lockup detected on CPU#3!
>>>> Call Trace:
>>>> [C00000003FEDEDA0] [C000000000010220] .show_stack+0x68/0x1b0 (unreliable)
>>>> [C00000003FEDEE40] [C0000000000A061C] .softlockup_tick+0xf0/0x13c
>>>> [C00000003FEDEEF0] [C000000000072E2C] .run_local_timers+0x1c/0x30
>>>> [C00000003FEDEF70] [C000000000022FA0] .timer_interrupt+0xa8/0x488
>>>> [C00000003FEDF050] [C0000000000034EC] decrementer_common+0xec/0x100
>>>> --- Exception: 901 at .ioread8+0x14/0x60
>>>> LR = .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
>>>> [C00000003FEDF340] [D0000000002B3BC0] 0xd0000000002b3bc0 (unreliable)
>>>> [C00000003FEDF3B0] [D00000000029A3C0] .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
>>>> [C00000003FEDF480] [D000000000291D30] .sym2_probe+0x75c/0x9f8 [sym53c8xx]
>>>> [C00000003FEDF710] [C0000000001B65A4] .pci_device_probe+0x13c/0x1dc
>>>> [C00000003FEDF7D0] [C000000000219A0C] .driver_probe_device+0xa0/0x15c
>>>> [C00000003FEDF870] [C000000000219C64] .__driver_attach+0xb4/0x138
>>>> [C00000003FEDF900] [C00000000021913C] .bus_for_each_dev+0x7c/0xd4
>>>> [C00000003FEDF9C0] [C0000000002198B0] .driver_attach+0x28/0x40
>>>> [C00000003FEDFA40] [C000000000218BA4] .bus_add_driver+0x98/0x18c
>>>> [C00000003FEDFAE0] [C00000000021A064] .driver_register+0xa8/0xc4
>>>> [C00000003FEDFB60] [C0000000001B68AC] .__pci_register_driver+0x5c/0xa4
>>>> [C00000003FEDFBF0] [D00000000029C204] .sym2_init+0x104/0x1550 [sym53c8xx]
>>>> [C00000003FEDFC90] [C00000000008D1F4] .sys_init_module+0x1764/0x1998
>>>> [C00000003FEDFE30] [C00000000000869C] syscall_exit+0x0/0x40
>>>>
>>> hm, odd.
>>>
>>> Can you look up sym_hcb_attach+0x1194/0x1384 in gdb? Something like
>>>
>> Hi Andrew,
>>
>> I tried with 2.6.24-rc3-git3 and got the following trace
>>
>> BUG: soft lockup - CPU#2 stuck for 11s! [insmod:375]
>> NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
>> REGS: c00000077ca3b0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git3-autokern1)
>> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
>> TASK = c00000077cc58000[375] 'insmod' THREAD: c00000077ca38000 CPU: 2
>> GPR00: d0000000001414fc c00000077ca3b330 c00000000052b880 d000080080002014
>> GPR04: d00008008000202c 0000000000000000 c00000077c82eb00 d00000000014ce54
>> GPR08: c00000077c82e63c 0000000000000000 000000000000002a c00000000002f018
>> GPR12: d000000000143610 c000000000473f80
>> NIP [c00000000002f02c] .ioread8+0x14/0x60
>> LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
>>
>> Call Trace:
>> [c00000077ca3b330] [c00000077ca3b3c0] 0xc00000077ca3b3c0 (unreliable)
>> [c00000077ca3b3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
>> [c00000077ca3b470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
>> [c00000077ca3b710] [c0000000001bc098] .pci_device_probe+0x124/0x1b0
>> [c00000077ca3b7b0] [c0000000002210c4] .driver_probe_device+0x144/0x20c
>> [c00000077ca3b850] [c0000000002213dc] .__driver_attach+0xcc/0x154
>> [c00000077ca3b8e0] [c00000000021ff20] .bus_for_each_dev+0x7c/0xd4
>> [c00000077ca3b9a0] [c000000000220e28] .driver_attach+0x28/0x40
>> [c00000077ca3ba20] [c000000000220464] .bus_add_driver+0x90/0x228
>> [c00000077ca3bac0] [c0000000002217e4] .driver_register+0x94/0xb0
>> [c00000077ca3bb40] [c0000000001bc3b0] .__pci_register_driver+0x6c/0xcc
>> [c00000077ca3bbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
>> [c00000077ca3bc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
>> [c00000077ca3be30] [c00000000000872c] syscall_exit+0x0/0x40
>>
>> Instruction dump:
>> 60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
>> f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
>>
>> The gdb list the following for the above trace
>>
>> 0xa4fc is in sym_hcb_attach (drivers/scsi/sym53c8xx_2/sym_hipd.c:1041).
>> 1036 OUTL_DSP(np, pc);
>> 1037 /*
>> 1038 * Wait 'til done (with timeout)
>> 1039 */
>> 1040 for (i=0; i<SYM_SNOOP_TIMEOUT; i++)
>> 1041 if (INB(np, nc_istat) & (INTF|SIP|DIP))
>> 1042 break;
>> 1043 if (i>=SYM_SNOOP_TIMEOUT) {
>> 1044 printf ("CACHE TEST FAILED: timeout.\n");
>> 1045 return (0x20);
>>
>
> doh, I missed that.
>
> #define SYM_SNOOP_TIMEOUT (10000000)
>
> ten million is close enough to infinity for me to assume that we broke the
> driver and that's never going to terminate.
>
> otoh, if that's true you should have got the "CACHE TEST FAILED: timeout"
> message. Did you? And does the driver actually work OK after this?
Yes, i got that message
CACHE TEST FAILED: timeout.
sym1: CACHE INCORRECTLY CONFIGURED.
sym1: giving up ...
and the file system stress passes.
> If it is indeed expected that a ~10 second stall in there is correct
> behaviour then all we need to do is do make that loop a bit smarter (10,000
> msleep(1)'s, for example).
>
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Dell Query @ 2007-11-29 10:01 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200711290756.32565.sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]
Hi Stefan,
1. I used the 0x1c0002000 offset because I was referring to the first reply that I received. Now, I used the address 0x1c0002000 and tried to read from it. I retrieved 0x0f01c087. May I know what does this mean? How does this data relate to Board ID?
2. Referring back to "Embedded Planet 440xC" document, I tried to activate the USER_LED0/USER_LED1 (with new address 0x1c0000000 + 0x2 offset) by setting it to 0. But didn't see the led turned on. Did some experiments and tried 0x1c0000000 without offset, sent 0, and found that USER_LED0 (CR3) and USER_LED1 (CR4) are activated! This got me confused. May I know why is this so? Could you please refer me to some documents?
Thanks for all the assistance.
Regards,
dell
Stefan Roese <sr@denx.de> wrote: On Thursday 29 November 2007, Dell Query wrote:
> I see. No wonder I couldn't get more information on BCSR. I should contact
> sequoia to get the proper details like the correct addresses.
>
> I already used ioremap64(), remapping 0x1c0002000. I got a hex value for
> the Board ID but could figure out what it means. So I tried the
> USER_LED0/USER_LED1 (base address+0x2), to see if I could turn on/off the
> user LEDS, but still no luck. I think I am accessing the wrong addresses so
> I need to verify it with them.
Why do think you need the offset 0x2000? I just tested on my Sequoia under
U-Boot and "see" the CPLD at address 0xc000.0000:
=> md.b c0000000 20
c0000000: 0f 00 c0 07 00 80 00 80 00 20 00 00 00 00 00 00 ......... ......
c0000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
So you should map not 0x1.c000.2000 but 0x1.c000.0000 under Linux. Please let
me know if this works.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
---------------------------------
Never miss a thing. Make Yahoo your homepage.
[-- Attachment #2: Type: text/html, Size: 2536 bytes --]
^ permalink raw reply
* Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Stefan Roese @ 2007-11-29 10:13 UTC (permalink / raw)
To: Dell Query; +Cc: linuxppc-embedded
In-Reply-To: <539126.37238.qm@web45608.mail.sp1.yahoo.com>
Hi Dell (???),
On Thursday 29 November 2007, Dell Query wrote:
> 1. I used the 0x1c0002000 offset because I was referring to the first reply
> that I received. Now, I used the address 0x1c0002000 and tried to read from
> it. I retrieved 0x0f01c087. May I know what does this mean? How does this
> data relate to Board ID?
Please refer to the document describing the CPLD registers. They are byte
registers and not 32bit lword registers (see below).
> 2. Referring back to "Embedded Planet 440xC" document, I tried to activate
> the USER_LED0/USER_LED1 (with new address 0x1c0000000 + 0x2 offset) by
> setting it to 0. But didn't see the led turned on. Did some experiments and
> tried 0x1c0000000 without offset, sent 0, and found that USER_LED0 (CR3)
> and USER_LED1 (CR4) are activated! This got me confused. May I know why is
> this so? Could you please refer me to some documents?
The address of the CPLD is without this 0x2000 offset as it seems. Maybe the
Sequoia users manual is incorrect here.
Make sure that you address these registers with the correct functions. That is
in_8()/out_8(). Here a log from U-Boot:
=> md.l c0000000 1
c0000000: 0f00c007 ....
=> md.b c0000000 4
c0000000: 0f 00 c0 07 ....
By writing 0x00 to offset 0x02 (LED control) I am able to set the user led's.
This should work in Linux the same way:
=> mw.b c0000002 00
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH] Increase the upper bound on NR_CPUS.
From: Arnd Bergmann @ 2007-11-29 10:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20071129041603.GM24243@bakeyournoodle.com>
On Thursday 29 November 2007, Tony Breeds wrote:
> why not?
In the past I've seen run-time problems because some parts of the
code kmalloc NR_CPUS sized arrays, which can easily grow beyond
the kmalloc limit of 128kb. Have you tried running some tests
on a small machine with the big NR_CPUS?
Arnd <><
^ permalink raw reply
* Re: [PATCH] powerpc: fix os-term usage on kernel panic
From: Olaf Hering @ 2007-11-29 10:41 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Will Schmidt, paulus
In-Reply-To: <20071128200932.GG19584@austin.ibm.com>
On Wed, Nov 28, Linas Vepstas wrote:
> On Wed, Nov 28, 2007 at 12:00:37PM +0100, Olaf Hering wrote:
> > On Tue, Nov 27, Will Schmidt wrote:
> > > > - if (panic_timeout)
> > > > - return;
> >
> > This change is wrong. Booting with panic=123 really means the system
> > has to reboot in 123 seconds after a panic.
>
> And it does.
Have you ever tried it? Current state is that the JS20 hangs after
panic, simply because it calls into the hypervisor (or whatever).
To reproduce:
mkdir ../O-os-term
cp arch/powerpc/configs/pseries_defconfig ../O-os-term/.config
yes '' | make -kj6 O=../O-os-term zImage
scp -4pr ../O-os-term/arch/powerpc/boot/zImage root@tftp:/tftpboot/js20
boot /pci@8000000f8000000/pci@0/ethernet@1,1 debug panic=1 root=/dev/sdx42
Whoever relies on the string passing to the HMC can boot with panic=0 or
use some sysctl to write to /proc/sys/kernel/panic
So, please restore the panic_timeout check.
^ permalink raw reply
* Re: MPC5200 I2C and 2.6 kernel
From: Oliver Rutsch @ 2007-11-29 11:00 UTC (permalink / raw)
To: Linuxppc-dev
In-Reply-To: <20071128202245.90051247C1@gemini.denx.de>
Hi,
>> hwclock --debug tells me:
>
>> hwclock: Open of /dev/rtc failed, errno=19: No such device.
>
> Well... did you check how your /dev/rtc is set up? It used to be a
> misc device with MAJ=10 MIN=135 in old kernel versions, but now it's
> MAJ=254 MIN=4, i. e. it should look like this:
>
> crw-r--r-- 1 root root 254, 0 Jun 22 18:30 /dev/rtc
>
Yes this was not correct in my filesystem. But in your filesystem
it looks like MAJ=254 MIN=0. I set MIN to 0 and applied Jon's
suggestions and now it works! So many thanks to Wolfgang and Jon,
this was really a hard problem for me!
But I should mention that I modified my dts for the M41T00 RTC
in the following way:
rtc@68 {
compatible = "stm,m41t00";
reg = <68>;
};
In some piece of an older driver I found the I2C Address for this RTC
(0x68), although the data sheet tells me that the slave address is 0xD0.
However, now it's up and running!
Thanks and bye,
--
Dipl. Ing. Oliver Rutsch
EMail: orutsch@sympatec.com
^ permalink raw reply
* Re: Xilinx devicetrees
From: David H. Lynch Jr. @ 2007-11-29 10:56 UTC (permalink / raw)
To: John Williams; +Cc: Stephen Neuendorffer, Michal Simek, linuxppc-embedded
In-Reply-To: <474CBBDE.9010007@itee.uq.edu.au>
John Williams wrote:
>
> I'm not sure I agree, here, given that most people building MicroBlaze
> systems are doing so with uClinux-dist (or PetaLinux), you can do a
> full rebuilt, kernel libs apps, in a couple of minutes. Much shorter
> than sythnesis and P&R, that's for sure (and runtime is linear in
> size, unlike P&R :)
I am mostly a lurker in this debate. Pico has V5 cards that we intend to
run MicroBlaze Linux on, but as I would end up with the Linux work and I
have spent most of the past 6 months getting our host software working
under Linux, OpenBSd, and OS X, the time to play with the MicroBlaze
just was not there - but might be soon.
I did take note that Xilinx purportedly has an MMU for the MB now. This
is particularly intriguing.
To cast in my .02 - Pico is likely to either not run the MB on our V5's
or run a fairly bloated one.
uClinux only interests us - because the MB would not run full blown
Linux. Given the possibility that it might, we become less and less
interested, in the smallest MB posible. I know this contradicts many
things I have said about our position on Our PPC Linux, but our clients
who want Linux really want the whole thing. At this moment I do not have
a full appreciation of all the MB instruction options and emulating them
through exception handlers. But my guess is that we would turn
everything on that has any significant impact on linux kernel performance.
I am glad that John mentioned MB/PPC convergence. Particularly with an
MMU it is our hope that our PPC BSP for our V4FX boards ddifferes as
little as possible from our MB BSP for V4/V5 LX boards.
I am not looking to tell someone else how to spend their time - but Pico
would have little interest in dynamically mangling a kernel to adapt to
different CPU parameters. It sounds like alot of work, and alot of
grief. We would design our own CPU first.
>
> My experience tells me that if the microblaze can be configured in a
> particular way, *someone* will want to do it (and still boot linux on
> it!) We still have people building MicroBlaze 3.00 in Spartan2E, with
> EDK 6.3. And autoconfig works! Exceptions on/off, MMU on/off (runtime
> configurable on that?).
I would still venture that with very few exception people are going to
gravitate to the extremes, mostly all off, and mostly all on.
Mostly on would probably run full blown MMU Linux, and mostly off would
either run uClinux or nothing at all. Frankly I am not sure that with
everything mostly off, you wouldn't just pick a much smaller less
powerful core - something 8 or 16 bit that is a fraction of the size,
then the CPU become a logic element, rather than something to run an OS
- I.E. I can build a graphics processor in an FPGA implimenting most
things in hardware, but ploping a cheap (small) CPU in to do general
purpose low performance administrative tasks, that might take more space
in hardware.
Other things that would be higher on my hitlist would be seeing the GCC
MicroBlaze CPU support find its way into distribution GCC's.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-11-29 11:24 UTC (permalink / raw)
To: Alessandro Zummo; +Cc: rtc-linux, linuxppc-embedded
In-Reply-To: <20071128194321.0804b3aa@i1501.lan.towertech.it>
Hello, Allessandro!
Alessandro Zummo schrieb:
> On Wed, 28 Nov 2007 19:25:00 +0100
> Clemens Koller <clemens.koller@anagramm.de> wrote:
>
>> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
>> on my MPC8540(ads like) PowerPC working properly on
>> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
>> as well as a 2.6.22-rc6-gb75ae860 is working fine.
>> (mainstream's console is broken, so cannot test these, yet.)
Just to give you an update: The latest paulus.git as of today
(Linux-2.6.24-rc3-g0b47759d) is still broken. Same story as yesterday.
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: Timers on mpc8248 etc...
From: Vitaly Bordug @ 2007-11-29 11:31 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0711282006o235c987eg80732114e489befd@mail.gmail.com>
On Wed, 28 Nov 2007 21:06:36 -0700
Alan Bennett wrote:
> It comes from uboot. Can you point me in the right direction to make
> sure its right?
> PowerPC,8248@0 {
> device_type = "cpu";
> reg = <0>;
> d-cache-line-size = <d#32>;
> i-cache-line-size = <d#32>;
> d-cache-size = <d#16384>;
> i-cache-size = <d#16384>;
> timebase-frequency = <0>;
> clock-frequency = <0>;
> };
>
if your u-boot is up to date, it will have fdt command, and by
fdt boardsetup
fdt print /
inspect what u-boot did. Of course you should have dtb preloaded to memory and
fdt addr <offset> should be said to let u-boot know where dtb resides.
>
> On 11/28/07, Scott Wood <scottwood@freescale.com> wrote:
> > Alan Bennett wrote:
> > > I've got a routine that needs to delay for X microseconds, this
> > > is a must. The command after schedule_timeout must has to wait
> > > for the HW to complete a task that takes X microseconds.
> > >
> > > I would think that one way to do this is with a simple
> > > schedule_timeout. But in the example below, the time that passes
> > > from run1() to dontrun() is far less than 3.2 msecs. Infact,
> > > sometimes its ~ 800 micros according the a analyzer looking at
> > > points triggered in run1() and donrun(). Could this be a
> > > configuration problem with the timer/interrupt that generates the
> > > jiffies?
> >
> > Are you sure the timebase frequency is set correctly in the device
> > tree?
> >
> > -Scott
> >
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely, Vitaly
^ permalink raw reply
* Re: DS1337 RTC on I2C broken.
From: raul.moreno @ 2007-11-29 11:34 UTC (permalink / raw)
To: Clemens Koller
Cc: linuxppc-embedded-bounces+raul.moreno=telvent.abengoa.com,
Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <474EA159.2040200@anagramm.de>
Hello all,
I am trying to use some devices on i2c protocol, one of them is the DS1=
337
RTC, but I don't know too much about how.
I am using the Linux kernel 2.6.15 and a mpc866 processor. I've seen th=
ere
is a cpm i2c interface for these processors (for a rpx board). However =
the
corresponding code (i2c-algo8xx) doesn't appear in the sources. The
i2c-rpx.c just initializes the ioports, the adapter struct and the isr.=
Maybe I am not understanding the i2c driver right.
I am a bit confused about it. Could you give me some help about how it
works or what should I have to do?
Thanks in advance.
Best regards,
Ra=FAl Moreno
Clemens Koller <clemens.koller@anagramm.de>
Clemens Koller
Enviado por:
linuxppc-embedded-bounces+raul.moreno=3Dtelvent.abengoa.com@ozlabs.org
29/11/2007 12:24
=
Para: Alessandro Zummo <alessandro.zummo@towertech.it> =
=
cc: rtc-linux@googlegroups.com, linuxppc-embedded@ozlabs.org =
=
Asunto: Re: DS1337 RTC on I2C broken. =
=
Hello, Allessandro!
Alessandro Zummo schrieb:
> On Wed, 28 Nov 2007 19:25:00 +0100
> Clemens Koller <clemens.koller@anagramm.de> wrote:
>
>> Well, as already mentioned, I have problems to get my DS1337 RTC on=
I2C
>> on my MPC8540(ads like) PowerPC working properly on
>> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee=
4cc
>> as well as a 2.6.22-rc6-gb75ae860 is working fine.
>> (mainstream's console is broken, so cannot test these, yet.)
Just to give you an update: The latest paulus.git as of today
(Linux-2.6.24-rc3-g0b47759d) is still broken. Same story as yesterday.
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra=DFe 45/1
Linhof Werksgel=E4nde
D-81379 M=FCnchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
=
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions
From: Kamalesh Babulal @ 2007-11-29 11:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: Jan Kara, samba-technical, linux-kernel, linuxppc-dev, nfs
In-Reply-To: <20071129010906.772e0c15.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
>> Hi Andrew,
>>
>> While running file system stress on nfs and cifs mounted partitions, the machine
>> drops to xmon
>>
>> 1:mon> e
>> cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
>> pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
>> lr: c0000000001074d0: .vfs_link+0x204/0x298
>> sp: c000000080a9fb00
>> msr: 8000000000009032
>> dar: 280
>> dsisr: 40010000
>> current = 0xc0000000c8e6f670
>> paca = 0xc000000000512c00
>> pid = 2848, comm = fsstress
>> 1:mon> t
>> [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
>> [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
>> [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
>> --- Exception: c00 (System Call) at 000000000ff1bdfc
>> SP (ffeaed10) is in userspace
>> 1:mon> r
>> R00 = c0000000001074d0 R16 = 0000000000000000
>> R01 = c000000080a9fb00 R17 = 0000000000000000
>> R02 = c00000000060c380 R18 = 0000000000000000
>> R03 = 0000000000000000 R19 = 0000000000000000
>> R04 = 0000000000000004 R20 = 0000000000000000
>> R05 = 0000000000000000 R21 = 0000000000000000
>> R06 = 0000000000000000 R22 = 0000000000000000
>> R07 = 0000000000000000 R23 = 0000000000000004
>> R08 = 0000000000000000 R24 = 0000000000000280
>> R09 = 0000000000000000 R25 = fffffffffffff000
>> R10 = 0000000000000001 R26 = c000000082827790
>> R11 = c0000000003963e8 R27 = c0000000828275a0
>> R12 = d000000000deec78 R28 = 0000000000000000
>> R13 = c000000000512c00 R29 = c00000007b18fcf0
>> R14 = 0000000000000000 R30 = c0000000005bc088
>> R15 = 0000000000000000 R31 = 0000000000000000
>> pc = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
>> lr = c0000000001074d0 .vfs_link+0x204/0x298
>> msr = 8000000000009032 cr = 24000882
>> ctr = c0000000003963e8 xer = 0000000000000000 trap = 300
>> dar = 0000000000000280 dsisr = 40010000
>>
>>
>> The gdb output shows
>>
>> 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
>> 103 * fsnotify_create - 'name' was linked in
>> 104 */
>> 105 static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
>> 106 {
>> 107 inode_dir_notify(inode, DN_CREATE);
>> 108 inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
>> 109 dentry->d_inode);
>> 110 audit_inode_child(dentry->d_name.name, dentry, inode);
>> 111 }
>> 112
>>
>
> If it is reproducible can you please try reverting
> inotify-send-in_attrib-events-when-link-count-changes.patch?
Hi Andrew,
reverting the patch inotify-send-in_attrib-events-when-link-count-changes.patch, the
bug is not reproduced.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions
From: Jan Kara @ 2007-11-29 12:10 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: samba-technical, linux-kernel, linuxppc-dev, nfs, Andrew Morton
In-Reply-To: <474EA914.1060502@linux.vnet.ibm.com>
On Thu 29-11-07 17:27:08, Kamalesh Babulal wrote:
> Andrew Morton wrote:
> > On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> >
> >> Hi Andrew,
> >>
> >> While running file system stress on nfs and cifs mounted partitions, the machine
> >> drops to xmon
> >>
> >> 1:mon> e
> >> cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
> >> pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
> >> lr: c0000000001074d0: .vfs_link+0x204/0x298
> >> sp: c000000080a9fb00
> >> msr: 8000000000009032
> >> dar: 280
> >> dsisr: 40010000
> >> current = 0xc0000000c8e6f670
> >> paca = 0xc000000000512c00
> >> pid = 2848, comm = fsstress
> >> 1:mon> t
> >> [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
> >> [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
> >> [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
> >> --- Exception: c00 (System Call) at 000000000ff1bdfc
> >> SP (ffeaed10) is in userspace
> >> 1:mon> r
> >> R00 = c0000000001074d0 R16 = 0000000000000000
> >> R01 = c000000080a9fb00 R17 = 0000000000000000
> >> R02 = c00000000060c380 R18 = 0000000000000000
> >> R03 = 0000000000000000 R19 = 0000000000000000
> >> R04 = 0000000000000004 R20 = 0000000000000000
> >> R05 = 0000000000000000 R21 = 0000000000000000
> >> R06 = 0000000000000000 R22 = 0000000000000000
> >> R07 = 0000000000000000 R23 = 0000000000000004
> >> R08 = 0000000000000000 R24 = 0000000000000280
> >> R09 = 0000000000000000 R25 = fffffffffffff000
> >> R10 = 0000000000000001 R26 = c000000082827790
> >> R11 = c0000000003963e8 R27 = c0000000828275a0
> >> R12 = d000000000deec78 R28 = 0000000000000000
> >> R13 = c000000000512c00 R29 = c00000007b18fcf0
> >> R14 = 0000000000000000 R30 = c0000000005bc088
> >> R15 = 0000000000000000 R31 = 0000000000000000
> >> pc = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
> >> lr = c0000000001074d0 .vfs_link+0x204/0x298
> >> msr = 8000000000009032 cr = 24000882
> >> ctr = c0000000003963e8 xer = 0000000000000000 trap = 300
> >> dar = 0000000000000280 dsisr = 40010000
> >>
> >>
> >> The gdb output shows
> >>
> >> 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
> >> 103 * fsnotify_create - 'name' was linked in
> >> 104 */
> >> 105 static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
> >> 106 {
> >> 107 inode_dir_notify(inode, DN_CREATE);
> >> 108 inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
> >> 109 dentry->d_inode);
> >> 110 audit_inode_child(dentry->d_name.name, dentry, inode);
> >> 111 }
> >> 112
> >>
> >
> > If it is reproducible can you please try reverting
> > inotify-send-in_attrib-events-when-link-count-changes.patch?
>
> Hi Andrew,
>
> reverting the patch inotify-send-in_attrib-events-when-link-count-changes.patch, the
> bug is not reproduced.
OK, thanks for testing. I was trying to reproduce the problem locally but
without success so far - I guess it's either NFS or CIFS which makes the
problem appear. I'll investigate more.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox