Re: kern/98388: [ata] FreeBSD 6.1 - WDC WD1200JS SATA II disks are seen as older SATA
Andrey V. Elsukov wrote: sam wrote: FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Tue Aug 12 13:54:27 MSD 2008root@:/usr/obj/usr/src/sys/GENERIC i386 | please, any solution ? Probably speed is limited via jumpers on your hard drive. http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=1409&p_created=#jumper tried it without results /Vladimir Ermakov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/98388: [ata] FreeBSD 6.1 - WDC WD1200JS SATA II disks are seen as older SATA
sam wrote: FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Tue Aug 12 13:54:27 MSD 2008 root@:/usr/obj/usr/src/sys/GENERIC i386 | please, any solution ? Probably speed is limited via jumpers on your hard drive. -- WBR, Andrey V. Elsukov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/98388: [ata] FreeBSD 6.1 - WDC WD1200JS SATA II disks are seen as older SATA
[EMAIL PROTECTED] wrote: I bought an ASUS motherboard with onboard SATA II controller. I attached 2 HDs SATA II but when I run dmesg I notice that my system sees them as normal older SATA 150 instead of SATA 300. Is there any suggestion to solve this problem ? Have a nice day. --dmesg output--- Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-RELEASE-p1 #0: Fri Jun 2 15:41:03 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AMOS-SMP WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) D CPU 3.00GHz (3000.38-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf62 Stepping = 2 Features=0xbfebfbff Features2=0xe43d,> AMD Features=0x2000 AMD Features2=0x1 Cores per package: 2 real memory = 2138701824 (2039 MB) avail memory = 2087825408 (1991 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 atapci0: port 0xc800-0xc807,0xc400-0xc403,0xc000-0xc007,0xb800-0xb803,0xb400-0xb40f irq 19 at device 4.0 on pci1 ata2: on atapci0 ata3: on atapci0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci1 ata1: on atapci1 atapci2: port 0xa800-0xa807,0xa400-0xa403,0xa000-0xa007,0x9800-0x9803,0x9400-0x940f irq 17 at device 31.2 on pci0 atapci2: failed to enable memory mapping! ata4: on atapci2 ata5: on atapci2 acd0: DVDROM at ata0-master UDMA33 ad8: 114473MB at ata4-master SATA150 GEOM_MIRROR: Device gm0 created (id=2415013281). GEOM_MIRROR: Device gm0: provider ad8 detected. ad10: 114473MB at ata5-master SATA150 GEOM_MIRROR: Device gm0: provider ad10 detected. SMP: AP CPU #1 Launched! GEOM_MIRROR: Device gm0: provider ad10 activated. GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. GEOM_MIRROR: Device gm0: rebuilding provider ad8. Trying to mount root from ufs:/dev/mirror/gm0s1a em0: link state changed to UP hello my similar problem motherboard with the Intel G31 Express Chipset |# output 'dmesg' (|partially|) atapci1: port 0xc880-0xc887,0xc800-0xc803,0xc480-0xc487,0xc400-0xc403,0xc080-0xc08f irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ad7: 476940MB at ata3-slave SATA150 # atacontrol cap ad7 Protocol Serial ATA II device model WDC WD5000AAKS-00YGA0 serial number WD-WCAS87395070 firmware revision 12.01C02 cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 976773168 sectors dma supported overlap not supported Feature Support EnableValue Vendor write cacheyes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 0/0x00 automatic acoustic management yes no 254/0xFE128/0x80 # atacontrol mode ad7 current mode = SATA150 # output 'pciconf -lv' (|partially|) [EMAIL PROTECTED]:0:31:2:class=0x01018f card=0x26391019 chip=0x27c08086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller' class = mass storage subclass = ATA # uname -a FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Tue Aug 12 13:54:27 MSD 2008 root@:/usr/obj/usr/src/sys/GENERIC i386 | please, any solution ? /Vladimir Ermakov ___ 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]"
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]"
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]"
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]"
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]"
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. 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: 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 > > signature.asc Description: This is a digitally signed message part
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: 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/3141&cl=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]"
tilt/horizontal scroll support
I have the following mouse: http://www.logitech.com/index.cfm/partners/system_builders_integrators/products/mice/devices/3141&cl=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: 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]"
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
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
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: 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: 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 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
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: 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: 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: 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: 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? (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]"
