Re: Strange ucd-snmp actions
Turns out that compiling for 64 bit was more trouble than changing the scanf parser. -- --- net-snmp-5.0.9.org/agent/mibgroup/mibII/interfaces.c2004-01-31 21:18:15.0 +0100 +++ net-snmp-5.0.9/agent/mibgroup/mibII/interfaces.c2004-01-31 01:02:54.0 +0100 @@ -1492,12 +1492,12 @@ struct ifreqifrq; struct ifnet **ifnetaddr_ptr; FILE *devin; -unsigned long rec_pkt, rec_oct, rec_err, rec_drop; -unsigned long snd_pkt, snd_oct, snd_err, snd_drop, coll; +unsigned long long rec_pkt, rec_oct, rec_err, rec_drop; +unsigned long long snd_pkt, snd_oct, snd_err, snd_drop, coll; int i, fd; conf_if_list *if_ptr; const char *scan_line_2_2 = -"%lu %lu %lu %lu %*lu %*lu %*lu %*lu %lu %lu %lu %lu %*lu %lu"; +"%llu %llu %llu %llu %*llu %*llu %*llu %*llu %llu %llu %llu %llu %*llu %llu"; const char *scan_line_2_0 = "%lu %lu %*lu %*lu %*lu %lu %lu %*lu %*lu %lu"; const char *scan_line_to_use; - On Thu, 2004-01-29 at 02:02, Kenneth Johansson wrote: > On Jan 5, 2004, at 10:22, Igal Baevsky wrote: > > > To all the people wondering about MRTG funkiness - it's not an MRTG > > problem ! > > I'm using Ultra 10 with Debian installed as a router. > > I've found out that the MIB counter on eth0 stops growing when getting > > to the specific value (IF-MIB::ifInOctets.2 = Counter32: 4294967295). > > Thats why you keep seeing zeros on your graphs - no delta between the > > previous value and the current. I'm seeking for a solution for this > > problem. > > Igal. > > > > The reason for this is that smnpd uses scanf to pars /proc/net/dev but > the values in that file is 64bit for a 64bit kernel and we get problems > with 32bit binaries. > > I'm currently trying to recompile snmpd into a 64 bit binary but I need > to recompile all the libraries that it uses to 64 bit versions also and > openssl was not happy. > > Also to make things even funnier the snmp value is actually a 32 bit > counter and I'm not sure what will happen exactly even if I get it to > compile into 64 bit. > > One other solution would be to change scanf to behave better when feed > to large values. > I have seen this problem in other applications that read /proc/net/dev > like procmeter. > > > > Philippe Sainte-Marie wrote: > >> Hi. > >> I'm using testing on a Ultra5 which is now my gateway at home. > >> I'm trying to graph my output/input bw with mrtg but i have like > >> a bug with mrtg. > >> It does work fine, until a day where it simply stuck and doesn't > >> graph > >> anything in input or anything in output. > >> I've tried all kind of settings without success. > >> On my provider side, i'm using DHCP to connect to the internet. > >> Would that have any influence over the snmp request for data > >> input/output ? > >> Any help would be great! > >> > > > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > > [EMAIL PROTECTED] > > >
Re: recompiling deb to 64 bit
On Jan 29, 2004, at 14:26, Ben Collins wrote: On Thu, Jan 29, 2004 at 02:40:32AM +0100, Kenneth Johansson wrote: I managed to confuse myself trying to recompile a few libs to 64 bit version doing apt-get source -b works very bad with anything tat installs libraries as the resulting deb installs the new 64 bit lib over the 32 bit version. what is the proper sequence to get it to install in the lib64 directory You have to rewrite portions of debian/rules, and also edit debian/control so the library package names are of the form lib64foo. I'm betting you'll screw up your system pretty badly trying though. There's lots of pitfalls involved, and as you have to ask how to do this, you probably wont be aware of the problems (and they aren't easy to list). What more than to get the library into /lib64 would need to be done? Is the problem in building a correct deb package or something else like autoconf? I tried to find any information about this but could not find much at all
recompiling deb to 64 bit
I managed to confuse myself trying to recompile a few libs to 64 bit version doing apt-get source -b works very bad with anything tat installs libraries as the resulting deb installs the new 64 bit lib over the 32 bit version. what is the proper sequence to get it to install in the lib64 directory ??
Re: Strange ucd-snmp actions
On Jan 5, 2004, at 10:22, Igal Baevsky wrote: To all the people wondering about MRTG funkiness - it's not an MRTG problem ! I'm using Ultra 10 with Debian installed as a router. I've found out that the MIB counter on eth0 stops growing when getting to the specific value (IF-MIB::ifInOctets.2 = Counter32: 4294967295). Thats why you keep seeing zeros on your graphs - no delta between the previous value and the current. I'm seeking for a solution for this problem. Igal. The reason for this is that smnpd uses scanf to pars /proc/net/dev but the values in that file is 64bit for a 64bit kernel and we get problems with 32bit binaries. I'm currently trying to recompile snmpd into a 64 bit binary but I need to recompile all the libraries that it uses to 64 bit versions also and openssl was not happy. Also to make things even funnier the snmp value is actually a 32 bit counter and I'm not sure what will happen exactly even if I get it to compile into 64 bit. One other solution would be to change scanf to behave better when feed to large values. I have seen this problem in other applications that read /proc/net/dev like procmeter. Philippe Sainte-Marie wrote: Hi. I'm using testing on a Ultra5 which is now my gateway at home. I'm trying to graph my output/input bw with mrtg but i have like a bug with mrtg. It does work fine, until a day where it simply stuck and doesn't graph anything in input or anything in output. I've tried all kind of settings without success. On my provider side, i'm using DHCP to connect to the internet. Would that have any influence over the snmp request for data input/output ? Any help would be great! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New kernel 2.4.21 and Sparc
On Tue, 2003-06-17 at 07:19, Elie De Brauwer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Monday 16 June 2003 19:33, Kenneth Johansson wrote: > > On Mon, 2003-06-16 at 16:58, Elie De Brauwer wrote: > > > I little quick response, the 2.4.21 package works perfectly on my Sun > > > Blade 100, installed from the first time, loaded perfectly after reboot > > > after following the threads the past few days i think it has to be > > > said that the kernel package can actually work > > > > Can you create and use a swapfile ?? > > Since i never used a swapfile it tried to create and use one, but it seems > that it fails, am I doing something wrong ? No you are doing it right. > Or is there some other problem ? Looks like it :(
Re: New kernel 2.4.21 and Sparc
On Mon, 2003-06-16 at 16:58, Elie De Brauwer wrote: > I little quick response, the 2.4.21 package works perfectly on my Sun Blade > 100, installed from the first time, loaded perfectly after reboot after > following the threads the past few days i think it has to be said that the > kernel package can actually work > Can you create and use a swapfile ??
Re: New kernel 2.4.21 and Sparc
On Sat, 2003-06-14 at 15:13, Ben Collins wrote: > On Sat, Jun 14, 2003 at 03:06:20PM +0200, Andreas Tille wrote: > > On Fri, 13 Jun 2003, Ben Collins wrote: > > > > > suspect you did something wrong though. Try my > > > kernel-image-2.4.21-sparc64 package. If that works, use the > > > /boot/config-2.4.21 as a starting point for compiling your own. > > Any hint what would be the right compiler for a woody machine? > > I have better than a hint, egcs64 package. Typical I just upgraded my kernel and used "gcc (GCC) 3.2.3 (Debian)" The result is actually running now what problems could I expect ?? The original reason for upgrading was that I noticed that the old version I was running could not use swapfiles but that problem still exist. #mkswap .swapfile Assuming pages of size 8192 (not 4096) Setting up swapspace version 1, size = 8200 kB # swapon .swapfile swapon: .swapfile: Invalid argument In syslog I get this Swap area shorter than signature indicates
update OpenBoot
I got a new harddrive for my cp1500 card but now I have the problem that openboot can't boot from that disk unless I also have the old disk inserted but then everything works fine. The reason for the new disk was that the old one sound like a jet engine and most probably do not have that long left so having both in is not an option. I'm hoping that a firmware update is going to fix this but is it possible to update the firmware from linux? or is this done from openboot directly? The reason I don't know is that sun had messed up all the links and I could not download anything from the firmware section. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
console on ttya
I have a number of problem with my sparc that uses ttya for IO. Problem one. Connecting the serial port to a PC also running debian has the funny effect that when I shutdown the PC the sparcs enters the openboot. In short the effect is like turning both off, This is not good as one is NIS master and the other the slave :( Problem two. When connecting to the PC from any system and running minicom to talk to the sparc and not exiting minicom the proper way the sun enters obenboot. Problem three. can't figure out how to enter openboot the proper way :) The way this works for me right now I have to make shure I don't have the serial cable connected this is a minor irritation.
ntp
I have a problem with the ntp binary package in testing and looking thru the bugtracker I'am not the only one. Installing the version in stable works but since it's the same upstream version this must be some kind on compilation problem or a debian specific patch. The only new patch looks completly harmless so this leavs a build problem. Anyone else having this problem?
Re: ppp on sparc
Ben Collins wrote: > On Wed, Mar 07, 2001 at 09:02:45PM +0100, Kenneth Johansson wrote: > > I have problem getting ppp to work on 2.4.2 for sparc64. I run potato > > with a few packages replaced to support the new kernel. > > > > I get this error > > kernel: sys32_ioctl: Unknown cmd fd(0) cmd(40047437) arg(0006be18) > > > > The exact same versions of ppp-kernel work on x86. > > What program produces this? pppd? I'll check into it later if I can. > Looks like a new ioctl that isn't being translated. I fixed it myself. --- linux/arch/sparc64/kernel/ioctl32.c Mon Feb 19 04:49:54 2001 +++ linux-2.4.3-pre3/arch/sparc64/kernel/ioctl32.c Fri Mar 9 16:21:33 2001@@ -3331,6 +3331,7 @@ COMPATIBLE_IOCTL(PPPIOCCONNECT) COMPATIBLE_IOCTL(PPPIOCDISCONN) COMPATIBLE_IOCTL(PPPIOCATTCHAN) +COMPATIBLE_IOCTL(PPPIOCGCHAN) /* PPPOX */ COMPATIBLE_IOCTL(PPPOEIOCSFWD); COMPATIBLE_IOCTL(PPPOEIOCDFWD);
Re: ppp on sparc
Ben Collins wrote: > On Wed, Mar 07, 2001 at 09:02:45PM +0100, Kenneth Johansson wrote: > > I have problem getting ppp to work on 2.4.2 for sparc64. I run potato > > with a few packages replaced to support the new kernel. > > > > I get this error > > kernel: sys32_ioctl: Unknown cmd fd(0) cmd(40047437) arg(0006be18) > > > > The exact same versions of ppp-kernel work on x86. > > What program produces this? pppd? I'll check into it later if I can. > Looks like a new ioctl that isn't being translated. > Yes it's pppd it happens even before any traffic. try starting pppd in a server mode where it simply wait on a remote connection but you have to turn on the local option otherwise pppd waits on the modem and don't even try to start ppp. pppd ttyS0 9600 local ---options ms-dns 192.168.1.1 asyncmap 0 noauth lcp-echo-interval 30 lcp-echo-failure 4 - and a dummy pap-sectrets file should do it.
ppp on sparc
I have problem getting ppp to work on 2.4.2 for sparc64. I run potato with a few packages replaced to support the new kernel. I get this error kernel: sys32_ioctl: Unknown cmd fd(0) cmd(40047437) arg(0006be18) The exact same versions of ppp-kernel work on x86. --- ii ppp 2.4.0f-1 Point-to-Point Protocol (PPP) daemon. ii egcs64 19980921-4 C Cross-Compiler for 64 bit UltraSPARC kernels ii gcc 2.95.2-13The GNU C compiler. ii modutils 2.4.2-1 Linux module utilities.
