Re: ACPI using too much CPU on idle system
In message: <[EMAIL PROTECTED]> Kris Kennaway <[EMAIL PROTECTED]> writes: : On Mon, Mar 24, 2003 at 01:20:40PM -0800, Kris Kennaway wrote: : > top -S shows the following on my machine: : > : > CPU states: 0.8% user, 0.0% nice, 80.3% system, 12.9% interrupt, 6.1% idle : > : > PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND : >11 root -160 0K12K RUN563:23 32.23% 32.23% idle : > 7 root -840 0K12K actask 1:33 18.51% 18.51% acpi_task2 : > 5 root -840 0K12K actask 1:33 18.21% 18.21% acpi_task0 : > 6 root -840 0K12K actask 1:33 17.82% 17.82% acpi_task1 : >21 root -68 -187 0K12K WAIT 0:55 4.98% 4.98% irq9: fxp0 atapci0* : >17 root -24 -143 0K12K WAIT 0:06 0.83% 0.83% swi6: acpitaskq : > : > The machine is supposedly idle..no process, disk or network activity, : > so I can't see any reason for all this kernel CPU activity. What is : > going on? Is this some kind of software-emulated CPU step-down : > because ACPI has decided my CPU is too fast? :) : : Hello, ACPI people? I haven't had any response to this yet. I've seen this on a dying battery on my Dell i8000. From time to time, it just eats lots of CPU trying to get the battery's status. Could also be a defective battery bay. But I see very similar results. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated pci/if_* attach patches
In message: <[EMAIL PROTECTED]>
Nate Lawson <[EMAIL PROTECTED]> writes:
: * Add bus_child_present check to calls to *_stop in the detach method for
: devices that have children (i.e. miibus).
bus_child_present isn't quite right for this. bus_child_present means
"this child is still there in hardware" not "this node has children"
+ if (device_is_alive(dev)) {
+ if (bus_child_present(dev)) {
+ dc_stop(sc);
+ device_delete_child(dev, sc->dc_miibus);
+ }
+ ether_ifdetach(ifp);
+ bus_generic_detach(dev);
+ }
should be just:
+ if (device_is_alive(dev)) {
+ if (bus_child_present(dev))
+ dc_stop(sc);
+ device_delete_child(dev, sc->dc_miibus);
+ ether_ifdetach(ifp);
+ bus_generic_detach(dev);
+ }
since it says 'if the card is still there, stop it' which is what you
want in the cardbus case (and one day hotplug pci) since the card
might not be there, in which case trying to do anything with it is
doomed to failure. Please fix this issue before commit.
# guess this is my fault for never writing a bus_child_present man
# page :-(
Also, on a stylistic note:
- free(sc->dc_srom, M_DEVBUF);
+ if (sc->dc_srom)
+ free(sc->dc_srom, M_DEVBUF);
The kernel free, just like its ANSI-89 userland counterpart, can
tolerate free(NULL) now. I know some of the other frees check, some
don't, but none should. I'd not hold up the commit on this issue,
however.
from kern_malloc.c:
void
free(addr, type)
void *addr;
struct malloc_type *type;
{
...
/* free(NULL, ...) does nothing */
if (addr == NULL)
return;
...
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: unrecognized Prism III card
In message: <[EMAIL PROTECTED]>
"Michael W . Lucas" <[EMAIL PROTECTED]> writes:
: Hi folks,
:
: I picked up a couple of no-name Prism III cards, and found that
: FreeBSD-current doesn't recognize them. Is there anything I can do to
: make these work? (Up to and including shipping a card to a
: committer?)
Ship me a dozen :-) At least tell me their name so I can do the
support right...
: Mar 27 07:14:35 pedicular kernel: pccard1: (manufacturer=0x50c2,
product=0x7300) at function 0
: Mar 27 07:14:35 pedicular kernel: pccard1:CIS info: WLAN, PRISM PCMCIA CARD,
37300P
However, short of that, let's try the following patch:
Warner
//depot/user/imp/newcard/dev/pccard/pccarddevs#16 -
/dell/imp/p4/newcard/src/sys/dev/pccard/pccarddevs
@@ -100,6 +100,7 @@
vendor LASAT 0x3401 Lasat Communications A/S
vendor BONDWELL0x3b01 Bondwell
vendor LEXARMEDIA 0x4e01 Lexar Media
+vendor OEM10x50c2 OEM #1
vendor ARCHOS 0x5241 Archos
vendor DUAL0x890f Dual
vendor EDIMAX 0x890f Edimax Technology Inc.
@@ -315,6 +316,9 @@
product NWN WLAN_550 0x0002 NWN 550 WLAN
product NWN WLAN_1148 0x0003 NWN 1148 WLAN
+/* Mystery OEM #1 */
+product OEM1 PRISM30x7300 Prism 3 37300P
+
/* Olicom Products */
product OLICOM TR 0x2132 GoCard Token Ring 16/4
//depot/user/imp/newcard/dev/pccard/pccarddevs.h#16 -
/dell/imp/p4/newcard/src/sys/dev/pccard/pccarddevs.h
@@ -1,4 +1,4 @@
-/* $FreeBSD: src/sys/dev/pccard/pccarddevs.h,v 1.45 2003/03/18 02:37:25 imp Exp $
*/
+/* $FreeBSD$ */
/*
* THIS FILE AUTOMATICALLY GENERATED. DO NOT EDIT.
@@ -107,6 +107,7 @@
#definePCMCIA_VENDOR_LASAT 0x3401 /* Lasat Communications A/S */
#definePCMCIA_VENDOR_BONDWELL 0x3b01 /* Bondwell */
#definePCMCIA_VENDOR_LEXARMEDIA0x4e01 /* Lexar Media */
+#definePCMCIA_VENDOR_OEM1 0x50c2 /* OEM #1 */
#definePCMCIA_VENDOR_ARCHOS0x5241 /* Archos */
#definePCMCIA_VENDOR_DUAL 0x890f /* Dual */
#definePCMCIA_VENDOR_EDIMAX0x890f /* Edimax Technology Inc. */
@@ -540,6 +541,11 @@
#definePCMCIA_PRODUCT_NWN_WLAN_11480x0003
#definePCMCIA_STR_NWN_WLAN_1148"NWN 1148 WLAN"
+/* Mystery OEM #1 */
+#definePCMCIA_CIS_OEM1_PRISM3 { NULL, NULL, NULL, NULL }
+#definePCMCIA_PRODUCT_OEM1_PRISM3 0x7300
+#definePCMCIA_STR_OEM1_PRISM3 "Prism 3 37300P"
+
/* Olicom Products */
#definePCMCIA_CIS_OLICOM_TR{ NULL, NULL, NULL, NULL }
#definePCMCIA_PRODUCT_OLICOM_TR0x2132
@@ -744,39 +750,39 @@
/*
* Cards we know only by their cis, sorted by name.
*/
-#definePCMCIA_VENDOR_AMBICOM -1 /* AmbiCom Inc */
-#definePCMCIA_VENDOR_ACCTON-1 /* ACCTON */
-#definePCMCIA_VENDOR_ADDTRON -1 /* Addtron */
-#definePCMCIA_VENDOR_ARGOSY-1 /* ARGOSY */
-#definePCMCIA_VENDOR_AMD -1 /* AMD */
-#definePCMCIA_VENDOR_BILLIONTON-1 /* Billionton Systems Inc. */
-#definePCMCIA_VENDOR_CNET -1 /* CNet */
-#definePCMCIA_VENDOR_DIGITAL -1 /* Digital Equipment Corporation */
-#definePCMCIA_VENDOR_DLINK -1 /* D-Link */
-#definePCMCIA_VENDOR_DYNALINK -1 /* DynaLink */
-#definePCMCIA_VENDOR_EIGERLABS -1 /* Eiger labs,Inc. */
-#definePCMCIA_VENDOR_EPSON -1 /* Seiko Epson Corporation */
-#definePCMCIA_VENDOR_EXP -1 /* EXP Computer Inc */
-#definePCMCIA_VENDOR_FUTUREDOMAIN -1 /* FutureDomain */
-#definePCMCIA_VENDOR_GEMTEK-1 /* Gem Tek */
-#definePCMCIA_VENDOR_ICOM -1 /* ICOM Inc */
-#definePCMCIA_VENDOR_INTERSIL -1 /* Intersil */
-#definePCMCIA_VENDOR_IODATA3 -1 /* I-O DATA */
-#definePCMCIA_VENDOR_LANTECH -1 /* Lantech Computer Company */
-#definePCMCIA_VENDOR_NAKAGAWAMETAL -1 /* NAKAGAWA METAL */
-#definePCMCIA_VENDOR_NDC -1 /* NDC */
-#definePCMCIA_VENDOR_NEC -1 /* NEC */
-#definePCMCIA_VENDOR_PLANET-1 /* Planet */
-#definePCMCIA_VENDOR_PLANEX-1 /* Planex Communications Inc */
-#definePCMCIA_VENDOR_PREMAX-1 /* Premax */
-#definePCMCIA_VENDOR_RPTI -1 /* RPTI */
-#definePCMCIA_VENDOR_SVEC -1 /* SVEC/Hawking Technology */
-#definePCMCIA_VENDOR_SYNERGY21 -1 /* Synergy 21 */
-#definePCMCIA_VENDOR_TEAC -1 /* TEAC */
-#definePCMCIA_VENDOR_WORKBIT2 -1 /* WORKBIT */
-#definePCMCIA_VENDOR_YEDATA-1 /* Y-E DATA */
-#definePCMCIA_VENDOR_YIS -1 /* YIS Corporation */
-#definePCMC
Re: Kernel panic - never had one before, what do I do?
On Fri, Mar 28, 2003 at 12:54:16AM -0500, taxman wrote: > that gives an error that is similiar to: > WARNING: syntax error on file /boot/loader.conf > dumpdev=/dev/ad0s1b > ^ Hi Tim, Please do 'dumpdev="/dev/ad0s1b". The doube quotes is a must . Jiawei -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel panic - never had one before, what do I do?
On Wednesday 26 March 2003 07:54 pm, Greg 'groggy' Lehey wrote: > On Wednesday, 26 March 2003 at 13:35:28 +, Jason Morgan wrote: > > I just got a panic. As I have never had one before, I don't know what to > > do. It's on another system so I don't have to reboot immediately (that > > would solve the problem temporarily, wouldn't it?) if someone would give > > me some advice, I could try to help debug it; however, as I'm not a > > coder (not a real one anyway), I don't know how much help I would be. > > > > It's a 5.0-CURRENT system, just installed and built last week. It > > paniced right after doing a source update (not a build, just cvsup). > > The panic error is as follows: > > > > panic: mtx_lock() of spin mutex vnode interlock @ > > /usr/src/sys/kern/vfs_subr.c:3187 > > Take a look at http://www.lemis.com/texts/panic.txt or > http://www.lemis.com/texts/panic.pdf and tell me if that helps. This > will be going into the new edition of "The Complete FreeBSD" in a few > days time, so I'm interested in getting something which is helpful. Hi Greg, I've been looking at doing the same thing, learn how to capture a crash dump, and analyze it etc. I'm a definite newbie at that so I thought it would be a good test for the article. It's pretty readable, but I had a problem with enabling the crash dump as noted: To enable dumping, put something like this in /boot/loader.conf: dumpdev=/dev/ad0s1b that gives an error that is similiar to: WARNING: syntax error on file /boot/loader.conf dumpdev=/dev/ad0s1b ^ the same syntax in /etc/rc.conf worked fine, however. This was on 4.8 RC2, but the syntax error appeared on a recent -current too. Thanks, Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VIA82c686a sound problem
Fred The via82c686.c code changed this week to implement the cold reset described in the AC97 r2.3 spec since there are some boards where the former initialization does not work. It may be your board is reporting it's ready, but it requires a reset. Can you apply the attached patch to the head version of via82c686.c and let me know if it works on your h/w and what the additional dmesg information is? The patch forces a cold reset and sets an additional "enabled" bit in the AC97 link control register during the reset (there's not enough info in the spec to know whether this bit should be set during the reset, it works elsewhere). Thanks - Orion ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI using too much CPU on idle system
On Mon, Mar 24, 2003 at 01:20:40PM -0800, Kris Kennaway wrote: > top -S shows the following on my machine: > > CPU states: 0.8% user, 0.0% nice, 80.3% system, 12.9% interrupt, 6.1% idle > > PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND >11 root -160 0K12K RUN563:23 32.23% 32.23% idle > 7 root -840 0K12K actask 1:33 18.51% 18.51% acpi_task2 > 5 root -840 0K12K actask 1:33 18.21% 18.21% acpi_task0 > 6 root -840 0K12K actask 1:33 17.82% 17.82% acpi_task1 >21 root -68 -187 0K12K WAIT 0:55 4.98% 4.98% irq9: fxp0 atapci0* >17 root -24 -143 0K12K WAIT 0:06 0.83% 0.83% swi6: acpitaskq > > The machine is supposedly idle..no process, disk or network activity, > so I can't see any reason for all this kernel CPU activity. What is > going on? Is this some kind of software-emulated CPU step-down > because ACPI has decided my CPU is too fast? :) Hello, ACPI people? I haven't had any response to this yet. Kris pgp0.pgp Description: PGP signature ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI and USB
In message <[EMAIL PROTECTED]>, Anish Mistry wrote:
>Hi,
>
> I finally got -CURRENT to install on my laptop as of 2003-03-25 and have
>been playing around with the acpi code trying to figure it out. One of the
>main problems is to get my USB bus to wake up after a suspend, currently all
>the USB devices dies when suspended and resumed.
>How can I tell the USB PowerResource to turn on? I've been able to access
>devices that have a HID and create drivers for those, but I don't know how to
>access resources with only _ADR addresses.
>below:
You may get know PCI bus number where the USB bridge connected to and
use _ADR to pick Device and Function number.
In following structure, The \SB.PCI1.FOO0 device has
Bus no 2, Device No 4 Function number 0.And this is accessible with
pci2:4:0 by pciconf(8).
Device(\_SB){
Device(PCI0){
...
}
Device(PCI1){
Name(_ADR, 0);
Name(_BBN, 2)
...
Device(FOO0){
Name(_ADR, 0x4)
}
}
}
> The USB portion of my acpidump
>
>Device(USB_) {
>Name(_ADR, 0x0002)
>Name(_PR0, Package(0x1) {
>USBP,
>})
>Name(_PR1, Package(0x1) {
>USBP,
>})
>Name(_PR2, Package(0x1) {
>USBP,
>})
>PowerResource(USBP, 1, 0) {
>Name(RSTA, 0x1)
>Method(_STA) {
>Return(RSTA)
>}
>Method(_ON_) {
>Store(One, RSTA)
>}
>Method(_OFF) {
>Store(Zero, RSTA)
>}
>}
>}
I want to know RSTA imprementation.(Probably, it is defined by
Field Op.) Please show me full dump.
Temporally work around may done by accessing Hardware registers
as same way as accessing RSTA ACPI object.
But we will have to have framework to bind PowerResource
and Device together.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI and USB
Hi,
I finally got -CURRENT to install on my laptop as of 2003-03-25 and have
been playing around with the acpi code trying to figure it out. One of the
main problems is to get my USB bus to wake up after a suspend, currently all
the USB devices dies when suspended and resumed.
How can I tell the USB PowerResource to turn on? I've been able to access
devices that have a HID and create drivers for those, but I don't know how to
access resources with only _ADR addresses. The USB portion of my acpidump
below:
Device(USB_) {
Name(_ADR, 0x0002)
Name(_PR0, Package(0x1) {
USBP,
})
Name(_PR1, Package(0x1) {
USBP,
})
Name(_PR2, Package(0x1) {
USBP,
})
PowerResource(USBP, 1, 0) {
Name(RSTA, 0x1)
Method(_STA) {
Return(RSTA)
}
Method(_ON_) {
Store(One, RSTA)
}
Method(_OFF) {
Store(Zero, RSTA)
}
}
}
Thanks,
--
Anish Mistry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VIA82c686a sound problem
Hello again, I just tried reverting (sys/dev/sound/pci/) via8233.c to 1.7, via82c686.c to 1.22 and via82c686.h to 1.5 and the sound works again. These are the revisions of those files prior to the lastest ones. Fred -- "Everyone has a scheme for getting rich that will not work." pgp0.pgp Description: PGP signature ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VIA82c686a sound problem
I forgot to mention that the "old kernel" was built off source of 03/26, around mid-night GMT-3. Fred -- Insults for obnoxious people: I'm not being rude. You're just insignificant... pgp0.pgp Description: PGP signature ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
VIA82c686a sound problem
Hello, Since my last kernel build (sources of 03/27, about 15:00 GMT-3), my -CURRENT box detects the soundcard OK, esd starts fine and mpg123 "prentends" to be playing soundfiles correctly, only no sound will come out. Booting the previous kernel guarantees it's not hardware's fault, because then it'll work fine again. I see no suspicious boot-time, syslog or console messages for tracing where the problem is, either. Has anyone else noticed this? [EMAIL PROTECTED]:~! uname -a FreeBSD torment.storming.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Mar 27 16:43:18 BRT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/torment i386 [EMAIL PROTECTED]:~! dmesg | grep pcm0 pcm0: port 0xe000-0xe003,0xdc00-0xdcff irq 11 at device 7.5 on pci0 pcm0: [EMAIL PROTECTED]:~! cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0xdc00 irq 11 (1p/1r/0v channels duplex default) Thanks, Fred -- "I'm prepared for all emergencies but totally unprepared for everyday life." pgp0.pgp Description: PGP signature ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AC97 sound problems with current
> Date: Wed, 26 Mar 2003 22:43:17 -0700 > From: Scott Long <[EMAIL PROTECTED]> > > Orion Hodson wrote: > > Kevin Oberman writes: > > | > > | After upgrading my laptop from STABLE to CURRENT on 3/14 I have been > > | having problems with GnomeMeeting. Often the sound is badly broken with > > | 'spurts' of sound with silent gaps in between. This was never the case > > | with STABLE. Other times it's fine. > > | > > | When I looked at my dmesg output I noticed some changes between STABLE > > | and CURRENT for the pcm0 device. Under STABLE I only got two messages: > > | pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff irq 11 at > > device 31.5 on pci0 > > | pcm0: > > | Under CURRENT I get a third: > > | > > | pcm0: measured ac97 link rate at 51200 Hz > > > > There is a calibration step in the driver to determine the clock rate of the > > AC97 link. What you are seeing is the calibration step failing and setting a > > bogus ac97 link rate. I took a cursory look a couple of weeks back and it > > smelt like the timecounter initialization point changed, but haven't gotten > > around to looking closer and fixing the driver. > > If this were true then I'd be very concerned. Let me know what you > find. For what it's worth, my ICH3 setup is still working fine when > loaded at boot, though my kernel is about 2 weeks old. I have a system with problems and would be happy to help out as much as I have the time for. Unfortunately, I have a project due at work on Monday, and will be on vacation the rest of the week (but on line Tuesday and Wednesday). I'm afraid that I have never written a driver for FreeBSD, so I may be of limited help. I have written drivers or other OSes, but they were all written in assembly, not C and I wrote the last one at least 15 years ago. But I am will to do what I can, at least test code others provide. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Updated pci/if_* attach patches
I have made the following updates and these should be the versions that will be committed (modulo any bugs people may find). * Move bus_setup_intr to after ether_ifattach. This removes the need for any locking in *_attach because interrupts, even if shared, will not be delivered until *_intr is hooked. * Add bus_child_present check to calls to *_stop in the detach method for devices that have children (i.e. miibus). If you have one of these ethernet cards, please test the patches found at: http://www.root.org/~nate/freebsd/if-diffs/ Thanks, Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Port breakage (isnan undeclared)
On Thu, Mar 20, 2003 at 08:27:06PM +1100, Tim Robbins wrote: > On Thu, Mar 20, 2003 at 12:55:22AM -0800, Kris Kennaway wrote: > > > Several ports have become broken recently with the following error: > > > > ../../../include/osg/Math:149: `isnan' undeclared (first use this function) > > > > http://bento.freebsd.org/errorlogs/i386-5-latest/osg-0.9.3.log > > http://bento.freebsd.org/errorlogs/i386-5-latest/gnucap-0.31.log > > http://bento.freebsd.org/errorlogs/i386-5-latest/fractorama-1.6.4.log > > > > Can someone please investigate? > > The prototypes for isnan() &c. need to be put back into math.h, and their > source files need to be un-deprecated. Any progress on this? Kris pgp0.pgp Description: PGP signature ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ports broken due to -current change (Re: Ports broken on ia64)
On Tue, Mar 18, 2003 at 09:31:48PM -0500, Mike Barcroft wrote: > > stat.h: > > $FreeBSD: src/sys/sys/stat.h,v 1.34 2003/03/14 16:09:48 mike Exp $ > > I think I see the problem. I'll try to get a fix committed by > tonight. Still appears to be broken with r1.35: http://bento.freebsd.org/errorlogs/i386-5-latest/osh-020214.log http://bento.freebsd.org/errorlogs/i386-5-latest/aide-0.9.log ... Kris pgp0.pgp Description: PGP signature ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Strange behaviour with host(1) SOLVED
The problem was bind9, even though I thought it was bugging before the install of it. The host(1) who comes with bind9 doesnt work the way that the one in base does. Crap :( Erik. > Hi, I'm trying to get host working properly with ipv6 on > 5.0-RELEASE-p6. > > Example: > > [EMAIL PROTECTED] uname -sr > -[~]-[11:06PM]- > FreeBSD 4.7-RELEASE-p1 > [EMAIL PROTECTED] host 6bone.net > -[~]-[11:06PM]- > 6bone.net has address 206.123.31.124 > 6bone.net has address 3ffe:b00:c18:1::10 > 6bone.net mail is handled (pri=10) by quark.isi.edu > 6bone.net mail is handled (pri=20) by darkstar.isi.edu > 6bone.net mail is handled (pri=0) by venera.isi.edu > > While, on my personal 5.0: > > -su-2.05b# uname -sr > FreeBSD 5.0-RELEASE-p6 > -su-2.05b# host 6bone.net > 6bone.net has address 206.123.31.124 > > > Why is this happening? I've tried to change nameservers, no > luck. Tried to install bind9-base, no luck. I'm basically out > of ideas. The server has IPV6 up and running. The only thing > that works is if I specify -t : > > -su-2.05b# host -t irc6.qeast.net > irc6.qeast.net has address 2001:510:0:13:: > > Erik. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
including a kernel config in another
I would like to include a kernel config file in another, as is done with the SMP config file and how it includes the GENERIC config file. When I try this with including any config file other than GENERIC, I get a syntax error. IS GENERIC the only config that can be included or am I doing something wrong? Thanks. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Strange behaviour with host(1)
Hi, I'm trying to get host working properly with ipv6 on 5.0-RELEASE-p6. Example: [EMAIL PROTECTED] uname -sr -[~]-[11:06PM]- FreeBSD 4.7-RELEASE-p1 [EMAIL PROTECTED] host 6bone.net -[~]-[11:06PM]- 6bone.net has address 206.123.31.124 6bone.net has address 3ffe:b00:c18:1::10 6bone.net mail is handled (pri=10) by quark.isi.edu 6bone.net mail is handled (pri=20) by darkstar.isi.edu 6bone.net mail is handled (pri=0) by venera.isi.edu While, on my personal 5.0: -su-2.05b# uname -sr FreeBSD 5.0-RELEASE-p6 -su-2.05b# host 6bone.net 6bone.net has address 206.123.31.124 Why is this happening? I've tried to change nameservers, no luck. Tried to install bind9-base, no luck. I'm basically out of ideas. The server has IPV6 up and running. The only thing that works is if I specify -t : -su-2.05b# host -t irc6.qeast.net irc6.qeast.net has address 2001:510:0:13:: Erik. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
psmintr: out of sync
Hi, Not sure what happened to the original message, sorry for the noise! I am running a recent current: FreeBSD opal.macaroon.net 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Mar 26 16:18:16 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 The machine is a Dell Inspiron 4000 laptop. It is running XFree86-4.3.0 It has both a trackpad and a pointing stick (?what is the real name for this, I always call them nipples?), and it is seems to be the mouse I am having a problem. Every now and again, but with great regularity the screen will freeze up, so that nothing works, not even the caps lock light. However, it isn't a crash as leaving the machine alone for a random amount of time will normally fix it. Sometimes this delay is a matter of seconds, other times I have left if for about 20+mins. Interestingly enough, pinging the laptop from another computer will always unfreeze it immediately. As this occurs the following is printed to the console: Mar 27 11:23:57 opal kernel: psmintr: out of sync (00c0 != ). Mar 27 11:23:58 opal kernel: psmintr: discard a byte (1). The above appears for each freeze, and every now and again this appears: Mar 27 11:23:57 opal kernel: psmintr: out of sync (00c0 != ). Mar 27 11:23:58 opal kernel: psmintr: discard a byte (1). Mar 27 11:23:58 opal kernel: psmintr: out of sync (0040 != ). Mar 27 11:23:58 opal kernel: psmintr: discard a byte (2). Mar 27 11:23:58 opal kernel: psmintr: out of sync (00c0 != ). Mar 27 11:23:58 opal kernel: psmintr: re-enable the mouse. When the re-enable the mouse message happens then the pointing stick stops working and only the trackpad functions. This started happening with 5-RELEASE though not when -RELEASE was first installed. I am not sure what has caused it. Probably completely unrelated but the below appears on boot up, (GENERIC kernel - ie, WITNESS and INVARIANTS) pci0: at device 7.3 (no driver attached) pcm0: port 0xc800-0xc8ff mem 0xf9ffe000-0xf9ff irq 5 at device 8.0 on pci0 pcm0: malloc() of "64" with the following non-sleepablelocks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc332c6c0) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 malloc() of "16" with the following non-sleepablelocks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc332c6c0) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 malloc() of "16" with the following non-sleepablelocks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc332c6c0) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 malloc() of "16" with the following non-sleepablelocks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc332c6c0) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 malloc() of "64" with the following non-sleepablelocks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc332c6c0) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 malloc() of "16" with the following non-sleepablelocks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc332c6c0) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 malloc() of "16" with the following non-sleepablelocks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc332c6c0) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 malloc() of "16" with the following non-sleepablelocks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc332c6c0) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 pcib2: at device 16.0 on pci0 Thanks a lot! -- Cameron Murdoch <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.x locking plan
:My curiousity has overcome my fear of the bikeshed so I'll ask the :question that has been bugging me for a while. Why haven't we gone :through the tree and created a lock for each spl and then converted every :spl call into the appropriate mtx_lock call? At that point, we can mark :large sections of the tree giant-free and then make the locking data-based :(instead of code-based) one section at a time. This is the approach :Solaris took. : :-Nate The problem is that SPLs are per-thread masks, and different sets of bits can be added or removed from the master mask in any order and at any time. There is no direct translation to a mutex (which cannot be obtained in random order, is not per-thread, and may result in preemption or a context switch). Most of the code locked under Giant assumes the single-threading of kernel threads regardless of the SPL. This 'inherent' single threading is one the reasons why the original code was so efficient. Since preemption can occur now under many new circumstances, including when 'normal' (non-spin) mutexes are used to replace prior uses of SPLs (which could not cause thread level preemption)... well, it basically means there is no easy way to remove Giant short of going through every bit of code and fixing it one subsystem at a time. Giant itself is a special case. It is not a normal mutex. Instead, the kernel very carefully saves and restores the state of Giant on a per-thread basis so programs don't 'need to know' whether Giant is being held or not and so Giant can be held in combination with another mutex without violating the basic 'only one mutex can be held when going to sleep' rule. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.x locking plan
My curiousity has overcome my fear of the bikeshed so I'll ask the question that has been bugging me for a while. Why haven't we gone through the tree and created a lock for each spl and then converted every spl call into the appropriate mtx_lock call? At that point, we can mark large sections of the tree giant-free and then make the locking data-based (instead of code-based) one section at a time. This is the approach Solaris took. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Re: NFS -current
On Thu, 2003-03-27 at 12:24, Steve Sizemore wrote: > On Thu, Mar 27, 2003 at 12:09:28AM -0800, Terry Lambert wrote: > > Steve Sizemore wrote: > > > On Wed, Mar 26, 2003 at 12:18:11AM -0800, Terry Lambert wrote: > > > > In fact, the only legitimate argument I have ever heard for UDP > > > > has been "I have an old Linux install that can't talk TCP, as > > > > only UDP was implemented at the time I installed it". > > > > > > Have you already forgotten the locking problem that you were > > > helping me with last week? The only solution was to use UDP. > > > > Working around a screwed up implementation is not a "legitimate" > > argument. The only legitimate argument to that is "unscrewing" > > the implementation. > > > > 8-). > > I agree with that to a degree - at least from the perspective of a > developer. (If I had the knowledge and time to unscrew the > implementation, I would certainly try.) However, for those who are > primarily sysadmins and FreeBSD advocates, using UDP is a legitimate > alternative to switching to linux. I do not think switching to Linux will fix that TCP Vs UDP issue. I'm in need of an NFS TCP server. Well, at version 2.4.18, I still do not have it. I have a need to run tCP for NFS and not use UDP. For now, FreeBSD will be serving me up NFS shares. > > Steve > -- > Steve Sizemore <[EMAIL PROTECTED]>, (510) 642-8570 > Unix System Manager > Dept. of Mathematics and College of Letters and Science > University of California, Berkeley > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Re: NFS -current
On Thu, Mar 27, 2003 at 12:09:28AM -0800, Terry Lambert wrote: > Steve Sizemore wrote: > > On Wed, Mar 26, 2003 at 12:18:11AM -0800, Terry Lambert wrote: > > > In fact, the only legitimate argument I have ever heard for UDP > > > has been "I have an old Linux install that can't talk TCP, as > > > only UDP was implemented at the time I installed it". > > > > Have you already forgotten the locking problem that you were > > helping me with last week? The only solution was to use UDP. > > Working around a screwed up implementation is not a "legitimate" > argument. The only legitimate argument to that is "unscrewing" > the implementation. > > 8-). I agree with that to a degree - at least from the perspective of a developer. (If I had the knowledge and time to unscrew the implementation, I would certainly try.) However, for those who are primarily sysadmins and FreeBSD advocates, using UDP is a legitimate alternative to switching to linux. Steve -- Steve Sizemore <[EMAIL PROTECTED]>, (510) 642-8570 Unix System Manager Dept. of Mathematics and College of Letters and Science University of California, Berkeley ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AC97 sound problems with current
--- John Hay <[EMAIL PROTECTED]> wrote: > > > > | > There is a calibration step in the driver to > determine the clock rate of th > > | e > > | > AC97 link. What you are seeing is the > calibration step failing and setting > > | a > > | > bogus ac97 link rate. I took a cursory look a > couple of weeks back and it > > | > smelt like the timecounter initialization > point changed, but haven't gotten > > | > > | > around to looking closer and fixing the > driver. > > > > It's definitely nothing to do with the timecounter > - quick test on other h/w > > along similar lines. I don't access to an ich > board to test on - it's > > probably obvious, but I'm not seeing it just now > with visual inspection... > > It doesn't look like it is the timecounters. I just > added some printfs > and it looks like this: > > pcm0: measured ac97 link rate at 51200 Hz > t1 1.098359, t2 1.098363 > ociv 0, nciv 1, bytes 8192 > tsc1 445813142, tsc2 445821922, diff 8780 > > The tsc values are just from rdtsc(), I added tsc1 = > rdtsc() just above > the first microtime() and tsc2 just after the last. > My machine is a 1.8G > P4 (ICH2), so the timecounter values seem correct. > > I have kernel around the middle of Feb that gets the > value right and one > from March 4 that gets it all wrong. > > John > -- > John Hay -- [EMAIL PROTECTED] / > [EMAIL PROTECTED] > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" I also see this problem. On my machine, I dumped the t1 and t2 variables - there's only about 3 microsecond difference!. It seems the calibration loop is entered, but that CIV is immediately updated to the next index, thus getting out of the loop after about 3-4 microseconds. I thought something with the setup of the registers or maybe a blocksize issue, but I'm getting out of my element here. I can try various testing and debug code if needed. Chuck McCrobie [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AC97 sound problems with current
> > | > There is a calibration step in the driver to determine the clock rate of th > | e > | > AC97 link. What you are seeing is the calibration step failing and setting > | a > | > bogus ac97 link rate. I took a cursory look a couple of weeks back and it > | > smelt like the timecounter initialization point changed, but haven't gotten > | > | > around to looking closer and fixing the driver. > > It's definitely nothing to do with the timecounter - quick test on other h/w > along similar lines. I don't access to an ich board to test on - it's > probably obvious, but I'm not seeing it just now with visual inspection... It doesn't look like it is the timecounters. I just added some printfs and it looks like this: pcm0: measured ac97 link rate at 51200 Hz t1 1.098359, t2 1.098363 ociv 0, nciv 1, bytes 8192 tsc1 445813142, tsc2 445821922, diff 8780 The tsc values are just from rdtsc(), I added tsc1 = rdtsc() just above the first microtime() and tsc2 just after the last. My machine is a 1.8G P4 (ICH2), so the timecounter values seem correct. I have kernel around the middle of Feb that gets the value right and one from March 4 that gets it all wrong. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
psmintr: out of sync
___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ng_fec
Hello, The netgraph module fails to build. Could you please take a look at that (and connect it to the build)? /sys/modules/netgraph/fec Thanks, --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel panic - never had one before, what do I do?
On Thu, Mar 27, 2003 at 11:24:44AM +1030, Greg 'groggy' Lehey wrote: > On Wednesday, 26 March 2003 at 13:35:28 +, Jason Morgan wrote: > > I just got a panic. As I have never had one before, I don't know what to > > do. It's on another system so I don't have to reboot immediately (that > > would solve the problem temporarily, wouldn't it?) if someone would give > > me some advice, I could try to help debug it; however, as I'm not a > > coder (not a real one anyway), I don't know how much help I would be. > > > > It's a 5.0-CURRENT system, just installed and built last week. It > > paniced right after doing a source update (not a build, just cvsup). > > The panic error is as follows: > > > > panic: mtx_lock() of spin mutex vnode interlock @ > > /usr/src/sys/kern/vfs_subr.c:3187 > > Take a look at http://www.lemis.com/texts/panic.txt or > http://www.lemis.com/texts/panic.pdf and tell me if that helps. This > will be going into the new edition of "The Complete FreeBSD" in a few > days time, so I'm interested in getting something which is helpful. Thanks. It has been a lot of help and I do think it is of value. Heck, I may even get a copy of "The Complete FreeBSD". Thanks again. Jason > > Greg > -- > See complete headers for address and phone numbers ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: bremfree: removing a buffer not on a queue
My bitty box just crashed out while doing some light desktop work and a small amount of NFS server stuff. The source was cvsup'd a few minutes before the kernel was compiled last Sunday. The contents of dmesg.boot are include below. If it's of any use, the machine crashed badly the day before yesterday during the middle of a background fsck, and a whole pile of unexpected soft update errors popped up. Most of the files reappeared in lost+found, but a few went to swim with the fishes. Nick pancake# uname -a FreeBSD pancake.netability.ie 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Mar 23 11:50:37 GMT 2003 [EMAIL PROTECTED]:/opt/usr.obj.pancake/usr/src/sys/PANCAKE i386 pancake# gdb -k kernel.debug.0 vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 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-undermydesk-freebsd"... panic: bremfree: removing a buffer not on a queue panic messages: --- panic: softdep_disk_io_initiation: read cpuid = 1; lapic.id = 0100 boot() called on cpu#1 syncing disks, buffers remaining... panic: bremfree: removing a buffer not on a queue cpuid = 1; lapic.id = 0100 boot() called on cpu#1 Uptime: 1d22h51m8s Dumping 255 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- Reading symbols from /boot/kernel/snd_pcm.ko...done. Loaded symbols for /boot/kernel/snd_pcm.ko Reading symbols from /boot/kernel/snd_ich.ko...done. Loaded symbols for /boot/kernel/snd_ich.ko Reading symbols from /boot/kernel/nvidia.ko...done. Loaded symbols for /boot/kernel/nvidia.ko Reading symbols from /boot/kernel/linux.ko...done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/acpi.ko...done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/usb.ko...done. Loaded symbols for /boot/kernel/usb.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 239 dumping++; (kgdb) bt full #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 No locals. #1 0xc01d0c22 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371 No locals. #2 0xc01d0f70 in poweroff_wait (junk=0xc035da3f, howto=1) at /usr/src/sys/kern/kern_shutdown.c:542 td = (struct thread *) 0xc0eca1e0 bootopt = 260 buf = "bremfree: removing a buffer not on a queue", '\0' #3 0xc0215800 in bremfreel (bp=0xc035da3f) at /usr/src/sys/kern/vfs_bio.c:636 old_qindex = 260 #4 0xc0215713 in bremfree (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:618 No locals. #5 0xc02177cd in vfs_bio_awrite (bp=0x104) at /usr/src/sys/kern/vfs_bio.c:1687 i = 1 j = 0 lblkno = 11 vp = (struct vnode *) 0xc0eca1e0 ncl = -1070212545 nwritten = -1070212545 size = 8192 maxcl = 16 #6 0xc02c6ef2 in ffs_fsync (ap=0xcd2079cc) at /usr/src/sys/ufs/ffs/ffs_vnops.c:255 ---Type to continue, or q to quit--- vp = (struct vnode *) 0xc3458490 ip = (struct inode *) 0xc7729440 bp = (struct buf *) 0xc7729440 nbp = (struct buf *) 0xc7749470 error = 0 wait = 0 passes = 4 skipmeta = 0 lbn = 14 #7 0xc02c5ff9 in ffs_sync (mp=0xc2657c00, waitfor=2, cred=0xc0eb5e80, td=0xc037e5c0) at vnode_if.h:612 nvp = (struct vnode *) 0xc31fea44 vp = (struct vnode *) 0xc3458490 devvp = (struct vnode *) 0xc3458490 ip = (struct inode *) 0x0 ump = (struct ufsmount *) 0xc2752a00 fs = (struct fs *) 0xc25e6800 error = 0 count = -853509684 wait = 0 lockreq = 18 allerror = 0 #8 0xc022c83b in sync (td=0xc037e5c0, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:138 ---Type to continue, or q to quit--- mp = (struct mount *) 0xc2657c00 nmp = (struct mount *) 0x0 asyncflag = 0 #9 0xc01d0747 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280 bp = (struct buf *) 0xc0ec7080 iter = 4 nbusy = 0 pbusy = 1 subiter = 0 #10 0xc01d0f70 in poweroff_wait (junk=0xc0366096, howto=-1071556845) at /usr/src/sys/kern/kern_shutdown.c:542 td = (struct thread *) 0xc0eca1e0 bootopt = 256 buf = "bremfree: removing a buffer not on a queue", '\0' #11 0xc02bf38c in softdep_disk_io_initiation (bp=0xc0eca1e0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3465 wk = (struct worklist *) 0xc0366096 nextwk = (struct worklist *) 0xc775fba8 indirdep = (struct indirdep *) 0x100 inodedep = (struct inodedep *) 0x0 #12 0xc021e43d in cluster_wbuild (vp=0xc3458490, size=8192, start_lbn=11, len=2) at buf.h:422 bp = (struct buf *) 0xc76b2fe8 ---Type to continue, or q to quit---
unrecognized Prism III card
Hi folks, I picked up a couple of no-name Prism III cards, and found that FreeBSD-current doesn't recognize them. Is there anything I can do to make these work? (Up to and including shipping a card to a committer?) Mar 27 07:14:35 pedicular kernel: pccard1: (manufacturer=0x50c2, product=0x7300) at function 0 Mar 27 07:14:35 pedicular kernel: pccard1:CIS info: WLAN, PRISM PCMCIA CARD, 37300P Thanks, ==ml -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.BlackHelicopters.org/~mwlucas/ Absolute BSD: http://www.AbsoluteBSD.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: -current amanda dump -L
On Thu, Mar 27, 2003 at 03:30:04AM -0600, Aaron Wohl wrote:
> How can I convince the amanda backup system to use -L when running dumps
> so it can take advantage of using snapshots? I checked all the amanda
> web man pages abd FAQ system but didnt see anything on snapshoting or
> giving extra options to dump.
How about putting this short wrapper in amanda's path?
#!/bin/sh
exec dump -L ${1+"$@"}
--
Joshua Goodall
[EMAIL PROTECTED] "Your object hit ratio is weak, old man"
"If you cache me now, I will dump more core than you can possibly imagine"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
malloc problem ?
Hello, dmesg give me a lot of messages like this: Stack backtrace: malloc() of "128" with the following non-sleepablelocks held: exclusive sleep mutex netisr lock r = 0 (0xc04777e0) locked @ /usr/src/sys/net/netisr.c:215 malloc() of "64" with the following non-sleepablelocks held: exclusive sleep mutex netisr lock r = 0 (0xc04777e0) locked @ /usr/src/sys/net/netisr.c:215 malloc() of "64" with the following non-sleepablelocks held: exclusive sleep mutex netisr lock r = 0 (0xc04777e0) locked @ /usr/src/sys/net/netisr.c:215 malloc() of "128" with the following non-sleepablelocks held: exclusive sleep mutex netisr lock r = 0 (0xc04777e0) locked @ /usr/src/sys/net/netisr.c:215 malloc() of "64" with the following non-sleepablelocks held: exclusive sleep mutex netisr lock r = 0 (0xc04777e0) locked @ /usr/src/sys/net/netisr.c:215 malloc() of "128" with the following non-sleepablelocks held: exclusive sleep mutex netisr lock r = 0 (0xc04777e0) locked @ /usr/src/sys/net/netisr.c:215 and my computer identity: fileserver# uname -a FreeBSD fileserver.lapi.itb.ac.id 5.0-CURRENT FreeBSD 5.0-CURRENT #4: Fri Mar 21 10:31:26 WIT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAMBA i386 thanks ! -dikshie- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
-current amanda dump -L
How can I convince the amanda backup system to use -L when running dumps so it can take advantage of using snapshots? I checked all the amanda web man pages abd FAQ system but didnt see anything on snapshoting or giving extra options to dump. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
-current amanda dump -L
How can I convince the amanda backup system to use -L when running dumps so it can take advantage of using snapshots? I checked all the amanda web man pages abd FAQ system but didnt see anything on snapshoting or giving extra options to dump. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AC97 sound problems with current
/-- Scott Long wrote: | Orion Hodson wrote: | > There is a calibration step in the driver to determine the clock rate of th | e | > AC97 link. What you are seeing is the calibration step failing and setting | a | > bogus ac97 link rate. I took a cursory look a couple of weeks back and it | > smelt like the timecounter initialization point changed, but haven't gotten | | > around to looking closer and fixing the driver. | | If this were true then I'd be very concerned. Let me know what you | find. For what it's worth, my ICH3 setup is still working fine when | loaded at boot, though my kernel is about 2 weeks old. It's definitely nothing to do with the timecounter - quick test on other h/w along similar lines. I don't access to an ich board to test on - it's probably obvious, but I'm not seeing it just now with visual inspection... - Orion ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Re: NFS -current
Steve Sizemore wrote: > On Wed, Mar 26, 2003 at 12:18:11AM -0800, Terry Lambert wrote: > > In fact, the only legitimate argument I have ever heard for UDP > > has been "I have an old Linux install that can't talk TCP, as > > only UDP was implemented at the time I installed it". > > Have you already forgotten the locking problem that you were > helping me with last week? The only solution was to use UDP. Working around a screwed up implementation is not a "legitimate" argument. The only legitimate argument to that is "unscrewing" the implementation. 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
