>> 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
It 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) = 0x40157000 That 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
