LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [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

* Re: Init hangs on Xilinx4
From: David H. Lynch Jr. @ 2007-11-29 12:41 UTC (permalink / raw)
  To: schardt; +Cc: Linux PPC Linux PPC
In-Reply-To: <474D8839.6020609@fz-juelich.de>

I had a similar problem. In my instance it turned out that I was
inadvertently using the physical address of my uart as the output address.
This worked during boot becasue there was a 1:1 physical-logical entry
stuffed into the MMU. But since Linux did nto know about it, as soon as
the VM system decided to use that TLB entry IO died - right in the
middle of a string.

While it is unlikely you made exactly the same mistake. One area you can
check is memory.

What is your output device ?

schardt wrote:
> Hi all,
>
> i still have some problems booting linux from flash and don't know how
> to debug.
>
> i have a xilinx4-ppc with 64MB Ram and 4MB Flash, U-Boot works fine,
> kernel is booting, but my little hello world program runs as init, died
> after printing "He" (intead of "Hello World"). i tried initramfs with
> build in cpio-image and jffs2 rootfs
>
> Is there a log-buffer to look at ?
> Should i try another compiler version ? (btw. booting from systemace
> works with the version i use).
>
> ---------------------------
> famous last words :
>
> [   50.476641] VFS: Mounted root (jffs2 filesystem).
> [   50.533581] Freeing unused kernel memory: 68k init
> He
> ---------------------------
>
>
> regards
> Georg
>
>
>
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> Forschungszentrum Jülich GmbH
> 52425 Jülich
>
> Sitz der Gesellschaft: Jülich
> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
> Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
> Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
> Dr. Ulrich Krafft (stellv. Vorsitzender), Dr. Sebastian M. Schmidt
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>   


-- 
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 12:43 UTC (permalink / raw)
  To: raul.moreno
  Cc: linuxppc-embedded-bounces+raul.moreno=telvent.abengoa.com,
	Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <OF72889778.967E4ED4-ONC12573A2.003EEB4F-C12573A2.003F93BA@abengoa.com>

Hello, Raul!

raul.moreno@telvent.abengoa.com schrieb:
 > I am trying to use some devices on i2c protocol, one of them is the DS1337
 > RTC, but I don't know too much about how.
 > I am using the Linux kernel 2.6.15 and a mpc866 processor.

I don't remember too much about these old kernels.
And, please notice, that
- I am on an mpc8540 which is quite different from your mpc866 processor.
- I am on the latest kernels which are also very different from the old
ones regarding the RTC subsystem.

Usually you have to configure the kernel using the right i2c interface
for your processor (if supported). I am using the 'fsl-i2c' driver
enabled by: I2C-support -> I2C Hardware Bus support -> MPC107/824x/85xx/52xx/86xx
which will be:
CONFIG_I2C_MPC=y

Then, you might have to enable the (now deprecated)
Misc I2C Chip Support -> Dallas DS1337 and ... Real Time Clock support
which gives you:
CONFIG_SENSORS_DS1337=y

 > I've seen there
 > is a cpm i2c interface for these processors (for a rpx board).

the fsl-i2c might be the right place

 > 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?

I would suggest - despite the current problems - to use a current
kernel and check your mileage there.
I don't want to ride dead horses anymore.

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: Init hangs on Xilinx4
From: schardt @ 2007-11-29 12:53 UTC (permalink / raw)
  To: David H. Lynch Jr.; +Cc: Linux PPC Linux PPC
In-Reply-To: <474EB36D.1080408@dlasys.net>


David H. Lynch Jr. wrote:
> I had a similar problem. In my instance it turned out that I was
> inadvertently using the physical address of my uart as the output address.
> This worked during boot becasue there was a 1:1 physical-logical entry
> stuffed into the MMU. But since Linux did nto know about it, as soon as
> the VM system decided to use that TLB entry IO died - right in the
> middle of a string.
>
> While it is unlikely you made exactly the same mistake. One area you can
> check is memory.
>
> What is your output device ?
>
>   
My Output Device is a Xilinx UartLite at 0x40600000 and the kernel
detects this
as /dev/ttyUL0.

Georg







-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich

Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------

^ permalink raw reply

* Re: The question about the high memory support on MPC8360?
From: robert lazarski @ 2007-11-29 12:59 UTC (permalink / raw)
  Cc: linuxppc-embedded
In-Reply-To: <474E6A58.2070200@gdatech.co.in>

On Nov 29, 2007 2:29 AM, vijay baskar <cn.vijaibaskar@gdatech.co.in> wrote:
>
>  How to make the linux find the total 2GB memory?
>
>
>         Hi Friend,
>
>  I hope u had tracked the conversion that has been going on. The max mem
> that the kernel can show is only 768 MB because only that of memory is
> directly mapped with your ram.. No matter how much ram > 768 MB (in
> powerpc.. it varies in other architectures) u have, the kernel will show
> only 768 MB.. This is called low mem..
>
>  How t o use high mem??
>
>  scott can probably guide us on this.. I also have lot of confusions about
> high mem.. Also i would suggest you a bit of reading on virtual memory
> management on linux to get a grasp about how things are done
>  Rest for scott
>
>  regards,
>  vijai
>

I also have a requirement to use more than 768MB and 0x30000000. I
have other problems at the moment, so I haven't tested this completely
yet. My limited understanding, though, is that to use more than 768MB
you have to change your kernel configuration, including shifting the
kernel start address. This is what I plan on testing for 1GB when I
have time:

CONFIG_ADVANCED_OPTIONS=y
CONFIG_LOWMEM_SIZE_BOOL=y
CONFIG_LOWMEM_SIZE=0x40000000
CONFIG_KERNEL_START_BOOL=y
CONFIG_KERNEL_START=0xa0000000
# CONFIG_CONSISTENT_START_BOOL is not set
# CONFIG_CONSISTENT_SIZE_BOOL is not set
# CONFIG_BOOT_LOAD_BOOL is not set

If that works for current kernels, please respond to the list ;-) .

