Re: Fetching distfiles from mirrors by default
I use this in make.conf
MASTER_SITE_OVERRIDE=ftp://freebsd.cisco.com/pub/FreeBSD/distfiles/${DIST_SUBDIR}/
to get stuff off an internal mirror
There are probably better ways to do it, but this has worked for me.
dave c
you wrote:
Hello,
I seem remember 4.7 had an option in /etc/make.conf to prefer
downloading from mirror sites (or sites matching a regex) by default. Is
there anything similar to this available in CURRENT without having to
rearrange (and most likely refuse) bsd.sites.mk?
Hmm.. using a shell script to ping and sort the file after each cvsup
might be sort of cool, but probably more trouble then it's worth. It's
only for those occasional huge distfiles where it really matters
(currently, the 77M games/vegastrike snatched from a PR.)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED])
There aren't any monkeys chasing us... - Xochi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: current SMP kernel crashes (different?)
you wrote: I think the ACPI PCI LNK code is messing up b/c with SMP we don't use LNK's. So you probably want to disable ACPI for now. Is the panic the same w/o ACPI? without ACPI the kernel hangs after the Waiting 2 seconds for SCSI devices to settle message. Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x6dbc00 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02d7383 stack pointer = 0x10:0xc06decf8 frame pointer = 0x10:0xc06ded18 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 = 0 (swapper) kernel: type 12 trap, code=0 Stopped at _mtx_lock_flags+0x43: cmpl$0xc05216c0,0(%ebx) db trace _mtx_lock_flags(6dbc00,0,c04c3c00,138,c02d767d) at _mtx_lock_flags+0x43 ithread_remove_handler(c06ded80,c06ded78,c046c427,c06ded80,0) at ithread_remove_handler+0x53 inthand_remove(c06ded80,0,c04e8e36,445,a0) at inthand_remove+0x11 cpu_initclocks(c06ded98,c02bcf75,0,6db000,6dbc00) at cpu_initclocks+0x327 initclocks(0,6db000,6dbc00,6db000,0) at initclocks+0x1c mi_startup() at mi_startup+0xb5 begin() at begin+0x2c db _mtx_lock_flags+0x43 - sys/kern/kern_mutex.c:324 ithread_remove_handler+0x53 - sys/kern/kern_intr.c:314 inthand_remove+0x11 - sys/i386/isa/intr_machdep.c:705 cpu_initclocks+0x327 - sys/i386/isa/clock.c:1096 initclocks+0x1c - sys/kern/kern_clock.c:153 mi_startup+0xb5 - sys/kern/init_main.c:217 KASSERT(m-mtx_object.lo_class == lock_class_mtx_sleep, (mtx_lock() of spin mutex %s @ %s:%d, m-mtx_object.lo_name, file, line)); It's blowing up doing that == compare, so it seems that the mutex pointer (m) (%ebx) is 0x6dbc00. (Doing a p $ebx might confirm this.) That means that the ithread might be messed up. Either that or the handler itself might be messed up. If you do a hexdump of the first argument to ithread_remove_handler() that should give you a dump of the struct intrhand, and you can then see if that looks valid, esp. the ithread pointer. If the ithread pointer is valid then you can start looking at the ithread structure via hexdump and see if it looks valid. Thanks for these hints, I'll try them ASAP, dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
current SMP kernel crashes (different?)
priority: 110 arbitrated configuration - \_SB_.LNUS irq 0: [ 10] 0.15.0 pci0: ACPI PCI bus on pcib0 IOAPIC #1 intpin 12 - irq 2 IOAPIC #1 intpin 10 - irq 5 IOAPIC #1 intpin 11 - irq 7 IOAPIC #1 intpin 15 - irq 9 pcib1: ACPI PCI-PCI bridge at device 0.1 on pci0 initial configuration before setting priority for links \_SB_.LNUS: interrupts: 10 penalty: 110 references: 1 priority: 110 before fixup boot-disabled links - \_SB_.LNUS: interrupts: 10 penalty: 110 references: 1 priority: 110 after fixup boot-disabled links -- \_SB_.LNUS: interrupts: 10 penalty: 110 references: 1 priority: 110 arbitrated configuration - pci1: ACPI PCI bus on pcib1 IOAPIC #1 intpin 14 - irq 10 pci1: display, VGA at device 0.0 (no driver attached) fxp0: Intel Pro 10/100B/100+ Ethernet port 0xc800-0xc83f mem 0xfe80-0xfe8f,0xfeafb000-0xfeafbfff irq 2 at device 4.0 on pci0 fxp0: Ethernet address 00:30:48:11:69:84 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: Adaptec aic7899 Ultra160 SCSI adapter port 0xd000-0xd0ff mem 0xfeafc000-0xfeafcfff irq 5 at device 5.0 on pci0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: Adaptec aic7899 Ultra160 SCSI adapter port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 7 at device 5.1 on pci0 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs fxp1: Intel Pro 10/100B/100+ Ethernet port 0xd400-0xd43f mem 0xfe90-0xfe9f,0xfeafd000-0xfeafdfff irq 9 at device 6.0 on pci0 fxp1: Ethernet address 00:30:48:11:6e:27 inphy1: i82555 10/100 media interface on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge port 0x580-0x58f at device 15.0 on pci0 isa0: ISA bus on isab0 atapci0: ServerWorks ROSB4 ATA33 controller port 0xffa0-0xffaf at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ohci0: OHCI (generic) USB controller mem 0xf000-0x irq 0 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib2: ACPI Host-PCI bridge on acpi0 acpi0: couldn't attach pci bus device_probe_and_attach: pcib2 attach returned 6 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 fdc0: cmd 3 failed at out byte 1 of 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A pcib2: ACPI Host-PCI bridge on acpi0 acpi0: couldn't attach pci bus device_probe_and_attach: pcib2 attach returned 6 fdc0: cmd 3 failed at out byte 1 of 3 orm0: Option ROMs at iomem 0xcf000-0xc,0xc9000-0xcefff,0xc8000-0xc8fff,0xc-0xc7fff on isa0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 pmtimer0 on isa0 ppc0: parallel port not found. sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x100 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec APIC_IO: Testing 8254 interrupt delivery Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x6dbc00 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02d7383 stack pointer = 0x10:0xc06decf8 frame pointer = 0x10:0xc06ded18 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 = 0 (swapper) kernel: type 12 trap, code=0 Stopped at _mtx_lock_flags+0x43: cmpl$0xc05216c0,0(%ebx) db trace _mtx_lock_flags(6dbc00,0,c04c3c00,138,c02d767d) at _mtx_lock_flags+0x43 ithread_remove_handler(c06ded80,c06ded78,c046c427,c06ded80,0) at ithread_remove_handler+0x53 inthand_remove(c06ded80,0,c04e8e36,445,a0) at inthand_remove+0x11 cpu_initclocks(c06ded98,c02bcf75,0,6db000,6dbc00) at cpu_initclocks+0x327 initclocks(0,6db000,6dbc00,6db000,0) at initclocks+0x1c mi_startup() at mi_startup+0xb5 begin() at begin+0x2c db _mtx_lock_flags+0x43 - sys/kern/kern_mutex.c:324 ithread_remove_handler+0x53 - sys/kern/kern_intr.c:314 inthand_remove+0x11 - sys/i386/isa/intr_machdep.c:705 cpu_initclocks+0x327 - sys/i386/isa/clock.c:1096 initclocks+0x1c - sys/kern/kern_clock.c:153 mi_startup+0xb5 - sys/kern/init_main.c:217 -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL
fxp0 timeouts
I'm quite certain this was discussed recently, but I can't find it in the mailing list archives. I'm getting a few fxp0: device timeout on my supermicro 6010H (dual 1GHz PIII with onboard fxp). Was this resolved? thanks, dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make release broken (+ fix)
It looks like if_wx was not removed from /usr/src/release/i386/drivers.conf which breaks make release. Index: drivers.conf === RCS file: /home/ncvs/src/release/i386/drivers.conf,v retrieving revision 1.2 diff -c -r1.2 drivers.conf *** drivers.conf7 Nov 2000 14:00:04 - 1.2 --- drivers.conf23 Oct 2001 22:31:58 - *** *** 54,58 vrif_vr 2 network VIA VT3043/VT86C100A Rhine PCI ethernet card wbif_wb 2 network Winbond W89C840F PCI ethernet card wiif_wi 2 network Lucent WaveLAN/IEEE 802.11 PCMCIA card - wxif_wx 2 network Intel Gigabit Ethernet (82452) card xlif_xl 2 network 3COM 3c90x / 3c90xB PCI ethernet card --- 54,57 dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make release: kernel floppy too big
I tried a make release today and when (I think) it's making the kernel floppy it craps out - the DIOCWLABEL may or may not be a problem, but it would appear that the kernel floppy has overflowed. This is probably rather simple to fix (and potentially politically charged), but more importantly, I'm lazy, and figured I'd just whine and hope someone fixes it for me. :-) If you've read this far and not already hit reply to flame me, seriously, it looks like the total file sizes of what I think it's trying to cpio to the floppy image adds up to 1447587 bytes. Assuming I'm not wrong here, or I somehow compiled with the 'create bloated object' file options set, how do you handle things like this? Below are an ls -lR in the directory it's copying about and the last few lines of output from make release. dave c = [dave@white] 114% ls -lR total 1265 drwxr-xr-x 2 root wheel 512 Sep 24 20:20 boot/ -r-xr-xr-x 1 root wheel 1285524 Sep 24 20:20 kernel.gz* ./boot: total 172 -rw-r--r-- 1 root wheel2156 Sep 24 20:20 device.hints -r-xr-xr-x 1 root wheel 159744 Sep 24 20:20 loader* -rw-r--r-- 1 root wheel 163 Sep 24 20:20 loader.rc [dave@white] 115% = linking BOOTMFS textdata bss dec hex filename 2478437 259532 139860 2877829 2be985 BOOTMFS install -c -m 555 -o root -g wheel BOOTMFS /R/stage/kernels mv /R/stage/kernels/BOOTMFS /R/stage/image.kern/kernel Setting up /boot directory for kern floppy /R/stage/image.kern/kernel: 53.7% -- replaced with /R/stage/image.kern/kernel.gz sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt 1440 /R/stage/image.kern 8 fd1440 disklabel: ioctl DIOCWLABEL: Operation not supported by device Warning: Block size restricts cylinders per group to 6. Warning: 1216 sector(s) in last cylinder unallocated /dev/md0c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 32 i/g) super-block backups (for fsck -b #) at: 32 cpio: write error: No space left on device *** Error code 1 Stop in /usr/src/release. *** Error code 1 Stop in /usr/src/release. *** Error code 1 Stop in /usr/src/release. -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
unpleasant ps output and possible related problems.
I apologize for not having any idea where to start on this. I am not whining for someone to fix something, merely reporting an odd behavior that I have now seen on multiple machines in cae it means something to anybody. I am tracking current almost daily on three machines. Starting yesterday I managed to get one box that refused to go into multiuser mode it would run the rc script and then hang somewhere executing the scripts in /usr/local/etc/rc.d. If I Ctrl-C'ed it - it would come up in the single-user mode shell. no login prompt, just the shell. I could however telnet into the thing most things seemed to work. In this state it had hung without starting INN - so I su'ed and tried to start it. INN starts, but I end up at a prompt with a uid of news! If I exit that, INN dies. I do a ps -ax and I get some corrupt lines: 471 p0 Is 0:00.07 -csh (csh) 473 p0 I 0:00.01 su -m 474 p0 S 0:00.04 \M-[\M-!\^D\b\M-X\M-!\^D\b (csh) 12673 p0 R+ 0:00.00 ps ax 466 v0 Is+0:00.01 /usr/libexec/getty Pc ttyv0 In troubleshooting this I went back to an older kernel and the problem persists. Change back to an old world and it's gone. Tried the new kernel with old world and it also seems to work fine. So the problem seems to be somewhere in the libs or userland. Now I went and looked at some other systems rebuilt yesterday evening and today and while they still work I see the same sort of corruption as above in the ps output - but no other apparent side effects. The corrupted line shows up in many different places and users, and the exact contents vary, but there's always a (csh) at the end. -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unpleasant ps output and possible related problems.
you wrote: When you rebuild and install a new kernel, are you also doing a `make buildworld` and a `make installworld` in /usr/src before you reboot? My usual method is to build a kernel, reboot, build world, reboot, build a kernel using the new world, reboot again, do a mergemaster, one final build world, reboot, then test. If I'm bored I'll do it all over again after combing for stale binaries Fortunately, I have a very fast system. :-) Sometimes changes to userland are trivial, and you may not need to rebuild userland, but utmp corruption is indicative of changes that require userland be rebuilt and installed. Ideally, you should buildworld/installworld *EVERY* time you build a -current kernel. Of course, if you have already done this, feel free to issue me a boot to the head. I expect that this is the first question that should be asked of anyone who doesn't state explicitly that they follow a rigorous process for assuring a good build. No boot to the head necessary... You note that you are running innd, please don't tell me that you are using -current in a production environment... -current is always subject to massive *FUNDAMENTAL* changes with only a moment's notice, and breakage without any notice at all... Using -current in a production environment, unless seriously justified [such as -current being more stable than -stable], is a fine way to put yourself in a position to commit hari-kari, and nobody wants that. I would call it a non-production system - besides, how better to test -current than by doing exactly what I would do with it in a real production system? I really don't think that this is an INN problem though - my best guess at the moment is that either something is busted in csh/tcsh or that something it relies upon is broken. The outward symptoms I saw that screwed up news or the boot sequence I think could be explained by the scripts returning control to console rather than exiting the shell, but that's a wild guess. I have rolled most of my -current systems back to a source tree from 23:36 UT on Monday night which is the last time I built a fully working system. I don't have too much time to play with it but I still have two very -current systems that exhibit the problem of the ps corruption so I'll keep plugging and if I get some time this weekend and they still are doing this, then I'll try and get more info. dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
you wrote: And just for the record: PERL is right out (of space) for this purpose... as I assume emacs would be too? :-( -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
more on supermicro 6010H hang
flags 0x80 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2 APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 acd0: CDROM MATSHITA CR-177 at ata1-master PIO4 Waiting 2 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST318451LC 0002 Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 17501MB (35843671 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST318451LC 0002 Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 17501MB (35843671 512 byte sectors: 255H 63S/T 2231C) Mounting root from ufs:/dev/da0s1a SMP: AP CPU #1 Launched! -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
I have gotten this system to boot with a current SMP kernel from as late as mid-September 2000, and am working on stabilising the system so that I can try later versions. It seems that all the working versions don't use Ultra-160 (I'm not sure when this hit the tree) - could the problem have been introduced when support was added? thanks, dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
old current snapshots
Does anyone know of a place where I can find old current snapshots? current.freebsd.org only goes back to April, and I'd like to find something earlier. I am trying to find out why a 4.3 SMP kernel will boot on a SuperMicro 6010H while a current kernel hangs. I am taking the rather tedious approach of trying to isolate when the breakage might have occurred by installing the oldest version of 5.0 I can easily get my hands on and working my way forward. I am running a make release with a tag of PRE_SMPNG, but given my operable hardware it's going to be days before I have something from that (provided nothing is broken). thanks, dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
Justin T. Gibbs wrote: John Baldwin wrote: Hrmm, perhaps you are getting an interrupt storm from ahc. Ok, try this: find the ahc driver's interrupt handler, and add a printf. Then see if the printf fires while the machine is hung. Ok, I put a printf in ahc_handle_seqint() and ahc_handle_scsiint(). That won't catch all interrupts. Most notably, you won't know if commands are completing. Command completions are much more prevalent than sequencer or scsi interrupts. should I try and catch the command completions? which routine is best to do this in? btw, thanks very much for your help! dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
John Baldwin wrote: Hrmm, perhaps you are getting an interrupt storm from ahc. Ok, try this: find the ahc driver's interrupt handler, and add a printf. Then see if the printf fires while the machine is hung. Ok, I put a printf in ahc_handle_seqint() and ahc_handle_scsiint(). My current (freshly cvsupped sources) kernel with the printf()s in it is pretty consistent in it's behavior: with SMP it hangs soon after the 15 second SCSI delay and keystrokes will not cause it to continue to boot. The order that they print out on the screen is this: message Waiting 15 seconds for SCSI devices to settle (approximately 15 second delay) 26 times scsiint called with intstat = 0x4, status0 = 0, status = 0x88 (SELTO BUSFREE?) 2 times seqint called with instat = 0x71 (BAD_STATUS?) 36 times seqint called with intstat = 0x61 (HOST_MSG_LOOP?) and then the system hangs. I have gone back to a SMP kernel from April 15th - using a GENERIC kernel with SMP enabled it exhibits the same problem. Will work my way back to -stable and see if anything changes... dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
John Baldwin wrote: Is this on -current or -stable? If it's on -current, why did you ask on -questions? :) It looks like an interrupt problem however. When I asked on questions, I was of the belief that I had a hardware problem and that it was not necessarily a -current issue. When I later went back and installed 4.3 and it worked I then realized that I had justification to post it on -current. Hey, at least I didn't cross-post to questions, stable, scsi, and current! :) I guess my next step is to try and trace through what's happening - can you suggest a good place to start (like a routine to start tracing), or is there anything I can do that might get more info for the people that know what is going on? thanks! dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
John Baldwin wrote: Ok, sounds good, just checking. :) Can you provide the output of mptable for this box? In the SMP case, -current does interrupt routing for PCI interrupts a bit differently, which might be a possible reason. Hmm, but you are getting interrupts eventually it seems. I can only get the thing past the hang maybe once in twenty+ tries. Below is the mptable output (I don't remember what version of FreeBSD I had installed when I did this, hope it doesn't matter). I'll try the KTR stuff later tonight. thanks! dave c === MPTable, version 2.0.15 --- MP Floating Pointer Structure: location: BIOS physical address: 0x000ff780 signature:'_MP_' length: 16 bytes version: 1.1 checksum: 0xb9 mode: Virtual Wire --- MP Config Table Header: physical address: 0x000f0bd0 signature:'PCMP' base table length:284 version: 1.1 checksum: 0x28 OEM ID: 'AMI ' Product ID: 'CNB20HE ' OEM table pointer:0x OEM table size: 0 entry count: 27 local APIC address: 0xfee0 extended table length:0 extended table checksum: 0 --- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model StepFlags 0 0x11BSP, usable 6 8 6 0x387fbff 1 0x11AP, usable 6 8 6 0x387fbff -- Bus:Bus ID Type 0 PCI 1 PCI 2 PCI 3 ISA -- I/O APICs: APIC ID Version State Address 4 0x11usable 0xfec0 5 0x11usable 0xfec01000 -- I/O Ints: TypePolarityTrigger Bus ID IRQAPIC ID PIN# INT active-lo level1 0:A 5 14 INT active-lo level0 5:B 5 11 INT active-lo level0 15:A 4 10 INT active-lo level0 6:A 5 15 INT active-lo level0 5:A 5 10 INT active-lo level0 4:A 5 12 ExtINT active-hiedge3 0 40 INT active-hiedge3 1 41 INT active-hiedge3 0 42 INT active-hiedge3 3 43 INT active-hiedge3 4 44 INT active-hiedge3 6 46 INT active-hiedge3 8 48 INT active-hiedge312 4 12 INT active-hiedge313 4 13 INT active-hiedge314 4 14 INT active-hiedge315 4 15 -- Local Ints: TypePolarityTrigger Bus ID IRQAPIC ID PIN# ExtINT active-hiedge3 02550 NMI active-hiedge0 0:A2551 === -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
John Baldwin wrote: Actuually, KTR is your friend here. :) Read the ktr(4) manpage, then compile a kernel with KTR_MASK and KTR_COMPILE set to KTR_INTR|KTR_PROC. Then when it hangs, break into DDB and look at the longs via 'show ktr' to see if you can locate any interrutps coming in from ahc0 or ahc1. Okay - fired up the box, built a kernel off of a 6/18 source snapshot, and it hangs in about the same place - however what I get that as soon as I touch a key to invoke the debugger from the console, it continues merrily booting and I can't break into DDB until way past the problem. In my mind this kind of confirms something is busted in the interrupts. Tried looking back through the show ktr output and I'm not 100% clear on what it all means - I guess I'm interested in the ithread stuff and the only thing I ever see is swi6: tty:sio+ in the trace buffer besides what appears to be normal process rescheduling (?) which is mostly idle task time... Do think there's any use to rolling my source tree back a ways and compiling a kernel? thanks, dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SCSI hangs w/SuperMicro 6010H
Please excuse me if you've seen this in questions, but I found a relevancy to current: If I drop back to 4.3 release, this system boots every time with no hangs observed in half a dozen tries in either UP or SMP mode. Anyone else seeing similar? thanks, dave c - Forwarded message from Dave Cornejo - From: Dave Cornejo [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Subject: SuperMicro 6010H SCSI Problems To: [EMAIL PROTECTED] Date: Sun, 17 Jun 2001 00:20:47 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL88 (25)] I finally got a make release done (a heartfelt thanks to all the people I badgered to commit fixes for that!) and installed it. I'm having a problem with a SuperMicro 6010H server (uses a 370DER+ motherboard), dual 1GHz PIII, 1GB RAM, 2 x Seagate ST318451LC drives (18GB 15K RPM Ultra160 SCSI). The SCSI chip is an Adaptec 7899. The software is several different kernels from today (June 16) cvsupped at various times. It seems to boot okay with a non-SMP kernel, but hangs with an SMP one. It seems to revolve around the SCSI stuff, I did a boot -v and tried to get into the debugger but it's hung hard. Oddly sometimes if you pound on the keyboard at the right point (noted in the edited output of dmesg below) it will continue on to boot, but you get tons of Retrying commands and tagged openings now XXX before things settle out and all seems to work okay after that. Another tidbit: swapped the drives and reinstalled and the command retries aren't happening (at least not as quickly or often), but the hang is still there. Any clues would be appreciated... dave c what I hope are the relevant bits of dmesg: ahc0: Adaptec aic7899 Ultra160 SCSI adapter port 0xd000-0xd0ff mem 0xfeafc000-0xfeafcfff irq 5 at device 5.0 on pci0 ahc0: Reading SEEPROM...done. ahc0: Manual LVD Termination ahc0: BIOS eeprom is present ahc0: Secondary High byte termination Enabled ahc0: Secondary Low byte termination Enabled ahc0: Primary Low Byte termination Enabled ahc0: Primary High Byte termination Enabled ahc0: Downloading Sequencer Program... 419 instructions downloaded aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: Adaptec aic7899 Ultra160 SCSI adapter port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 7 at device 5.1 on pci0 ahc1: Reading SEEPROM...done. ahc1: Manual LVD Termination ahc1: BIOS eeprom is present ahc1: Secondary High byte termination Enabled ahc1: Secondary Low byte termination Enabled ahc1: Primary Low Byte termination Enabled ahc1: Primary High Byte termination Enabled ahc1: Downloading Sequencer Program... 419 instructions downloaded aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/255 SCBs ... BIOS Geometries: 0:03fefe3f 0..1022=1023 cylinders, 0..254=255 heads, 1..63=63 sectors 1:03fefe3f 0..1022=1023 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2 APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 ... Waiting 2 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. (probe0:ahc0:0:0:0): Retrying Command (probe1:ahc0:0:1:0): Retrying Command (ahc0:A:0:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options 2 (ahc0:A:0:0): Received PPR width 1, period 9, offset 3f,options 2 Filtered to width 1, period 9, offset 3f, options 2 ahc0: target 0 using 16bit transfers ahc0: target 0 synchronous at 80.0MHz DT, offset = 0x3f (ahc0:A:1:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options 2 (ahc0:A:1:0): Received PPR width 1, period 9, offset 3f,options 2 Filtered to width 1, period 9, offset 3f, options 2 ahc0: target 1 using 16bit transfers ahc0: target 1 synchronous at 80.0MHz DT, offset = 0x3f usually hangs here, but sometimes if you pound on the keyboard at exactly the right moment, it will continue as in this case: pass0 at ahc0 bus 0 target 0 lun 0 pass0: SEAGATE ST318451LC 0002 Fixed Direct Access SCSI-3 device pass0: Serial Number 3CC00ESN1048HMU7 pass0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled pass1 at ahc0 bus 0 target 1 lun 0 pass1: SEAGATE ST318451LC 0002 Fixed Direct Access SCSI-3 device pass1: Serial Number 3CC00DZC10460HC7 pass1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled Creating DISK da0 Creating DISK da1 da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST318451LC 0002 Fixed Direct Access SCSI-3 device da0: Serial Number 3CC00ESN1048HMU7 da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 17501MB (35843671 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST318451LC 0002 Fixed Direct Access SCSI-3 device da1: Serial Number 3CC00DZC10460HC7 da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 17501MB (35843671 512 byte sectors
Re: threaded python seg faults?
The patch seems to solve my problems, thank you! dave c John Polstra wrote: It's because libc_r isn't getting initialized in time. Please try applying the appended patch to "src/gnu/lib/libgcc_r/Makefile" and let us know if it fixes the problem. You will need to rebuild and reinstall libgcc_r, and then rebuild python. Thanks for providing the detailed information! This never would have caught my eye otherwise. John Index: Makefile === RCS file: /home/ncvs/src/gnu/lib/libgcc_r/Makefile,v retrieving revision 1.4 diff -u -r1.4 Makefile --- Makefile 1999/10/03 02:43:20 1.4 +++ Makefile 2000/10/31 18:06:34 @@ -2,5 +2,6 @@ LIB= gcc_r CFLAGS+=-D_PTHREADS +CFLAGS+=-D'__GTHREAD_MUTEX_INIT_FUNCTION(m)=pthread_mutex_init(m, NULL)' .include "../libgcc/Makefile" -- Dave Cornejo @ Dogwood Media, Fremont, California "There aren't any monkeys chasing us..." - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
threaded python seg faults?
For the last couple of days I've been trying to build python 2 from the ports tree without success. I updated my sources a couple of time and rebuilt the kernel and world with no effect. The problem seems to have appeared in the last couple of days and seems to happen while loading libc_r.so.4 - Is anyone else seeing this, or have any suggestion what I might be doing wrong? Further playing around get it working with WITHOUT_THREADS defined, so the problem seems to point at the threaded libc - which I've rebuilt several time in the last couple of days. thanks! dave Here's what gdb shows me: juneau# gdb python GNU gdb 4.18 Copyright 1998 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-unknown-freebsd"... (gdb) run Starting program: /usr/ports/lang/python/work/Python-2.0/python Program received signal SIGSEGV, Segmentation fault. 0x28383ec6 in pthread_mutex_lock () from /usr/lib/libc_r.so.4 (gdb) bt #0 0x28383ec6 in pthread_mutex_lock () from /usr/lib/libc_r.so.4 #1 0x80bb5b0 in __register_frame_info () #2 0x2834713a in _init () from /usr/lib/libc_r.so.4 #3 0x28343fe5 in _init () from /usr/lib/libc_r.so.4 #4 0x2815086c in _rtld () from /usr/libexec/ld-elf.so.1 (gdb) quit The program is running. Exit anyway? (y or n) y juneau# The system is a dual PIII-600 w/512M RAM if that helps... -- Dave Cornejo @ Dogwood Media, Fremont, California "There aren't any monkeys chasing us..." - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fetch problem with fwtk
I am using fwtk-2.1 on a firewall, and with the latest builds, fetch seems to have changed behaviors such that it no longer works with it. I have FTP_PROXY set to "red:9696" the difference in behavior seems that older versions of fetch would send a USER command like this: USER [EMAIL PROTECTED] the latest fetch sends this: USER [EMAIL PROTECTED]@21 which fwtk apparently interprets as username "[EMAIL PROTECTED]" at IP address "0.0.0.21" What is incorrect here? Should FWTK understand this or is fetch wrong? dave -- Dave Cornejo @ Dogwood Media, Fremont, California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
You know, the people reading this list are *not* the typical FreeBSD users. The fact that releases occur at all is a concession to the realities of the world - WCCDROM needs to pay it's bills by selling CDROMs, and their business pressures require new updates on time and to be as stable as possible (to minimize tech support). You have no idea how expensive it was for them to slip the date a month as it already has to include the features that will go into 4.0. Additionally, despite what you think, I'd bet 99+% of the FreeBSD users in the world could give a rats *ss about IPv6. I run many FreeBSD systems and not one of the ISPs I deal with has announced any plans to move to IPv6 yet. I don't see much, if any, market pressure to move yet, and I suspect that v4 will be perfectly adequate to the needs of a vast majority of FreeBSD users for at least the next year, if not longer. If you want v6, run current, don't make the people waiting for 4.0 wait longer. This is much more likely to cause lost users than no v6. -- Dave Cornejo - Dogwood Media, Fremont, California General Magician Registered Be Developer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
