similar to: newhidups and APC Back-UPS CS 350

Hi all, I've recently upgraded a system from CentOS 4.4 to CentOS5, and now when the system boots, the r8169 ethernet card doesn't come up. After the boot sequence, if I type "ifup eth1 | ifup eth1.10 | ifup eth1.203" then the adapter starts up ok. It seems to be something with the boot sequence it loads the ethernet adapters a different way around (ie 4.4 eth0 is now

Me again. The ASUS P5N32-SLI motherboard in my new machine has dual NICs but CentOS has only detected one of them. I've tried rebooting with the network plugged in only to the second one, but kudzu still doesn't find it. Any suggestions?

I have a bug report in (0002288) on an install failure on my decTOPs (Centos 4.5 installed on them). I have tried a lot of combinations and it is getting tiring. What what happen, or rather how do I get the following to work: Put my HD into a computer (Compaq SSF that I have installed Centos 5 on with no trouble), install Centos 5, move the HD to the decTOP. Different Video card. No PS/2

Thomas, The none (-22) message in your log is an errno from the libusb_get_interrupt() call in HIDGetEvents() in libhid.c. It indicates an invalid ioctl type. In HIDGetEvents() there is a comment with that call: /* needs libusb-0.1.8 to work => use ifdef and autoconf */ You may want to make sure your libusb is up-to-date. Hope this helps, AG --

I've go a Compaq Presario (SR5110NX) that I've loaded CentOS 5 on and all is well except for the sound card. I understand that OSS supports the chipset but it's not being detected an loaded properly and I've invested a significant amount of time already. I've probably got an old supported card lying around here somewhere but I hat to give up on the principal. I would rather

Hi all, I am having problems to get the SeaLevel IO card to work with CentOS distro. Basically the card is being recognised and shown by lspci BUT /proc/devices file is not updated with the new devices does anyone know why. ? Could someone tell me what/where infos are needed to get /proc/devices to be updated. The reason I require the /proc/devices infos is because I want to run a mknod

Peter, You may want to have a look at the comments to Bug 164524 at bugzilla@redhat.com: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164524 I filed this a long while ago, because of the mess we get into when shutting down Linux via /etc/rc.d/init.d/halt, and the UPS device no longer being reachable when we want shut it down. There seem to be some changes to libusb on the way, that

I was testing out newhidups with an APC UPS, and I noticed that I needed '-x vendor=American.Power.*' instead of '-x vendor=APC.*' as indicated in the man page. Do other APC USB UPSes use 'APC' in the vendor string? Should we sidestep any such problems and just go with the hex vendor ID for APC examples? This was tested with a snapshot from the development branch, but the

Ladies and Gentlemen, I have been trying to sort out a nasty kernel oops for which I would like to ask for some advice. I don't actually think that this is a nut problem, although it is triggered by upsdrvctl or usbhid-ups. I rather suspect the USB library or the associated kernel code. Here is the configuration information: * system: Centos-5.5 * kernel: 2.6.18-194.32.1.el5, latest vanilla

Ladies and Gentlemen, I have been playing around with Arnaud's new HAL stuff a bit, and have some questions and observations. First my configuration: my UPS (Peter may remember): ups.mfr: APC ups.model: Back-UPS ES 650 ups.productid: 0002 ups.firmware: 818.w1.D ups.firmware.aux: w1 kernel: 2.6.18-92.1.6.el5 hal-0.5.8.1-35.el5, nut based on nut-2.2.2.tar.gz, small changes to

Gentlemen, I have now had a chance to run some initial tests of my changes to apc-hid.c of the current development tree. Running newhipups and inspecting the -DDDD output seems to indicate that with the fix below everything seems to work as expected. However, I have not yet shut my system in order to take the UPS out of action so that I can do my various tests with a lightbulb load. I still hope

Arnaud, > first, even if your battery is full, and your ups is online, there is a > small amount of power drawn. So having always is CHRG status is normal. > In fact, these complementary status are more interesting for higher end > UPSs. > > second, these status need not to be handled like LB, as each one clears the > other. While LB had no pending event (!LB) before... >

Hello all, I'm going to tackle learning C this week, and start writing my first * add-on/contribution; assuming it's actually worthy of contributing once it's done.. I think I've chosen a hefty project for my first go round here... I'd like to get some feedback from everyone on a FindMe/FollowMe spec I've put together. Before you read on, let me say, I don't want

CentOS 4.3 (fully updated, including CentOS Plus kernel). Running KDE 3.5.2 (fully updated from redhat.kde repo). I can't seem to get the OS to recognize my SD card when inserted into my USB card reader. Mepis 6 Beta 3 has no problem with it. DMESG sees nothing happening when the card is inserted. USB-STORAGE module is loaded.

I've added a pull request with changes to drivers/libusb and drivers/usbhid-ups mainly. They are to resolve issues I encountered when setting up a Tripp Lite SMART1500LCDT, but I think they're generally useful to the community. Here is the pull request comment I sent: https://github.com/networkupstools/nut/pull/122 Had trouble getting nut to work for my new Tripp Lite SMART1500LCDT. So

Peter, Thanks a lot for your latest changes to newhidups, which I like a lot. Unfortunately, when I tried to build the latest development tree stuff, I got a compile time error when compiling al175.c. It looks to me like my compiler, gcc-3.4.4-2.fc3, doesn't like the macro definition for "RECV(reg) do" because of a poorly inserted comment. I fixed the problem locally by the

Hi Stephen, It's been a little busy at home, so I haven't had a chance to go over the pull request in depth, but I didn't want you to think it hadn't been considered. On Apr 19, 2014, at 1:23 AM, Stephen J. Butler wrote: > I've added a pull request with changes to drivers/libusb and drivers/usbhid-ups mainly. They are to resolve issues I encountered when setting up a

Joel Peshkin wrote: > > I hacked in the following additonal changes... > > Index: newhidups.c > =================================================================== > RCS file: /cvsroot/nut/nut/drivers/newhidups.c,v > retrieving revision 1.1.1.1.8.6.2.21 > diff -u -r1.1.1.1.8.6.2.21 newhidups.c > --- newhidups.c 7 Nov 2005 22:14:20 -0000 1.1.1.1.8.6.2.21 > +++

Hi, I run NAS4Free (FreeBSD) system which somehow fails to recognize my UPS and fails with message: Unknown USB device: vendor 0x051d product 0x0002 bus uhub2 It's nut 2.6.5 Network UPS Tools - Generic HID driver 0.37 (2.6.5-Unversioned directory) USB communication driver 0.31 I have already posted on N4F forum if they have some ideas Here I would like to try another one. On this box I

Hallo, Following the tips found at https://calomel.org/nut_ups.html I was trying to make NUT operate "APC Back UPS CS-350". The device introduces itself as: #v+ ugen0 at uhub0 port 1 "American Power Conversion Back-UPS CS 350 FW:807.q7.I USB FW:q7" rev 1.10/0.06 addr 2 #v- My config: #v+ [apc] driver = usbhid-ups port = /dev/ugen0.00 pollfreq =