[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