[Nut-upsuser] Kernel crash when using usbhid-ups driver.

[Rod Roark]

On 07/01/2013 06:41 PM, Charles Lepple wrote:
> On Jul 1, 2013, at 12:00 AM, Rod Roark wrote:
>
>> Jun 30 10:29:24 ns1 kernel: [90099.128500] RIP: 0010:[<ffffffff811740db>] 
>> [<ffffffff811740db>] __kmalloc+0x7b/0x1a0
> The reference to kmalloc makes me think "memory corruption". I'd report this to Ubuntu as a kernel bug to see if this is an issue specific to that kernel version, but it might also be worth running a memory test.
>
> There is a slim chance that we are triggering some sort of kernel logic bug. (The usbhid-ups driver is making the same requests, over and over, and nothing intentionally has a period of 1-3 days.) The kernel should return an error to the ioctl() syscall if it's a userspace programming bug.

Thanks.  My first thought was hardware error, and so already did memory
testing (everything passed) as well as swapping out both memory sticks
and even lowering the DRAM refresh rate and some other BIOS tweaks.  No
difference.  Then I remembered that all ran fine for a week before I
installed nut, and after that there were 6 crashes in 10 days.  So
removed nut and it's been good since, though will have more certainty
about that over time.

I don't know what privilege level this stuff runs at, but if none of it
is ring 0 then in theory the kernel should not crash, right?  In that
case it's got to be a kernel bug that's being exposed, but I don't think
they'd act without more info or at least better reproducability.

I expect the 1-3 days just comes from the probability of crashing in
some period of time.  As another point of interest, the crashes have all
happened when the server was relatively idle, so UPS polling is
(relatively speaking) a significant part of what little is going on.

Anyway, just sharing what I can because it seemed important.  Seems
likely a kernel bug, but my solution for now is not using nut.  I'll
chime in again if any new info comes to light.

Rod