Arnaud Quette
2007-Sep-07 20:16 UTC
[Nut-upsuser] Bug#439055: hid driver tries to mmap huge area, fails
tags 439055 upstream thanks Hi Joey, interesting setup! Do you use it (the arm) to monitor the UPS and send notifications... I've sadly not much time to investigate, but have you tested the latest trunk? also, you mention that it was working before: which nut version? what has changed since? 2007/8/21, Joey Hess <joeyh at debian.org>:> Package: nut > Version: 2.0.5-3+b1 > Severity: normal > > root at slug:/home/joey>/sbin/upsdrvctl start > Network UPS Tools - UPS driver controller 2.0.5 > Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.0.5) > > Detected a UPS: American Power Conversion/Back-UPS BR 800 FW:9.o2 .D USB FW:o2 > Using subdriver: APC/CyberPower HID 0.9 > Unable to enter background: Cannot allocate memory > Driver failed to start (exit status=1) > > slug is a nslu2, an arm machine. While it has only 32 mb ram, it has run > nut recently with no problem, and has a reasonable amount of free memory > and swap. I stopped many daemons, and the problem persisted. > > I tried stracing /lib/nut/newhidups: > > write(2, "Path: UPS.Battery.ff86001b, Type"..., 59) = 59 > write(2, "entering path_to_string()\n", 26) = 26 > write(2, "Looking up 00840004\n", 20) = 20 > write(2, "Looking up 00840012\n", 20) = 20 > write(2, "Looking up ff860016\n", 20) = 20 > write(2, "entering string_to_path()\n", 26) = 26 > write(2, "parsing UPS\n", 12) = 12 > write(2, "Looking up UPS\n", 15) = 15 > write(2, "hid_lookup_usage: found 840004\n", 31) = 31 > write(2, "parsing Battery\n", 16) = 16 > write(2, "Looking up Battery\n", 19) = 19 > write(2, "hid_lookup_usage: found 840012\n", 31) = 31 > write(2, "parsing APCBattReplaceDate\n", 27) = 27 > write(2, "Looking up APCBattReplaceDate\n", 30) = 30 > write(2, "hid_lookup_usage: found ff860016"..., 33) = 33 > write(2, "Path depth = 3\n", 15) = 15 > write(2, "0: Usage(00840004)\n", 19) = 19 > write(2, "1: Usage(00840012)\n", 19) = 19 > write(2, "2: Usage(ff860016)\n", 19) = 19 > mmap2(NULL, 822218752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) > brk(0x31078000) = 0x46000 > mmap2(NULL, 822349824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) > mmap2(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xa221a000 > munmap(0xa221a000, 942080) = 0 > munmap(0xa2400000, 106496) = 0 > mprotect(0xa2300000, 135168, PROT_READ|PROT_WRITE) = 0 > mmap2(NULL, 822218752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) > write(2, "Can\'t retrieve Report 69 (12): C"..., 54) = 54 > > These mmaps are suspicious. 822218752 bytes is 784 megabytes. I have > attached the whole strace. I also have this problem with nut 2.2.0, > using the usbhid-ups driver, strace looks the same. The strace using > version 2.0.4-4 shows much more sane looking mmaps: > > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4 > mmap2(NULL, 22877, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40157000 > > -- System Information: > Debian Release: lenny/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') > Architecture: arm > > Kernel: Linux slug 2.6.21-2-ixp4xx #1 Wed Jun 27 00:51:53 UTC 2007 armv5tel GNU/Linux > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash >cheers, Arnaud -- Free Software Developer - http://arnaud.quette.free.fr/ Debian Developer - http://people.debian.org/~aquette/ Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Ubuntu Media Center (UMC) Project Leader - https://launchpad.net/~umc-team
Joey Hess
2007-Sep-07 20:50 UTC
[Nut-upsuser] Bug#439055: hid driver tries to mmap huge area, fails
Arnaud Quette wrote:> interesting setup! Do you use it (the arm) to monitor the UPS and send > notifications...Yes.> I've sadly not much time to investigate, but have you tested the latest trunk?No. Is it packaged?> also, you mention that it was working before: which nut version? what > has changed since?I think I was using 2.0.4 sucessfully before. -- see shy jo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20070907/b7250f7a/attachment.pgp
Arjen de Korte
2007-Sep-08 08:47 UTC
[Nut-upsuser] Bug#439055: hid driver tries to mmap huge area, fails
>> I tried stracing /lib/nut/newhidups: >> >> write(2, "Path: UPS.Battery.ff86001b, Type"..., 59) = 59 >> write(2, "entering path_to_string()\n", 26) = 26 >> write(2, "Looking up 00840004\n", 20) = 20 >> write(2, "Looking up 00840012\n", 20) = 20 >> write(2, "Looking up ff860016\n", 20) = 20 >> write(2, "entering string_to_path()\n", 26) = 26 >> write(2, "parsing UPS\n", 12) = 12 >> write(2, "Looking up UPS\n", 15) = 15 >> write(2, "hid_lookup_usage: found 840004\n", 31) = 31 >> write(2, "parsing Battery\n", 16) = 16 >> write(2, "Looking up Battery\n", 19) = 19 >> write(2, "hid_lookup_usage: found 840012\n", 31) = 31 >> write(2, "parsing APCBattReplaceDate\n", 27) = 27 >> write(2, "Looking up APCBattReplaceDate\n", 30) = 30 >> write(2, "hid_lookup_usage: found ff860016"..., 33) = 33 >> write(2, "Path depth = 3\n", 15) = 15 >> write(2, "0: Usage(00840004)\n", 19) = 19 >> write(2, "1: Usage(00840012)\n", 19) = 19 >> write(2, "2: Usage(ff860016)\n", 19) = 19 >> mmap2(NULL, 822218752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) >> brk(0x31078000) = 0x46000 >> mmap2(NULL, 822349824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) >> mmap2(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xa221a000 >> munmap(0xa221a000, 942080) = 0 >> munmap(0xa2400000, 106496) = 0 >> mprotect(0xa2300000, 135168, PROT_READ|PROT_WRITE) = 0 >> mmap2(NULL, 822218752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) >> write(2, "Can\'t retrieve Report 69 (12): C"..., 54) = 54It looks like it fails while attempting to read a variable from the UPS (it would be better though to run the driver in debug mode though, mmap should only be used as a last resort).>> These mmaps are suspicious. 822218752 bytes is 784 megabytes. I have >> attached the whole strace. I also have this problem with nut 2.2.0, >> using the usbhid-ups driver, strace looks the same. The strace using >> version 2.0.4-4 shows much more sane looking mmaps: >> >> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4 >> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4 >> mmap2(NULL, 22877, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40157000That may just be a coincidence. We had a problem with uninitialized storage space in the hidparser, which caused the size of expected replies from the UPS to be calculated wrong for report ids 64-255. Since the driver will attempt to allocate the length of the expected reply *before* reading it, this may case this problem. This bug has been in the newhidups driver from day 1, so this is not something that was introduced after nut-2.0.4. It has been fixed in SVN version 1079 though, so could you try out the development version from the trunk? Best regards, Arjen