Re: AuthenticAMD, cpufreq and SunFire X2200
Jeremy Chadwick wrote: On Fri, Jul 11, 2008 at 09:40:11PM +0300, Danny Braniss wrote: On Fri, Jul 11, 2008 at 03:57:00PM +0300, Danny Braniss wrote: Hi, I'm trying to find out why there is no frequency info. ie: sunfire> sysctl dev.cpu.0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.P001 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% so any help/insight is most welcome. BTW, its 7.0-stable Is the cpufreq device in your kernel config? Do the SunFire X2200's provide any sort of frequency data in their ACPI tables? Are there BIOS settings which are relevant to this board enabling Cool'n'Quiet or anything else of that nature (thus inducing the use of powernow(4))? device is configured: config -x /boot/kernel/kernel | grep -a cpufreq device cpufreq the BIOS has powernow enabled (or something similar). the kernel prints: ... powernow0: on cpu0 powernow0: STATUS: 0x3106120806120212 powernow0: STATUS: maxfid: 0x12 powernow0: STATUS: maxvid: 0x06 ... the same is repeated for cpu 1,2,3,4,5,6 & 7 - yes it's a dual quad. which seem to indicate that it didn't like the ACPI data it got - this by comparing with other amd's that do report correctly. as to the question '...any sort of frequency data in their ACPI tables' I tried to 'read' the ACPI data, but didn't understand the language :-( First and foremost, please don't remove the mailing list from the CC line; others need to know the technical details. I don't have an answer for you, however. Nate Lawson might have some ideas as to what's going on. A verbose boot may be needed. I've CC'd Nate here. Looks like someone should check the AMD datasheets and/or acpidump. I'm currently not an active committer though. -- Nate ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] enhance powerd(8) to handle max temperature
Warner Losh wrote: > From: Nate Lawson <[EMAIL PROTECTED]> > Subject: Re: [patch] enhance powerd(8) to handle max temperature > Date: Thu, 02 Aug 2007 10:08:33 -0700 > >> M. Warner Losh wrote: >>> I keep getting the system shutting down on my HP by FreeBSD because >>> the temperature exceeds the _CRT value. Maybe there's something wrong >>> with my values, since it happens a lot: >>> >>> hw.acpi.thermal.min_runtime: 0 >>> hw.acpi.thermal.polling_rate: 10 >>> hw.acpi.thermal.user_override: 0 >>> hw.acpi.thermal.tz0.temperature: 0.0C >>> hw.acpi.thermal.tz0.active: -1 >>> hw.acpi.thermal.tz0.passive_cooling: 1 >>> hw.acpi.thermal.tz0.thermal_flags: 0 >>> hw.acpi.thermal.tz0._PSV: 90.0C >>> hw.acpi.thermal.tz0._HOT: -1 >>> hw.acpi.thermal.tz0._CRT: 94.0C >>> hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 >>> >>> Note: temperature is always 0.0C. >>> >>> What can I do to help my situation, if I really want the kernel doing >>> the cooling? >> Your embedded controller is timing out. Thus you're getting a bogus >> value for _TMP. >> >> Those settings for _CRT appear correct. It's the "measured" temperature >> that is wrong. > > So how do I track down the problem? I'm tired of the system just > shutting down when I'm building OOO or even something simpler like > doing a buildworld... You do what's #1 on my list, which is rewrite the EC driver event model (yet again) and figure out if it's possible to automatically detect which workarounds are needed. Linux requires you to specify boot-time flags to select polled or event-driven work. -Nate ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] enhance powerd(8) to handle max temperature
M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Nate Lawson <[EMAIL PROTECTED]> writes: > : Hajimu UMEMOTO wrote: > : >>>>>> On Mon, 30 Jul 2007 23:31:33 +0200 > : >>>>>> Pietro Cerutti <[EMAIL PROTECTED]> said: > : > gahr> My patch is really just a first draft that I wrote in order to have > : > gahr> feedbacks on the general idea to implement a temperature controlling > : > gahr> system inside powerd, and doesn't implement hysteresis as you > noted, and > : > gahr> your feedback is that it's not a good idea, which I respect. > : > > : > It is rather backward, IMHO. I did implement a passive cooling > : > feature as an enhancement of powerd(8) like you did, during initial > : > phases. Then, I implemented it in our kernel as a result. > : > : I'll take a look at your patch. Umemoto-san is right in that you really > : want the kernel to control cooling. What happens if powerd dies/hangs > : and your system burns up? Passive cooling is often a last resort to > : keep the system from overheating. > > I keep getting the system shutting down on my HP by FreeBSD because > the temperature exceeds the _CRT value. Maybe there's something wrong > with my values, since it happens a lot: > > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 0.0C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 1 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: 90.0C > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 94.0C > hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 > > Note: temperature is always 0.0C. > > What can I do to help my situation, if I really want the kernel doing > the cooling? Your embedded controller is timing out. Thus you're getting a bogus value for _TMP. Those settings for _CRT appear correct. It's the "measured" temperature that is wrong. -Nate ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] enhance powerd(8) to handle max temperature
Hajimu UMEMOTO wrote: >> On Mon, 30 Jul 2007 23:31:33 +0200 >> Pietro Cerutti <[EMAIL PROTECTED]> said: > gahr> My patch is really just a first draft that I wrote in order to have > gahr> feedbacks on the general idea to implement a temperature controlling > gahr> system inside powerd, and doesn't implement hysteresis as you noted, and > gahr> your feedback is that it's not a good idea, which I respect. > > It is rather backward, IMHO. I did implement a passive cooling > feature as an enhancement of powerd(8) like you did, during initial > phases. Then, I implemented it in our kernel as a result. I'll take a look at your patch. Umemoto-san is right in that you really want the kernel to control cooling. What happens if powerd dies/hangs and your system burns up? Passive cooling is often a last resort to keep the system from overheating. -Nate ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Laptop won't power off
Pietro Cerutti wrote: > On 2/23/07, Moore, Robert <[EMAIL PROTECTED]> wrote: >> On linux, the compiler must be generated with the "flex-old" package, I >> don't know if there is anything like it for bsd. We are looking at >> making changes to support newer versions of flex/bison. > > Bob, > we don't have a flex-old package, so we'll have to wait till the new > version becomes available. By the way, the asl code compiles without > warning using the iasl apt package on Ubuntu, so the problem is > definitely not with the asl. We take care of the lex issue when we import acpi-ca. Please wait until we've done the import and use the iasl in the base system. Your issue is definitely not ASL-related. > >> Power problems: sorry, not the expert in this area. > For everyone else: > By disabling SMP I could get to a stage where, at the end of the > shutdown process, this message is displayed (with SMP enabled, the > screen turns black and I can't read messages): > > AcpiEnterSleepStatePrep failed - AE_NOT_FOUND > > So, any ideas on that? The \_S5 object is missing? Can you and the reboot failure people try: sysctl debug.acpi.do_powerstate=0 -Nate >> > -Original Message- >> > From: Pietro Cerutti [mailto:[EMAIL PROTECTED] >> > Sent: Thursday, February 22, 2007 3:46 PM >> > To: Moore, Robert >> > Cc: Nate Lawson; [EMAIL PROTECTED]; freebsd-hackers@freebsd.org; >> > [EMAIL PROTECTED] >> > Subject: Re: Laptop won't power off >> > >> > On 2/23/07, Moore, Robert <[EMAIL PROTECTED]> wrote: >> > > Not likely to be cause of power off problems >> > Ok, any other ideas? >> > >> > > >> > > Compiler runs on linux, should run on bsd. >> > If you're talking about this one: >> > http://www.intel.com/technology/iapc/acpi/downloads/acpica-unix- >> > 20061109.tar.gz >> > it doesn't compile neither on Debian (Kernel 2.6.12) nor on FreeBSD >> > (6.2) >> > >> > > make >> > bison -v -d -y -pAslCompiler aslcompiler.y >> > aslcompiler.y:3083.37-48: warning: rule never reduced because of >> > conflicts: OptionalResourceType: /* empty */ >> > >> > cp y.tab.c aslcompilerparse.c >> > cp y.tab.h aslcompiler.y.h >> > cc -Wall -O2 -Wstrict-prototypes -D_LINUX -DACPI_ASL_COMPILER >> > -I../include-c -o aslcompilerparse.o aslcompilerparse.c >> > flex -i -PAslCompiler -oaslcompilerlex.c aslcompiler.l >> > cc -Wall -O2 -Wstrict-prototypes -D_LINUX -DACPI_ASL_COMPILER >> > -I../include-c -o aslcompilerlex.o aslcompilerlex.c >> > aslcompiler.l: In function 'comment': >> > aslcompiler.l:847: error: 'yytext_ptr' undeclared (first use in this >> > function) >> > aslcompiler.l:847: error: (Each undeclared identifier is reported only >> > once >> > aslcompiler.l:847: error: for each function it appears in.) >> > make: *** [aslcompilerlex.o] Error 1 >> > > -- Nate ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Laptop won't power off
Pietro Cerutti wrote: > Hi Lists, > first off, sorry for cross-posting, but I'm not subscribed to > freebsd-acpi@, so acpi guys please CC me. > > The problem here is that my laptop doesn't power off when issuing halt > -p or shutdown -p now. > This is the machine: > http://www.msicomputer.com/NB/product_spec.asp?model=MS-1034_(Core2_Duo) > > Any hint is greatly appreciated! > CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (2000.15-MHz > 686-class CPU) > Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 > > Features=0xbfebfbff > > Features2=0xe3bd,CX16,,> > AMD Features=0x2010 > AMD Features2=0x1 > Cores per package: 2 Try disabling SMP so only 1 core is running. Build a kernel without SMP option or at loader prompt type: set hint.apic.0.disabled="1" -- Nate ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi-target and the buffer cache
[mailing list changed to [EMAIL PROTECTED] Eric Anderson wrote: Nate Lawson wrote: Scott Long wrote: Eric Anderson wrote: Nate Lawson wrote: Agree 100%. While having it in usermode means there are boundary crossings that increase per-transaction latency, the actual bulk data transfer is via zero-copy IO and you should be able to exceed the data transfer rates of several 10K RPM drives on decent hardware. Ok, great.. Now, will scsi_target work ok with raw devices, or only files? (although I'm not sure theres all that much difference really). You can write your userland code to use whatever files or devices you want. Are you talking about the scs_target.c code in /usr/share/examples? That's just a skeletal example that you can use as a starting point for your own work. No, it's not just a skeletal example. You can point it at a raw device as the backing store file and it will work as a block device (i.e. RBC command set). It has been tested as working at least moderately fast over SCSI, FC, and firewire. I'm finally getting around to playing with this, and I'm having some problems. First, I can't seem to make one isp card in target mode and the other an initiator. I've messed with adding the following to loader.conf: hint.isp.0.role="initiator" hint.isp.1.role="target" that still doesn't show my currently connected fiber channel devices on the initiator side. I've tried a few different kernel options, currently I have: options ISP_TARGET_MODE=1 device targ I've also tried just: options ISP_TARGET_MODE and that doesn't seem to allow me to select one either. hints aren't needed. Here's an intro on how to use it: http://root.org/~nate/freebsd/scsi/README.targ The same card is in target or initiator mode based on the scsi_target user program. When it's running, target mode is enabled. Anyhow, I've compiled scsi_target (from /usr/share/examples/scsi_target), and tried to run it using a 20gb file as the target, and still I can't seem to get it working. Is there a doc somewhere I need to read? Also - as a side note, the Makefile for scsi_target seems like it's missing a path variable in order to do a make install, but that's not a real issue. There was some debate when I imported it whether to make it an example or usr.sbin. Given the lack of updates (i.e. ki_sig or whatever), I probably should have put it somewhere else. -- Nate ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi-target and the buffer cache
Scott Long wrote: Eric Anderson wrote: Nate Lawson wrote: Agree 100%. While having it in usermode means there are boundary crossings that increase per-transaction latency, the actual bulk data transfer is via zero-copy IO and you should be able to exceed the data transfer rates of several 10K RPM drives on decent hardware. Ok, great.. Now, will scsi_target work ok with raw devices, or only files? (although I'm not sure theres all that much difference really). You can write your userland code to use whatever files or devices you want. Are you talking about the scs_target.c code in /usr/share/examples? That's just a skeletal example that you can use as a starting point for your own work. No, it's not just a skeletal example. You can point it at a raw device as the backing store file and it will work as a block device (i.e. RBC command set). It has been tested as working at least moderately fast over SCSI, FC, and firewire. -- Nate ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi-target and the buffer cache
Scott Long wrote: Eric Anderson wrote: Nate Lawson wrote: Eric Anderson wrote: I'm curious about whether a target mode device would use the buffer cache or not. Here's a scenario: Host A: has fibre channel host adapter, in target mode, large memory pool, and another fiber channel host adapter connecting to fibre channel block device. Host B: Fibre channel host adapter, connecting to Host A. 'sees' the target mode block device created by Host A. Will Host A use the buffer cache to cache blocks between the real block device, and the shared target mode device? What about if Host A put a filesystem on the block device, created a single file the size of the filesystem, and shared that filesystem via a target mode device to Host B? What I'm wanting is a box (FreeBSD?) that can be placed between a fibre channel block device (like a RAID array), and a fibre channel host using that block device, and act as a block cache for that device, using the FreeBSD's memory. If it had a significant amount of memory, this could be very useful. If you use the example scsi_target usermode (usr/share/examples/scsi_target), then the buffer cache will be used since its reads/writes are from usermode like normal. If you don't want that behavior, you can set O_DIRECT in the open() call of the backing store file. If you chose to modify the kernel side, you'd have to make sure your accesses were through the VOP layer and then it would be cached. You should check to be sure the target mode performance meets your expectations also. I guess I would be using the user mode tool, unless there's another way? Your comment on performance also makes me a little worried about that now - do you think I would see a large performance hit? Thanks! Eric The way the target mode stack works in FreeBSD is that the kernel provides some of the basic services, but the actual target emulator is meant to live in userland. The userland program responds to events from the kernel via the select interface. This generally works pretty well. However, it does mean that control has to cross the kernel-userland boundary at least once for every event. What I'd suggest doing is prototyping your target emulator in userland and evaluating the performance there, and then moving it to the kernel if you _really_ need more performance. Agree 100%. While having it in usermode means there are boundary crossings that increase per-transaction latency, the actual bulk data transfer is via zero-copy IO and you should be able to exceed the data transfer rates of several 10K RPM drives on decent hardware. -- Nate ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi-target and the buffer cache
Eric Anderson wrote: I'm curious about whether a target mode device would use the buffer cache or not. Here's a scenario: Host A: has fibre channel host adapter, in target mode, large memory pool, and another fiber channel host adapter connecting to fibre channel block device. Host B: Fibre channel host adapter, connecting to Host A. 'sees' the target mode block device created by Host A. Will Host A use the buffer cache to cache blocks between the real block device, and the shared target mode device? What about if Host A put a filesystem on the block device, created a single file the size of the filesystem, and shared that filesystem via a target mode device to Host B? What I'm wanting is a box (FreeBSD?) that can be placed between a fibre channel block device (like a RAID array), and a fibre channel host using that block device, and act as a block cache for that device, using the FreeBSD's memory. If it had a significant amount of memory, this could be very useful. If you use the example scsi_target usermode (usr/share/examples/scsi_target), then the buffer cache will be used since its reads/writes are from usermode like normal. If you don't want that behavior, you can set O_DIRECT in the open() call of the backing store file. If you chose to modify the kernel side, you'd have to make sure your accesses were through the VOP layer and then it would be cached. You should check to be sure the target mode performance meets your expectations also. -- Nate ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: enable acpi
Dinesh Nair wrote: On 03/31/05 20:51 John Baldwin said the following: The problem is that the taskqueue_swi in 4.x doesn't have a thread context that can be slept on via tsleep(). The fix would be to create a kthread in which to run the ACPI tasks. 4.x already has one such kthread for the taskqueue_thread taskqueue that you could use as a reference if you wish to do this yourself. thanx for the pointer, john. with your explanation, the fix was simple. since applying this, it's not paniced in over 24 hours of continuous running. patch attached. i'll also raise a PR for this. Don't bother, I already committed it. -- Nate ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Driver for Thinkpad Hotkeys.
Takanori Watanabe wrote: Hi, I updated ThinkPad Hotkey driver so that it can * Read Brightness * Read Volume * Read Mute status * Read Keylight status * AccessIBM, Zoom Screen(Fn+Sp) toggle. ToDo lists * Set Brightness * Set Volume * Bluetooth attach/detach. * Userland worker. These features will come Real Soon Now. * Wireless LAN indicator Will be take more time. I wrote for ThinkPad X31, but it may work on some other ThinkPad X,R,T,S series. Enjoy! http://www.init-main.com/acpi_tpkey/ Thanks for working on this. After 5.3-RELEASE, I think it would be good to import it. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 64 bit endian routines
Date: Thu, 27 Feb 2003 21:17:13 -0800
From: Marcel Moolenaar <[EMAIL PROTECTED]>
To: Nate Lawson <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: 64 bit endian routines
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
On Thu, Feb 27, 2003 at 08:45:44PM -0800, Nate Lawson wrote:
> Both scsi and geom implement unaligned access functions
that perform byte > ordering. I never intended to supplant
them with __bswap*(). What I want > is for machine/endian.h
to have functions that provide 16-64 bit endian > conversions
in both aligned and unaligned access forms. After these
functions > are there, I'd like us to unify use of them and
remove driver-private > versions. > > Is this more clear
now?
Crystal :-)
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
Heh, I hope I didn't sound too forceful. It was just a straightforward
question, not a diatribe. :)
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: 64 bit endian routines
Date: Thu, 27 Feb 2003 20:18:49 -0800
From: Marcel Moolenaar <[EMAIL PROTECTED]>
To: Mike Barcroft <[EMAIL PROTECTED]>
Cc: Nate Lawson <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: 64 bit endian routines
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
On Thu, Feb 27, 2003 at 10:30:58PM -0500, Mike Barcroft wrote:
> Most of these could probably be implemented in terms of the __bswap*()
> functions in , except for vendor sources like
> openssl, and htonl and ntohl which already are. I'm not sure if there
> would be an advantage to moving the geom byte ordering functions to
> (I guess phk didn't either).
The geom functions serve a primary purpose of dealing with random
alignment of fields. The endianness has been added later, so they
now serve a dual function. Do not unify them with byte-order only
functions.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
Both scsi and geom implement unaligned access functions that perform byte
ordering. I never intended to supplant them with __bswap*(). What I want
is for machine/endian.h to have functions that provide 16-64 bit endian
conversions in both aligned and unaligned access forms. After these functions
are there, I'd like us to unify use of them and remove driver-private
versions.
Is this more clear now?
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
64 bit endian routines
First, the simple question: what's the simplest cross-platform way of implementing scsi_ulto4b and scsi_4btoul (/sys/cam/scsi/scsi_all.h) for 64 bit values. GEOM (/sys/geom/geom_enc.c) implements it via a 64 bit cast in g_enc_le8. Is this the best current way? Second, anyone done work on unifying our various byte ordering macros? Besides htonl and ntohl, there are scsi_*ul*, g_enc_*, openssl/aes_locl.h, machine/endian.h, arpa/nameser.h, and I'm sure there are others. Perhaps the best thing is to add macros similar to geom_enc_* to machine/endian.h. Any ideas? Thanks, Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/sys/i386/i386 i386-gdbstub.c
Followups to hackers@. For those just tuning in, the patch under discussion is gdb.diff at: http://www.root.org/~nate/freebsd/ On Tue, 17 Dec 2002, Alfred Perlstein wrote: > I'd appreciate the default being such that when one quits gdb the kernel > begins running again instead of hanging for what seems like forever. The procedure now to get back to kernel running with a shared serial console/gdb line is gdb detach, quit, fire up terminal emulator on the serial port, and type "c" to ddb. I'm thinking of combining my patch such that if you enter gdb directly (via the new auto enter mechanism or a kernel option that defaults to GDB on break), doing a detach in gdb detaches and continues. States: "continue""detach" - DDB --- / (break) "gdb" \ running | \ "detach"/ ` GDB --' (break/GDB_DEFAULT) Note that the transitions between GDB and DDB are not available if GDB is entered through the lower half of the loop. I'm open to suggestions on how to implement the lower half from a user's perspective. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: setattr() syscall as proposed by phk
On Sun, 15 Dec 2002 [EMAIL PROTECTED] wrote: > Nate Lawson writes: > >I don't mean to be rude but I doubt the utility of this whole > >plan. dump/restore are done on disk devices which are at least an order > >of magnitude slower than a syscall boundary crossing. Going from 4 > >syscalls to 1 can't make a bit of difference in restore(8) performance. > > You are wrong about restore: restore is done on a mounted filesystem. Heh, you took that too literally. I meant the IO is coming from a tape, disk, or other physical media device where latencies for a 32-64k xfer are usually on the order of 1-10 ms or more. > >So why is this faster? Something is likely slowing namei() down. > > Because 1 syscall and 2 namei calls are faster than 4 syscalls and > four namei calls. Which leaves us back at my previous point which is that something is wrong with caching if 4 namei calls (for the SAME name) are so much slower. A great task would be to examine/test namei(), identify why it's not cached correctly, and fix the underlying problem. The syscall boundary crossing is NOT significant here. -Nate "One hand for your own code, and one hand for the infrastructure". -- phk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Restoring superblock backup?
On Sun, 15 Dec 2002, Andreas Klemm wrote: > On Sun, Dec 15, 2002 at 12:41:58AM -0800, Nate Lawson wrote: > > After the fs has been repaired, the alternate sb is not copied to the > > default sb (currently). > > This doesn't sound valid. It would mean, if your suberblock has > crashed and you use the alternate, then every subsequent fsck > run would fail and need manual operation to use the alternate > superblock. This is indeed the current (bad) behavior, hence my original request for a workaround. I'm working on a patch. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Restoring superblock backup?
On Sat, 14 Dec 2002, Yury Tarasievich wrote: > >On Fri, Dec 13, 2002 at 02:28:00PM -0800, Nate Lawson wrote: > >>I've successfully repaired a fs with the superblock backup at 32. Now how > >>do I copy that backup to the default superblock location? fsck_ffs does > >>NOT automatically do this. > > If FS boundaries are right, one can always try newfs -N, then fsck with -b. > I tried this once and succeeded using superblock copy being really more > distant from FS start. I appreciate the help but you're both answering the wrong question. Go re-read my question above again. The current workaround (as given by mckusick@) is: --- > It used to be that when you ran with an alternate superblock, the > last question asked by fsck is whether you wish to update the > standard superblock. Answering yes would do that update for you. > As it appears that that feature got dropped, you can do the copy > manually using: > >dd if= skip=32 of= seek=16 bs=512 count=16 --- -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: setattr() syscall as proposed by phk
On Sat, 14 Dec 2002, Michael Ranner wrote: > Hi there! > > I have implemented the setattr(), lsetattr() and fsetattr() syscalls for > 4.7 and 5.0. You can review my code on http://www.ranner.jawa.at/freebsd.php. > > Comments and suggestions are welcome. I don't mean to be rude but I doubt the utility of this whole plan. dump/restore are done on disk devices which are at least an order of magnitude slower than a syscall boundary crossing. Going from 4 syscalls to 1 can't make a bit of difference in restore(8) performance. So why is this faster? Something is likely slowing namei() down. However, this should be fixed by improving namei() or whichever subsystem is slowing restore down. Adding new syscalls is not the right answer. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Restoring superblock backup?
On Sat, 14 Dec 2002, Andreas Klemm wrote: > On Fri, Dec 13, 2002 at 02:28:00PM -0800, Nate Lawson wrote: > > I've successfully repaired a fs with the superblock backup at 32. Now how > > do I copy that backup to the default superblock location? fsck_ffs does > > NOT automatically do this. > > It does. With fsck -b 32 you use the alternate super block to repair > the filesystem just in case the superblock in at the usual place is > damaged. After that the filesystem is completely repaired ... > Of course the previously damages superblock ... After the fs has been repaired, the alternate sb is not copied to the default sb (currently). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Restoring superblock backup?
I've successfully repaired a fs with the superblock backup at 32. Now how do I copy that backup to the default superblock location? fsck_ffs does NOT automatically do this. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates
On Thu, 12 Dec 2002, Steve Shorter wrote: > I have been using softupdates on 500G SCSI RAID in production > for about 1 year, no problems. > > $ df /mnt/2d > Filesystem 1K-blocks UsedAvail Capacity Mounted on > /dev/da2d 523577788 470120524 1157104298%/mnt/2d Your luck may soon change. ;-) -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: panic: icmp_error: bad length
On Thu, 12 Dec 2002, Ian Dowse wrote:
> --- ip_fw.c 21 Nov 2002 01:27:30 - 1.131.2.38
> +++ ip_fw.c 12 Dec 2002 00:43:22 -
> @@ -1573,6 +1573,11 @@
> break;
> }
> default:/* Send an ICMP unreachable using code */
> + /* Must convert to host order for icmp_error(). */
> + if (BRIDGED) {
> + NTOHS(ip->ip_len);
> + NTOHS(ip->ip_off);
> + }
> icmp_error(*m, ICMP_UNREACH,
> f->fw_reject_code, 0L, 0);
> *m = NULL;
Since the REJECT case needs several headers in host order, why not put
this there (line 1546), taking care of potential problems in the tcp RST
case?
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel process(thread) in SMP system
On Fri, 6 Dec 2002, Kyunghwan Kim wrote: > I've heard that kernel of RELENG_4 branch is single-threaded, > but can hardly check out if kernel process(thread) like pagedaemon can > run on other cpu concurrently when another cpu is processing an network > interrupt. Using Kernel process(thread) for cpu-bound job in SMP environment > will be beneficial? It there any method to tell which process including > user and kernel process is in kernel mode? -stable can run multiple processes at once but only one can enter the kernel at a time. A network interrupt runs at splnet and the pagedaemon runs with no interupts disabled (and splvm at some parts) so technically they can run concurrently. Still, a user proc can run concurrently with a splnet interrupt and vm_pageout() kern proc. So going to a kern proc has no bearing on your cpu-bound work. Just use multiple user procs (i.e. fork()) and you'll get the most out of your -stable box, given that your computation is divisible. You can tell what procs are doing with "ps axl" or top. If they're running, top shows as CPU0 or 1. Unfortunately, this doesn't tell if it's in kernel mode or not -- you have to use profiling to get an average view of this. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: maxusers and random system freezes
On Wed, 4 Dec 2002, Terry Lambert wrote: > Marc Recht wrote: > > Every now and this I hear people saying (mostly you :)) that some problems > > are KVA related or that the KVA must be increased. This makes me a bit > > curious, since I've never seen problems like that on Linux. It sounds for > > me, the not kernel hacker, a bit like something which should be set at boot > > time (or via sysctl). Have you got some pointers which explain FreeBSD's > > KVA ? > > I have written documentation for FreeBSD 4.3/4.4. Unfortunately, > everyone keeps substituting activity for action, and hacking away > at the code, so it doesn't sit still long enough to match any > useful documentation; otherwise, I would have published what I > wrote in Pentad Embedded Systems Journal already (example: the ^^^ I appreciate some of the info you give. But every time you reference a proper noun (person, journal, etc.), Google only gives results of you talking about it in FreeBSD list archives! See also "freebsd mitre netbeui" What kind of conclusion is one to draw from that? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: booting multiple kernels
On Tue, 3 Dec 2002, Rashim Gupta wrote: > I have a machine to which I remotely log in and do > kernel programming. It has two kernel versions - one is WORKING and the > other is TEST - the one I am presently working on. Is it possible that > the bootloader tries to first load TEST but in case TEST panics then > it loads the WORKING version of kernel without user intervention ? My > initial guess would be to use loader scripts. Any suggestions? man 8 reboot, esp. -k option. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Review by USB wizard wanted
I'm not a usb expert but I think your patch deserves some comments.
On Mon, 25 Nov 2002, Yar Tikhiy wrote:
> First, sometimes (especially, if twitching a memory stick out of
> the reader while the device is being detected) a transfer to the
> umass device is initiated *after* the device is already gone. System
> panic follows. The transfer is initiated when destroying the default
> pipe to the device. Indeed, the current usb_subr.c code will detach
> child devices first and destroy the default pipe then. Reverting
> this order eliminates the panic.
>
> Second, twitching a memory stick can cause CAM jam. That happens
> because the umass detach routine won't wake up the upper layer when
> processing a device with a pending transfer on it.
>
> Patches addressing the above problems are attached below.
> [...]
> --- usb_subr.c.orig Sat Nov 16 12:07:50 2002
> +++ usb_subr.cFri Nov 22 15:45:35 2002
> @@ -1292,8 +1292,6 @@
> {
> int ifcidx, nifc;
>
> - if (dev->default_pipe != NULL)
> - usbd_kill_pipe(dev->default_pipe);
> if (dev->ifaces != NULL) {
> nifc = dev->cdesc->bNumInterface;
> for (ifcidx = 0; ifcidx < nifc; ifcidx++)
> @@ -1340,6 +1338,9 @@
> return;
> }
> #endif
> +
> + if (dev->default_pipe != NULL)
> + usbd_kill_pipe(dev->default_pipe);
>
> if (dev->subdevs != NULL) {
> DPRINTFN(3,("usb_disconnect_port: disconnect subdevs\n"));
>
This change looks good to me. With your patch, we need to be careful if
anyone ever calls usb_free_device() directly since the default pipe won't
be killed. But since I don't see it called by anyone else, it seems ok.
Why not make usb_free_device() static too?
> --- umass.c.orig Sat Nov 16 12:07:50 2002
> +++ umass.c Fri Nov 22 21:42:10 2002
> @@ -1033,6 +1033,13 @@
> /* detach the device from the SCSI host controller (SIM) */
> err = umass_cam_detach(sc);
>
> + /* if upper layer is waiting for a transfer to finish, wake it up */
> + if (sc->transfer_state != TSTATE_IDLE) {
> + sc->transfer_state = TSTATE_IDLE;
> + sc->transfer_cb(sc, sc->transfer_priv,
> + sc->transfer_datalen, STATUS_WIRE_FAILED);
> + }
> +
> for (i = 0; i < XFER_NR; i++)
> if (sc->transfer_xfer[i])
> usbd_free_xfer(sc->transfer_xfer[i]);
This looks good except you're passing the full datalen as the
residue. Does this address the situation where the data has been
partially transferred successfully? Or should you subtract
transfer_actlen in that case? I think your code is correct, I just am not
familiar enough with usb to be sure.
After addressing these questions, please send your patch to re@ for commit
approval.
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: out-of-order execution and code profiling
On Mon, 25 Nov 2002, Luigi Rizzo wrote: > I just got hit by a peculiar problem related to out-of-order > execution of instructions. > I was doing some low-level timing measurements using the rdtsc() > around selected pieces of code (the rdtsc() is included in > the TSTMP() functions that are in RELENG_4, source is in > sys/i386/isa/clock.c), as follows: > > TSTMP(3, ifp->if_unit, 1, 0); > tmp = CSR_READ_1(sc, FXP_CSR_SCB_STATACK); > TSTMP(3, ifp->if_unit, 2, 0); > TSTMP(3, ifp->if_unit, 3, 0); > > CSR_READ_1() goes to do a volatile read on memory across a 33MHz > PCI bus, so it should take a very minimum of 100ns, plus arbitration > and bridge crossing and whatnot. To my surprise, on a 750MHz Athlon > box, the delta between the first two timestamps turned out to be > in the order of 39 clock cycles, whereas the delta between 2 and 3 > is the 270-300 cycles range. > > The only explaination i can find is that the rdtsc() within TSTMP() > is executed out of order. > > I wonder, is there on the high-end i386 processors any 'barrier' > instruction of some kind that enforces in-order execution of some > piece of code ? The Intel processor manual has an explicit example for this and recommends you use cpuid as a serializing instruction before the call to rdtsc. Basically you call cpuid + rdtsc a bunch of times to calibrate its average latency. Then do your run with cpuid + rdtsc to get the beginning and end clockstamp, subtract the two plus the latency you calculated above. This gives a good value for the cycles in your routine. Other factors like acpi can affect rdtsc so beware of this. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [brooks@one-eyed-alien.net: [PATCH] switching to if_xname]
On Sat, 23 Nov 2002, Brooks Davis wrote: > On Tue, Nov 19, 2002 at 02:15:34PM -0800, Nate Lawson wrote: > > On Tue, 19 Nov 2002, Brooks Davis wrote: > > > On Fri, Nov 01, 2002 at 10:54:23AM -0800, Brooks Davis wrote: > > > > I'm trying to get some review for the following patch. I realize it's > > > > quite large, but most it is is trivial. The ipfw code is the only thing > > > > that worries me significantly. I have promised Kris that I will fix > > > > ports that break with this change so you don't need to worry about that > > > > issue. > > > > > > I've uploaded a new version of the patch addressing the concerns I've > > > heard to: > > > > > > http://people.freebsd.org/~brooks/patches/if_xname.diff > > > > Thanks for fixing things. Are all the uses of sprintf() below safe and > > intentional? > > No, they weren't intentional. I managed to forget to scan for those. > Most of them were safe, but I've removed all of them. (Grep still hits > a few due to ipf using sprintf). I've uploaded a new version. I'm now > testing a world build on panther. Looks good to me now. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [FreeBSD PR bin/15416] addr2line broken
It has been closed. On Sat, 23 Nov 2002, [ISO-8859-1] Mikko Työläjärvi wrote: > On Wed, 20 Nov 2002, Joseph Scott wrote: > > > FreeBSD PR bin/15416 (addr2line is unable to find line > > numbers) indicates that addr2line appears to be broken. This PR was > > submitted at the end of 99 when 4.x was -current. It hasn't been touched > > since. > > > > The PR gives a test case where addr2line appears to be broken. I > > ran this exact test case on a 4-stable box and saw the same issue. The > > version addr2line reports is 2.12.1 [FreeBSD] 2002-07-20. I tested it on > > 5-DP2 and it appears to work correctly, the version there is 2.13 > > [FreeBSD] 2002-10-10. > > > > What's the correct thing to do with this PR? The issue does > > appear to be fixed in -current (with the newer addr2line). I suppose the > > PR should at least be set to a status of patched. > > As the originator of that PR (the e-mail address in the PR is now > defunct), I'd say close it. Nowadays the problem only seems to affect > the "main" symbol, other functions are resolved as expected. > >Regards, >/Mikko > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Changing socket buffer timeout to a u_long?
On Fri, 22 Nov 2002, Terry Lambert wrote: > Nate Lawson wrote: > > As a member of the e2e camp, I'd say that any device which is looking at > > sequence space is implicitly an endpoint and has to accept the processing > > limitations as such. MITM devices (load balancers, firewalls, etc.) are > > IMO a poor workaround for the fact that most endpoints have a closed OS > > with weak software management tools. Every endpoint should have MAC > > capability with per-application filters on network traffic and single > > system image features for load balancing. Add in robust management tools > > and you get all the features of network devices without MITM. This is the > > direction I hope FreeBSD continues in. > > The main problem is things like third party web-enabled applications > that are not built on an anonymous work-to-do model, and/or are not > capable of sharing session state across multiple instantiations. > > Nothing you do to the OS is going to enable a local "shopping cart" > cookie, for example, to look up the "shopping cart" contents on one > web server, if the cookie was issued by another. Neither is an SSL > session going to be transferrable between back-end servers, since > the session is persistent across requests. This is orthogonal to the original discussion but if you had a single system image, you use the OS to share state just like you share state between multiple processes on the same machine. The same primitives work. To a lesser degree, a shared directory service gives you the same thing but requires more application support. Finally, the most difficult to use as an application programmer is custom, explicit sharing through writing your own state management protocol or layering it on top of NFS or LDAP. > Load balancers and other "MITM" devices are just something you are > going to have to live with. 8-). Yes, but because of the reasons I mentioned before -- closed endpoints with weak distributed application support. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Changing socket buffer timeout to a u_long?
On Thu, 21 Nov 2002, Terry Lambert wrote: > Nate Lawson wrote: > > On Thu, 21 Nov 2002, Terry Lambert wrote: > > > FWIW: upping the roll-over rate is not a good reason to increase > > > the size of fields, unless you want to increase the TCP sequence > > > number filed to 64 bits? ...it has exactly the same issues at > > > high data rates. > > > > That's what the timestamp option does and I think it was a good idea, > > given the range of systems TCP needs to work well on. > > Setting your HZ to 100,000 instead of 100, and then complaining > because a timer field with a resolution specified in ticks instead > of an interval length can't handle a value which is way to large > for a fast transport seems a bit silly to me. That's not what I was saying. I was addressing a particular point he raised -- questioning whether the sequence number of TCP should be increased to 64 bits due to rollover. I pointed out that it already has two modes: 32 bit sequence or 64 bit TS/sequence combo. The nice thing about the latter being an option is that it allows the implementer to choose which they want to support. In an embedded app, I'm not going to do 64 bit math, hence it is good that this is an option, not an automatic increase to 64 bits for the sequence field across the board. I agree that timers should be interval based, not counters that are dependent on a variable system event clock. But I was not saying anything about that in the previous message. > PS: Adding *any* TCP options is bad karma, for networking equipment; > the cost in terms of in transit overhead is immense, if you are > trying to use the code later to build a switch or a load balancer. > Doing that sort of thing is fine -- as long as you know beforehand > that what you are doing is making the code less general purpose, > and everyone buys into that idea. As a member of the e2e camp, I'd say that any device which is looking at sequence space is implicitly an endpoint and has to accept the processing limitations as such. MITM devices (load balancers, firewalls, etc.) are IMO a poor workaround for the fact that most endpoints have a closed OS with weak software management tools. Every endpoint should have MAC capability with per-application filters on network traffic and single system image features for load balancing. Add in robust management tools and you get all the features of network devices without MITM. This is the direction I hope FreeBSD continues in. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Changing socket buffer timeout to a u_long?
On Thu, 21 Nov 2002, Terry Lambert wrote: > FWIW: upping the roll-over rate is not a good reason to increase > the size of fields, unless you want to increase the TCP sequence > number filed to 64 bits? ...it has exactly the same issues at > high data rates. That's what the timestamp option does and I think it was a good idea, given the range of systems TCP needs to work well on. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/sys/cam/scsi scsi_cd.c scsi_cd.h src/sys/dev/ataatapi-cd.c src/sys/sys cdrio.h src/usr.sbin/burncd burncd.8 burncd.csrc/usr.sbin/cdcontrol cdcontrol.1 cdcontrol.c
On Wed, 20 Nov 2002, Dirk Froemberg wrote:
> What about CDRIOCGETBLOCKSIZE and CDRIOCSETBLOCKSIZE? Any chance
> to have these ioctl in cd(4)?
>
> This would allow mplayer to play (S)VCD with SCSI cd drives. 8-)
>
> Regards Dirk
I'm open to reviewing a patch that does this if someone wants to do it
(jkh?) The ioctls left to port from atapi-cd.c are:
#define CDRIOCBLANK _IOW('c', 100, int)
#define CDRIOCNEXTWRITEABLEADDR _IOR('c', 101, int)
#define CDRIOCINITWRITER_IOW('c', 102, int)
#define CDRIOCINITTRACK _IOW('c', 103, struct cdr_track)
#define CDRIOCSENDCUE _IOW('c', 104, struct cdr_cuesheet)
#define CDRIOCFLUSH _IO('c', 105)
#define CDRIOCFIXATE_IOW('c', 106, int)
#define CDRIOCGETBLOCKSIZE _IOR('c', 109, int)
#define CDRIOCSETBLOCKSIZE _IOW('c', 110, int)
#define CDRIOCGETPROGRESS _IOR('c', 111, int)
#define CDRIOCREADFORMATCAPS_IOR('c', 112, struct
cdr_format_capacities)
#define CDRIOCFORMAT_IOW('c', 113, struct cdr_format_params)
However, I'm working on more CAM stuff that should make this code
duplication unnecessary so I won't be duping this code myself.
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [brooks@one-eyed-alien.net: [PATCH] switching to if_xname]
On Tue, 19 Nov 2002, Brooks Davis wrote: > On Fri, Nov 01, 2002 at 10:54:23AM -0800, Brooks Davis wrote: > > I'm trying to get some review for the following patch. I realize it's > > quite large, but most it is is trivial. The ipfw code is the only thing > > that worries me significantly. I have promised Kris that I will fix > > ports that break with this change so you don't need to worry about that > > issue. > > I've uploaded a new version of the patch addressing the concerns I've > heard to: > > http://people.freebsd.org/~brooks/patches/if_xname.diff Thanks for fixing things. Are all the uses of sprintf() below safe and intentional? sprintf(sc->sc_if.if_xname, "sl%d", unit); sprintf(sc->sc_if.if_xname, "sl%d", unit); sprintf(multicast_decap_if[s].if_xname, "mdecap%d", s); sprintf(ifp->if_xname, "get%d", device_get_unit(sc->sc_dev)); sprintf(ifp->if_xname, "%s%d", iedriver.name, unit); sprintf(ifp->if_xname, "lp%d", device_get_unit(dev)); sprintf(ifp->if_xname, "sbni%d", unit); sprintf(ifp->if_xname, "sn%d", device_get_unit(dev)); sprintf(ifp->if_xname, "aue%d", sc->aue_unit); sprintf(ifp->if_xname, "cue%d", sc->cue_unit); sprintf(ifp->if_xname, "kue%d", sc->kue_unit); sprintf(ifp->if_xname, "wl%d", id->id_unit); sprintf(c->ifp->if_xname, "cx%d", u); sprintf(sc->le_if.if_xname, "%s%d", ledriver.name, dvp->id_unit); sprintf(ifp->if_xname, "rdp%d", unit); sprintf(sc->sc_if.if_xname, "ipr%d", i); sprintf(sc->sc_if.if_xname, "isp%d", sc->sc_unit); sprintf(ifp->if_xname, "%s%d", NG_EIFACE_EIFACE_NAME, priv->unit); sprintf(ifname, "if%s", ifp->if_xname); (void) sprintf(ifp->if_xname, "%s%d", NG_IFACE_IFACE_NAME, priv->unit); sprintf(ifp->if_xname, "ipxip%d", ipxipif_units); sprintf(ifp->if_xname, "ipxip%d", ipxipif_units++); sprintf(sc->tulip_xname, "de%d", sc->tulip_unit); -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Steve Quits Smoking!
HEAD is frozen for the first time in years... Trolls and spammers are on the rise... Looks like he picked the wrong week to stop smoking. -Nate On Tue, 19 Nov 2002, Ramshur wrote: > Hello- > > This Thursday is the Great American Smokeout, and after 20 years, I am finally >quitting smoking. I will be keeping a daily weblog of the up and downs, the trials >and tribulations, how I'm doing it, why I'm doing it, etc. You can view it at: > > http://stevequits.webhop.net > > If you have any problems viewing the site, please let me know, and my apologies if >you find this email intrusive. > > All the best, > Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/bin/sleep sleep.c
On Fri, 15 Nov 2002, Alfred Perlstein wrote: > * Matthew Dillon <[EMAIL PROTECTED]> [021115 12:17] wrote: > > :Will the knobs allow one to link /bin and /sbin against full blown > > :libc? That would be nice as we can then start using pam and user > > :management in / with dynamic modules (finally!). > > : > > :-- > > :-Alfred Perlstein [[EMAIL PROTECTED]] > > > > I think that should be a goal. I think something like this: > > > > USE_MINIC=YES Link against the mini-C library. > > > > USE_SHARED_BIN=YES Link against a shared libc or mini-C rather > > then linking statically. > > Moiving forward I think it makes the most sense for us to maker /s?bin > dynamically linked against libc by default with options for linking > statically or dynamically against libc or mini-libc via make.conf. I appreciate your interest but want to avoid a war so we'll just say that the _option_ to link them dynamically will be added but the default will be left up to a separate discussion, once things are well-tested in both configurations. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/bin/sleep sleep.c
On Thu, 14 Nov 2002, Alfred Perlstein wrote: > * Nate Lawson <[EMAIL PROTECTED]> [021114 15:42] wrote: > > Please see earlier threads on hackers@ about bloat in libc and dynamic > > linking of /[s]bin. Tim Kientzle submitted a patch that breaks exit's > > dependency on malloc which saves space in the programs that don't > > otherwise use malloc. > > > > I don't think a mini-libc is a good idea because bugfixes would need to be > > duplicated or confusion about which one is being used for a program would > > make debugging harder. I'd rather have the normal libc on /lib (modulo > > some paring down of libc) and things dynamically linked. > > I'd like to see / dynamically linked with some form of /stand that gets > updated in case of emergencies. > > When/who is going to do this already? :) Time Kientzle has offered to build something similar to NetBSD's dynamic /[s]bin and lukem has sent us some info on his work. Let me know if anyone is duplicating effort here. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/bin/sleep sleep.c
Please see earlier threads on hackers@ about bloat in libc and dynamic
linking of /[s]bin. Tim Kientzle submitted a patch that breaks exit's
dependency on malloc which saves space in the programs that don't
otherwise use malloc.
I don't think a mini-libc is a good idea because bugfixes would need to be
duplicated or confusion about which one is being used for a program would
make debugging harder. I'd rather have the normal libc on /lib (modulo
some paring down of libc) and things dynamically linked.
-Nate
On Thu, 14 Nov 2002, Matthew Dillon wrote:
> I think the real issue is the bloat in libc. printf() eats 20K, basic
> stdio eats 5K. You get 15K of bloat just with a blank main(), a good
> chunk of that being malloc() (reasonable in larger programs, ridiculous
> in tiny programs where you don't care about malloc() efficiency).
>
> (static link output)
> -rwxr-xr-x 1 dillon dillon 52873 Nov 14 14:36 xprintf("X\n");
> -rwxr-xr-x 1 dillon dillon 21493 Nov 14 14:36 xputs("X");
> -rwxr-xr-x 1 dillon dillon 21493 Nov 14 14:36 xputs("X");
> -rwxr-xr-x 1 dillon dillon 15109 Nov 14 14:38 xmain()
>
> -rwxr-xr-x 1 dillon dillon 959 Nov 14 14:55 x _start() / no libc
> -rwxr-xr-x 1 dillon dillon 959 Nov 14 14:55 x _start() + phk malloc
> -rwxr-xr-x 1 dillon dillon 13409 Nov 14 14:56 x
>
> My zalloc implementation, which I could turn into a poor-man's malloc
> in 10 seconds (and is used in libstand) eats 1.7K. My *printf()
> core (pfmt) from DICE, which handles 95% of the capabilities of *printf,
> is 1.9K. I could adapt the stdio library from DICE to fit in probably
> less then 2K, assuming one actually referenced every single function.
>
> Why not create a mini-libc? No language-aware character conversions,
> no efficient string or memory functions, no floating point. Just a basic
> implementation of the core functionality required for stdio, malloc,
> *printf(), string functions, and system calls (which will simply be
> borrowed from libc), sufficient for simple binaries. It could be made
> compatible with our standard includes (structural bloat != code bloat,
> so who cares).
>
> I could whip this up in a day or two. I'm not kidding. I already have
> most of the necessary pieces from my embedded libraries and DICE
> libraries.
>
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
>
> :
> :In message: <[EMAIL PROTECTED]>
> :Maxim Sobolev <[EMAIL PROTECTED]> writes:
> :: On Wed, Nov 13, 2002 at 03:32:13PM -0500, Mike Silbersack wrote:
> :: >
> :: > On Wed, 13 Nov 2002, Nate Lawson wrote:
> :: >
> :: > > njl 2002/11/13 12:12:26 PST
> :: > >
> :: > > Modified files:
> :: > > bin/sleepsleep.c
> :: > > Log:
> :: > > Remove getopt and strtol dependencies, reducing size of static exe.
> :: > > Preserve older desired behavior, accept [+-]*[0-9]*\.[0-9]*
> :: > > Remove a few unnecessary casts.
> :: >
> :: > Please don't commit crap like this. While having smaller binaries might
> :: > be nice, being entered into an obfuscated C contest is not one of the
> :: > goals of FreeBSD.
> ::
> :: I fully agree - HDD space is pretty cheap today, while embedded folks
> :: should use other means to reduce footprint (e.g crunchgen). Actually
> :: in the case of crunchgen this commit worsens situation, as the code
> :: is no longer shared.
> :
> :It also makes the dynamic binary larger for the folks that have / and
> :/usr on the same partition and dynamically link /sbin and /bin. Much
> :more bang for the buck that these silly micro-optimizations. So this
> :is a negative thing as far as I'm concerned. :-(
> :
> :Warner
> :
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Shrinking /(s)bin: A Proposal
On Thu, 14 Nov 2002, Wes Peters wrote: > Doug Rabson wrote: > > > > On Thursday 14 November 2002 6:45 am, M. Warner Losh wrote: > > > > > > % make NOSHARED=NO buildworld > > > > > > No patches necessary. We do this all the time at work, and it works > > > fabulously. I do this for disk based systems that have / and /usr on > > > the same file system too. > > > > To do it right for split root/usr installations requires a few patches > > though. The rtld and the libs required for /[s]bin need to move to / > > and compat symlinks created from /usr. A suitable crunchgen'ed binary > > for /recover would be useful too. > > Time to bring back /lib? Yeah, this is what I figured patches would be needed for and it's more a policy issue of fs layout than a technical problem. A couple things that could be useful: * All dynamic/static flag (imp's option above) * Flag to selectively link dynamically/statically, overriding the above flag for specific binaries (Makefile flags?) * Minimal /lib (libc, ...?) with symlinks from /usr/lib * Optional recovery crunchgen utility. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shrinking /(s)bin: A Proposal
On Mon, 11 Nov 2002, Tim Kientzle wrote: > The possibility of dynamically linking /(s)bin seems > to recur pretty regularly. As libc continues to grow, > this idea seems worth revisiting. However, I've come up > with an alternative that might be worth considering. I'm open to patches for building /[s]bin as dynamic. If you have time and can coordinate with [EMAIL PROTECTED] to build the patch, I would appreciate it. > 4) Implement a command-line helper. A user_from_uid > binary could be run by /bin/mv as needed. This could > povide most of the benefits of a daemon with the > added advantage of on-demand loading; no memory is > required unless the service is actually needed. >... > I've started experimenting with the helper binary approach > (#4 above), and it seems pretty workable. Of course, a single > helper should handle user, group, and DNS lookups and do so in > a way that does not require re-running it for every lookup. I > can manage all of that without too much trouble. Making a separate pw resolver program probably is too drastic a change, so I think it's better to focus for now on a patch to allow building the entire /[s]bin or user-selected parts as dynamic. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sio howto
On Mon, 11 Nov 2002, the evil toor wrote: > I just followed the recent sio thread, but it did not answer my questions. > I have a program that needs to set RTS and DTR and then later set them > again and again.. I could go for the open /dev/io and then the IO adr of > the serial port.. but as far as i've seen it would lock up the kernel, but > is there a good way to this? Don't access the port directly, use /usr/include/sys/ttycom.h, see TIOCSDTR -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: busdma in the DRM
On 6 Nov 2002, Eric Anholt wrote: > I've been trying to figure out how to use the bus_dma* functions in the > DRM. What I'm working on at the moment is the ATI PCIGART. How it > works right now is an ioctl is done which mallocs a chunk of memory (up > to 32MB). Later, the ioctl that sets up dma allocates a physically > contiguous 32K of memory which contains pointers (by vtophys) into the > pages of the 32MB. The physical address of that 32K is then written to > the card. The 32MB is mapped by both the kernel and userspace (the X > Server). > > So, I'm trying to convert it to busdma. I'm making a tag (is making it > without having a parent tag a bad thing?) for the 32K contiguous, > allocing 32K, and loading, with a callback to drop the dma address into > a place of my choice. However, how do I do the 32MB? It only has to > consist of pages, with nothing else special for alignment. For > nsegments in bus_dma_tag_create it says it can't be more than 250-300, > while I've got possibly 8192 segments. I'm thinking I would have to > make a tag for the 32MB, allocate it, then loop and create PAGE_SIZE, > nsegments=1 tags with the 32MB as parent, and bus_dmamap_load on those > tags with offsets from the first map's vaddr and PAGE_SIZE long. Am I > totally off base here? Is this even possible? Check out /sys/pci/agp* -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Formatting a large (1.3TB) SCSI disk
On Thu, 7 Nov 2002, Marc Olzheim wrote: > With some minor modifications to disklabel, you can label a 2 Tb disk. > We've done it with a 1.4Tb disk: > > Filesystem Size Used Avail Capacity Mounted on > /dev/da20a 669G 246G 370G40%/rapraid0 > /dev/da20e 669G 499G 117G81%/rapraid1 > > Patch attached (Don't mind the code, it's a quick hack) Um, why did you reimplement strtoll(3)? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: max phy mem known working with FreeBSD 4.x
On Tue, 5 Nov 2002, Terry Lambert wrote: > As far as PCI goes (or anything they publish, for that matter), the > MindShare books are very, very good. But for the particular question > of how much physical address space is eaten, you really have to go to > the chipset spec. sheets to get the right answer these days. 8-(. The PCI book is good. The others less so. Bottom of the barrel is "plug and play arch" -- terrible. Amazon's reviews are pretty close to reality IMO. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GDB auto enter/detach patch
On Tue, 5 Nov 2002, Archie Cobbs wrote:
> Nate Lawson writes:
> > I've put together a patch that enables a kernel on the target machine to
> > detect a GDB packet and automatically enter GDB mode. When the debugger
> > detaches, it also continues execution. This speeds up debugging,
> > especially when the target is in a remote location. The patch plus more
> > explanation is at:
> >
> >http://www.root.org/~nate/freebsd/
>
> Neat. A couple of comments:
>
> 1. I think a better abstraction of the GDB packet protocol would
>be something like this:
>
> struct gdb_parse {
> int state; /* opaque state value */
> u_int len;/* current packet length */
> u_int maxlen; /* maximum packet length */
> u_char data[0];/* packet data */
> };
>
> extern void gdb_parse_init(struct gdb_parse *p);
> extern int gdb_parse_byte(struct gdb_parse *p);
>
>That is, if you're doing the state machine, why not go ahead
>and decode the packet data as well?
The first version of the patch collected the data in a small static buffer
with the idea that I'd send the command to the gdb stub once it was
assembled. However, gdb on attach retries multiple times with different
commands before giving up so I just discard the first complete gdb frame
and let the retries hit gdb once I call breakpoint()
> 2. You need to handle the escape mechanism for packets containing
>"raw" data.: '$', '#', and '~' are escaped with '~' characters
>in case the the 'X' command is used.
Escapes should be added but I haven't done that yet because all the
commands currently used to attach to the stub don't need them.
> 3. I think GDB_AUTO_DETACH should be mandatory, i.e., the current
>state of affairs is a bug IMHO.
I've always wondered why that wasn't the case. I'd also like to catch the
$k command (kill) which is sent on typing "quit" into gdb while still
attached and do something useful. Should that also restart the kernel
like an explicit "detach"?
> 4. Does FreeBSD use the 'O' command to send ordinary serial port output
>when GDB mode is active? Haven't looked but this would be nice to
>have if it's not already there.
No, it uses gdb remote chat which prefixes commands with
> 5. Receipt of a '$' character should always reset the state, no?
>(modulo the '~' escape mechanism mentioned above).
Yeah, I should add this. Basically the state machine is a little lax at
the moment and it's possible (although unlikely) that data transferred
over the serial port could trigger a breakpoint(). It matches
$ + up to 12 chars + # + [0-F] + [0-F]
If you're worried about this, just use the sysctl to turn off
debug.gdb_auto_enter while transferring binary data over the gdb port.
Even when I implement stricter protocol matching, relying on inband
signalling is inherently unreliable. If you need to debug a serial port
driver, you can use a 2nd serial port.
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
GDB auto enter/detach patch
I've put together a patch that enables a kernel on the target machine to detect a GDB packet and automatically enter GDB mode. When the debugger detaches, it also continues execution. This speeds up debugging, especially when the target is in a remote location. The patch plus more explanation is at: http://www.root.org/~nate/freebsd/ Thanks, Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dgb driver update
On Mon, 4 Nov 2002, Wilko Bulte wrote: > On Mon, Nov 04, 2002 at 03:14:01AM -0800, Terry Lambert wrote: > > Wilko Bulte wrote: > > > On Mon, Nov 04, 2002 at 11:05:29AM +0300, Oleg Sharoiko wrote: > > > > > > you could use send-pr to make the proposed patch visible in the > > > bug tracking database > > > > Submit it to the PR database. > > > > It can get in line behind the other almost 3000 open PR's, 65% of > > which are ports, 30% of which are against kern, and for which many > > contain patches, but have not been committed (yes, I am skeptical > > about the effectiveness of "send-pr", and will probably remain so, > > You have every right to be sceptical. I'm unfortunately just as > sceptical about a patch floating in a random mailing list. > > Rock & a hard place :( The best way is to send a pr and then followup on mailing lists as appropriate or perhaps by contacting the maintainer. The PR provides history for a given problem and patch and the followup initiates action on behalf of the committers. It's important to get someone to take up the "responsible" field before any action can happen. BTW, the number of PRs is not totally the fault of committers. I've been scanning through the DB with about 50% of my FreeBSD-time and fixing things that I find there. However, it has taken about 3x as long as I expected to commit a patch because almost all of them are very incomplete and actually are more a suggestion on an area that needs improvement, not a fix. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH] switching to if_xname
On Fri, 1 Nov 2002, Brooks Davis wrote:
> The bigger deal is breaking
> the network interface API and ABI which in turn breaks a few user land
> programs that use libkvm ("netstat -r" for exmaple). That's why this is
> a .0 feature.
>
> Thanks,
> Brooks
Please check the libdnet port and possibly libpcap.
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH] switching to if_xname
You might also try -net or -arch. On Fri, 1 Nov 2002, Brooks Davis wrote: > I'm trying to get some review for the following patch. I realize it's > quite large, but most it is is trivial. The ipfw code is the only thing > that worries me significantly. I have promised Kris that I will fix > ports that break with this change so you don't need to worry about that > issue. > > I'd like to commit this prior to 5.0-R pending RE approval (post DP2 > would be fine if that would help get it out the door). > > Thanks, > Brooks > > http://people.freebsd.org/~brooks/patches/if_xname.diff > > Please review. Couple comments. * You interchangeably use strlcpy and snprintf(... "%s", ...) and even strncpy/strcpy(!). You probably want to go with just strlcpy. * There may be some cases where a string compare is too slow and it needs a unit compare. I'm not familiar with the code that does this but please comment. * Some places seem to still be using a unit number as a local loop counter. Just curious if this has any side effects. * Do the ipfw glob changes break ABI? Overall, I like it. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: core dump from ffs_write - i think
Try to figure out where it was in frames 8 and 10 (probably a module). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Command used to trace the stack of a process
l *routine + 0x350 or if you use a core file with symbols (-g), gdb will do it automatically. Please read the gdb docs for better info. On Tue, 29 Oct 2002, Zhihui Zhang wrote: > > Thanks. The backtrace often gives something like: > > + 0x350 > > Is there a way to quickly determine the correponding source code line? > > -Zhihui > > On Tue, 29 Oct 2002, Nate Lawson wrote: > > > On Tue, 29 Oct 2002, John Baldwin wrote: > > > On 29-Oct-2002 Zhihui Zhang wrote: > > > > > > > > I remember there is a command in either gdb or ddb which enable you to > > > > display the stack of a particular process. Can anyone tell me if there is > > > > such a command and what the command is? Thanks! > > > > > > In ddb you can do 'tr ' where is the PID of the process. > > > > In gdb, it's bt. > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Command used to trace the stack of a process
On Tue, 29 Oct 2002, John Baldwin wrote: > On 29-Oct-2002 Zhihui Zhang wrote: > > > > I remember there is a command in either gdb or ddb which enable you to > > display the stack of a particular process. Can anyone tell me if there is > > such a command and what the command is? Thanks! > > In ddb you can do 'tr ' where is the PID of the process. In gdb, it's bt. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [hardware] Tagged Command Queuing or Larger Cache ?
On Mon, 28 Oct 2002, Doug Barton wrote: > On Mon, 28 Oct 2002, Kenneth Culver wrote: > > > > I'd probably steer clear of the western digital drives as well. Yes the > > > > make that "stear" clear. > > Ummm... why? "steer" is a word with multiple meanings. I can't find > "stear" anywhere. Mu. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC
On Thu, 24 Oct 2002, Maxim Sobolev wrote: > Please review the patch, which adds two new types of events - > NOTE_STARTEXEC and NOTE_STOPEXEC, that could be used to get > notification when the image starts or stops executing. For example, it > could be used to monitor that a daemon is up and running and notify > administrator when for some reason in exits. I am running this code > for more than a year now without any problems. > > Any comments and suggestions are welcome. Couldn't this just be done by init(8) and /etc/ttys? Or inetd? If you want to write your own, couldn't you use waitpid()? Or a kevent() of EVFILT_PROC with NOTE_EXIT/NOTE_FORK? I'm not sure I see the need for this. Comments below. > +.It NOTE_STOPEXEC > +Execution of the file referenced by the descriptor ended. Triggered > when > +the process associated with the file exited or was replaced with anoter > +image using > +.Xr execve 2 > +or simial syscall. The PID of the process is returned in ^ typo > Index: src/sys/sys/event.h > === > RCS file: /home/ncvs/src/sys/sys/event.h,v > retrieving revision 1.21 > diff -d -u -r1.21 event.h > --- src/sys/sys/event.h 29 Jun 2002 19:14:52 - 1.21 > +++ src/sys/sys/event.h 24 Oct 2002 06:57:41 - > @@ -83,13 +83,15 @@ > /* > * data/hint flags for EVFILT_VNODE, shared with userspace > */ > -#define NOTE_DELETE 0x0001 /* vnode was removed */ > -#define NOTE_WRITE 0x0002 /* data contents changed */ > -#define NOTE_EXTEND 0x0004 /* size increased */ > -#define NOTE_ATTRIB 0x0008 /* attributes changed */ > -#define NOTE_LINK 0x0010 /* link count changed */ > -#define NOTE_RENAME 0x0020 /* vnode was renamed */ > -#define NOTE_REVOKE 0x0040 /* vnode access was revoked */ > +#define NOTE_DELETE 0x0010 /* vnode was removed */ > +#define NOTE_WRITE 0x0020 /* data contents changed */ > +#define NOTE_EXTEND 0x0040 /* size increased */ > +#define NOTE_ATTRIB 0x0080 /* attributes changed */ > +#define NOTE_LINK 0x0100 /* link count changed */ > +#define NOTE_RENAME 0x0200 /* vnode was renamed */ > +#define NOTE_REVOKE 0x0400 /* vnode access was revoked */ > +#define NOTE_STARTEXEC 0x0800 /* vnode was executed */ > +#define NOTE_STOPEXEC 0x1000 /* vnode execution stopped */ > +/* Applies both to EVFILT_VNODE and EVFILT_PROC */ > #define NOTE_PDATAMASK 0x000f /* mask for pid */ I don't think we should burn our 32 bits on this. Since pids are 32 bits, this interface will fail unpredictably. > /* additional flags for EVFILT_PROC */ > Index: src/sys/kern/kern_exec.c > === > RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v > retrieving revision 1.193 > diff -d -u -r1.193 kern_exec.c > --- src/sys/kern/kern_exec.c 11 Oct 2002 21:04:01 - 1.193 > +++ src/sys/kern/kern_exec.c 24 Oct 2002 06:57:41 - > @@ -518,6 +518,8 @@ >* to locking the proc lock. >*/ > textvp = p->p_textvp; > + if (textvp) > + VN_KNOTE(textvp, NOTE_STOPEXEC | p->p_pid); > p->p_textvp = ndp->ni_vp; Do these always stay an int or are there casts that could result in endian problems? >Index: src/sys/kern/kern_fork.c >=== >RCS file: /home/ncvs/src/sys/kern/kern_fork.c,v >retrieving revision 1.172 >diff -d -u -r1.172 kern_fork.c >--- src/sys/kern/kern_fork.c 18 Oct 2002 17:45:41 - 1.172 >+++ src/sys/kern/kern_fork.c 24 Oct 2002 06:58:03 - >@@ -724,6 +724,8 @@ >* tell any interested parties about the new process >*/ > KNOTE(&p1->p_klist, NOTE_FORK | p2->p_pid); >+ if (p2->p_textvp != NULL) >+ VN_KNOTE(p2->p_textvp, NOTE_STARTEXEC | p2->p_pid); > PROC_UNLOCK(p1); > > /* This shows my doubt for the need for this since the NOTE_FORK is immediately before your duplicate NOTE_STARTEXEC. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help with System panics - Debugger output attached.
On Wed, 16 Oct 2002, Terry Lambert wrote: > Frank C Pilarcik wrote: > > To whom it may concern, > > > > We have been experiencing intermittent system panics on system intended to > > handle email and web mail. Neither system load or traffic volume seems to > > have a bearing on when the panics occur. > > > > Any insight into our issue would be greatly appreciated. > > > > I have attached the debugger output (panic1.txt). > > This is a double panic. > > Please do the following: > > sysctl kern.sync_on_panic=0 > > And recreate the traceback, so as to not mask the first panic with > a second panic. > > -- Terry Additionally, the line that your gdb claims generated the trap was ip_input.c:759 which is the ip_freef(fp) line. -- #endif } else if (fp) 759 :: ip_freef(fp); } else ip->ip_len -= hlen; -- It seems that it may be possible for fp to be garbage (uninitialized) and thus this would trigger a fault. Note this is fixed in 4.7-RELEASE and above by removing the dangling ip_freef() and depending on the interior of the "if (mff)" case to free it instead. Upgrade to 4.7R and see if the problem goes away. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: swapoff?
Nice, thanks for doing this. How about some more accurate names for the userland routines instead of "this_is_swapoff" and "twiddle"? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: proper printf fmt type for off_t?
On Mon, 30 Sep 2002, Brooks Davis wrote: > On Mon, Sep 30, 2002 at 06:36:39PM -0700, Nate Lawson wrote: > > What's the portable way of printing an off_t? It should work on Linux and > > FreeBSD. Linux seems to recommend casting the off_t to intmax_t which > > isn't present in FreeBSD. This is in usermode. > > In current, intmax_t is defined in stdint.h. In stable, I think you're > SOL and have to cast to quad_t which is totally non-portable. > > -- Brooks Thanks. Yeah I couldn't find intmax_t on -stable and figured someone had an acceptable workaround. I think I'll add my own intmax_t typedef for __FreeBSD_version < 50. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
proper printf fmt type for off_t?
What's the portable way of printing an off_t? It should work on Linux and FreeBSD. Linux seems to recommend casting the off_t to intmax_t which isn't present in FreeBSD. This is in usermode. Thanks, -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Hey, is there space for a newbie? =)
On Wed, 25 Sep 2002, Bruce M Simpson wrote: > On Tue, Sep 24, 2002 at 12:32:40PM -0700, Nate Lawson wrote: > > How about updating Alpine (alpine.cs.washington.edu) and fixing a lot of > > its lousy hacks (i.e. the sysinit stuff)? > > Nice idea, but a lot of people will/are use/using Bochs or VMware for this. > Mind you, the Alpine approach doesn't require as much other crap (vmnet, > vmmon, et al) to operate. And tun(4) could be used as a faux ethernet driver. It's still useful and can be expanded like usermode Linux. Having both the user code calling a socket and tcp_output in the same address space helps a lot for GDB. Your approach is also useful. > > Zero copy BPF? > > This is a seriously nice idea; but won't it require user-space applications > to allocate their buffers on page boundaries (assuming MMU page tricks are > one underlying mechanism to avoid copies) ? See options ZERO_COPY. Similar tricks would be needed. > > Port the Linux Rockwell/Conexant winmodem support to freebsd? (Tons of > > laptops have this chipset). > > http://www.mbsi.ca/cnxtlindrv/ > > I had a brief look at this last month. I should warn you that the Linux > driver is simply a wrapper. The actual software modem is a Linux object > with encrypted symbols which is linked in to the wrapper to provide the > loadable softmodem module. I didn't get further than that - but I imagine > that there must be some way to convert the module to something which > could be linked in to a corresponding FreeBSD .ko. Yep. The grunt work is in mapping the FreeBSD kernel services to provide the expected entries their binary driver wants. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kqueue
On Wed, 25 Sep 2002, Michel Oosterhof wrote: > Hello. > > Recently I started looking into kqueue(2), and to get to know the > interface better I attempted to turn usr.sbin/moused into a kqueue > program (replacing the main select() loop that reads the mouse > device). > > Now I thought I understood the interface, I requested a kqueue, but > as soon as I add an event for monitoring I get an 'Operation not > permitted' error. Does anyone know if this is caused because > kqueue() only supports FFS? The mouse device is on devfs (I'm running > -CURRENT, btw). No, it's a device driver not fs deficiency. The serial/ps2/whatever drivers need to add a KNOTE when they have data ready. Check out sys/kern/tty.c for a driver that does this. This is not a difficult change -- KNOTE would go into psmintr() near the selwakeup. You also need to add kqfilter, attach, detach entries (see ttykqfilter, fil_ttyrdetach, etc.) > I've got one more question, actually a fact that surprises me, it > seems that tail(1) is the only place in the base system that actually > uses kqueue. Is there a reason for this? I read in most places > kqueue() is more efficient, scalable, etc. I'm sure code like ftpd > or other services would benefit. (And i'm sure Apache could use it > too). No time. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Hey, is there space for a newbie? =)
On Tue, 24 Sep 2002, Brooks Davis wrote: > On Tue, Sep 24, 2002 at 07:56:43PM +0200, Paolo Pisati wrote: > > > > Here there's a mini list of things i would like to work on, tell me > > which one is available and fell free to add any other project you > > think could help the FreeBSD community in general. > > > -a fs with journaling: some times ago, i would like to develop > > my own fs with journaling, but right now i could even drop the > > dream of my own fs and JUST port the xfs/jfs for FreeBSD.. > > Your own Journaling FS could be intresting, especialy if you licensed it > under a BSD license. > > > any ideas is welcome =) > > If you have an intrest in networking, you might look at what it would > take to build a pure netgraph TCP/IP stack. It probably wouldn't > become the default, but it could be very useful for research if the > components where properly seperated. You'd need a routing module, ip > module, and tcp module at least. You'd probably also want to implement > various versions of TCP (tahoe, reno, newreno, vegas, FreeBSD, etc). An > intresting research topic related to that would be building a TCP stack > where it's easy to replace the congestion control algorithm. How about updating Alpine (alpine.cs.washington.edu) and fixing a lot of its lousy hacks (i.e. the sysinit stuff)? Zero copy BPF? Port the Linux Rockwell/Conexant winmodem support to freebsd? (Tons of laptops have this chipset). http://www.mbsi.ca/cnxtlindrv/ > Some one may already be working on this, but an iSCSI implementation > (hopefully both sides) would be cool. > > -- Brooks There are already a couple for FreeBSD and we are examining them for possible integration. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What does this log mean (SCSI problem ?)
On Tue, 24 Sep 2002, Angelin Lazarov Lalev wrote: > I think I have a problem. From time to tme, apparently when the disk > activity of my IBM SCSI disk becomes higher, > all disk operations are suspended for about 30 seconds. After that all > continues ok, but the following log messages are written to the syslog. > Is that normal? > > Sep 18 16:39:53 ns1 /kernel: (da0:ahc0:0:6:0): SCB 0x15 - timed out ... This just means that the driver waited for IO to complete and it never happened so it reset the bus. > And this is what my kernel prints when I'm booting. > ... > Aug 21 10:07:39 ns1 /kernel: ahc0: adapter> port 0xd000-0xd0ff mem 0xcd00-0xcd000fff irq 10 at device > 6.0 on pci0 > Aug 21 10:07:39 ns1 /kernel: aic7890/91: Ultra2 Wide Channel A, SCSI > Id=7, 32/253 SCBs > Aug 21 10:07:39 ns1 /kernel: pci0: graphics accelerator> at 9.0 irq 10 I noticed both the ahc and mga are on irq 10. I've had some real problems with Matrox cards sharing irqs with other devices. Try moving the card order on the PCI bus. This is just a hunch. > Aug 21 10:07:40 ns1 /kernel: Waiting 15 seconds for SCSI devices to settle > Aug 21 10:07:40 ns1 /kernel: Mounting root from ufs:/dev/da0s1a > Aug 21 10:07:40 ns1 /kernel: da0 at ahc0 bus 0 target 6 lun 0 > Aug 21 10:07:40 ns1 /kernel: da0: Fixed Direct > Access SCSI-3 device > Aug 21 10:07:40 ns1 /kernel: da0: 80.000MB/s transfers (40.000MHz, > offset 31, 16bit), Tagged Queueing Enabled > Aug 21 10:07:40 ns1 /kernel: da0: 8748MB (17916240 512 byte sectors: > 255H 63S/T 1115C) You might also try with tagged queuing disabled. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: interrupting target kernel using single sio
On Mon, 9 Sep 2002, John Polstra wrote: > In article <[EMAIL PROTECTED]>, > Hanspeter Roth <[EMAIL PROTECTED]> wrote: > > > > using a single serial cable I can pass control to the remote kgdb > > pressing ctl-alt-del at the target host. > > I'm looking for a means to interrupt the target kernel from the > > remote host. > > I got suggestions using a second serial cable or using ipgdb > > instead. > > Setting remotechat didn't help me. > > > > Is it intended to be able to interrupt the target kernel from the > > remote kgdb by some means at all? Or is this a wrong expectation? > > BSD/OS has a little state machine in its sio driver which notices > if something looking like a kgdb packet comes in and interrupts > the target automatically. It's extremely handy. You just type > "target remote /dev/tty00" into kgdb and the target breaks into the > debugger -- no muss, no fuss. I wish we had this feature too. It > should obviously be under the control of a sysctl to protect against > accidental entry into the debugger. > > Another nice thing about BSD/OS is that when you exit kgdb, the target > OS automatically starts running again. So you can enter and exit the > debugger painlessly, as many times as you'd like. Any chance of getting that from BSD/OS? If not, perhaps we could reimplement. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New scsi_target code
On Thu, 5 Sep 2002, Bruce M Simpson wrote: > On Thu, Sep 05, 2002 at 01:54:08AM -0700, Nate Lawson wrote: > > I have rewritten the scsi_target driver and usermode client with a much > > simpler model suggested by Justin Gibbs. The kernel driver receives > > This sounds like excellent work and I can't wait to check it out further. > Whilst looking into the problem of USB->ATA bridge support I was recently > faced with the problem of writing various ATA->SCSI command translations, > which involved emulating a SCSI device, so I imagine your code should be > very useful. Possibly. I have updated the version online with a patch for -current. It builds and runs but panics in read/write. I'll look into the issues with -current over the weekend. I'm very interested in comments and testing on -stable to help update the general architecture and stability. Thanks, -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: interrupting the remote kernel
On Fri, 6 Sep 2002, Hanspeter Roth wrote: > On Sep 06 at 12:11, Julian Elischer spoke: > > > hit CTL_ALT_ESC on it's keyboard... > > Doing this on the remote host (running gdb) tells me `No debugger in > kernel'. > Doing this on the target host passes control to the remote gdb. Like it should. Julian's suggestions were both for the target host. > But I want to pass control to the remote debugger by issuing > the interrupt command on the _remote_ host (in gdb). You can do this by connecting a second serial cable for a console between your host and target or by using the remotechat option and a single cable. Once you have the serial console, option ALT_BREAK_TO_DEBUGGER allows you to initiate a break using your terminal emulator's "send break" command. > But I want to be able to pass control to the debugger when the > target kernel `hangs', that is when no `ctl-alt-f1', `ctl-alt-del' > has any effect. If the hang is not a system hang, the console break will have an effect. But if the kernel is so hung that the keyboard doesn't work, the remote serial console will not do you any better. In this case you need a box with a real console (i.e. Sun). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
New scsi_target code
I have rewritten the scsi_target driver and usermode client with a much simpler model suggested by Justin Gibbs. The kernel driver receives commands in the form of CCBs via write(2) and returns completed CCBs to usermode via read(2). The included sample client is much simpler as well, implementing only RBC (simple hard drive command set). What is this useful for? It allows anyone with an HBA to emulate various SCSI target devices for reverse engineering initiator implementations, debugging, host-host communication, and many other uses. Because it operates at the CAM layer, it should work with multiple transports (parallel SCSI, FC, ...) Currently, the code works to the point of passing camcontrol rescan and a few reads and writes with two Adaptec 2940U2Ws (ahc driver). However, there is an unknown bug where after a few commands (even just TUR), the target hangs after sending a CTIO and the initiator aborts the command. As such, the code is ALPHA QUALITY and may hang your system. For more information, see the included README and manpages. Comments are needed and appreciated. http://www.root.org/~nate/freebsd/ -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting /dev/smb* to work.
On Wed, 28 Aug 2002, Bruce M Simpson wrote: > On Wed, Aug 28, 2002 at 12:01:15AM +0200, Dan Larsson wrote: > > While trying to get hardware monitoring to work on my computer I > > found the below procedure to enable the smbus device. > > It didn't get me any closer to actually monitoring the hardware with > > xbmon, lmmon or healthd. But the device is there. > > I'd like to add to this. uname is: > FreeBSD triage.dollah.com 4.6-STABLE FreeBSD 4.6-STABLE #1: Sun Aug 25 11:23:33 BST >2002 [EMAIL PROTECTED]:/usr/src/sys/compile/TRIAGE i386 > > pcib0: on motherboard > ... > intpm0: port 0x1040-0x104f irq 9 at >device 7.3 on pci0 > intpm0: I/O mapped 1040 > intpm0: intr IRQ 9 enabled revision 0 > smbus0: on intsmb0 > smb0: on smbus0 > intpm0: PM I/O mapped 8000 > > This supports APM just fine, but SMB goes nowhere. Any clues? When ktracing > processws which use /dev/smb0, it seems that the ioctls simply don't > get handled. I assume this is because something somewhere didn't attach. > >From the above dmesg output I'd infer that nothing's being seen on the smbus. What error is open or ioctl returning in your ktrace? EINVAL? boot -v will give you more info about the attach progress. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Commit schedule for bandwidth delay product pipeline limitingfor TCP
Comments below. Consider them only semi-informed. :)
On Fri, 16 Aug 2002, Matthew Dillon wrote:
> +void
> +tcp_xmit_bandwidth_limit(struct tcpcb *tp, tcp_seq ack_seq)
> +{
> + u_long bw;
> + u_long bwnd;
> + int save_ticks;
> +
> + /*
> + * If inflight_enable is disabled in the middle of a tcp connection,
> + * make sure snd_bwnd is effectively disabled.
> + */
> + if (tcp_inflight_enable == 0) {
> + tp->snd_bwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT;
> + tp->snd_bandwidth = 0;
> + return;
> + }
> +
> + /*
> + * Figure out the bandwidth. Due to the tick granularity this
> + * is a very rough number and it MUST be averaged over a fairly
> + * long period of time.
> + */
> + save_ticks = ticks;
> + if ((u_int)(save_ticks - tp->t_bw_rtttime) < 1)
> + return;
If tp->t_bw_rtttime is greater than save_ticks, the unsigned compare will
fail. Can this ever happen (say with the "tick count goes
backwards" issue)? Why not do this as a signed compare and check for
<= 0?
> + bw = (int64_t)(ack_seq - tp->t_bw_rtseq) * hz /
> + (save_ticks - tp->t_bw_rtttime);
> + tp->t_bw_rtttime = save_ticks;
> + tp->t_bw_rtseq = ack_seq;
> + if (tp->t_bw_rtttime == 0)
> + return;
> + bw = ((int64_t)tp->snd_bandwidth * 15 + bw) >> 4;
I'm not familiar with the paper -- where does 15 come from? I'm guessing
this is a cheap way to perturb the lower bits.
> + tp->snd_bandwidth = bw;
> +
> + /*
> + * Calculate the semi-static bandwidth delay product, plus two maximal
> + * segments. The additional slop puts us squarely in the sweet
> + * spot and also handles the bandwidth run-up case. Without the
> + * slop we could be locking ourselves into a lower bandwidth.
> + *
> + * Situations Handled:
> + * (1) prevents over-queueing of packets on LANs, especially
> + * high speed LANs, allowing larger TCP buffers to be
> + * specified.
> + *
> + * (2) able to handle increased network loads (bandwidth drops
> + * so bwnd drops).
> + *
> + * (3) Randomly changes the window size in order to force
> + * bandwidth balancing between connections.
> + */
> +#define USERTT ((tp->t_srtt + tp->t_rttbest) / 2)
> + bwnd = (int64_t)bw * USERTT / (hz << TCP_RTT_SHIFT) + 2 * tp->t_maxseg;
Would prefer an #undef USERTT after you're done with it.
> + if (tcp_inflight_debug > 0) {
> + static int ltime;
What happens when multiple packets arrive at once. Can they make the
calculation below fail? Do you want splimp or a lock on ltime?
> + if ((u_int)(ticks - ltime) >= hz / tcp_inflight_debug) {
Why the division by a debug enable/disable int? Is it possible for this
to ever be 0 at this point?
> + ltime = ticks;
> + printf("%p bw %ld rttbest %d srtt %d bwnd %ld\n",
> + tp,
> + bw,
> + tp->t_rttbest,
> + tp->t_srtt,
> + bwnd
> + );
> + }
> + }
> + if ((long)bwnd < tcp_inflight_min)
> + bwnd = tcp_inflight_min;
> + if (bwnd > tcp_inflight_max)
> + bwnd = tcp_inflight_max;
> + if ((long)bwnd < tp->t_maxseg * 2)
> + bwnd = tp->t_maxseg * 2;
> + tp->snd_bwnd = bwnd;
> +}
> +
> Index: netinet/tcp_var.h
> ===
> RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v
> retrieving revision 1.82
> diff -u -r1.82 tcp_var.h
> --- netinet/tcp_var.h 19 Jul 2002 18:27:39 - 1.82
> +++ netinet/tcp_var.h 21 Jul 2002 02:26:36 -
>
> @@ -137,6 +139,9 @@
> int t_rtttime; /* round trip time */
> tcp_seq t_rtseq;/* sequence number being timed */
>
> + int t_bw_rtttime; /* used for bandwidth calculation */
Does this need to be signed?
> + tcp_seq t_bw_rtseq; /* used for bandwidth calculation */
> +
> int t_rxtcur; /* current retransmit value (ticks) */
> u_int t_maxseg; /* maximum segment size */
> int t_srtt; /* smoothed round-trip time */
> @@ -144,6 +149,7 @@
>
> int t_rxtshift; /* log(2) of rexmt exp. backoff */
> u_int t_rttmin; /* minimum rtt allowed */
> + u_int t_rttbest; /* best rtt we've seen */
> u_long t_rttupdated; /* number of times rtt sampled */
> u_long max_sndwnd; /* largest window peer has offered */
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD and HP Pavilion computers
It was first supported in 3.3.6 when you load agp.ko. http://www.xfree86.org/3.3.6/i810.html However, I think the recommended config is 4.2.0 for today's agp.ko: http://www.xfree86.org/4.2.0/i810.html I had trouble getting 3.3.6 working with any combination of intel/old linux agp.ko on Linux but have had no problems with FreeBSD, 4.2.0, and the integrated agp kernel module. -Nate On Wed, 14 Aug 2002, Julian Elischer wrote: > Any idea how to set up XFree86 V3.3.6 for the i810 VGA controller? > > > On Wed, 14 Aug 2002, D J Hawkey Jr wrote: > > > In article ><[EMAIL PROTECTED]>, > > [EMAIL PROTECTED] writes: > > > > > > Has anyone managed to get dual-boot working on an HP Pavilion? > > > > > > (Or even a non dual boot?) > > > > Yup. I have a Pavilion 7840. I used FreeBSD's FIPS (I think that's what > > it's called) to cut the Windoze(tm) partition in half, and installed > > FreeBSD in the new space. FreeBSD's boot manager works fine. > > > > > Julian > > > > You have a problem, or just looking ahead? > > Dave > > > > -- > > > > Windows: "Where do you want to go today?" > > Linux: "Where do you want to go tomorrow?" > > FreeBSD: "Are you guys coming, or what?" > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP monitoring
On Tue, 13 Aug 2002, Sean Hamilton wrote: > Also, forgot to mention, I will need to look inside TCP streams, and know > which user owns them, and which packets pertain to which TCP stream, which > is why I was thinking a module would be more suitable. If I did this in user > space, I'd have to reconstruct the streams myself (but as I understand, that > isn't amazingly difficult.) > > sh pcap(3) does fast usermode packet capture via BPF ports/net/libnids does TCP stream reassembly Running things in the kernel does not automatically make them fast unless your CPU usage is maxed by boundary crossings. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI device emulation using SCSI host controller
Yes. sys/cam/scsi/scsi_target* /usr/share/examples/scsi_target On Tue, 13 Aug 2002, Semen A. Ustimenko wrote: > Hi! > > I beg you all pardon for a question not related directly to FreeBSD, but > if the answer is ``yes'', then I believe FreeBSD will be in deal. > > The question is: "Can I emulate a SCSI device (tape, if that matters) > using usual SCSI host controller and specific software, or I will > definitely need specific hardware?" > > Thanks! > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Freezing Freebsd (4.3/4.6)
You could start by sending full dmesg and pciconf -l output. You should also enable ddb and see if you can enter the debugger when the box freezes. If so, the output of "trace" and "ps" would be useful. On Thu, 8 Aug 2002, Yanko Yanez Keller da Costa wrote: > Just another thing... > Last week I put a w2k box to play music and have no problem, so I > eliminate the hardware problem... > > Maybe a ESS driver problem > Something not freeing in the code using all the resources??? > > How can I see or test if I can not have any core dump or list > the resources beeing used? > > Thanks... > > On Wed, 7 Aug 2002, Yanko Yanez Keller da Costa wrote: > > But if I listen music for more than 3/4 hours my freebsd box freeze and I > > can only turn off/on. Nothing in logs. Just a crash msg in /var/log/wtmp > > > > I think was a 4.3 issue but when upgrade to 4.6 I have the same > > behaviour. > > > > Any ideas ? > > > > This is a Compaq armada e500. > > > > - FreeBSD noteyy.lasalle.tche.br 4.6-STABLE FreeBSD 4.6-STABLE #2: Fri Jul > > - pcm0: port 0x3000-0x30ff irq 11 at device > > 8.0 on pci0 > > - root ttyv0 Ter ago 6 12:03 - crash (22:08) > > - xmms 1.2.7 > > > > > > > > Yanko > > -- > > Centro Universitario La Salle > > http://www.unilasalle.edu.br/~yanko To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: floating point exceptions
On Fri, 5 May 2000, Martin Cracauer wrote: > In <[EMAIL PROTECTED]>, Nate Lawson wrote: > > I am running FreeBSD 4.0-RELEASE on x86 with gcc 2.95.2 and the > > httperf-0.6 port gives a SIGFPE and dumps core when run against a system > > that has no web server running. (The default behavior is to measure > > localhost when no arguments are specified). > > > > It seems this is caused by a divide by zero error since the delta between > > connections ends up being zero. The author suggest that the divide > > should return a defined value, Inf, according to the IEEE floating point > > standard. FreeBSD generates SIGFPE. I temporarily patched the code > > locally to check for a delta of zero and arbitrarily set it to 1.0 so > > that the divide succeeds and everything comes out ok without crashing. > > FreeBSD up to 3.x defaults to have exceptions unmasked. > > This was changed before 4.0 and should be in 4.x/4-STABLE and in > 5-current. > > Are you sure you get this on a real 4.0 system, not one from a few > weeks before release? If so, what is the version of > /usr/include/machine/npx.h? It should be 1.18. Of course, the kernel > should be complied with it in case this is a source-updated system. > > Anyway, the solution is fpsetmask, as others noted. > > Also note that FreeBSD/gcc/ANSI C 89 have a few other problems with > IEEE 754 compatibility so that we can't claim conformity in any case. > > Please check the mail archives on www.freebsd.org, this has been > discussed every 7 months for the last 5 years now. Thanks for the information. I checked the system again and it is indeed 4.0-2127-CURRENT (ie. just before 4.0-RELEASE). I will upgrade. David, is it possible to add the following to the httperf port? #ifdef __FreeBSD__ fpsetmask(~FP_X_DZ); #endif Thanks, Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: floating point exceptions
I am running FreeBSD 4.0-RELEASE on x86 with gcc 2.95.2 and the
httperf-0.6 port gives a SIGFPE and dumps core when run against a system
that has no web server running. (The default behavior is to measure
localhost when no arguments are specified).
It seems this is caused by a divide by zero error since the delta between
connections ends up being zero. The author suggest that the divide
should return a defined value, Inf, according to the IEEE floating point
standard. FreeBSD generates SIGFPE. I temporarily patched the code
locally to check for a delta of zero and arbitrarily set it to 1.0 so
that the divide succeeds and everything comes out ok without crashing.
Is FreeBSD's behavior correct? Why or why not? You can use the included
code snippet to verify that this occurs.
Thanks,
Nate
-- Forwarded message --
Date: Mon, 24 Apr 2000 15:54:38 -0700 (PDT)
From: David Mosberger <[EMAIL PROTECTED]>
To: Nate Lawson <[EMAIL PROTECTED]>
Subject: Re: patch to httperf-0.6
>>>>> On Mon, 24 Apr 2000 15:37:21 -0700 (PDT), Nate Lawson <[EMAIL PROTECTED]> said:
Nate> On x86. Your code generates SIGFPE, not SIGBUS sorry. Here
Nate> is a code snippet which generates SIGFPE as well.
Nate> main() { float a, b, c;
Nate> a = 1.0; b = 0.0; c = a/b; }
Nate> This seems to be correct behavior.
No, IEEE says that the exceptions should be disabled by default. You
should get Inf instead of SIGFPE.
--david
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
