Re: default dns config change causing major poolpah
Poul-Henning Kamp wrote: That said, I fully agree with the spirit of this change, I have myself seen what positive difference it makes for servers in Denmark to have a slave of the .dk zone, particular for busy mailservers. One of the other objections I have with this change (other than the fact that it was made w/o consultation) is the fact that this is would become the default setting. Yes, busy mail servers may be better served by slaving frequently used zones, and as Vixie mentioned on the dns-operations list, there is less objection if wizards use AXFR, and they would perhaps know more of the pitfalls that doing this entails (vs. relying on hints). But the fact is this is being enabled for every Tom, Dick, and Sarah operating a OS who won't know what the possible ramifications are of this change, and the benefit compared to the downside is nonexistant. And that is *BAD, BAD, BAD*. Has this change been raised on the relevant IETF DNS operations list? These are the defaults we are talking about here. I will reiterate, this change needs to be rolled back until there has been more discussion. dbarton mentioned earlier that root operators make changes on a glacial scale. There is a reason for that. ;) Best Wishes - Peter -- [EMAIL PROTECTED] | ISC | OpenPGP 0xE8048D08 | The bits must flow signature.asc Description: OpenPGP digital signature
Re: default dns config change causing major poolpah
Doug Barton wrote: Here is where the problem lies. What you're saying here is simply not true. I know several of the root operators personally, and in my previous position as GM of IANA I worked with them directly both individually and collectively. Everything involving a change to a root server is done at a near-glacial pace. There no more danger that we will wake up tomorrow unable to AXFR the root from any server than there is that we'll wake up tomorrow not able to send resolver queries to any root server. To say that this IS possible is FUD. Doug - that is a *BIG* assumption you just made there. As far as I know you didn't discuss this change with any of the root server operators (you certainly didn't with ISC) and we could have told you then how bad of a idea this was. It seems you made this change on instinct, and in addition nowhere does it state in RFC2870 that the root-servers have to accept AXFR's as part of their service. You just made with this change what was before a diagnostic service into a production service and you didn't even ask the folks most affected by it. This change should be yanked and yanked now until at least there has been some discussion with the root server operators. (and discussing it on the dns-operations@ list does not cut it) -Peter (with his root-ops hat on his desk) -- [EMAIL PROTECTED] | ISC | OpenPGP 0xE8048D08 | The bits must flow signature.asc Description: OpenPGP digital signature
rc.d scripts not honoring rc_conf_files setting in /etc/rc.conf?
Hi, Testing out decentralizing rc.conf and breaking it out into two components on a 6.2-RELEASE system: /etc/rc.conf.default- Settings that are standard across all systems (daemons, etc) /etc/rc.conf.local - Settings that are local to the system (network settings, etc) In /etc/rc.conf, all I have is: rc_conf_files=/etc/rc.conf /etc/rc.conf.default /etc/rc.conf.local Which I took as read in these rc.conf files in descending order to populate your variables When I restarted the system, my rc.d (ntpd, openssh) scripts which were looking for rc.conf variables in /etc/rc.conf.default failed to read in that file. It wasn't until I added /etc/rc.conf.default to rc_conf_files in /etc/defaults/rc.conf was it able to read in that file at boottime and in this case start the daemon(s). Is this how it's supposed to work? (I suspect not if I have to hack /etc/default/rc.conf) If not, can it be fixed? (or if I am assuming incorrectly, can someone enlighten me on how it should work?) :) Thanks - Peter -- [ http://www.plosh.net/ ] - Earth Halted: Please reboot to continue ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
IPv6+dummynet causing panic on 6.2-RELEASE
We have been having rampant issues using Dummynet's IPv6 support, and it's been causing panic's every 24-48 hours. Enabled WITNESS and BREAK_TO_DEBUGGER, and this is the result. -=- lock order reversal: (sleepable after non-sleepable) 1st 0xff034809c900 rtentry (rtentry) @ /usr/src/sys/netinet6/ip6_input.c:501 2nd 0x808dda70 user map (user map) @ /usr/src/sys/vm/vm_map.c:3074 KDB: stack backtrace: witness_checkorder() at witness_checkorder+0x48a _sx_xlock() at _sx_xlock+0x3e vm_map_lookup() at vm_map_lookup+0x44 vm_fault() at vm_fault+0xba trap_pfault() at trap_pfault+0x13c trap() at trap+0x1bd calltrap() at calltrap+0x5 --- trap 0xc, rip = 0x804c41f7, rsp = 0xbdf0da60, rbp = 0xbdf0daf0 --- ip6_input() at ip6_input+0xa07 dummynet_send() at dummynet_send+0x17e dummynet() at dummynet+0x21a softclock() at softclock+0x19a ithread_loop() at ithread_loop+0x132 fork_exit() at fork_exit+0x87 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xbdf0dd00, rbp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 06 fault virtual address = 0x98 fault code = supervisor read, page not present instruction pointer = 0x8:0x804c41f7 stack pointer = 0x10:0xbdf0da60 frame pointer = 0x10:0xbdf0daf0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 15 (swi4: clock sio) [thread pid 15 tid 19 ] Stopped at ip6_input+0xa07:movq0x98(%rdi),%rax db tr Tracing pid 15 tid 19 td 0xff040ff3b000 ip6_input() at ip6_input+0xa07 dummynet_send() at dummynet_send+0x17e dummynet() at dummynet+0x21a softclock() at softclock+0x19a ithread_loop() at ithread_loop+0x132 fork_exit() at fork_exit+0x87 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xbdf0dd00, rbp = 0 --- -=- Any ideas how to proceed? Best Wishes - Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
'panic: bad pte' error on 6.2-RELEASE (amd64)
We recently updated one of our dual Opteron systems (w/ 4GB RAM) from 5.5 to 6.2 (amd64 wipe and reinstalled) and about once a week, it panics with the below message: -=- TPTE at 0x840028a0 IS ZERO @ VA 800514000 panic: bad pte cpuid = 2 KDB: stack backtrace: panic() at 0x803fdd03 = panic+0x253 pmap_remove_pages() at 0x806072a3 = pmap_remove_pages+0x283 exec_new_vmspace() at 0x803e18e6 = exec_new_vmspace+0x216 exec_elf64_imgact() at 0x803cbb73 = exec_elf64_imgact+0x273 kern_execve() at 0x803e2107 = kern_execve+0x457 execve() at 0x803e2bed = execve+0x5d syscall() at 0x8060d141 = syscall+0x4d1 Xfast_syscall() at 0x805f8128 = Xfast_syscall+0xa8 --- syscall (59, FreeBSD ELF64, execve), rip = 0x80069838c, rsp = 0x7fffe7c8, rbp = 0x7fffecd0 --- Uptime: 4d16h55m46s -=- I do have a dump, and can make that available if need be. Has anyone encountered this recently and can shed any light on what might be causing this? Best Wishes - Peter signature.asc Description: OpenPGP digital signature
New IPv6 LOR in 6.2-RELEASE
FYI: saw this when upgrading one of my boxes (quad-cpu Opteron, 2GB of RAM) to 6.2-RELEASE: Firewall logging enabled net.inet.ip.fw.enable: 1 - 1 lock order reversal: 1st 0xff00b79c3cc8 inp (raw6inp) @ /usr/src/sys/netinet6/raw_ip6.c:153 2nd 0xff00b79c3df8 inp (rawinp) @ /usr/src/sys/netinet6/raw_ip6.c:153 KDB: stack backtrace: witness_checkorder() at 0x8042a12a = witness_checkorder+0x4da _mtx_lock_flags() at 0x803f4e3c = _mtx_lock_flags+0x5c rip6_input() at 0x804ed15e = rip6_input+0x9e ip6_input() at 0x804dd288 = ip6_input+0x838 netisr_processqueue() at 0x80489a07 = netisr_processqueue+0x17 swi_net() at 0x80489cf6 = swi_net+0x116 ithread_loop() at 0x803e6f5c = ithread_loop+0x14c fork_exit() at 0x803e5cab = fork_exit+0xbb fork_trampoline() at 0x805f82ee = fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xb3a43d00, rbp = 0 --- Mounting NFS file systems:. Limiting icmp unreach response from 262 to 200 packets/sec Expensive timeout(9) function: 0x80ba8da0(0) 0.069698243 s -Peter -- [ http://www.plosh.net/ ] - Earth Halted: Please reboot to continue ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
BTX issues when booting from a USB CD-ROM
I have a Matushita based USB CD/DVD-ROM drive that I have been using to install FreeBSD with for the better part of the last year. I just took delivery yesterday of both a HP Proliant 1450 G3 and a generic 1U server based on a Tyan Tomcat i845GV S3098 MB. In both cases, once the USB CD-ROM started loading either 6.1 or 6.2, I get a BTX halt: -=- from CD : CD Loader 1.2 Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.01 Consoles: internal video/keyboard int=000d err= efl=00030206 eip=37d0 eax=8001 ebx= ecx=a391 edx=009f esi=0b32 edi= ebp= esp=03d2 cs=f000 ds=3eca es=3eacfs= gs= ss=97fc cs:eip=2e 0f 01 16 f8 38 0f 20-c0 0c 01 0f 22 c0 b8 30 00 8e c0 0f 20 c0 24 fe-0f 22 c0 eb 00 66 58 c3 ss:esp=01 80 00 00 db 36 00 00-00 00 32 0b 00 00 00 00 00 00 f8 03 00 00 00 00-00 00 9f 00 00 00 01 00 BTX halted -=- Opening up the cases and plugging in a EIDE CD-ROM, the installer CD's work just fine. So it looks like perhaps there is some new BIOS instruction set that's causing the BTX loader some pain with a USB device. Anyone encounter similar issues recently? Best Wishes - Peter -- [EMAIL PROTECTED] | ISC | OpenPGP 0xE8048D08 | The bits must flow signature.asc Description: OpenPGP digital signature
Re: 'make release' questions...
Andrew Li wrote: First, is there any way to instruct 'make release' to just build certain packages (and their dependencies) for inclusion in the release instead of a blanket NOPORTS? There's no need for us spend two/three days From my experience with playing with make release, you can do it. First build your packages with make package or pkg_create to get a package tarball. Then put the packages into your_path/release/R/cdrom/disc1 into a directory call packages. Create the package directory structure, like packages/All, packages/your_package_category, ... O.k. did that (and generated a new INDEX file using scrubindex.pl) However in sysinstall, after selecting the packages and selecting Install it remarks that: This is disc 1. Package $package_name is on Disc 0. Would you like to switch discs now? Disk 0? After that, modify the INDEX file so it only contain your packages (plus dependencies). Then run mkisomages.sh to create your ISO. So I have used scrubindex.pl to generate a INDEX of just our packages, however, I have to generate a new master INDEX-6 file to account for the fact that we build our packages w/o x11 support and with GSSAPI. (so scrubindex.pl can then strip the rest out) However after a 'make index' things like mtr-nox11 are included into INDEX-6, but not openssh-gssapi? The only difference is that the -gssapi moniker is declared as a GSSAPI_SUFFIX make varaible vs. the normal PKGNAMESUFFIX. I'll send a version of this email to ports@ to get their input. That's all from memory, may contain rough edges, hope it helps anyway. Thanks... The base release is done, it's just the pesky frills that take forever to resolve... :) Best Wishes - Peter signature.asc Description: OpenPGP digital signature
make rerelease broken at camcontrol...
Thanks to all who answered my 'make release' questions; now that I have done the initial release cut, now I am trying out 'make rerelease', and it's bombing at the stage 4.4: building everything stage. -=- === sbin/camcontrol (all) cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -o camcontrol camcontrol.o util.o modeedit.o -lcam -lsbuf modeedit.o(.text+0xd14): In function `mode_edit': : undefined reference to `mode_sense' modeedit.o(.text+0xd5c): In function `mode_edit': : undefined reference to `mode_sense' modeedit.o(.text+0xdf9): In function `mode_edit': : undefined reference to `mode_sense' modeedit.o(.text+0xe86): In function `mode_edit': : undefined reference to `mode_select' modeedit.o(.text+0xebf): In function `mode_edit': : undefined reference to `mode_sense' modeedit.o(.text+0x11ec): In function `mode_list': : undefined reference to `mode_sense' *** Error code 1 Stop in /usr/src/sbin/camcontrol. *** Error code 1 Stop in /usr/src/sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. + exit 1 + umount /dev *** Error code 1 (ignored) -=- Looking in CVS; modeedit.c hasn't changed in two years, so I am perplexed at what is going on here. Any ideas? The make rerelease command used is: make -i rerelease NODOC=YES NO_FLOPPIES=YES CHROOTDIR=/hog/release \ BUILDNAME=6.1-RELEASE-p2 CVSROOT=/hog/FreeBSD-CVS RELEASETAG=RELENG_6_1 (no optimizations, etc.) Thanks - Peter signature.asc Description: OpenPGP digital signature
'make release' questions...
I have been mucking about w/ 'make release' for some time now (stripping out OpenSSH, sendmail, Heimdal, bits oF BIND, etc.) and while I now have a working .iso image, that will install and update, I have some questions that 'man release' just won't answer. :) First, is there any way to instruct 'make release' to just build certain packages (and their dependencies) for inclusion in the release instead of a blanket NOPORTS? There's no need for us spend two/three days compiling all the various ports when we will only use a small handful of them on most of our boxes. (and would speed up the amount of time it takes to roll out a new release) ;) Second, is there a way to build/tell sysinstall that if NO_OPENSSH is set, that it doesn't ask you whether you want to enable SSH logins? Thanks again in advance for any advice you can provide. Best Wishes - Peter -- [ http://www.plosh.net/ ] - Earth Halted: Please reboot to continue signature.asc Description: OpenPGP digital signature
How to disable libcom_err from being built?
Hi - I have an install base of machines running MIT Krb5 (which have their own com_err implementation), and I have always used NO_KERBEROS=true so that the integrated Heimdal stuff wouldn't be built during a buildworld. However libcom_err does, and that causes issues when trying to link in programs that are linked to MIT Krb5. What I am asking is - can NO_KERBEROS be extended to cover com_err? Thanks - Peter signature.asc Description: OpenPGP digital signature
Forcing a da* numbering scheme.
Hi -
What's the proper method these days for defining a static naming scheme
for direct access devices (da*)?
In this case, I have two systems (one 5.1 and one 6.0) connected to a
read-only RAID appliance (via FibreChannel) while having two SCSI disks
onboard for the OS and applications. With the 5.4 system, the onboard
SCSI disks take up da{0,1} and the FibreChannel connected devices fall
behind it. With the 6.0 system it's the reverse, with the onboard disks
taking up the end of the line, which causes more than a little havoc w/
fstab when we add more read-only devices over FibreChannel and the boot
partition keeps moving because of it... :(
It used to be in the 4.x days you could define the da* in the kernel and
tie it to it's SCSI ID, is that still the case now, or is there some
boot-time variable in /boot/loader.conf that is now preferred?
-Peter
--
[ http://www.plosh.net/ ] - Earth Halted: Please reboot to continue
signature.asc
Description: OpenPGP digital signature
Re: IPv6 and IPFW
Hajimu UMEMOTO wrote: plosher Will this change in 6.1, or will we have to wait for ip6fw to be plosher completly removed before the module will support v6 by default? (You plosher would have to admit that it's somewhat confusing the way it is now) It was already MFC'ed into RELENG_6. So, ipfw.ko obeys the kernel config, now. Thanks, I see that now on my -STABLE boxes; is there any move to do the same for dummynet? Best Wishes - Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPv6 and IPFW
Hajimu UMEMOTO wrote: The ipfw in 6-STABLE has an IPv6 awareness, but it is not enabled as far as you use ipfw as a KLD module. If ipfw is compiled into kernel, ipfw does filterling an IPv6 as well. Will this change in 6.1, or will we have to wait for ip6fw to be completly removed before the module will support v6 by default? (You would have to admit that it's somewhat confusing the way it is now) Best Wishes - Peter signature.asc Description: OpenPGP digital signature
Panic when ifconfig'ing nge card.
We are rebuilding a system which has a Netgear GA621 (using the nge driver) installed, and which had run 5.2 5.3 pre-releases on amd64 (it's a Dual Opteron box - Tyan Thunder motherboard) We are now intending to make it a backup server and it is running 5.4-PRE/i386 (cvsupped just under 20 hours ago), and when we try to configure nge0, after coming up for around 10 seconds it panics. -=- nge0: National Semiconductor Gigabit Ethernet port 0x9800-0x98ff mem 0xfb8ff000-0xfb8f irq 29 at device 1.0 on pci1 nge0: Using TBI nge0: 1000baseSX, 1000baseSX-FDX, auto -=- -=- % ifconfig fxp0 down % ifconfig nge0 204.152.187.8 netmask 255.255.255.0 % % % % Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc055bdda stack pointer = 0x10:0xe97c9c9c frame pointer = 0x10:0xe97c9cac code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 39 (irq29: nge0) trap number = 12 panic: page fault Uptime: 21m3s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... -=- Any ideas? I have already tried turning of HTT (can't), ACPI (same effect). We can't run amd64 since we know the 3ware driver isn't 64-bit clean and locks up the system under heavy I/O load. We could just live w/ 100baseTX, but we would rather be running GigE... Best Wishes - Peter -- [EMAIL PROTECTED] | ISC | OpenPGP 0xE8048D08 | The bits must flow signature.asc Description: OpenPGP digital signature
Re: Panic when ifconfig'ing nge card.
Robert Watson wrote: The below is a NULL pointer dereference in the kernel. Off-hand, it looks very likely to be a driver bug. The question is -- where? The best way to answer this is to compile with DDB/KDB, and do a stack trace from DDB, or get a dump and do similar things with gdb. Here it is again with DDB/GDB compiled in and a stack trace: -=- Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0561e4a stack pointer = 0x10:0xe7d1bc9c frame pointer = 0x10:0xe7d1bcac code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 40 (irq29: nge0) [thread pid 40 tid 100011 ] Stopped at nge_newbuf+0x6a:movl0x8(%ebx),%ecx db trace Tracing pid 40 tid 100011 td 0xc56d9190 nge_newbuf(c5891c00,e9a49000,c5c6ec00) at nge_newbuf+0x6a nge_rxeof(c5891c00) at nge_rxeof+0x10e nge_intr(c5891c00) at nge_intr+0x15e ithread_loop(c56d2e00,e7d1bd48) at ithread_loop+0x159 fork_exit(c060571c,c56d2e00,e7d1bd48) at fork_exit+0x75 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe7d1bd7c, ebp = 0 --- -=- Best Wishes - Peter -- [EMAIL PROTECTED] | ISC | OpenPGP 0xE8048D08 | The bits must flow signature.asc Description: OpenPGP digital signature
Hard lockups using 5.3-RELEASE..
We have a Celestica dual-Opteron system w/ 4GB RAM running
5.3-RELEASE/i386 (32-bit), and a SMP-aware kernel, which is experiencing
hard lockups. Debugging results below.
-=-
[BREAK]
KDB: enter: Line break on console
[thread 100104]
Stopped at kdb_enter+0x2b: nop
db where
kdb_enter(c084e4c6) at kdb_enter+0x2b
siointr1(c507d800,c0946700,0,c084e28e,6ad) at siointr1+0xce
siointr(c507d800) at siointr+0x21
intr_execute_handlers(c4f5d490,e9826b80,4,e9826bd0,c07b2ae3) at
intr_execute_han
dlers+0x89
lapic_handle_intr(34) at lapic_handle_intr+0x2e
Xapic_isr1() at Xapic_isr1+0x33
--- interrupt, eip = 0xc0604456, esp = 0xe9826bc4, ebp = 0xe9826bd0 ---
_mtx_lock_sleep(c08f67c0,c5698640,0,c084a0b3,126) at _mtx_lock_sleep+0xc6
_mtx_lock_flags(c08f67c0,0,c084a0b3,126,c6a82738) at _mtx_lock_flags+0x48
vm_fault(c5bbd5dc,81ae000,2,8,c5698640) at vm_fault+0x1fe
trap_pfault(e9826d48,1,81ae000,81ae000,0) at trap_pfault+0xf2
trap(2f,2f,2f,2000,81ae000) at trap+0x1df
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0x2809bd8d, esp = 0xbfbfb7b0, ebp = 0xbfbfb7e8 ---
db panic
panic: from debugger
cpuid = 3
boot() called on cpu#3
Uptime: 2h50m29s
-=-
(then resetting the system causes a panic, and the system locks up for
good, and a power reset is required)
We were able to get a coredump, and the resulting kgdb output is below:
-=-
(kgdb) up
#45 0xc05f9bda in fork_exit (callout=0xc05fa5dc ithread_loop,
arg=0xc4fe7a00, frame=0xe8daed48) at ../../../kern/kern_fork.c:811
811 callout(arg, frame);
(kgdb) l
806 * cpu_set_fork_handler intercepts this function call to
807 * have this call a non-return function to stay in
kernel mode.
808 * initproc has its own fork handler, but it does return.
809 */
810 KASSERT(callout != NULL, (NULL callout in fork_exit));
811 callout(arg, frame);
812
813 /*
814 * Check if a kernel thread misbehaved and returned from
its main
815 * function.
(kgdb) down
#44 0xc05fa6e8 in ithread_loop (arg=0xc4fe7a00)
at ../../../kern/kern_intr.c:547
547 ih-ih_handler(ih-ih_argument);
(kgdb) l
542 mtx_unlock(ithd-it_lock);
543 goto restart;
544 }
545 if ((ih-ih_flags IH_MPSAFE) == 0)
546 mtx_lock(Giant);
547 ih-ih_handler(ih-ih_argument);
548 if ((ih-ih_flags IH_MPSAFE) == 0)
549 mtx_unlock(Giant);
550 }
551 if (ithd-it_enable != NULL) {
(kgdb) down
#43 0xc0615dfa in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:247
247 mtx_lock(Giant);
(kgdb) l
242 (c-c_flags
~CALLOUT_PENDING);
243 }
244 curr_callout = c;
245 mtx_unlock_spin(callout_lock);
246 if (!(c_flags CALLOUT_MPSAFE)) {
247 mtx_lock(Giant);
248 gcalls++;
249 CTR1(KTR_CALLOUT,
callout %p, c_func);
250 } else {
251 mpcalls++;
-=-
It looks like it's trying to lock Giant while it already has Giant. In
any case, we have rebuilt a uniprocessor kernel for now. If this is
already fixed in 5-STABLE, then let me know. ;)
Best Wishes - Peter
--
[EMAIL PROTECTED] | ISC | OpenPGP 0xE8048D08 | The bits must flow
signature.asc
Description: OpenPGP digital signature
Weird bge related lock order reversal...
I have a quad-Opteron box running FreeBSD 5.3-p5/i386, and it has two onboard Broadcom copper GigE NIC's (bge0 is used as a private wire, bge1 is the public interface) -=- bge0: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2003 mem 0xf114-0xf114,0xf115-0xf115 irq 31 at device 3.0 on pci14 miibus0: MII bus on bge0 bge0: Ethernet address: some mac address bge0: [GIANT-LOCKED] bge1: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2003 mem 0xf116-0xf116,0xf117-0xf117 irq 28 at device 3.1 on pci14 miibus1: MII bus on bge1 bge1: Ethernet address: some mac address bge1: [GIANT-LOCKED] -=- When booting, and just after initializing the network (configuring the NIC's for autoneg to a DLink GigE switch), console spits out this lock order reversal: -=- Starting local daemons:bge1: gigabit link up lock order reversal 1st 0xc5a65dec inp (rawinp) @ netinet/raw_ip.c:199 2nd 0xc5a65ea0 inp (raw6inp) @ netinet/raw_ip.c:199 KDB: stack backtrace: kdb_backtrace(,c08fdb48,c08fdb70,c088f47c,c09223e8) at kdb_backtrace+0x29 witness_checkorder(c5a65ea0,9,c08391f0,c7) at witness_checkorder+0x49d _mtx_lock_flags(c5a65ea0,0,c08391e7,c7) at _mtx_lock_flags+0x1e rip_input(c5461200,14,5e0,0,0) at rip_input+0x64 ip_input(c5461200) at ip_input+0x596 netisr_processqueue(c0923418) at netisr_processqueue+0x6e swi_net(0) at swi_net+0x88 ithread_loop(c4fe7a80,e7307d48,c08f6780,0,c082cc46) at ithread_loop+0x10c fork_exit(c05fa5dc,c4fe7a80,e7307d48) at fork_exit+0x66 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe7307d7c, ebp = 0 --- -=- Is this ominous? Are there any known issues w/ Broadcom NIC's running at GigE speeds? The only other oddity on this system is that we have assigned v6 addressed to vlan interfaces. (we haven't done that in the past until now) Thanks in advance for any light you can shed on this... Best Wishes - Peter -- [EMAIL PROTECTED] | ISC | OpenPGP 0xE8048D08 | The bits must flow pgp4IkjgoOaZV.pgp Description: PGP signature
Weird bge related lock order reversal...
(apologies if you get this sent twice, I sent the first one to [EMAIL PROTECTED] by mistake) I have a quad-Opteron box running FreeBSD 5.3-p5/i386, and it has two onboard Broadcom copper GigE NIC's (bge0 is used as a private wire, bge1 is the public interface) -=- bge0: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2003 mem 0xf114-0xf114,0xf115-0xf115 irq 31 at device 3.0 on pci14 miibus0: MII bus on bge0 bge0: Ethernet address: some mac address bge0: [GIANT-LOCKED] bge1: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2003 mem 0xf116-0xf116,0xf117-0xf117 irq 28 at device 3.1 on pci14 miibus1: MII bus on bge1 bge1: Ethernet address: some mac address bge1: [GIANT-LOCKED] -=- When booting, and just after initializing the network (configuring the NIC's for autoneg to a DLink GigE switch), console spits out this lock order reversal: -=- Starting local daemons:bge1: gigabit link up lock order reversal 1st 0xc5a65dec inp (rawinp) @ netinet/raw_ip.c:199 2nd 0xc5a65ea0 inp (raw6inp) @ netinet/raw_ip.c:199 KDB: stack backtrace: kdb_backtrace(,c08fdb48,c08fdb70,c088f47c,c09223e8) at kdb_backtrace+0x29 witness_checkorder(c5a65ea0,9,c08391f0,c7) at witness_checkorder+0x49d _mtx_lock_flags(c5a65ea0,0,c08391e7,c7) at _mtx_lock_flags+0x1e rip_input(c5461200,14,5e0,0,0) at rip_input+0x64 ip_input(c5461200) at ip_input+0x596 netisr_processqueue(c0923418) at netisr_processqueue+0x6e swi_net(0) at swi_net+0x88 ithread_loop(c4fe7a80,e7307d48,c08f6780,0,c082cc46) at ithread_loop+0x10c fork_exit(c05fa5dc,c4fe7a80,e7307d48) at fork_exit+0x66 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe7307d7c, ebp = 0 --- -=- Is this ominous? Are there any known issues w/ Broadcom NIC's running at GigE speeds? The only other oddity on this system is that we have assigned v6 addresses to vlan interfaces. (we haven't done that in the past until now) Thanks in advance for any light you can shed on this... Best Wishes - Peter -- [EMAIL PROTECTED] | ISC | OpenPGP 0xE8048D08 | The bits must flow pgplu2wGhGBuV.pgp Description: PGP signature
Problems w/ a TDK DVD-RW and burncd...
Hi, I purchased a TDK indiDVD ATAPI DVD-RW (model 228H) this morning, and after installing it into this system, it's detected: acd0: CD-RW DVD+RW RW5125 at ata1-slave PIO4 (FreeBSD thinking it's only a CD-RW is slightly disconcerting...) And playing CD's and burning CD-R's are no problem. But as soon as I try to burn a DVD-R it errors out: tar burncd -f /dev/cdrom data data_1.iso fixate burncd: ioctl(CDRIOCNEXTWRITEABLEADDR): Input/output error And messages throws this up: acd0: READ_TRACK_INFO - HARDWARE ERROR asc=0x09 ascq=0x02 error=0x00 acd0: TEST_UNIT_READY - HARDWARE ERROR asc=0x09 ascq=0x02 error=0x00 acd0: TEST_UNIT_READY - HARDWARE ERROR asc=0x09 ascq=0x02 error=0x00 acd0: TEST_UNIT_READY - HARDWARE ERROR asc=0x09 ascq=0x02 error=0x00 acd0: TEST_UNIT_READY - HARDWARE ERROR asc=0x09 ascq=0x02 error=0x00 acd0: TEST_UNIT_READY - HARDWARE ERROR asc=0x09 ascq=0x02 error=0x00 acd0: TEST_UNIT_READY - HARDWARE ERROR asc=0x09 ascq=0x02 error=0x00 acd0: TEST_UNIT_READY - HARDWARE ERROR asc=0x09 ascq=0x02 error=0x00 acd0: TEST_UNIT_READY - HARDWARE ERROR asc=0x09 ascq=0x02 error=0x00 acd0: TEST_UNIT_READY - HARDWARE ERROR asc=0x09 ascq=0x02 error=0x00 acd0: READ_TRACK_INFO - HARDWARE ERROR asc=0x09 ascq=0x02 error=0x00 I used to have a old SCSI CD-RW external drive in here before, but that's not an issue here. (or the CD-R wouldn't burn). Has anyone had any success with this drive? I suspect FreeBSD is just not recognizing the drive correctly (or the TDK drive isn't what it seems) Thanks - Peter -- [EMAIL PROTECTED] - [ http://www.plosh.net/ ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Opera for FreeBSD
(Apologies for the late response, but I wanted to get this answer in the archives, and I am now catching up on my -stable mail...) On Monday 04 November 2002 12:03 pm, Dave Cantrell wrote: Yeah, but if you *bought* the linux license to run under emulation, you still have to *buy* the FreeBSD license, now that they finally got it native. For me, I'm switching to konqui (KDE). A clarification, like you I have a Linux license (as well as a Windows; I really do like Opera) What I did is upgrade the license for US$15 to convert my Linux license to FreeBSD. Since I have had my Linux license for over a year, paying $15 for letting Opera know I use FreeBSD and will support Opera natively on FreeBSD is good value for money, IMO. Hopefully soon there will be a opera-sharedqt port, since I use KDE, I can take advantage of the AA support I have compiled into my QT install, and makes Opera look just as good as the rest of my KDE setup :) (I still use Konq for my IPv6 web browsing, so it still has a use) ;) Best Wishes - Peter -- [EMAIL PROTECTED] - [ http://www.plosh.net/ ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
