Date: Sun, 04 Oct 1998 14:17:23 -0700 From: Mike Smith <mike@smith.net.au> To: Joao Carlos Mendes Luis <jonny@jonny.eng.br> Cc: jfieber@indiana.edu (John Fieber), emulation@FreeBSD.ORG Subject: Re: APC PowerChute under FreeBSD Message-ID: <199810042117.OAA06715@dingo.cdrom.com> In-Reply-To: Your message of "Sun, 04 Oct 1998 17:36:39 -0200." <199810041936.RAA10583@roma.coe.ufrj.br>
next in thread | previous in thread | raw e-mail | index | archive | help
> // Since I've just been working in the guts of the emulator to get > // Sybase running...what is the ioctl in question? > > There are at least 4 Unknown errors in the linux_kdump below. The > program writes a probe string to the UPS, and waits for an answer that > never comes back. The cable is working, I have tested it with apcmon > and upsd. Linux negates its error returns (for what reason I can't imagine). I didn't change linux_kdump to translate these (I guess I was lazy). > roma::root [767] ktrace ./apcupsd-libc5 > ./apcupsd-libc5: PANIC! Cannot talk to UPS > roma::root [768] > > linux_kdump: > > ... > 10485 apcupsd-libc5 CALL linux_open(0x80556b8,0x502,0) > 10485 apcupsd-libc5 NAMI "/compat/linux/dev/ups" > 10485 apcupsd-libc5 NAMI "/dev/ups" > 10485 apcupsd-libc5 RET linux_open 3 > 10485 apcupsd-libc5 CALL linux_open(0x805ac18,0xc2,0x1a4) > ... > 10485 apcupsd-libc5 CALL linux_ioctl(0x3,0x5401 ,0x805aba0) > 10485 apcupsd-libc5 RET linux_ioctl 0 > 10485 apcupsd-libc5 CALL linux_sigaction(0x1,0xefbfd500,0xefbfd4f0) > 10485 apcupsd-libc5 RET linux_sigaction 0 > 10485 apcupsd-libc5 CALL linux_sigaction(0x2,0xefbfd4f8,0xefbfd4e8) > 10485 apcupsd-libc5 RET linux_sigaction 0 > 10485 apcupsd-libc5 CALL linux_sigaction(0xf,0xefbfd4f0,0xefbfd4e0) > 10485 apcupsd-libc5 RET linux_sigaction 0 > 10485 apcupsd-libc5 CALL linux_ioctl(0x3,0x540b ,0) > >> Probably this is the guilty one. > 10485 apcupsd-libc5 RET linux_ioctl -1 errno -14 Unknown error: -14 That's bad, but probably not fatal. 14 is EFAULT; this looks like it's attempting to flush the serial interface, but 0 is definitely an invalid argument from our point of view. > 10485 apcupsd-libc5 CALL linux_ioctl(0x3,SNDCTL_TMR_START,0x805a9c0) > 10485 apcupsd-libc5 RET linux_ioctl 0 I don't quite understand the sound ioctl here. > 10485 apcupsd-libc5 CALL write(0x3,0xefbfd533,0x1) > 10485 apcupsd-libc5 GIO fd 3 wrote 1 byte > "Y" > 10485 apcupsd-libc5 RET write 1 > 10485 apcupsd-libc5 CALL linux_sigprocmask(0,0xefbfd4ec,0xefbfd4e8) > 10485 apcupsd-libc5 RET linux_sigprocmask 0 > 10485 apcupsd-libc5 CALL linux_sigaction(0xe,0xefbfd500,0xefbfd4f0) > 10485 apcupsd-libc5 RET linux_sigaction 0 > 10485 apcupsd-libc5 CALL linux_time(0) > 10485 apcupsd-libc5 RET linux_time 907529171/0x3617cbd3 > 10485 apcupsd-libc5 CALL linux_alarm(0x1) > 10485 apcupsd-libc5 RET linux_alarm 0 > 10485 apcupsd-libc5 CALL linux_sigsuspend(0,0,0) > 10485 apcupsd-libc5 PSIG SIGALRM caught handler=0x280c3cb0 > mask=0x2000 code=0x > 0 > 10485 apcupsd-libc5 RET linux_sigsuspend -1 errno -4 Unknown error: > -4 > 10485 apcupsd-libc5 CALL linux_sigreturn(0xefbfd454) > 10485 apcupsd-libc5 RET linux_sigreturn JUSTRETURN > 10485 apcupsd-libc5 CALL linux_time(0) > 10485 apcupsd-libc5 RET linux_time 907529172/0x3617cbd4 > 10485 apcupsd-libc5 CALL linux_sigaction(0xe,0xefbfd4f0,0) > 10485 apcupsd-libc5 RET linux_sigaction 0 > 10485 apcupsd-libc5 CALL linux_alarm(0) > 10485 apcupsd-libc5 RET linux_alarm 0 > 10485 apcupsd-libc5 CALL linux_sigprocmask(0x2,0xefbfd4e8,0) > 10485 apcupsd-libc5 RET linux_sigprocmask 0 > 10485 apcupsd-libc5 CALL linux_ioctl(0x3,0x540b ,0x2) > 10485 apcupsd-libc5 RET linux_ioctl -1 errno -14 Unknown error: -14 > 10485 apcupsd-libc5 CALL write(0x3,0xefbfd533,0x1) > 10485 apcupsd-libc5 GIO fd 3 wrote 1 byte > "Y" > 10485 apcupsd-libc5 RET write 1 > 10485 apcupsd-libc5 CALL linux_sigaction(0xe,0xefbfd4e8,0xefbfd4d8) > 10485 apcupsd-libc5 RET linux_sigaction 0 > 10485 apcupsd-libc5 CALL linux_alarm(0x3) > 10485 apcupsd-libc5 RET linux_alarm 0 > 10485 apcupsd-libc5 CALL read(0x3,0xefbfd513,0x1) > 10485 apcupsd-libc5 PSIG SIGALRM caught handler=0x8051980 mask=0x0 > code=0x0 > 10485 apcupsd-libc5 RET read -1 errno -4 Unknown error: -4 > 10485 apcupsd-libc5 CALL linux_sigreturn(0xefbfd490) > 10485 apcupsd-libc5 RET linux_sigreturn JUSTRETURN > 10485 apcupsd-libc5 CALL linux_alarm(0) > 10485 apcupsd-libc5 RET linux_alarm 0 > 10485 apcupsd-libc5 CALL linux_sigaction(0xe,0xefbfd4e4,0xefbfd4d4) > 10485 apcupsd-libc5 RET linux_sigaction 0 > 10485 apcupsd-libc5 CALL write(0x2,0xefbfcb40,0x2c) > 10485 apcupsd-libc5 GIO fd 2 wrote 44 bytes > "./apcupsd-libc5: PANIC! Cannot talk to UPS > \a" > 10485 apcupsd-libc5 RET write 44/0x2c > ... > > I've also tested it with kermit. Sending a single 'Y' char gives me a > 'SM' back, instantly. Looks like there might be a problem with setting the right modes on the serial interface. You should look for ioctls setting CBREAK or RAW mode, as I suspect this might be being lost. You could also loop the serial interface back to another port, and use kermit to pretend to be the UPS. If you see the Y, and say "SM<cr>" and it works, you will know that it's a raw/cookedness problem. At any rate, it would be good to know why the Linux TCFLSH ioctl is being called with a NULL argument - perhaps this has some special significance under Linux? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810042117.OAA06715>