Len Brown wrote:We're not talking about "a" additional line. In my case [1] we're talking about 22 (!) additional identical lines. Not fixing this before 2.6.24 seems completely inconsistent: - either this is a real bug and the ERR level message is correct, in which case the limits should be increased; - or hitting the limits is harmless and the message should be changed to DEBUG level. It is great to hear that the memory allocation will become dynamic in the future and maybe that could just justify your standpoint, but having the messages is damn ugly and alarming from a user point of view. Please keep in mind that depending on distro release schedules, 2.6.24 could live for quite a bit longer than just the period needed to release 2.6.25 (if that is when the dynamic allocation will be implemented). Cheers, FJP [1] http://lkml.org/lkml/2008/1/6/279 --
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| David Woodhouse | [PATCHv2 00/28] Allow built-in firmware to be accessed by request_firmware() |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Mike Travis | [RFC 00/15] x86_64: Optimize percpu accesses |
git: | |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
| David Miller | [GIT]: Networking |