HTH,
Robert

^ permalink raw reply

* Re: Timers on mpc8248 etc...
From: Alan Bennett @ 2007-11-29 13:50 UTC (permalink / raw)
  To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20071129143159.2538786d@kernel.crashing.org>

My uboot is new-ish, but I don't have the fdt commands?  U-Boot 1.3.0
g992742a5-dirty

u-boot:clock configuration
===========================
MPC8248 Clock Configuration
 - Bus-to-Core Mult 3.5x, VCO Div 2, 60x Bus Freq  30-85 , Core Freq 100-300
 - dfbrg 1, corecnf 0x1e, busdf 3, cpmdf 1, plldf 0, pllmf 5, pcidf 5
 - vco_out  396000000, scc_clk   99000000, brg_clk   24750000
 - cpu_clk  231000000, cpm_clk  198000000, bus_clk   66000000

Boot Wrapper Reporting
===========================
Memory <- <0x0 0x8000000> (128MB)
CPU clock-frequency <- 0xdc4c7c0 (231MHz)
CPU timebase-frequency <- 0xfbc520 (17MHz)
CPU bus-frequency <- 0x3ef1480 (66MHz)

Kernel reporting
===========================
clocksource: timebase mult[f26c9b2] shift[22] registered

device tree in kernel (hex= `od -x`:
===========================
/proc/device-tree/cpus/PowerPC,8248@0/name
    PowerPC,8248
/proc/device-tree/cpus/PowerPC,8248@0/bus-frequency
    0000000 03ef 1480
/proc/device-tree/cpus/PowerPC,8248@0/clock-frequency
    0000000 0dc4 c7c0
/proc/device-tree/cpus/PowerPC,8248@0/timebase-frequency
    0000000 00fb c520
/proc/device-tree/cpus/PowerPC,8248@0/i-cache-size
    0000000 0000 4000



On 11/29/07, Vitaly Bordug <vitb@kernel.crashing.org> wrote:
> 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: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions
From: Kamalesh Babulal @ 2007-11-29 14:36 UTC (permalink / raw)
  To: Jan Kara; +Cc: samba-technical, linux-kernel, linuxppc-dev, nfs, Andrew Morton
In-Reply-To: <20071129121001.GD16558@duck.suse.cz>

Jan Kara wrote:
> 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

Hi Jan,

I was running file system stress parallely on NFS and CIFS mounted partitions.
  

-- 
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 14:40 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, it's a problem with CIFS. Its cifs_hardlink() function doesn't call
d_instantiate() and thus returns a dentry with d_inode set to NULL. I'm not
sure if such behavior is really correct but anyway, attached is a new
version of the patch which should handle it gracefully. Kamalesh, can you
please give it a try? Thanks.

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR
---

  Currently, no notification event has been sent when inode's link count
changed. This is inconvenient for the application in some cases:
  Suppose you have the following directory structure
    foo/test
    bar/

  and you watch test. If someone does "mv foo/test bar/", you get event
IN_MOVE_SELF and you know something has happened with the file "test".
However if someone does "ln foo/test bar/test" and "rm foo/test" you get no
inotify event for the file "test" (only directories "foo" and "bar" receive
events).
  Furthermore it could be argued that link count belongs to file's metadata
and thus IN_ATTRIB should be sent when it changes.
  The following patch implements sending of IN_ATTRIB inotify events when
link count of the inode changes, i.e., when a hardlink to the inode is
created or when it is removed. This event is sent in addition to all the
events sent so far. In particular, when a last link to a file is removed,
IN_ATTRIB event is sent in addition to IN_DELETE_SELF event.

Signed-off-by: Jan Kara <jack@suse.cz>

diff --git a/fs/namei.c b/fs/namei.c
index 3b993db..c1839d1 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2188,6 +2188,7 @@ int vfs_unlink(struct inode *dir, struct dentry *dentry)
 
 	/* We don't d_delete() NFS sillyrenamed files--they still exist. */
 	if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) {
+		fsnotify_link_count(dentry->d_inode);
 		d_delete(dentry);
 	}
 
