IP over IEEE1394?
Hi, there is some plan to port NetBSD's implementation of IP over Firewire? I know, we have "Ethernet over Firewire", but like the Linux one, isn't a standard... Just curious. -- (_ ) "Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with." \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Tiny BSD Pages
Hi, Chris Fowler schrieb: I do one thing in Linux that I want to do in FreeBSD. I store my root file system as a blow fish, gzipped, encrypted file on a DiskOnChip. I have done exactly this some years ago, checkout PicoBSD (freebsd-small mailinglist). But I don't know the current status of PicoBSD. see also: http://people.freebsd.org/~picobsd/ bye, -- --- -- Michael Bretterklieber - [EMAIL PROTECTED] JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200-- privat A-8041 GRAZ GSM: ++43-(0)676-84 03 15 712 Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED] Fax: ++43-(0)316-403274-10 http://www.bretterklieber.com --- -- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: type errors in src-tree
On Tue, Mar 04, 2003 at 11:01:25PM -0800, David O'Brien wrote: > On Mon, Mar 03, 2003 at 12:08:04AM +0100, Jens Rehsack wrote: > > Now, that OpenWatcom is released, the FreeBSd port of it should follow. > > And maybe someone will try to compile the kernel and world with it. > > I hate to be the skeptic, but looking at OpenWatcom 1.0, it only produces > dos and win32 binaries. It will be a *long* time until it targets Unix > correctly. I think the bigger problem is to make the compiler a Unix program itself. The whole tree is pretty much non-portable at this time. Generating code for Unix is the least of the problems (assuming no compiler special libc implementation). I started playing with TenDRA as well and even though the compiler isn't usable yet, it's much more Unix oriented. Instead of mucking with getting a proprietary make variant to compile or figuring out if you should replace all slash options for dash options, you can pretty much focus on the compiler itself from the word go. Needless to say that for OW I'm going to piggyback the Linux port. TenDRA has a higher chance of being able to compile world and kernel I think before OW. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Volunteer with genuine i386 cpu & lots of time wanted.
In message <[EMAIL PROTECTED]>, Andy Farkas writes: >I'll try and get some data for your clock/time tracking requests in a few >days. I assume you want wall-clock tracking info for both with and >without ntpd running? yes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: nvidia module panics today's kernel [03-03-03]
Hi, thanks Maxime, your patch works ok! Well, the nVIDIA driver is labeled "beta quality" anyway, so, why not upgrade nvidia-driver port to support 5-CURRENT too? I'm actually using it, with a ugly hack: applying the patch, compacting and copying the new distfile, editing Makefile to comment 4.x (/dev entries) stuff and 5.x (IGNORE), make NO_CHECKSUM=yes install clean. It's working great, my "big" stress test is the glx version of Quakeforge. :) I can run it in a range of 40-77 FPS (640x480, fullscreen). glxgears reports 551.400 FPS in default size. My hardware setup: AMD Athlon XP 1800+ (@ 1.53GHz) ASUS A7N266-VM (nForce based, Integrated GeForce2, sharing 32MB) 256MB DDR266 -- (_ ) "Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with." \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) - On Tue, 4 Mar 2003, Maxime Henrion wrote: > walt wrote: > > My mini 'disaster' of earlier today was caused by the nvidia kernel > > module being autoloaded at boot, which causes an immediate kernel panic. > > > > The newest kernel seems fine until I try to load the module manually, > > at which time I still get the kernel panic even after re-compiling > > the module. > > > > Maxime, it looks like the nvidia module will need to be sculpted one > > more time. :-( > > Yes, the cdevsw initialization scheme and the driver needs to be updated > accordingly. I've updated my patch at : > > http://mu.org/~mux/patches/nvidia.patch > > Cheers, > Maxime > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
boot0cfg
Last weekend I had to reinstall Windows XP on my PC and certainly I lost boot manager. After booting from CD and mounting as root ad0 device, I replaced boot0 record using the following command line : # boot0cfg -Bv -s 1 -t 91 ad0 On my PC I have 14G Windows XP partition(primary partition), 7G Linux (2 extended partitions) and 7G FreeBSD 5.0 - Current (primary partition). On second disk I have Windows 98. After installing I see something like this : F1 - ??? F3 - FreeBSD F5 - Disk 2 It is strange that only F1 works (start Windows XP), while F3 play some sound. Pressing F5 starts Windows XP, but it could be because Windows on my second disk. Yes I know that there are other boot managers like GRUB, but it is another beer. I haven't enough time to investigate where the problem is (boot0 code), but this evening I should. Any comments would be greatly appreciated. Dimitar Peikov Software Developer ___ BORG INSTRUMENTS Ltd. 17 Washington str. BG - 1040, Sofia Tel.: +359 (0) 2 989 5523 Fax: +359 (0) 2 989 5585 mailto:[EMAIL PROTECTED] http://www.borg.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: type errors in src-tree
> From: "David O'Brien" <[EMAIL PROTECTED]> > To: "Jens Rehsack" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Wednesday, March 05, 2003 10:01 AM > Subject: Re: PATCH: type errors in src-tree > > On Mon, Mar 03, 2003 at 12:08:04AM +0100, Jens Rehsack wrote: > > Now, that OpenWatcom is released, the FreeBSd port of it should follow. > > And maybe someone will try to compile the kernel and world with it. > > I hate to be the skeptic, but looking at OpenWatcom 1.0, it only produces > dos and win32 binaries. It will be a *long* time until it targets Unix > correctly. Just FYI: Well, not only dos and win32, but it will be really long... What they have now: > From: "Bart Oldeman" <[EMAIL PROTECTED]> > Newsgroups: openwatcom.contributors > Sent: Sunday, March 02, 2003 7:36 AM > Subject: Re: bootstrap on linux > > In article <[EMAIL PROTECTED]>, Andi Kleen wrote: > > Michal Necasek <[EMAIL PROTECTED]> writes: > > > >> Andi Kleen wrote: > >>> does a native bootstrap on linux of openwatcom work yet? > >>> > >> No. Some of the tools can be built and some even work but not > >> enough to get the build environment going. > > > > Can you elaborate a bit on it. What does work, what doesn't? > > the compilers work (wcc386 and wcc), compiled using gcc and compiled > using watcom. they can however (still) only reliably output OMF > objects. > > wlink can be cross-compiled for Linux but crashes (SIGSEGV) if you > run it there to combine several OMFs into an ELF executable. Without > a working linker the Linux hosted compiler isn't very useful yet > -- and a full bootstrap impossible. > > There has been an attempt to cross-compile wasm, I'm not sure how > far that went. > > wmake cannot be compiled yet -- it uses spawnxx calls that would > need to be translated into fork()s and execve()s for Linux (using > a wrapper or to be implemented in the Watcom LIBC). > > And Linux development has stalled for the last month (lack of time of > the contributors). > > Bart heh > > > If that would work, this would be great, because the watcom compiler > > generates much better code than gcc does, even than gcc -O3 (and all > > known optimizations on). > > Rather than just repeat some old wife's tale; can anyone produce a real > analysis backing this statement up? Not me :) Igor To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Witness problem with sound
> -Original Message- > From: Pete Carah [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 05, 2003 2:43 AM > To: [EMAIL PROTECTED] > Subject: Witness problem with sound > > > I don't know how system-specific this problem is, but: it's not system-specifiv > Problem: > .. > Mar 4 14:56:27 port2 kernel: > /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:748 this problem is in last (1.27->1.28) changes in /usr/src/sys/dev/sound/pcm/feeder.c (if I remember correctly) You can revert to previous version (1.27) if you don't want to see witness messages. Yuriy Tsibizov, http://chibis.persons.gfk.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems compiling KDE after mega-commit
Yep, this message is no more about KDE. :) Thanks Sergey, your patch isn't in ports tree yet, but I used it, ltmdm now compiles and works. I'm running today's version of CURRENT. kern.osreldate: 500105 dmesg: ltmdm0: port 0xb000-0xb0ff,0xb400-0xb407 mem 0xdc00-0xdcff irq 5 at device 8.0 on pci1 ltmdm0: type Virtual 16550A Allocating major#251 to "ltmdm" pciconf -lv: [EMAIL PROTECTED]:8:0:class=0x078000 card=0x04401668 chip=0x044011c1 rev=0x01 hdr=0x00 vendor = 'Lucent/Agere Systems (Was: AT&T MicroElectronics)' device = 'LT Winmodem 56k Data+Fax+Voice+DSVD' class= simple comms -- (_ ) "Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with." \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) - On Tue, 4 Mar 2003, Sergey A. Osokin wrote: > On Tue, Mar 04, 2003 at 04:39:46AM -0300, Rossam Souza Silva wrote: > > > > Yes, I had problems with icewm in CURRENT too, but tried to compile > > it before the mega-commit (version of 3-4 days ago). My workstation > > at work (version of two weeks ago) installed icewm from ports without > > problem. > > > > I upgraded my ports tree and now I'm running portupgrade -u --all before > > try KDE again. ltmdm (changed from 1.4_3 to 1.4_4) continues broken: > > > > [EMAIL PROTECTED]:/usr/ports/comms/ltmdm> sudo make clean > > ===> Cleaning for ltmdm-1.4_4 > > [EMAIL PROTECTED]:/usr/ports/comms/ltmdm> sudo make > [skip build log] > > elements in struct initializer > > /usr/ports/comms/ltmdm/work/sys/dev/ltmdm/ltmdmsio.c:389: warning: (near > > initialization for `sio_cdevsw') > > *** Error code 1 > > > > Stop in /usr/ports/comms/ltmdm/work/sys/modules/ltmdm. > > *** Error code 1 > > > > Stop in /usr/ports/comms/ltmdm. > > Look at http://www.freebsd.org/cgi/query-pr.cgi?pr=48922 > > > > On Tue, Mar 04, 2003 at 01:57:46AM -0500, Andre Guibert de Bruet wrote: > > > > > > > > You need to upgrade your ports skeleton. There's a couple of fixes that > > > > were committed within the last 24 hours which fix these issues. > > > > > > Hmm..I've seen this on another port already (icewm, I think). It > > > looks like phk might have some additional patching to do when I get > > > him the full list. > > -- > > Rgdz,/"\ ASCII RIBBON CAMPAIGN > Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL > http://ozz.pp.ru/ X AND NEWS > / \ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Volunteer with genuine i386 cpu & lots of time wanted.
David O'Brien wrote: > On Wed, Mar 05, 2003 at 12:27:19PM +1000, Andy Farkas wrote: > > Well, finally got a kernel to boot on a 16MHz 386SX (suicidal is an > > understatement!) - will this do? > > Can you post the /var/run/dmesg.boot? Should be very interesting to see the output of this file :) > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: type errors in src-tree
On Mon, Mar 03, 2003 at 12:08:04AM +0100, Jens Rehsack wrote: > Now, that OpenWatcom is released, the FreeBSd port of it should follow. > And maybe someone will try to compile the kernel and world with it. I hate to be the skeptic, but looking at OpenWatcom 1.0, it only produces dos and win32 binaries. It will be a *long* time until it targets Unix correctly. > If that would work, this would be great, because the watcom compiler > generates much better code than gcc does, even than gcc -O3 (and all > known optimizations on). Rather than just repeat some old wife's tale; can anyone produce a real analysis backing this statement up? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
IPFILTER broken as of world/kernel a few hours old
With IPFILTER enabled in the kernel, all socket(2) calls inbound/outbound are very slow. A normal SSH connection within the same subnet takes 5 minutes to connect. Anything I can provide to pin down the problem? Jiawei -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Volunteer with genuine i386 cpu & lots of time wanted.
On Wed, Mar 05, 2003 at 12:27:19PM +1000, Andy Farkas wrote: > Well, finally got a kernel to boot on a 16MHz 386SX (suicidal is an > understatement!) - will this do? Can you post the /var/run/dmesg.boot? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Witness problem with sound
On Tue, Mar 04, 2003 at 03:42:43PM -0800, Pete Carah wrote: > Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:748 > Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with I'm seeing something somewhat similar here. Whenever I play any audio, I get an endless stream of: malloc() of "64" with the following non-sleepablelocks held: exclusive sleep mutex pcm0:play:1 (pcm channel) r = 0 (0xc6794740) locked @ /usr/src/sys/dev/sound/pcm/dsp.c:673 This is with: FreeBSD edgemaster.zombie.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Mar 4 20:30:35 CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ EDGEMASTER i386 FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0xcc00 irq 10 (4p/2r/4v channels duplex default) -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org pgp0.pgp Description: PGP signature
Re: Removal of netns
On Wed, 5 Mar 2003, Tim Robbins wrote: > Is there a compelling reason why I shouldn't remove netns? That is, does > it serve a purpose now that it could not serve if it was moved to the > Attic? netns could be safely moved to Attic. I'm receive enough IPX related questions, and never got any about XNS. netns stack was used by NetCon package which implemented TFS filesystem for NetWare connectivity. Guess, which protocol they used to communicate with servers ? Right, it was IPX. So, if netns were still supported it became just a parallel implementation of netipx. Last version of FreeBSD supported by NetCon was 2.2.X. Lack of support for FreeBSD 3.X encouraged me to write nwfs because it was necessary for my daily tasks. BTW, NetCon still offers their product for FreeBSD 2.2: http://www.netcon.com/download/download.htm -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Witness problem with sound
I'm getting the "could sleep with" messages repeated over and over on my Dell Lattitude C800 which uses the maestro3 chip. The sound isn't overly choppy. It only stutters under disk/compute activity. > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> On Tue, 4 Mar 2003, Pete Carah wrote: > I don't know how system-specific this problem is, but: > > Sony VAIO R505ES > Sound is Intel ICH3 + Yamaha. > > This or something closely related has been happening for weeks. > Several times earlier this week and last week sound panic'd, and > also sometimes there was a panic (several different kinds) on boot. > Late last week X wouldn't start due to not being able to see the > VESA modes. > All those except the sound problems currently appear fixed... > > This may or may not be related to the fact that acpi puts nearly all > device interrupts on irq 9 (which causes other problems). > > Problem: > .. > Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:748 > Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:748 > Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:748 > Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:696 > Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:696 > Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:696 > Mar 4 14:56:28 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:696 > Mar 4 14:56:28 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:696 > Mar 4 14:56:28 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:696 > Mar 4 14:56:28 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:673 > Mar 4 14:56:28 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:673 > Mar 4 14:56:28 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with > "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:673 > . > (repeated by the thousands, at various lines, the above plus > sound.c:191 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Volunteer with genuine i386 cpu & lots of time wanted.
On Wed, 26 Feb 2003, Poul-Henning Kamp wrote:
> Is there anybody out there who can try to run a straight -current
> on a _real_ i386 class CPU ?
>
> Ie, not a i486, not a Cyrix, not an AMD but a genuine Intel i386DX
> (SX would be but too suicidal to be informative).
Well, finally got a kernel to boot on a 16MHz 386SX (suicidal is an
understatement!) - will this do?
(Actually, the box is a AST Bravo/286 with the 80286 CPU replaced with a
386SX upgrade. The company I used to work for made various CPU upgrade
products for 286's and 386's in the early 90's, especially for IBM PS/2's)
Had to patch the npx_attach() function in src/sys/i386/isa/npx.c to get it
to work though. It seems revision 1.131 broke FPU-less CPU support:
(bad bde, no cookie)
> diff -u npx.c-orig npx.c
--- npx.c-orig Wed Mar 5 11:42:49 2003
+++ npx.c Wed Mar 5 11:43:27 2003
@@ -495,7 +495,7 @@
}
npxinit(__INITIAL_NPXCW__);
- if (npx_cleanstate_ready == 0) {
+ if (npx_cleanstate_ready == 0 && npx_exists) {
s = intr_disable();
stop_emulating();
fpusave(&npx_cleanstate);
I'll try and get some data for your clock/time tracking requests in a few
days. I assume you want wall-clock tracking info for both with and
without ntpd running?
> I am also not interested in people running heavily modified source
> trees, it is -current I am interested in. (It's OK to fiddle the
> kernel config and hints of course.)
>
> If somebody has the time and inclination, I have a number of questions
> I would like answers to:
>
> 1. Does -current even boot on that vintage of hardware any more ?
>
> 2. Does it survive a kernel (GENERIC) build ?
> 2a. Does the clock track wall-clock time correctly while doing so ?
>
> 3. Does it survive a buildworld ?
> 3a. Does the clock track wall-clock time correctly while doing so ?
>
> 4. Can ntpd run against some random (but decent) NTP server steer
> the clock ?
> 1) If the machine is idle
> 2) During buildworld.
> Please notice if
> a) ntpd resorts to clock steps
> b) ntpd exits
> c) ntpd core dumps
>
> Thanks in advance!
>
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: A few 5.0-Release questions...
--- Scott Long <[EMAIL PROTECTED]> wrote: [Dell PowerEdge] > What model? There are quite a few PowerEdges out It's a 600SC - P4 1.8 - Perc3/SC Since new, I've added a Plextor CD-RW (IDE), Lite-On DVD-ROM (IDE), and an ATI All-In-Wonder VE (7500, PCI). > > These machines come with integrated video, an ATI [Complications with integrated RageXL and PCI version of the ATI AIW VE... NMI halts] > As a wild guess, what happens when you remove the > EISA device from the kernel? I tried this as well. Unfortunately, removing the EISA device did nothing to relieve the problem with the NMI. The only thing that cleared it up was adding 'hw.pci.enable_io_modes=0' in /boot/device.hints. This was the case, at least, with 5.0-RELEASE. I've yet to see what happens with -CURRENT. Perhaps I'll try and cvsup -CURRENT, remove 'hw.pci.enable_io_modes=0', and see what happens. > There have been problems in the past with ATAPI/IDE > drives that claim DMA capabilities but instead corrupt data > and/or cause panics. Forcing everything to PIO is the > easiest way to achieve maximum compatibility. The ata manual > page describes what to put into /boot/loader.conf to > force them back using DMA. I pulled these two drives from a WinXP machine, and based on the transfer method reported in XP, it was using DMA. No stability issues were noted, at least in regard to XP. I've been running them under 5.0 now for a few days, burned a few CD's and played a few DVD's without stability issues either -- thankfully. I'll check out the above referenced manual page and make the suggested changes. Thank you for the tip. [About permanently disabling the integrated video] > Does the motherboard have a jumper that will disable > it? Unfortunately, no. I've even contacted Dell regarding this as I could find no information in the documentation provided with the system. They simply stated that when another video card is installed, the integrated video is disabled. They also mentioned that this type of configuration "is not supported." I've looked for jumpers on the motherboard itself and only found jumpers for clearing the BIOS password... nothing else. Thank you once again, Scott, for your help. It was very much appreciated. - John Wilson <[EMAIL PROTECTED]> __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] make netns compile cleanly (was Re: Removal of netns - politically correct version
Terry Lambert wrote: > Terry Lambert wrote: > > Peter Wemm wrote: > > > Terry: will you please check your facts? It takes around 30 seconds > > > to find out that it doesn't even compile. > > > > [ ... lots of trivial to fix warnings and errors ... ] > > > > Tell you what, I'll fix these and post a patch. Will that make you > > guys happy? > > > > This crap is *s* trivial to fix, it's easier to fix than > > to watch you guys bitch about it not being fixable. > > > Here are two patches. The first fixes missing pieces in /sys/conf/files > and /sys/conf/options, the second fixes all the files that need it in > /sys/netns/. You seem to have posted the wrong patch. This is against 4.x, not -current, and this is [EMAIL PROTECTED] Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert wrote: > Peter Wemm wrote: > > Terry Lambert wrote: > > > Is there a compelling reason for removing this working code to > > > the Attic? > > > > Terry: will you please check your facts? It takes around 30 seconds > > to find out that it doesn't even compile. > > [ ... lots of trivial to fix warnings and errors ... ] > > > Tell you what, I'll fix these and post a patch. Will that make you > guys happy? Not really. I'd like to see a relevant demonstration of it working with another relevant networking system [that does NOT speak some other common protocol such as IP or IPX] that shows that it is worth keeping this baggage around. No, I'm not interested in some DOS-2.11 floppy disks you have had sitting untouched in a drawer for 10 years. ie: Show that it is worth something to the project to keep it. This was only revived last time because somebody promised to maintain it. And as you can see, for the last 7 years it hasn't been missed. The point wasn't that "it doesn't compile", rather "nobody gave a damn that it didn't compile for 7 years". Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Oops, never mind (was Re: 5.0 Release: `npx_driver',`npx_devclass'defined but not used, breaks kernel build
Haha. I'm an idjit. Sorry. That's what happens when you take isa out of the kernel config (what was I thinking anyway? - fd and atkbdc among others need this and I knew that). On Tue, 4 Mar 2003, Geoffrey wrote: > > This is repeatable. Re-cvsupped using the same tag yesterday > morning and rebuilt on a clean /obj with the same result. > 5.0 Release appears to be broken. > > On Sun, 2 Mar 2003, Geoffrey wrote: > > > > Ladies and Gentlemen > > > > From a fresh cvsup of RELENG_5_0 this afternoon, make buildkernel > > returns: > > > > cc1: warnings being treated as errors > > /usr/src/sys/i386/isa/npx.c:1078: warning: `npx_driver' defined but not > > used > > /usr/src/sys/i386/isa/npx.c:1084: warning: `npx_devclass' defined but not > > used > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/BINKY1. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > > > This is with -march=pentium-mmx in make.conf and device npx > > in my kernel configuration. > > > > Suggestions? Remedies? > > > > Thankyou. > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
Darcy Buskermolen wrote: > I have at least 1 VPN setup that requires full IPX support. Yep, but keep in mind that netipx is different to netns. netipx actually works and is actually useful. > On Tuesday 04 March 2003 15:32, Chris Fowler wrote: > > What is IPX currently being used for? Legacy systems? > > > > I've been stuck in TCP/IP land for many years now. Have been lucky > > enough to not run into any IPX. > > > > On Tue, 2003-03-04 at 18:26, Tim Robbins wrote: > > > On Tue, Mar 04, 2003 at 02:53:56PM -0800, Julian Elischer wrote: > > > > I thought nwfs used it? > > > > > > nwfs uses netipx. From what I can tell, netipx was based on netns. > > > > > > > > > Tim > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-current" in the body of the message > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-net" in the body of the message > > --=20 > Darcy Buskermolen > Wavefire Technologies Corp. > ph: 250.717.0200 > fx: 250.763.1759 > http://www.wavefire.com > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
Julian Elischer wrote: > I thought nwfs used it? Nope. But actually looking at the code would have told you that. Remember, we're talking about the Xerox networking suite here. It's not like its a widely deployed protocol or something important. > > On Wed, 5 Mar 2003, Tim Robbins wrote: > > > Is there a compelling reason why I shouldn't remove netns? That is, does > > it serve a purpose now that it could not serve if it was moved to the > > Attic? > > > > > > Tim > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-net" in the body of the message > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH] make netns compile cleanly (was Re: Removal of netns - politically correct version
Terry Lambert wrote:
> Peter Wemm wrote:
> > Terry: will you please check your facts? It takes around 30 seconds
> > to find out that it doesn't even compile.
>
> [ ... lots of trivial to fix warnings and errors ... ]
>
> Tell you what, I'll fix these and post a patch. Will that make you
> guys happy?
>
> This crap is *s* trivial to fix, it's easier to fix than
> to watch you guys bitch about it not being fixable.
Here are two patches. The first fixes missing pieces in /sys/conf/files
and /sys/conf/options, the second fixes all the files that need it in
/sys/netns/.
It's now possible to add:
options NS
to a kernel config, and still get a kernel that does it's thing.
Note that I did not go through and made the protosw[] changes,
so there's some initialization warnings there, but by my clock,
I only spent an hour on the thing, and what you guys were bitching
about was "it doesn't even compile".
If you want that fixed too, then it's an easy fix, using the IPX
sources as a guide, since IPX is derives from XNS.
-- TerryIndex: files
===
RCS file: /usr/cvs/src/sys/conf/files,v
retrieving revision 1.340.2.87
diff -c -r1.340.2.87 files
*** files 19 Dec 2001 20:59:27 - 1.340.2.87
--- files 5 Mar 2003 00:49:18 -
***
*** 923,928
--- 923,929
netns/ns_output.c optional ns
netns/ns_pcb.coptional ns
netns/ns_proto.c optional ns
+ netns/ns_cksum.c optional ns
netns/spp_debug.c optional ns
netns/spp_usrreq.coptional ns
nfs/nfs_bio.c optional nfs
Index: options
===
RCS file: /usr/cvs/src/sys/conf/options,v
retrieving revision 1.191.2.37
diff -c -r1.191.2.37 options
*** options 3 Nov 2001 01:41:07 - 1.191.2.37
--- options 4 Mar 2003 22:10:11 -
***
*** 272,277
--- 272,278
TCPDEBUG
TCP_DROP_SYNFIN opt_tcp_input.h
XBONEHACK
+ NSopt_ns.h
# Netgraph(4). Use option NETGRAPH to enable the base netgraph code.
# Each netgraph node type can be either be compiled into the kernel
Index: idp_usrreq.c
===
RCS file: /usr/cvs/src/sys/netns/idp_usrreq.c,v
retrieving revision 1.9
diff -c -r1.9 idp_usrreq.c
*** idp_usrreq.c28 Aug 1999 00:49:47 - 1.9
--- idp_usrreq.c5 Mar 2003 01:15:42 -
***
*** 54,59
--- 54,63
#include
#include
+ extern int idpcksum; /* from ns_input.c */
+ extern long ns_pexseq;/* from ns_input.c */
+ extern struct nspcb nsrawpcb; /* from ns_input.c */
+
/*
* IDP protocol implementation.
*/
***
*** 63,68
--- 67,73
/*
* This may also be called for raw listeners.
*/
+ void
idp_input(m, nsp)
struct mbuf *m;
register struct nspcb *nsp;
***
*** 79,92
idp_ns.sns_addr = idp->idp_sna;
if (ns_neteqnn(idp->idp_sna.x_net, ns_zeronet) && ifp) {
register struct ifaddr *ifa;
! for (ifa = ifp->if_addrlist; ifa; ifa = ifa->ifa_next) {
if (ifa->ifa_addr->sa_family == AF_NS) {
idp_ns.sns_addr.x_net =
IA_SNS(ifa)->sns_addr.x_net;
break;
}
! }
}
nsp->nsp_rpt = idp->idp_pt;
if ( ! (nsp->nsp_flags & NSP_RAWIN) ) {
--- 84,99
idp_ns.sns_addr = idp->idp_sna;
if (ns_neteqnn(idp->idp_sna.x_net, ns_zeronet) && ifp) {
register struct ifaddr *ifa;
+ int s;
! s = splimp();
! TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link)
if (ifa->ifa_addr->sa_family == AF_NS) {
idp_ns.sns_addr.x_net =
IA_SNS(ifa)->sns_addr.x_net;
break;
}
! splx(s);
}
nsp->nsp_rpt = idp->idp_pt;
if ( ! (nsp->nsp_flags & NSP_RAWIN) ) {
***
*** 103,108
--- 110,116
m_freem(m);
}
+ void
idp_abort(nsp)
struct nspcb *nsp;
{
***
*** 134,153
so->so_error = errno;
ns_pcbdisconnect(nsp);
soisdisconnected(so);
}
int noIdpRoute;
idp_output(nsp, m0)
struct nspcb *nsp;
struct mbuf *m0;
{
! register struct mbuf *m;
register struct idp *idp;
register struct socket *so;
register int len = 0;
register struct route *ro;
! struct mbuf *mprev;
! extern int idpcksum;
/*
* Calculate data length.
--- 142,163
so->so_error = errno;
ns_pcbdisconn
Re: A few 5.0-Release questions...
John Wilson wrote: Good day, After spending quite some time trying to get 5.0-RELEASE installed on a Dell PowerEdge machine, it seems that all is now working quite well. Being that these machines are somewhat common, I'll share what was halting my installation. What model? There are quite a few PowerEdges out there. I installed 5.0 (actually, I built the official 5.0 release) on a PowerEdge. These machines come with integrated video, an ATI RageXL, which is rather useless for anything other than console mode. I installed an ATI All- In-Wonder VE so that I could get somewhat decent performance out of X. The problem manifested when the kernel probed the machines hardware, causing an "NMI ISA 30, EISA ff", and locking up the machine solid. After I began pulling memory and expansion cards from the system, the error went away when I removed the ATI AIW card. I reinstalled the card and attempted to find how to correct this. My only solution to this issue was to interrupt the boot process and use the following command: set hw.pci.enable_io_modes = 0 This prevented any further halts. As a wild guess, what happenes when you remove the EISA device from the kernel? My first question is as follows: is /boot/device.hints the most proper place to stick this? Also, are there any other possible solutions to this issue? /boot/loader.conf is the best place for this. My main drives are SCSI, and I have one CD-RW and one DVD-R on the secondary IDE controller. The kernel detects the drives just fine, but defaults them both down to PIO4. The drives are fully UDMA2 capable. I am able to set the drives to use UDMA2 via atacontrol without issue. However, how would one make this more permanent, such that I wouldn't have to use atacontrol everytime I boot the machine? There have been problems in the past with ATAPI/IDE drives that claim DMA capabilities but instead corrupt data and/or cause panics. Forcing everything to PIO is the easiest way to achieve maximum compatibility. The ata manual page describes what to put into /boot/loader.conf to force them back using DMA. Back to the topic of video; is there _any_ way to permanently disable, or at least prevent FreeBSD from detecting the integrated video on the motherboard? There is nothing in the machines BIOS that would allow this. This would just be "nice" to do, as X works just fine, but it still sticks an entry into the XFree86Config file for the integrated chip. Does the motherboard have a jumper that will disable it? And finally... Where can one obtain a complete list of allowed hints for use in /boot/device.hints? I tried searching around the FBSD site as well as the handbook and found no listing, other than a line here and a line there. This has been desired for a long time, yes. There have been periodic pushes to do this, but they quickly loose steam or become outdated. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: ATA MODE_SENSE_BIG timeout
> For those want to fix ATA code, I have another problem
> with CURRENT. I have a Tyan Tiger 230T which is based
> on VIA Apollo 133T, south bridge is VIA 686B.
> On second IDE, I have a Mitsubishi 52X cdrom as master,
> and a Sony 16X CD R/W as slave, when startup, kernel
> is always stuck at "MODE_SENSE_BIG timeout".
> I fortunately catched the dmesg text since ATA code past the
> probing stage. In most case, it will be stuck there forever.
> BTW, both Linux (2.2.14, Redhat) and MS Windows can probe
> these devices in few seconds without any problem.
>
I had more than a few machines behaved this way. I believe
the problem is with the probe and attach sequence of our
ata driver. After an ATA reset, according to spec, an ATAPI
device is supposed to present the ATAPI signature and deassert
the ready bit, until it receives its first packet command.
However when the ata driver issues the first mode sense command,
it polls first for the ready bit which never becomes set and
the operation times out. The most obviously solution is
sending the first command without checking for the ready bit.
My solution is a little different, but works equally well,
instead I issue an ATAPI reset (what now called a device reset?),
because I don't want to write another or alter the current
ata_command function and we need an atapi_reset function anyway.
According spec, atapi devices SHOULD ONLY be reset via the
atapi reset command (our ata driver doesn't follow this rule).
The patch is for -stable. I hope it's not too difficult to port
to -current.
-lq
Index: atapi-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-all.c,v
retrieving revision 1.46.2.18
diff -u -r1.46.2.18 atapi-all.c
--- atapi-all.c 31 Oct 2002 23:10:33 - 1.46.2.18
+++ atapi-all.c 19 Dec 2002 19:59:20 -
@@ -48,6 +48,7 @@
#include
/* prototypes */
+static void atapi_reset(struct ata_device *);
static void atapi_read(struct atapi_request *, int);
static void atapi_write(struct atapi_request *, int);
static void atapi_finish(struct atapi_request *);
@@ -77,6 +78,7 @@
ata_umode(atadev->param), atadev->param->support_dma);
ATA_SLEEPLOCK_CH(atadev->channel, ATA_CONTROL);
+atapi_reset(atadev);
if (atapi_dma && !(atadev->param->drq_type == ATAPI_DRQT_INTR)) {
ata_dmainit(atadev->channel, atadev->unit,
(ata_pmode(atadev->param) < 0) ?
@@ -483,6 +485,8 @@
void
atapi_reinit(struct ata_device *atadev)
{
+atapi_reset(atadev);
+
/* reinit device parameters */
if (atadev->mode >= ATA_DMA)
ata_dmainit(atadev->channel, atadev->unit,
@@ -536,6 +540,43 @@
}
static void
+atapi_reset(struct ata_device *atadev)
+{
+struct ata_channel *ch = atadev->channel;
+u_int8_t stat, lsb, msb;
+int timeout;
+
+ATA_OUTB(ch->r_io, ATA_DRIVE, ATA_D_IBM | atadev->unit);
+DELAY(10);
+ATA_OUTB(ch->r_altio, ATA_ALTSTAT, ATA_A_4BIT | ATA_A_IDS);
+DELAY(10);
+ATA_OUTB(ch->r_io, ATA_DRIVE, ATA_D_IBM | atadev->unit);
+DELAY(10);
+ATA_OUTB(ch->r_io, ATA_CMD, ATA_C_ATAPI_RESET);
+
+for (timeout = 1; timeout; timeout--) {
+ DELAY(100);
+ ATA_OUTB(ch->r_io, ATA_DRIVE, ATA_D_IBM | atadev->unit);
+ DELAY(10);
+ lsb = ATA_INB(ch->r_io, ATA_CYL_LSB);
+ msb = ATA_INB(ch->r_io, ATA_CYL_MSB);
+ stat = ATA_INB(ch->r_io, ATA_STATUS);
+ if ((stat & ATA_S_BUSY) == 0)
+ break;
+}
+
+if (bootverbose)
+ ata_prtdev(atadev, "stat %x, lsb %x, msb %x\n", stat, lsb, msb);
+
+if (timeout == 0)
+ ata_prtdev(atadev, "soft reset failed\n");
+
+ATA_OUTB(ch->r_io, ATA_DRIVE, ATA_D_IBM | atadev->unit);
+DELAY(10);
+ATA_OUTB(ch->r_altio, ATA_ALTSTAT, ATA_A_4BIT);
+}
+
+static void
atapi_read(struct atapi_request *request, int length)
{
int8_t **buffer = (int8_t **)&request->data;
@@ -617,10 +658,13 @@
{
struct ata_device *atadev = request->device;
+ATA_FORCELOCK_CH(atadev->channel, ATA_CONTROL);
atadev->channel->running = NULL;
ata_prtdev(atadev, "%s command timeout - resetting\n",
atapi_cmd2str(request->ccb[0]));
+atapi_reset(atadev);
+
if (request->flags & ATPR_F_DMA_USED) {
ata_dmadone(atadev->channel);
if (request->retries == ATAPI_MAX_RETRIES) {
@@ -631,17 +675,20 @@
request->retries = 0;
}
}
+ATA_UNLOCK_CH(atadev->channel);
/* if retries still permit, reinject this request */
if (request->retries++ < ATAPI_MAX_RETRIES) {
+ int s = splbio();
TAILQ_INSERT_HEAD(&atadev->channel->atapi_queue, request, chain);
+ ata_start(atadev->channel);
+ splx(s);
}
else {
/* retries all used up, return error */
request->error = EIO;
wakeup((caddr_t)request);
}
-ata_reinit(atadev->channel);
}
static char *
To Unsubscribe: send mail to [EMAIL PROT
Re: Removal of netns
I have at least 1 VPN setup that requires full IPX support. On Tuesday 04 March 2003 15:32, Chris Fowler wrote: > What is IPX currently being used for? Legacy systems? > > I've been stuck in TCP/IP land for many years now. Have been lucky > enough to not run into any IPX. > > On Tue, 2003-03-04 at 18:26, Tim Robbins wrote: > > On Tue, Mar 04, 2003 at 02:53:56PM -0800, Julian Elischer wrote: > > > I thought nwfs used it? > > > > nwfs uses netipx. From what I can tell, netipx was based on netns. > > > > > > Tim > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
On Tue, Mar 04, 2003 at 01:35:51PM -0800, Terry Lambert wrote: > Things being removed constantly. > > If you will remember, there has been a rocky history with the > removal of functionality in FreeBSD. If you don't remember, > I will be happy to remind you of specific incidents that ended > up causing a lot of grief, most of which I was not involved in, > but merely watched from the sidelines. I'm hard-pressed to think of any change to FreeBSD that you have not involved yourself in ;-) Kris pgp0.pgp Description: PGP signature
Re: mbuf cache
Hiten Pandya (Tue, Mar 04, 2003 at 07:01:15PM -0500) wrote:
> Petri Helenius (Wed, Mar 05, 2003 at 01:42:05AM +0200) wrote:
> > >
> > > This does look odd... maybe there's a leak somewhere... does "in use"
> > > go back down to a much lower number eventually? What kind of test are
> > > you running? "in pool" means that that's the number in the cache
> > > while "in use" means that that's the number out of the cache
> > > currently being used by the system; but if you're telling me that
> > > there's no way usage could be that high while you ran the netstat,
> > > either there's a serious leak somewhere or I got the stats wrong
> > > (anyone else notice irregular stats?)
> > >
> > I think I figured this, the "em" driver is allocating mbuf for each receive
> > descriptor regardless if it?s needed or not. Does this cause a performance
> > issue if there is 8000 mbufs in use and we get 100k-150k frees and
> > allocates a second (for every packet?)
> >
> > (I have the em driver configured for 4096 receive descriptors)
>
> While you are there debugging mbuf issues, you might also want to try
> this patch:
>
Oops, my first patch had some bugs because of quick editing. Please try
the newer patch:
http://www.unixdaemons.com/~hiten/work/mbuf/if_em.c.patch
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
Index: sys/dev/em/if_em.c
===
RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.19
diff -u -r1.19 if_em.c
--- sys/dev/em/if_em.c 19 Feb 2003 05:47:03 - 1.19
+++ sys/dev/em/if_em.c 5 Mar 2003 00:17:05 -
@@ -1802,17 +1802,11 @@
ifp = &adapter->interface_data.ac_if;
if (mp == NULL) {
- MGETHDR(mp, M_DONTWAIT, MT_DATA);
+ mp = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR);
if (mp == NULL) {
adapter->mbuf_alloc_failed++;
return(ENOBUFS);
}
- MCLGET(mp, M_DONTWAIT);
- if ((mp->m_flags & M_EXT) == 0) {
- m_freem(mp);
- adapter->mbuf_cluster_failed++;
- return(ENOBUFS);
- }
mp->m_len = mp->m_pkthdr.len = MCLBYTES;
} else {
mp->m_len = mp->m_pkthdr.len = MCLBYTES;
@@ -2410,8 +2404,6 @@
adapter->no_tx_desc_avail2);
printf("em%d: Std Mbuf Failed = %ld\n",unit,
adapter->mbuf_alloc_failed);
- printf("em%d: Std Cluster Failed = %ld\n",unit,
- adapter->mbuf_cluster_failed);
printf("em%d: Symbol errors = %lld\n", unit,
(long long)adapter->stats.symerrs);
Index: sys/dev/em/if_em.h
===
RCS file: /home/ncvs/src/sys/dev/em/if_em.h,v
retrieving revision 1.12
diff -u -r1.12 if_em.h
--- sys/dev/em/if_em.h 23 Dec 2002 19:11:23 - 1.12
+++ sys/dev/em/if_em.h 5 Mar 2003 00:20:57 -
@@ -366,7 +366,6 @@
/* Misc stats maintained by the driver */
unsigned long dropped_pkts;
unsigned long mbuf_alloc_failed;
- unsigned long mbuf_cluster_failed;
unsigned long no_tx_desc_avail1;
unsigned long no_tx_desc_avail2;
#ifdef DBG_STATS
Re: mbuf cache
On Wed, Mar 05, 2003 at 01:42:05AM +0200, Petri Helenius wrote:
> >
> > This does look odd... maybe there's a leak somewhere... does "in use"
> > go back down to a much lower number eventually? What kind of test are
> > you running? "in pool" means that that's the number in the cache
> > while "in use" means that that's the number out of the cache
> > currently being used by the system; but if you're telling me that
> > there's no way usage could be that high while you ran the netstat,
> > either there's a serious leak somewhere or I got the stats wrong
> > (anyone else notice irregular stats?)
> >
> I think I figured this, the "em" driver is allocating mbuf for each receive
> descriptor regardless if it´s needed or not. Does this cause a performance
> issue if there is 8000 mbufs in use and we get 100k-150k frees and
> allocates a second (for every packet?)
>
> (I have the em driver configured for 4096 receive descriptors)
Yeah, it kinda sucks but I'm not sure how it works... when are the
mbufs freed? If they're all freed in a continous for loop that kinda
sucks.
> > Another thing I find odd about those stats is that you've set the high
> > watermark to 8192, which means that in the next free, you should be
> > moving buckets to the general cache... see if that's really
> > happening... The low watermark doesn't affect anything right now.
>
> Nothing seems to be moving to the GEN pool.
Lower the high watermark to like 512... wait for the next free... if
it's still not moving, but you see that the per-cpu caches are being
used ("in use" is changing), please let me know ASAP.
> > Can you give me more details on the exact type of test you're running?
> > Let's move this to -current instead of -current and -net please (feel
> > free to trim the one you want), getting 3 copies of the same
> > message all the time is kinda annoying. :-(
> >
> I´m running a snort-like application with the interface getting receive only
> packets. It can either connect to a netgraph node or use bpf, both seem to have
> similar performance (most CPU is used elsewhere) as the email I sent previously
> had listed.
>
> Pete
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns - politically correct version
* De: Mark Linimon <[EMAIL PROTECTED]> [ Data: 2003-03-04 ] [ Subjecte: Re: Removal of netns - politically correct version ] > On Tue, 4 Mar 2003, Terry Lambert wrote: > > Tell you what, I'll fix these and post a patch. Will that make you > > guys happy? > > Yes, as will anything else that cuts down on the metadiscussions and > increases the quality of the codebase. No, it screws up the quality of the codebase if it cannot be tested and used every day, and I doubt Terry will be doing real testing. HOWEVER, I am willing to keep netns working if someone can provide a pure XNS with IP-over-XNS provider. Playing around using multiple FreeBSD boxen with a possibly broken but interoperable implementation is also out of the question, as nobody uses it. For things that people actually use, it's OK as prototyping fixes and getting them in tree, and then the users can find where it's broken later. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
Petri Helenius (Wed, Mar 05, 2003 at 01:42:05AM +0200) wrote:
> >
> > This does look odd... maybe there's a leak somewhere... does "in use"
> > go back down to a much lower number eventually? What kind of test are
> > you running? "in pool" means that that's the number in the cache
> > while "in use" means that that's the number out of the cache
> > currently being used by the system; but if you're telling me that
> > there's no way usage could be that high while you ran the netstat,
> > either there's a serious leak somewhere or I got the stats wrong
> > (anyone else notice irregular stats?)
> >
> I think I figured this, the "em" driver is allocating mbuf for each receive
> descriptor regardless if it?s needed or not. Does this cause a performance
> issue if there is 8000 mbufs in use and we get 100k-150k frees and
> allocates a second (for every packet?)
>
> (I have the em driver configured for 4096 receive descriptors)
While you are there debugging mbuf issues, you might also want to try
this patch:
%%%
Index: sys/dev/em/if_em.c
===
RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.19
diff -u -r1.19 if_em.c
--- sys/dev/em/if_em.c 19 Feb 2003 05:47:03 - 1.19
+++ sys/dev/em/if_em.c 4 Mar 2003 23:49:02 -
@@ -1802,15 +1802,10 @@
ifp = &adapter->interface_data.ac_if;
if (mp == NULL) {
- MGETHDR(mp, M_DONTWAIT, MT_DATA);
+ mp = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR);
if (mp == NULL) {
adapter->mbuf_alloc_failed++;
- return(ENOBUFS);
- }
- MCLGET(mp, M_DONTWAIT);
- if ((mp->m_flags & M_EXT) == 0) {
m_freem(mp);
- adapter->mbuf_cluster_failed++;
return(ENOBUFS);
}
mp->m_len = mp->m_pkthdr.len = MCLBYTES;
%%%
This is sort of an optimization. It reduces locking operations, and
will be making calling less routnes overall. It would be beneficial to
know the profiling and performance results of this patch.
> I?m running a snort-like application with the interface getting receive only
> packets. It can either connect to a netgraph node or use bpf, both seem to have
> similar performance (most CPU is used elsewhere) as the email I sent previously
> had listed.
This code from 'em' driver worries me a bit:
if (em_get_buf(i, adapter, NULL) == ENOBUFS) {
adapter->dropped_pkts++;
em_get_buf(i, adapter, mp);
if (adapter->fmp != NULL)
m_freem(adapter->fmp);
adapter->fmp = NULL;
adapter->fmp = NULL;
}
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns - politically correct version
On Tue, 4 Mar 2003, Terry Lambert wrote: > Tell you what, I'll fix these and post a patch. Will that make you > guys happy? Yes, as will anything else that cuts down on the metadiscussions and increases the quality of the codebase. mcl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Tiny BSD Pages
I do one thing in Linux that I want to do in FreeBSD. I store my root file system as a blow fish, gzipped, encrypted file on a DiskOnChip. When the Linux kernel boots it loads an initial ramdisk that will open this file, uncompress, and decrypt. I will then write the good data to a ram disk. Upon completion, it will terminate itself and the Linux kernel will now mount /dev/ram7 as its root fs. I do much more in my loader. I allow flashing of that file, I allow an alternate method of getting the same file. It can be on a tftp server or in a URL like http://192.168.2.1/sw/sw-package. But that is in the details. I would like to do the exact same thing with FreeBSD but I can not find any leads on this type of configuration. Any pointers? Thanks, chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns - politically correct version
* De: Terry Lambert <[EMAIL PROTECTED]> [ Data: 2003-03-04 ] [ Subjecte: Re: Removal of netns - politically correct version ] > Peter Wemm wrote: > > Terry Lambert wrote: > > > Is there a compelling reason for removing this working code to > > > the Attic? > > > > Terry: will you please check your facts? It takes around 30 seconds > > to find out that it doesn't even compile. > > [ ... lots of trivial to fix warnings and errors ... ] > > > Tell you what, I'll fix these and post a patch. Will that make you > guys happy? > > This crap is *s* trivial to fix, it's easier to fix than > to watch you guys bitch about it not being fixable. Terry, watch your language. And then find me a site running XNS that expects to be running a current version of FreeBSD, or ideally someone I could peer an XNS system with if I were to take up maintainership of it? You have until the code is gone from CVS, which hopefully will be very soon. Thanx, juli. PS: I might be interested in getting it out of the attic if you could find me a good place for XNS-only connectivity, with IP-over-XNS of some sort so I could still IRC. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns - politically correct version
Peter Wemm wrote: > Terry Lambert wrote: > > Is there a compelling reason for removing this working code to > > the Attic? > > Terry: will you please check your facts? It takes around 30 seconds > to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? This crap is *s* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Witness problem with sound
I don't know how system-specific this problem is, but: Sony VAIO R505ES Sound is Intel ICH3 + Yamaha. This or something closely related has been happening for weeks. Several times earlier this week and last week sound panic'd, and also sometimes there was a panic (several different kinds) on boot. Late last week X wouldn't start due to not being able to see the VESA modes. All those except the sound problems currently appear fixed... This may or may not be related to the fact that acpi puts nearly all device interrupts on irq 9 (which causes other problems). Problem: .. Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:748 Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:748 Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:748 Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:696 Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:696 Mar 4 14:56:27 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:696 Mar 4 14:56:28 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:696 Mar 4 14:56:28 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:696 Mar 4 14:56:28 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:696 Mar 4 14:56:28 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:673 Mar 4 14:56:28 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:673 Mar 4 14:56:28 port2 kernel: /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/dsp.c:673 . (repeated by the thousands, at various lines, the above plus sound.c:191 . Sound comes out but is chopped up, as if interrupt service was not reliable. Dmesg: Copyright (c) 1992-2003 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 5.0-CURRENT #34: Tue Mar 4 11:36:51 PST 2003 [EMAIL PROTECTED]:/d/obj-c/usr/src/sys/PORT2 Preloaded elf kernel "/boot/kernel/kernel" at 0xc053f000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc053f0a8. Calibrating clock(s) ... i8254 clock: 1193201 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz Calibrating TSC clock ... TSC clock: 1193108506 Hz Timecounter "TSC" frequency 1193108506 Hz CPU: Intel(R) Pentium(R) III Mobile CPU 1200MHz (1193.11-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383f9ff real memory = 535298048 (510 MB) Physical memory chunk(s): 0x1000 - 0x0009dfff, 643072 bytes (157 pages) 0x00566000 - 0x1fce, 527998976 bytes (128906 pages) 0x1fd0 - 0x1fe77fff, 1540096 bytes (376 pages) avail memory = 514080768 (490 MB) bios32: Found BIOS32 Service Directory header at 0xc00f6bb0 bios32: Entry = 0xfd871 (c00fd871) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd870+0x13a pnpbios: Found PnP BIOS data at 0xc00f6be0 pnpbios: Entry = f:8816 Rev = 1.0 Other BIOS signatures found: Allocating major#253 to "net" wlan: <802.11 Link Layer> null: Allocating major#252 to "pci" random: mem: Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 pci_open(1):mode 1 addr port (0x0cf8) is 0x8000f904 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=35758086) pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00fdf30 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded25A 0x69 3 embedded28A 0x68 9 embedded0 29A 0x60 9 embedded0 29B 0x63 9 embedded02A 0x60 9 embedded01A 0x60 9 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width
Re: mbuf cache
> > This does look odd... maybe there's a leak somewhere... does "in use" > go back down to a much lower number eventually? What kind of test are > you running? "in pool" means that that's the number in the cache > while "in use" means that that's the number out of the cache > currently being used by the system; but if you're telling me that > there's no way usage could be that high while you ran the netstat, > either there's a serious leak somewhere or I got the stats wrong > (anyone else notice irregular stats?) > I think I figured this, the "em" driver is allocating mbuf for each receive descriptor regardless if it´s needed or not. Does this cause a performance issue if there is 8000 mbufs in use and we get 100k-150k frees and allocates a second (for every packet?) (I have the em driver configured for 4096 receive descriptors) > Another thing I find odd about those stats is that you've set the high > watermark to 8192, which means that in the next free, you should be > moving buckets to the general cache... see if that's really > happening... The low watermark doesn't affect anything right now. Nothing seems to be moving to the GEN pool. > > Can you give me more details on the exact type of test you're running? > Let's move this to -current instead of -current and -net please (feel > free to trim the one you want), getting 3 copies of the same > message all the time is kinda annoying. :-( > I´m running a snort-like application with the interface getting receive only packets. It can either connect to a netgraph node or use bpf, both seem to have similar performance (most CPU is used elsewhere) as the email I sent previously had listed. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
What is IPX currently being used for? Legacy systems? I've been stuck in TCP/IP land for many years now. Have been lucky enough to not run into any IPX. On Tue, 2003-03-04 at 18:26, Tim Robbins wrote: > On Tue, Mar 04, 2003 at 02:53:56PM -0800, Julian Elischer wrote: > > > I thought nwfs used it? > > nwfs uses netipx. From what I can tell, netipx was based on netns. > > > Tim > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
On Tue, Mar 04, 2003 at 02:53:56PM -0800, Julian Elischer wrote: > I thought nwfs used it? nwfs uses netipx. From what I can tell, netipx was based on netns. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
On Wed, Mar 05, 2003 at 01:12:55AM +0200, Petri Helenius wrote: > > > Any comments on the high cpu consumption of mb_free? Or any other places > > > where I should look to improve performance? > > > > What do you mean "high cpu consumption?" The common case of mb_free() > > is this: > > According to profiling mb_free takes 18.9% of all time consumed in kernel and is > almost double to next cpu consuming function. Since I´m looking how to optimize > the system, it´s usually a good idea to start looking where most CPU is spent. > > For example, I´m wondering if mbufs get unneccessarily freed and allocated or thrown > around different buckets because of the tunables are wrong. I´m not saying that > there must be something wrong with the code itself. > > For example what does "in use" mean below: There is no way there is enough > traffic on the system to allocate 7075 mbufs when this netstat -m was taken. > > mbuf usage: > GEN cache: 0/0 (in use/in pool) > CPU #0 cache: 7075/8896 (in use/in pool) > CPU #1 cache: 1119/4864 (in use/in pool) > Total: 8194/13760 (in use/in pool) > Mbuf cache high watermark: 8192 > Mbuf cache low watermark: 128 > > > Pete This does look odd... maybe there's a leak somewhere... does "in use" go back down to a much lower number eventually? What kind of test are you running? "in pool" means that that's the number in the cache while "in use" means that that's the number out of the cache currently being used by the system; but if you're telling me that there's no way usage could be that high while you ran the netstat, either there's a serious leak somewhere or I got the stats wrong (anyone else notice irregular stats?) Another thing I find odd about those stats is that you've set the high watermark to 8192, which means that in the next free, you should be moving buckets to the general cache... see if that's really happening... The low watermark doesn't affect anything right now. Can you give me more details on the exact type of test you're running? Let's move this to -current instead of -current and -net please (feel free to trim the one you want), getting 3 copies of the same message all the time is kinda annoying. :-( -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
Julian Elischer (Tue, Mar 04, 2003 at 02:53:56PM -0800) wrote: > I thought nwfs used it? > > > On Wed, 5 Mar 2003, Tim Robbins wrote: > > > Is there a compelling reason why I shouldn't remove netns? That is, does > > it serve a purpose now that it could not serve if it was moved to the > > Attic? That's netncp if I am not mistaken and thanks to Tim and Max Khon, it's now fixed, IIRC. Kudos to them. :-) -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
> > Any comments on the high cpu consumption of mb_free? Or any other places
> > where I should look to improve performance?
>
> What do you mean "high cpu consumption?" The common case of mb_free()
> is this:
According to profiling mb_free takes 18.9% of all time consumed in kernel and is
almost double to next cpu consuming function. Since I´m looking how to optimize
the system, it´s usually a good idea to start looking where most CPU is spent.
For example, I´m wondering if mbufs get unneccessarily freed and allocated or thrown
around different buckets because of the tunables are wrong. I´m not saying that
there must be something wrong with the code itself.
For example what does "in use" mean below: There is no way there is enough
traffic on the system to allocate 7075 mbufs when this netstat -m was taken.
mbuf usage:
GEN cache: 0/0 (in use/in pool)
CPU #0 cache: 7075/8896 (in use/in pool)
CPU #1 cache: 1119/4864 (in use/in pool)
Total: 8194/13760 (in use/in pool)
Mbuf cache high watermark: 8192
Mbuf cache low watermark: 128
Pete
>
> bucket = mb_list->ml_btable[MB_BUCKET_INDX(m, mb_list)];
> owner = bucket->mb_owner & ~MB_BUCKET_FREE;
> switch (owner) {
> ...
> default:
> cnt_lst = MB_GET_PCPU_LIST_NUM(mb_list, owner);
> MB_PUT_OBJECT(m, bucket, cnt_lst);
> MB_MBTYPES_DEC(cnt_lst, type, 1);
> if (bucket->mb_owner & MB_BUCKET_FREE) {
> SLIST_INSERT_HEAD(&(cnt_lst->mb_cont.mc_bhead),
> bucket,
> mb_blist);
>bucket->mb_owner = cnt_lst->mb_cont.mc_numowner;
> }
> }
>
> That's the common path, modulo a couple checks on whether or not the
> container being freed to needs to be moved or whether we're in a
> starvation situation. The only thing to be done, possibly, is make
> the routine smaller by moving those couple of actions to seperate
> routines, but I'm not clear that this is very useful, given that
> mb_free()'s usage is restricted to only inside subr_mbuf.c
>
> > Pete
>
> --
> Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
A few 5.0-Release questions...
Good day, After spending quite some time trying to get 5.0-RELEASE installed on a Dell PowerEdge machine, it seems that all is now working quite well. Being that these machines are somewhat common, I'll share what was halting my installation. These machines come with integrated video, an ATI RageXL, which is rather useless for anything other than console mode. I installed an ATI All- In-Wonder VE so that I could get somewhat decent performance out of X. The problem manifested when the kernel probed the machines hardware, causing an "NMI ISA 30, EISA ff", and locking up the machine solid. After I began pulling memory and expansion cards from the system, the error went away when I removed the ATI AIW card. I reinstalled the card and attempted to find how to correct this. My only solution to this issue was to interrupt the boot process and use the following command: set hw.pci.enable_io_modes = 0 This prevented any further halts. My first question is as follows: is /boot/device.hints the most proper place to stick this? Also, are there any other possible solutions to this issue? My main drives are SCSI, and I have one CD-RW and one DVD-R on the secondary IDE controller. The kernel detects the drives just fine, but defaults them both down to PIO4. The drives are fully UDMA2 capable. I am able to set the drives to use UDMA2 via atacontrol without issue. However, how would one make this more permanent, such that I wouldn't have to use atacontrol everytime I boot the machine? Back to the topic of video; is there _any_ way to permanently disable, or at least prevent FreeBSD from detecting the integrated video on the motherboard? There is nothing in the machines BIOS that would allow this. This would just be "nice" to do, as X works just fine, but it still sticks an entry into the XFree86Config file for the integrated chip. And finally... Where can one obtain a complete list of allowed hints for use in /boot/device.hints? I tried searching around the FBSD site as well as the handbook and found no listing, other than a line here and a line there. Thank you all very much for your help, and have a wonderful day. - John Wilson [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
I thought nwfs used it? On Wed, 5 Mar 2003, Tim Robbins wrote: > Is there a compelling reason why I shouldn't remove netns? That is, does > it serve a purpose now that it could not serve if it was moved to the > Attic? > > > Tim > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
On Wed, Mar 05, 2003 at 12:24:27AM +0200, Petri Helenius wrote:
> >
> > Yes, it's normal. The commit log clearly states that the new
> > watermarks do nothing for now. I have a patch that changes that but I
> > haven't committed it yet because I left for vacation last Sunday and I
> > only returned early this Monday. Since then, I've been too busy to
> > clean up and commit it. In about a week or so you should notice a
> > difference.
> >
> Any comments on the high cpu consumption of mb_free? Or any other places
> where I should look to improve performance?
What do you mean "high cpu consumption?" The common case of mb_free()
is this:
bucket = mb_list->ml_btable[MB_BUCKET_INDX(m, mb_list)];
owner = bucket->mb_owner & ~MB_BUCKET_FREE;
switch (owner) {
...
default:
cnt_lst = MB_GET_PCPU_LIST_NUM(mb_list, owner);
MB_PUT_OBJECT(m, bucket, cnt_lst);
MB_MBTYPES_DEC(cnt_lst, type, 1);
if (bucket->mb_owner & MB_BUCKET_FREE) {
SLIST_INSERT_HEAD(&(cnt_lst->mb_cont.mc_bhead),
bucket,
mb_blist);
bucket->mb_owner = cnt_lst->mb_cont.mc_numowner;
}
}
That's the common path, modulo a couple checks on whether or not the
container being freed to needs to be moved or whether we're in a
starvation situation. The only thing to be done, possibly, is make
the routine smaller by moving those couple of actions to seperate
routines, but I'm not clear that this is very useful, given that
mb_free()'s usage is restricted to only inside subr_mbuf.c
> Pete
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
> > Yes, it's normal. The commit log clearly states that the new > watermarks do nothing for now. I have a patch that changes that but I > haven't committed it yet because I left for vacation last Sunday and I > only returned early this Monday. Since then, I've been too busy to > clean up and commit it. In about a week or so you should notice a > difference. > Any comments on the high cpu consumption of mb_free? Or any other places where I should look to improve performance? Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
On Tue, Mar 04, 2003 at 11:34:11PM +0200, Petri Helenius wrote: > > I did some profiling on -CURRENT from a few days back, and I think I haven´t > figured the new tunables out or the code is not doing what it´s supposed to > or I´m asking more than it is supposed to do but it seems that mb_free > is being quite wasteful... > > Any pointers to how the new high/low watermark tunables should be used? > > Is it normal that after almost all traffic has been stopped there is still 8k+ > mbufs in "cache"? > > Pete Yes, it's normal. The commit log clearly states that the new watermarks do nothing for now. I have a patch that changes that but I haven't committed it yet because I left for vacation last Sunday and I only returned early this Monday. Since then, I've been too busy to clean up and commit it. In about a week or so you should notice a difference. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
Wilko Bulte wrote: > On Tue, Mar 04, 2003 at 07:56:27AM -0800, Terry Lambert wrote: > > Is there a compelling reason for doing this, other than "I > > want to make some API/locking change, but I don't want to > > have to keep this code working at the same time"? Maximizing > > Is there a compelling reason for you to moan about the removal > of things constantly? Things being removed constantly. If you will remember, there has been a rocky history with the removal of functionality in FreeBSD. If you don't remember, I will be happy to remind you of specific incidents that ended up causing a lot of grief, most of which I was not involved in, but merely watched from the sidelines. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mbuf cache
I did some profiling on -CURRENT from a few days back, and I think I haven´t figured the new tunables out or the code is not doing what it´s supposed to or I´m asking more than it is supposed to do but it seems that mb_free is being quite wasteful... Any pointers to how the new high/low watermark tunables should be used? Is it normal that after almost all traffic has been stopped there is still 8k+ mbufs in "cache"? Pete granularity: each sample hit covers 16 byte(s) for 0.00% of 708.90 seconds % cumulative self self total time seconds secondscalls ms/call ms/call name 18.9 134.04 134.04 778488459 0.00 0.00 mb_free [5] 10.0 204.9970.95 290131104 0.00 0.00 ether_input [8] 9.0 268.4663.47 __mcount [9] 6.3 313.4244.96 198223061 0.00 0.00 m_move_pkthdr [15] 5.1 349.6836.27 18238430 0.00 0.02 em_intr [2] 5.0 385.0935.41 778488459 0.00 0.00 mb_alloc [17] 4.8 418.8733.77 198510151 0.00 0.00 generic_bcopy [18] 4.5 450.6431.77 234113.5763.33 m_freem [4] 4.1 479.8129.17 967684 0.03 0.03 call_fast_unpend [20] 3.5 504.5324.72 17641942 0.00 0.01 em_process_receive_interru pts [3] 1.8 517.2612.73 m_pullup [6] 1.6 528.5111.25 290131104 0.00 0.00 em_get_buf [10] mbuf usage: GEN cache: 56/256 (in use/in pool) CPU #0 cache: 8138/12064 (in use/in pool) Total: 8194/12320 (in use/in pool) Mbuf cache high watermark: 4096 Mbuf cache low watermark: 128 Maximum possible: 51200 Allocated mbuf types: 8194 mbufs allocated to data 24% of mbuf map consumed mbuf cluster usage: GEN cache: 4/16 (in use/in pool) CPU #0 cache: 8188/12280 (in use/in pool) Total: 8192/12296 (in use/in pool) Cluster cache high watermark: 4096 Cluster cache low watermark: 16 Maximum possible: 25600 48% of cluster map consumed 27672 KBytes of wired memory reserved (66% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Amanda backups, or dump(8) broken?
On Tue, Mar 04, 2003 at 11:57:34AM -0800, Brooks Davis wrote: > I've seen reports that dump compatability was broken. I'm dumping two > 5.0 boxes and one 4-STABLE box to one of the 5.0 boxes and the amverify > I'm current running doesn't seem to have any problem. Thus, I'd tend to > suspect we need to fix restore in 4.x. What about non FreeBSD Amanda servers? Are they going to be able to verify a FreeBSD-CURRENT dump? Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: HEADS UP: cvsup cvs-supfile users!
Are all the official mirrors in the USA (cvsup1..17.freebsd.org) supposed to have the "cvsroot-all" package? I just tried cvsup16 and it doesn't have it. > -Original Message- > From: Peter Wemm [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 04, 2003 1:45 PM > To: Stijn Hoop > Cc: [EMAIL PROTECTED] > Subject: Re: HEADS UP: cvsup cvs-supfile users! > > > Stijn Hoop wrote: > > > On Tue, Mar 04, 2003 at 11:10:45AM -0800, Peter Wemm wrote: > > > Anybody who uses the cvs-supfile example to get the repository > > > should add "cvsroot-all" to their supfile. This is in > addition to > > > src-all, ports-al= > > l, > > > doc-all etc. > > >=20 > > > This is *ONLY* for the folks getting the CVS ,v files via > cvsup. If > > >you use tag=3D. or tag=3DRELENG_4, then you are not affected by > > >this. =20 I have updated cvs-supfile in -current but not RELENG_4 > > >yet. > > > > Just to be doubly sure, this goes for cvsup mirrors as > well, I assume? > > So I have to edit /usr/local/etc/cvsup/supfile to include > it? If so, > > then you might want to update > ports/net/cvsup-mirror/files/supfile a= > > lso. > > No, people who use cvs-all are already getting this stuff. > If you use the cvsup-mirror port yourself, you do not need to > change anything either. Mirrors who use cvs-all (official and > unofficial) do not need to change anything. > > Cheers, > -Peter > -- > Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] "All of this is for nothing if we don't > go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: cvsup cvs-supfile users!
On Tue, Mar 04, 2003 at 11:45:18AM -0800, Peter Wemm wrote: > No, people who use cvs-all are already getting this stuff. If you use > the cvsup-mirror port yourself, you do not need to change anything either. > Mirrors who use cvs-all (official and unofficial) do not need to change > anything. OK, thanks for the clarification. --Stijn -- "...I like logs. They give me a warm fuzzy feeling. I've been known to keep logs for 30 months at a time (generally when I thought I was rotating them daily, but was actually rotating them once a month)." -- Michael Lucas, in Big Scary Daemons article 'Controlling Bandwidth' pgp0.pgp Description: PGP signature
Re: Removal of netns
On Tue, 4 Mar 2003, Vincent Jardin wrote: > Why does it need to be removed ? According to me, it would be the same mistake > as the removal of netiso and netccitt. I did not know FreeBSD at this time, > but nowadays, in order to get an OS that supports many stacks, we have to use > NetBSD. If netns has so many users and our implementation has been broken for so long, why is it there hasn't been hordes of complaints? It appears as if users of netns are a rarity... > BSD4.4 was designed in order to support many stacks, FreeBSD 6, 7 ou 9 will > support only IPv4 and IPv6, won't they ? Today, widely-used networking applications use IPv4 and/or IPv6. It's understandable that as such, our IP stacks have gotten more testing and tuning than any other. If there's another networking protocol out there that has enough users interested and enough developer, vendor or device support, I don't see why it wouldn't be incorporated into the FreeBSD tree. A good example of a stack that was recently imported (comparatively speaking) would be Bluetooth. > I do not think that it needs to be removed. One should try to keep this > feature. As always, patches are welcome. If you happen to need netns for anything, scratch the itch... :-) Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Amanda backups, or dump(8) broken?
On Tue, Mar 04, 2003 at 07:31:27AM -0800, Will Andrews wrote: > Anyone know if maybe the dump format has been changed to the > extent that it breaks Amanda or something? In fact, based on the > "64+0" it appears that the header or something similar may have > been broken. I've seen reports that dump compatability was broken. I'm dumping two 5.0 boxes and one 4-STABLE box to one of the 5.0 boxes and the amverify I'm current running doesn't seem to have any problem. Thus, I'd tend to suspect we need to fix restore in 4.x. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: HEADS UP: cvsup cvs-supfile users!
Stijn Hoop wrote: > On Tue, Mar 04, 2003 at 11:10:45AM -0800, Peter Wemm wrote: > > Anybody who uses the cvs-supfile example to get the repository should add > > "cvsroot-all" to their supfile. This is in addition to src-all, ports-al= > l, > > doc-all etc. > >=20 > > This is *ONLY* for the folks getting the CVS ,v files via cvsup. If you > > use tag=3D. or tag=3DRELENG_4, then you are not affected by this. > >=20 > > I have updated cvs-supfile in -current but not RELENG_4 yet. > > Just to be doubly sure, this goes for cvsup mirrors as well, I assume? > So I have to edit /usr/local/etc/cvsup/supfile to include it? > If so, then you might want to update ports/net/cvsup-mirror/files/supfile a= > lso. No, people who use cvs-all are already getting this stuff. If you use the cvsup-mirror port yourself, you do not need to change anything either. Mirrors who use cvs-all (official and unofficial) do not need to change anything. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
"Poul-Henning Kamp" wrote: > In message <[EMAIL PROTECTED]>, Vincent Jardin writes: > > >Why does it need to be removed ? According to me, it would be the same mista ke > >as the removal of netiso and netccitt. I did not know FreeBSD at this time, > >but nowadays, in order to get an OS that supports many stacks, we have to us e > >NetBSD. > > > >BSD4.4 was designed in order to support many stacks, FreeBSD 6, 7 ou 9 will > >support only IPv4 and IPv6, won't they ? > > We will import and retain any protocol stack which has enough interested > users and committers to keep it alive. > > netiso and netccitt both fell for both of those criteria: neither users > nor committers. > > netns fails both criteria too. Yep. It was removed in 1996 as well, because it didn't work. One company (Netcon) objected and claimed that they needed it for their commercial product and that they'd send fixes. Now, 7 years later, not a single person has shown the slightest interest in fixing it. It may as well have been left in the Attic the whole time. revision 1.7 date: 1996/10/17 18:42:19; author: jkh; state: Exp; lines: +3 -1 branches: 1.7.2; Bring back netns so that Netcon can take over support for it, as agreed. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns - politically correct version
In message <[EMAIL PROTECTED]>, Peter Wemm writes: >Terry Lambert wrote: > >> Is there a compelling reason for removing this working code to >> the Attic? > >Terry: will you please check your facts? It takes around 30 seconds >to find out that it doesn't even compile. Could we possibly move Terry to the attic too ? Please ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA MODE_SENSE_BIG timeout
On 04-Mar-2003 Soeren Schmidt wrote: > It seems David Xu wrote: >> > (snip snap) >> > > acd1: read data overrun 34/0 >> > > acd1: MODE_SENSE_BIG command timeout - resetting >> > > ata1: resetting devices .. >> > > done >> > > acd1: CD-RW at ata1-slave PIO4 >> > >> > Hmm, can you use the acd1 device normally or does it fail (how) ? >> > >> > -Søren >> > >> It is very rare that the CD-RW will be found now, kernel is always >> stuck there, so I must pull the device off or disable Second IDE in BIOS, >> I can not use it. > > OK, from the above it looked like it was found after the retries.. > I'll try to reproduce the problem here, but so far no luck at that.. I've seen this same problem trying to install 4.7 on a box with a 52x drive. I don't have that drive around anymore and I'm not sure if it was the same make/model. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Possible patch for limiting APs at startup
On 04-Mar-2003 Hiten Pandya wrote: > John Baldwin (Mon, Mar 03, 2003 at 02:49:21PM -0500) wrote: >> >> On 02-Mar-2003 Juli Mallett wrote: >> > * De: Hiten Pandya <[EMAIL PROTECTED]> [ Data: 2003-03-01 ] >> > [ Subjecte: Possible patch for limiting APs at startup ] >> >> Hello. >> >> >> >> Just as the topic says, do you think this patch is good enough, or gets >> >> even close to it? I have tested the patch, and it seems to do it's job >> >> in the right way. Some might call it hackery, but it's better than >> >> nothing I would suppose. >> > >> > I think your use of "cpus" to refer to APs only is silly, and also that >> > overriding mp_naps instead of using a real cpus value and using it as >> > a bounds check akin to MAXCPU, is a bit of the wrong direction. As you >> > know, the following is my patch, and it does not work, but I think, >> > personally, the behaviour is saner, in theory at least :) >> >> You should set mp_maxcpus prior to the mp_naps test so it isn't left >> invalid in the common case. Also, this patch doesn't limit HT cpu's >> at all. I could have a 4 cpu system with HTT and maxcpus=2, and I >> will end up with 4 CPU's due to 2 logical CPU's per processor. Perhaps >> this is intentional? > > Yes. It was intentional, in the sense that we only want to limit the > number of Application Processors, and not the HTT cores inside it, > because that does not make much sense, IMHO. > > Do you think that patch will be committed, or does it need improving? > (http://www.unixdaemons.com/~hiten/work/diffs/mp_machdep.c.patch) Juli's patch is much closer. Setting mp_naps directly is bogus at best. mp_naps would get reset by the mptable stuff anyways since SI_SUB_CPU is well after SI_SUB_TUNABLES. Ignoring HTT is fine. All I would really do is change juli's patch to set the max value before the if test so it is always valid. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert wrote: > Is there a compelling reason for removing this working code to > the Attic? Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. In file included from ../../../netns/idp_usrreq.c:51: ../../../netns/ns_pcb.h:82: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c:67: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:67: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_input': ../../../netns/idp_usrreq.c:83: incompatible types in assignment ../../../netns/idp_usrreq.c:83: structure has no member named `ifa_next' ../../../netns/idp_usrreq.c:101: warning: `return' with no value, in function returning non-void ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:107: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:107: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_abort': ../../../netns/idp_usrreq.c:111: warning: implicit declaration of function `ns_pcbdisconnect' ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:120: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c:141: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:141: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_output': ../../../netns/idp_usrreq.c:150: warning: nested extern declaration of `idpcksum' ../../../netns/idp_usrreq.c:184: warning: address of register variable `m' requested ../../../netns/idp_usrreq.c:200: too many arguments to function `ns_cksum' ../../../netns/idp_usrreq.c:209: warning: implicit declaration of function `ns_output' ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:258: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:258: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_ctloutput': ../../../netns/idp_usrreq.c:266: warning: nested extern declaration of `ns_pexseq' ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:369: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:369: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_usrreq': ../../../netns/idp_usrreq.c:377: warning: implicit declaration of function `ns_control' ../../../netns/idp_usrreq.c:394: warning: implicit declaration of function `ns_pcballoc' ../../../netns/idp_usrreq.c:407: warning: implicit declaration of function `ns_pcbdetach' ../../../netns/idp_usrreq.c:411: warning: implicit declaration of function `ns_pcbbind' ../../../netns/idp_usrreq.c:423: warning: implicit declaration of function `ns_pcbconnect' ../../../netns/idp_usrreq.c:493: warning: implicit declaration of function `ns_setsockaddr' ../../../netns/idp_usrreq.c:497: warning: implicit declaration of function `ns_setpeeraddr' ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:531: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:531: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_raw_usrreq': ../../../netns/idp_usrreq.c:537: warning: nested extern declaration of `nsrawpcb' ../../../netns/idp_usrreq.c:543: `SS_PRIV' undeclared (first use in this function) ../../../netns/idp_usrreq.c:543: (Each undeclared identifier is reported only once ../../../netns/idp_usrreq.c:543: for each function it appears in.) In file included from ../../../netns/ns.c:40: ../../../sys/ioctl.h:47:2: #warning "Don't #include ioctl.h in the kernel. Include xxxio.h instead." In file included from ../../../netns/ns_error.c:49: ../../../netns/ns_pcb.h:82: warning: function declaration isn't a prototype ../../../netns/ns_error.c:66: warning: return type defaults to `int' ../../../netns/ns_error.c:66: warning: function declaration isn't a prototype ../../../netns/ns_error.c:91: warning: return type defaults to `int' ../../../netns/ns_error.c:91: warning: function declaration isn't a prototype ../../../netns/ns_error.c: In function `ns_error': ../../../netns/ns_error.c:98: warning: nested extern declaration of `idpcksum' ../../../netns/ns_error.c:107: warning: implicit declaration of function `ns_echo' ../../../netns/ns_error.c:108: warning: `return' with no value, in function returning non-void ../../../netns/ns_error.c:159: too many arguments to function `ns_cksum' ../../../netns/ns_error.c:162: warning: implicit declaration of function `ns_output' ../../../netns/ns_error.c: At top level: ../../../netns/ns_error.c:169: warning: return type defaults to `int' ../../../netns/ns_error.c:169: warning: function declaration isn't a prototype ../../../netns/ns_error.c:186: warning: return type defaults to `int' ../../../netns/ns_error.c:186: warning: function declaration isn't a prototype ../../../netns/ns_error.c: In function
Re: Removal of netns
In message <[EMAIL PROTECTED]>, Vincent Jardin writes: >Why does it need to be removed ? According to me, it would be the same mistake >as the removal of netiso and netccitt. I did not know FreeBSD at this time, >but nowadays, in order to get an OS that supports many stacks, we have to use >NetBSD. > >BSD4.4 was designed in order to support many stacks, FreeBSD 6, 7 ou 9 will >support only IPv4 and IPv6, won't they ? We will import and retain any protocol stack which has enough interested users and committers to keep it alive. netiso and netccitt both fell for both of those criteria: neither users nor committers. netns fails both criteria too. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: cvsup cvs-supfile users!
On Tue, Mar 04, 2003 at 11:10:45AM -0800, Peter Wemm wrote: > Anybody who uses the cvs-supfile example to get the repository should add > "cvsroot-all" to their supfile. This is in addition to src-all, ports-all, > doc-all etc. > > This is *ONLY* for the folks getting the CVS ,v files via cvsup. If you > use tag=. or tag=RELENG_4, then you are not affected by this. > > I have updated cvs-supfile in -current but not RELENG_4 yet. Just to be doubly sure, this goes for cvsup mirrors as well, I assume? So I have to edit /usr/local/etc/cvsup/supfile to include it? If so, then you might want to update ports/net/cvsup-mirror/files/supfile also. --Stijn -- "An adult is a child who has more ethics and morals, that's all." -- Shigeru Miyamoto pgp0.pgp Description: PGP signature
Re: Removal of netns
Why does it need to be removed ? According to me, it would be the same mistake as the removal of netiso and netccitt. I did not know FreeBSD at this time, but nowadays, in order to get an OS that supports many stacks, we have to use NetBSD. BSD4.4 was designed in order to support many stacks, FreeBSD 6, 7 ou 9 will support only IPv4 and IPv6, won't they ? I do not think that it needs to be removed. One should try to keep this feature. Regards, Vincent Le Mardi 4 Mars 2003 14:47, Tim Robbins a écrit : > Is there a compelling reason why I shouldn't remove netns? That is, does > it serve a purpose now that it could not serve if it was moved to the > Attic? > > > Tim > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
GEOM problems when installing 5.0-RELEASE
Hi all, please point me to the right list if this isn't the right one, but I'm running into what appears to be GEOM trouble when installing 5.0-RELEASE. [btw, the below uses MSDOS terminology for partitions, sorry] The setup is a fairly straight athlon 700 with IDE 2 harddisks, a primary master of 13 G and primary slave of 6 G. BIOS detects both fine, I have Windows XP installed in the first primary partion of ad0, and an extra FAT logical partition in the extended partion on the same drive, resulting in ad0s1, ad0s2 and ad0s5. This disk is fine. The other however, is not. I first tried to install FreeBSD when I still had a primary FAT partition with Win98 on it. Booting from floppy & doing an FTP install went fine, but on reboot, the kernel couldn't mount the root partition. Even worse, after rebooting in XP, it turned out that my Win98 partition was unrecognizable (fortunately nothing was lost). I thought it might be due to my 'unusual' (for me) setup of having 2 primary partitions, 1 win98 and 1 BSD, so I tried again, this time allocating the whole 6 G disk to BSD. Retried the install, once again went fine until the reboot, when the kernel still couldn't find the root partition. Handtyping ad1s1 didn't work, ad1 wasn't listed in the boot devices list, no go. I booted from floppy once again and tried the fixit floppy. And I think I found out where the problem was (forgive any typos, this is transcribed as I don't have a serial console): Fixit# ls -l /dev/ad* crw-r- 1 root operator4, 4 Mar 3 20:07 /dev/ad0 crw-r- 1 root operator4, 5 Mar 3 20:07 /dev/ad0s1 crw-r- 1 root operator4, 6 Mar 3 20:07 /dev/ad0s2 crw-r- 1 root operator4, 8 Mar 3 20:07 /dev/ad0s5 crw-r- 1 root operator4, 7 Mar 3 20:07 /dev/ad1 There is no ad1s1 device! No wonder the kernel can't find it's root if it doesn't detect the correct partition. Am I doing something wrong here? Unfortunately I'm not able to get at sysctl output so I can't find GEOM debugging output there. Is there any way I can provide more information on this? Has anyone else run into this? --Stijn -- Fairy tales do not tell children that dragons exist. Children already know dragons exist. Fairy tales tell children the dragons can be killed. -- G.K. Chesterton pgp0.pgp Description: PGP signature
HEADS UP: cvsup cvs-supfile users!
Anybody who uses the cvs-supfile example to get the repository should add "cvsroot-all" to their supfile. This is in addition to src-all, ports-all, doc-all etc. This is *ONLY* for the folks getting the CVS ,v files via cvsup. If you use tag=. or tag=RELENG_4, then you are not affected by this. I have updated cvs-supfile in -current but not RELENG_4 yet. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: witness_get: witness exhausted?
John Baldwin writes: > > Unfortunately dead witnesses may still be stuck in the lock order > hierarchy and I haven't figured out yet how to properly handle the > case of free'ing a witness structure from the tree while preserving > the correct lock orders. You can try Ah, I think I see. Thanks for the info. > http://www.freebsd.org/~jhb/patches/witness.patch but I don't think > it will help with your specific case. It would probably help a little, but not very much.. Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
On Tue, Mar 04, 2003 at 07:56:27AM -0800, Terry Lambert wrote: > Tim Robbins wrote: > > Is there a compelling reason why I shouldn't remove netns? That is, does > > it serve a purpose now that it could not serve if it was moved to the > > Attic? > > Might as well move /sys/i386/conf/GENERIC to the attic while > you are at it. It can serve it's purpose from there, too. > > Is there a compelling reason for doing this, other than "I > want to make some API/locking change, but I don't want to > have to keep this code working at the same time"? Maximizing Is there a compelling reason for you to moan about the removal of things constantly? -- | / o / /_ _ |/|/ / / /( (_) Bulte [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: witness_get: witness exhausted?
On 03-Mar-2003 Andrew Gallatin wrote: > > I'm developing a character driver which tracks a lot of state on a > per-open basis. I've got several mutexes in there which are > initialzed at open, and destroyed at close. After a few > dozen opens, witness seems to croak with: > > witness_get: witness exhausted > > Am I leaking something? Or is the witness code? I looked at > subr_witness.c, and I don't see witness_free() being called from > witness_destroy(). There's probably some design constraint that > I don't understand. Unfortunately dead witnesses may still be stuck in the lock order hierarchy and I haven't figured out yet how to properly handle the case of free'ing a witness structure from the tree while preserving the correct lock orders. You can try http://www.freebsd.org/~jhb/patches/witness.patch but I don't think it will help with your specific case. > FWIW, Witness (and the FreeBSD debugging environment in general) is > why I've gotten approval to co-develop this driver on FreeBSD (in > addition to linux). Its already caught several locking bugs. Glad to hear it is at least working in some cases. :) -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent sendmail import
On 2003-03-04 12:43, Matt <[EMAIL PROTECTED]> wrote: > > Try to do following commands: > > # cd /etc/mail > > # touch *.mc > > # make cf > > # make restart > > > > then telnet localhost 25 > > Yes this sorted it. "ESMTP Sendmail 8.12.8/8.12.8". The first version number is the version of your Sendmail executable. The second is the version of your sendmail.cf file. They don't always need to be the same, although it's not a bad idea to update the cf file too after upgrades. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert <[EMAIL PROTECTED]> writes: > Mike Barcroft wrote: > > Terry Lambert <[EMAIL PROTECTED]> writes: > > > Tim Robbins wrote: > > > > Is there a compelling reason why I shouldn't remove netns? That is, does > > > > it serve a purpose now that it could not serve if it was moved to the > > > > Attic? > > > > > > Might as well move /sys/i386/conf/GENERIC to the attic while > > > you are at it. It can serve it's purpose from there, too. > > > > This comment is not helpful. > > Then let me politically correct it. This is much more useful, since you document your assertions which turn out to be incorrect (see below). > I am cynical about the ability of any code to serve the same purpose > from the Attic which it serves in the main source tree. > > What of the rest of my comment, which you removed? I'll > rephrase that, too: > > > Is there a compelling reason for removing this working code to > the Attic? Yes, the compelling reason is that it is broken and no one has stepped forward to fix it. Tim is trying to ascertain whether there are infact real users of this. Real users would either have big patchsets or very old versions of FreeBSD. > I am cynical that any purpose is served by making this change; > my cynicism leads me to believe that the intention of it is to > make it easier for someone to hack up other code which uses > related API's, without having to hack up the netns code as > well. The LINT option for Xerox NS protocols has been commented out since at least 1996. It's very unlikely there are actual FreeBSD users of said protocol. > In other words, it is being done to avoid maintenance, so that > code changes may be hurried into the source tree. No, Tim's goal is to clean up the tree and remove unused code, or find maintainers for broken code that indeed has users. [other comments based on false assertions removed.] > Practically, and historically, it seems that there are a lot > of instances, recently, of code being diked out, not because > it is not currently working, but because someone wished to > avoid maintaining it in the face of some sweeping change or > new idea they want to push into the project. I think most people just don't want to have to maintain code that no one uses. The only way we can figure out if anyone's using the code is to ask. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns - politically correct version
Mike Barcroft wrote: > Terry Lambert <[EMAIL PROTECTED]> writes: > > Tim Robbins wrote: > > > Is there a compelling reason why I shouldn't remove netns? That is, does > > > it serve a purpose now that it could not serve if it was moved to the > > > Attic? > > > > Might as well move /sys/i386/conf/GENERIC to the attic while > > you are at it. It can serve it's purpose from there, too. > > This comment is not helpful. Then let me politically correct it. I am cynical about the ability of any code to serve the same purpose from the Attic which it serves in the main source tree. What of the rest of my comment, which you removed? I'll rephrase that, too: Is there a compelling reason for removing this working code to the Attic? I am cynical that any purpose is served by making this change; my cynicism leads me to believe that the intention of it is to make it easier for someone to hack up other code which uses related API's, without having to hack up the netns code as well. In other words, it is being done to avoid maintenance, so that code changes may be hurried into the source tree. This upsets me, in that it seems to me that if someone makes an API change in one place, and avoids it in another, then the person who best understands the API change will be later unavailable to correct the code in which they avoided making the change. This is because, by avoiding the change in the first place, they have expressed a disinterest in making the change in the code in question. I would feel much more comfortable, were mainting older code, rather than diking it out, made part of the cost associated with making the API change in question. In other words, in order to write new code, it is sometimes necessary to maintain old code, and that maintenance is part of the price you must pay to the project in order to have your new code accepted. If this can not be accomplished, then I would submit that the new code be documented sufficiently before the dikeing out of the older code, such that someone else may take on the task of converting the code. Further, I suggest that there be some collaboration between the person making the changes, and anyone who wants to step forward in defense of the older code, such that there is an opportunity to correct the old code before it is diked out. In other words, it seems to me that the dike out is a "first strike" attack on code which will not LINT, following changes which are currently stored in someone local source tree, and the intent here is to dike out the code, and quickly follow it up with a set of commits which will kill it. Thus preventing it from "serving it's same purpose from the Attic". Practically, and historically, it seems that there are a lot of instances, recently, of code being diked out, not because it is not currently working, but because someone wished to avoid maintaining it in the face of some sweeping change or new idea they want to push into the project. Or if you prefer an analogy: it is one thing for bits to rot; it is another thing altogether to intentionally spray them with Agent Orange. Regards, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fw: Re: current and vmware2
Looks like this email didn't make it to the mailing list. I've not tried the solution yet, but I figured everyone would like to see this. James. Begin forwarded message: Date: Tue, 4 Mar 2003 18:14:32 +0900 From: Yoshinori KASAZAKI <[EMAIL PROTECTED]> To: James Satterfield <[EMAIL PROTECTED]> Subject: Re: current and vmware2 hi. On Mon, 3 Mar 2003 14:57:12 -0800 James Satterfield <[EMAIL PROTECTED]> wrote: > I'm trying to run vmware2 on a recent -current. I'm getting these when trying to > load the vmmon_up module. > kldload: can't load /usr/local/lib/vmware/lib/modules/vmmon_up.ko: No such file or > directory > Also making an appearance in dmesg is link_elf: symbol cdevsw_add undefined. > Current from today. Using linux_base-7.1_2. > Linux module is loaded. > > Any suggestions would be appreciated. > > James. I've also bitten by this. I found that the cause is 'cdevsw_add' call, which seems like required to register device before. so I did: % cd /usr/ports/emulators/(rtc|vmware2) % make configure % grep -r 'cdevsw_add' work/* and replaced all 'error = cdevsw_add' by 'error = 0', then % make all install and VMware2 works fine for me again. but a warning message : WARNING: driver "vmmon" used unreserved major device number 200 is displayed when vmmon.ko is loaded. so this might not be a right solution, but it worked for me. hope this helps. Y.Kasazaki // To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
Terry Lambert <[EMAIL PROTECTED]> writes: > Tim Robbins wrote: > > Is there a compelling reason why I shouldn't remove netns? That is, does > > it serve a purpose now that it could not serve if it was moved to the > > Attic? > > Might as well move /sys/i386/conf/GENERIC to the attic while > you are at it. It can serve it's purpose from there, too. This comment is not helpful. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA problems
On Tue, Mar 04, 2003 at 04:59:33PM +0100, Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote: > Soeren Schmidt <[EMAIL PROTECTED]> writes: > > It seems Dag-Erling Smorgrav wrote: > > > ad0: READ command timeout tag=0 serv=1 - resetting > > > ad0: invalidating queued requests > > That why it is disabled, its not working for the time being. > > For me, "the time being" == "since it was introduced in the tree". It > has never worked for me, ever. That's the point I was trying to make. It's probably dependent of your ATA controller. You have the infamous P5A board with ALi chipset, it has timekeeping problems also if I remember. I've used DTLA and DPTA disk behind PIIX4 controller and have had zero problems after the initial development did settle. -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems compiling KDE after mega-commit
On Tue, Mar 04, 2003 at 04:39:46AM -0300, Rossam Souza Silva wrote: > > Yes, I had problems with icewm in CURRENT too, but tried to compile > it before the mega-commit (version of 3-4 days ago). My workstation > at work (version of two weeks ago) installed icewm from ports without > problem. > > I upgraded my ports tree and now I'm running portupgrade -u --all before > try KDE again. ltmdm (changed from 1.4_3 to 1.4_4) continues broken: > > [EMAIL PROTECTED]:/usr/ports/comms/ltmdm> sudo make clean > ===> Cleaning for ltmdm-1.4_4 > [EMAIL PROTECTED]:/usr/ports/comms/ltmdm> sudo make [skip build log] > elements in struct initializer > /usr/ports/comms/ltmdm/work/sys/dev/ltmdm/ltmdmsio.c:389: warning: (near > initialization for `sio_cdevsw') > *** Error code 1 > > Stop in /usr/ports/comms/ltmdm/work/sys/modules/ltmdm. > *** Error code 1 > > Stop in /usr/ports/comms/ltmdm. Look at http://www.freebsd.org/cgi/query-pr.cgi?pr=48922 > > On Tue, Mar 04, 2003 at 01:57:46AM -0500, Andre Guibert de Bruet wrote: > > > > > > You need to upgrade your ports skeleton. There's a couple of fixes that > > > were committed within the last 24 hours which fix these issues. > > > > Hmm..I've seen this on another port already (icewm, I think). It > > looks like phk might have some additional patching to do when I get > > him the full list. -- Rgdz,/"\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA problems
Soeren Schmidt <[EMAIL PROTECTED]> writes: > It seems Dag-Erling Smorgrav wrote: > > ad0: READ command timeout tag=0 serv=1 - resetting > > ad0: invalidating queued requests > That why it is disabled, its not working for the time being. For me, "the time being" == "since it was introduced in the tree". It has never worked for me, ever. That's the point I was trying to make. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent sendmail import
On Tue, 04 Mar 2003 07:52:32 -0800, Terry Lambert wrote > > If you care, see other posting on how to "fix" it. Or you could > just edit the version in the config file, and call it a day. I > don't think you will see any differences from regenerating from > the M4 sources. > > -- Terry Yeah, thanks for the reply. I think what actually happened was that I cvsup'd halfway between the update and missed some of the src/etc/mail updates. This morning I cvsup'd again and ran mergemaster for a second time and the freebsd.cf and sendmail.cf both contain DZ8.12.8 now. Thankyou for confirming what the two version numbers were for though. I never knew this and when I saw the differences in versions it made me wonder. Regards, Matt. --- Matt ([EMAIL PROTECTED]) http://www.xtaz.co.uk/ --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
Tim Robbins wrote: > Is there a compelling reason why I shouldn't remove netns? That is, does > it serve a purpose now that it could not serve if it was moved to the > Attic? Might as well move /sys/i386/conf/GENERIC to the attic while you are at it. It can serve it's purpose from there, too. Is there a compelling reason for doing this, other than "I want to make some API/locking change, but I don't want to have to keep this code working at the same time"? Maximizing bit-rot in order to avoid effort is a bad thing, particularly when it's done by the person who is making the change that causes the rot: that person is the person most qualified in the world to correct the bit-rot (or prevent it from happening), in that they have the best understanding of *why* their change broke something. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent sendmail import
Matt wrote: > After I rebooted I checked the sendmail header by telnetting port 25 to check > I had the new version and it had "ESMTP Sendmail 8.12.8/8.12.7" in it. This I > thought was odd as I was expecting it to say 8.12.8 on both. I grepped for > 8.12 in /etc/mail and freebsd.cf and sendmail.cf had DZ8.12.7 in them. Is > this intentional or something not updated properly? I did run mergemaster etc > but like I said I was tired and could well have answered something wrong. Non-problem. It indicates version of sendmail, version of config file. If you care, see other posting on how to "fix" it. Or you could just edit the version in the config file, and call it a day. I don't think you will see any differences from regenerating from the M4 sources. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Amanda backups, or dump(8) broken?
Hi, Is anyone else here backing up -CURRENT machines using AMANDA? I've been noticing that the backups for these machines have what appear to be bad backups. That is to say, amverify gives things like this: [...] firepipe-3 (ganymede._.20030304.1): amrestore: 0: skipping start of tape: date 20030304 label firepipe-3 amrestore: 1: restoring ganymede._.20030304.1 gzip: stdin: decompression OK, trailing garbage ignored amrestore: 2: reached end of information cannot open /dev/tty: Device not configured Tape is not a dump tape 64+0 in 64+0 out firepipe-3 (oberon._usr.20030304.2): amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: 0: restoring oberon._usr.20030304.2 gzip: stdin: decompression OK, trailing garbage ignored amrestore: 1: reached end of information cannot open /dev/tty: Device not configured Tape is not a dump tape 64+0 in 64+0 out [...] ganymede: FreeBSD ganymede.firepipe.net 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Sun Mar 2 22:01:40 EST 2003 [EMAIL PROTECTED]:/net/ganymede/src/sys/i386/compile/GANYMEDE i386 oberon: FreeBSD oberon.firepipe.net 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Jan 14 01:19:15 EST 2003 [EMAIL PROTECTED]:/usr/src/sys/sparc64/compile/OBERON sparc64 Ganymede runs Amanda 2.4.3 while oberon is running Amanda 2.4.4b1 due to 64-bit safeness fixes in that version. Note that I also back up three other machines (two 4.x/i386 and one Linux/mipsel) without a peep from amverify. Anyone know if maybe the dump format has been changed to the extent that it breaks Amanda or something? In fact, based on the "64+0" it appears that the header or something similar may have been broken. Or maybe Amanda is broken. I'm just looking for someone else who has already seen this behavior. Preferably someone else that knows what the issue is and how it might be fixed... Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: nvidia module panics today's kernel [03-03-03]
Maxime Henrion wrote: walt wrote: My mini 'disaster' of earlier today was caused by the nvidia kernel module being autoloaded at boot, which causes an immediate kernel panic. The newest kernel seems fine until I try to load the module manually, at which time I still get the kernel panic even after re-compiling the module. Maxime, it looks like the nvidia module will need to be sculpted one more time. :-( Yes, the cdevsw initialization scheme and the driver needs to be updated accordingly. I've updated my patch at : http://mu.org/~mux/patches/nvidia.patch Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message Maybe the kernel driver portion of the nvidia driver set should be imported into /sys/contrib? It seems to be breaking quite often at the hands of people who usually are good about updating all drivers in the tree. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: nvidia module panics today's kernel [03-03-03]
Maxime Henrion wrote: > walt wrote: > > My mini 'disaster' of earlier today was caused by the nvidia kernel > > module being autoloaded at boot, which causes an immediate kernel panic. > > > > The newest kernel seems fine until I try to load the module manually, > > at which time I still get the kernel panic even after re-compiling > > the module. > > > > Maxime, it looks like the nvidia module will need to be sculpted one > > more time. :-( > > Yes, the cdevsw initialization scheme and the driver needs to be updated ^ changed > accordingly. I've updated my patch at : > > http://mu.org/~mux/patches/nvidia.patch > > Cheers, > Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: nvidia module panics today's kernel [03-03-03]
walt wrote: > My mini 'disaster' of earlier today was caused by the nvidia kernel > module being autoloaded at boot, which causes an immediate kernel panic. > > The newest kernel seems fine until I try to load the module manually, > at which time I still get the kernel panic even after re-compiling > the module. > > Maxime, it looks like the nvidia module will need to be sculpted one > more time. :-( Yes, the cdevsw initialization scheme and the driver needs to be updated accordingly. I've updated my patch at : http://mu.org/~mux/patches/nvidia.patch Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA problems
It seems Dag-Erling Smorgrav wrote: > Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: > > No tags, like you said. Previously, with a tags-capable kernel, > > enabling tags would cause a continuous stream of timeouts and resets > > on both disks. > > Just for kicks, I removed the #if 0 in ata-disk.c and got exactly the > same symptoms as before: > > ad0: READ command timeout tag=0 serv=1 - resetting > ad0: invalidating queued requests That why it is disabled, its not working for the time being. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: nvidia module panics today's kernel [03-03-03]
Andre Guibert de Bruet wrote: If you really need to use your workstation, you can try the open source nv XFree86 driver. It's not as fast as the nVidia detonator driver and it's not accelerated, but you can at least use X11 at a reasonable resolution and color depth. It works well enough for my purposes, thanks once again. Actually, I had tried the 'nv' driver once before with no luck, but this time I thought to disable the 'glx' module which is installed by the proprietary nVidia driver and now it works just fine. Maybe I should mention that I'm using a Riva TNT2 chip, not a GeoForce. And, of course, I'm still running my kernel from two days ago, so I'd better try compiling today's kernel before I get too complacent... You've been a great help in the last 24 hours. Thank you! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Removal of netns
Is there a compelling reason why I shouldn't remove netns? That is, does it serve a purpose now that it could not serve if it was moved to the Attic? Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build - fail
walt (wa1ter) writes: > vnode_if.pl is a file from the -STABLE tree, not -CURRENT. Which > kernel are you trying to build? Doh! Well, when I cvsup'ed I accidently used an old cvsup-src-file for RELENG_4.. That might explain the problem. Thanks. /mich -- Best Regards, Michael Landin Hostbaek FreeBSDCluster.org - an International Community */ PGP-key available upon request /* pgp0.pgp Description: PGP signature
Re: kernel build - fail
Michael Hostbaek wrote: --ncSAzJYg3Aa9+CRW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I cvsup'ed my source this morning, and after a successfull 'make buildworld' I launch 'make buildkernel KERNCONF=3DGENERIC' - shortly after it dies with the following message: sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s perl5 /usr/src/sys/kern/vnode_if.pl -h /usr/src/sys/kern/vnode_if.src vnode_if.pl is a file from the -STABLE tree, not -CURRENT. Which kernel are you trying to build? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel build - fail
Hi, I cvsup'ed my source this morning, and after a successfull 'make buildworld' I launch 'make buildkernel KERNCONF=GENERIC' - shortly after it dies with the following message: sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s perl5 /usr/src/sys/kern/vnode_if.pl -h /usr/src/sys/kern/vnode_if.src perl5: Perl is not installed, try 'pkg_add -r perl' *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 I have perl installed.. but a kernel build does not normally depend on perl ?? Let me know if you need additional info. /mich -- Best Regards, Michael Landin Hostbaek FreeBSDCluster.org - an International Community */ PGP-key available upon request /* pgp0.pgp Description: PGP signature
Re: ATA problems
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: > No tags, like you said. Previously, with a tags-capable kernel, > enabling tags would cause a continuous stream of timeouts and resets > on both disks. Just for kicks, I removed the #if 0 in ata-disk.c and got exactly the same symptoms as before: ad0: READ command timeout tag=0 serv=1 - resetting ad0: invalidating queued requests ata0: resetting devices .. ad0: invalidating queued requests done ad0: no request for tag=0 ad0: invalidating queued requests ad0: 9641MB [19590/16/63] at ata0-master tagged UDMA33 ad0: READ command timeout tag=0 serv=1 - resetting ad0: invalidating queued requests ata0: resetting devices .. ad0: invalidating queued requests done ad0: no request for tag=0 ad0: invalidating queued requests ad1: READ command timeout tag=0 serv=1 - resetting ad1: invalidating queued requests ata1: resetting devices .. ad1: invalidating queued requests done ad1: no request for tag=0 ad1: invalidating queued requests ad0: READ command timeout tag=0 serv=1 - resetting ad0: invalidating queued requests ata0: resetting devices .. ad0: invalidating queued requests done ad0: no request for tag=0 ad0: invalidating queued requests ad1: 39266MB [79780/16/63] at ata1-master tagged UDMA33 acd0: CD-RW at ata0-slave WDMA2 ad1: READ command timeout tag=0 serv=1 - resetting ad1: invalidating queued requests ata1: resetting devices .. ad1: invalidating queued requests done ad1: no request for tag=0 ad1: invalidating queued requests ad0: READ command timeout tag=0 serv=1 - resetting ad0: invalidating queued requests ad0: trying fallback to PIO mode ata0: resetting devices .. ad0: invalidating queued requests done ad1: READ command timeout tag=0 serv=1 - resetting ad1: invalidating queued requests ata1: resetting devices .. ad1: invalidating queued requests done ad1: no request for tag=0 ad1: invalidating queued requests ad1: no request for tag=0 ad1: invalidating queued requests ad1: READ command timeout tag=0 serv=1 - resetting ad1: invalidating queued requests ad1: trying fallback to PIO mode ata1: resetting devices .. ad1: invalidating queued requests done it never even got to mounting root, I grew tired of waiting and coldbooted it. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA problems
Soeren Schmidt <[EMAIL PROTECTED]> writes: > Tags are disabled in -current in ata-disk.c so if the sources are > up to date that cannot be the problem. > Please update and then at least provide a dmesg if it still fails. top-of-tree: [EMAIL PROTECTED] /home/des# egrep '(ata|ad)[0-9]' /var/run/dmesg.boot ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 9641MB [19590/16/63] at ata0-master UDMA33 ad1: 39266MB [79780/16/63] at ata1-master UDMA33 acd0: CD-RW at ata0-slave WDMA2 No tags, like you said. Previously, with a tags-capable kernel, enabling tags would cause a continuous stream of timeouts and resets on both disks. I saw your commit disabling tags on 2003-02-23, but I didn't see any related discussion that would explain why they were disabled. [EMAIL PROTECTED] /home/des# atacontrol cap 0 0 ATA channel 0, Master, device ad0: ATA/ATAPI revision4 device model IBM-DTTA-371010 serial number WN0WKFW1158 firmware revision T77OA73A cylinders 16383 heads 16 sectors/track 63 lba supported 19746720 sectors lba48 not supported dma supported overlap not supported Feature Support EnableValue Vendor write cacheyes yes read ahead yes yes dma queued yes yes 31/1F SMART yes no microcode download no no security yes no power management yes yes advanced power management no no 0/00 automatic acoustic management no no 0/000/00 [EMAIL PROTECTED] /home/des# atacontrol cap 1 0 ATA channel 1, Master, device ad1: ATA/ATAPI revision5 device model IC35L040AVER07-0 serial number SX0SXM75217 firmware revision ER4OA44A cylinders 16383 heads 16 sectors/track 63 lba supported 80418240 sectors lba48 not supported dma supported overlap not supported Feature Support EnableValue Vendor write cacheyes yes read ahead yes yes dma queued yes yes 31/1F SMART yes no microcode download no no security yes no power management yes yes advanced power management yes no 0/00 automatic acoustic management yes no 254/FE 128/80 DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0 Release: `npx_driver',`npx_devclass' defined but not used, breakskernel build
This is repeatable. Re-cvsupped using the same tag yesterday morning and rebuilt on a clean /obj with the same result. 5.0 Release appears to be broken. On Sun, 2 Mar 2003, Geoffrey wrote: > > Ladies and Gentlemen > > From a fresh cvsup of RELENG_5_0 this afternoon, make buildkernel > returns: > > cc1: warnings being treated as errors > /usr/src/sys/i386/isa/npx.c:1078: warning: `npx_driver' defined but not > used > /usr/src/sys/i386/isa/npx.c:1084: warning: `npx_devclass' defined but not > used > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/BINKY1. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > > This is with -march=pentium-mmx in make.conf and device npx > in my kernel configuration. > > Suggestions? Remedies? > > Thankyou. > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent sendmail import
> Try to do following commands: > # cd /etc/mail > # touch *.mc > # make cf > # make restart > > then telnet localhost 25 Yes this sorted it. "ESMTP Sendmail 8.12.8/8.12.8". Cheers :) Matt. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent sendmail import
On Tue, Mar 04, 2003 at 12:04:49PM +, Matt wrote: > This could well be just something I forgot to do or I'm missing something as > I built my world last night at about 1am when I was knackered, so I apologise > if this isn't an issue. > > After I rebooted I checked the sendmail header by telnetting port 25 to check > I had the new version and it had "ESMTP Sendmail 8.12.8/8.12.7" in it. This I > thought was odd as I was expecting it to say 8.12.8 on both. I grepped for > 8.12 in /etc/mail and freebsd.cf and sendmail.cf had DZ8.12.7 in them. Is > this intentional or something not updated properly? I did run mergemaster etc > but like I said I was tired and could well have answered something wrong. > > Thought I would mention it in case it was something that was missed! Try to do following commands: # cd /etc/mail # touch *.mc # make cf # make restart then telnet localhost 25 -- Rgdz,/"\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA problems
It seems Dag-Erling Smorgrav wrote: > Scotty <[EMAIL PROTECTED]> writes: > > ad0: READ command timeout tag=0 serv=0 - resetting > > ata0: resetting devices .. > > Disable tags (add hw.ata.tags=0 to /boot/loader.conf). Never worked > for me either (ASUS P5A, ALi M1543 southbridge, IBM DTTA and IC35L > disks) Tags are disabled in -current in ata-disk.c so if the sources are up to date that cannot be the problem. Please update and then at least provide a dmesg if it still fails. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA problems
Scotty <[EMAIL PROTECTED]> writes: > ad0: READ command timeout tag=0 serv=0 - resetting > ata0: resetting devices .. Disable tags (add hw.ata.tags=0 to /boot/loader.conf). Never worked for me either (ASUS P5A, ALi M1543 southbridge, IBM DTTA and IC35L disks) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Recent sendmail import
This could well be just something I forgot to do or I'm missing something as I built my world last night at about 1am when I was knackered, so I apologise if this isn't an issue. After I rebooted I checked the sendmail header by telnetting port 25 to check I had the new version and it had "ESMTP Sendmail 8.12.8/8.12.7" in it. This I thought was odd as I was expecting it to say 8.12.8 on both. I grepped for 8.12 in /etc/mail and freebsd.cf and sendmail.cf had DZ8.12.7 in them. Is this intentional or something not updated properly? I did run mergemaster etc but like I said I was tired and could well have answered something wrong. Thought I would mention it in case it was something that was missed! Regards, Matt. --- Matt ([EMAIL PROTECTED]) http://www.xtaz.co.uk/ --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Changes to libfetch in 5.0 break proxy support?
"Brian J. McGovern" <[EMAIL PROTECTED]> writes: > Anyone have any ideas if something has broken, or whether its pilot error? Please show the output of "fetch -vvv " DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB port periodically dies, now with complete body text
On Tue, Mar 04, 2003 at 04:21:14AM -0700, Cliff L. Biffle wrote: > Damn KMail. Full text to follow: > --- > > I've been having a reliable USB issue on my 5-current box (3 Mar, 23:58:25 > MST). It's been happening since I upgraded to -current in the DP2 days, and > has happened on two completely independent motherboards. On the more recent > of the two (the previous died) I've enabled USB_DEBUG. Here's the deal. I'm aware of problems when disconnecting open usb devices at least on ohci controllers and some devices. The simptoms might have changed. Maybe I find some time this week to hunt it - I already have an idea about the reason. In the meantime as a workaround don't dissconnect opened devices. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
