Re: If not the force, what should I use? (Was: FreeBSD in Business (was Re: Idea for FreeBSD))
On Tuesday 12 August 2008 17:51:32 Mike Meyer wrote: On Tue, 12 Aug 2008 17:10:22 +0200 Adrian Penisoara [EMAIL PROTECTED] wrote: Umm, I have used Gentoo and I do not remember having to use forcestart at the command line... Ok, given that you 1) want to have both this service if it's part of our normal runtime and this service even if it's not part of our normal runtime as script commands, and that 2) without a prefix gets the if it's part of our normal runtime meaning, as we want the user to have to explicitly say Yes, I know this looks odd, but I know what I'm doing so do it anyway to get the even if it's not part of our normal runtime behavior, then what would you have us use instead of force? People keep talking about forcestart. Unless I'm misunderstanding things horribly, forcestart does exactly that - forces the service to start regardless of any error that may occur. The better option for starting something as a one-off (not enabled in rc.conf) is mnemonically named onestart - which only ignores the rcvar but still fails on any other error. And yes, I like having onestart/onestop distinguished from start/stop. Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Debugging reboot with Linux emulation
Hi folks, I recently tried to run a Linux binary of Maple (commercial math software) on my FreeBSD 7.0-RELEASE/amd64 box, and the machine rebooted. I tried it again while watching the console, and no panic message appeared to be produced. Does anyone have any ideas on how to debug problems of this nature? I realize I may not be able to get Maple to work, but in any case the system should not die like this, so I can at least try to fix that bug. Incidentally, is it possible to run kdb with a USB keyboard? Hitting Ctrl-Alt-Esc gives me the kdb prompt, but I can't type, so I can do nothing except hit the power button. I do have hint.atkbd.0.flags=0x1 in /boot/device.hints. Unfortunately I don't have a PS/2 keyboard on hand, though I can try and get a hold of one if all else fails. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: If not the force, what should I use? (Was: FreeBSD in Business (was Re: Idea for FreeBSD))
Jonathan McKeown wrote: On Tuesday 12 August 2008 17:51:32 Mike Meyer wrote: On Tue, 12 Aug 2008 17:10:22 +0200 Adrian Penisoara [EMAIL PROTECTED] wrote: Umm, I have used Gentoo and I do not remember having to use forcestart at the command line... Ok, given that you 1) want to have both this service if it's part of our normal runtime and this service even if it's not part of our normal runtime as script commands, and that 2) without a prefix gets the if it's part of our normal runtime meaning, as we want the user to have to explicitly say Yes, I know this looks odd, but I know what I'm doing so do it anyway to get the even if it's not part of our normal runtime behavior, then what would you have us use instead of force? People keep talking about forcestart. Unless I'm misunderstanding things horribly, forcestart does exactly that - forces the service to start regardless of any error that may occur. The better option for starting something as a one-off (not enabled in rc.conf) is mnemonically named onestart - which only ignores the rcvar but still fails on any other error. And yes, I like having onestart/onestop distinguished from start/stop. I believe it forces a start even though its not actually enabled (in rc.conf) rather than regardless of errors. If you really want a command line of onestart/onestop install the sysutils/bsdadminscripts port which has a script called rconestart and rconestop which do exactly that ;) Vince Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging reboot with Linux emulation
On Tue, Aug 12, 2008 at 11:52:35PM -0700, Nate Eldredge wrote: Hi folks, I recently tried to run a Linux binary of Maple (commercial math software) on my FreeBSD 7.0-RELEASE/amd64 box, and the machine rebooted. I tried it again while watching the console, and no panic message appeared to be produced. Does anyone have any ideas on how to debug problems of this nature? I realize I may not be able to get Maple to work, but in any case the system should not die like this, so I can at least try to fix that bug. Hi ktrace/linux_kdump, or best - build linux module with -DDEBUG and see where it die. -- Have fun! chd ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: If not the force, what should I use?
On Wednesday 13 August 2008 10:40:53 Vincent Hoffman wrote: Jonathan McKeown wrote: People keep talking about forcestart. Unless I'm misunderstanding things horribly, forcestart does exactly that - forces the service to start regardless of any error that may occur. The better option for starting something as a one-off (not enabled in rc.conf) is mnemonically named onestart - which only ignores the rcvar but still fails on any other error. And yes, I like having onestart/onestop distinguished from start/stop. I believe it forces a start even though its not actually enabled (in rc.conf) rather than regardless of errors. If you really want a command line of onestart/onestop install the sysutils/bsdadminscripts port which has a script called rconestart and rconestop which do exactly that ;) No, you don't need to install anything - it's part of rc.subr. From the rc.subr(8) manpage: argument may have one of the following prefixes which alters its operation: fast Skip the check for an existing running process, and sets rc_fast=YES. force Skip the checks for rcvar being set to ``YES'', and sets rc_force=YES. This ignores argument_precmd returning non-zero, and ignores any of the required_* tests failing, and always returns a zero exit status. oneSkip the checks for rcvar being set to ``YES'', but performs all the other prerequisite tests. I certainly use onestart - generally when I'm configuring and testing a new service before enabling it in rc.conf. I also use it with NFS. Whenever I've changed /etc/exports, I force mountd to reread it by issuing /etc/rc.d/mountd onereload Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: If not the force, what should I use?
Jonathan McKeown wrote: On Wednesday 13 August 2008 10:40:53 Vincent Hoffman wrote: Jonathan McKeown wrote: People keep talking about forcestart. Unless I'm misunderstanding things horribly, forcestart does exactly that - forces the service to start regardless of any error that may occur. The better option for starting something as a one-off (not enabled in rc.conf) is mnemonically named onestart - which only ignores the rcvar but still fails on any other error. And yes, I like having onestart/onestop distinguished from start/stop. I believe it forces a start even though its not actually enabled (in rc.conf) rather than regardless of errors. If you really want a command line of onestart/onestop install the sysutils/bsdadminscripts port which has a script called rconestart and rconestop which do exactly that ;) No, you don't need to install anything - it's part of rc.subr. From the rc.subr(8) manpage: argument may have one of the following prefixes which alters its operation: fast Skip the check for an existing running process, and sets rc_fast=YES. force Skip the checks for rcvar being set to ``YES'', and sets rc_force=YES. This ignores argument_precmd returning non-zero, and ignores any of the required_* tests failing, and always returns a zero exit status. oneSkip the checks for rcvar being set to ``YES'', but performs all the other prerequisite tests. I certainly use onestart - generally when I'm configuring and testing a new service before enabling it in rc.conf. I also use it with NFS. Whenever I've changed /etc/exports, I force mountd to reread it by issuing /etc/rc.d/mountd onereload Doh I just skimmed though /etc/rc.subr not the manpage, thanks for the pointers. Vince Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging reboot with Linux emulation
Quoting Nate Eldredge [EMAIL PROTECTED] (from Tue, 12 Aug 2008 23:52:35 -0700 (PDT)): Hi folks, I recently tried to run a Linux binary of Maple (commercial math software) on my FreeBSD 7.0-RELEASE/amd64 box, and the machine rebooted. I tried it again while watching the console, and no panic message appeared to be produced. Does anyone have any ideas on how to debug problems of this nature? I realize I may not be able to get Maple to work, but in any case the system should not die like this, so I can at least try to fix that bug. Incidentally, is it possible to run kdb with a USB keyboard? Hitting Ctrl-Alt-Esc gives me the kdb prompt, but I can't type, so I can do nothing except hit the power button. I do have hint.atkbd.0.flags=0x1 in /boot/device.hints. Unfortunately I don't have a PS/2 keyboard on hand, though I can try and get a hold of one if all else fails. A guess out of my cristallball: That's one of the cases which happen if you run a linux program without branding it as a linux program first. People tend to think it is not needed, but in some rare circumstances it just causes what you see, a reboot. So go and identify all binaries (IMPORTANT: but not the libraries!), e.g. with the file(1), and use brandelf -t Linux on those programs. Bye, Alexander. -- She said, I know you ... you cannot sing. I said, That's nothing, you should hear me play piano. -- Morrisey http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging reboot with Linux emulation
On Wed, Aug 13, 2008 at 01:28:22PM +0200, Alexander Leidinger wrote: Quoting Nate Eldredge [EMAIL PROTECTED] (from Tue, 12 Aug 2008 23:52:35 -0700 (PDT)): Hi folks, I recently tried to run a Linux binary of Maple (commercial math software) on my FreeBSD 7.0-RELEASE/amd64 box, and the machine rebooted. I tried it again while watching the console, and no panic message appeared to be produced. Does anyone have any ideas on how to debug problems of this nature? I realize I may not be able to get Maple to work, but in any case the system should not die like this, so I can at least try to fix that bug. Incidentally, is it possible to run kdb with a USB keyboard? Hitting Ctrl-Alt-Esc gives me the kdb prompt, but I can't type, so I can do nothing except hit the power button. I do have hint.atkbd.0.flags=0x1 in /boot/device.hints. Unfortunately I don't have a PS/2 keyboard on hand, though I can try and get a hold of one if all else fails. A guess out of my cristallball: That's one of the cases which happen if you run a linux program without branding it as a linux program first. People tend to think it is not needed, but in some rare circumstances it just causes what you see, a reboot. So go and identify all binaries (IMPORTANT: but not the libraries!), e.g. with the file(1), and use brandelf -t Linux on those programs. That would be an enormous local hole, assuming an native FreeBSD binary may cause system crash. I actually doubt that non-branded elf binary ever start, due to unsatisfied dynamic dependencies. pgpIROlSwTLLW.pgp Description: PGP signature
Re: If not the force, what should I use?
On Wed, 13 Aug 2008 12:27:30 +0200 Jonathan McKeown [EMAIL PROTECTED] wrote: On Wednesday 13 August 2008 10:40:53 Vincent Hoffman wrote: Jonathan McKeown wrote: People keep talking about forcestart. Unless I'm misunderstanding things horribly, forcestart does exactly that - forces the service to start regardless of any error that may occur. The better option for starting something as a one-off (not enabled in rc.conf) is mnemonically named onestart - which only ignores the rcvar but still fails on any other error. And yes, I like having onestart/onestop distinguished from start/stop. I believe it forces a start even though its not actually enabled (in rc.conf) rather than regardless of errors. If you really want a command line of onestart/onestop install the sysutils/bsdadminscripts port which has a script called rconestart and rconestop which do exactly that ;) No, you don't need to install anything - it's part of rc.subr. From the rc.subr(8) manpage: argument may have one of the following prefixes which alters its operation: fast Skip the check for an existing running process, and sets rc_fast=YES. force Skip the checks for rcvar being set to ``YES'', and sets rc_force=YES. This ignores argument_precmd returning non-zero, and ignores any of the required_* tests failing, and always returns a zero exit status. oneSkip the checks for rcvar being set to ``YES'', but performs all the other prerequisite tests. In that case, someone should file a doc bug for the rc(8) manpage, which says: Each script is expected to support at least the following arguments, which are automatically supported if it uses the run_rc_command() func- tion: startStart the service. This should check that the service is to be started as specified by rc.conf(5). Also checks if the service is already running and refuses to start if it is. This latter check is not performed by standard FreeBSD scripts if the system is starting directly to multi-user mode, to speed up the boot process. If forcestart is given, ignore the rc.conf(5) check and start anyway. stop If the service is to be started as specified by rc.conf(5), stop the service. This should check that the service is running and complain if it is not. If forcestop is given, ignore the rc.conf(5) check and attempt to stop. I don't have time to do it now, but will later if no one says they have mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea for FreeBSD
Quoting Kurt J. Lidl [EMAIL PROTECTED] (from Thu, 7 Aug 2008 16:20:42 -0400): On Thu, Aug 07, 2008 at 07:02:30PM +1000, Peter Jeremy wrote: On 2008-Aug-06 19:14:51 -0400, [EMAIL PROTECTED] wrote: In Solaris 10 the Services Management Facility (SMF) was introduced. The main purpose of SMF appears to be to drum up business for Sun's training courses by radically changing Sol10 Administration for little benefit. The main purpose of SMF was to make it possible to programmatically control the system and deal with the myriad of different types of faults from the gazillion different things that people want to run on machines. It's complex because it has to deal with the real world. There's also some sort of functionality included, which is comparable with daemontools (depending if you enable this in the xml description or not). You could say this is included in your deal with ... faults above, but for people not aware of this it may be nice to know. Bye, Alexander. -- Life may have no meaning, or, even worse, it may have a meaning of which you disapprove. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging reboot with Linux emulation
On Wed, Aug 13, 2008 at 04:03:53PM +0200, Alexander Leidinger wrote: Quoting Kostik Belousov [EMAIL PROTECTED] (from Wed, 13 Aug 2008 14:54:13 +0300): On Wed, Aug 13, 2008 at 01:28:22PM +0200, Alexander Leidinger wrote: Quoting Nate Eldredge [EMAIL PROTECTED] (from Tue, 12 Aug 2008 23:52:35 -0700 (PDT)): Hi folks, I recently tried to run a Linux binary of Maple (commercial math software) on my FreeBSD 7.0-RELEASE/amd64 box, and the machine rebooted. I tried it again while watching the console, and no panic message appeared to be produced. Does anyone have any ideas on how to debug problems of this nature? I realize I may not be able to get Maple to work, but in any case the system should not die like this, so I can at least try to fix that bug. Incidentally, is it possible to run kdb with a USB keyboard? Hitting Ctrl-Alt-Esc gives me the kdb prompt, but I can't type, so I can do nothing except hit the power button. I do have hint.atkbd.0.flags=0x1 in /boot/device.hints. Unfortunately I don't have a PS/2 keyboard on hand, though I can try and get a hold of one if all else fails. A guess out of my cristallball: That's one of the cases which happen if you run a linux program without branding it as a linux program first. People tend to think it is not needed, but in some rare circumstances it just causes what you see, a reboot. So go and identify all binaries (IMPORTANT: but not the libraries!), e.g. with the file(1), and use brandelf -t Linux on those programs. That would be an enormous local hole, assuming an native FreeBSD binary may cause system crash. I actually doubt that non-branded elf binary ever start, due to unsatisfied dynamic dependencies. You see this behavior only for static binaries. In the non-branded case the image activator takes the FreeBSD image and unfortunately there's a common syscall in linux which matches the syscall number in FreeBSD which causes the reboot (IIRC reboot syscall, do we have something like this?). It's not a system crash (kernel panic), it's a real reboot. AFAIR this also only works if you run the program as root. So... Then, the issue of mixing our reboot(2)/linux fcntl(2) is irrelevant. The original reporter said that system just rebooted, and I believe that filesystems where not synced and not unmounted properly. Our reboot(2) does not have flag combination that could cause such behaviour, I think. Also, I doubt that the program being run is statically linked or run by root. Confirmation ? Overall, this looks like a nasty bug, hopefully in the linuxolator. pgpcKmuG0ELY2.pgp Description: PGP signature
Re: Debugging reboot with Linux emulation
Quoting Kostik Belousov [EMAIL PROTECTED] (from Wed, 13 Aug 2008 14:54:13 +0300): On Wed, Aug 13, 2008 at 01:28:22PM +0200, Alexander Leidinger wrote: Quoting Nate Eldredge [EMAIL PROTECTED] (from Tue, 12 Aug 2008 23:52:35 -0700 (PDT)): Hi folks, I recently tried to run a Linux binary of Maple (commercial math software) on my FreeBSD 7.0-RELEASE/amd64 box, and the machine rebooted. I tried it again while watching the console, and no panic message appeared to be produced. Does anyone have any ideas on how to debug problems of this nature? I realize I may not be able to get Maple to work, but in any case the system should not die like this, so I can at least try to fix that bug. Incidentally, is it possible to run kdb with a USB keyboard? Hitting Ctrl-Alt-Esc gives me the kdb prompt, but I can't type, so I can do nothing except hit the power button. I do have hint.atkbd.0.flags=0x1 in /boot/device.hints. Unfortunately I don't have a PS/2 keyboard on hand, though I can try and get a hold of one if all else fails. A guess out of my cristallball: That's one of the cases which happen if you run a linux program without branding it as a linux program first. People tend to think it is not needed, but in some rare circumstances it just causes what you see, a reboot. So go and identify all binaries (IMPORTANT: but not the libraries!), e.g. with the file(1), and use brandelf -t Linux on those programs. That would be an enormous local hole, assuming an native FreeBSD binary may cause system crash. I actually doubt that non-branded elf binary ever start, due to unsatisfied dynamic dependencies. You see this behavior only for static binaries. In the non-branded case the image activator takes the FreeBSD image and unfortunately there's a common syscall in linux which matches the syscall number in FreeBSD which causes the reboot (IIRC reboot syscall, do we have something like this?). It's not a system crash (kernel panic), it's a real reboot. AFAIR this also only works if you run the program as root. So... Bye, Alexander. -- Blow it out your ear. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging reboot with Linux emulation
Quoting Kostik Belousov [EMAIL PROTECTED] (from Wed, 13 Aug 2008 17:10:59 +0300): On Wed, Aug 13, 2008 at 04:03:53PM +0200, Alexander Leidinger wrote: Quoting Kostik Belousov [EMAIL PROTECTED] (from Wed, 13 Aug 2008 14:54:13 +0300): On Wed, Aug 13, 2008 at 01:28:22PM +0200, Alexander Leidinger wrote: Quoting Nate Eldredge [EMAIL PROTECTED] (from Tue, 12 Aug 2008 23:52:35 -0700 (PDT)): Hi folks, I recently tried to run a Linux binary of Maple (commercial math software) on my FreeBSD 7.0-RELEASE/amd64 box, and the machine rebooted. I tried it again while watching the console, and no panic message appeared to be produced. Does anyone have any ideas on how to debug problems of this nature? I realize I may not be able to get Maple to work, but in any case the system should not die like this, so I can at least try to fix that bug. Incidentally, is it possible to run kdb with a USB keyboard? Hitting Ctrl-Alt-Esc gives me the kdb prompt, but I can't type, so I can do nothing except hit the power button. I do have hint.atkbd.0.flags=0x1 in /boot/device.hints. Unfortunately I don't have a PS/2 keyboard on hand, though I can try and get a hold of one if all else fails. A guess out of my cristallball: That's one of the cases which happen if you run a linux program without branding it as a linux program first. People tend to think it is not needed, but in some rare circumstances it just causes what you see, a reboot. So go and identify all binaries (IMPORTANT: but not the libraries!), e.g. with the file(1), and use brandelf -t Linux on those programs. That would be an enormous local hole, assuming an native FreeBSD binary may cause system crash. I actually doubt that non-branded elf binary ever start, due to unsatisfied dynamic dependencies. You see this behavior only for static binaries. In the non-branded case the image activator takes the FreeBSD image and unfortunately there's a common syscall in linux which matches the syscall number in FreeBSD which causes the reboot (IIRC reboot syscall, do we have something like this?). It's not a system crash (kernel panic), it's a real reboot. AFAIR this also only works if you run the program as root. So... Then, the issue of mixing our reboot(2)/linux fcntl(2) is irrelevant. The original reporter said that system just rebooted, and I believe that filesystems where not synced and not unmounted properly. Our reboot(2) does not have flag combination that could cause such behaviour, I think. Also, I doubt that the program being run is statically linked or run by root. Confirmation ? I will not be surprised if it is statically linked and run by root. I've seen enough such cases with commercial software and users using it, that my cristalball caused me to send my first reply to the problem. Overall, this looks like a nasty bug, hopefully in the linuxolator. The linuxulator is not involved, as there's no branding it is not invoked. The same will happen if the linxulator is not in the kernel. Bye, Alexander. -- If value corrupts then absolute value corrupts absolutely. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging reboot with Linux emulation
On Wed, Aug 13, 2008 at 04:03:53PM +0200, Alexander Leidinger wrote: Quoting Kostik Belousov [EMAIL PROTECTED] (from Wed, 13 Aug 2008 14:54:13 +0300): On Wed, Aug 13, 2008 at 01:28:22PM +0200, Alexander Leidinger wrote: Quoting Nate Eldredge [EMAIL PROTECTED] (from Tue, 12 Aug 2008 23:52:35 -0700 (PDT)): Hi folks, I recently tried to run a Linux binary of Maple (commercial math software) on my FreeBSD 7.0-RELEASE/amd64 box, and the machine rebooted. I tried it again while watching the console, and no panic message appeared to be produced. Does anyone have any ideas on how to debug problems of this nature? I realize I may not be able to get Maple to work, but in any case the system should not die like this, so I can at least try to fix that bug. Incidentally, is it possible to run kdb with a USB keyboard? Hitting Ctrl-Alt-Esc gives me the kdb prompt, but I can't type, so I can do nothing except hit the power button. I do have hint.atkbd.0.flags=0x1 in /boot/device.hints. Unfortunately I don't have a PS/2 keyboard on hand, though I can try and get a hold of one if all else fails. A guess out of my cristallball: That's one of the cases which happen if you run a linux program without branding it as a linux program first. People tend to think it is not needed, but in some rare circumstances it just causes what you see, a reboot. So go and identify all binaries (IMPORTANT: but not the libraries!), e.g. with the file(1), and use brandelf -t Linux on those programs. That would be an enormous local hole, assuming an native FreeBSD binary may cause system crash. I actually doubt that non-branded elf binary ever start, due to unsatisfied dynamic dependencies. You see this behavior only for static binaries. In the non-branded case the image activator takes the FreeBSD image and unfortunately there's a common syscall in linux which matches the syscall number in FreeBSD which causes the reboot (IIRC reboot syscall, do we have something like this?). It's not a system crash (kernel panic), it's a real reboot. AFAIR this also only works if you run the program as root. So... There is indeed a reboot syscall, #55: /usr/include/sys/sycall.h: #define SYS_reboot 55 -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
tilt/horizontal scroll support
I have the following mouse: http://www.logitech.com/index.cfm/partners/system_builders_integrators/products/mice/devices/3141cl=gb,en# It has Tilt Wheel Plus Zoom™ technology, i.e. its scroll wheel can be tilted left and right. Currently it perfectly works as 3 buttons + wheel mouse, but tilting action does not cause any effect (in xev). This is some debug output from ums driver: ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/27.20, addr 2, iclass 3/1 ums0: 8 buttons and Z dir. ums_attach: sc=0xff004d747400 ums_attach: X 8/8 ums_attach: Y 16/8 ums_attach: Z 24/8 ums_attach: B1 0/1 ums_attach: B2 1/1 ums_attach: B3 2/1 ums_attach: B4 3/1 ums_attach: B5 4/1 ums_attach: B6 5/1 ums_attach: B7 6/1 ums_attach: B8 7/1 Here's how normal/vertical scrolling of the wheel is reported by ums (one scroll forward and one scroll backward): ums_intr: sc=0xff006b502400 status=0 ums_intr: data = 00 00 00 ff 00 ums_intr: x:0 y:0 z:1 t:0 buttons:0x0 ums_intr: sc=0xff006b502400 status=0 ums_intr: data = 00 00 00 01 00 ums_intr: x:0 y:0 z:-1 t:0 buttons:0x0 As expected value in the 4th byte (data[3]) is interpreted as z-axis movement (and seems to always be +1/-1). Here's how tilting of the wheel is reported (tilted the wheel, held it for some time and then released): ums_intr: sc=0xff004d747400 status=0 ums_intr: data = 00 00 00 00 01 ums_intr: x:0 y:0 z:0 t:0 buttons:0x0 ums_intr: sc=0xff004d747400 status=0 ums_intr: data = 00 00 00 00 01 ums_intr: x:0 y:0 z:0 t:0 buttons:0x0 ums_intr: sc=0xff004d747400 status=0 ums_intr: data = 00 00 00 00 01 ums_intr: x:0 y:0 z:0 t:0 buttons:0x0 ums_intr: sc=0xff004d747400 status=0 ums_intr: data = 00 00 00 00 00 ums_intr: x:0 y:0 z:0 t:0 buttons:0x0 It seems that tilting is reported by value in the 5th byte (data[4]), it has hardware auto-repeat and end of tilting is reported by all-zeroes data. Currently, it seems, data[4] is completely ignored. I would like to get tilting to work as horizontal scrolling in X, using SysMouse protocol. As I understand currently our sysmouse(4) protocol doesn't provide for tilting data (there is no field for it in the packet structure), and Xorg sysmouse driver does not have any support for tilting either. So now I have two questions. 1. What would be the best way to each ums about the tilt capability of this mouse? Is there some generic way to detect it or maybe logitech-specific way or some model-specific quirk is required? 2. What would be the best way to pass tilting data to consumers? I see two possibilities: A) map data[4] to some extended button value (do it in ums driver), e.g. to button 6 and button 7; B) it seems that dz value is always 1 or -1, amount of scrolling affects number of mouse events, but abs(dz) is always 1; if this is really always true, then tilting could be piggy-backed onto dz as +2/-2 value (or some such) and then Xorg sysmouse driver could be taught to interpret such values as special button presses (similarly to how vertical scrolling is handled in it). Thank you in advance for advices and opinions. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tilt/horizontal scroll support
On Wed, Aug 13, 2008 at 06:41:45PM +0300, Andriy Gapon wrote: I have the following mouse: http://www.logitech.com/index.cfm/partners/system_builders_integrators/products/mice/devices/3141cl=gb,en# ... So now I have two questions. 1. What would be the best way to each ums about the tilt capability of this mouse? Is there some generic way to detect it or maybe logitech-specific way or some model-specific quirk is required? 2. What would be the best way to pass tilting data to consumers? I see two possibilities: A) map data[4] to some extended button value (do it in ums driver), e.g. to button 6 and button 7; B) it seems that dz value is always 1 or -1, amount of scrolling affects number of mouse events, but abs(dz) is always 1; if this is really always true, then tilting could be piggy-backed onto dz as +2/-2 value (or some such) and then Xorg sysmouse driver could be taught to interpret such values as special button presses (similarly to how vertical scrolling is handled in it). Well, perhaps the best way is to teach sysmouse about horizontal scrolling and then add a quirk WRT your mouse ? sysmouse(4) really needs to grow horizontal scrolling since nowadays every mouse has it. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging reboot with Linux emulation
On Wed, 13 Aug 2008, Kostik Belousov wrote: Then, the issue of mixing our reboot(2)/linux fcntl(2) is irrelevant. The original reporter said that system just rebooted, and I believe that filesystems where not synced and not unmounted properly. Our reboot(2) does not have flag combination that could cause such behaviour, I think. You are right, file systems were not unmounted, and I doubt that they were synced either. They had to be fscked when the system came back up. Also, I doubt that the program being run is statically linked or run by root. Confirmation ? I did not run it as root. Sorry, I should have said that before. It is a little hard to trace their maze of shell scripts to figure out which binary was being run, but if I am looking at the right one, it is dynamically linked and branded SVR4. I will make sure later today. Overall, this looks like a nasty bug, hopefully in the linuxolator. Indeed. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: If not the force, what should I use?
On Wed, 2008-08-13 at 08:00 -0400, Mike Meyer wrote:
stop If the service is to be started as specified by
rc.conf(5), stop the service. This should check that the
service is running and complain if it is not. If
forcestop is given, ignore the rc.conf(5) check and
attempt to stop.
I don't have time to do it now, but will later if no one says they have
mike
Why should it complain? If I've asked it to stop a service, and the
service is not running, that's not an error or complaint - its the
desired outcome.
The only thing that perhaps should be warned about is when you attempt
to stop a service that is not configured to start, but has been started
using {one,force}start, it will not be stopped unless you use the
equivalent {one,force}stop. Personally, I think that's fine, but it
certainly could annoy.
One of the things that appeals to me with FreeBSD is how sane
everything is, and how unobtrusive and simple it is, especially
compared to the noisy, obtrusive SysV init that you find on most Linux
distros - you know the kind I mean, one program to add a service to a
run level, one program to list the services in a run level... FreeBSD
allows you to do all that stuff, with simple commands like vi, grep etc.
Cheers
Tom
signature.asc
Description: This is a digitally signed message part
Re: If not the force, what should I use?
On Wed, 13 Aug 2008 17:58:39 +0100 Tom Evans [EMAIL PROTECTED] wrote: On Wed, 2008-08-13 at 08:00 -0400, Mike Meyer wrote: stop If the service is to be started as specified by rc.conf(5), stop the service. This should check that the service is running and complain if it is not. If forcestop is given, ignore the rc.conf(5) check and attempt to stop. Why should it complain? Because somebody quoted it out of context to justify a completely bogus assumption about what was and wasn't a bug. The bug in question is that the man page should note that force(start|stop|restart) should ignore any precmd problems as well as the setting in rc.conf, as that is what the tools provided by rc.subr do. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging reboot with Linux emulation
Quoting Kostik Belousov [EMAIL PROTECTED] (from Wed, 13 Aug 2008 18:45:01 +0300): On Wed, Aug 13, 2008 at 05:28:05PM +0200, Alexander Leidinger wrote: The linuxulator is not involved, as there's no branding it is not invoked. The same will happen if the linxulator is not in the kernel. Ok, if the case is confirmed, I very much want to get such binary into my hands. I.e., unbranded statically linked ELF binary running which causes immediate reboot without normal kernel shutdown sequence. You could try /compat/linux/sbin/ldconfig without a brand. If it uses fcntl, it should trigger the problem. Bye, Alexander. -- Some people have no respect for age unless it's bottled. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
VMWare 3 port on FreeBSD 7 STABLE
Hi: I am trying to run VMware 3 port from /usr/ports/emulators/vmware3 on FreeBSD 7.0 STABLE. I did a make install from the /usr/ports as root and the build and install went fine. It installed Linux Base FC4 and then installed VMWare 3. However, whenever I try to startup vmware, I get an error that /dev/vmmon cannot be found. The error is: Could not open /dev/vmmon: No such file or directory. Please make sure that the kernel module `vmmon' is loaded. Failed to initialize monitor device. Linprocfs is mounted on /compat/linux/proc. I also ran the /usr/local/rc.d/vmware.sh start and it reported that all modules are already loaded. kldstat reveals that vmmon_smp.ko is indeed loaded. Based on some research, I found this issue reported in FreeBSD 5.4; I believe the same is at work here. I am running on a DELL SMP hardware (DELL Precision 530 Workstation). http://lists.freebsd.org/pipermail/freebsd-bugs/2005-May/012725.html Any way to fix this issue in FreeBSD 7? Is it due to the SMP hardware? Can I make VMWare belive that it is running on Uniprocessor hardware? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Ptrace in FreeBSD
someone could help me use the PT_SETREGS on FreeBSD? I get the value of registers with PT_GETREGS normal, but when I make the modification and the use PT_SETREGS not working! could show me an example? _ Instale a Barra de Ferramentas com Desktop Search e ganhe EMOTICONS para o Messenger! É GRÁTIS! http://www.msn.com.br/emoticonpack___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ptrace in FreeBSD
ANDERSON EDUARDO wrote: someone could help me use the PT_SETREGS on FreeBSD? I get the value of registers with PT_GETREGS normal, but when I make the modification and the use PT_SETREGS not working! could show me an example? _ Instale a Barra de Ferramentas com Desktop Search e ganhe EMOTICONS para o Messenger! É GRÁTIS! http://www.msn.com.br/emoticonpack___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] Would be more appropriate if you showed us the snippet of code that's causing trouble. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ptrace in FreeBSD
ANDERSON EDUARDO wrote: someone could help me use the PT_SETREGS on FreeBSD? I get the value of registers with PT_GETREGS normal, but when I make the modification and the use PT_SETREGS not working! could show me an example? _ Instale a Barra de Ferramentas com Desktop Search e ganhe EMOTICONS para o Messenger! É GRÁTIS! http://www.msn.com.br/emoticonpack___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] Would be more appropriate if you showed us the snippet of code that's causing trouble. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: If not the force, what should I use? (Was: FreeBSD in Business (was Re: Idea for FreeBSD))
On Wed, Aug 13, 2008 at 1:40 AM, Vincent Hoffman [EMAIL PROTECTED] wrote:
Jonathan McKeown wrote:
On Tuesday 12 August 2008 17:51:32 Mike Meyer wrote:
On Tue, 12 Aug 2008 17:10:22 +0200 Adrian Penisoara
Ok, given that you 1) want to have both this service if it's
part of our normal runtime and this service even if it's not
part of our normal runtime as script commands, and that 2)
without a prefix gets the if it's part of our normal runtime
meaning, as we want the user to have to explicitly say Yes, I know
this looks odd, but I know what I'm doing so do it anyway to get the
even if it's not part of our normal runtime behavior, then what
would you have us use instead of force?
People keep talking about forcestart.
Unless I'm misunderstanding things horribly, forcestart does exactly that
- forces the service to start regardless of any error that may occur.
The better option for starting something as a one-off (not enabled in
rc.conf) is mnemonically named onestart - which only ignores the rcvar but
still fails on any other error.
And yes, I like having onestart/onestop distinguished from start/stop.
I believe it forces a start even though its not actually enabled (in
rc.conf) rather than regardless of errors.
If you really want a command line of onestart/onestop install the
sysutils/bsdadminscripts port which has a script called rconestart and
rconestop which do exactly that ;)
From /etc/rc.subr:
# run_rc_command argument
# Search for argument in the list of supported commands, which is:
# start stop restart rcvar status poll ${extra_commands}
# If there's a match, run ${argument}_cmd or the default method
# (see below).
#
# If argument has a given prefix, then change the operation as follows:
# Prefix Operation
# -- -
# fastSkip the pid check, and set rc_fast=yes
# force Set ${rcvar} to YES, and set rc_force=yes
# one Set ${rcvar} to YES
Further in the file:
case $rc_arg in
fast*) # fast prefix; don't check pid
rc_arg=${rc_arg#fast}
rc_fast=yes
;;
force*) # force prefix; always run
rc_force=yes
_rc_prefix=force
rc_arg=${rc_arg#${_rc_prefix}}
if [ -n ${rcvar} ]; then
eval ${rcvar}=YES
fi
;;
one*) # one prefix; set ${rcvar}=yes
_rc_prefix=one
rc_arg=${rc_arg#${_rc_prefix}}
if [ -n ${rcvar} ]; then
eval ${rcvar}=YES
fi
;;
esac
Which, if I follow things, means:
** /etc/rc.d/$script faststart won't check for existing PID files
or already running apps, and just run $script, but still checks if
$script_enable=yes is in /etc/rc.conf.
** /etc/rc.d/$script onestart sets $script_enable=yes internally,
regardless of what is in rc.conf, and runs $script. All other checks
are done as per normal.
** /etc/rc.d/$script forcestart runs $script, regardless of what's
in rc.conf, the status of the PID file, or the existence of an already
running daemon.
What most people in this thread are looking for is onestart.
--
Freddie Cash
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