@@ -2360,7 +2361,7 @@ int vfs_link(struct dentry *old_dentry, struct inode *dir, struct dentry *new_de
 	error = dir->i_op->link(old_dentry, dir, new_dentry);
 	mutex_unlock(&old_dentry->d_inode->i_mutex);
 	if (!error)
-		fsnotify_create(dir, new_dentry);
+		fsnotify_link(dir, old_dentry->d_inode, new_dentry);
 	return error;
 }
 
diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
index 2bd31fa..d4b7c4a 100644
--- a/include/linux/fsnotify.h
+++ b/include/linux/fsnotify.h
@@ -92,6 +92,14 @@ static inline void fsnotify_inoderemove(struct inode *inode)
 }
 
 /*
+ * fsnotify_link_count - inode's link count changed
+ */
+static inline void fsnotify_link_count(struct inode *inode)
+{
+	inotify_inode_queue_event(inode, IN_ATTRIB, 0, NULL, NULL);
+}
+
+/*
  * fsnotify_create - 'name' was linked in
  */
 static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
@@ -103,6 +111,20 @@ static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
 }
 
 /*
+ * fsnotify_link - new hardlink in 'inode' directory
+ * Note: We have to pass also the linked inode ptr as some filesystems leave
+ *   new_dentry->d_inode NULL and instantiate inode pointer later
+ */
+static inline void fsnotify_link(struct inode *dir, struct inode *inode, struct dentry *new_dentry)
+{
+	inode_dir_notify(dir, DN_CREATE);
+	inotify_inode_queue_event(dir, IN_CREATE, 0, new_dentry->d_name.name,
+				  inode);
+	fsnotify_link_count(inode);
+	audit_inode_child(new_dentry->d_name.name, new_dentry, dir);
+}
+
+/*
  * fsnotify_mkdir - directory 'name' was created
  */
 static inline void fsnotify_mkdir(struct inode *inode, struct dentry *dentry)

^ permalink raw reply related

* [PATCH 0/5] PowerPC 74xx: Add Emerson Katana Qp support
From: Andrei Dolnikov @ 2007-11-29 15:07 UTC (permalink / raw)
  To: linuxppc-dev

Hello folks,

The following patch sequence is Emerson KatanaQp board support reworked after initial review/discussion.
The patches are incremental to minor mv64x60 code fixups sent by
Mark A. Greer on 11/08/07.

Let me know if you think that some updates/changes needed.


As for Vitaly's and Arnd's questions:

Vitaly Bordug wrote:
>> +		clock-frequency = <7f28155>;		/*
>> 133.333333 MHz */
>This should be updated somewhere in fw or bootwrapper.. Or is it hardcoded
>value that is not going to change?
Yep, it is :)

About cfi-flash: I leave this code as is, according to Benjamin comment.

Thanks,
Andrei.

^ permalink raw reply

* Re: Problems booting a 64k page kernel
From: aglitke @ 2007-11-29 15:12 UTC (permalink / raw)
  To: michael; +Cc: Linux/PPC Development
In-Reply-To: <1196293142.7875.1.camel@concordia>

Michael, thanks for your reply...

I am seeing the segmentation fault both on the default SLES10 initrd and
the default RHEL5.1 initrd.  Therefore, I am reasonably sure this is a
problem with my kernel build and not the initrd itself.

On Thu, 2007-11-29 at 10:39 +1100, Michael Ellerman wrote:
> On Wed, 2007-11-28 at 16:50 -0600, aglitke wrote:
> > Hello all.  I am new to building 64k page kernels and can't seem to get
> > one to boot correctly.  Everything looks okay until init gets a signal
> > 11 while booting.  Attached is my boot log and the kernel config I used.
> > To generate this config I merely enabled the 64k page option in make
> > menuconfig to alter a previously working config.
> > 
> > Any help you can provide would be greatly appreciated.
> 
> I've seen that happen with an init linked with uClibc, its dynamic
> loader was doing mmap with MAP_FIXED on non-64K aligned addresses.
> What user space are you using?
> 
> cheers
> 
-- 
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox