How do I determine if ipv6 is enabled?
Is there a sysctl variable, or a quick method to determine if ipv6 is enabled in the kernel? e.g. How do I test for the prescence of ipv6 in a script or at the commandline? Thanks, Billy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BIND vs. mac_portacl
On Tue, Jul 05, 2005 at 12:17:40AM +0200, K?vesd?n G?bor wrote: The bind user has the uid 55. I've added a rule for it, as You can see, but it doesn't help. I get this error with the ruleset can be seen above, and also without any rules. But apache works. It can change to the www user. Proftpd can change to the proftpd user. BIND is the only one that doesn't work. What's wrong? The portrange stuff doesn't work for IPv6 sockets at the moment, and I suspect that BIND is trying to bind to some IPv6 ports (or maybe to the IPv6 wildcard port, which can cover the IPv4 addresses too). I'm planning to fix the portrange stuff soon, but just haven't had time yet - I'll try to get to it by the end of the week. If you don't actually want to use IPv6, you could give explicit addresses to named using the listen-on and query-source directives. Alternatively, a kernel without IPv6 might work. David. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How do I determine if ipv6 is enabled?
On Tue, Jul 05, 2005 at 01:17:41AM -0500, Billy Newsom wrote: Is there a sysctl variable, or a quick method to determine if ipv6 is enabled in the kernel? e.g. How do I test for the prescence of ipv6 in a script or at the commandline? You could check for the existance of the net.inet6 sysctl tree. If IPv6 is present then sysctl net.inet6 will return true, otherwise it will return an error. (Note, that this doesn't mean that IPv6 has been configured, just that the kernel supports it.) David. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel: bge0: watchdog timeout -- resetting
Hi Ever since i upgraded to 5.4-RELEASE-p3 i get these entries in /var/log/messages once in a while : kernel: bge0: watchdog timeout -- resetting Shall i worry? ;) U. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How do I determine if ipv6 is enabled?
On Tue, Jul 05, 2005 at 01:17:41AM -0500, Billy Newsom wrote: Is there a sysctl variable, or a quick method to determine if ipv6 is enabled in the kernel? e.g. How do I test for the prescence of ipv6 in a script or at the commandline? You could use ifconfig together with the loopback interface (or any other network interface): ifconfig lo0 inet6 This will return true or false, depending on the ipv6 protocol support. Simple for shell scripting. Bruce Nikkel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: bge0: watchdog timeout -- resetting
I've only ever had that message, on network cards that were about to die. Uzi Klein wrote: Hi Ever since i upgraded to 5.4-RELEASE-p3 i get these entries in /var/log/messages once in a while : kernel: bge0: watchdog timeout -- resetting Shall i worry? ;) U. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: bge0: watchdog timeout -- resetting
Chris Phillips wrote: I've only ever had that message, on network cards that were about to die. The machine is a new HP DL380-G4 I doubt the card is dying (even tho its the easy way out for me) Uzi Klein wrote: Hi Ever since i upgraded to 5.4-RELEASE-p3 i get these entries in /var/log/messages once in a while : kernel: bge0: watchdog timeout -- resetting Sorry, attached my kernel config and dmesg www# uname -v FreeBSD 5.4-RELEASE-p3 #1: Fri Jul 1 22:35:49 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DL380 U. machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident DL380 # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. options SMP # Multi-Processor options SCHED_4BSD # 4BSD scheduler options INET# InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev #optionsAHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. #optionsAHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic# I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa #device eisa device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata #device atadisk # ATA disk drives #device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #device ahd # AHA39320/29320 and onboard AIC79xx devices #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD device pass# Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss# Compaq Smart RAID 5* #device dpt # DPT
Re: kernel: bge0: watchdog timeout -- resetting
Uzi Klein a écrit : Chris Phillips wrote: I've only ever had that message, on network cards that were about to die. The machine is a new HP DL380-G4 I doubt the card is dying (even tho its the easy way out for me) we have 3 HP DL380-G4 with FreeBSD 5.4-RELEASE-p3 and I never seen this message on them. On DL380-G4, there is 2 bge cards, have you tried bge1 for seeing if you have the same symptom ? Uzi Klein wrote: Hi Ever since i upgraded to 5.4-RELEASE-p3 i get these entries in /var/log/messages once in a while : kernel: bge0: watchdog timeout -- resetting Sorry, attached my kernel config and dmesg www# uname -v FreeBSD 5.4-RELEASE-p3 #1: Fri Jul 1 22:35:49 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DL380 U. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: geom nudge
on 01.07.2005 20:13 Poul-Henning Kamp said the following: In message [EMAIL PROTECTED], Andriy Gapon writes: I am actually OK with such situation. The problem is that the only device created is obviously da0 i.e. there are no devices for slices present on medium. So, when the card reader comes to senses I would like to give a nudge to geom to re-scan or re-create da0. true /dev/da0 will do it. Thank you very much. So, it is opening for write that actually does it ? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-p3 and bind9: isc_mutex_init failed in new_adbfind / exited on signal 11
Hi, You (Mark Andrews) wrote: FreeBSD's pthread_mutex_init() (isc_mutext_init()) can fail if there is no memory. On most other OS this is not the case. The callers to isc_mutext_init() assume that a failure is due to a double initialision and as a result log a error message when it fails. Memory allocation failures on the other hand are not logged. Thanks for your reply. I think I have found the reason. I have configured datasize value lower than max-cache-size. Obviously this makes no sense. Now I am waiting if it runs stable again. bye, Andy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BIND vs. mac_portacl
David Malone wrote: If you don't actually want to use IPv6, you could give explicit addresses to named using the listen-on and query-source directives. Alternatively, a kernel without IPv6 might work. I don't have IPv6 support in the kernel. Anyway, I tried to set those directives in named.conf, but I got the same error. Cheers, Gábor Kövesdán ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ndisgen intended to be the only way to generate ndis?
Hi all, as you probably have noticed, the amount of mails about problems with compiling ndis has increased in the last four weeks. The old way to compile ndis was to go to /usr/src/sys/modules/if_ndis/, use ndiscvt to create a header file containing the windows driver and to make;make install. It was fast and well documented in the handbook and on the web in general. Later Bill Paul wrote /usr/sbin/ndisgen to automate these steps. ndisgen is an interactive shell script, it is user friendly and describes what it's doing. However, using it is slower than the old way was. You can't use shell auto completion to specify the location of the drivers sys and inf files, some steps are done, even if they aren't needed each time you recompile ndis. ATM the existence of ndisgen is poorly documented. It's not mentioned in the handbook, not in the man pages and seldom appears on other websites. If you don't read the mailing lists or the cvs logs, you probably won't know about it. For a while the new and the old way coexisted, everybody was happy. Since perhaps four weeks, the old way stopped working for many (all?) people. You can still build and kldload the needed modules without error, but they will not work. Most of the time (every time?) ndisgen still does. AFAIK, nobody has announced that the old way is death, therefore I would like to know if the breakage is intentional and if it is, if there's a technical reason why these methods can no longer coexists. Mark A-J. Raught wrote on freebsd-mobile yesterday: I prefer the old way, but as long as it works I'll suffer through the wizard feel. So do I, I guess we're not alone. Fabian -- http://www.fabiankeil.de/ pgpjdKg9wEYXe.pgp Description: PGP signature
Re: geom nudge
In message [EMAIL PROTECTED], Andriy Gapon writes: on 01.07.2005 20:13 Poul-Henning Kamp said the following: In message [EMAIL PROTECTED], Andriy Gapon writes: I am actually OK with such situation. The problem is that the only device created is obviously da0 i.e. there are no devices for slices present on medium. So, when the card reader comes to senses I would like to give a nudge to geom to re-scan or re-create da0. true /dev/da0 will do it. Thank you very much. So, it is opening for write that actually does it ? Well, technically it is last close for write that does it but yes. Since a write could have modified the metadata on the device, the last close for write will trigger a tasting. -- 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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: bge0: watchdog timeout -- resetting
On Jul 5, 2005, at 4:02 AM, Uzi Klein wrote: Hi Ever since i upgraded to 5.4-RELEASE-p3 i get these entries in /var/ log/messages once in a while : kernel: bge0: watchdog timeout -- resetting Shall i worry? ;) Yes, worry. I had that on my Tyan S2881 motherboard onboard NICs. System would lock up all the time. I finally just replaced with intel NIC card and all has been well for several months since. Vivek Khera, Ph.D. +1-301-869-4449 x806
Re: panic in RELENG_5 UMA - two new stack traces
Gleb Smirnoff wrote: G How often does it crash? Does debug.mpsafenet=0 increases stability? G G I can reproduce the crash within 60 seconds of firing off 30+ ping/arp G -d scripts, all running in parallel. G G debug.mpsafenet=0 seems to have solved the problem. I'm running 100+ G instances of the above script and the system has been stable for over an G hour. Thanks! We definitely see that the bug is a race, not a broken logic. I am almost sure, that you are experiencing the same bug as I described in the beginning of the thread. Although there is no yet fix available for race between 'arp -d' and outgoing packet, there is one for race between incoming ARP reply and outgoing packet. We will probably commit it soon, after more review. Sorry to say, but it looks like debug.mpsafenet=0 reduced the frequency of the problem, but did not eliminate it. The system crashed and hung again over the weekend with very little load. There was no kernel panic, so no core files. I can leave 5.4 on this system for a week or so before installing 4.11, if you want me to continue doing diagnostics on it. Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
APIC problems on FreeBSD/amd64 panic: Can't find ExtINT pin to route through!
Hi John, From my console: FreeBSD 5.4-RELEASE-p2 #2: Wed Jul 6 00:01:31 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MASTER Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Opteron(tm) Processor 248 (2193.76-MHz K8-class CPU) Origin = AuthenticAMD Id = 0xf5a Stepping = 10 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 AMD Features=0xe0500800SYSCALL,NX,MMX+,LM,3DNow+,3DNow real memory = 2146893824 (2047 MB) avail memory = 2061148160 (1965 MB) ACPI APIC Table: PTLTD APIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 0.0 irqs 0-0 on motherboard ioapic1 Version 1.1 irqs 1-4 on motherboard panic: Can't find ExtINT pin to route through! cpuid = 0 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort I was discussing this with peter on chat: peter anders: what OS release? peter: FreeBSD/amd64, RELENG_5_4. peter anders: this is sounding like irq0 / 5.x problems peter ahh peter anders: bug jhb to mfc the fixes for this. Its a known problem and already fixed. peter panic: Can't find ExtINT pin to route through! peter in other words, the routing of irq0 is fubar. peter a mfc of the apic timer code would 99.99% likely solve it just like that. peter: Mind you I am using RELENG_5_4, not RELENG_5. peter anders: FreeBSD is the only known OS on the planet that uses irq0 for a clock source in SMP mode. Hence we are the people who find all the problems in the untested bios code and hardware. Hence we switched from the irq0 timer to local apic timer to do it like everybody else It happens with FreeBSD/amd64 running RELENG_5_4 using options SMP. I can boot if I set hint.acpi.0.disabled=1, but then the OS does not do SMP and apic things etc. Do you have a patch to fix this? Will you MFC it? PS: I am using a Sun Fire V20z system with the latest firmware/BIOS: master $ inventory get software Name Revision Install Date Description BIOS-V20z V1.32.7.2 Sat Jun 25 06:15:08 2005 Platform BIOS for V20z servers Operator Panel X1.0.1.0 Wed Mar 30 16:59:59 2005 Operator Panel Firmware PPCBootV2.1.0.16 Sat Jun 25 06:07:30 2005 PPCBoot Software SP Value-Add V2.2.0.18 Sat Jun 25 06:08:02 2005 SP Value-Add Software SP BaseV2.2.0.18 Sat Jun 25 06:08:02 2005 SP Base Software Cheers, -- Anders. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 4.x - SATA problems ... ?
Recently, I added a new server to our network, using the 3Ware RAID controller (the 9500S-4LP card) and 3x140G SATA drives ... overall, the system works, but I'm getting a very odd behaviour that I've never seen before ... I have a process that run an rsync from another server to 'duplicate' the VPSs ... a 'live backup' sort of thing ... this is running on all our servers, without incident, *except*, it appears, the SATA server ... I had disabled it for a time, and just re-enabled it this morning, and somehow or another, it seems to be causing file system corruption ... As most 'old timers' here know, we use UNIONFS on all our servers ... when the corruption occurs, it looks like the directory structures are being changed ... this one is hard to explain :( For example, /usr/local/cyrus/bin has a bunch of binaries in it ... the binaries are kept on the lower layer, so the upper layer only has a /usr/local/cyrus/bin directory created/ghosted, but no copies of the binaries ... so, when you are in the VPS, and do an ls of that directory, you see: # ls /usr/local/cyrus/bin arbitroncyr_expire lmtpd notifyd smmapd chk_cyrus cyrdump masssievec pop3d squatter ctl_cyrusdb deliver master pop3proxyd timsieved ctl_deliver fud mbexamine quota tls_prune ctl_mboxlistimapd mbpath reconstruct cvt_cyrusdb ipurge mkimap sievec When the 'corruption' happens, those all disappear, almost as if someone did a 'rm -rf' of the directory within the VPS, and then a 'mkdir' ... except that, from what I've been able to tell, this only happens randomly, it happens on any of the VPSs *and* only around the time that the rsync process is running ... As if, somehow, the rsync is taxing the system and causing bad writes ... but I can't find anything anywhere to indicate a problem ... To fix things, I umount the UNIONFS layer, and then do a 'find / cpio' to copy the top layer back over to fix the directory structure itself ... The thing is, I don't even know *where* to begin debugging this issue, since there aren't any errors being reported anywhere ... but maybe someone out there has an idea? thanks ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic: don't do that ... while unloading snd_ich.ko
Readily reproducable, 5.4-STABLE as of last week. Kernel messages prior to panic (from memory): pcm0: unregister: mixer busy WARNING: Driver mistake: destroy_dev on 30/3 Backtrace: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. #0 0xc04ea796 in doadump () at pcpu.h:160 160 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) bt #0 0xc04ea796 in doadump () at pcpu.h:160 #1 0xc04eacc0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:413 #2 0xc04eaf54 in poweroff_wait (junk=0xc067dd2a, howto=-1066935045) at /usr/src/sys/kern/ker #3 0xc04c455a in idestroy_dev (dev=0xc337e190) at /usr/src/sys/kern/kern_conf.c:563 #4 0xc04c4684 in destroy_dev (dev=0xc06d3428) at /usr/src/sys/kern/kern_conf.c:612 #5 0xc07a0f6c in ?? () #6 0xc06d3428 in devt_stash () #7 0xc2379980 in ?? () #8 0xc2379980 in ?? () #9 0xc2324200 in ?? () #10 0xe96c2c18 in ?? () #11 0xc07b0d7e in ?? () #12 0xc2379980 in ?? () #13 0xc2379980 in ?? () #14 0xc2379980 in ?? () #15 0xe96c2c30 in ?? () #16 0xc04feb37 in device_detach (dev=0xc23b65e0) at /usr/src/sys/kern/subr_bus.c:2301 Previous frame inner to this frame (corrupt stack?) -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpHeBuBxl3zW.pgp Description: PGP signature
Re: aac support for Adaptec 2020SA ZCR
Scott Long wrote: The 2020 seems to be in a pre-release phase just for SuperMicro. It's not mentioned at all on the Adaptec website. I've been in contact with Adaptec engineers who are preparing updates for the FreeBSD driver for it, but it's looking unlikely that they will be done in time for the 5.4 release. any news on support for the 2020SA ZCR in FreeBSD 5? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic: don't do that ... while unloading snd_ich.ko
On Wednesday, 6 July 2005 at 2:31:37 +0200, Michael Nottebrock wrote: Readily reproducable, 5.4-STABLE as of last week. Kernel messages prior to panic (from memory): pcm0: unregister: mixer busy WARNING: Driver mistake: destroy_dev on 30/3 This is a phkism. It's supposed to tell the developer to fix his code. You'll have to look at the code and work out what's wrong. I don't understand how this could get into STABLE, though. Greg -- The virus contained in this message was detected by LEMIS anti-virus. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgpzFC5XvAOgs.pgp Description: PGP signature
Re: ndisgen intended to be the only way to generate ndis?
On Tue, 5 Jul 2005 22:49, Fabian Keil wrote: AFAIK, nobody has announced that the old way is death, therefore I would like to know if the breakage is intentional and if it is, if there's a technical reason why these methods can no longer coexists. The old way built the .sys and .inf files into a .ko along with if_ndis code. In the new way you build the .sys and .inf files into a .ko without any other code. When you load it, it pulls in if_ndis which then reads the wrapped .sys and .inf file you loaded. You can't build things the old way any more because the if_ndis code no longer expects to be linked to a .sys file. I suggest the best approach would be to submit improved documentation for the ndiscvt man page (and a new ndisgen page) along with some handbook changes. It would also be fairly trivial to modify ndisgen to take some arguments. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpUP1XJOVWTv.pgp Description: PGP signature
Re: Panic: don't do that ... while unloading snd_ich.ko
On Wed, 6 Jul 2005 10:16:59 +0930 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: On Wednesday, 6 July 2005 at 2:31:37 +0200, Michael Nottebrock wrote: Readily reproducable, 5.4-STABLE as of last week. Kernel messages prior to panic (from memory): pcm0: unregister: mixer busy WARNING: Driver mistake: destroy_dev on 30/3 This is a phkism. It's supposed to tell the developer to fix his code. You'll have to look at the code and work out what's wrong. I don't understand how this could get into STABLE, though. Greg It's a long standing sound driver unloading routine bug, not really phkism. http://staff.mybsd.org.my/skywizard/FreeBSD/sound/RELENG_5/pcm/mixer.c.diff http://staff.mybsd.org.my/skywizard/FreeBSD/sound/RELENG_5/pcm/sound.c.diff http://staff.mybsd.org.my/skywizard/FreeBSD/sound/RELENG_5/pcm/dsp.c.diff will solve the problem. -- Ariff Abdullah MyBSD http://www.MyBSD.org.my (IPv6/IPv4) http://staff.MyBSD.org.my (IPv6/IPv4) http://tomoyo.MyBSD.org.my (IPv6/IPv4) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic: don't do that ... while unloading snd_ich.ko
On Wed, 6 Jul 2005 11:42:41 +0800 Ariff Abdullah [EMAIL PROTECTED] wrote: On Wed, 6 Jul 2005 10:16:59 +0930 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: On Wednesday, 6 July 2005 at 2:31:37 +0200, Michael Nottebrock wrote: Readily reproducable, 5.4-STABLE as of last week. Kernel messages prior to panic (from memory): pcm0: unregister: mixer busy WARNING: Driver mistake: destroy_dev on 30/3 This is a phkism. It's supposed to tell the developer to fix his code. You'll have to look at the code and work out what's wrong. I don't understand how this could get into STABLE, though. Greg It's a long standing sound driver unloading routine bug, not really phkism. http://staff.mybsd.org.my/skywizard/FreeBSD/sound/RELENG_5/pcm/mixer.c.diff http://staff.mybsd.org.my/skywizard/FreeBSD/sound/RELENG_5/pcm/sound.c.diff http://staff.mybsd.org.my/skywizard/FreeBSD/sound/RELENG_5/pcm/dsp.c.diff will solve the problem. Ah.. sorry. Greg was right. *It's supposed to tell the developer to fix the driver code*. -- Ariff Abdullah MyBSD http://www.MyBSD.org.my (IPv6/IPv4) http://staff.MyBSD.org.my (IPv6/IPv4) http://tomoyo.MyBSD.org.my (IPv6/IPv4) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
network resquest to tap pseudo device driver
Hi, Can anybody tell me what benefit for building a tap pseudo ethernet device driver for some sort of network communication? Why not directly communicate thru a real ethernet device driver like fxp0, xl0, etc. Thanks Sam Sell on Yahoo! Auctions no fees. Bid on great items. http://auctions.yahoo.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
