Problem with accessing windows-share
Hi! I'm having problems accessing a share on a windows-box at work. I used mount_smbfs earlier: --- ex. --- su-2.05a# mount_smbfs -I hostname.of.windows.box -W win-workgroup //my-win-username@remote-windows-box/share-name/ /mnt/winbox/ Password: mount_smbfs: unable to open connection: syserr = RPC struct is bad --- ex. --- This used to work fine... I've also tried Sharity Light (haven't used it before, so I wouldn't know if it would have worked earlier, though): --- ex. --- su-2.05a# ./shlight //hostname.of.windows.box/share-name /mnt/winbox/ -W win-workgroup -U my-win-username -s remote-windows-box Password: error connecting to server: [5] Input/output error --- ex. --- uname: su-2.05a# uname -a FreeBSD hostname.of.my.box 4.5-RELEASE-p2 FreeBSD 4.5-RELEASE-p2 #0: Tue Mar 19 10:03:00 CET 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DAEMONBOX i386 Any help is appreciated. -- Bo To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
TCL 8.3 Build Error
In the latest copy of /usr/ports/x11-toolkits/tk83 that I have, it does not want to build correctly. This port is of tk 8.3.4. I have tried to make this build since sometime I did a port upgrade on FreeBSD 4.4. I have included the error message, and it's important that sometime I get this going because I need it in order to make tkseti run (I thought it would like tk84 installed, but that install didn't make tkseti want to build). Heh, then I can keep better track of our team's SETI@Home progress. If there is any way to make tcl84 (a make.conf setting?) work w/tkseti instead of tk83 just tell me. This is being run on FreeBSD 4.5 Stable. For those of you who don't know, tkseti is a GUI frontend to the SETI@Home packet analyzer. Error log: === Building for tk-8.3.4_2 cc -pipe tkAppInit.o -L/usr/ports/x11-toolkits/tk83/work/tk8.3.4/unix -ltk83 -L/usr/local/lib -ltcl83 -L/usr/X11R6/lib -lX11 -lm -lc -o wish /usr/ports/x11-toolkits/tk83/work/tk8.3.4/unix/libtk83.so: undefined reference to `Tcl_SetMainLoop' *** Error code 1 Stop in /usr/ports/x11-toolkits/tk83/work/tk8.3.4/unix. *** Error code 1 Stop in /usr/ports/x11-toolkits/tk83. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Logitech iFeel Optical USB Mouse cannot be attached.
This looks like an electrical problem. What happens if you connect the mouse directly to the machine, without any hubs? Nick On Sun, 23 Dec 2001, Raman Ng wrote: Hello all, I have already sent a mail about this problem before. I am a newbie of FreeBSD. This time I attached the dmesg output and kernel configuration for you all. I am using Asus A7V mb, Athlon 1.1 GHz CPU, 512 Mb RAM. Whenever the kernel boot up, the message device_probe_and_attach: ums0 attach returned 6. Details can refer to the attached detail.. This problem is similar to PR misc/30373 and there is no one handle it at all. I have tried FreeBSD 4.4-RELEASE, 4.5-PRERELEASE and 5.0-CURRENT (which is cvsup a month ago) and the problem is still persisted. I can use this mouse without any problem with Windows and Linux. Please give me any clue if I can solve this problem. Thanks in advance. Regards, Raman --- dmesg output --- Copyright (c) 1992-2001 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 4.5-PRERELEASE #0: Sun Dec 23 01:55:47 HKT 2001 root@:/usr/obj/usr/src/sys/STABLE_DEBUG Timecounter i8254 frequency 1193182 Hz CPU: AMD Athlon(tm) Processor (1109.89-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x642 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044b18,AMIE,DSP,3DNow! real memory = 536788992 (524208K bytes) avail memory = 518246400 (506100K bytes) Preloaded elf kernel kernel at 0xc0389000. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 9 entries at 0xc00f1750 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: VIA 8363 (Apollo KT133) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: NVidia model 0110 graphics accelerator at 0.0 irq 11 isab0: VIA 82C686 PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA66 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 9 at device 4.2 on pci0 uhci0: LegSup = 0x003b uhci_run: setting run=0 uhci_run: done cmd=0x80 sts=0x20 uhci_run: setting run=1 uhci_run: done cmd=0x81 sts=0x0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xd000-0xd01f irq 9 at device 4.3 on pci0 uhci1: LegSup = 0x0010 uhci_run: setting run=0 uhci_run: done cmd=0x80 sts=0x20 uhci_run: setting run=1 uhci_run: done cmd=0x81 sts=0x0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci_device_request: not done, ii=0xc104f680 uhub2: ALCOR Generic USB Hub, class 9/0, rev 1.10/1.00, addr 2 uhub2: 4 ports with 4 removable, self powered uhci_device_intr_transfer: not done, ii=0xc104f620 uhci_waitintr: timeout uhci_idone: error, addr=3, endpt=0x00, status 0x50BABBLE,STALLED uhci_waitintr: timeout usbd_transfer_cb: short transfer 01 uhci_waitintr: timeout usbd_transfer_cb: short transfer 01 ums0: Logitech, Inc. iFeel Mouse, rev 1.00/1.01, addr 3, iclass 3/1 uhci_waitintr: timeout usbd_transfer_cb: short transfer 074 device_probe_and_attach: ums0 attach returned 6 uhci_waitintr: timeout usbd_transfer_cb: short transfer 01 uhci_waitintr: timeout usbd_transfer_cb: short transfer 01 uhci_waitintr: timeout usbd_transfer_cb: short transfer 04 uhci_waitintr: timeout usbd_transfer_cb: short transfer 04 chip1: VIA 82C686 ACPI interface at device 4.4 on pci0 rl0: RealTek 8139 10/100BaseTX port 0xa400-0xa4ff mem 0xd580-0xd58000ff irq 9 at device 9.0 on pci0 rl0: Ethernet address: 00:50:ff:60:0b:b8 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Creative EMU10K1 port 0xa000-0xa01f irq 5 at device 10.0 on pci0 pci0: unknown card (vendor=0x104c, dev=0x8020) at 13.0 irq 9 atapci1: Promise ATA100 controller port 0x8000-0x803f,0x8400-0x8403,0x8800-0x8807,0x9000-0x9003,0x9400-0x9407 mem 0xd400-0xd401 irq 10 at device 17.0 on pci0 ata2: at 0x9400 on atapci1 ata3: at 0x8800 on atapci1 orm0: Option ROMs at iomem 0xc-0xcbfff,0xcc000-0xc,0xd-0xd27ff on isa0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0
help: routes don't release!
Hi! After dial-in connection (pppd) (users who have static IP in /etc/ppp/pap-secrets) don't release routing table. In routing table remains wrong lines: DestinationGatewayFlagsRefs Use Netif Expire 192.168.100.100(0)UH 00 ppp12 192.168.200.3 (0)UH 04 ppp14 192.168.200.14 (0)UH 00 ppp13 and this users don't more connect to system: after authenticating pppd can't assign IP to interface. Some my friends obtained same problem with pppX and tunX interfaces after updating to 4.5 stable. uname: FreeBSD 4.5-STABLE #10: Wed Mar 27 14:52:11 EET 2002 Help!! -- Vladislav V. Zhuk (06267)3-60-03 [EMAIL PROTECTED] 2:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: installworld failure
Hello, Crist J. Clark! On Tue, Apr 02, 2002 at 03:22:52PM -0800, you wrote: mtree -deU -f /usr/src/etc/mtree/BSD.var.dist -p /var mtree: line 63: unknown user smmsp *** Error code 1 what is wrong here? You don't have a user smmsp in your passwd(5) database. Update your master.passwd(5) and group(5) files and try again. Shouldn't it be done by mergemaster? I think that build/install should not depend on this kind of things, or there should be note in handbook ( | ||) UPDATING that mergemaster should be run _before_ installworld. -- NEVE-RIPE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Heads up, a bit: ephemeral port range changes
On Wed, 3 Apr 2002, Garance A Drosihn wrote: What I don't see is why this must be made to -stable at all. What would be the consequences if we simply left RELENG_4 with the same port-range that it's always had? Note that this is not a complaint on my part, it is only a request for more information. The ephemeral port range determines the maximum number of simultaneous outbound connections that you can have. As pointed out in a PR (I don't recall the # offhand), our low limit was probably the reason that FreeBSD ran out of steam before the other OSes in the sysadmin benchmark last year. Normally I wouldn't change settings to tune for a benchmark, but there is no functional downside to this change. As Jacques points out, many sysadmins with busy servers _already_ make this change, as have a few other OSes. Chances are pretty good that they would not notice any such problems until after they have done the installworld step, and thus it is not necessarily a simple matter to just go back to their previous kernel. Sure it is. After an installkernel you always have kernel.old sitting around. This isn't a big deal, guys. Go find something better to make a fuss about. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Heads up, a bit: ephemeral port range changes
On Wed, Apr 03, 2002 at 10:53:25PM -0600, Mike Silbersack wrote: As we have a RELENG_4_5 branch, I see no reason that I should hold off on the change. It's mostly unimportant, not gratuitous. Well, Mike, I don't think I can put it more strongly. If you are insistent about making this change, I cannot stop you. I wish you would not. If it is not gratuitous, pray tell what benefit this change will bring. It will certainly snag a minority of folks, and that makes it a bad idea as far as I am concerned. On Wed, Apr 03, 2002 at 04:09:56PM -0800, Michael Sierchio wrote: It isn't stable -- gratuitously updating on a weekly or daily basis is for hobbyists. It's known to break things now and then. We try very hard _not_ to break things. We break things only when there is a compelling reason to break them. Not because we just feel like it. The idea of holding pending MFCs until we're in RC stage is far worse. As I implied in an earlier message, I would prefer that it never be merged to 4.x. If you're interested in stability, you'll track RELENG_4_5, as Mike suggests. I don't track RELENG_4_5. I _maintain_ the RELENG_4_5 and other security branches. On Wed, Apr 03, 2002 at 07:57:08PM -0500, Garance A Drosihn wrote: Chances are pretty good that they would not notice any such problems until after they have done the installworld step, and thus it is not necessarily a simple matter to just go back to their previous kernel. Yes, it is worse. It probably will not happen until the run application X --- perhaps an ICQ client, or an FTP server, or whatever. It will fail, and for some people it will cost time to determine the cause and to repair it. This is not /so/ bad for someone tracking -STABLE, except that the whole problem can and should be avoided. I would feel a little better about making this change to -stable if we knew what important (time-critical) issue that it was fixing. BSD has used the low range ports ``forever''. There is absolutely no time-critical reason to change the default now. I don't think I'll be posting on the issue again, as the length of the thread will soon be disproportionate to the subject's importance, if it isn't already. :-) Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Heads up, a bit: ephemeral port range changes
On Thu, Apr 04, 2002 at 01:07:13AM -0600, Mike Silbersack wrote: The ephemeral port range determines the maximum number of simultaneous outbound connections that you can have. As pointed out in a PR (I don't recall the # offhand), our low limit was probably the reason that FreeBSD ran out of steam before the other OSes in the sysadmin benchmark last year. This falls in the same category as any other system tuning for questionable benchmarks. It is certainly not a compelling reason to break things. Normally I wouldn't change settings to tune for a benchmark, but there is no functional downside to this change. As Jacques points out, many sysadmins with busy servers _already_ make this change, as have a few other OSes. And it is a good change --- for a new operating system release. Sure it is. After an installkernel you always have kernel.old sitting around. You don't need the old kernel, anyway. You can just use the sysctl knobs. This isn't a big deal, guys. Go find something better to make a fuss about. Thanks for your consideration, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Heads up, a bit: ephemeral port range changes
Forgive me if I don't understand something. I presume you are changing the default values of net.inet.ip.portrange.first and net.inet.ip.portrange.last? If this is true, and it follows that you can change these back to their previous values, what is the fuss about? -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] The opinions expressed above are entirely my own The practice of study only too often makes people mere repeaters and producers of cliches and sayings. Such study has been all but wasted. The product has taken the form in which we find it because it is an unsuitable graft upon an unprepared basis. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: installworld failure
Alex wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 3 Apr 2002, Bryan Berch wrote: I am getting the same error messages when doing make installworld, but I have the right lines in /etc/master.passwd and /etc/group from previous mergemaster. Is there something else I should try? Try deleting the entries and then use pw to put them back. Worked for me. I tried deleting the entries and using pw to put them back in, but get told that they already exist. Then I tried using pw to delete them and it tells me they do not exist. Is there another way to get the system to recognize the smmsp and mailnull? Bryan - - Alexander Davis [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (OpenBSD) Comment: For info see http://www.gnupg.org iD8DBQE8q4ihQII06+T026URAsd9AJsEUvdmtqzAuyfPmlLC7ozbIGo5EQCcC0GC L65BD3OF8dQEFidgSuBfGuE= =Q/BM -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: src-sys-crypto and src-all (was des_enc.S)
Hi,
On Wed, 3 Apr 2002 12:06:03 -0700 (MST)
Aaron Mildenstein [EMAIL PROTECTED] said:
aaronm Ah. src-all
aaronm I had set up cvsup with the cvsupit tool in the ports collection when I
aaronm first started using cvs (back in 4.0 days). It had me select what lines I
aaronm wanted to use, ie. src-games, src-sys, etc, and then I had a 20+ line
aaronm cvsupfile. I have been transplanting that file on all of my FreeBSD
aaronm machines since then, and had been unaware that src-sys-crypto had been
aaronm added, or that there was even a src-all option for cvsupfile. Perhaps
aaronm more attention should be given this, as it was a fairly recent (pre 4.5
aaronm release, I never had a problem) change.
The smbfs.ko module was newly added into 4-STABLE since 4.4-RELEASE.
If you have src/sys/crypto in your src tree, smbfs.ko will be compiled
with DES support.
Recently, new module (des_enc.S) was added into src/sys/crypto and
smbfs.ko requires it.
It seems you had src/sys/crypto in your src tree but you didn't do
CVSup for src-sys-crypto collection.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: (hardware?) trouble with make buildworld on 4.5
On Tue, 2 Apr 2002, Alex Edelman wrote: My current theory on the failure places blame on the CPU; I think, it is either busted (I broke it) or it is not supported by FreeBSD. The hardware is a Shuttle SV24 (those cute mini-systems everybody raves about) and the CPU is a Via C3 866 (Ezra core or later.) I have a friend who has the same system and a slightly older/slower Via C3 (Samuel core). He upgraded to 4.5-STABLE last night without any problems. I am not sure about VIA chips. Here is the relevant snippet from his dmesg output: CPU: VIA C3 Samuel 2 (751.71-MHz 686-class CPU) Origin = CentaurHauls Id = 0x671 Stepping = 1 Features=0x803035FPU,DE,TSC,MSR,MTRR,PGE,MMX ...Here is mine, note the unrecognized CPU: CPU: IDT Unknown (864.47-MHz 686-class CPU) Origin = CentaurHauls Id = 0x678 Stepping = 8 Features=0x803035FPU,DE,TSC,MSR,MTRR,PGE,MMX Here are the last 50 lines of two separate make buildworld attempts. The few lines leading up to the 'Stop' line usually tell the needed information. Here are the last 50 lines of two separate make buildworld attempts. Both of which were done last night, after deleting all of /usr/src and /usr/obj, and grabbing fresh from cvsup7.freebsd.org. Thanks in advance for any guidance you can provide. Deleting /usr/src is not useful. Cvsup will correct a not up to date source tree. Deleting /usr/obj is accomplishes by a 'make clean' as part of a normal 'make buildworld'. 'make world' includes the make targets of 'make buildworld' and 'make installworld'. Let's look. /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c -o lib_refresh.o /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c: In function `wnoutrefresh': /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c:73: syntax error before character 0323 Syntax errors here. ^^^ /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c:129: `limit_x' undeclared (first use in this function) /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c:129: (Each undeclared identifier is reported only once /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c:129: for each function it appears in.) *** Error code 1 /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c:129: `limit_x' undeclared (first use in this function) /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c:129: (Each undeclared identifier is reported only once /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_refresh.c:129: for each function it appears in.) *** Error code 1 Stop in /usr/src/lib/libncurses. *** Error code 1 And also... cc -O -pipe -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c /usr/src/lib/msun/src/k_standard.c -o k_standard.o /usr/src/lib/msun/src/k_standard.c: In function `__kernel_standard': /usr/src/lib/msun/src/k_standard.c:322: syntax error before character 0240 *** Error code 1 Stop in /usr/src/lib/msun. *** Error code 1 This says syntax error too. ^^^ I don't know why you are getting syntax errors. My guess is you supped at an inopportune moment. I would sup again and 'make buildworld'. Like I said, I don't know about VIA chips and how well they are supported. One commonly sees errors like 'kernel panic, signal 11' when there is a faulty hardware problem. If you have a custom kernel, make sure it has support for the 686 class CPU. This is shown in your dmesg output. My answers is based on an empirical guess. I think a new sup might work. It has almost always worked for me when I get a syntax error of some sort. Also, when your build fails on a certain file in a certain directory, you can change to that directory and often do a 'make clean' 'make' in that specific directory. If I get a buildworld failure, I will re-sup and do the above to see if my problem cleared up before I spend all that time waiting for 'make world' to work its way into the problematic directory. Also, if I can't figure it out, my post to -stable would have a subject like make world dies in ./libexec/telnetd. This way if a commiter just MFCed a change to telnetd, she can spot your error message quickly and investigate. These are just a couple tips to round out your self proclaimed lack of experience. HTH! Jason C. Wells To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: installworld failure
On Wed, 3 Apr 2002, Bryan Berch wrote: Alex wrote: On Wed, 3 Apr 2002, Bryan Berch wrote: I am getting the same error messages when doing make installworld, but I have the right lines in /etc/master.passwd and /etc/group from previous mergemaster. Is there something else I should try? Try deleting the entries and then use pw to put them back. Worked for me. I tried deleting the entries and using pw to put them back in, but get told that they already exist. Then I tried using pw to delete them and it tells me they do not exist. Is there another way to get the system to recognize the smmsp and mailnull? Did you use 'vipw' to edit your passwd databases? You must use 'vipw' to edit the passwd database to be sure that the shadow passwd database is updated. If not, there is also something like 'pw_mkdb' to update your databases. Later, Jason C. Wells To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Modules System (Was: Panic on 'kldunload snd')
On Thu, 4 Apr 2002, Andrew Boothman wrote: Chris BeHanna wrote: However, I was (slightly) less pleased to discover that a consequent 'kldunload snd' paniced the kernel. This is on a (cvsuped last night) -STABLE box. Do you, perchance, have sound compiled into your kernel? There was a bug with kldload and kldunload when loading and unloading a module that was already compiled into the kernel, that would manifest itself as a panic when you tried the kldunload (usually when you were rebooting, which is how I tripped over it). No actually. I was doing this using the stock GENERIC, which contains no sound support I think I'm a little confused as to the current state of the kernel modules system. I mean do people out there have systems will very small kernel files and loads of *_load=YES statements in their /boot/loader.conf? This would seem to be possible, but I've never heard of anybody actually doing it. I'm sure there's someone out there who does it that way. I usually build a custom kernel with support for the stuff that I need, although I think from time to time that I should try a stripped down kernel to see how well the automagically-load-what's-needed-when-it's-needed code works. Is it just the dependancies between modules that are a bit of a problem, or is the whole system not quite ready for the light of day in a production environment? (I say this because I notice that there is no documentation on the modules system anywhere in the doc tree other than the developer's handbook.) It may well be that you've just tickled a bug that's heretofore gone unnoticed. Not too many people kldload their sound modules (from what I've seen on -stable), and fewer still kldunload them on a lark, I'd imagine. I'm not saying what you did is wrong; it's just uncommon (and worthy of a PR). FWIW, I have compiled a custom kernel, but I've also kldloaded a few things: behanna@topperwein kldstat Id Refs AddressSize Name 19 0xc010 31e310 kernel 31 0xc0423000 550c vesa.ko 41 0xc1765000 7000 linprocfs.ko 51 0xc17e3000 4000 logo_saver.ko 61 0xc17e8000 15000linux.ko 81 0xc1831000 2000 rtc.ko 91 0xc1823000 9000 agp.ko 101 0xc18a9000 d000 gamma.ko 111 0xc18bc000 13000radeon.ko (Despite entries 9-11, no, I don't yet have DRI working. :-/ I still have to follow the instructions on the FreeBSD DRI webpage to apply all of the patches and give it a whirl.). -- Chris BeHanna Software Engineer (Remove bogus before responding.) [EMAIL PROTECTED] I was raised by a pack of wild corn dogs. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: HEADS UP: sendmail 8.12.2 MFC'ed
Hi, One of the neat things I like about 8.12.2 are the milter facilities. Just wondering if http://www.sendmail.org/~ca/email/patches/milter.c.8.188.p could / would be committed to FreeBSD at some point ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
make buildworld broken at fortune
I am trying to do a make buildworld, and it keeps crapping out while making boot strap tools, something about rcsfreeze. I have had this problem for 2 weeks or so, so I highly doubt it's a tree issue. For those of you playing at home, I am the one who had problems with bsd-make recently. Details are at [http://www.theapt.org/fortune.html]. (I've already deleted /usr/src and re-cvsup'd, so I know it's not a bad cvs merge) Any help would be great. -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: HEADS UP: sendmail 8.12.2 MFC'ed
mike One of the neat things I like about 8.12.2 are the milter mike facilities. Just wondering if mike http://www.sendmail.org/~ca/email/patches/milter.c.8.188.p mike could / would be committed to FreeBSD at some point ? We are prepping 8.12.3 for release (which includes the patch). It will be imported into FereBSD shortly after release. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: HEADS UP: sendmail 8.12.2 MFC'ed
gshapiro We are prepping 8.12.3 for release (which includes the patch). gshapiro It will be imported into FereBSD shortly after release. After importing it into FereBSD, I'll import it into FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
