[Prism54-devel] patch against null pointers in islpci_mgt.c

Denis Vlasenko vda at port.imtp.ilyichevsk.odessa.ua
Wed Mar 9 11:48:30 UTC 2005


> > > now another error remains:
> > >
> > >  frame = kmalloc(sizeof (struct islpci_mgmtframe) + size,
> > >     GFP_ATOMIC);
> > >
> > > in islpci_mgt.c line 410 always fails, resulting in the following error
> > > messages:
> > >
> > > root at mtx-1:~# ifconfig eth1 up
> > > remove_proc_entry: 00:00.0/loading busy, count=1
> > > remove_proc_entry: firmware/00:00.0 busy, count=1
> > > de_put: deferred delete of loading
> > > de_put: deferred delete of 00:00.0
> > > eth1: Out of memory, cannot handle oid 0x00000010
> > > eth1: timeout waiting for mgmt response
> > > eth1: mgt_commit_list: failure. oid=19000004 err=-145
> > > eth1: Out of memory, cannot handle oid 0x04000012
> > > eth1: timeout waiting for mgmt response
> > > eth1: mgt_commit_list: failure. oid=12000003 err=-145
> > > eth1: interface reset failure
> > > prism54: Your card/socket may be faulty, or IRQ line too busy :(
> > > SIOCSIFFLAGS: Connection timed out
> > >
> > > i don't know what to do against that one. any ideas?
> >
> > Interesting. Add 'printk("size=%d\n", size)' there, right above
> > kmalloc. What does it say?
> 
> the funny thing is: it works when i put the printf line here! if i comment it 
> out again, compile and reload the driver i get the errors. the same with 
> debugging output: if debugging is enabled it works, otherwise not. it sounds 
> strange, yes, but the printk calls somehow seem to change the available 
> memory for kmalloc. 
[snip]
> i might have to add that the system configuration is somewhat unusual: its a 
> MIPS platform with a 2.4.27 kernel and it runs with non-cache-coherent IO 
> memory (CONFIG_NONCOHERENT_IO=y). the prism54 driver runs o.k. (although not 
> 100% stable) with coherent IO memory enabled, but i can't use this option for 
> some other reason.
> 
> how could this be solved? allocating the memory in advance? or using a work 
> queue, where kmalloc may sleep?

Have no idea. We need to determine WHY does printk help first.
Go to kernel/printk.c, find printk() definition, and duplicate it
(say, make printk_bruno() :). Use it instead of printk.

Then start commenting out portions of it until you find out
which one is responsible.

Rather silly method, I have to confess :]
--
vda



except for




More information about the Prism54-devel mailing list