Re: Restartable system call behaviour
On Wed, 2006-Feb-01 11:44:08 +, Pete French wrote: >I have a piece of coode which does some networking, in which I see read >and write calls failing with 'Interrupted system call' from time to time. You will get EINTR if the interrupt occurs before any data is read or written. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dhclient wedged
On Tue, 2006-Jan-31 15:38:53 -0500, Lodewijk Vge wrote: >On 31-jan-2006, at 14:13, Brooks Davis wrote: > >>At the very least I need a coredump and your executable so I can >>look at variables >>in receive_packet. > >I accidentally killed it with my attempts to make it dump a core >file. so, what should I do the next time it happens to make it dump >core? "kill -QUIT ..." is the generic answer. sigaction(2) provides the definitive list of which signals default to dumping core. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dc0: watchdog timeout and nve0: device timeout
On Tue, 31 Jan 2006 11:30:02 +0300, Gleb Smirnoff wrote:
> On Tue, Jan 31, 2006 at 03:08:03AM -0500, Anish Mistry wrote:
> A> After updating to STABLE today I'm getting the following message with
> A> my dc and nve NICs every few seconds. UP, AMD64. A kernel from last
> A> Thursday was fine.
> A>
> A> dc0: watchdog timeout
> A> nve0: device timeout (4)
>
> Can you try to backout the code in sys/dev/pci to Thursday? If this
> doesn't help, you probably need to do a binary search in this small
> timeframe.
I think I found the problem - the merge was not quite correct, and
the PCI interrupt rerouting was disabled for some reason.
Warner, is there a reason for hiding the "Try to re-route interrupts"
code behind an apparently "ifdef 0" case? Well, okay, most probably
there is a reason, since you've done it, but... it breaks my re0 card
and it also seems to break Anish's hardware :)
BTW, the commit message was not quite correct - rev. 1.302 was not
really merged, it's included in my patch here. Also, rev. 1.305 of
pci.c seems to have more than just adding the PCI_FIND_EXTCAP method -
there are a couple of offset fixes that I also included in the patch
while trying to come as close to the -CURRENT code as possible; could
you check if they actually apply to -STABLE?
Anyway, here's a patch that fixes it for me, although most probably
the __PCI_REROUTE_INTERRUPT chunk should be sufficient. Warner, if
you want more details, I could help with debugging this - on my
system, the re0 card definitely needs this rerouting. I've posted
some verbose boot output with explanations at
http://people.FreeBSD.org/~roam/pcirouting/
The patch itself is also there in case it gets munged by the mail
swervers along the way.
Index: src/sys/dev/pci/pci.c
===
RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.292.2.6
diff -u -r1.292.2.6 pci.c
--- src/sys/dev/pci/pci.c 30 Jan 2006 18:42:10 - 1.292.2.6
+++ src/sys/dev/pci/pci.c 31 Jan 2006 10:57:32 -
@@ -428,7 +428,7 @@
ptrptr = PCIR_CAP_PTR;
break;
case 2:
- ptrptr = 0x14;
+ ptrptr = PCIR_CAP_PTR_2;
break;
default:
return; /* no extended capabilities support */
@@ -447,10 +447,10 @@
}
/* Find the next entry */
ptr = nextptr;
- nextptr = REG(ptr + 1, 1);
+ nextptr = REG(ptr + PCICAP_NEXTPTR, 1);
/* Process this entry */
- switch (REG(ptr, 1)) {
+ switch (REG(ptr + PCICAP_ID, 1)) {
case PCIY_PMG: /* PCI power management */
if (cfg->pp.pp_cap == 0) {
cfg->pp.pp_cap = REG(ptr + PCIR_POWER_CAP, 2);
@@ -1040,7 +1040,8 @@
}
if (cfg->intpin > 0 && PCI_INTERRUPT_VALID(cfg->intline)) {
-#ifdef __PCI_REROUTE_INTERRUPT
+#if defined(__ia64__) || defined(__i386__) || defined(__amd64__) || \
+ defined(__arm__) || defined(__alpha__)
/*
* Try to re-route interrupts. Sometimes the BIOS or
* firmware may leave bogus values in these registers.
Hope this helps!
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
"yields falsehood, when appended to its quotation." yields falsehood, when
appended to its quotation.
pgpSZ7qvqy2jJ.pgp
Description: PGP signature
Re: weird buildworld consequences in 6.0
On Sat, 2006-Jan-28 16:24:49 -0500, David Coder wrote: ># ldd /usr/obj/usr/src_6/bin/sh/sh >/usr/obj/usr/src_6/bin/sh/sh: >libedit.so.5 => /lib/libedit.so.5 (0x2809c000) >libncurses.so.6 => /lib/libncurses.so.6 (0x280b2000) >libc.so.6 => /usr/local/lib/pluginwrapper/flash6.so (0x280f5000) That last line is definitely wrong. Check /etc/libmap.conf (maybe rename it temporarily). -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfilter + bge strangeness
On Sat, 2006-Jan-28 16:32:54 +0100, Koen Martens wrote: >Yesterday night, i was going to send the message below. However, >just before pressing send, i found a solution to the problem: >disable checksum checks (ifconfig bge0 -rxcsum -txcsum). Though this >is a solution, it has me puzzled. Is this a bug^H^H^Hfeature of >6-STABLE, as it works with 5.4. > >With 5.4, there was only the rxcsum option for the bge card, not a >txcsum. It worked fine with rxcsum enabled on 5.4.. At least on Solaris, you need to disable checksum offloading to pass packets through an IPfilter firewall (check the IPFilter FAQ). I gather that the outgoing packets are marked as "checksum valid" so the NIC doesn't re-compute the checksum and it winds up wrong. If you disable IPfilter and just use the box as a straight router, does it then work when you enable checksum offloading? If so, then I think you've bumped into the same (mis-)feature. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hi all.. Novice user having woes getting Atheros card up in FreeBSD 6.0
On Thu, 2006-Jan-26 20:10:56 -0800, resonant evil wrote: >Hi there.. So I can't use this wireless card at all right now? Damn why >did I buy this thing then.. People from the mailing list showed me this one >so I ordered it :-( That exact card, or that model number? One major problem with PC hardware is that vendors regularly "update" the electronics without changing the model designations. This doesn't affect Windoze users because they provide updated drivers to match. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Panic on S3 suspend
#x27;,
ifi_mtu = 1500, ifi_metric = 0, ifi_baudrate = 1000,
ifi_ipackets = 38910, ifi_ierrors = 0, ifi_opackets = 12023,
ifi_oerrors = 0, ifi_collisions = 0, ifi_ibytes = 50025442,
ifi_obytes = 4410559, ifi_imcasts = 350, ifi_omcasts = 0, ifi_iqdrops = 0,
ifi_noproto = 0, ifi_hwassist = 7, ifi_epoch = 0, ifi_lastchange = {
tv_sec = 1138272696, tv_usec = 308610}}, if_multiaddrs = {
tqh_first = 0xff0035cb2c40, tqh_last = 0xff0035cb2d40},
if_amcount = 0, if_output = 0x802dd820 ,
if_input = 0x802de190 ,
if_start = 0x801b8fc0 ,
if_ioctl = 0x801b9670 ,
if_watchdog = 0x801b9990 ,
if_init = 0x801b9370 ,
if_resolvemulti = 0x802deb70 , if_spare1 = 0x0,
if_spare2 = 0x0, if_spare3 = 0x0, if_drv_flags = 64, if_spare_flags2 = 0,
if_snd = {ifq_head = 0xff002a34a500, ifq_tail = 0xff002a34a500,
ifq_len = 1, ifq_maxlen = 511, ifq_drops = 0, ifq_mtx = {mtx_object = {
lo_class = 0x8053a340, lo_name = 0xff941020 "bge0",
lo_type = 0x803f685d "if send queue", lo_flags = 196608,
lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0},
mtx_lock = 4, mtx_recurse = 0}, ifq_drv_head = 0x0, ifq_drv_tail = 0x0,
ifq_drv_len = 0, ifq_drv_maxlen = 511, altq_type = 0, altq_flags = 1,
altq_disc = 0x0, altq_ifp = 0xff941000, altq_enqueue = 0,
altq_dequeue = 0, altq_request = 0, altq_clfier = 0x0, altq_classify = 0,
altq_tbr = 0x0, altq_cdnr = 0x0},
if_broadcastaddr = 0x803f6b60 "ÿÿ", if_bridge = 0x0,
lltables = 0x0, if_label = 0x0, if_prefixhead = {tqh_first = 0x0,
tqh_last = 0xff9412b0}, if_afdata = {0x0 },
if_afdata_initialized = 2, if_afdata_mtx = {mtx_object = {
lo_class = 0x8053a340, lo_name = 0x803f684d "if_afdata",
lo_type = 0x803f684d "if_afdata", lo_flags = 196608, lo_list = {
tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4,
mtx_recurse = 0}, if_starttask = {ta_link = {stqe_next = 0x0},
ta_pending = 0, ta_priority = 0,
ta_func = 0x802dcab0 ,
ta_context = 0xff941000}, if_linktask = {ta_link = {
stqe_next = 0x0}, ta_pending = 0, ta_priority = 0,
ta_func = 0x802dab00 ,
ta_context = 0xff941000}, if_addr_mtx = {mtx_object = {
lo_class = 0x8053a340,
lo_name = 0x803f6841 "if_addr_mtx",
lo_type = 0x803f6841 "if_addr_mtx", lo_flags = 196608,
lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0},
mtx_lock = 4, mtx_recurse = 0}}
(kgdb)
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: manual escape to debugger on serial console not working?
On Thu, 2006-Jan-26 11:17:21 +0200, Niki Denev wrote: >Ah, this was the missing link :) >I completely forgot the part that i must >type "~~#" to actually send a BREAK. I rarely use the ssh break so I set it to something other than '~' in my .ssh/config so it doesn't clash with (eg) tip. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: xorg-server 6.9.0 won't build on 4.11-stable
On Wed, 2006-Jan-25 13:23:52 +, Steve O'Hara-Smith wrote: >On Wed, 25 Jan 2006 23:29:20 +1100 >Mark Andrews <[EMAIL PROTECTED]> wrote: >> Or I suspect you can get away with just using gcc33 which >> has va_copy() builtin. > > Hmm I have gcc34 courtesy of some other ports build dependency, >so I suppose I could add a USE_GCC=3.4 to the Makefile. > > Would it be a good idea to add this to all the xorg-6.9 Makefiles ? Looking at bsd.gcc.mk, maybe "USE_GCC=3.3+" would be acceptable. I find ports that depend on specific version of gcc annoying - it's not especially fast to build and having multiple versions lying around starts to eat disk space. > As an aside running a 6.8.2 server on top of 6.9 libraries produces >an interesting effect - after a few minutes the mouse pointer dives to the >left side of the screen and then will only move vertically. I don't think that should happen, though I doubt that combination is officially supported. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Xorg server dies
On Sat, 2006-Jan-21 16:56:41 -0800, Tushar Desai wrote: >I'm tracking the FREEBSD-6 STABLE branch and when I try to configure >Xorg X server it just dies on me, when I try to test run. There's nothing obviously wrong in Xorg.0.log - it looks like the X server started successfully and then shut down cleanly. Presumably the xorg.conf.new is the result of "Xorg -configure". How about supplying the command line you used to start X, the output written to the console and anything else you did between starting X and getting the console prompt back. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with PCI SATA Controller
Mark Kirkwood wrote: Unfortunately the sii 3112 is a bit of a horrornumerous people have experienced issues with it (web search on "sii 3112 data corruption" makes quite interesting reading). I seem to recall a posting suggesting that some success might be had with just 1 SATA channel (i.e 1 disk) attached, however I can't find it offhand. Cheers Mark *sigh* I guess I'll be taking the card back and getting some PATA -> SATA adaptors. I need two drives as I wish to do a mirrored RAID, which with this card seems to be out of the question. Regards, Peter Hoskin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problems with PCI SATA Controller
Hi, I've had a number of problems with this card. Please note I'm not using this as a RAID card. [EMAIL PROTECTED]:3:0: class=0x010400 card=0x61121095 chip=0x31121095 rev=0x02 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'SiI 3112 SATALink/SATARaid Controller' class= mass storage subclass = RAID Under FreeBSD 5, it'd continually generate timeout - WRITE_DMA errors which would make the disks operate really slow... I found many others to be having the same issue and they recommended dropping back to PIO mode... seems I cannot do that on this card. Under FreeBSD 6-BETA5, I never managed to get it installed... was getting an error DANGER WILL ROBINSON Under FreeBSD 6-RELEASE, I wasn't able to install with multiple disk slices which I have attempted several times for the machine to lock up when it gets to 28% copied each time. I ended up partitioning as a single slice and strangely this worked. However, it seems whenever there is a bit of disk activity the machine locks up just after dumping the error ata2: DISCONNECT requested Strangely this seems to happen everytime if I begin accessing both disks I have attached to this controller at once. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CFLAGS vs COPTFLAGS for building kernel modules
/usr/share/examples/etc/make.conf v1.265.2.1 states: # To compile just the kernel with special optimizations, you should use # this instead of CFLAGS (which is not applicable to kernel builds anyway). # There is very little to gain by using higher optimization levels, and doing # so can cause problems. # #COPTFLAGS= -O -pipe Unfortunately, it seems that kernel modules are build with CFLAGS rather than COPTFLAGS. This is somewhat embarrassing when CFLAGS includes options that don't work in the kernel but aren't explicitly disabled (eg -msse3). My make-foo isn't up to quickly isolating the problem. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SUMMARY: Fast releases demand binary updates..
On Thu, 2006-Jan-12 00:08:56 -0800, Jo Rhett wrote: >I'm going to kill this topic. Results of my trolling to see if we could >get any committer interest in this topic are: Deliberate antagonism of most (if not all) FreeBSD developers is unlikely to assist in getting your ideas listened to. You also left out the results of the assorted claims/promises you made: 1) "core" deliberately killed suggestions of improved binary update processes You have yet to produce the e-mails demonstrating this. 2) Your PRs get ignored. This has been disproven by examining the status of your PRs. It appears that you never received the status updates, but equally, you never appear to have bothered following up any of the PRs. 3) Your promise to provide a formal requirements specification defining exactly what you are asking for. Again, you have yet to produce the information you promised. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Wed, 2006-Jan-11 23:22:53 -0800, Jo Rhett wrote: >I am deliberately trolling: not to cause grief, but to see if there are any >bites on the topic. So far it's just people insulting my intelligence and >cut&pasting web pages to me. Going out of your way to antagonize FreeBSD developers is not the way to get your ideas adopted. >And yes, I'm using a macro I call '-core' to refer to group of people who >can absolutely kill something like this because they don't like the food >coloring in it. It's a convenience for me. As a convenience for the rest of us, how about using same terminology as the rest of the Project. It makes it much simpler if we all agree on the meanings of the words we use. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SHA1_Update() produces wrong results for large buffers
On Tue, 2006-Jan-10 02:59:53 +0300, Pavel Gorshkov wrote: >The problem is that the asm-optimized version fails on large input >buffers. Attached is a test program, which mmaps a file and then >just feeds its contents to SHA1_Update(): "openssl sha1" agrees with the shared version on -current. ># exits immediately, displaying a WRONG hash value >./sha1test.md-static test-1.5G >747cd7172ce7737d1735cf936c0d69ce0f733fcd I get this on 7-current as well. Copying the relevant bits from libmd and compiling it myself, I get the same behaviour. The fact that this exits virtually instantly strongly suggests that it is broken (rather than the shared version). My initial guess is that an operation on the length is overflowing 32 bits. Unfortunately, the asm is rather opaque - it was auto-generated by a perl script that doesn't seem to included in the repository. (There is a sha1-586.pl in openssl but it generates different code). As far as I can determine, the asm code (sha1_block_x86) is designed to process an integral number of SHA1 blocks of input, leaving the remainder to be processed in the C code. Using the debugger, the asm code is not looping when passed 1610612736 (1.5G) - which explains the rapid exit and incorrect result. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NIC card problems
Peter Jeremy wrote: >Real DEC Tulip cards do this when running Tru64 as well. My guess is that >it's a bug in the NIC. (And it looks like AMDtek have copied it). Peter, Warner, Stefan, et al.: I just found this thread on the mailing list, and am responding to it, a year later :) I also believe the problem is a bug in the NIC as well, since the ADMTek 985 appears to not listen to the "automagic buffer underrun recovery" command. Silby added some patches to mbuf allocation in 2003 after stress testing dc(4), which improves the situation somewhat (ability to sustain the traffic longer) but doesn't solve it. While my system doesn't reboot (panic), it will often hang as a result of this. What happens then is that when the interface tries to transmit, a "No buffer space available" error occurs. If one can access the console, it can be rescued by bringing the interface down and then up again using ifconfig(8). This will reset the card and presumably flush the buffers. I wonder if any work has been done on the driver in -CURRENT (and I am too lazy to look), but in the next few weeks the machine is getting overhauled from 4.11 to 6 (reformat/reinstall) so we shall see if it does anything. -- Peter C. Lai Dept. of Neurobiology Yale University School of Medicine http://cowbert.2y.net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Fri, 2006-Jan-06 02:34:40 -0800, Jo Rhett wrote:
>On Thu, Jan 05, 2006 at 10:47:38AM +0100, Patrick M. Hausen wrote:
>> While I agree with much of your reasoning, I know exactly zero
>> people running a modified kernel of any version of Windows,
>> Mac OS X or Solaris, to name just three commercial OS's.
>
>You're tickling a different subject here. All three of these operating
>systems have loadable kernel modules that work.
As does FreeBSD.
> I mean, they dynamically
>load the modules they need, and you can disable kernel modules in
>configuration files. FreeBSD has loadable kernel modules, but they don't
>autoload (you have to modify rc files)
This isn't quite true. FreeBSD does not currently have the tools to
automatically load kernel modules for most hardware device drivers and
they need to either be built into the kernel or specified in
loader.conf. Writing a tool to do this automatically would be fairly
simple - either use pciconf(8) and a database of PCI ID to driver
mappings or (as Solaris and X do) load every module and see if it can
attach to anything, unload it if it can't. To date, no-one has been
sufficiently motivated to do so.
FreeBSD will autoload kernel modules for many software functions if
their functionality is required (NFS, SysV IPC, firewalls). In some
cases this is automatic (NFS client loads automatically if NFS
filesystems are found). In other cases, (eg firewalls) you need to
configure the functionality anyway.
> and you can't trim down the kernel
>to minimize unused memory without recompiling.
In the absence of tools to automatically detect your configuration and
load the appropriate modules, GENERIC includes a fairly standard set
of drivers that also exist as modules. GENERIC probably could be cut
down somewhat but this isn't the forum to discuss that.
>To give you a specific example: if we could remove NFS and the 3ware
>driver from the kernel in a configuration file, we could probably run
>GENERIC.
IMHO, NFS server could be removed without problems (it will autoload),
as could tw{a,e} (which are loadable). NFS client can't be removed
because it has to be built in to support diskless operation.
>hog we have to remove on small footprint systems
FreeBSD has never claimed to optimally support small footprint systems
without customisation. There are too many variables and some kernel
functionality can't be readily converted to modules (eg IPv6 support).
In any case, the way to minimise the kernel footprint is to statically
load all the required functionality and not have any modules.
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Fri, 2006-Jan-06 03:03:18 -0800, Jo Rhett wrote: >> Bottom line: Once code exists, then support can be talked about.. > >This is bullhockey and you know it. Once the project is done, we'll >authorize a budget for it? Once the season is over we'll know who should >be on the starting team? In general, volunteer projects have a surfeit of ideas and a shortage of real implementations. The Project is never going to agree to import an idea without some substance. > Yeah, hindsight is sweet. But this isn't a >simple change. It will require very close integration with the installation >and kernel modules at least (and probably more). So having some sort of >consensus that (a) the project has interest and (b) what flavors would be >acceptable to the existing groups - are both necessary for this project to >even mumble it's first line of code. In which case you need to move this thread to freebsd-arch where these sort of issues are discussed. You need to clearly define your goals and suggest a design to meet them. If your idea has merit, you'll be able to convince at least one committer to work with you to implement your design. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [EMAIL PROTECTED]: Re: [Flow-tools] Memory leak ?]
[flow-capture process too large] On Fri, 2006-Jan-06 11:08:54 +0200, Todor Dragnev wrote: >Can someone help with this ? Help how? AFAIK, flow-control/flow-capture is not a FreeBSD port so finding someone here with knowledge of it may be difficult. If you think it's a problem with FreeBSD, you're going to need to supply more information so that we can help you. >>>I use flow-control from about 1 week. My OS is FreeBSD 6.0-RELEASE #0 >>>for AMD64. All works fine but yesterday I found this in dmesg: >>> >>>Jan 4 21:30:58 katana kernel: swap_pager_getswapspace(16): failed >>>Jan 4 21:30:58 katana kernel: swap_pager_getswapspace(12): failed >>>Jan 4 21:30:58 katana kernel: swap_pager_getswapspace(6): failed ... >>>518 root1 960 2648M 104M select 0:33 0.00% flow-capture This means you've run out of swap space. The top output shows that the offending process was flow-capture. Presumably you already knew this much. >>>My starting line for flow-capture is: >>> >>>/usr/local/bin/flow-capture -p /var/run/flow-capture.pid -n 287 -N 0 -w >>>/var/log/netflows/ -S 5 /127.0.0.1/8899 >>> >>>Is that huge memory usage is memory leak or I do something wrong ? The command line means nothing to me. How big a process size were you expecting? If you kill and restart the process, how big is it initially? What libraries is it using? What does it do? >>I think the easiest way to start looking at this would be to run >>flow-capture under a memory debugger of some sort, like efence >>(Electric Fence Malloc Debugger). Have you tried this suggestion? Note that phkmalloc (the standard FreeBSD malloc) has some good debugging facilities built in - check malloc(3) for details. >I'm running flow-capture on AMD64 on Fedora Core 3 with no problems. >The only issue I run into is lack of disk space! Sometimes 50GB is not >enough! Unfortunately, Jonathan didn't say what the process size he saw was so this doesn't help much. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, 2006-Jan-05 01:37:27 -0800, Jo Rhett wrote:
>No. I want a binary update mechanism. Obviously if we have local
>configuration options we'll have to compile our own binaries. But doing
>the work of tracking system updates currently requires us to build our own
>patch tracking mechanism, and then re-write it for every new release.
If you're willing to do your own compiles:
1) CVSup or cvs update to whatever branch you want
2) make build{world,kernel}
3) make DESTDIR=/updates install{world,kernel}
4) mergemaster -D /updates
5) rsync or similar
It seems fairly obvious that you are frustrated by FreeBSD's inability
to meet your needs as far as updating is concerned. I suspect I'm not
alone in being uncertain exactly what your requirements are and what
additional features FreeBSD needs to satisfy you. How would you like
to write a formal requirements specification and post it here (or in
-arch).
>It's not a recompile issue. It's a tracking/update/backout issue. I don't
>mind recompiling, if I could somehow push the updates to all the right
>systems and they would have it stored somewhere that they were patched...
Have you looked at tools like Bcfg2 ( http://www.mcs.anl.gov/cobalt/bcfg2/ )?
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, 2005-Dec-22 13:17:30 -0800, Jo Rhett wrote: >But FreeBSD Update suffers from all of the same limitations that I've been >describing because of lack of integration with the Core OS. > >1. modified kernels are foobar > ..yet are practically mandatory on production systems > >2. modified sources are foobar > ..yet many common production situations require source compilation options So you want to be able to make arbitrary changes you your source code and compilation options and then expect the FreeBSD project to provide a tool that will apply binary fixes to the resultant executables? I don't know that modified kernels are mandatory. A lot of work has been going on to reduce the need to re-compile the kernel for common situations. Likewise, I don't know that "many common" and "require" go together - IMHO, 'desire' or 'would be nice' are more appropriate descriptions. Would you care to provide some details of what you believe can be done to reduce your need to re-compile the OS. I'm not sure that FreeBSD Update is totally unusable for you. If you have the situation where you have a modified FreeBSD that you need to roll out to a large number of hosts, you just need to have your own FreeBSD Update server - you test the changes in your environment and then roll them out as you require. AFAIK, Colin hasn't fully productised FreeBSD Update to date but has not rejected the idea of doing so. >3. FreeBSD Update can't handle updates of jails and other situations that >package systems deal with just fine. I don't run jails so I'm not familiar with the problems here. Maybe you'd like to explain the problems you run into. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Thu, 2005-Dec-22 13:10:19 -0800, Jo Rhett wrote: >I and many others have offered to work on this. The core team has >repeatedly stated that they won't integrate the efforts, which makes >os-upgrade capability minimal and easily broken. (see current efforts) On Thu, 2005-Dec-22 14:05:32 -0800, Jo Rhett wrote: >On Thu, Dec 22, 2005 at 01:30:41PM -0800, Brooks Davis wrote: >> This statement makes no sense. The core team wouldn't have much to >> do with this other than possibly being involved in making any service >> official. Also, approval is never given to include a non-existent >> feature. Easy, binary updates sound like a great idea, but without >> seeing actual code thats all anyone can say other than offering advice. >> If volunteering is conditional on acceptance of the work, that's a >> chicken-egg problem and is not resolvable. We simply can't maintain >> quality if we accept non-existent code just because the idea sounds >> good. > >What are you talking about? These issues have been repeatedly brought up >in the mailing lists, and what it would require to make it possible to >handle appropriately (namely, core os packages or a similar versioning >mechanism) and the arguements have often been given. I agree with Brooks. I don't recall ever seeing a message from -core (or anyone else talking on behalf of the Project) stating that code to make binary updates possible would not be integrated. For that matter, I don't recall ever seeing code offered to implement such a feature. Core OS packages have been discussed but I don't recall the idea ever being vetoed. Some work have been done in breaking bits of the base OS out into packages (perl, games and UUCP come to mind) but packaging the entire system is a major undertaking. In any case, I don't see how packaging the system would help you. Taking Solaris as an example of an OS which is broken up into lots of packages, patches don't replace whole packages, they replace individual files. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [SOLVED] Re: NFS UDP mounts on RELENG_6?
On Mon, 2005-Dec-19 01:37:44 -0800, Jon Dama wrote: >I haven't see any evidence that suggests using NFS with UDP is actually >useful. IMO, its a false economy. On modern hardware anyway. Keep in mind that NFS was written to run on a 25MHz (or so) 68020. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS UDP mounts on RELENG_6?
On Mon, 2005-Dec-19 08:39:47 +0100, Oliver Brandmueller wrote: >While NFS stalls at the same time ntp to the same host works without >problems. So it's not a comüplete stall of all UDP traffic.I guess >there's something that's only triggered by a certain combination of >things. How about big/fragmented UDP packets? NFS typically sends 8K packets which are split into 6 UDP packets. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Need help with crash analysis
I had another crash and this time ran kgdb and typed "bt full" with the
following output. As a last resort I rebuilt the kernel with HZ=2000,
instead of 1000 and haven't had a crash since. My wireless card seems
more responsive under load too. Ping times are lower when I'm
transferring large files across the network.
[GDB will not be able to debug user-mode
threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x10
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc066ccec
stack pointer = 0x28:0xe36198bc
frame pointer = 0x28:0x0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 38 (swi1: net)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 3m17s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (158 pages)
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x1c
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc0549f20
stack pointer = 0x28:0xe5084c8c
frame pointer = 0x28:0xe5084ccc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 36 (swi4: clock)
trap number = 12
... ok
chunk 1: 1023MB (261802 pages) 1007 991 975 959 943 927 911 895 879
863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591
575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303
287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt full
#0 doadump () at pcpu.h:165
No locals.
#1 0xc053b467 in boot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:399
first_buf_printf = 1
#2 0xc053b818 in panic (fmt=0xc06dc865 "%s")
at /usr/src/sys/kern/kern_shutdown.c:555
td = (struct thread *) 0xc22ec4b0
bootopt = 260
newpanic = 0
ap = 0xc22ec4b0 ""
buf = "page fault", '\0'
#3 0xc06b4b14 in trap_fatal (frame=0xe361987c, eva=0)
at /usr/src/sys/i386/i386/trap.c:831
code = 40
type = 12
ss = 40
esp = 0
softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27, ssd_dpl =
0, ssd_p = 1, ssd_xx = 0, ssd_xx1 = 0, ssd_def32 = 1, ssd_gran = 1}
#4 0xc06b480d in trap_pfault (frame=0xe361987c, usermode=0, eva=16)
at /usr/src/sys/i386/i386/trap.c:742
va = 0
vm = (struct vmspace *) 0x0
map = 0xc073d820
rv = 1
ftype = 1 '\001'
td = (struct thread *) 0xc22ec4b0
p = (struct proc *) 0xc234b000
#5 0xc06b43f3 in trap (frame=
{tf_fs = -480182264, tf_es = 40, tf_ds = 40, tf_edi = 0, tf_esi =
-315641204, tf_ebp = 0, tf_isp = -480143192, tf_ebx = -315638608, tf_edx
= 791735, tf_ecx = -1073475471, tf_eax = 1, tf_trapno = 12, tf_err = 0,
tf_eip = -1067004692, tf_cs = 32, tf_eflags = 66050, tf_esp = 16777216,
tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:432
td = (struct thread *) 0xc22ec4b0
p = (struct proc *) 0xc234b000
sticks = 3814824188
i = 0
ucode = 0
type = 12
code = 0
eva = 16
#6 0xc06a041a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
No locals.
#7 0xc066ccec in zz0e373a4d ()
No symbol table info available.
(kgdb) quit
On Fri, 2005-12-16 at 18:17 -0500, Peter D. Quilty wrote:
> I have a Dell Inspiron 9100 laptop that has been crashing lately. It
> seems to happen when there is a moderate disk load and the network load
> is > 6 Mbits/sec. I can usually replicate it by running "portsdb -fUu"
> while downloading or copying large files across the network. I have
> tried the following in an attempt to isolate the problem, but nothing
> has worked.
> * disabling ACPI
> * disabling hyperthreading
> * disabling SMP
> * switching back to the 4BSD scheduler from ULE
> I ran kgdb against kernel.debug and the crash dump, but don't quite know
> how to interpret it
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Sat, 2005-Dec-17 18:19:25 -0700, Scott Long wrote: >Peter Jeremy wrote: >>I think FreeBSD Update shows the way forward but IMHO there needs to >>be an "official" binary update tool accessible from www.freebsd.org. > >FreeBSD Update was written by, and is continuously maintained by the >actual FreeBSD Security Officer. I realise that. But nowhere does it state that it is an "official" Project tool (though it no longer seems to include the "this is not sanctioned by the FreeBSD Project" disclaimer that I thought it used to have). > If the only barrier to acceptance is that it's not distributed from the >FreeBSD.org domain, then a) that's a silly argument, and b) it's easily >solvable so long as Colin agrees. I agree it's easily solvable. I disagree that it's a silly argument. As an end user, I would expect to find online updates to Solaris at sun.com, Microsoft at microsoft.com, etc. If I run FreeBSD, I would expect to find FreeBSD updates at freebsd.org, not daemonology.net. A quick search starting at www.freebsd.org does not throw up any references to FreeBSD Update. If I didn't know that Colin Percival was the SO, there would be nothing to suggest that FreeBSD Update had any relationship to the FreeBSD Project. Computer users are slowly cottoning on to the idea of computer security. This is good. Encouraging them to find an apparently arbitrary site that says "upgrade your operating system here" does nothing to reinforce the concept that people should be careful about downloading software from "unknown" sources. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Sat, 2005-Dec-17 23:35:34 +0100, Kövesdán Gábor wrote: >I agree. And after all, tracking a security branch isn't too difficult, ... ># cd /usr/src ># patch < /path/to/patch ># cd /usr/src/gnu/usr.bin/cvs/cvsbug ># make obj && make depend && make && make install ># cd /usr/src/gnu/usr.bin/send-pr ># make obj && make depend && make && make install > >Is that difficult? Speaking as a developer, I think it's trivially easy. As an end user, I don't think this is acceptable. Firstly, it requires that the user has installed the src distribution - which is optional. Secondly, the user is expected to use development tools without understanding what they do - this is scary for them. Running the above commands is OK as long as nothing goes wrong but the "support" group (who inhabit -questions and answer seemingly silly questions) are going to have to cope with people who've made a typo somewhere in the sequence and can't explain exactly what they did - without putting them off FreeBSD. I think FreeBSD Update shows the way forward but IMHO there needs to be an "official" binary update tool accessible from www.freebsd.org. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Need help with crash analysis
I have a Dell Inspiron 9100 laptop that has been crashing lately. It seems to happen when there is a moderate disk load and the network load is > 6 Mbits/sec. I can usually replicate it by running "portsdb -fUu" while downloading or copying large files across the network. I have tried the following in an attempt to isolate the problem, but nothing has worked. * disabling ACPI * disabling hyperthreading * disabling SMP * switching back to the 4BSD scheduler from ULE I ran kgdb against kernel.debug and the crash dump, but don't quite know how to interpret it or where to go from here. I've attached my kernel config file, dmesg.boot, and the outputs from kldstat and kgdb. I recently upgraded my router/access point at home from 802.11b to 802.11g to take advantage of the faster network cards in my laptops and I am wondering if that could be exposing a bug or race condition. I tried putting my network card back in 11b mode (instead of 11g) and I don't see the problem nearly as often. Does anyone have any suggestions as to how to troubleshoot this further? I have saved the relevant kernel files and crash dumps, in case I need to reference them again. -- Peter D. Quilty [EMAIL PROTECTED] 703-906-5633 GnuPG Key: http://users.adelphia.net/~pdquilty/gpg-pubkey.asc GnuPG Key Fingerprint: A46A 0E56 D13E 5617 4696 2B04 0D0C E34D CB6D D107 makeoptions DEBUG=-g machine i386 cpu I686_CPU ident "PDQ.9100" options INCLUDE_CONFIG_FILE options ROOTDEVNAME=\"ufs:ad0s1a\" options SMP options SCHED_ULE options PREEMPTION options MPTABLE_FORCE_HTT options IPI_PREEMPTION options INET options FFS options SOFTUPDATES options UFS_DIRHASH options MSDOSFS options SMBFS options CD9660 options PROCFS options PSEUDOFS options COMPAT_LINUX options LINPROCFS options COMPAT_43 options KTRACE options SYSVSHM options SYSVMSG options SYSVSEM options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV options ADAPTIVE_GIANT options NETSMB options NETSMBCRYPTO options LIBMCHAIN options LIBICONV device apic device isa device pci device ata device atadisk device atapicd device atapicam options ATA_STATIC_ID device scbus device da device cd device pass device atkbdc device atkbd device psm device vga device splash device sc device npx device pmtimer device cbb device pccard device cardbus device sio device miibus device bfe device wlan device wlan_wep device ath_hal device ath_rate_sample device ath device loop device mem device io device random device ether device pty device snp device bpf device uhci device ehci device usb device umass device ums device firewire device sbp device sound device snd_ich Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-RELEASE #16: Wed Dec 14 14:34:52 EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PDQ.9100 ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400> Hyperthreading: 2 logical CPUs real memory = 1073389568 (1023 MB) avail memory = 1041309696 (993 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard netsmb_dev: loaded kqemu version 0x00010200 kqemu: KQEMU installed, max_instances=4 max_locked_mem=129932kB. ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pci_link0: irq 11 on acpi0 pci_link1: irq 11 on acpi0 pci_link2: irq 11 on acpi0 pci_link3: irq 11 on acpi0 pci_link4: on acpi0 pci_link5: irq 11 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_acad0: on acpi0 battery0: on acpi0 acpi_l
Re: indefinite wait buffer: Does this indicate hardware issue?
On Sat, 2005-Dec-17 04:06:36 +0800, Xin LI wrote: >No, it's sometimes other, and is quite infrequent. On the other hand, >neither SMART nor error has reported some incident, so I was stuck >when looking on hardware issues, as the message does not indicate >which disk(s) may have problem... A hardware error should have been reported as such. But if you suspect a disk problem, try dd'ing the swap partition (or the whole disk) to /dev/null. If you can read the whole partition, you can probably write to it. (Or you could dd /dev/zero to the partitions whilst swap is not attached - eg in single user after boot). If you suspect retries are a problem, monitor the I/O rate with iostat or systat and see if it suddenly drops. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Release schedule for 2006
On Fri, 2005-Dec-16 21:20:44 +0100, Melvyn Sopacua wrote: >Features=0xa7e9f9bf >+ Features2=0x180 > >Q: What are those extra features and are they useful? ;-) This is just printing out the CPU features bitmasks. The difference is that the CPU identification code in 6.x looks at the bitmap returned in %ecx after a cpuid 1. The features were always there, 6.x just prints them out. As for usefulness... EST - Enhanced SpeedStep TM2 - Thermal Monitor 2 >+uhci0: [GIANT-LOCKED] >+uhci1: [GIANT-LOCKED] >+uhci2: [GIANT-LOCKED] > >Q: Again - is this formatting or are these (and the ones below) still under >Giant in 6.x but not in 5.x? No. 6.x is just more verbose. I thought these had all been hidden behind 'verbose' as they are primarily hints to the developers. >-pci0: at device 29.7 (no driver attached) >+ehci0: mem >0xf4fffc00-0xf4ff irq 11 at device 29.7 on pci0 >+ehci0: [GIANT-LOCKED] > >Kudos! I'm still trying to get my USB2 to do anything more than probe :-( >-Timecounter "TSC" frequency 1398819442 Hz quality 800 >-Timecounters tick every 10.000 msec >+Timecounter "TSC" frequency 1398819606 Hz quality 800 >+Timecounters tick every 1.000 msec > >Q: This is a big scarey difference :p This isn't a printf bug I presume? Which bit? The TSC is notoriously unstable and a relative change of 1.2e-7 can be ignored. If you look at kern.clockrate, you'll see that hz now defaults to 1000. >-acd0: CDRW at ata1-master PIO4 >+acd0: CDRW at ata1-master UDMA33 > >That's *very* nice! Again, that's just a change in defaults. Problems were found with DMA to ATAPI devices so the decision was made to default to PIO4 in 5.x. You can set hw.ata.atapi_dma to 1 in 5.x if you want to (see acd(4)). -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel cpu entries
On Thu, 2005-Dec-15 17:59:38 +, Pete French wrote: >Got some curiuous results when I tested this today by the way. >I have a twin processor PIII machine. Did a parallel compile on >it. The actuall wall clock time is faster when I add the 586 >back in. *but* if you look at the user and system times, the >user time has dropped slightly, but the system tme has gone up >a lot. So its doing more work, but with a slghtly greater amount >of parallelism allow it to finish faster in real time. > >Can anyone explain that I can't see anything in the kernel source code to explain it. Since you don't mention actual times, is the difference statistically significant? (see src/tools/tools/ministat) -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: shmget errors
On Thu, 2005-Dec-15 15:22:04 +0100, Oliver Fromme wrote:
>Also, the following shell snippet might be helpful:
>
>ipcs | awk '($1=="m"){print $2}' | xargs -n 1 -t ipcrm -m
ipca -ma | awk '$9 == "0"{print $2}' | xargs -n 1 -t ipcrm -m
has the advantage of only removing segments with no processes attached.
>It removes _all_ shared memory segments. Be careful:
>Don't do that while any programs are still running which
>use SysV shared memory.
As with deleting open files, the segment doesn't disappear immediately
but only after the last process detaches (see IPC_RMID in shmctm(2)).
> You can check that by looking at
>the output of ``ipcs -p'': If the process IDs listed under
>the CPID and LPID columns don't exist, chances are that the
>memory segment isn't in use anymore.
Looking at NATTACH in "ipcs -a" is a better approach.
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel cpu entries
On Thu, 2005-Dec-15 12:53:59 -, Steven Hartland wrote: >Same here be nice to get a catagoric answer to this. > > Steve >- Original Message - >From: "Randy Rowe" <[EMAIL PROTECTED]> >> >>I have multiple dual and quad Pentium Pro machines running 4.x that have >>been >>remarkably stable using the I686_CPU setting (kudos to the developers!!). >>So I add myself to the list of those that have been removing the >>I586_CPU option. UTSL: The i586 optimised routines were only ever enabled if the CPU was identified as a 586. And these routines have been disabled since mid-2001. See my mail in the "Odd performance problems..." thread for more details. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Odd performance problems after upgrade from 4.11 to 6.0-Stable
On Wed, 2005-Dec-14 16:17:38 -0700, Scott Long wrote:
>Also, taking out CPU_I586 is usually a bad idea. It offers no
>performance penalties (unlike CPU_I386 and maybe CPU_I486), but
>enables things like optimized bcopy.
This doesn't quite mesh with my reading of -current and -stable.
The following refers only to x86 kernels.
Kernel references to {bcopy,bzero,copyin,copyout}() indirect
through {bcopy,bzero,copyin,copyout}_vector. This is initialised
to generic_{bcopy,bzero,copyin,copyout} in i386/i386/support.s.
*_vector is over-ridden with optimised routines as follows:
bcopy_vector:
- (effectively) never
bzero_vector:
- i486_bzero if (cpu_class == CPUCLASS_486) in sys/i386/i386/identcpu.c
copyin_vector:
- (effectively) never
copyout_vector:
- (effectively) never
The i586 optimised routines are defined in sys/i386/i386/support.s but
(effectively) never used since v1.101 of sys/i386/isa/npx.c changed
'#ifdef I586_CPU' to '#ifdef I586_CPU_XXX' (in 2001/05/22 21:20:49).
Even then, they are inside if (cpu_class == CPUCLASS_586) which is not
true for P-II and later CPUs.
That said, it might be worthwhile revisiting the issue of cpu-specific
optimisations. If there is better code then generic_*() for Athlon
or P4 CPUs, we should implement it. If there isn't, we can get a
(slight) performance improvement by removing the indirection through
*_vector - I suspect that CPUs can't predict/pipeline an indirect
branch as well as a direct branch.
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 random freezes
On Wed, 2005-Dec-14 08:28:26 -0400, fredthetree wrote: >i've only used the generic 6.0 kernel > ># kgdb kernel.debug /var/crash/vmcore.1 ... >#6 0xc07f6dca in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >#7 0xc0a7cf08 in ?? () Unfortunately, it's frame 7 and below that is crucial. Was #7 the last line or did you cut the backtrace off? The top frames are the kernel handling the trap. It looks like the trap occurred in a KLD - in this case, try running: # cd /usr/obj/usr/src/sys/GENERIC (or name of kernel config) # make gdbinit[this just copies a few config files for kgdb] # gdb kernel.debug /var/crash/vmcore.1 (kgdb) kldsyms (kgdb) where Hopefully this will decode #7 and you can provide a few more frames. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 random freezes
On Tue, 2005-Dec-13 13:43:13 -0400, fredthetree wrote:
>[/var/crash/vmcore.1]
>--
>Unread portion of the kernel message buffer:
>
>
>Fatal trap 12: page fault while in kernel mode
>fault virtual address = 0x10
That's a NULL pointer de-reference - it Shouldn't Happen(TM). Can you
get a backtrace from kgdb ("where")?
>[vmcore.0]
>--
>Unread portion of the kernel message buffer:
>ÃwÄ0¿Á0ÂÁ"ÀíÁÀJðÂÄüÂ3ÄÓÂÀíÁÀóÂDþÁÀóÂðCÂÀíÁ1Ä
>ÃðÚÃÀíÁ´ÂÄBð°ÄÁÀíÁ"[EMAIL PROTECTED]@
>--
The most likely problem is that your vmcore file doesn't match your kernel.
Are you running kgdb with the same kernel as was running when the system
crashed? (If you don't have that kernel handy, you might as well delete
vmcore.0).
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 random freezes
On Mon, 2005-Dec-12 18:57:24 -0800, Atanas wrote: >When I plug a keyboard, there's no response at all - no LEDs, no VTYs, >Ctrl-Alt-Esc, etc. You might think of "hint.atkbd.0.flags" not being set >properly, but it's right (i.e. unchanged, it appears to default to that >on i386 5.x+) and other machines with identical configuration do accept >keyboard. Note that PS/2 keyboards aren't hot-pluggable and attempts to do so can have deleterious effects on your keyboard and/or motherboard. In any case, the probe/attach sequence relies on the kernel being in a reasonably sane state (and I'm not sure if it will detect the keyboard as a console device except at boot time). If the keyboard has been plugged in since the system booted, do you still get the same "no response"? If so, the kernel has wedged at a fairly low level and I'm not quite sure how to proceed other than by enabling the sanity checks that other people have mentioned (eg WITNESS, INVARIANTS) and hoping they catch something. >the next crash. But if I have no keyboard response I won't be able to >save it, right? True. But DDB has been designed to rely on a fairly minimal subset of kernel functionality and often works, even though the system appears frozen. >I do not know what a serial console is and would need some time to get >along with it. Would I get something in addition to what I can get from >the standard console? I only mentioned serial consoles on the off-chance that you had one. Whilst it may not help here, serial consoles have a number of advantages when managing remote equipment (ie equipment not sitting on your desk) - you can access the console remotely and log all console output on another computer (either cross-connect com1/com2 on pairs of hosts or get a multi-port serial card to manage a number of systems). If your BIOS can handle serial communications, you virtually never need to physically visit your servers. For details, check out: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html I personally use ports/comms/conserver-com to manage about 50 assorted Unix/FreeBSD servers and switches at work. >The "dumpdev" variable seems to default to AUTO, i.e. trying to use the >first swap device if it's bigger than the RAM (in my case yes), so I >guess I don't need to touch it. It seems that my suggestion has been obsoleted by changes to the startup scripts since I checked last. >After the downgrade we could eventually set a test bed and start >hammering it with requests. The problem would be how to trigger the >crash and whether we would be able to reproduce it at all. Depending on your application and the interfaces to it, it might be feasible to either tee live traffic into both systems and just junk the responses from your test bed, or "record" live traffic and replay it into your test bed. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 random freezes
On Mon, 2005-Dec-12 22:21:52 -0400, fredthetree wrote: >I just wanted to chime in and say I've had my 6.0-RELEASE #0 freeze up twice >in the past few days. never once had it happen with 5.x. everything locks, >no keyboard response, no mouse, and after several minutes it reboots itself, >and savecore starts up during boot.. This suggests you've had a panic (or something that develops into one). If you've got a crashdump, you can probably get enough information out of it for people to get an idea of what is wrong. Please have a look at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebg-gdb.html -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 random freezes
On Mon, 2005-Dec-12 13:15:55 -0800, Atanas wrote: >I have 3 machines running 6.0-RELEASE, and recently 2 of them started >freezing once a day or so. There are no error messages on the console or >in the system logs. > >The first one I put in production about a month ago and it was working >flawlessly until it got some load and now it started freezing almost >every day. The second one has exactly the same behavior - it was fine >when doing nothing (a couple of weeks), and started freezing when loaded. Define "freezing": Does it respond to pings? Can you switch VTYs? Do the num-lock/caps-lock LEDs respond? Do some processes seem to freeze before others? I suggest you add the following to your kernel config: options KDB # Enable kernel debugger support. options DDB # Support DDB. When it hangs, break into DDB (Ctrl-Alt-Esc on the console or BREAK on a serial console). As a start, run 'show lockedvnods' and 'ps'. My guess is that you'll see a lock that has a number of waiters - which is probably the culprit. Use 'panic' or 'call doadump' to get a crashdump and then you can use kgdb to rummage around once you reboot - see http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebg-gdb.html >< makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols I suggest you add this back in. Without it, you can't debug any crash dumps that you manage to get (and add "dumpdev" to your rc.conf). >Now the only reasonable option for me (I mean for production and in >relatively short term) seems going downward to 5.4 and wait until 6.x >get more stable Whilst I realise that you can't have production machines freezing on schedule, your assistance in providing more information about your problem will help make 6.x more stable. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic
On Wed, 2005-Dec-07 13:34:53 -0800, Vizion wrote: >Well having run many very large scale projects myself I find it difficult to >accept either implication of this perspective. There's a massive difference between running a large commercial project and running a large open source project using volunteers. On a commercial project, you can direct someone to do something and they have a choice of either doing it or finding another job. On a volunteer project, there's a limit to how far you can push someone to do something they don't enjoy before they just leave. > The first implication is that >we should be complacent about it and not seek to find a method to improve the >process. I don't think anyone is suggesting this. In my experience, the FreeBSD project is always open to process improvements - this is especially obvious in the documentation and release engineering areas. >>Most of our really top >>notch developers are actually very bad at documenting their work (I don't >>mean bad at being timely with it, I mean that they are bad at DOING it), and >>frankly their time is better spent elsewhere. > >That is a judgment call - franky my experience has been that developers who >are bad at ensuring their work is well documentated are second rate rather >than top rate developers. Software developers are notoriously poor at writing documentation for non-technical people. There are probably very few developers who enjoy writing end-user documentation (and can write). In my experience, especially on large projects, it's rare for developers to write the end-user documentation. They may write a rough outline but it's the technical writers who actually do the documentation. The problem is finding people with technical writing skills who are interested in helping with FreeBSD. It's also worth noting that a number of FreeBSD developers are not native English speakers. It's probably unreasonable to expect them to write polished English documentation. >What I have found works in development is to create team relationships that >cover design, development and documentation. I agree that this is a good approach. It's similar to the 'surgical team' approach that Brooks recommends in "The Mythical Man-Month". I think that this does happen to some extent in FreeBSD but agree it could be more widespread. (Though it is probably harder to put it into practice in a distributed, volunteer project than when the team share a cubicle). >My view would be that the freebsd project might do well to consider >implementing a "no release without quality documentation assurance" policy. ... >development is so good. It deserves better and more professional attention to >the role of end user documentation. Are you volunteering? -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpu-timer rate
On Wed, 2005-Dec-07 15:39:04 -0800, Ed wrote: >With all due respect, "vmware plays fast and loose with the clocks" is not >a satisfactory technical explanation. Hi-jacking unrelated e-mail threads and top posting is not good etiquette either. >It is no doubt true that those of us who run FreeBSD in VMWare are a >minority of a minority, I run FreeBSD in VMware at work. After installing vmware-tools and telling VMware to use the host clock I haven't seen any clock problems (definitely in 5.x and I don't recall seeing any in 4.x or 6.x). -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpu-timer rate
On Wed, 2005-Dec-07 03:51:47 -0800, Ed wrote: >I certainly do not have a full understanding of the interactions between >the various FreeBSD software timers and i386 hardware clocks, but I do know >this is not the first time we've seen a problem with the APIC/ACPI >timers/clocks. You have a totally different problem. In your case the system is not keeping correct time - this is because VMware does not provide stable clock interrupts - probably due to interactions between VMware and the host OS. In kama's case, the interrupt rate reported by vmstat -i does not match the numbers reported by kern.clockrate. There is no indication that the system is not keeping correct time. >Again, I'm no expert, but clock problems do keep cropping up here on >the -STABLE list, and the explanations for them to date have not been >consistent. AFAIR, all the problems reported here have been related to VMware clients. And as someone stated "VMware plays fast and loose with clocks". >I'm sure I'm not the only end-user who would appreciate it if the core team This is nothing to do with the core team. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpu-timer rate
On Mon, 2005-Dec-05 10:15:52 -0800, Kevin Oberman wrote: >> On Mon, Dec 05, 2005 at 09:42:08AM +0100 I heard the voice of >> kama, and lo! it spake thus: >> > >> > I appreciate that you took time to answer about the different >> > clocks. But that does not answer why vmstat -i shows a rate of 2000 >> > when I have set the hz to 1000. >> >> Because the rate is always twice hz. > >While I will concede that I have no explanation, but on all of my systems >rate = HZ +/-1. I have never seen a case where rate/2 = HZ. Basically, it depends on what clock(s) your kernel is using. Traditionally, FreeBSD/i386 uses the one of the i8254 counters to generate hz (on irq0) and the RTC to generate profhz/stathz (on irq8). In this case, the rate on those interrupts should match the values reported by kern.clockrate. On SMP machines, this approach is fairly expensive because the interrupts need to be forwarded to all CPUs using IPIs. In early February, jhb implemented an alternative approach using the local APIC clock (sys/i386/i386/local_apic.c v1.13 and other files). Since every CPU has a LAPIC, every CPU gets its own clock interrupts without needing IPIs. The downside is that there's only a single LAPIC so a single hardware clock interrupt needs to generate separate (and independent) hz/tick and stathz/profhz clocks. Since the clocks need to be independent (to make process statistics meaningful), this implies that the hardware (LAPIC) clock (cpu0) needs to be faster than hz. The original commit ran LAPIC at hz*3 but this was later changed to hz*2 to reduce overheads. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpu-timer rate
On Fri, 2005-Dec-02 14:32:58 +0100, kama wrote:
>I am just wondering why the cpu-timer is doubled from what I set in
>kern.hz?
>
># vmstat -i
>interrupt total rate
...
>cpu0: timer 14314031 1999
>Total 14750922 2060
>
># sysctl -a | grep hz
>kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }
There's only a single timer but FreeBSD needs two independent clocks.
The 'tick' clock is used to update the TOD counters and decide when to
reschedule processes. The 'stathz' is used to collect statistics on
CPU utilisation ('profhz' is used instead if any process is using
profiling). Since processes tend to synchronize to 'tick' the
statistics clock needs to be independent to ensure that a CPU utilisation
is correctly allocated.
In order to simulate two clocks, FreeBSD runs the hardware clock at a
high rate and uses two different divisors for the soft clocks (/2 for
tick, /3 for profhz and /15 for stathz). Larger divisors are better
for utilisation statistics but increase clock interrupt overheads.
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.0 cron is running on GMT
On Sat, 2005-Nov-26 22:27:49 -0700, Brett Glass wrote: >I am wondering if I shouldn't just redo everything in the system that >has to do with time zones and time keeping (deleting files and re-creating >them if need be), reboot, and see what happens. That's as good as idea as any other. I know cron on my 6.0 system behaves correctly so I suspect it's something odd on your system. Last suggestions/guesses: - If you run "/sbin/rcorder -s nostart /etc/rc.d/*", does /etc/rc.d/cron come after /etc/rc.d/adjkerntz? - If /etc/localtime is a symlink, is the filesystem it points to mounted when cron starts? (Look thru the rcorder above to check). - Do "at" jobs run at local or UTC time? - If you run "date" and "date -u" as a cron job, what do they report? > I've never seen a good >explanation of all of the sysctl variables, environment variables, files, >etc. that control it, especially since (as I understand it) the responsibility >has been shifted from the kernel to libraries. Is there a summary out there? The timezone has always been the responsibility of userland in FreeBSD. The kernel provides a UTC timestamp to the ctime(3) functions, which are solely responsible to mapping UTC to local time based on $TZ or /etc/localtime. adjkerntz(8) is responsible for handling the RTC's offset between UTC and localtime. If /etc/wall_cmos_clock exists, it means that CMOS clock keeps local time. If that file does not exist, it means that the CMOS clock keeps UTC time. adjkerntz sets machdep.wall_cmos_clock. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.0 cron is running on GMT
On Sat, 2005-Nov-26 15:07:26 -0700, Brett Glass wrote: >By the way, the "date" command does report the correct time. It's cron >that seems to be getting the time wrong. You haven't accidently created a line that looks like 'TZ=' in the crontab have you? Is this affecting all users or just one? -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Recurring problem: processes block accessing UFS file system
On Mon, 2005-Nov-21 21:23:10 -0600, Greg Rivers wrote: > the >deadlock also occurs under normal operation when no snapshots are running >or have ever been run since boot. It's just much less frequent in this >case. I've also seen this behaviour in both 5.x and 6.0 (I can't recall if it bit me in 4.x). In my case, the trigger is OpenOffice.org - one of the offending processes is almost always OOo/program/pagein. Unfortunately, I haven't been able to get to the bottom of this (and my son isn't happy that OOo keeps deadlocking on him). -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Laptop choices
I have an IBM Thinkpad R51with a Radeon Mobility 9000 M9. It works quite well with FreeBSD 5.4. The only issue I have, is that I cannot have 3d-acceleration and at the same time have suspend-to-ram support. (Theres a huge difference noticable when I run glxgears) The device section in my xorg.conf looks like this: Section "Device" Identifier "Card0" # Driver "ati" Driver "radeon" VendorName "ATI Technologies Inc" BoardName "Radeon R250 Lf [Radeon Mobility 9000 M9]" BusID "PCI:1:0:0" EndSection To enable dri for hardware acceleration I have to set acpi_video_load="NO" in /boot/loader.conf But then it doesn't wake up properly from suspend mode. Setting it to "YES" dri cannot be loaded, but suspend mode works . Sorry, it was some time ago when I configured all the things so I cannot not remember what the problem finally was. (suspend to disk doesn't work at all) The touch pad can easily been disabled in the bios (what I also did, because I don't like it). I hope that helps! Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Swapfile problem in 6?
On Thu, 2005-Nov-17 00:00:03 -0800, Rob wrote:
> The only way I know of how to trigger the deadlock, is to compile
> a new kernel and the 'linking kernel' stage will lock-up the PC.
> With a regular kernel, this takes 2.5 hours until deadlock, but with
> a fully equipped debug kernel it takes about 8 hours
When the first deadlock occurs, you have a fully populated set of kernel
objects (though possibly some of them are in the buffer case rather than
on disk). You should be able to quickly reproduce the panic by running:
# cd /usr/obj/usr/src/sys/<>
# make
(Adjust the directory to suit your config name and MAKEOBJDIRPREFIX).
Alternatively, check out the following lines in /usr/src/Makefile.inc1
# -DNO_KERNELCONFIG do not run config in ${MAKE} buildkernel
# -DNO_KERNELCLEAN do not run ${MAKE} clean in ${MAKE} buildkernel
# -DNO_KERNELDEPEND do not run ${MAKE} depend in ${MAKE} buildkernel
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Swapfile problem in 6?
On Wed, 2005-Nov-16 04:21:09 -0800, Rob wrote: >If not, then what should I remove/keep from the >above list, to allow the deadlock to reappear and >still be able to debug the problem? The minimum you need to get into DDB and use GDB off-line is makeoptions DEBUG=-g options KDB options DDB options BREAK_TO_DEBUGGER -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Swapfile problem in 6?
On Tue, 2005-Nov-15 02:08:12 -0800, Rob wrote: > makeoptions DEBUG=-g > options INVARIANTS > options WITNESS > options WITNESS_KDB > options KDB > options DDB > options DDB_NUMSYM > options GDB > >Is that enough? If your system is headless, you probably want 'options BREAK_TO_DEBUGGER' as well. First question is: Does the system still deadlock? INVARIANTS and WITNESS will have added sanity checks which might have picked up the problem. >1) Can I debug a kernel that does not crash, but > just hangs in a deadlock? Everything seems to > be frozen, except pinging the PC Have a look at http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html and ddb(4). Unless you have another system handy, you might like to print out ddb(4) - it's difficult to read man pages when you're in the kernel debugger :-). >2) Is such debugging possible on a headless PC > without a keyboard attached? > I do have serial console access. Yes. See above URL. The advantage is that you can (hopefully) capture a log of your debug session. Send a serial BREAK and you should get a DDB> prompt. Basically, wait until your system deadlocks. BREAK into DDB. As a start, run 'show lockedvnods', 'ps'. My guess is that you'll see a lock that has a number of waiters - which is probably the culprit. Use 'panic' to get a crashdump and then you can use kgdb to rummage around once you reboot - see http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html If in doubt, post the output from the above commands here and someone will hopefully provide further input. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Swapfile problem in 6? (was: 6.0: during kernel compilation, 'kernel linking' freezes PC)
On Mon, 2005-Nov-14 22:38:59 -0800, Rob wrote: >--- Kris Kennaway <[EMAIL PROTECTED]> wrote: >> Since you can compile a kernel without it, add DDB, >> WITNESS and INVARIANTS support, then trigger the >> deadlock with the swapfile, break to DDB and >> examine the state of the machine. See the chapter >> on kernel debugging in the developers handbook for >> more instructions. > >Thanks, but for now, I cannot compile a new kernel, >because the kernel compilation terminates with >insufficient swap space error. Unfortunately, we're probably not going to be able to provide much assistance without knowing more about what is happening when it deadlocks. (As Kris requests). BTW, you should probably make sure you keep "makeoptions DEBUG=-g" and set dumpdev in rc.conf (which will make it possible to capture and use a crashdump if you can trigger one). > Apparently 32 MB is >not enough for a new kernel compilation. Quite probably. >This is my partitioning: > /dev/ad0s1a253678 34446 19893815%/ > /dev/ad0s1b 39848 8168 3984820%(swap) > /dev/ad0s1d253678 152958 8042666%/var > /dev/ad0s1e253678 6016 227368 3%/home > /dev/ad0s1f 1624576 727274 76733649%/usr Since your /home is almost empty, how about (temporarily) moving the contents into /usr and swapping onto ad0s1e rather than into a swapfile. This should at least enable you to build a debug kernel. >First I used 128 MB swapfile on root partition; >then tried again with a 128 MB swapfile on /var. >However, exactly the same deadlock occurs: Have you pre-allocated the swapfile or is it being allocated as necessary? If the latter, try "dd if=/dev/zero of=swapfile bs=1m count=128" -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB Card Reader Permissions
On Tue, 2005-Nov-08 20:54:41 +, Andy Fraser wrote: >I've read the man pages for devfs, devfs.conf and devfs.rules. devfs.rules >looks like what I need but I can't work out what I actually need to do or how >to test a rule without rebooting. I also found the man pages very opaque but some googling turned up a site with a tutorial (unfortunately, I didn't keep a record). -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4 -> 6.0 buildworld failure
On Sat, 2005-Nov-05 21:17:58 +0100, Markus Buretorp wrote: >I'm trying to upgrade from FreeBSD 5.4-STABLE to 6.0. I've done a cvsup >to RELENG_6 and RELENG_6_0, I've ran make cleanworld, make clean, rm -rf >/usr/obj/*, etc; but nothing helps. ... > /usr/src/lib/libkvm/kvm_proc.c:108: error: storage size of 't_cdev' > isn't known I've just done a buildworld of RELENG_6 on 5.3 without problems so I suspect it's something you've done. It looks very much like kvm_proc.c is being built using the wrong include files - the ones in /usr/include/sys rather than the ones in /usr/src/sys/sys. Where is this error occurring during the buildworld? (What are the latest lines beginning '>>>' and '===>') What non-standard bits do you have in your command line, /etc/make.conf or MAKEOBJDIRPREFIX? -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nogobble, nogobble
On Fri, 2005-Nov-04 06:39:46 -0800, David Wolfskill wrote: >So I'm wondering if, perhaps, it might help to consider the following >variant of the current theme: > >* Decompose GENERIC into a set if "functional blocks" of config info. > >* Then make GENERIC itself merely a set of "include" directives, perhaps > with some commentary. One downside is that you wind up in a maze of twisty little include files, all similar, and working out the final configuration becomes a nightmare. Another problem is tracking changes - someone makes a change to .../conf/GENERIC_foo and your kernel config stops working because GENERIC_foo is included by GENERIC_bar which you are using. I can see the purpose of having a DEFAULTS file - a small number of "mandatory" options that cause problems when people delete them. IMHO, before proceeding any further down this path, config(8) needs to grow a "preprocess only" option to flatten the input into a single file. "options INCLUDE_CONFIG_FILE" and config.c should contain this flattened input. (For bonus points, include an option to make "nofoo" disable "foo" so that the output only includes active directives). Someone mentioned CISCO IOS directives - the biggest problem with the CISCO approach is that the configuration is defined as a set of differences from a default configuration but (AFAIK) the default configuration isn't formally documented (ie in IOS config format). FreeBSD does document the defaults. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.0 Released
[-current dropped] On Fri, 2005-Nov-04 16:33:10 -0200, Renato Botelho wrote: >one example, perl warning me about my locale: What version of perl? Was it compiled under RELENG_6 or a previous install? >perl: warning: Setting locale failed. >perl: warning: Please check that your locale settings: >LC_ALL = "en_US.ISO8859-1", >LANG = "en_US.ISO8859-1" Does the directory /usr/share/locale/en_US.ISO8859-1 exist? Do the relevant files (LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC and LC_TIME) exist in the directory? >And on another machine, when I go to gnome, this start with locale >US-ASCII and I can't use acents on OpenOffice. Is this locale set via LC_ALL or within OOo itself? I'm not sure that 'US-ASCII' should exist - the locale name should be en_US.US-ASCII. That said, I believe this is the correct behaviour. You have specified that you only want to be able to use 7-bit ASCII which doesn't include accents. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: compile error - bus error
On Fri, 2005-Nov-04 07:12:54 +, Jayton Garnett wrote: >Yes it is reproducable, it just happened while compiling mysql41-server. >While trying to compile apache20 a short while ago the computer rebooted >itself, before that it had the same error so I tried compiling again and >thats when it rebooted. That sounds very much like hardware. I'd check the hardware before anything else - faulty fans, loose cards/cables, give memtest86 a run. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: compile error - bus error
On Thu, 2005-Nov-03 07:39:02 +, Jayton Garnett wrote: >Just to confirm my suspicions, while compiling apache 2.0.55 on a fresh >install of FreeBSD 5.4 with fresh cvsup'd ports tree I got an error, the >error stated : Bus error. >This is a hardware fault is it not? or is it some other error? I'd lean towards it being a hardware problem but you haven't provided enough information to really answer this. Is the problem reproduceable? If the bus error repeats in exactly the same place then it's may be a problem with the toolchain. If the error moves around then it's probably hardware. Do you have problems compiling anything else (buildworld in particular). -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: math/grace port: "libXcursor.so.1.0" not found ??
On Tue, 2005-Oct-25 20:41:33 -0700, Rob wrote:
>2. Create $HOME/.grace/gracerc.user and put
> one line in this file:
> USE "pow" TYPE f_of_dd FROM "/usr/lib/libm.so"
> (this is the example from the Grace UsersGuide)
Does grace work correctly if you don't include this line?
>3. Start grace like this:
> $ xmgrace
> Shared object "libXcursor.so.1.0" not found,
> required by "xmgrace"
"libXcursor.so.1.0" is not a valid FreeBSD shared library name.
The closest is /usr/X11R6/lib/libXcursor.so.1
> handle =
>(void *)dlopen("/usr/lib/libm.so", RTLD_LAZY)
It doesn't make sense for an attempt to dlopen libm to complain about
an X library.
You might like to try asking the port maintainer (see the Makefile).
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: new FreeBSD-webpage
On Thu, 2005-Oct-06 20:22:06 +0300, Tuomo Latto wrote: >Lynx Version 2.8.5rel.1 (04 Feb 2004) doesn't seem to handle XML, >so when you're in a pinch with your fw/gw machine that doesn't have >X installed and you quickly need to access eg. some documentation >on the site, you're out of luck. The first three links at the top of the new home page are in XML - they appear to be the RSS news feeds. The bits of documentation that I've looked at are all in HTML. It might be nicer if the RSS links were more clearly identified as such but claiming that the website is incompatible with lynx is a bit of an exaggeration. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: new FreeBSD-webpage
It's definitely a totally different look. At this stage, I'd say that I prefer the old site - but that's a very personal opinion and is at least partially based on familiarity. I'm disappointed that the daemon has gone from the top banner. I'd suggest that the most important feature that is missing is a website map. The website looks nothing like it used to and many of my commonly referenced links are no longer on the home page. Finding my way around is going to be very time consuming until I learn my way around it. On the positive side, I'm glad that it's still usable with a text browser. On the downside, I notice it now uses cookies. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: bridge(4) removed from HEAD
On Wed, 2005-Sep-28 08:13:32 +0200, Simon L. Nielsen wrote: >Considering that we only (more or less) document -STABLE branches in >the Handbook it's not a big rush, as long as it's mentioned before 7.0 >comes out, though documentation about if_bridge in the Handbook would >of cause be nice, considering it's also in 6.0 :-). bridge(4) no longer exists in -current and is (effectively) deprecated in 6.x. It is desirable that this is documented in the handbook and the filtering bridges article. I though that the Project guidelines stated that deprecated features had to be retained for a full major release but having checked the Committers' Guide, it's only required that they be retained until the next major release. This means that it's not essential that the handbook be updated before 6.0-RELEASE but it is desirable that the updates occur early in the 6.x-STABLE cycle to provide adequate notice. There's no reason why the handbook can't mention both (or, preferably, all three) bridging devices - it just needs to mention that if_bridge doesn't exist in 5.x -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3 -> 5.4 breaks ATA (Intel ICH2)
On Fri, 2005-Sep-23 22:52:09 -0400, Tim Howe wrote: >I've got several other Pentium 3-based machines running 5.4-RELEASE-p3 >with a GENERIC kernel, and I have a 5.3 installer disk, so my strategy >was to do a minimal install of 5.3, then NFS mount /usr/src and /usr/obj >from my organizational build server and upgrade to 5.4 from there. Did you reboot after the 5.3 install or do the upgrade whilst booted from that install disk? >root filesystem. Further investigation found that it wasn't able to >find the ATA HDD (master on ata0) at all, but could find the ATAPI CDROM >drive (master on ata0). You shouldn't have two masters on ata0. I hope that's a typo. How far through the boot process do you get? I gather the loader runs successfully and loads the kernel but the kernel can't find ad0. Does it find the controller (ata0 or whatever)? -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6-Release Beta 5: extremely slow installation in VMWare 4.52
On Fri, 2005-Sep-23 09:14:17 +, Christoph Sold wrote: >Unfortunately, our corporate firewall blocks anything but http/port80, >https/port443. Thus, neither CVS nor CVSup are an option. in addition, the >install is still running after 24 hours. At this time, the full install churns >slowly against ports/x11-themes. You might like to consider CTM[1]. Whilst you'll need to get the original starting delta via FTP, updates from then on can be e-mailed to you (typically 3 per day for cvs-cur). >One more hint: "calcru: runtime went backwards..." pops up once or twice for >each file. Lots of kernel printf messages won't be helping performance. [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ctm.html -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: High interrupts w/ Cisco 350 card
On Thu, 2005-Sep-22 07:13:29 -0400, Peter D. Quilty wrote: >On Wed, 2005-09-21 at 18:01 +1000, Peter Jeremy wrote: >> Have you tried anything other that FreeBSD 5.4 on your Tecra? > >No, I haven't. It is my primary laptop and I would prefer not to have >to load another OS merely for testing. It would probably be sufficient to boot the first install CD, go into fixit mode, bring up the interface and try to pass some traffic over it. No need for a full install. Other than that, I'm out of suggestions. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: High interrupts w/ Cisco 350 card
On Wed, 2005-09-21 at 18:01 +1000, Peter Jeremy wrote: > On Tue, 2005-Sep-20 19:44:07 -0400, Peter D. Quilty wrote: > >I'm running 5.4-RELEASE-p6 on a Toshiba Tecra M2 laptop. My network > >card is a Cisco 350 PCMCIA card. I'm experiencing a very high rate of > >interrupts during heavy network traffic. > > Not quite. "vmstat -i" reports 173 interrupts/sec. That's not high. > "systat -iostat" shows a ludicrously high interrupt load though. > > I notice that almost all the hardware on your laptop maps to irq 11 - > that's undesirable. Can you convince your BIOS to use different > interrupt mappings? No, the PCI bus is hardcoded to use only irqs 10 & 11. The video card uses 10 and everything else shares 11. > > This Cisco card works fine in every other laptop I have. > > What OS? All are running FreeBSD 5.4-RELEASE. > > I suspect it might be a cardbus problem, but I don't > >know how to resolve it or troubleshoot it any further. > > The PCCard bus is fairly atrocious (basically ISA) but isn't that bad. > I can get roughly wire speed from a 10baseT NIC without serious CPU > strain on a P-233 laptop. > > Have you tried anything other that FreeBSD 5.4 on your Tecra? No, I haven't. It is my primary laptop and I would prefer not to have to load another OS merely for testing. > >interrupt total rate > ... > >irq11: cbb0 cbb1+++ 6773905173 > ... > > /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 > >cpu user|X > > nice| > > system|X > >interrupt|XXX > > idle|XXX > ... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: High interrupts w/ Cisco 350 card
On Tue, 2005-Sep-20 19:44:07 -0400, Peter D. Quilty wrote: >I'm running 5.4-RELEASE-p6 on a Toshiba Tecra M2 laptop. My network >card is a Cisco 350 PCMCIA card. I'm experiencing a very high rate of >interrupts during heavy network traffic. Not quite. "vmstat -i" reports 173 interrupts/sec. That's not high. "systat -iostat" shows a ludicrously high interrupt load though. I notice that almost all the hardware on your laptop maps to irq 11 - that's undesirable. Can you convince your BIOS to use different interrupt mappings? > This Cisco card works fine in every other laptop I have. What OS? > I suspect it might be a cardbus problem, but I don't >know how to resolve it or troubleshoot it any further. The PCCard bus is fairly atrocious (basically ISA) but isn't that bad. I can get roughly wire speed from a 10baseT NIC without serious CPU strain on a P-233 laptop. Have you tried anything other that FreeBSD 5.4 on your Tecra? >interrupt total rate ... >irq11: cbb0 cbb1+++ 6773905173 ... > /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 >cpu user|X > nice| > system|X >interrupt|XXX > idle|XXX ... >cbb0: at device 11.0 on pci2 >cardbus0: on cbb0 >pccard0: <16-bit PCCard bus> on cbb0 >cbb1: at device 11.1 on pci2 >cardbus1: on cbb1 >pccard1: <16-bit PCCard bus> on cbb1 ... >an0: at port 0xc000-0xc03f irq >11 function 0 config 5 on pccard0 >an0: got RSSI <-> dBM map >an0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >an0: Ethernet address: 00:07:0e:b9:2e:d5 -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ep0 Interrupt Storm, 3Com EtherLink III (PnP)
On Wed, 2005-Sep-21 10:34:43 +0900, Joel Rees wrote: > >On å¹³æ 17/09/21, at 5:35, Billy Newsom wrote: > >>Does anyone know exactly what to do about an interrupt storm, > >My understanding is that an interrupt storm is a noisy interrupt >line. It could be a flaky chip, an incompatible setting for the >interrupt lines in the BIOS, a loose wire, dust or some sort of >condensate (very typically tobacco tar) on the PC board, ... Or a driver bug: Failing to clear the condition causing the interrupt before sending an end-of-interrupt notification to the device will cause it to re-assert the interrupt request. I've also seen it when a device configured for polling (and hence without an installed interrupt handler) decides to raise an interrupt and gets upset at the interrupt not being handled. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
High interrupts w/ Cisco 350 card
-bit PCCard bus> on cbb0 cbb1: at device 11.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pci2: at device 13.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xbfa0-0xbfaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 11 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pcm0: port 0xbdc0-0xbdff,0xbe00-0xbeff mem 0xfc4ffd00-0xfc4ffdff,0xfc4ffe00-0xfc4f irq 11 at device 31.5 on pci0 pcm0: pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_acad0: on acpi0 acpi_toshiba0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A orm0: at iomem 0xe-0xe,0xc-0xc on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ums0: Sun Microsystems Type 6 USB mouse, rev 1.10/1.05, addr 2, iclass 3/1 ums0: 3 buttons. Timecounter "TSC" frequency 598494220 Hz quality 800 Timecounters tick every 10.000 msec ad0: 38154MB [77520/16/63] at ata0-master UDMA100 an0: at port 0xc000-0xc03f irq 11 function 0 config 5 on pccard0 an0: got RSSI <-> dBM map an0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps an0: Ethernet address: 00:07:0e:b9:2e:d5 ata1-slave: FAILURE - ATAPI_IDENTIFY timed out ata1-slave: FAILURE - ATAPI_IDENTIFY timed out ata1-slave: FAILURE - ATAPI_IDENTIFY timed out acd0: CDRW at ata1-master UDMA33 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Mounting root from ufs:/dev/ad0s1a -- Peter D. Quilty [EMAIL PROTECTED] 703-906-5633 GnuPG Key: http://users.adelphia.net/~pdquilty/gpg-pubkey.asc GnuPG Key Fingerprint: A46A 0E56 D13E 5617 4696 2B04 0D0C E34D CB6D D107 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS directory copies cause crash
On Thu, 2005-Sep-15 23:58:39 -0400, Damian Gerow wrote:
>Thus spake Kris Kennaway ([EMAIL PROTECTED]) [15/09/05 21:39]:
>: > Is this something known and being worked on, or should I try to gather some
>: > debugging information?
>:
>: The latter..at least a DDB traceback to begin with so we can tell if
>: it's a known issue or not.
>
>This is what I've got:
>
>Fatal trap 18: integer divide fault while in kernel mode
>instruction pointer = 0x8:0xc063c94d
...
>#4 0xc06c2722 in trap (frame=
> {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1048248320, tf_esi =
> 0, tf_ebp = -738105568, tf_isp = -738105648, tf_ebx = 0, tf_edx = 0, tf_ecx =
> 0, tf_eax = 183205888, tf_trapno = 18, tf_err = 0, tf_eip = -1067202227,
> tf_cs = 8, tf_eflags = 66182, tf_esp = 38, tf_ss = 0}) at
> /usr/src/sys/i386/i386/trap.c:622
...
>#19 0xc063c94d in ffs_dirpref (pip=0xc1b193d4) at libkern.h:56
>#20 0xc063c42a in ffs_valloc (pvp=0xc1e38d68, mode=16877, cred=0xc1e08d80,
> vpp=0xd40167a0) at /usr/src/sys/ufs/ffs/ffs_alloc.c:863
Frame #19 is the real problem. This is where inline functions are a
real nuisance. libkern.h:56 is min() and there are two invocations of
min() from ffs_dirpref() which could potentially have a divide-by-zero.
As a first step to tracking down what has gone wrong, within kgdb:
print *(struct inode *)0xc1b193d4
print *((struct inode *)0xc1b193d4)->i_fs
disas ffs_dirpref
The disassembly is about 280 lines and someone will need to map 0xc063c94d
to the source line within ffs_dirpref() to locate which divide is failing.
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can't reboot into single mode
On Sat, Sep 10, 2005 at 11:19:22PM -0400, Didier Rwitura wrote: > >After I upgraded my FreeBSD-5.3 to FreeBSD -5.4 stable, I can't to go to >single user mode anymore . I am getting the following error message > >init: can't exec getty '/usr/libexec/getty' for port /dev/ttyv0 ... getty's are only exec'd in multi-user mode so something odd is happening. More information is needed: How did you upgrade? Source upgrade or binary upgrade? If it was a source upgrade, exactly what did you do? How are you booting to single user mode? Breaking to the loader prompt and entering "boot -s" or entering "4" (from memory) into the boot menu? When you boot single user, what are console messages between "Mounting root..." and the "can't exec getty" message? -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HZ option [Was: Re: custom kernel + if_xl + error]
On Sun, 2005-Sep-04 04:27:24 +0200, Emanuel Strobl wrote:
>standard. Here's what my non-acpi/apic system ([EMAIL PROTECTED]) says:
>kern.clockrate: { hz = 1000, tick = 1000, profhz = 1024, stathz = 128 }
>And here from my 1GHz Celeron with acpi and apic:
>kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }
>
>Can somebody eplain the profhz to me? Especially why it's higher on the
>much slower machine...
On your older system, profhz and stathz are driven the RTC interrupts
and tick is driven by the 8254. On your newer system all the clocks
are derived from the LAPIC timer running at 2000Hz - tick is LAPIC/2,
profhz is LAPIC/3 and stathz is LAPIC/15.
The actual values of profhz and stathz are unimportant, their primary
purpose is to sample the system state at a rate that is difficult for
processes to synchronize with. If a process synchronizes with the
profiling/statistics clock then the statistics become unreliable (and
a process can cheat the scheduler by appearing to use no CPU time).
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0-BETA2 as reliable webserver?
On Fri, 2005-Aug-19 23:42:18 +0200, Frans-Jan v. Steenbeek wrote: >building. Since we are moving in a few months, we decided to use a HP >laptop instead (reasonably fast CPU, 512 Megs) since we had a few to >spare. > >The toy is currently set up with FreeBSD 6.0-BETA2, Apache 2.0, MySQL 5.0 >and PHP-5.0 with all the reasonable modules. Everything is compiled from >ports. No changes to the kernel yet, no world-rebuilding done. I'd also be extremely loath to bet my company on a laptop running beta software. As others have pointed out, laptops aren't designed for this. (Though my old Compaq laptop ran FreeBSD 24x7 for several years and I only stopped using it because the lid was cracking too badly). If you're really concerned about noise: - use an older desktop and maybe even underclock it to keep it cooler - build your own system. Either go the low power route (mini-ITX) so you don't need noisy fans or use an over-rated PSU and CPU heatsink to keep fan speed (and noise) down. In either case, you'll need to look around to find a quiet HDD. - [as a completely left-field suggestion] look at something like an Apple G5 system - large fans running slowly generate very little noise. At the very least, you need to build a test harness to test the system under load (and maybe get some friends and/or friendly customers to hammer it as well). Whilst all the software is derived from a mature code-base, I'd be surprised if you can't crash it. >I will post all problems not yet reported to the list, but if anyone of >you would like to share his or her opinion on this matter, please let me >know. Will 4.11-RELEASE perhaps be a better choice? 4.x is definitely more mature than 6.x. That said, I'd recommend against deploying 4.x in a new system because it is a dead end - you'll need to migrate off it at some point and that's far easier to do before a system goes live. You made the point that you support for newer hardware is better in newer releases. Why not use 5.4? As you point out, you are more familiar with it. And, once 6.x does become more stable, moving from 5.x to 6.x will be far easier than moving from 4.x to 6.x. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory requirements between releases
On Fri, 2005-Aug-12 21:38:43 +0100, Chris wrote: >The installation notes for 4.11 say, referring to i386 platform >" ...after installation, FreeBSD itself can be run in 4-8MB of RAM with >a pared-down kernel" > >The installation notes for 5.4 and 6 (the floppies README.TXT) say >"FreeBSD for the i386 requires ...at least 24 MB of RAM". > >Did the memory requirement really jump that much or is something >different being measured? As Kris said, you are measuring two different things. Note the phrase "after installation" in your first quote. Installation takes substantially more memory because FreeBSD needs to load a full-sized GENERIC kernel, allocate space for a RAM disk to hold the installation filesystem process and have enough RAM left over to actually run the installaton processes. Once you've installed FreeBSD, you can prune down the kernel and you don't need the RAM disk. That said, 5.x is larger than 4.x (which is larger than 3.x, etc). >I have on old tosh 110CT laptop with 24mb memory I want to set up as a >wireless router/NAT box but would prefer to use 6 or 5.4. Can I reduce >the amount of memory required? I have compiled a reduced kernel but it >swaps like mad when compiling. Kismet and deps took over 12 hours. Just >after boot and not doing anything it has about 2mb free and 17 processes >running. 24MB should be adequate as a SOHO wireless router/NAT box but doing compilations will stress it significantly (as you've noticed). It would be too small if you were going to run lots of applications (named, squid etc) 2MB free sounds about right. The Unix kernel sees free space as wasted space and tries to avoid having too much of it. You can add "inactive" to the free memory to get a better idea of how much RAM isn't being used, and the cache will shrink if processes need for RAM. As long as your system isn't paging during normal operation (normal operation for a firewall excludes compiling ports or the kernel), then you have enough RAM. 17 processes sounds a bit high. You can probably find some that aren't necessary - in particular, you probably only want one or two gettys. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4->5 libmilter.a install failure
On Mon, 2005-Aug-08 14:25:35 -1000, Randy Bush wrote:
>my error. i hacked /etc/make.conf between build and install.
>so i can use ed to unhack it, but when i try to install again
>
>--
>>>> Making hierarchy
>--
>cd /usr/src; /usr/obj/usr/src/make.i386/make -f Makefile.inc1 hierarchy
>cd /usr/src/etc;/usr/obj/usr/src/make.i386/make distrib-dirs
>mtree -eU -f /usr/src/etc/mtree/BSD.root.dist -p /
>/usr/libexec/ld-elf.so.1: Shared object "libmd.so.2" not found, required by
>"mtree"
Apart from the other suggested solutions: At the beginning of the
installworld, make stashes a selection of utilities (including
mtree) into a temporary directory (${INSTALLTMP} in Makefile.inc1).
The exact name varies but is something like /tmp/install.
If you haven't lost the directory from the first installworld, you can
always copy mtree (any any other over-written utilities) back where
they started.
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Quality of FreeBSD
On Thu, 2005-Jul-21 17:46:13 +0200, Martin wrote: >One more thing about "cheap hardware": if you know that a piece of >hardware is potentially buggy (I mean real BUGS and not missing >support), please publish your opinion, because I will buy hardware >FOR FREEBSD, so I avoid major problems. How about test suites for >ACPI quality, e.g.? Would it be possible? In general, I'd say what you want isn't achievable. Firstly, there's the risk of legal action from a vendor who believes they have been maligned and the reliability (or lack thereof) of the supplied opinions. More critically, vendors often make (significant to FreeBSD) changes to products without any obvious external differences. For example, wireless cards that are externally identical but have different chipsets when you open the packaging. And there's no way to ensure that the BIOS and ACPI in the motherboard you bought last week bears any resemblance to the BIOS and ACPI in the supposedly identical motherboard that I buy this week. As far as the vendor is concerned, as long as it (sort of) works on Windoze when you use the vendor-supplied driver then the vendor has fulfilled their "fit-for-use" responsibility. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ahd problems on 5.4-STABLE and 6.0-BETA1
Hello, It seems to me, that the 'ahd' driver got some problems on both 5.4-STABLE and 6.0-BETA1. My hardware is a HP Workstation 6000, with an on-board Adaptec SCSI controller, which is disabled in BIOS, as I only have IDE CD- and harddrives. I start with 6.0-BETA1, as it's the easier one: when I boot the install CD, it finds the controller, writes "Unable to read SEEPROM", it waits a few seconds, writes another 20 lines of error messages on screen, then reboots the computer, so there isn't time to read the rest of messages and can't install the beta. 5.4-STABLE: simptoms are the same on my installed 5.4-STABLE machine, I can read "Unable to read SEEPROM", it waits, prints some more messages, and reboots. When I boot an older kernel (from the 29th of June), the kernel finds the controller, and works fine. Compiling a kernel without ahd support (commenting out: '#device ahd') solves the problem as well, and the machine boots fine. This is part of dmesg from the old kernel: Jul 20 13:48:02 beech kernel: ahd0: adapter> at device 12.0 on pci5 Jul 20 13:48:02 beech kernel: aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs Jul 20 13:48:02 beech kernel: ahd1: adapter> at device 12.1 on pci5 Jul 20 13:48:02 beech kernel: aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs Bye, Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: init: can't exec getty 'none' for port /dev/console: No such file or directory
Please don't top-post. On Fri, 2005-Jul-01 20:17:47 +0300, Bashar wrote: >Peter Jeremy wrote: >>You should have the following line in /etc/ttys: >>console noneunknown off secure >True its set to on, but i believe this change was requested from the DC >to enable the remote console for the box. > >would turning it off effect the remote console from working? No. The 'console' entry is just a marker. By "remote console" I presume you mean "serial console". The easiest way to get a serial console is to put "-P" into /boot.config and unplug the keyboard. (For other ways, see boot(8) and sio(4)). In order to enable logins on a serial console, you will need to turn on the getty for ttyd0. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: init: can't exec getty 'none' for port /dev/console: No such file or directory
On Fri, 2005-Jul-01 08:23:52 +0300, Bashar wrote: >i noticed one of my boxes had the message "init: can't exec getty 'none' >for port /dev/console: No such file or directory" into messages and >repeating forever. You should have the following line in /etc/ttys: console noneunknown off secure The only change you can validly make to this line is to change 'secure' to 'insecure' but I suspect you've changed 'off' to 'on'. Try turning the console back off and sending a SIGHUP to init. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with 5.x
Hi Matt, On Thu, 2005-Jun-30 11:57:38 -0400, Matt Emmerton wrote: >First, I tried to install 5.2. Booting from CD, BTX would halt with a >register dump. There are some people around who can read BTX dumps. Any chance of you posting it? The CD boot mode was changed from "floppy emulation" mode in 4.x to "no emulation" mode in 5.x (for slightly more details, see the '-b' and '-no-emul-boot' options to mkisofs). At a guess, it looks like your BIOS doesn't handle the latter very well. My two suggestions are: 1) A BIOS upgrade. If your BIOS is flashable, check out the vendor's website. 2) Boot from physical floppies. The images are in the 'floppies' directory on the CD-ROM. I presume you've satisfied yourself that the CD-ROMs aren't corrupt. (Unlikely but possible). You might have to experiment with dis/enabling ACPI to get things working. >Next, I installed 4.10 (which installs fine) and tried to cvsup to -stable, >but had problems with buildworld. Generally, upgrading to version N from version N-1 is only supported from the latest version of N-1, so you might need to upgrade your 4.10 system to 4-STABLE first. Alternatively, you will need to post more details (cut-and-paste) of the errors you are getting. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Data corruption in cd9660 on FreeBSD 4.11?
On Fri, 2005-Jun-24 22:31:06 +1000, Stephen McKay wrote: >I'm experiencing data corruption when reading CDs and DVDs on FreeBSD 4.11. ... >So, can anyone suggest any more tests I could try? Or is there a kind of >hardware fault that could cause this substitution of whole blocks read from >CDs without causing any other problems? You might like to post the relevant sections of a verbose boot - the ATA and CD probes. Are you running the CD/DVD drives in PIO or UDMA modes? In the former, the CPU is reading the data from the CD and writing it to memory. In the latter, the CPU tells the disk controller where to write. It could be instructive to change modes and see what happens. Have you tried anything other than ISO9660 filesystems on a physical CD? What happens if you just dd the CD-ROM? What happens if you use a vnode mount (see vnconfig(8)) of an ISO filesystem sitting in a UFS filesystem? Anything unusual in your kernel config file? Have you tried building a kernel with WITNESS and/or DIAGNOSTIC? Any chance of you repeating the tests with a 5.x system? Maybe on a spare small partition or using a 5.4-RELEASE disk1 as a live filesystem. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: howto update freebsd 4.7 release to 4.7 stable
On Tue, 2005-Jun-21 17:24:46 -0400, Brian Fundakowski Feldman wrote: >On Tue, Jun 21, 2005 at 07:37:42PM +0700, Khanh Cao Van wrote: >> hi , I could not findout the "# cd /usr/src/lib/libpthread" as your >> answer bellow ,please help me to fix this problem > >Yeah, 4.x actually uses libc_r. Sorry about that. I was looking in the wrong source tree. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: howto update freebsd 4.7 release to 4.7 stable
On Tue, 2005-Jun-21 09:16:30 +0700, Khanh Cao Van wrote: >My custom use freeBSD 4.7 release and ask me to install JDK1.4 on it . >But when I use ports to compile JDK , the system show me a message : > >You must have a version of FreeBSD later than 4.7-STABLE February 2003 >or 5-CURRENT February 2003 to compile and use JDK 1.4.2. JDK 1.4 requires some threading changes that were (presumably) introduced in February 2003. Looking back at the CVS commit logs, there were a large number of changes to the threading library during January and February 2003 and it's not clear exactly what fixes JDK is relying on. If the only problem with JDK is the threading library, you may be able to get JDK1.4 running by just upgrading libpthread to 4-STABLE: # cd /usr/src/lib/libpthread upgrade just this tree to 4-STABLE using whatever method you prefer # make clean # make all # make install I can't guarantee that this will work but it is probably your only option to get JDK 1.4 working without doing a full upgrade. >So I have to update my 4.7 release to 4.7 stable . But I do not know >how to do make it . I've looking everywhere but could not find any >clear document about it . Please help me ! 4.7-STABLE is not a fixed package. It refers to the RELENG_4 CVS branch between the time that RELENG_4_7 was branched and RELENG_4_8 was branched (ie betweem 4.7-RELEASE and 4.8-RELEASE). It is not really practical to update to 4.7-STABLE once 4.8 has been released. >PS : I'm not going to upgrade my kernel 4.7 to 4.8 or anything else , >just 4.7 only . Thank for reading ! Note that 4.7 is no longer supported by the FreeBSD project and I would strongly recommend that you consider upgrading. In particular, security fixes are unlikely to be applied to 4.7. Upgrading userland without upgrading the kernel is not supported in general. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rebooting problem
On Fri, 2005-Jun-17 11:58:35 +0200, GMane wrote: >When I try to reboot my machine it hangs on and I have to do it manually >pressing the reset button. > >Did anyone have the same problem? I've seen something similar on a HP DL380. Do you have any modules loaded? If so, does the problem go away if you avoid loading any modules? See http://www.FreeBSD.org/cgi/query-pr.cgi?pr=i386/72441 -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, 2005-Jun-17 23:42:08 +0200, Wilko Bulte wrote: >On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote.. >> Wilko Bulte wrote: >> >Yes. Go and visit the London City and check their computer rooms. >> >You will be surprised about the number of UNIX boxes. You don't >> >think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? >> >> But are those Unix servers actually processing bank transactions and >> holding customer accounts? Unix and mainframes are not mutually exclusive - the major mainframe vendors will be happy to supply Unix on their mainframes. The big benefit of mainframes is data integrity - your typical mainframe will have error detection and/or correction on _all_ data paths, including through the ALU, all levels of cache and all I/O paths. The other benefit of mainframes is massive I/O bandwidth and the ability to usefully use the available bandwidth. >Why not? As an aside: what do you think telecom operators run their >main billing systems on? UNIX... Any idea what downtime costs per hour >on those systems? Not just billing systems. My employer sells Unix systems used for call processing (intelligent networks) as well as PABX's built on Unix kernels. And downtime at the call processing end is more expensive than the billing end - customers won't notice if the bill is ½hr late (or a call is undercharged) but they do notice if they can't ring the home-delivery pizza shop when they're hungry. I think this is getting somewhat off-topic: I don't think any banks or telcos have business critical systems running on FreeBSD or Linux with MySQL databases. And the FreeBSD-S/390 port is nowhere near Tier-1 status yet. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, 2005-Jun-17 10:38:34 -0400, David Sze wrote: >It turns out that the problem was the same thing everyone usually points >the finger at, but no one actually mentioned this time: Linux mounts its >partitions async by default. This shouldn't be an issue here. The FreeBSD default has always been that data is written asynchronously (see below) and there should be virtually no metadata updates in a database application. If an application needs control over when the data is physically written to the disk (eg a database server), it needs to use fsync(2) and/or msync(2) calls. If Linux (or FreeBSD) isn't complying with fsync(2) or msync(2) semantics then it has a serious problem. >super-smack select-key >5.4-RELEASE ~20,000 queries/second >6.0-CURRENT ~24,000 queries/second >CentOS w/async ~36,000 queries/second >CentOS w/sync ~26,000 queries/second I can't see where this benchmark is doing any writes so I'd like to see an explanation of the difference in CentOS performance figures before making any decision on CentOS vs FreeBSD. >super-smack update-select >5.4-RELEASE ~4,000 queries/second >6.0-CURRENT ~4,500 queries/second >CentOS w/async ~7,500 queries/second >CentOS w/sync ~750 queries/second > >That last CentOS number is not a typo, it was an order of magnitude >slower. That's a surprising difference - I wouldn't have expected it to be so large. A couple of people have mentioned the impact of journalling. Journalling improves performance by converting time-critical random I/Os into time-critical sequential I/Os and background random I/Os - and sequential I/O is many orders of magnitude faster than random I/O. All transactional databases do their own journalling (REDO logs). As long as the database correctly issues filesystem synchronisation commands and the filesystem correctly implements them, database application, a journalling filesystem provides no benefits. A more interesting test would be a client that issues a series of updates to a server and, immediately after receiving the acknowledge for the last update turns, off the server's power. After the server is rebooted, confirm that all the updates have been applied correctly. Filesystem I/O behaviour: DataMetadata Mount type asyncasync async async sync 'traditional' UFS asyncasync[*] UFS + softupdates sync sync sync 'Metadata' covers directory updates and some inode updates [*] softupdates controls write ordering to ensure on-disk consistency. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/local/etc/rc.d/*.sh not working?
Put them all in the same directory and write a quick script to loop through the dir (make sure the directory's secure...). Then you could just add that script to /etc/rc.conf? peter - Original Message - From: "Michael W. Lucas" <[EMAIL PROTECTED]> To: "K?vesd?n G?bor" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, June 14, 2005 4:19 PM Subject: Re: /usr/local/etc/rc.d/*.sh not working? That works fine for ports, but what about truly local custom scripts? For example, I have a server with about 400 separate MRTG daemons on it. (Yes, they must be separate, for administrative rather than technical reasons.) Each daemon has a custom script. These aren't ports, and they have no rcNG infrastructure. They used to work fine. Now they don't. Obviously something has changed. I'd like to have just a plain old /usr/local/etc/rc.d/*.sh file get executed on boot, like it used to be, but if I have to change the scripts I will. On Tue, Jun 14, 2005 at 05:10:25PM +0200, K?vesd?n G?bor wrote: For scripts in /usr/local/etc/rc.d You should add an entry to /etc/rc.conf. For example, if You script is somedaemon.sh, then add somedaemon_enable='YES' to /etc/rc.conf and it will run at the next boot. Cheers, G?bor K?vesd?n Michael W. Lucas wrote: >I'm certain this is documented somewhere, but danged if I can find it. > >I have a whole variety of custom scripts in /usr/local/etc/rc.d. For >years now, simply giving them a name ending in .sh and making them >executable has been sufficient to make them start on boot. > >On 5.x, it's not. And now, having upgraded to 4.11-s on some older >boxes and running portupgrade -a, it's not. > >Obviously these scripts need something else. There's no fancy rcNG >infrastructure in them; is rcNG a requirement for startup scripts now? >Any pointers on where I can find the right documentation? > >Thanks, > >==ml > > > -- Michael W. Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.BlackHelicopters.org/~mwlucas/ "The cloak of anonymity protects me from the nuisance of caring." -Non Sequitur ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Strange error
On Fri, 2005-Jun-10 22:41:36 +0200, Jack Raats wrote: >This day I've a very strange error when trying to connect to my FreeBSD >machine (4.11-STABLE) >I got the following error: >ssh_exchange_identification: Connection closed by remote host > >Can anyone give me any clue what's wrong? Try turning on debugging on the client (ssh -vvv ...). You can also turn on debugging on the server with '-d' (though you probably also want to use '-p'). If the problem isn't obvious, compare the output with a debugging session that works. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-RC2 freezing - ATA related?
On Tue, 2005-May-31 16:47:19 -0700, Steve Watt wrote: >>> The vnode locks are held by processes: >>> PID namewaiting on >>> 487 perl [ufs c3c1c1b4] >>> 57 syncer [snaplk c535f500] (holds 2 locks) >>> 476 perl [ufs c87e4f1c] >>> 489 perl [snaplk c535f500] (holds 2 locks) >>> 3337 mksnap_ffs [getblk d77656f4] ... >This is a filesystem lock problem, not an ATA driver problem. I analyzed >it, and posted the results to -hackers last week, with the subject "snapshots >and innds". I saw your previous post but the symptoms don't look the same to me. Your deadlock has mksnap_ffs blocked on ufs whilst Elliot's problem has mksnap_ffs blocked on getblk. getblk is a lower level call (physical I/O) and I don't see how a FS problem could cause problems for getblk calls. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.4: Is it generally unstable?
On Wed, 2005-Jun-08 10:13:16 +1000, David Hogan wrote: >Recently though, I've been playing around with FreeBSD 5.4 on a vmware box, >and I'm beginning to think it may be the way forward in the long run. Having >observed freebsd-stable@freebsd.org for the last couple of weeks, I've >noticed a worrying (to me) amount of traffic regarding kernel panics, >general instability etc, and I'm now posting this in the hope that I might >obtain perspective on this from some experienced FreeBSD users. IMHO, just reading this mailing list will give you an overly negative view of FreeBSD's stability. My experiences are that FreeBSD 5.4 using a GENERIC kernel (or something close to it) is quite stable. I'm only aware of one issue - relating to an interaction between mysnc(2) and UFS2 snapshots - and that hasn't affected me so far.. Most of the problems I've seen on this list relate to one or more of: - Experimenting with the ULE scheduler (which is not used by default) - Experimenting with PREEMPTION (which is off by default) - Having machines with 4GB or more of RAM - Running 5-STABLE (the development version) rather than 5.4 - Having filesystems with lots (>>1e6) of inodes - Unusual hardware (eg laptops) My suggestion is that you install your application suite on FreeBSD 5.4 (either native or within VMware) and experiment for a while. Your own applications are by far the best test. If you're happy with FreeBSD, switch over. If you run into problems, let us know. At this stage, I would recommend 5.4 over 4.11. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DVD only gets udma2 (udma4 capable)
Hello Axel, Monday, May 30, 2005, 7:40:43 AM, you wrote: AG> Im getting problems to get the DVD burner in udma4 mode. It says: AG> AG> ata1-master: DMA limited to UDMA33, non-ATA66 cable or device AG> This is wrong, the device is udma4 capable. AG> The problem seems to be in the detection of the cable type, it detects it as AG> 40-pin, while its a 80-pin one. (dmsg is at the end) AG> * The DVD is secondary master, with no other devices on the cable AG> * THe bios detects it correctly, on boot screen it says udma66 AG> * When booting in w*n, it says udma66 AG> * I have another hard drive udma100 on same system, so I inverted (identical) AG> cables, and the HD is still at udma100, this to discard any cable problems. AG> Its important to get udma66 working, in order to achive maximum burning speed AG> for the drive. AG> So i'm out of ideas here, and any help would be apretiated. AG> Thanks in advance :) (snip) Try playing with the jumpers on the drive. If it is set to Cable Select (CS or CSEL), try manually jumpering it to Master. To be 100% correct, the drive should be jumpered as CSEL but i've seen quite a few cd/dvd drives that don't seem to work correctly when put in CSEL mode with an 80 wire cable. -- Best regards, Petermailto:[EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Context sensitivity in beastie.4th?
On Thu, 2005-May-26 23:41:26 -0600, Scott Long wrote: >Seems to work for me with the commented lines fixed. Btw, you by no >doubt have noticed that it's somewhat inconvenient to do 4th programming >by modifying the boot scripts and then praying that the reboot works. >It's possible to do 90% of the testing in userland, like I did when I >wrote beastie.4th. [Instructions deleted] I believe your instructions are worth preserving. Any chance of you adding that to (eg) /usr/src/sys/boot/README or into the ficl or forth directories? -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-RC2 freezing - ATA related?
On Fri, 2005-May-20 14:53:09 -0600, Elliot Finley wrote: >From: "Peter Jeremy" <[EMAIL PROTECTED]> >> On Fri, 2005-May-20 08:25:58 -0600, Elliot Finley wrote: >> >I took the -L option off of my dump command in my daily dump script. I've >> >gone two days without locking up which is unusual. I think that may be what >> >was tickling the bug that was locking me up. >> >> Sometime you might like to do a 'dd if=/dev/ar0 of=/dev/null bs=32k' just >> to confirm that you don't have any unreadable blocks (though this seems >> unlikely). > >came up clean. transfer went 40MB/s. That seem to leave the finger pointing at the ATA driver. Paging Søren: Are you have to help Elliot? -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-RC2 freezing - ATA related?
On Fri, 2005-May-20 08:25:58 -0600, Elliot Finley wrote: >I took the -L option off of my dump command in my daily dump script. I've >gone two days without locking up which is unusual. I think that may be what >was tickling the bug that was locking me up. Sometime you might like to do a 'dd if=/dev/ar0 of=/dev/null bs=32k' just to confirm that you don't have any unreadable blocks (though this seems unlikely). -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Boot loader cant identify ntfs?
Hello Torfinn, Thursday, May 19, 2005, 4:07:27 PM, you wrote: TI> My proposal is this; don't change anything in the FreeBSD bootloader. TI> People who want a fancier / more verbose / more readable boot menu - use TI> another boot manager. There are enough of them. Yes. GNU GRUB is perfect in this regard. The only thing I would *maybe* suggest is to add the option of using the Multiboot specification that GRUB defines, instead of chainloading /boot/loader, however chainloading works well enough and is easy to accomplish. -- Best regards, Petermailto:[EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Where to sing up to a spam list?
Marcin Jessa wrote: Even though my anti-spam email gateways drop tons of spam everyday, some of it still gets through. I want to test my new anti-spam filters and therefore sign in/publish an email account to a spammer database. Any idea where I can do that ? Spamcop.net is a great place for reporting spam. All the users of MX have been informed to submit any spam getting through the filters to Spamcop. I use SpamAssassin to block email, which also checks Spamcops database. However its not a wise idea to send all the spam from that account to someone like Spamcop, if you get something legitimate? On the testing though, signup for some spam lists such as lolfun.com and optinbig.com -- .---. |. ____ ___ _______ | | ./ | . ) | | ||\ |/ \ | . ) / \ | | / | '_) | | |__ | \ | | .. | | '_) | __ | | \. | \ | | || \ | | '' | | \ || | | \.| \ | | |___ | \| || \__/ | \ \__/ | | [EMAIL PROTECTED] | || | Hosted by 10mbit.biz | `' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Boot loader cant identify ntfs?
On Thu, 2005-May-19 09:29:25 +0100, Bob Bishop wrote: >At 01:56 19/05/2005, Ian Dowse wrote: >>[...] >>BTW, one potential improvement to the current boot0 situation would >>be to have boot0cfg dynamically generate the OS table based on what >>partition types actually exist on the disk. [etc] > >That would be just plain unhelpful in the case where a partition gets >retyped subsequently. As I read Ian's proposal, it still dynamically detects the partition types at boot time. It's just that the table of known partition types is built by boot0cfg based on the partition types when boot0cfg is run. If you change a partition partition type then the new partition type may not be recognized but that is no worse than the current situation. It would probably be possible to pad the available space with other "common" partition types. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-RC2 freezing - ATA related?
Previously posted trap frame:
#5 0xc0691771 in trap (frame=
{tf_fs = -1068433384, tf_es = -989790192, tf_ds = 16, tf_edi = -106612473
6, tf_esi = -1066124736, tf_ebp = -323699844, tf_isp = -323699872, tf_ebx = -10
07063716, tf_edx = 528, tf_ecx = -1013235680, tf_eax = 307472464, tf_trapno = 1
2, tf_err = 2, tf_eip = -1067870386, tf_cs = 8, tf_eflags = 66050, tf_esp = -98
9760240, tf_ss = -1007063716}) at /usr/src/sys/i386/i386/trap.c:425
On Thu, 2005-May-19 00:15:44 +0100, Jamie Heckford wrote:
>Fatal trap 12: page fault while in kernel mode
>fault virtual address = 0x214
That's a NULL pointer somewhere. The trap frame shows %edx is 528 so
the code has presumably tried to dereference %edx but it's not clear
how %edx would up with that value.
>fault code = supervisor write, page not present
>instruction pointer = 0x8:0xc059974e
>stack pointer = 0x10:0xecb4bb74
>frame pointer = 0x10:0xecb4bb7c
This instruction pointer matches the trap frame but not the traceback
you posted. The trap frame gives the stack pointer as 0xC5017510
(which is nonsense) with a nonsense stack segment but the frame
pointer matches. Having the frame pointer above the stack pointer
is also unusual.
It looks like gdb is a bit confused. You could try:
disasm 0xc059974e
x/x 0xecb4bb74
Does the instruction either at or immediately before 0xc059974e
include [%edx]? What function is it in and can you work out the
line number? Does the address reported by the x/x match anything
in the backtrace?
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-RC2 freezing - ATA related?
On Wed, 2005-May-18 16:03:16 +0100, Jamie Heckford wrote: >Managed to get a dump on our system for a similar prob we are getting: That traceback looks like a panic, not a deadlock. What was the panic message? >#2 0xc0513474 in panic (fmt=0xc06c3da5 "%s") at >/usr/src/sys/kern/kern_shutdown.c:566 ... >#7 0xc0510018 in crcopy () at /usr/src/sys/kern/kern_prot.c:1810 >#8 0xc0598c77 in in_pcbdetach (inp=0xc0743a40) at >/usr/src/sys/netinet/in_pcb.c:720 >#9 0xc05b21a6 in tcp_close (tp=0x0) at /usr/src/sys/netinet/tcp_subr.c:783 There's something wrong here: If tcp_close() is passed NULL it will panic at this point when it tries to dereference tp. >#10 0xc05ae560 in tcp_input (m=0xc3a6a300, off0=20) at >/usr/src/sys/netinet/tcp_input.c:2308 >#11 0xc05a5aed in ip_input (m=0xc3a6a300) at >/usr/src/sys/netinet/ip_input.c:776 >#12 0xc0582f13 in netisr_processqueue (ni=0xc0742498) at >/usr/src/sys/net/netisr.c:233 >#13 0xc058310a in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:346 -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
