Re: Patch: sym(4) "VTOBUS FAILED" panics on amd64, amd64/89550
On Fri, 22 Sep 2006, Jan Mikkelsen wrote:
Quick summary: sym(4) assumes on amd64 that virtual addresses provided by
bus_dmamem_alloc() have the same alignment as the physical addresses (in
this case, 2*PAGE_SIZE). They don't, and stuff breaks. This patch works
around that.
Why is this? busdma supports alignment constraints; why not just set the
alignment to what you need it set at? I realize sym has its own hand
rolled DMA management craziness but alignment is something busdma can take
care of easily.
Also the changes to MEMO_CLUSTER_SIZE seems to be already compensated for
by the code blocks that calculate it:
#define MEMO_SHIFT 4 /* 16 bytes minimum memory chunk */
#ifndef __amd64__
#define MEMO_PAGE_ORDER 0 /* 1 PAGE maximum */
#else
#define MEMO_PAGE_ORDER 1 /* 2 PAGEs maximum on amd64 */
#endif
#if 0
#define MEMO_FREE_UNUSED/* Free unused pages immediately */
#endif
#define MEMO_WARN 1
#define MEMO_CLUSTER_SHIFT (PAGE_SHIFT+MEMO_PAGE_ORDER)
#define MEMO_CLUSTER_SIZE (1UL << MEMO_CLUSTER_SHIFT)
#define MEMO_CLUSTER_MASK (MEMO_CLUSTER_SIZE-1)
This results in 2*PAGE_SIZE clusters on amd64 and PAGE_SIZE clusters on
other platforms. Since you seem to like doing MEMO_CLUSTER_SIZE * 2, why
not just increase MEMO_PAGE_ORDER to 2 (and get 4*PAGE_SIZE clusters) ?
Oh dear, I didn't notice that the call to bus_dma_tag_create() has bad
arguments. From the (RELENG_6) source:
if (!bus_dma_tag_create(dev_dmat, 1, MEMO_CLUSTER_SIZE,
BUS_SPACE_MAXADDR_32BIT,
BUS_SPACE_MAXADDR_32BIT,
NULL, NULL, MEMO_CLUSTER_SIZE, 1,
MEMO_CLUSTER_SIZE, 0,
busdma_lock_mutex, &Giant, &mp->dmat)) {
As you fixed, that second BUS_SPACE_MAXADDR_32BIT should be
BUS_SPACE_MAXADDR since its an exclusion zone. I'm suprised that doesn't
fix it right there.
If increasing MEMO_PAGE_ORDER fixes the issue, then the #ifs are
extraneous.
Also we generally prefer diffs in unidiff (-u) format, its a little easier
to figure out exactly what changed just by looking at the diff. Thanks!
--
Doug White| FreeBSD: The Power to Serve
[EMAIL PROTECTED] | www.FreeBSD.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggestions for Adaptec SAS AIC9410
On Mon, 5 Jun 2006, Andy Dills wrote: I'm trying to get a Supermicro 6024H-32R setup with 6.1, but I'm discovering that the Adaptec SAS AIC9410 controller isn't yet supported. I see one brief thread about it on this mailing list back in March, but no further mention or conclusive details. There was talk of MFCing the mpt driver...is anybody using this in production? Can you get a pciconf -lv off this system? It might just be a case of needing to add an ID to an existing driver (aac?). -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1-RELEASE: WARNING - WRITE_DMA soft error
On Mon, 5 Jun 2006, srwadleigh wrote: I have 6.1-RELEASE installed on a Supermicro SuperServer 6014P-TR with Supermicro motherboard: Super X6DHP-TG http://supermicro.com/products/motherboard/Xeon800/E7520/X6DHP-TG.cfm I have four SATA drives attached to the internal backplane which uses the following controller, I am Not using the onboard RAID features: Marvell 88SX6081 4-port SATA Controller with 3rd-Party Adaptec AIC-8110(4x drive), RAID 0, 1, JBOD support The problem I am seeing occurs with the fourth drive, ad10, and appears on all read/write operations: ad10: WARNING - WRITE_DMA48 soft error (ECC corrected) LBA=293046767 kernel:ad10: WARNING - WRITE_DMA soft error (ECC corrected) LBA=12393823 kernel:ad10: WARNING - READ_DMA soft error (ECC corrected) LBA=12480567 This same warning message appears on 6.0-RELEASE and 6.1-STABLE I have problems with a similar chassis w/ SCSI and bay 3 throwing spurious errors on a number of systems, so I think its just poor backplane design on SuperMicro's part. Try getting them to replace your backplane board. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dual Opteron system will not run SMP
On Wed, 7 Jun 2006, Pete French wrote: If just non-ACPI isnt sufficient, the other thing SAFE does is turn off disk DMA. I have an as-yet unreleased system that has this same type of issue, and the problem is that two PCI device ID's are not recognized, so maybe that will be your problem. So, I got around to booting the system without ACPI and there are quite a number of 'unknown' reports at boot, viz: unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) These are normal motherboard resources that FreeBSD reserves via other methods. They can be safely ignored. pciconf -l gives me 5 devices without drivers attached, these being: [EMAIL PROTECTED]:7:2: class=0x0c0500 card=0x13101462 chip=0x746a1022 rev=0x02 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8111 SMBus 2.0 Controller' class= serial bus subclass = SMBus You need to load a device driver to attach to this function; I believe its called amdpm. It is only needed if you want to inquiry devices on SMBus. [EMAIL PROTECTED]:7:3: class=0x068000 card=0x13101462 chip=0x746b1022 rev=0x05 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8111 ACPI System Management Controller' class= bridge [EMAIL PROTECTED]:10:1:class=0x080010 card=0x13101462 chip=0x74511022 rev=0x01 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8131 PCI-X IOAPIC' class= base peripheral subclass = interrupt controller [EMAIL PROTECTED]:11:1:class=0x080010 card=0x13101462 chip=0x74511022 rev=0x01 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8131 PCI-X IOAPIC' class= base peripheral subclass = interrupt controller FreeBSD detects and attaches these through ACPI and not through the PCI bus. In the non-ACPI case (which BTW is not exactly kosher for amd64, since ACPI is a required part of the platform spec), IOAPICs are enumerated and attached through MPTable. The fact that the IOAPICs have PCI bus attachments at all is an implementation detail. They didn't back in the Pentium Pro days. [EMAIL PROTECTED]:6:0: class=0x03 card=0x13101462 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Rage XL PCI' class= display subclass = VGA This usually gets grabbed either by the agp driver or by the DRM (Direct Rendering Module) appropriate for the chip. The console uses generic VGA register accesses and doesn't need the PCI attachment to figure that out. If you don't run X then this is normal. My recommendation for problems with amd64 boards: 1. Upgrade to the latest release BIOS from the vendor. This is really, really, really important; the latest BIOS often has revised memory and bus timings that improve compatibility. The Tyan S2892 in particular needs it to avoid lockups if any PCI cards are installed. 2. Lockups at the SCSI detection phase are usually due to interrupt routing issues (an interrupt gets stuck on and won't clear since we can't figure out who's triggering it). If you have PCI cards installed try moving them to different slots or removing them entirely. Also disconnect any USB peripherals you may have connected. 3. You could have a defective IOAPIC, or other device, on your system board. Very rare, but possible. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1 buildkernel question
On Fri, 2 Jun 2006, [EMAIL PROTECTED] wrote: My system works, however the buildkernel process had about 2000 warnings, with 1/2 of those compiling aic7xxx (see below). This was discussed on BSDForums but as far as I can tell, different compiler options were used; the conclusion was using -O3 was the problem. Using compilation options other than the defaults (except for options enabled through the CPUTYPE make.conf option) is not recommended or supported. Bug reports about compile errors or warnings while non-standard options are enabled will be ignored. That being said: ./machine/bus.h:221: warning: inlining failed in call to 'bus_space_read_1': --p aram inline-unit-growth limit reached This is normal. We're not entirely sure how we're hitting the limit in this component, but the warning is harmless. You may safely ignore this message. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1 kernel unable to find /dev ?
On Sat, 3 Jun 2006, Brian Tao wrote: I had a very stable 6.1-R amd64 server (once I swapped out some bad RAM, that is) that needed a couple more hard drives installed. There were some problems with the upgrade (device renumbering woes, basically... topic of another thread), and it had to be rolled back. Upon rolling back, the previously-good kernel would no longer complete the boot after the device probe. I saw two types of panics on the serial console: | Trying to mount root from ufs:/dev/ad4s1a | Lookup of /dev for devfs, error: 20 Error 20 is ENOTDIR which means something along the requested path exists, but it is not a directory. From this output it looks the root directory entry is somehow corrupted or being misinterpeted. | exec /sbin/init: error 20 | exec /sbin/oinit: error 20 | exec /sbin/init.bak: error 20 | exec /rescue/init: error 20 | exec /stand/sysinstall: error 20 | init: not found in path | /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall | panic: no init | Uptime: 8s | Cannot dump. No dump device defined. | Automatic reboot in 15 seconds - press a key on the console to abort | --> Press a key on the console to reboot, | --> or switch off the system now. ... and: | Trying to mount root from ufs:/dev/ad4s1a | pid 47 (sh), uid 0: exited on signal 11 | TPTE at 0x840028e0 IS ZERO @ VA 80051c000 | panic: bad pte | Uptime: 8s This is usually indicative of bad RAM or a faulty processor. Since you seem to be having disk problems, it may just be due to the disk returning faulty data. Or there is a bad kernel module in the mix that is randomly corrupting data. The first one is suggesting that /dev does not exist (or is not a directory)... I'm thinking this means that devfs is somehow unavailable, but I did not think it is even possible to disable devfs via the kernel config file these days. The second one leaves me clueless... I have not been able to find any useful information on that panic during boot. Granted, I've only see the "bad pte" panic twice... all other reboot attempts result in the first type of problem. Fortunately, I did happen to keep an old 6.0-RELEASE-p6 kernel around (Apr 15 2006 build). That kernel boots fine, using the same filesystem as newer kernels on that drive. I am up-to-date with the RELENG_6_1 tag. Should I perhaps to a make installkernel installworld before rebooting? The installed binaries on the server are from an early 6.1-RELEASE (which *was* successfully booted by this server). I am running into a few minor but surmountable problems because of the older kernel version, but I obviously would like to get my world and kernel back in sync ASAP. My gut feeling is that there is still a disconnect on what the root filesystem is. That or there is hidden corruption that 6.0 isn't noticing that 6.1 is. Here's what I'd do next: 1. Capture the boot output from both the working 6.0 kernel and your broken 6.1 kernel and compare the two. If there are differences or errors being returned from the ATA controller or disks then those will need to be addressed. 2. Try a splat-over reinstall of 6.1-R from CD to force everything to match up. Mount the filesystems but don't mark them to be newfs'd. Install the GENERIC kernel only. If you are going to be tracking a branch, please read the instructions at the end of src/UPDATING on how to perform the build. There is a specific procedure and not following it can cause significant issues. While unlikely, it is possible to irreparibly damage the system by not following the instructions to the letter. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jail issue question
On Sat, 6 May 2006, Gergely CZUCZY wrote: > hi all > > i've got this issue: > http://www.freebsd.org/cgi/query-pr.cgi?pr=96729 > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89528 > > i'd like to look into it, because i'm not experience with the > development of the freebsd (or any other) kernel, yet i'd like > to create a temporary solution. it would consist of a userspace > utility that invokes a kernelspace function that cleans out the > unused jail entry from the "jail registry", and perhaps cleans out > other related entries(such as processes inside the jail). > > my question is, on which kernel tree should I try to manage this, > on my desktop currently i run 6-STABLE, first i though this could > be good, but maybe i should do it on -CURRENT. so, which tree should > i examine, check and maybe modify a bit? If you look at the audit trail in kern/89528 (96729 was closed as a duplicate) its related to the known pty leak issue. Writing a tool to brute-force free those resources will not help at all and likely lead to an immediate panic when something tries to reference the object you forcibly detached from the jail. If you can come up with a reliable test case that causes this pty leak, and be willing to test patches, then it would greatly help the debugging effort. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1-RC and the audit group
On Sat, 6 May 2006, Mark Kirkwood wrote: > I found that installworld stops, because the 'audit' group has not been > created. Now I just pressed 'return' for the default actions during > mergemaster -p, but I didn't notice any mention of the audit group. The default action is to do nothing, so its possible you just missed it as you were blazing through. :-) Also, if you didn't delete the temporary directory last time, mergemaster will ask you if you want to re-use it. 9 times out of 10, the answer is 'no', but the default may be to save it. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to disable libcom_err from being built?
On Fri, 5 May 2006, Peter Losher wrote: > 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? According to src/lib/Makefile, libcom_err is also needed for PAM. Grepping around it looks like its just picked up for the pam_krb5 and pam_ksu modules, so this seems like a reasonable request thats easy to implement in the current framework. There doesn't appear to be a make.conf option to inhibit libcom_err from building right now, though. You could always edit it out of src/lib/Makefile. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB Flash reader under RELENG_6: force GEOM rescan
On Thu, 9 Feb 2006, Dmitry Morozovsky wrote: > OF> > > OF> > dd if=/dev/da0 of=/dev/da0 count=1 > OF> > > OF> > which results in error, but actually create GEOMs > OF> > OF> The following should work as well, without giving an error: > OF> > OF> dd if=/dev/null of=/dev/da0 count=0 > OF> > OF> It opens the device for writing (without actually writing > OF> anything) and immediately closes it again, which causes > OF> devfs to be "triggered". > > Aha, actually, it works. Thanks. How about 'fdisk da0'? :) I have a usb drive that takes a while to become ready after being inserted. It initially generates errors when attempting to access it. Yours may have a similar issue. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD6 on PowerEdge 4200
On Thu, 2 Feb 2006, Enrique Ayesta Perojo wrote: > Hello, i'm trying to install FreeBSD6 on an old PowerEdge 4200. But i cannot > even get to sysinstall, when it's booting from the cd it gets to a point > where the system reboots, these are the messages i can see on the console: > > ... > amr0: port 0xf480-0xf4ff irq 9 at device 19.0 on pci0 > amr0: busmaster bit not set, enabling Try updating the system BIOS and the PERC card's firmware to the latest, and make sure the card is enabled in the BIOS (if its onboard). This indicates the device isn't being configured properly by the BIOS. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PXE Installation
On Fri, 20 Jan 2006, Marten Vijn wrote: > On Fri, 2006-01-20 at 03:36 +0100, Karel Miklav wrote: > > Hi, > > > > I'm trying to install FreeBSD 6.0 to a sub-notebook without > > floppy or optical unit. > > > Please give me a hand, I'm playing with this for whole week. > > > nice game aint it? sure of your friends is tcpdump :) > > > steps to follow (more below), create: > > 1 pxeboot > 2 exports a nfs bootdir > 3 populate bootdir > 4 config dhcpd.conf > 5 add hosts to dns or /etc/hosts > 6 proper config for the bootdir [...] If the goal is to simply start sysinstall on the target then it is not necessary to construct a fully-populated root filesystem for the purpose. Just tell loader to use the mfsroot disk image that's in the boot/ directory and sysinstall will start up like it does when booting directly from CD. Instructions for this are at: http://people.freebsd.org/~dwhite/pxeboot.html Its fundamentally the same, except step 3 takes about 1 minute (cp -Rp) instead of an hour. Admittedly these instructions assume proficiency with configuring NFS, DHCP, and so forth. Its mainly a note to myself on how to do it. :) The addition of vfs.root.mountfrom="ufs:/dev/md0c" line to loader.conf is the key. The CDROM loader.rc already pulls in mfsroot.gz, you just have to point the kernel at that image instead of the NFS root that pxeboot will pass on. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 on Dell 1850 with PERC4e/DC RAID?
On Thu, 5 Jan 2006, Scott Mitchell wrote: > Hi all, > > I may be getting a new Dell PE1850 soon, to replace our ancient CVS server > (still running 4-STABLE). The new machine will ideally run 6.0 and have a > PERC4e/DC RAID card - the one with battery-backed cache. This is listed as > supported by amr(4), but I'm wondering how well it actually works in the > case of a disk failure. Will the driver tell me that disk has failed (a > syslog message would be enough) or will I have to make a daily trip into > the server room to check the front panel lights? Presumably it handles > hot-swapping a replacement drive OK? >From what I remember, you will receive status-change kernel messages when disks disappear, rebuilds start, and so forth. So for most day-to-day manipulation you should be fine. You may want to make sure the auto rebuild option is enabled in the controller's BIOS since no working control programs from userland are generally available at this time. That also means you can't create new volumes at runtime, but thats not so horrible... -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI not work
On Tue, 20 Dec 2005, Paul.LKW wrote: > Hello All: > I have a problem about ACPI not work with the following error from the > message log > > Dec 21 20:22:24 amd-64 kernel: ioapic0: Assuming intbase of 0 > Dec 21 20:22:24 amd-64 kernel: ioapic0 irqs 0-23 on > motherboard > Dec 21 20:22:24 amd-64 kernel: ACPI-0397: *** Error: NsSearchAndEnter: Bad > character in ACPI Name: 43005350 > Dec 21 20:22:24 amd-64 kernel: ACPI-0381: *** Error: Looking up [0x43005350] > (NON-ASCII) > Dec 21 20:22:24 amd-64 kernel: in namespace, AE_BAD_CHARACTER > Dec 21 20:22:24 amd-64 kernel: ACPI-0204: *** Error: AcpiLoadTables: Could > not load namespace: AE_BAD_CHARACTER > Dec 21 20:22:24 amd-64 kernel: ACPI-0213: *** Error: AcpiLoadTables: Could > not load tables: AE_BAD_CHARACTER > Dec 21 20:22:24 amd-64 kernel: ACPI: table load failed: AE_BAD_CHARACTER > > Any idea to fix it. Try upgrading or reflashing your BIOS. The DSDT in the BIOS image is corrupted. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with ata RAID?
On Wed, 14 Dec 2005, Steven Hartland wrote: > Just spotted the following in the logs of one of our machines > There seems to errors across too many disks for it to be disk issues. > Any one seen this before / got any advice? I'd say ad4 went kaboom and is corrupting traffic on its bus, thus the ad5 CRC warnings. (Remember that Parallel ATA drives are master/slave.) > ad4: timeout waiting to issue command > ad4: error issueing WRITE_DMA command > ar0: WARNING - mirror protection lost. RAID0+1 array in DEGRADED mode > ad4: timeout waiting to issue command > ad4: error issueing WRITE_DMA command > ad4: write metadata failed > ad6: req=0xc49b0578 WRITE_DMA semaphore timeout !! DANGER Will Robinson !! > ad5: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=2325663 > ad5: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=2325695 > ad5: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=2325695 > ad5: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=2325727 > ad5: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=2325632 > ad5: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=393344 > ad5: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=393344 > ad5: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=393344 > ad5: FAILURE - WRITE_DMA status=51 error=84 > LBA=393344 > ad4: req=0xc8585258 WRITE_DMA semaphore timeout !! DANGER Will Robinson !! > ad4: req=0xc8585258 WRITE_DMA semaphore timeout !! DANGER Will Robinson !! > ad4: req=0xc8585258 WRITE_DMA semaphore timeout !! DANGER Will Robinson !! > ad4: req=0xc8585258 WRITE_DMA semaphore timeout !! DANGER Will Robinson !! > ad5: FAILURE - SETFEATURES SET TRANSFER MODE status=51 > error=4 > ad5: FAILURE - SETFEATURES SET TRANSFER MODE status=51 > error=4 > ad5: FAILURE - SETFEATURES ENABLE RCACHE status=51 > error=4 > ad5: FAILURE - SETFEATURES ENABLE WCACHE status=51 > error=4 > ad5: FAILURE - SET_MULTI status=51 error=4 > ad4: FAILURE - WRITE_DMA timed out LBA=234441585 > ad4: write metadata failed > ad5: FAILURE - WRITE_DMA status=59 error=4 > dma=0x06 LBA=234441585 > ad5: write metadata failed > ad6: req=0xc853c190 WRITE_DMA semaphore timeout !! DANGER Will Robinson !! > > [dmesg] > atapci0: port > 0xa400-0xa407,0xa800-0xa803,0xac00-0xac07,0xb000-0xb003,0xb400-0xb43f mem > 0xf812-0xf813 irq 18 at device 12.0 on pci0 > ata2: on atapci0 > ata3: on atapci0 > ad4: 114473MB at ata2-master UDMA100 > ad5: 114473MB at ata2-slave UDMA100 > ad6: 114473MB at ata3-master UDMA100 > ad7: 114473MB at ata3-slave UDMA100 > ar0: 228946MB status: READY > ar0: disk0 READY (master) using ad4 at ata2-master > ar0: disk1 READY (master) using ad5 at ata2-slave > ar0: disk2 READY (mirror) using ad6 at ata3-master > ar0: disk3 READY (mirror) using ad7 at ata3-slave > [/dmesg] > > > > > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > > In the event of misdirection, illegible or incomplete transmission please > telephone (023) 8024 3137 > or return the E.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]" > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Trouble with amd64
Since this references 6.0-RELEASE it should have been sent to -stable, or since it references amd64 specifically it should have been sent to -amd64. Rerouting to -stable. On Wed, 23 Nov 2005, Nils Berzins wrote: > Hi ! > > Few days ago I downloaded release 6.0 ISOs, in hope that I will finally be > able to run FreeBSD on my home computer. Unfortunately, booting from CD dies > with: > > > panic: sym: VTOBUS FAILED ! > > Is there something I can do to get around this error, or do I just wait for > more less stable 7.0 :-( According to the code this panic occurs when there is a problem with the DMA memory management. Typically we see this when the driver is not 64-bit clean, but I'd find that hard to believe with amd64 since the same driver runs on sparc64 fine (and must since many Sun machines have embedded sym controllers). Unfortunately it doesn't help that the sym driver has its own bizarre DMA management. It uses busdma but its kinda bolted on over the old memory-block management. Not going to make it any easier to debug. > P.S. I have ASUS A8V-E Deluxe with Athlon 64D. Can we get the dmesg from this system? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-stable Digest, Vol 136, Issue 3
On Tue, 22 Nov 2005, Rutger Bevaart wrote: > > There is no doubt that a lot of people have stable FreeBSD systems on Dell > hardware. The strange thing is though that there are also a lot of people > having problems with 1750's and 1850's (and therefore 2850's as well, as > they have an identical board). > > We have installed about 4 1750's and 8 1850/2850's in the last year and > _all_ except 1 of them have the "automatic reboot" feature (using 4_10, > 4_11, 5_3 and 5_4). We've had 1 lockup on the 1750 but have been unable to > trace that to a cause, might be unrelated. Strangely, the 1750 that does > ok is the one with the highest load (pushing several Mbits and an average > load >2) and running 5.3-RC3. I ran -CURRENT on a 1750 during performance tests in March -- that eventually became 6.0. Solid as a rock. You might look into putting RedHat or Windows on the machine and installing the Dell OpenManage Server Administrator and checking if its complaining about anything. These reboots could be caused by multibit ECC errors which would be logged to the hardware log. You can download OMSA from Dell's site if you go to the downloads page for the machine and select "Server Administration" as the category (I think -- they move that around). -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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-RELEASE: integer divide panic (trap 18) during install boot
On Mon, 21 Nov 2005 [EMAIL PROTECTED] wrote: > > Hi. I've got a system that's dying during the scsi probe of the > initial install boot. The console messages are along the lines of: > > [...usual boot stuff...] > vga0 > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > Timecounter [...] > Timecounters [...] > Waiting 15 seconds for SCSI > md0 preloaded image 4423680 bytes at 0xc0a34270 > da0 at bt0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > fatal trap 18: integer divide fault while in kernel mode Random guess: the disk is broken and is reporting its size as 0 bytes and CAM divides that value by 1024*1024 to get megabytes. Try removing or replacing the disk. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Mount related panic with FreeBSD 6?
On Sun, 20 Nov 2005, [UTF-8] V??clav Haisman wrote: > Hi, > I got this panic on freshly installed FreeBSD 6. I did this df -h and > noticed that /mnt/oldroot/home is somewhat mangled. The /mnt/oldroot is > root of FreeBSD 4.11 system. I successfully copied some settings and all > user accounts from that /mnt/oldroot/home earlier today. This is what I > did before the panic: [...] I discovered this by accident with a CDROM the other day. In 6.0 you can overlay read-only mounts (i.e., mount the same R/O FS on top of itself) but unmounting it will cause GEOM to tear down the underlying device while leaving the first mount behind. Next access to the mountpoint will panic the system. You can't mount a read/write mount on top of itself, or a r/o mount on a r/w mount -- you get an error. A quick discussion with phk points to a faulty or missing access check in GEOM. I'm not familiar with the VFS operations required to mount a filesystem, though, so I'm not sure where to look to put in the fix. In the interim, be careful not to mount a read-only FS multiple times. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6: ACPI-0698: *** Warning: Type override:
On Sat, 19 Nov 2005, Doug White wrote: > On Fri, 18 Nov 2005, Ricardo A. Reis wrote: > > > Hi all, > > > > > > Updating proxy server running 5.4, i resolve enable acpi,smp > > kernel to use HTT. > > You need to set > > machdep.hyperthreading_enabled="1" Sorry, this should be: machdep.hyperthreading_allowed="1" -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic: ad0: WARNING - removed from configuration
On Fri, 18 Nov 2005, Tom Jensen wrote: > Hi > > Seen this panic twice, there seems to be no pattern and I have no idea what > triggers this, is it failing hardware? Its certainly possible. Or a bad cable, or a bad firmware interaction. > System: FreeBSD 5.4-STABLE FreeBSD 5.4-STABLE #10: Sat Nov 5 17:14:46 CET > 2005 > > db> show msgbuf > msgbufp = 0xc101cfe4 > magic = 63062, size = 32740, r= 33501, w = 63892, ptr = 0xc1015000, cksum= > 3187082 > ad0: WARNING - removed from configuration > swap_pager: I/O error - pagein failed; blkno 5212,size 4096, error 0 > vm_fault: pager read error, pid 282 (syslogd) > <6>pid 282 (syslogd), uid 0: exited on signal 11 > ata0-master: FAILURE - WRITE_DMA timed out > initiate_write_filepage: already started > swap_pager: I/O error - pagein failed; blkno 6496,size 12288, error 6 > vm_fault: pager read error, pid 657 (courierlogger) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6: ACPI-0698: *** Warning: Type override:
On Fri, 18 Nov 2005, Ricardo A. Reis wrote: > Hi all, > > > Updating proxy server running 5.4, i resolve enable acpi,smp > kernel to use HTT. You need to set machdep.hyperthreading_enabled="1" in /boot/loader.conf, and make sure HyperThreading is enabled in your BIOS. The ACPI messages noted in the subject line are harmless. > dmesg output, > > Copyright (c) 1992-2005 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 6.0-STABLE #0: Fri Nov 18 12:53:50 BRST 2005 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.66GHz (2658.11-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 > > Features=0xbfebfbff > Features2=0x400 > Hyperthreading: 2 logical CPUs > real memory = 2147418112 (2047 MB) > avail memory = 2093625344 (1996 MB) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ACPI-0698: *** Warning: Type override - [DEB_] had invalid type > (Integer) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [MLIB] had invalid type > (Integer) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [DATA] had invalid type > (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [SIO_] had invalid type > (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [LEDP] had invalid type > (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [GPEN] had invalid type > (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [GPST] had invalid type > (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [WUES] had invalid type > (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [WUSE] had invalid type > (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [SBID] had invalid type > (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [SWCE] had invalid type > (String) for Scope operator, changed to (Scope) [snipped] -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "message too long" when sending broadcasts
On Wed, 16 Nov 2005, Michael Voucko wrote: > Hi, > > I'm trying to install the latest version of heartbeat (linux-ha), which > unfortunately is not available from the ports tree yet. > Setup is two boxes running (5.4-STABLE FreeBSD from Oct 17 2005) both > connected > to a hub with lnc NICs on a private 10.0.0.0/24 subnet (actually its only a > 'simulated hub' provided by VMWare if this matters). > > After some initial struggles configuration, build and installations works as > expected - but now the most basic parts of this application won't work > anymore. > When trying to use UDP broadcast messages for the heartbeat it would error out > with "Message too long" for packets larger than 1472 bytes, in other words as > soon as fragmentation of the package would be necessary (MTU is 1500). > > I received a code snippet from the heartbeat developers to isolate the problem > (create sender and receiver socket, send broadcast packets of a certain size). > To rule out VMware as the basic problem I tried real boxes but the problem > persists. > > Is there any size restriction for UDP broadcast messages? > Is there anything which prevents UDP broadcast from being fragmented? > > I searched RFCs, man pages for socket, setsockopt, ioctl, sendto and other > places but did not find anything that could explain the behaviour (which seems > to be no problem on other OS). > > Any pointers, comments? >From sendmsg(2): The address of the target is given by to with tolen specifying its size. The length of the message is given by len. If the message is too long to pass atomically through the underlying protocol, the error EMSGSIZE is returned, and the message is not transmitted. I remember debugging some funky behavior regarding fragmenting packets and UDPv6 some time ago. I don't remember if a fix was committed or not. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CF card and /dev filesystem entries
On Thu, 17 Nov 2005, Oliver Fromme wrote: > Brian Candler <[EMAIL PROTECTED]> wrote: > > However, when I insert a CF card with normal partioning I need /dev/da0s1, > > and this is not present in the /dev filesystem because the partition table > > has not been read. > > > > # mount -t msdos /dev/da0s1 /mnt/cf > > mount_msdosfs: /dev/da0s1: No such file or directory > > > > Just reading the first block is not sufficient: > > > > # dd if=/dev/da0 of=/dev/null count=1 > > 1+0 records in > > 1+0 records out > > 512 bytes transferred in 0.040984 secs (12493 bytes/sec) > > # mount -t msdos /dev/da0s1 /mnt/cf > > mount_msdosfs: /dev/da0s1: No such file or directory > > I think devfs is updated when a descriptor on the device > which was opended for writing is closed. But you don't > actually have to write anything. That means, the following > command should do it: > > # dd if=/dev/null of=/dev/da0 count=0 Or "fdisk da0" or "bsdlabel da0" or something like that :-) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Promise TX4300 boot problems
On Tue, 15 Nov 2005, Lawrence Farr wrote: > I've stuck a Promise TX4300 controller in to replace > the marvell onboard SATA that I can't boot off on a > Supermicro server. If I set 2 discs up as Raid 0 > or Raid 1 it's fine, But 4 discs as Raid 0+1 is detected, > installs without any problems, but hangs at the boot > loader with elf32_loadimage: read failed. I'm guesssing > the boot loader thinks it's a mirror, not a stripe and > fails to read past the first stripe on the disk? If this is the case then its a bug in the controller firmware; loader is just doing BIOS I/O calls. Check for a firmware update for your controller. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
umounting overlapping mount panics
Hey folks,
I accidentally mounted a CDROM over itself when installing X. OK, no
problem, umounted it and then started browsing the CD. Panic.
The panic output:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc05ffe4e
stack pointer = 0x28:0xda969ad4
frame pointer = 0x28:0xda969ae8
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 = 485 (csh)
trap number = 12
panic: page fault
The trace:
#0 doadump () at pcpu.h:165
#1 0xc0638202 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:399
#2 0xc0638498 in panic (fmt=0xc084e5a2 "%s")
at /usr/src/sys/kern/kern_shutdown.c:555
#3 0xc0807c30 in trap_fatal (frame=0xda969a94, eva=0)
at /usr/src/sys/i386/i386/trap.c:831
#4 0xc080799b in trap_pfault (frame=0xda969a94, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:742
#5 0xc08075d9 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1040124992, tf_esi =
0, tf_ebp = -627664152, tf_isp = -627664192, tf_ebx = -1027565108, tf_edx
= 2048, tf_ecx = 0, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip =
-1067450802, tf_cs = 32, tf_eflags = 66182, tf_esp = 1, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:432
#6 0xc07f6dca in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc05ffe4e in g_io_request (bp=0xc2c099cc, cp=0xc200f3c0)
at /usr/src/sys/geom/geom_io.c:259
#8 0xc0602399 in g_vfs_strategy (bo=0x1, bp=0xcbed1d68)
at /usr/src/sys/geom/geom_vfs.c:106
#9 0xc060a2d9 in cd9660_strategy (ap=0x1)
at /usr/src/sys/isofs/cd9660/cd9660_vnops.c:755
#10 0xc0817a49 in VOP_STRATEGY_APV (vop=0xc08bd320, a=0xda969b3c)
at vnode_if.c:1796
#11 0xc0681de8 in bufstrategy (bo=0xc1f883f0, bp=0x1) at vnode_if.h:928
#12 0xc067c78d in breadn (vp=0xc1f88330, blkno=0, size=2048, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0x1) at buf.h:415
#13 0xc067c6d0 in bread (vp=0xc1f88330, blkno=0, size=2048, cred=0x0,
bpp=0xda969bc8) at /usr/src/sys/kern/vfs_bio.c:719
#14 0xc0606be5 in cd9660_blkatoff (vp=0x800, offset=0, res=0x0,
bpp=0xda969c28)
at /usr/src/sys/isofs/cd9660/cd9660_lookup.c:406
#15 0xc0609db2 in cd9660_readdir (ap=0xda969c90)
at /usr/src/sys/isofs/cd9660/cd9660_vnops.c:513
#16 0xc0817754 in VOP_READDIR_APV (vop=0x1, a=0x800) at vnode_if.c:1427
#17 0xc0696e67 in getdirentries (td=0xc200e180, uap=0xda969d04)
at vnode_if.h:746
#18 0xc0807f47 in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 136507528, tf_esi =
-1078307728, tf_ebp = -1078347096, tf_isp = -627663516, tf_ebx =
672974052, tf_edx = 0, tf_ecx = 0, tf_eax = 196, tf_trapno = 22, tf_err =
2, tf_eip = 672447091, tf_cs = 51, tf_eflags = 582, tf_esp = -1078347140,
tf_ss = 59})
at /usr/src/sys/i386/i386/trap.c:976
#19 0xc07f6e1f in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:200
#20 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
Reproduction case:
mount /cdrom
mount /cdrom
ls /cdrom
umount /cdrom
ls /cdrom
*panic*
--
Doug White| FreeBSD: The Power to Serve
[EMAIL PROTECTED] | www.FreeBSD.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Strange boot messages under 6.0-STABLE
On Mon, 14 Nov 2005, Kris Kennaway wrote: > > That "reboot after panic" message is strange, because the box is running > > normally. > > Can someone plese tell me why I'm geting those messages. > > Your system panicked at some point in the past, but it can't save the > dump for the reason specified. Note that if you're never going to attempt to recover this crashdump you can clear it by running 'savecore -c'. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Consistent 6.0-STABLE Hang.
On Mon, 14 Nov 2005, Robert Watson wrote: > > I think you got it. After rebooting under a fresh 6.0-STABLE (build on > > Mon Nov 14 05:39:01 CET 2005), the problem didn't appear again... no > > more need for a serial console on this machine, i think :) > > Sounds like a good MFC candidate, assuming it can be MFC'd > non-disruptively. It's been MFC'd to RELENG_6 already, but I need to poll re@ on whether this merits an errata for 6.0-R. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 freezes shortly after logging in.
On Sun, 13 Nov 2005, Timm Florian Gloger wrote: > Hi list, > > I get some strange freezes with my fresh 6.0 installation. > > After booting for a several times now i got 2 more freezes in not > coherent periods of time after logging in. > > It is a complete freeze as far as i can explore, neither any keyboard > nor mouse input is noticed and keyboard "hangs" also (no numblock/ > shiftlock switching possible). > > I am able to access the fs through the other os so i checked the message > and other logfiles, but i cannot find any panic or other bad logentries. Try turning off background fsck by adding this to your rc.conf and rebooting: background_fsck="NO" -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hyperthreading issues.
On Fri, 11 Nov 2005, kama wrote: > Just upgraded from 5.4 to 6.0 and hyperthreading stoped working. > Everything looks ok, but it doesn't use two of the logical CPU's. This is disabled by default due to a information-leak vulnerability across the hyperthreaded cores. The details from the release notes: Because of an information disclosure vulnerability on processors using Hyper-Threading Technology (HTT), the machdep.hyperthreading_allowed sysctl variable has been added. It defaults to 1 (HTT enabled) on FreeBSD CURRENT, and 0 (HTT disabled) on the 4-STABLE and 5-STABLE development branches and supported security fix branches. More information can be found in security advisory FreeBSD-SA-05:09.htt. [MERGED] If you don't care about this, add machdep.hyperthreading_allowed="1" to /boot/loader.conf and reboot. > One other thing is when I try to switch off hyperthreading in BIOS, it > will hang at bootup when it are settling the scsi drives. After awhile it > will give me scsi timeouts. This only happens when I have two cpu enabled > and hyperthreading off. If I disable one cpu w ht off it will boot wo > problems, or two cpus w ht. But booting with ht + two cpu's gives me the > other problem. Sounds like the BIOS is not rerouting the interrupts correctly. Check for a BIOS update. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Crashing after umounting unavailable filesystems
On Thu, 10 Nov 2005, William Denton wrote: > On 10 November 2005, Michael C. Shultz wrote: > > >> Opps, I crashed the machine. When I moved it, I unplugged the > >> USB DVD-RW and I had mounted one of the dist discs on there. > >> When I did a umount it paniced. My bad. > > That happened to me the other day too. I'd mounted a USB flash drive, > unplugged the USB hub, replugged it, remounted the drive, and then of > course I couldn't umount the first mount. I did a umount -f and the > machine crashed instantly. > > Is this the sort of thing that's really hard to handle, or might it be > safer one day? I don't know how serious it is to do bad things to mounted > file systems, but I'm curious. Its Hard To Handle. :-) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Consistent 6.0-STABLE Hang
On Thu, 10 Nov 2005, Cy Schubert wrote: > Running the Citrix ICA wfcmgr (from ports) to change settings, e.g. > password, for connection to a Windows terminal server hangs FreeBSD 6.0 (as > of Nov 4) quite consistently. I've tried this on one of my 6.0 systems at > home and a 6.0 system here at work. I suspect it may have something to do > with Linux emulation however until I dig into this more I won't know for > sure. > > The only way to "unhang" the system is to press the reset switch. For fun, try updating to RELENG_6. I committed a fix recently for a hang thats caused by doing 'ls /dev' in the linuxulator. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Adaptec SATA 1210SA+ Freebsd 6.0
On Thu, 10 Nov 2005, Filip Wuytack wrote: > Hi, > > I also tried to create the label via the command line (following the > handbook). > > web2# dd if=/dev/zero of=/dev/ar0 count=2 > 2+0 records in > 2+0 records out > 1024 bytes transferred in 0.000757 secs (1352746 bytes/sec) > web2# disklabel /dev/ar0 | disklabel -B -R -r ar0 /dev/stdin > disklabel: /dev/ar0: no valid label found > > And the system freezes and shows 'ata2: DISCONNECT requested' I'd take a first guess that the disk attached to ata2 is having issues. Reseat and perhaps replace the cables. If that doesn't work then download and run the manufacturer's diagnostic tool and see if you can get that to error out. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 on VMWare 5.0: `calcru: negative runtime of -12728437 usec for pid 28 (irq17: lnc0)'
Adjusted cc: to remove private list. On Wed, 9 Nov 2005, Lev Serebryakov wrote: > Hello freebsd-stable, > > FreeBSD 6.0 on VMWare 5.0 prints such messages every 3-4 minute. > Also, messages like > > calcru: runtime went backwards from 40644816 to 40005944 usec for pid 3 (g_up) > > is shown routinely. Get used to it. VMWare does evil, evil things with the virtual machine clocks. We have problems with massive clock drift with Linux as the host and guest OSen. Comment out the printf and rebuild your kernel :-) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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 fails to find boot drive, then panics.
On Wed, 29 Jun 2005, Mike Meyer wrote: > In <[EMAIL PROTECTED]>, Doug White <[EMAIL PROTECTED]> typed: > > On Fri, 24 Jun 2005, Mike Meyer wrote: > > > > > I'm trying to install 5.4-RELEASE off of CDROM on an ASUS P5S800 > > > motherboard > > > with a SATA drive in it. The SATA drive shows up as ad4 during the install > > > process, and the install goes just fine. > > > > > > But the resulting system fails to boot. It goes through the boot sequence, > > > draws the cute 5.x booto menu, then issues the messages: > > > > > > Can't work out which disk we are booting from. > > > Guessed BIOS device 0x not found by probes, defaulting to disk0: > > > > > > panic: free: guard1 fail @0x5195c from > > > /usr/src/sys/boot/i386/loader/../../common/module.c:957 > > > --> Press a key on the console to reboot <-- > > > > > > Booting with debug messages doesn't change this at all. > > > > This is in the loader. Your machine is seriously messed up. I'd suggest > > checking for a BIOS update. Also try rearranging your ATA channels and > > disabling DMA mode for the ATA controllers in the BIOS setup. > > I figured that out. Since writing the original message, I managed to > get the thing (mostly) working by hacking the loader to wire down the > values for the boot drive rather than having it probe for them. > > > Unfortunately ASUS boards of this type are known to have braindamaged > > ACPI, so this is only the beginning of a long, painful journey. :( > > How far does turning off ACPI in the BIOS go towards solving these > problems? I'd be surprised if it does much, if anything. Reportedly, the machine doesn't boot. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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 fails to find boot drive, then panics.
On Fri, 24 Jun 2005, Mike Meyer wrote: > I'm trying to install 5.4-RELEASE off of CDROM on an ASUS P5S800 motherboard > with a SATA drive in it. The SATA drive shows up as ad4 during the install > process, and the install goes just fine. > > But the resulting system fails to boot. It goes through the boot sequence, > draws the cute 5.x booto menu, then issues the messages: > > Can't work out which disk we are booting from. > Guessed BIOS device 0x not found by probes, defaulting to disk0: > > panic: free: guard1 fail @0x5195c from > /usr/src/sys/boot/i386/loader/../../common/module.c:957 > --> Press a key on the console to reboot <-- > > Booting with debug messages doesn't change this at all. This is in the loader. Your machine is seriously messed up. I'd suggest checking for a BIOS update. Also try rearranging your ATA channels and disabling DMA mode for the ATA controllers in the BIOS setup. Unfortunately ASUS boards of this type are known to have braindamaged ACPI, so this is only the beginning of a long, painful journey. :( -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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 Installer + Promise FT100TX2 = Loader crash
On Sun, 26 Jun 2005, Mark Kirkwood wrote: > Daniel O'Connor wrote: > > > > > I find even disconnecting the drives so no RAID is detected works - ie it's > > not the presence of the card per se that is a problem. > > > > Good test - I had not tried that. > > In addition, I can confirm your observation that merely deleting the > array makes the loader work reliably again. Try: . Zero off the first megabyte or so of the subdisks with dd or similar tool. . Force an array initialize from the controller BIOS. Wait for it to finish. . Install some other OS that recognizes the array, write the MBR and partition table, then install FreeBSD over it. Some controller BIOSen have been known to peek at the DOS partition table, and it may be jumping off into space if its seeing half a table from one disk, or something like that. These actions should blow away any bogus underlying data. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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-p1 crash
On Sat, 25 Jun 2005, Mitch Parks wrote: > On Sun, 19 Jun 2005, Robert Watson wrote: > > >> there is a PR for it : kern/74319 > > > > This sounds very similar to a serial console related tty bug I was > > experiencing on -STABLE a few months ago, and that is believed may have been > > worked around in 5.4 tweaks before release. In particular, that there are > > reference counting related bugs in the 5.x tty code that are fixed by a > > partial rewrite of the tty code in 6.x, but that are too large and > > disruptive > > to merge to RELENG_5. If the problem is persisting, it may be worth trying > > to merge anyway, but it is a pretty big change and would break device driver > > binary compatibility, etc. What we might want to do here is wait until 6.x > > has settled out a bit more, then consider merging it to 5.x once 6.x has > > gotten burned in with similar workloads and continued to not illustrate the > > 5.x tty reference bugs. > > On Fri, 24 Jun 2005, Doug White wrote: > > > I've run out of time to debug this, unfortunately... > > I went back to reports I made in January about 5.3: > http://lists.freebsd.org/pipermail/freebsd-stable/2005-January/010898.html > which appears to be the same issue. I _thought_ this was resolved when I > disabled HT, but maybe I was just lucky between the last reboot and the 5.4 > upgrade. > > It sounds like there's a reasonable chance this has been squashed in code > for 6.0? Since this box is already unstable, I'd be tempted to be an early 6 > adopter to see if it is actually resolved. Especially so if that would be > helpful to the cause. 6.x is not affected by the tty-related problems that 5.x is having. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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-p1 crash
On Mon, 20 Jun 2005, Philippe PEGON wrote:
> Philippe PEGON wrote:
> > Mitch Parks wrote:
> >
> >> On Sun, 19 Jun 2005, Doug White wrote:
> >>
> >>> On Fri, 17 Jun 2005, Mitch Parks wrote:
> >>>
> >>>> Below are details regarding another crash on a Dell 2600 SMP (HTT
> >>>> and USB
> >>>> disabled). It has been 9 days since the last crash. I didn't have
> >>>> the serial
> >>>> console in place for this last crash, but it is now.
> >>>
> >>>
> >>>
> >>> As noted, the ttwakeup() panic is a known bug. The best thing we have
> >>> for
> >>> a fix is this patch:
> >>>
> >>> http://people.freebsd.org/~mlaier/tty.t_pgrp.diff
> >>>
> >>> Please give it a try and report back if you have any more panics (or
> >>> don't :-) ).
> >>
> >>
> >>
> >> Thanks! This patch appears to be for 5.3, but I manually applied the
> >> chunk of the patch that didn't apply cleanly and the countdown is on.
> >>
> >> I'll report back in 10 days unless something bad happens before then.
> >>
> >> Below is the patch chunk #10 that I actually applied rather than the
> >> one given. If I've done something bad here by removing the PGRP_LOCK
> >> please let me know.
> >
> >
> > I'm not a kernel developper, but if you remove
> >
> > PGRP_LOCK(tp->t_pgrp);
> >
> > and the PGRP_UNLOCK(tp->t_pgrp) in the if condition (removed by the
> > orginal patch)
> >
> > there is maybe another "PGRP_UNLOCK(tp->t_pgrp);" to remove if the if
> > condition doesn't match, line 2528 in the original 5.4-p1 tty.c ?
>
> after having applied the patch (with your modification), there is no
> "sx_sunlock(&proctree_lock)" in the ttyinfo function if the three
> conditions failed. Maybe we have just to replace
> "PGRP_UNLOCK(tp->t_pgrp);" line 2528 by "sx_sunlock(&proctree_lock)" ?
> I think that we need the helps of a kernel developper.
No, that would be a leaked lock, which would cause hangs. More likely its
some other case that got missed that needs locks extended to it, or the
aliased pgrp isn't the underlying problem.
I've run out of time to debug this, unfortunately...
>
> >
> >>
> >>
> >> Hunk #6 succeeded at 1154 (offset -51 lines).
> >> Hunk #7 succeeded at 1215 (offset -6 lines).
> >> Hunk #8 succeeded at 1203 (offset -51 lines).
> >> Hunk #9 succeeded at 1946 (offset -5 lines).
> >> Hunk #10 failed at 2562.
> >> Hunk #11 succeeded at 2847 (offset -212 lines).
> >> 1 out of 11 hunks failed--saving rejects to tty.c.rej
> >>
> >>
> >> @@ -2495,19 +2511,21 @@
> >> * On return following a ttyprintf(), we set tp->t_rocount to
> >> 0 so
> >> * that pending input will be retyped on BS.
> >> */
> >> + sx_slock(&proctree_lock);
> >> if (tp->t_session == NULL) {
> >> + sx_sunlock(&proctree_lock);
> >> ttyprintf(tp, "not a controlling terminal\n");
> >> tp->t_rocount = 0;
> >> return;
> >> }
> >> if (tp->t_pgrp == NULL) {
> >> + sx_sunlock(&proctree_lock);
> >> ttyprintf(tp, "no foreground process group\n");
> >> tp->t_rocount = 0;
> >> return;
> >> }
> >> - PGRP_LOCK(tp->t_pgrp);
> >> - if ((p = LIST_FIRST(&tp->t_pgrp->pg_members)) == 0) {
> >> - PGRP_UNLOCK(tp->t_pgrp);
> >> + if ((p = LIST_FIRST(&tp->t_pgrp->pg_members)) == NULL) {
> >> + sx_sunlock(&proctree_lock);
> >> ttyprintf(tp, "empty foreground process group\n");
> >> tp->t_rocount = 0;
> >> return;
> >>
> >> Or the complete patch:
> >> http://kuoi.asui.uidaho.edu/~mitch/crash/tty_5.4.patch
> >>
> >> Mitch Parks
> >> [EMAIL PROTECTED]
> >> ___
> >> freebsd-stable@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> >
> >
>
>
>
--
Doug White| FreeBSD: The Power to Serve
[EMAIL PROTECTED] | www.FreeBSD.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird fdisk behavior
On Sat, 18 Jun 2005, Baldur Gislason wrote: > I am trying to add another partition to my root drive, it has a few gigabytes > of unpartitioned space. > Whenever I try to run fdisk -u it says cannot open disk /dev/ad0: No such > file or directory > ad0 does exist, why does fdisk say otherwise? fdisk can display the partition > table but it can't alter it. > securelevel is -1 and this is FreeBSD 5.4-STABLE from the beginning of May > this year. Be aware that fdisk will fake up a partition table if the volume has no table. Look for a message like: warning: invalid partition table found If you see that then there is no FDISK partition table. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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-p1 crash
On Fri, 17 Jun 2005, Mitch Parks wrote: > Below are details regarding another crash on a Dell 2600 SMP (HTT and USB > disabled). It has been 9 days since the last crash. I didn't have the serial > console in place for this last crash, but it is now. As noted, the ttwakeup() panic is a known bug. The best thing we have for a fix is this patch: http://people.freebsd.org/~mlaier/tty.t_pgrp.diff Please give it a try and report back if you have any more panics (or don't :-) ). -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.11 panic #2, need help decoding
On Sun, 5 Jun 2005, Charles Sprickman wrote: > Hello, > > Second panic on this box in less than two weeks. Can someone help me > figure out whether this looks to be a hardware issue or not? Am I on the > correct list for this type of problem? You're in the right spot all right... > Previous info is at: > http://thread.gmane.org/gmane.os.freebsd.stable/28428 (no followups) > > Here's what gdb has for me this time: Can you go to frame 38 and print the value of "source"? Comparing it to NULL shouldn't cause a fault, but I suspect its another one of the cases in that if statement. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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 RELEASE atkbdc0 problem
On Sun, 5 Jun 2005, Remi Regruson wrote: > Hi, > > I put the folowing line in /boot/loader.conf : > usb_load="yes" > ukbd_load="yes" > This haven't done what I exepted : my usb keyboard don't work during the > loader prompt and now I can't boot. The kernel message stop with this line: If you want your USB keyboard to work in loader you need to enable "USB Legacy" in the BIOS. > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > I have the same log with or without : any keyboard(ps2 or usb), usb or apm > activating in the bios. FreeBSD can only handle input from one keyboard at a time. By default the first keyboard attached wins, which is atkbd. You have a few options: 1. Edit /boot/device.hints and remove the hint.atkbd.0.flags line, reboot, and unplug the PS/2 keyboard before the kernel starts. Unless your BIOS fakes up a keyboard it should keep atkbd0 from attaching and therefore let the USB keyboard take over kbd0. 2. Add a line to /etc/usbd.conf that calls kbdcontrol -k kbd1 < /dev/console when a USB keyboard is attached. This selects the USB keyboard as the active keyboard. If kbd1 goes away (by unplugging the USB keyboard) it'll fall back to the PS/2 keyboard. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: RELENG_5 panic
On Mon, 23 May 2005, Robin P. Blanchard wrote:
> Here's what I could get out of dmesg, and looking again at the dump
>
> # dmesg -M /usr/local/var/adm/crash/vmcore.44 -N /boot/kernel/kernel
> kernel trap 12 with interrupts disabled
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x24
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc0504808
> stack pointer = 0x10:0xc7ac0c08
> frame pointer = 0x10:0xc7ac0c3c
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= resume, IOPL = 0
> current process = 27 (swi5: clock sio)
> trap number = 12
> panic: page fault
> cpuid = 0
> Uptime: 3d6h59m25s
> Dumping 127 MB
> 16 32 48 64 80 96 112
>
> [EMAIL PROTECTED] [/usr/obj/usr/src/sys/fastipsec]# kgdb kernel.debug
> /usr/local/var/adm/crash/vmcore.44
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
> Undefined symbol "ps_pglobal_lookup"]
> 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 doadump () at pcpu.h:160
> 160 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) l *0xc0504808
> 0xc0504808 is in turnstile_wait (/usr/src/sys/kern/subr_turnstile.c:245).
> 240 /*
> 241 * Pick up the lock that td is blocked on.
> 242 */
> 243 ts = td->td_blocked;
> 244 MPASS(ts != NULL);
> 245 tc = TC_LOOKUP(ts->ts_lockobj);
> 246 mtx_lock_spin(&tc->tc_lock);
> 247
> 248 /*
> 249 * This thread may not be blocked on this turnstile
> anymore
> (kgdb)
Oh another of these wonderful races... can you go to that frame and "print
ts"? If its NULL then someone has ripped out the ts out from under us
since it was checked for NULL in the previous line!
>
> > -Original Message-
> > From: Doug White [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, May 22, 2005 3:20 PM
> > To: Robin P. Blanchard
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: RELENG_5 panic
> >
> > On Sat, 21 May 2005, Robin P. Blanchard wrote:
> >
> > > # uname -a
> > > FreeBSD robinpb.homeip.net 5.4-STABLE FreeBSD 5.4-STABLE
> > #0: Tue May
> > > 17
> > > 00:30:47 EDT 2005
> > > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/fastipsec i386
> > >
> > > # kgdb kernel.debug /usr/local/var/adm/crash/vmcore.44
> > > [GDB will not be able to debug user-mode threads:
> > /usr/lib/libthread_db.so:
> > > Undefined symbol "ps_pglobal_lookup"]
> > > 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 doadump () at pcpu.h:160
> > > 160 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> > > (kgdb) bt full
> > > #0 doadump () at pcpu.h:160
> > > No locals.
> > > #1 0xc04dd58c in boot (howto=260) at
> > /usr/src/sys/kern/kern_shutdown.c:410
> > > first_buf_printf = 1
> > > #2 0xc04ddccd in panic (fmt=0xc066e594 "%s") at
> > > /usr/src/sys/kern/kern_shutdown.c:566
> > > bootopt = 260
> > > newpanic = 0
> > > buf = "page fault", '\0'
> >
> > can you try to fish the trap output from msgbuf? That or use
> > dmesg's -N and -M options to extract it from the crashdump.
> >
> > > #3 0xc0641e92 in trap_fatal (frame=0xc7ac0bc8, eva=36) at
> > > /usr/src/sys/i386/i386/trap.c:817
> > > code = 16
> > > type =
Re: Diskless boot problem
On Mon, 23 May 2005, [ISO-8859-2] S�awek �ak wrote: > > > > > Hi, > > > > > > I have a problem with booting Dell 2850 over network. The machine reads > > > > kernel over net, boots upto mounting / from NFS and then crashes. > > > > > > What is the NFS server? It seems to think the NFS handle we pulled the > > > kernel with is no longer valid. > > > FreeBSD 5.3/5.4-STABLE. > > Hm ... dunno then ... does the server complain about the client at all in > the log? >No complaints whatsoever.The exact os version on NFS server is 5.4-RC2. All I can suggest is trying rebooting the NFS server. Something in it must have lost communication. If that doesn't fix it then I have no idea, it must be specific to your situation. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.3 forgets some of my users
On Sun, 22 May 2005, [ISO-8859-1] Kövesdán Gábor wrote: > Thanks for your suggestion. I use 'files' lookup. As You wrote I checked > the syntax with pwd_mkdb -C /etc/passwd' and it returned nothing. Then I > did a rebuild with -p, and now it seems to be okay, the two accounts > that had gone away are working now. Okay, perhaps the password database files had become corrupted. > > Anyway I haven't changed the nsswitch.conf, I have the default one: > > [EMAIL PROTECTED] less /etc/nsswitch.conf > group: compat > group_compat: nis > hosts: files dns > networks: files > passwd: compat > passwd_compat: nis > shells: files Looks right. A database problem would make sense. > > Cheers, > > Gábor Kövesdán > > > >What are you using for user lookups? Are you using nss_ldap or something > >other than the default 'files' lookup? Can you post the contents of > >/etc/nsswitch.conf? > > > >I'd also check your master.passwd file for any syntax errors or odd > >characters and then force a rebuild with: > > > >pwd_mkdb -p /etc/master.passwd > > > >as root. > > > > > > > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell PowerEdge 1855
On Sun, 22 May 2005, Danny Braniss wrote: > > > Hi Doug, > > > > > > Sorry for taking so long to reply on this, been on 3 weeks leave... > > > > > > On Fri, 8 Apr 2005, Doug White wrote: > > > > > > > On Wed, 6 Apr 2005, Carl Makin wrote: > > > > > > > > The boot sequence will hang if the USB drive is attached at boot. > > > > > There > > > > > > > It seems to be acting like Uthe USB controller isn't getting interrupts. > > > > Does the problem recur on the installed system? > > > > > > Yes it did however that chassis and the servers were a test loaner and > > > have been returned. We have decided to go with the 1855 though (our > > > windows guy was *very* enthusiastic about them) and when they arrive I'll > > > run the tests you suggested. > > > > > > Thanks! > > > > so now i'm testing one too :-), any nice things to say about this blade? > > while trying out the scsi the blade panics :-) > > and as to cpu/memory power, it seems to be slower than the pe-1750 > > > > danny > > nothing like talking to oneself :-) > > i disabled the mirrowing, and now the disk io is nice, and more importanly, > the > system does not panic, i guess the mpt/(aka da0: 1998>) needs some work still :-) The mpt driver has some issues. I have an IBM machine that freaks out similiarly if the integrated mirroring is enabled. However IM works properly on other machines, so YMMV :) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can't assign requested address with ntpd on 5-STABLE
On Sun, 22 May 2005, Richard Coleman wrote: > On 5-STABLE, when I try to start ntpd, I get the following error: bind() > fd 7, family 28, port 123, addr fe80:1::2a0:c9ff:fec8:ea25, > in6_is_addr_multicast=0 flags=0 fails: Can't assign requested address > > I've used netstat to check and nothing else is on that port (other than > sshd, there is nothing else on the box). This is normal; its trying to bind to the ipv6 address and you probably don't have one defined or have ipv6 disabled. It can be safely ignored. I think on later -STABLE its been disabled. Unless you _want_ to bind to the v6 address :) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Highpoint HPT371 support (kern/59624)
On Sun, 22 May 2005, Oliver Fromme wrote: > Why is kern/59624 still open? It's about 1,5 years old. > Would someone please commit it? Or, if it cannot be > commited, please tell me why. If any information is > missing (pcicon -lv output, verbose dmesg or whatever), > I'd be happy to provide it. You may want to track down Doug Ambrisko, who has a big stack of ata patches he's been carting around. I don't know if he committed that set or not. RELENG_4 is pretty much dead development-wise -- there will be no more 4.x releases -- so finding someone to commit this for you will be difficult. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_5 panic
trampoline () at > /usr/src/sys/i386/i386/exception.s:209 > No locals. > (kgdb) > > > > --- > Robin P. Blanchard > Systems Integration Specialist > Georgia Center for Continuing Education > fon: 706.542.2404 <-> fax: 706.542.6546 > --- > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Diskless boot problem
On Sat, 21 May 2005, [ISO-8859-2] S³awek ¯ak wrote: > On 5/20/05, Doug White <[EMAIL PROTECTED]> wrote: > Please try to avoid sending your message bodies base64 encoded :) My mail > client got really confused by it and didn't quote the message properly. > > Also stripping hackers cc:. I'd like to, but Gmail doesn't offer this option. Sorry :( > On Thu, 19 May 2005, [ISO-8859-2] S³awek ¯ak wrote: > > > Hi, > > > > I have a problem with booting Dell 2850 over network. The machine reads > > > kernel over net, boots upto mounting / from NFS and then crashes. > > > > What is the NFS server? It seems to think the NFS handle we pulled the > > kernel with is no longer valid. > FreeBSD 5.3/5.4-STABLE. Hm ... dunno then ... does the server complain about the client at all in the log? >> Does PXE and the system itself end up pulling different IP addresses? > No. The IP is the same. dunno ... -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nForce 4, SATA Drive only runs at UDMA33?
On Fri, 20 May 2005, alan bryan wrote: > > --- Doug White <[EMAIL PROTECTED]> wrote: > > Can you post the output of "pciconf -lv"? The nForce > > IDE controller is > > properly detected, but it looks like there's another > > one in the system. > > Looking at the spec for the system it may be the > > proprietary nVidia RAID > > controller. The pciconf output should help us > > identify if thats the > > issue. > > FYI: RAID features are disabled in the BIOS, I'm just > trying to get a single SATA drive to work at full > speed. The other drive in this system is IDE and that > seems to be working at proper speed. Thanks for the > help! I guess turning off the RAID converts the chips into standard SATA controllers. I'll have to look into that. An nForce 4 machine recently appeared at work, so I'll see what I can get it to do. > [EMAIL PROTECTED]:6:0: class=0x01018a card=0x50361297 > chip=0x005310de rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > class= mass storage > subclass = ATA > [EMAIL PROTECTED]:7:0: class=0x010185 card=0x50361297 > chip=0x005410de rev=0xa3 hdr=0x00 > vendor = 'NVIDIA Corporation' > class= mass storage > subclass = ATA > [EMAIL PROTECTED]:8:0: class=0x010185 card=0xcb8410de > chip=0x005510de rev=0xa3 hdr=0x00 > vendor = 'NVIDIA Corporation' > class= mass storage > subclass = ATA It looks like sos added support for atapci1 and 2 in this listing in the ATAmkIII patchset. While that patchset is in -CURRENT you'll have to apply the -stable patches yourself. Search the list archives for the location, soren posts it now and again. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.3 forgets some of my users
Stripping -bugs and -current cc; this applies to -stable and isn't in reference to an existing PR. On Sat, 21 May 2005, [ISO-8859-1] Kövesdán Gábor wrote: > Hello there, > > there is a strange thing FreeBSD 5.3 randomly frogets some of my > users. Sometimes I see in the first column of the ps aux output the uid > number instead of the login name, but next when I run it, there is the > login name. Besides, I tried to chown a directory to an existing user, > but the I get an error message, that there wasn't such user. What are you using for user lookups? Are you using nss_ldap or something other than the default 'files' lookup? Can you post the contents of /etc/nsswitch.conf? I'd also check your master.passwd file for any syntax errors or odd characters and then force a rebuild with: pwd_mkdb -p /etc/master.passwd as root. > I immediately checked passwd, group and master.passwd files in /etc but > the entry for that user was present there. The pw userdel was unable to > delete that user, so I had to manually remove it from those three files > and create it again. It worked then, but a bit later there was the same > result. I'm quite annoyed now. This state isn't safe enough, I have to > do something to get around with this. Do You have similar experiences? > Or do You now some kinda workaround? > > Cheers, > > Gábor Kövesdán > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Diskless boot problem
Please try to avoid sending your message bodies base64 encoded :) My mail client got really confused by it and didn't quote the message properly. Also stripping hackers cc:. On Thu, 19 May 2005, [ISO-8859-2] S³awek ¯ak wrote: > Hi, > I have a problem with booting Dell 2850 over network. The machine reads > kernel over net, boots upto mounting / from NFS and then crashes. What is the NFS server? It seems to think the NFS handle we pulled the kernel with is no longer valid. Does PXE and the system itself end up pulling different IP addresses? (rest of original email follows) Tcpdump output: 12:15:58.919683 arp who-has 10.158.190.73 tell 10.158.190.74 12:15:58.919702 arp reply 10.158.190.73 is-at 00:11:43:d3:6e:e1 12:15:58.920058 IP 10.158.190.74.475209176 > 10.158.190.73.2049: 92 getattr [|nfs] 12:15:58.920134 IP 10.158.190.73.2049 > 10.158.190.74.475209176: reply ok 28 getattr ERROR: Stale NFS file handle 12:15:58.920432 arp who-has 10.158.190.73 tell 10.158.190.74 12:15:58.920442 arp reply 10.158.190.73 is-at 00:11:43:d3:6e:e1 12:15:58.920681 IP 10.158.190.74.475209177 > 10.158.190.73.2049: 100 lookup [|nfs] 12:15:58.920707 IP 10.158.190.73.2049 > 10.158.190.74.475209177: reply ok 28 lookup ERROR: Stale NFS file handle 12:15:58.920932 IP 10.158.190.74.475209178 > 10.158.190.73.2049: 100 lookup [|nfs] 12:15:58.920963 IP 10.158.190.73.2049 > 10.158.190.74.475209178: reply ok 28 lookup ERROR: Stale NFS file handle 12:15:58.952180 IP 10.158.190.74.475209179 > 10.158.190.73.2049: 100 lookup [|nfs] 12:15:58.952277 IP 10.158.190.73.2049 > 10.158.190.74.475209179: reply ok 28 lookup ERROR: Stale NFS file handle 12:15:58.984785 IP 10.158.190.74.475209180 > 10.158.190.73.2049: 100 lookup [|nfs] 12:15:58.984866 IP 10.158.190.73.2049 > 10.158.190.74.475209180: reply ok 28 lookup ERROR: Stale NFS file handle 12:15:59.020500 IP 10.158.190.74.475209181 > 10.158.190.73.2049: 104 lookup [|nfs] 12:15:59.020573 IP 10.158.190.73.2049 > 10.158.190.74.475209181: reply ok 28 lookup ERROR: Stale NFS file handle 12:15:59.054130 IP 10.158.190.74.475209182 > 10.158.190.73.2049: 104 lookup [|nfs] 12:15:59.054224 IP 10.158.190.73.2049 > 10.158.190.74.475209182: reply ok 28 lookup ERROR: Stale NFS file handle I wonder where the `Stale NFS handle' error comes from, as the client doesn't seem to have mounted the filesystem over NFS from what I can see. On the console of the diskless I have this: NFS ROOT: 10.158.190.73:/var/www/FreeBSD-5.4-x86-PXE em0: Link is up 100 Mbps Half Duplex exec /sbin/init: error 70 exec /sbin/oinit: error 70 exec /sbin/init.bak: error 70 exec /rescue/init: error 70 exec /stand/sysinstall: error 70 init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall panic: no init Uptime: 55s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort The speed for em0 is obviously wrong. Setting on the switch is 100 full-duplex. Our network wizards can f***kup autonegotiation on Cisco Catalyst, so it must stay that way. Intel em-s tend to hang for a couple of seconds before getting on the net so it might be the problem. On the other hand kernel loads just fine over TFTP. Any thoughts? Thanks, /S -- S³awek ¯ak / UNIX Systems Administrator -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nForce 4, SATA Drive only runs at UDMA33?
id 0x1c type 4 at > 0xb60 > ata5: reset tp1 mask=03 ostat0=7f ostat1=7f > ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff > ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff > ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff > ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff > ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff > ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff > ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff > ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff > ata5-slave: stat=0x7f err=0xff lsb=0xff msb=0xff > ata5: reset tp2 stat0=ff stat1=ff devices=0x0 > ata5: [MPSAFE] > > Any hints/ideas for what I can do to make the most of > my new hardware? > > Thanks, > Alan Bryan > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SATA378 / SATA150 RAID controller supported by 5.4?
On Wed, 18 May 2005, Rob wrote: > > --- Doug White <[EMAIL PROTECTED]> wrote: > > On Tue, 17 May 2005, Rob wrote: > > > > > The 'pciconf -lv' tells me: > > > > > > [EMAIL PROTECTED]:4:0: class=0x010400 card=0x80f51043 > > >chip=0x3373105a rev=0x02 hdr=0x00 > > > vendor = 'Promise Technology Inc' > > > device = 'PDC20378 FastTrak 378/SATA 378 > > > RAID Controller' > > > class= mass storage > > > subclass = RAID > > > > > > But I get this in my dmesg output: > > > > > > atapci0: > > > port 0xd880-0xd8ff,0xdfa0-0xdfaf,0xdf00-0xdf3f > > > mem 0xfeac-0xfead,0xfeafe000-0xfeafefff > > > irq 10 at device 4.0 on pci2 > > > atapci0: failed: rid 0x20 is memory, requested 4 > > > > That's the PCI busmaster register, although it > > seems to be the wrong resource type. It should be > > I/O space, which maps to PCI config space, and > > not memory-mapped. I can't seem to find what > > function emits that message. > > > > A full dmesg would be useful. > > It's at: > http://surfion.snu.ac.kr/~lahaye/dmesg.boot > > Does that help? Yes .. your system has 2 ATA controllers. The RID failure is probably normal if the other one is present. The ICH5 southbridge ATA controller has grabbed the "standard" ports and the Promise ports stack in behind. To answer the question, yes the Promise controller is supported. You'll need to connect disks to it if you want to use it though :) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with ASR card/5.4
On Wed, 18 May 2005, Bruce Burden wrote: > > > >Hi Doug, > > well, pulling cards demonstrated where the problem lie, but it >was not a hardware problem. By chance, I happened upon the "options >ASR_COMPAT" directive, and that solved my problem. However, the >GENERIC kernel configuration for i386 does NOT have this option, but >it does have the "asr" driver configured. ASR_COMPAT controls some sizes of fields for use with the control ioctl. I don't think this would case problems on boot unless you are running an old control program at boot time, or whenever the panic occurs. > Having one but not the other causes problems, as I discovered. > > Bruce > > > On Wed, May 18, 2005 at 04:03:56PM -0700, Doug White wrote: > > On Mon, 16 May 2005, Bruce Burden wrote: > > > > > > > > > > > Hi folks, > > > > > > I am trying to get my Adaptec 3210S RAID running under 5.4, > > > and all I get for my trouble is pmap_ errors. Sorry, no dumps at > > > the moment. > > > > > > If I compile "device asr" into the kernel, I get a message > > > about "could not copy LDT", and a panic about "pmap_enter: > > > invalid page directory" when the system moves from single to multi > > > user. (single user is no problem?) > > > > > > If I do not compile the asr driver, and "kldload asr" instead, > > > I get a panic from pmap_mapdev, instead. > > > > > > Any ideas? This is annoying, and I am seriously considering > > > returning to 4.11, where asr was working... > > > > This sounds like your system has severe memory corruption issues. I'd try > > a different PCI slot for your asr card first, then try the card in another > > known working system and see if your problems appear there. > > > > Have you tested the system without the asr card installed? > > > > -- > > Doug White| FreeBSD: The Power to Serve > > [EMAIL PROTECTED] | www.FreeBSD.org > > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Boot loader cant identify ntfs?
On Wed, 18 May 2005, Matthias Buelow wrote: > Dan Nelson wrote: > > > The next release should: > > RCS file: /home/ncvs/src/sys/boot/i386/boot0/boot0.S,v > [...] > > Obviously the Right Way of doing such things is to move this into the > 2nd stage boot loader... I can't think of any reason (except quick > hackery) why this hasn't been done that way. I mean, one could retain a > simple choice of which disk/partition to boot in the 1st stage (to cover > all eventualities), and maybe hide it by having to hit a key, and do the > real menu in the 2nd stage, perhaps integrated with the kernel options > boot menu. Then the space problem just migrates. There's a limited amount of space in the disklabel for bootblocks and I think we're pushing that. If you want pretty menus, there's a large number of boot managers available. Someone showed me one at BSDcan and I don't recall the name offhand. Even had beastie icons. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SATA378 / SATA150 RAID controller supported by 5.4?
On Tue, 17 May 2005, Rob wrote: > > Hi, > > The 'pciconf -lv' tells me: > > [EMAIL PROTECTED]:4:0: class=0x010400 card=0x80f51043 > chip=0x3373105a rev=0x02 hdr=0x00 > vendor = 'Promise Technology Inc' > device = 'PDC20378 FastTrak 378/SATA 378 RAID > Controller' > class= mass storage > subclass = RAID > > But I get this in my dmesg output: > > atapci0: > port 0xd880-0xd8ff,0xdfa0-0xdfaf,0xdf00-0xdf3f > mem 0xfeac-0xfead,0xfeafe000-0xfeafefff > irq 10 at device 4.0 on pci2 > atapci0: failed: rid 0x20 is memory, requested 4 That's the PCI busmaster register, although it seems to be the wrong resource type. It should be I/O space, which maps to PCI config space, and not memory-mapped. I can't seem to find what function emits that message. A full dmesg would be useful. > rl0: > port 0xd000-0xd0ff > mem 0xfeaff400-0xfeaff4ff > irq 10 at device 9.0 on pci2 > > At present I use a single harddisk on the regular > IDE connector (atapci1 UDMA100-controller). > > Is the RAID controllor on atapci0 supported by 5.4? > What is the 'failed' message about in dmesg? It seems to be a bit error... > Also note the seemingly interrupt conflict of both, > rl0 and atapci0, claiming irq 10 ?!?! Thats normal for PIC mode. PCI cards can share interrupts, but ISA can't share with anything else, including other ISA cards. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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-RC3 crash report
On Tue, 17 May 2005, Cedric Tabary wrote: > On 17/05/2005 17:54, Cedric Tabary wrote: > > FreeBSD 5.4-RC3 i386, no SMP compiled in kernel > > dmesg atached > > Oops forgot the dmesg ;) Panic & trap messages would be nice too, so we know what address is exploded on. > > Copyright (c) 1992-2005 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.4-RC3 #1: Thu Apr 21 10:01:03 CEST 2005 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CED > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.01-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 > > Features=0xbfebfbff > Hyperthreading: 2 logical CPUs > real memory = 1073479680 (1023 MB) > avail memory = 1040789504 (992 MB) > ACPI APIC Table: > ioapic0: Changing APIC ID to 2 > ioapic1: Changing APIC ID to 3 > ioapic1: WARNING: intbase 32 != expected base 24 > ioapic2: Changing APIC ID to 4 > ioapic2: WARNING: intbase 64 != expected base 56 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 32-55 on motherboard > ioapic2 irqs 64-87 on motherboard > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 0.0 on pci1 > pci2: on pcib2 > amr0: mem > 0xdfee-0xdfef,0xd80f-0xd80f irq 46 at device 14.0 on pci2 > amr0: Firmware 513O, BIOS H418, 256MB RAM > pcib3: at device 0.2 on pci1 > pci3: on pcib3 > pcib4: at device 4.0 on pci0 > pci4: on pcib4 > pcib5: at device 5.0 on pci0 > pci5: on pcib5 > pcib6: at device 0.0 on pci5 > pci6: on pcib6 > em0: port > 0xecc0-0xecff mem 0xdfbe-0xdfbf irq 64 at device 7.0 on pci6 > em0: Ethernet address: 00:11:43:36:39:e5 > em0: Speed:N/A Duplex:N/A > pcib7: at device 0.2 on pci5 > pci7: on pcib7 > em1: port > 0xdcc0-0xdcff mem 0xdf9e-0xdf9f irq 65 at device 8.0 on pci7 > em1: Ethernet address: 00:11:43:36:39:e6 > em1: Speed:N/A Duplex:N/A > pcib8: at device 6.0 on pci0 > pci8: on pcib8 > pcib9: at device 30.0 on pci0 > pci9: on pcib9 > pci9: at device 13.0 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > orm0: at iomem > 0xec000-0xe,0xce800-0xcf7ff,0xcb000-0xcbfff,0xc-0xcafff on isa0 > pmtimer0 on isa0 > atkbdc0: at port 0x64,0x60 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > ppc0: parallel port not found. > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 > Timecounter "TSC" frequency 2793014175 Hz quality 800 > Timecounters tick every 1.000 msec > IP Filter: v3.4.35 initialized. Default = pass all, Logging = enabled > acd0: CDROM at ata0-master PIO4 > amrd0: on amr0 > amrd0: 69880MB (143114240 sectors) RAID 1 (optimal) > ses0 at amr0 bus 0 target 6 lun 0 > ses0: Fixed Processor SCSI-2 device > ses0: SAF-TE Compliant Device > Mounting root from ufs:/dev/amrd0s1a > em0: Link is up 100 Mbps Full Duplex > em1: Link is up 100 Mbps Full Duplex > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CUPDS reboot the whole system
On Wed, 18 May 2005, Todor Dragnev wrote: > Hello, > > Before a couple of days ago I started /usr/local/sbin/cupsd manualy from > console. When I press CTRL+C to interrupt a program, the system change > runlevel and going to reboot. This was on FreeBSD V5.3, today I > installed fresh new 5.4 but the problem is the same. FreeBSD doesn't have runlevels so I'm not sure what you're referring to here. Its also known that certain old Linux binaries that accidentally get run as FreeBSD binaries can call reboot() when trying a Linux SYSV syscall. If you copied cupsd from a linux box, use brandelf on it to make sure it gets run under the linuxulator. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with ASR card/5.4
On Mon, 16 May 2005, Bruce Burden wrote: > > > Hi folks, > > I am trying to get my Adaptec 3210S RAID running under 5.4, > and all I get for my trouble is pmap_ errors. Sorry, no dumps at > the moment. > > If I compile "device asr" into the kernel, I get a message > about "could not copy LDT", and a panic about "pmap_enter: > invalid page directory" when the system moves from single to multi > user. (single user is no problem?) > > If I do not compile the asr driver, and "kldload asr" instead, > I get a panic from pmap_mapdev, instead. > > Any ideas? This is annoying, and I am seriously considering > returning to 4.11, where asr was working... This sounds like your system has severe memory corruption issues. I'd try a different PCI slot for your asr card first, then try the card in another known working system and see if your problems appear there. Have you tested the system without the asr card installed? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Working Keyboard in 5.x
On Mon, 16 May 2005, Holtor wrote: > Does anyone know how to make a PS/2 keyboard work when plugged into a > system booted without a keyboard on FreeBSD 5.x? It doesn't seem to > work. This is a system-specific thing. As noted previously clearing flag 0x1 on atkbd0 can help this, but it doesn't always work on all motherboards. To do this, edit /boot/device.hints and make sure there is no "hint.atkbd.0.flags" line. Reboot to have the change take effect. _Technically_, ps/2 is not hotplug -- you risk severe electrical damage to the system by hotplugging ps/2 keyboards and mice. If you do this frequently you may consider investing in a KVM. > For example in 4.x the default GENERIC kernel line is: > device atkbd0 at atkbdc? irq 1 flags 0x1 > > If you leave that line alone, the ps/2 keyboard will not work if a system > booted without one plugged in. But if you remove the "flags 0x1" it will > work fine. > > Does anyone know how to make the PS/2 work properly in 5.x? > > Thank you, > > Holt G. > > > > > __ > Yahoo! Mail Mobile > Take Yahoo! Mail with you! Check email on your mobile phone. > http://mobile.yahoo.com/learn/mail > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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-RC2 freezing - ATA related?
On Wed, 18 May 2005, Jamie Heckford wrote: > Hi Peter, > > On Thu, May 19, 2005 at 05:53:12AM +1000, Peter Jeremy wrote: > > On Wed, 2005-May-18 16:03:16 +0100, Jamie Heckford wrote: > > >Managed to get a dump on our system for a similar prob we are getting: > > > > That traceback looks like a panic, not a deadlock. What was the panic > > message? > > Only have remote access to the box im afraid, is there anyway I can obtain > the panic message? "print msgbuf" should do it > > > > > >#2 0xc0513474 in panic (fmt=0xc06c3da5 "%s") at > > >/usr/src/sys/kern/kern_shutdown.c:566 > > ... > > >#7 0xc0510018 in crcopy () at /usr/src/sys/kern/kern_prot.c:1810 > > >#8 0xc0598c77 in in_pcbdetach (inp=0xc0743a40) at > > >/usr/src/sys/netinet/in_pcb.c:720 > > >#9 0xc05b21a6 in tcp_close (tp=0x0) at /usr/src/sys/netinet/tcp_subr.c:783 > > > > There's something wrong here: If tcp_close() is passed NULL it will panic > > at this point when it tries to dereference tp. > > Starting to stretch my knowledge a bit now ;) > > If I can provide you with further debug output would you be able to give me > some > pointers? > > Thanks for your help > > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic in recent RELENG_5 tcp code path
On Sun, 15 May 2005, Jeremie Le Hen wrote: > Sorry, I couldn't get a dump. > > %%% > obiwan:tataz$ uname -a > FreeBSD obiwan.tataz.chchile.org 5.4-STABLE FreeBSD 5.4-STABLE #16: Fri > May 13 01:01:50 CEST 2005 [EMAIL > PROTECTED]:/usr/src/sys/i386/compile/OBIWAN i386 > %%% > > %%% > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xc > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc05aa4e0 > stack pointer = 0x10:0xd6dbfaa4 > frame pointer = 0x10:0xd6dbfabc > 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 = 25637 (sshd) > [thread pid 25637 tid 100131 ] > Stopped at m_copydata+0x28:movl0xc(%esi),%ebx > db> trace > Tracing pid 25637 tid 100131 td 0xc23bc180 > m_copydata(c211aa00,0,40,c211aaa8,c21422ec) at m_copydata+0x28 > tcp_output(c1d74534,c211aa00,c211aa30,40,0) at tcp_output+0xb49 > tcp_usr_send(c1ec9144,0,c211aa00,0,0) at tcp_usr_send+0x1ca > sosend(c1ec9144,0,d6dbfc6c,c211aa00,0) at sosend+0x6dc > soo_write(c21422ec,d6dbfc6c,c2c2dd89,0,c23bc180) at soo_write+0x9e > dofilewrite(c23bc180,c21422ec,4,807d000,40) at dofilewrite+0xb6 > write(c23bc180,d6dbfd04,c,c23bc180,c21264b0) at write+0x6a > syscall(807002f,bfbf002f,bfbf002f,806eca8,40) at syscall+0x340 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (4, FreeBSD ELF32, write), eip = 0x2826cd0b, esp = > 0xbfbfe4fc, ebp = 0xbfbfr518 --- > %%% > > Please Cc: me in replies, I'm not subscribed to this list. Can you load a kernel.debug into gdb and do "l *(tcp_output+0xb49)" and post the output? that offset isn't a function call in my kernel. tcp_output() doesn't call m_copypacket directly so the exact spot is difficult to find. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Re: Supermicro superserver 5013S-i
On Sun, 15 May 2005, Balgansuren.B wrote: > Doug, > > I checked website for BIOS files and current loaded BIOS is latest > version. > > If I to use continously ACPI aware=NO, is there any problem? You can, but you may have reduced functionality (particularly if ACPI supports thermal zones). > Previously, on server was loaded Fedora Core 2, then I removed it. > > BTW, when I install Fedora Core 2 and it works normal. Fedora doesn't use ACPI by default I don't think. They may also suppress the messages. Again, the messages are largely harmless. I suspect its due to using a very old ACPI compiler and specification. > > Balgaa > > > > On Sat, 14 May 2005, Balgansuren.B wrote: > > > > > Yesterday (13 May, 2005), I installed FreeBSD 5.4 > > Release on this > > > server without problem. This morning (14 May, 2005) > > I did cvsup and now > > > it is 5.4-STABLE. > > > > > > But I saw strange thing when I change settings on > > bios setup. > > > > > > > [...] > > > > > May 14 10:41:41 altainet kernel: ACPI-0698: *** > > Warning: Type override > > > - [DEB_] had invalid type (Integer) for Scope > > operator, changed to > > > (Scope) > > > > This is a bug in the ACPI DSDT table in the BIOS. If > > upgrading the BIOS > > causes this then contact your systems vendor and > > complain since the prior > > BIOS table did not have these errors. It obviously > > goes away when ACPI is > > disabled since the table is not evaluated in that > > instance. > > > > Its likely harmless. > > > > -- > > Doug White| FreeBSD: The Power > > to Serve > > [EMAIL PROTECTED] | www.FreeBSD.org > > ___ > > 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]" > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem booting 5.4
On Sat, 14 May 2005, rduffner wrote: > Doug White writes: > > > On Thu, 12 May 2005, Rainer Duffner wrote: > > > >> Hi, > >> > >> I installed FreeBSD5.4 on a server with a 3ware 7006-2 controller and > >> two 120GB disks as RAID1 > >> I cannot boot this install. (I get some kind of panic or endless loop, > >> but the display is re-painted so fast I cannot read it). > >> What I *can* do is insert my SuSE9.2-pro cd1, boot from that and at the > >> grub-menu say "boot from harddisk". > >> That boots FreeBSD. > >> > >> On advice from IRC, I tried: > >> # boot0cfg -B twed0 > >> > >> -which leads to this output > >> > >> boot0cfg: write_mbr: /dev/twed0: No such file or directory > > > > This is a erroneous message. The actual problem is: > > > >484 boot0cfg NAMI "/dev/twed0" > >484 boot0cfg RET open -1 errno 1 Operation not permitted > > > > This is a known problem with certain MBR layouts. To work around this > > problem, set: > > > > sysctl kern.geom.debugflags=16 > > > > then try your boot0cfg. There's a protection mechanism that sometimes gets > > confused by certain partition table layouts. Flag 16 disables that > > protection. I don't recommend running this unless you are explicitly > > trying to updating something in a partition table-like area; its very easy > > to destroy your system with the flag set! > > > I booted from CD and ran the boot0cfg "offline" - however, this worked only > on one server. I have two more identical servers that now just beep > endlessly at the F1-prompt. > I was told it is a geometry problem, but what else can I do? boot0cfg -o packet adX -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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 install disc1 will not find hard drive
On Sat, 14 May 2005, fbsd_user wrote: > I have seen this problem on the questions list since 5.0 first can out as > development version. Here 5.4 is now stable release and this problem is > still not fixed. I have been using the same pc to test installing stable > versions from miniinst.iso every version since 3.4 without any problems. > Even 5.3-miniinst.iso worked just 2 weeks ago. The 5.4 stable does not have > a miniinst.iso file so this time I used the disc1.iso to burn the install cd > from and when booting from this cd I now get no hard drive found message > from sysinstall (standard install) menu. This sure looks very strange to me > as I can put in the cd burned from the 5.3-miniinst.iso file and the system > installs just fine. Only difference is using disc1 this time. Even though > the md5 CHECKSUM matched I downloaded and reburned disc1.iso again just to > verify it was good. What hardware (motherboard, cpus, memory, etc.) are you using? > Power management and APIC have been bios disabled since version FreeBSD 3.4 > version so that is not the problem. I tried selecting safe option to boot > and still get same error 'no hard disk found". My hard drive is an western > digital 310100 on ata0 as master. When using this 5.4 install cd on other > pc/ motherboard/ hard drive combos I get same error. You can hit Scroll Lock and use the arrow keys or page up/down to look at the boot messages. Near the bottom of the output should be the disk probe -- this may have more details. If not, try booting and selecting the "verbose boot" option. > I think there is something wrong with the build process of the disc1.iso > file. The miniinst.iso must be build using a different canned script that > does not incorporated the bug that is in the disc1 build. Maybe the .ISO > builds team needs to take a look at this problem. The only difference is the files included in the mkisofs run. The exact same files are used. > And to continue on with this thought why does 5.4 NOT have a miniinst.iso > file? That's a good question :-) I didn't realize we hadn't made one. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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-RELEASE amd64: Panic isadma_start : bad bounce buffer
On Sat, 14 May 2005, Steven Hartland wrote: > Thanks for the confirmation there Doug at least I have a workaround :) As another workaround, add this to loader.conf and reboot: vm.old_contigmalloc="1" This uses the old contigmalloc algorithm which may be more successful as allocating the bounce buffer area. > > Steve > - Original Message ----- > From: "Doug White" <[EMAIL PROTECTED]> > > > > This is a known bug; floppy drives don't work on amd64 since the ISA DMA > > buffer gets allocated above 16MB. I don't know if this is something that > > needs to be handled by busdma. > > > > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > > In the event of misdirection, illegible or incomplete transmission please > telephone (023) 8024 3137 > or return the E.mail to [EMAIL PROTECTED] > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Supermicro superserver 5013S-i
On Sat, 14 May 2005, Balgansuren.B wrote: > Yesterday (13 May, 2005), I installed FreeBSD 5.4 Release on this > server without problem. This morning (14 May, 2005) I did cvsup and now > it is 5.4-STABLE. > > But I saw strange thing when I change settings on bios setup. > [...] > May 14 10:41:41 altainet kernel: ACPI-0698: *** Warning: Type override > - [DEB_] had invalid type (Integer) for Scope operator, changed to > (Scope) This is a bug in the ACPI DSDT table in the BIOS. If upgrading the BIOS causes this then contact your systems vendor and complain since the prior BIOS table did not have these errors. It obviously goes away when ACPI is disabled since the table is not evaluated in that instance. Its likely harmless. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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-RELEASE amd64: Panic isadma_start : bad bounce buffer
On Sat, 14 May 2005, Steven Hartland wrote: > Just been trying to install FreeBSD 5.4 amd64 here and > when loading the raid control kernel module driver ( hptmv ) > from floppy and booting I was getting: > Panic isadma_start : bad bounce buffer This is a known bug; floppy drives don't work on amd64 since the ISA DMA buffer gets allocated above 16MB. I don't know if this is something that needs to be handled by busdma. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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 weird transmit problem
On Thu, 12 May 2005, jmc wrote: > I've got 5.4 amd64 installed on an Opteron server and I cannot get it to > reliably transmit packets larger than 80 bytes using the bge driver (on a > BCM5703 NIC). It receives large packets without any problem, but it just > won't transmit them. (I can tcpdump all day long without a problem - big and > small packets.) > > For example, I can "ping -s 38 " and it works fine. But if I try "ping > -s 39 " (or any size larger than 38) it does not work. A 38 byte ping > creates an 80 byte Ethernet packet. Random guesses: 1. Make sure your switch agrees with the speed and duplex setting. Auto-neg problems are common. 2. Replace the cable. 3. Back-to-back two systems and try to reproduce. > > Here's the bge0 info from dmesg: > > bge0: mem > 0xf7ef-0xf7 > ef irq 24 at device 1.0 on pci3 > bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0xf7ef > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX > -FDX, auto > bge0: bpf attached > bge0: Ethernet address: 00:11:85:fd:8f:f9 > bge0: [MPSAFE] > > Here's ifconfig for bge0: > > bge0: flags=8843 mtu 1500 > options=1a > inet 16.100.240.165 <http://16.100.240.165> netmask 0xfc00 broadcast > 16.100.243.255 <http://16.100.243.255> > inet6 fe80::211:85ff:fefd:8ff9%bge0 prefixlen 64 scopeid 0x1 > ether 00:11:85:fd:8f:f9 > media: Ethernet autoselect (1000baseTX ) > status: active > > Much to my dismay, I've found that if I use the -l option (preload) for > ping, I get some large packets through: > > ninox# ping -l10 -c10 -s200 16.100.240.1 <http://16.100.240.1> > PING 16.100.240.1 <http://16.100.240.1> (16.100.240.1 <http://16.100.240.1>): > 200 data bytes > 208 bytes from 16.100.240.1 <http://16.100.240.1>: icmp_seq=2 ttl=128 time= > 1.025 ms > 208 bytes from 16.100.240.1 <http://16.100.240.1>: icmp_seq=3 ttl=128 time= > 1.306 ms > 208 bytes from 16.100.240.1 <http://16.100.240.1>: icmp_seq=4 ttl=128 time= > 1.593 ms > 208 bytes from 16.100.240.1 <http://16.100.240.1>: icmp_seq=5 ttl=128 time= > 2.026 ms > 208 bytes from 16.100.240.1 <http://16.100.240.1>: icmp_seq=6 ttl=128 time= > 2.314 ms > 208 bytes from 16.100.240.1 <http://16.100.240.1>: icmp_seq=7 ttl=128 time= > 2.746 ms > 208 bytes from 16.100.240.1 <http://16.100.240.1>: icmp_seq=8 ttl=128 time= > 3.034 ms > 208 bytes from 16.100.240.1 <http://16.100.240.1>: icmp_seq=9 ttl=128 time= > 3.468 ms > > --- 16.100.240.1 <http://16.100.240.1> ping statistics --- > 10 packets transmitted, 8 packets received, 20% packet loss > round-trip min/avg/max/stddev = 1.025/2.189/3.468/0.806 ms > > Has anyone else ever seen a problem like this? Any suggestions on where to > poke around for a solution? > > Thanks, > John > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem booting 5.4
On Thu, 12 May 2005, Rainer Duffner wrote: > Hi, > > I installed FreeBSD5.4 on a server with a 3ware 7006-2 controller and > two 120GB disks as RAID1 > I cannot boot this install. (I get some kind of panic or endless loop, > but the display is re-painted so fast I cannot read it). > What I *can* do is insert my SuSE9.2-pro cd1, boot from that and at the > grub-menu say "boot from harddisk". > That boots FreeBSD. > > On advice from IRC, I tried: > # boot0cfg -B twed0 > > -which leads to this output > > boot0cfg: write_mbr: /dev/twed0: No such file or directory This is a erroneous message. The actual problem is: 484 boot0cfg NAMI "/dev/twed0" 484 boot0cfg RET open -1 errno 1 Operation not permitted This is a known problem with certain MBR layouts. To work around this problem, set: sysctl kern.geom.debugflags=16 then try your boot0cfg. There's a protection mechanism that sometimes gets confused by certain partition table layouts. Flag 16 disables that protection. I don't recommend running this unless you are explicitly trying to updating something in a partition table-like area; its very easy to destroy your system with the flag set! -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: twa0: INFO: (0x04: 0x000c): Background initialize started: unit=0
On Mon, 9 May 2005, Marc G. Fournier wrote: > > Ya, this looks like it might be a problem ... server just crashed, and > fsck is once more dog slow, and I suspect its in the 'initialization mode' > again ... > > Looking at the following that I've also found, things appear to be > pointing to ACPI as the 'trigger' ... does anyone else have any > experiences with these cards? This is normal for twa and twe cards with recent firmware. If it detects an unclean shutdown it will schedule a unit verify. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Experimental ttwwakeup() panic patch
Sorry for the late reply on this. On Fri, 6 May 2005, Ed Maste wrote: > On Wed, May 04, 2005 at 08:54:23PM -0700, Doug White wrote: > > > > http://people.freebsd.org/~dwhite/tty.c.20050503.patch > > > > This patch has been committed and exists as rev 1.228.2.4 of > > src/sys/kern/tty.c. Please let me know if this fixes the panic for you, > > or causes new problems :) > > For what it's worth, I've come across a similar crash during a test that > repeatedly ssh'd into the machine. > > This was while opening a pty, not using serial console. The symptoms > seem similar; my tty struct has a struct knlist with a null struct mtx *. > I haven't yet investigated in great detail or tried the patch. I just > wanted to offer this as another data point. > > Although kgdb gets confused during the backtrace (frames 7 and 8) the > tf_eip is a cmpxchg in knote(). This is a problem mlaier and I may have fixed, at least against -CURRENT. It appears that the process group alias in struct tty is accessed without locking and its changing out from under us. Give this a try: http://people.freebsd.org/~mlaier/tty.t_pgrp.diff It compiles but I haven't actually booted a kernel with it, so YMMV. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: unexpected panic in idle process (RELENG_5 2005/04/25UTC)
0 20c [RUNQ] swi5: clock sio >26 c0acc7100 0 0 204 [IWAIT] irq15: ata1 >25 c0acc8d40 0 0 204 [IWAIT] irq14: ata0 >24 c0acca980 0 0 204 [IWAIT] irq13: >23 c0accc5c0 0 0 204 [IWAIT] irq12: hifn0 >22 c0acce200 0 0 204 [IWAIT] irq11: sis2 >21 c0ae80000 0 0 204 [IWAIT] irq10: sis0 >20 c0ae81c40 0 0 204 [IWAIT] irq9: sis1 >19 c0ae83880 0 0 204 [IWAIT] irq8: rtc >18 c0ac50000 0 0 204 [IWAIT] irq7: >17 c0ac51c40 0 0 204 [IWAIT] irq6: >16 c0ac53880 0 0 204 [IWAIT] irq5: >15 c0ac554c0 0 0 204 [IWAIT] irq4: sio0 >14 c0ac57100 0 0 204 [IWAIT] irq3: >13 c0ac58d40 0 0 204 [IWAIT] irq1: >12 c0ac5a980 0 0 204 [IWAIT] irq0: clk >11 c0ac5c5c0 0 0 20c [CPU 0] idle > 1 c0ac5e200 0 1 0004200 [SLPQ wait 0xc0ac5e20][SLP] init >10 c0acc0000 0 0 204 [SLPQ ktrace 0xc066f7d8][SLP] ktrace > 0 c066bb000 0 0 200 [SLPQ sched 0xc066bb00][SLP] swapper > db> > > unfortunately, I won't be able to take a dump because the CF has > no swap. > > Anyone have an idea what this could be, and what I could type into > db> to get further info? > > One thing that I changed on this HW yesterday was to add a Mini-PCI > HiFn card: > > hifn0 mem 0x8004-0x80040fff,0x8000-0x8fff irq 12 at device 13.0 > on pci0 > hifn0: Hifn 7951, rev 0, 128KB sram > > before that change, earlier RELENG_5 systems didn't demonstrate > any such an "idle" panic on said HW. > > non-verbose dmesg and kernel config image are available, and I will > leave the db> there, awaiting suggestions. > > Adrian > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: loss of keyboard in single-user mode in RELENG_5
Don't crosspost both -current and -stable; your problem does not affect -current. On Fri, 6 May 2005, Thierry Herbelot wrote: > Hello, > > I have rebuilt the world and kernel this morning. The commit causing this problem has been backed out. Please cvsup and try again. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Experimental ttwwakeup() panic patch
On Tue, 3 May 2005, Doug White wrote: > Hey folks, > > I've taken a crack at working around the ttwwakeup() panic thats been > reported now and again. My early analysis, based on debugging output from > rwatson, is that a defunct struct tty gets reused without cleaning out the > associated (stale) knote structures, and the ttwwakeup() at the end of > sioopen() jumps off into space when it finds them. > > This patch is against RELENG_5 but the logic should apply to -CURRENT, > although the patch likely won't as ttymalloc() is organized differently > there. > > I did some basic testing on my UP box and didn't see any abberant behavior > afterwards. However I can't reproduce the panic in question, so if you're > good at triggering the panic give this a spin. > > http://people.freebsd.org/~dwhite/tty.c.20050503.patch This patch has been committed and exists as rev 1.228.2.4 of src/sys/kern/tty.c. Please let me know if this fixes the panic for you, or causes new problems :) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Experimental ttwwakeup() panic patch
Hey folks, I've taken a crack at working around the ttwwakeup() panic thats been reported now and again. My early analysis, based on debugging output from rwatson, is that a defunct struct tty gets reused without cleaning out the associated (stale) knote structures, and the ttwwakeup() at the end of sioopen() jumps off into space when it finds them. This patch is against RELENG_5 but the logic should apply to -CURRENT, although the patch likely won't as ttymalloc() is organized differently there. I did some basic testing on my UP box and didn't see any abberant behavior afterwards. However I can't reproduce the panic in question, so if you're good at triggering the panic give this a spin. http://people.freebsd.org/~dwhite/tty.c.20050503.patch -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Experimental ttwwakeup() panic patch
Hey folks, I've taken a crack at working around the ttwwakeup() panic thats been reported now and again. My early analysis, based on debugging output from rwatson, is that a defunct struct tty gets reused without cleaning out the associated (stale) knote structures, and the ttwwakeup() at the end of sioopen() jumps off into space when it finds them. This patch is against RELENG_5 but the logic should apply to -CURRENT, although the patch likely won't as ttymalloc() is organized differently there. I did some basic testing on my UP box and didn't see any abberant behavior afterwards. However I can't reproduce the panic in question, so if you're good at triggering the panic give this a spin. http://people.freebsd.org/~dwhite/tty.c.20050502.patch -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Opteron deadlock fix committed
Hey folks, Yesterday I committed a workaround for a deadlock condition in RELENG_5 and RELENG_5_4 caused by errata in AMD Opteron and Athlon64 processors. (-CURRENT after April 8 is not affected due to changes in critical sections.) The deadlock appeared under heavy load, particularly with lots of I/O interrupts, in SMP environments on both FreeBSD/amd64 and FreeBSD/i386. Specifically, a spinwait as part of inter-processor TLB flushing triggered Errata 106, which causes the cache on the spinning processor to not update. To workaround the issue we enabled interrupts during the spinwait, which breaks the lock on the cache when an interrupt occurs. AMD also offers a workaround that the BIOS can implement, but not all systems have applied the errata. This workaround will appear in 5.4-RELEASE. In addition, I committed a KDB feature written by Stephen Uphoff (ups) to assist in debugging SMP situations where one processor is stuck with interrupts disabled. Since the regular cpustop IPI won't get through in that case, he implemented an NMI handler to perform the stop. This feature, compiled in with the kernel option KDB_STOP_NMI and activated by debug.kdb.stop_cpus_with_nmi, is available on all current branches and will ship with 5.4-RELEASE. If you have had problems with deadlock conditions on AMD processors in an SMP environment, we urge you to update to the latest RELENG_5, or try the upcoming 5.4-RC4. I want to thank the following individuals for their help in debugging and fixing the deadlock issue: Paul Vixie and Peter Losher at ISC Stephen Uphoff (ups) Alan Cox (alc) John Baldwin (jhb) The rest of the FreeBSD RE team -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reproducible panic 5.4-stable when booting with -v
On Wed, 27 Apr 2005, Marc Olzheim wrote: > The same system about which I just mailed, crashes when booting with > verbose logging enabled. With a normal boot, everything's ok... Looks like it perturbs some sort of timing and upsets the SCSI card. Is this on a serail console? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multithreaded program crashes on SMP (HT enabled) machine
Dropping -hackers and -bugs On Wed, 27 Apr 2005, Adi Pircalabu wrote: > Hello, > I have a multithreaded application ported on FreeBSD 5.3 which crashes > in a minute or less if hyperthreading in enabled. Without HT there is no > problem. > How and where should I start to investigate the problem? > Can you expalin "crash"? Do you get any messages? > The backtrace: > (gdb) bt > #0 0x2819631b in pthread_testcancel () from /usr/lib/libpthread.so.1 > #1 0x2818e902 in pthread_mutexattr_init () from > /usr/lib/libpthread.so.1 #2 0x in ?? () This looks like a thread library mismatch. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vm_page_free: freeing wired page
On Tue, 26 Apr 2005, Sergey S. Ropchan wrote: > Hi, all > > I have problem on high loaded SMP server with FreeBSD 5.3-p10+Apache > 1.3.33+Mysql 4.0 reported in kern/75780 ! > > State still open - not fixed as i understand! > > If there any possible way to find "workaround" of this problem !? > > Maybe cvsup to 5.4 or something else ?! > > This problem exist only in 5.3 or in 5.x at all !? You might try one of the 5.4-RC release candidates ... there's been a bunch of VM fixes in that area that would help you. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ 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-RC3 Kernel Panic: "vinvalbuf: dirty bufs" (backtrace included)
ef9f irq 16 > at device 29.3 on pci0 > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub3: 2 ports with 2 removable, self powered > ehci0: mem 0xfebffc00-0xfebf irq 23 at > device 29.7 on pci0 > usb4: EHCI version 1.0 > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > usb4: on ehci0 > usb4: USB revision 2.0 > uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 > uhub4: 8 ports with 8 removable, self powered > pcib2: at device 30.0 on pci0 > pci2: on pcib2 > skc0: port 0xd800-0xd8ff mem 0xfeafc000-0xfeaf > irq 22 at device 5.0 on pci2 > skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9) > sk0: on skc0 > sk0: Ethernet address: 00:11:d8:52:51:d6 > miibus0: on sk0 > e1000phy0: on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, > auto > atapci0: port > 0xdf90-0xdf9f,0xdfe0-0xdfe3,0xdfa8-0xdfaf,0xdfe4-0xdfe7,0xdff0-0xdff7 mem > 0xfeaf8000-0xfeafbfff irq 21 at device 9.0 on pci2 > ata2: channel #0 on atapci0 > ata3: channel #1 on atapci0 > em0: port > 0xdf00-0xdf3f mem 0xfea8-0xfea9,0xfeaa-0xfeab irq 22 at > device 10.0 on pci2 > em0: Ethernet address: 00:0e:0c:06:21:17 > em0: Speed:N/A Duplex:N/A > asr0: mem 0xe800-0xefff irq 20 at device > 12.0 on pci2 > asr0: ADAPTEC 2400A FW Rev. 3A0L, 4 channel, 256 CCBs, Protocol I2O > pcib3: at device 12.1 on pci2 > pci3: on pcib3 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci1: port > 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 > ata0: channel #0 on atapci1 > ata1: channel #1 on atapci1 > pci0: at device 31.3 (no driver attached) > pcm0: port 0xee80-0xeebf,0xe800-0xe8ff mem > 0xfebff400-0xfebff4ff,0xfebff800-0xfebff9ff irq 17 at device 31.5 on pci0 > pcm0: > acpi_button0: on acpi0 > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > psm0: irq 12 on atkbdc0 > psm0: model IntelliMouse, device ID 3 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on > acpi0 > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > ppc0: port 0x378-0x37f irq 7 on acpi0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > npx0: on motherboard > npx0: INT 16 interface > orm0: at iomem > 0xd1000-0xd6fff,0xcf800-0xd0fff,0xcd000-0xcf7ff,0xc-0xccfff on isa0 > pmtimer0 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounter "TSC" frequency 2605921612 Hz quality 800 > Timecounters tick every 10.000 msec > IP Filter: v3.4.35 initialized. Default = block all, Logging = enabled > acd0: DVDR at ata0-master PIO4 > acd1: DVDROM at ata0-slave PIO4 > ad4: 190782MB [387621/16/63] at ata2-master > UDMA100 > ad6: 286103MB [581290/16/63] at ata3-master UDMA133 > da0 at asr0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: Tagged Queueing Enabled > da0: 228957MB (468903936 512 byte sectors: 255H 63S/T 29187C) > cd0 at ata0 bus 0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 16.000MB/s transfers > cd0: cd present [2133520 x 2048 byte records] > cd1 at ata0 bus 0 target 1 lun 0 > cd1: Removable CD-ROM SCSI-0 device > cd1: 16.000MB/s transfers > cd1: cd present [3911061 x 2048 byte records] > Mounting root from ufs:/dev/ad4s1a > WARNING: / was not properly dismounted > WARNING: /home was not properly dismounted > WARNING: /tmp was not properly dismounted > WARNING: /usr was not properly dismounted > WARNING: /var was not properly dismounted > WARNING: /big was not properly dismounted > em0: Link is up 1000 Mbps Full Duplex > drm0: port 0xc000-0xc0ff mem > 0xfe8f-0xfe8f,0xe000-0xe3ff irq 16 at device 0.0 on pci1 > info: [drm] AGP at 0xf800 64MB > info: [drm] Initialized radeon 1.11.0 20020828 on minor 0 > info: [drm] Loading R200 Microcode > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: installkernel succeeds, but old kernel boots
On Thu, 21 Apr 2005, Paco Hope wrote: > I cvsupped the latest RELENG_5 sources and did make buildworld. Then I > built and installed the kernel using > > make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=PACO > make -DALWAYS_CHECK_MAKE installkernel KERNCONF=PACO > > Then I rebooted. So far so good. This is all normal. However, after I > reboot and run 'uname -a' I see: > > FreeBSD www.provisio.net 5.3-RELEASE-p5 FreeBSD 5.3-RELEASE-p5 #0: Sat Mar > 19 01:28:39 EST 2005 [EMAIL PROTECTED]:/usr/obj/data/src/sys/PACO > i386 > > sysctl agrees with uname: > > kern.ostype: FreeBSD > kern.osrelease: 5.3-RELEASE-p5 > kern.osrevision: 199506 > kern.version: FreeBSD 5.3-RELEASE-p5 #0: Sat Mar 19 01:28:39 EST 2005 > [EMAIL PROTECTED]:/usr/obj/data/src/sys/PACO > > That's my old kernel that I was trying to replace. I run 'sysctl > kern.bootfile' and it says '/boot/kernel/kernel' so I'm a little confused. > By all indications, the file that's currently in /boot/kernel/kernel is > 5.4-STABLE. I can run 'strings' on /boot/kernel/kernel and see this near > the bottom: > > FreeBSD 5.4-STABLE #0: Thu Apr 21 00:04:21 EDT 2005 > [EMAIL PROTECTED]:/usr/obj/data/src/sys/PACO > FreeBSD > 5.4-STABLE > PACO > > It sure looks like I booted my old kernel somehow, but I can't figure out > how. It seems unlikely that I somehow installed from a stale build tree > because I newfs'd /usr/obj before building anything. > > Thoughts? loader.conf? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.4 RC2 on a Compaq Laptop?
On Thu, 21 Apr 2005, Matt Meola wrote: > On Wed, 2005-04-20 at 19:25 -0700, Doug White wrote: > > See the freebsd-amd64 list archives for an extensive discussion on the > > R3000 series. (or was it -mobile? :-) ) > > Yeah, I saw all that, and the gnats bug about it, too. It appears that > what needed to change was changed, and committed to (at least) -CURRENT. > > > You will probably need to run at least -STABLE. These machines are wierd > > birds. > > :-) You're telling me... BTW, I was under the impression that 5.4-RC* > was actually released from the -STABLE branch... Am I mistaken on that? That is correct. But I was trying to say I don't think 5.3-R will work. :) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MySQL signal 11
On Mon, 18 Apr 2005, Uzi Klein wrote: > Uzi Klein wrote: > > Uzi Klein wrote: > > > >> > >> Hi > >> > >> I got this message from mysql-error log. > >> Nothing visible on system log, but after it happens, mysql starts > >> acting strange (shoes double fields values as 0 while is still > >> contains the data - visible after restarting mysql) > >> > >> Hardware should be OK, nothing wrong in boot message and its a brand > >> new HP DL380-G4. > >> > >> Any leads or ideas? > >> > > > > eh.. something causing only 1 attachment to appear... sorry... > > > > * mysql-error.log : * > > mysqld got signal 11; > This could be because you hit a bug. It is also possible that this binary > or one of the libraries it was linked against is corrupt, improperly built, > or misconfigured. This error can also be caused by malfunctioning hardware. > We will try our best to scrape up some info that will hopefully help > diagnose > the problem, but since we have already crashed, something is definitely > wrong > and this may fail. This is generally indicative of bad memory or nonfunctional cooling. Check the system's environmentals. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcpwrappers problem
On Mon, 18 Apr 2005, Didier Wiroth wrote: > Hi, > (using freebsd5.4-stable) > > I'm trying to display a ftpd banner with hosts.allow, but it doesn't work. > > I'm using ftpd (/usr/libexec/ftpd) started through inetd. > Ined is started with standard flags: > /usr/sbin/inetd -wW -C 60 > > In hosts.allow I have: > ALL : ALL : allow > ALL : ALL : banners /usr/local/etc/banners/ > ALL : PARANOID : RFC931 20 : deny I wouldn't use tcpwrapper banners if you're doing more than just bitching out the user before kicking them off. Some FTP clients will just ignore your banner since it won't conform to the FTP protocol specification. If you want it to display when the user logs into your FTP server, put it in /etc/ftpmotd. If you want your telnet client to see it, put it in /etc/motd. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mysql40-server with linuxthreads and CFLAGS=-DUSE_OLD_FUNCTIONS
On Sun, 17 Apr 2005 [EMAIL PROTECTED] wrote: > Does any 1-:) have a compiled mysql4*-server with linuxthreads and CFLAGS=- > DUSE_OLD_FUNCTIONS > > I went by all the deltas from 5500 up to today ( 5734 ) and always get the > same > error > <> > cc -DDBUG_OFF -DUSE_OLD_FUNCTIONS -DUSE_OLD_FUNCTIONS -felide-constructors > -fno- > rtti -fno-exceptions -fno-implicit-templates -fno-exceptions -fno-rtti - > DMYSQLD_NET_RETRY_COUNT=100 -o mysqld sql_lex.o sql_handler.o item.o > item_sum.o item_buff.o item_func.o item_cmpfunc.o item_strfunc.o > item_timefunc.o thr_malloc.o item_create.o field.o key.o sql_class.o > sql_list.o > net_serv.o net_pkg.o lock.o my_lock.o sql_string.o sql_manager.o sql_map.o > mysqld.o password.o hash_filo.o hostname.o convert.o set_var.o sql_parse.o > sql_yacc.o sql_base.o table.o sql_select.o sql_insert.o sql_update.o > sql_delete.o uniques.o sql_do.o procedure.o item_uniq.o sql_test.o log.o > log_event.o init.o derror.o sql_acl.o unireg.o des_key_file.o time.o > opt_range.o opt_sum.o opt_ft.o records.o filesort.o handler.o ha_heap.o > ha_myisam.o ha_myisammrg.o ha_berkeley.o ha_innodb.o ha_isam.o ha_isammrg.o > sql_db.o sql_table.o sql_rename.o sql_crypt.o sql_load.o mf_iocache.o > field_conv.o sql_show.o sql_udf.o sql_analyse.o sql_cache.o slave.o sql_repl.o > sql_union.o mini_client.o mini_client_errors.o stacktrace.o repl_failsafe.o - > static -DHAVE_GLIBC2_STYLE_GETHOSTBYNAME_R -D_THREAD_SAFE - > I/usr/local/include/pthread/linuxthreads -DHAVE_GLIBC2_STYLE_GETHOSTBYNAME_R - > D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads - > L/usr/ports/databases/mysql40-server/work/mysql-4.0.24/bdb/build_unix - > ldb ../innobase/usr/libusr.a ../innobase/srv/libsrv.a > ../innobase/dict/libdict.a > ../innobase/que/libque.a ../innobase/srv/libsrv.a ../innobase/ibuf/libibuf.a > .. > /innobase/row/librow.a ../innobase/pars/libpars.a ../innobase/btr/libbtr.a > ../in > nobase/trx/libtrx.a ../innobase/read/libread.a ../innobase/usr/libusr.a > ../innob > ase/buf/libbuf.a ../innobase/ibuf/libibuf.a ../innobase/eval/libeval.a > ../innoba > se/log/liblog.a ../innobase/fsp/libfsp.a ../innobase/fut/libfut.a > ../innobase/fi > l/libfil.a ../innobase/lock/liblock.a ../innobase/mtr/libmtr.a > ../innobase/page/ > libpage.a ../innobase/rem/librem.a ../innobase/thr/libthr.a > ../innobase/sync/lib > sync.a ../innobase/data/libdata.a ../innobase/mach/libmach.a > ../innobase/ha/libh > a.a ../innobase/dyn/libdyn.a ../innobase/mem/libmem.a > ../innobase/sync/libsync.a > ../innobase/ut/libut.a ../innobase/os/libos.a ../innobase/ut/libut.a > ../isam/li > bnisam.a ../merge/libmerge.a ../myisam/libmyisam.a > ../myisammrg/libmyisammrg.a . > ./heap/libheap.a ../vio/libvio.a ../mysys/libmysys.a ../dbug/libdbug.a > ../regex/ > libregex.a ../strings/libmystrings.a -lwrap -L/usr/local/lib -llthread - > llgcc_r -lz -lcrypt -lm -llthread -llgcc_r > *** Error code 1 > <> > I will appreciate a compiled work directory. Hm, odd that it didn't actually print an error message. Are you omitting something? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Deadlock in 5.3p5
On Sat, 16 Apr 2005, Peter Jeremy wrote: > My son's computer deadlocked last night. "show lockedvnods" in DDB showed: > > Locked vnodes > 0xc1669840: tag ufs, type VDIR, usecount 8, writecount 0, refcount 2, flags > (VV_ROOT|VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc18ed000 (pid > 9666) with 7 pending > ino 2, on dev ad0s1g (4, 25) > 0xc1682000: tag ufs, type VDIR, usecount 5, writecount 0, refcount 2, flags > (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fd000 (pid 15686) > with 1 pending > ino 23552, on dev ad0s1g (4, 25) > 0xc1b30d68: tag ufs, type VDIR, usecount 2, writecount 0, refcount 1, flags > (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc268f000 (pid 9075) > with 1 pending > ino 122986, on dev ad0s1g (4, 25) > 0xc1c3c210: tag ufs, type VDIR, usecount 3, writecount 0, refcount 1, flags > (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fe4b0 (pid 9067) > with 1 pending > ino 142022, on dev ad0s1g (4, 25) > 0xc1e2ce70: tag ufs, type VREG, usecount 6, writecount 0, refcount 0, flags > (VV_OBJBUF), lock type ufs: SHARED (count 1) with 1 pending > ino 142169, on dev ad0s1g (4, 25) > > After poking around in the crashdump for a while, I've worked out that > the process holding each of the above exclusive locks is waiting on > the next lock in the list. Unfortunately, there doesn't appear to be > any way to work out which process is holding the shared lock unless > DEBUG_LOCKS is set (and even this doesn't work if the lock was implicitly > downgraded by a process calling lockmgr(LK_SHARED) when it holds an > exclusive lock). > > FWIW, the affected inodes are: > 2 /usr > 23552 /usr/local > 122986 /usr/local/OpenOffice.org1.1.4 > 142022 /usr/local/OpenOffice.org1.1.4/program > 142169 /usr/local/OpenOffice.org1.1.4/program/libpsp645fi.so > > Does anyone have any ideas on how to track this further (or so I just > write it off as a glitch). This is the old "race to root" that happens at the end of the death spiral. You need to know why the guy holding tte library lock isn't letting go of it. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.4 RC2 on a Compaq Laptop?
On Thu, 14 Apr 2005, Matt Meola wrote: > Has anyone had any success getting 5.4RC2 installed on a Compaq Presario > laptop? According to my BIOS, I have a Presario R3200 (Athlon XP > processor). I get the splash screen, it begins the boot process > and then it just shuts off the computer. See the freebsd-amd64 list archives for an extensive discussion on the R3000 series. (or was it -mobile? :-) ) You will probably need to run at least -STABLE. These machines are wierd birds. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp lockups on 5.4-RC1
0 0 0 204 [CPU 0] irq12: fxp0 > 22 c1580e200 0 0 204 [IWAIT] irq11: > 21 c15b60000 0 0 204 [IWAIT] irq10: > 20 c15b61c40 0 0 204 [IWAIT] irq9: > 19 c15b63880 0 0 204 [IWAIT] irq8: rtc > 18 c15780000 0 0 204 [IWAIT] irq7: > 17 c15781c40 0 0 204 [IWAIT] irq6: > 16 c15783880 0 0 204 [IWAIT] irq5: > 15 c157854c0 0 0 204 [IWAIT] irq4: sio0 > 14 c15787100 0 0 204 [IWAIT] irq3: sio1 > 13 c15788d40 0 0 204 [IWAIT] irq1: atkbd0 > 12 c1578a980 0 0 204 [IWAIT] irq0: clk > 11 c1578c5c0 0 0 20c [Can run] idle > 1 c1578e200 0 1 0004200 [SLPQ wait 0xc1578e20][SLP] init > 10 c1580 0 0 204 [SLPQ ktrace 0xc0609d18][SLP] ktrace > 0 c06064c00 0 0 200 [SLPQ sched 0xc06064c0][SLP] swapper > db> tr 375 > Tracing pid 375 tid 100038 td 0xc15b8c00 > sched_switch(c15b8c00,0,1) at sched_switch+0x143 > mi_switch(1,0,c15b8c00,0,c15b8c00) at mi_switch+0x1ba > sleepq_switch(c0c1f460) at sleepq_switch+0xda > sleepq_wait(c0c1f460,0,c0c45240,0,0) at sleepq_wait+0xb > msleep(c0c1f460,c0c1f468,44,c05d48df,0) at msleep+0x2ce > uma_zone_slab(c0c45b40,2,2,80,314c) at uma_zone_slab+0xd2 > uma_zalloc_bucket(c0c45b40,2) at uma_zalloc_bucket+0x14c > uma_zalloc_arg(c0c45b40,c41c1c00,2) at uma_zalloc_arg+0x274 > mb_init_pack(c41c1c00,100,2) at mb_init_pack+0x1d > uma_zalloc_bucket(c0c45ba0,3) at uma_zalloc_bucket+0x1b4 > uma_zalloc_arg(c0c45ba0,d5229c0c,2) at uma_zalloc_arg+0x274 > sosend(c1a05000,0,d5229c54,0,0) at sosend+0x33d > kern_sendit(c15b8c00,3fd,d5229ccc,0,0) at kern_sendit+0x11c > sendit(c15b8c00,3fd,d5229ccc,0,805a000) at sendit+0x145 > sendto(c15b8c00,d5229d14,6,60,202) at sendto+0x4d > syscall(2f,805002f,bfbf002f,1a4,80521b0) at syscall+0x27b > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (133, FreeBSD ELF32, sendto), eip = 0x280c2b9b, esp = 0xbfbfeb4c, > ebp = 0xbfbfeb78 --- > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reliable "panic: isa_dmastart: bad bounce buffer"
On Tue, 12 Apr 2005, Mikhail Teterin wrote: > Hello! > > Whenever I try to mount a floppy disk: > >mount -t msdosfs /dev/fd0 /mnt > > I get: > > panic: isa_dmastart: bad bounce buffer > > The OS is FreeBSD-5.4-STABLE from last night, amd64. dmesg attached. Probably related to: fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 isa_dmainit(2, 40960) failed fd0: <1440-KB 3.5" drive> on fdc0 drive 0 That message is printed by isa_dmainit() in src/sys/amd64/isa/isa_dma.c. You might instrument that function and see where its blowing up. I suspect its getting the buffer from malloc() but the range check below it fails. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel 6300ESB (ICH) SMBus controller not working
On Tue, 12 Apr 2005, Philip Murray wrote: > Hi, > > I'm running RELENG_5 on a Dell PowerEdge 750 and the ichsmb driver > doesn't want to work with it, I get the following on boot: > > ichsmb0: port 0x8c0-0x8df irq 17 > at device 31.3 on pci0 > device_attach: ichsmb0 attach returned 6 > > It then doesn't load smb or smbus. I had a look in the source and it is > supposed to work with this controller. > > Is this something wrong with the driver? or have I left out some bit of > configuration? > > Attached is the output from boot -v and my kernel configuration. Is > there any other debugging output that would be useful? According to the boot -v messages the I/O range map is getting attached to the wrong function on that chip: found-> vendor=0x8086, dev=0x25a3, revid=0x02 bus=0, slot=31, func=2 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02a8, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 08c0, size 5, enabled but it should be on this: ichsmb0: port 0x8c0-0x8df irq 17 at device 31.3 on pci0 I'll poke at this a bit, but you should check for a BIOS update. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hp dc7100 installs 5.4-rc1 from CD but won't boot from HD
On Mon, 11 Apr 2005, John Hawkes-Reed wrote: > (Which I think covers the problem) > > Boots from CD ok, USB keyboard seems less than reliable, so I'm using a PS2 > item. Running through 'standard' install appears to write data to the (SATA > ICH6 controller) disk, but on reboot it sits at the F1: FreeBSD prompt > beeping every ten seconds. > > Is there likely to be anything obvious I've missed? (Or indeed more useful > data I can provide.) Your system appears to require packet mode, but sysinstall didn't enable it. Two possible fixes: 1. If you have disc 2: Boot the install CD, go to Fixit, start up fixit off CD, then run boot0cfg -o packet adX where adX is the appropriate disk device. 2. Reinstall, but use the standard MBR rather than the boot manager. Once you get the system booted you can install the boot manager with: boot0cfg -B -o packet adX where adX is the appropriate disk device. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel killing processes when out of swap
On Wed, 13 Apr 2005, Jim C. Nasby wrote: > It's extremely disappointing that you can't turn this off. I've been > bashing linux for months now about how they think it's OK to kill random > processes. But at least they'll let you turn it off. It's extremely disappointing that you haven't submitted patches yet, particularly when you have so many testers lined up. :-) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Alternate menu logos
(Changing the subject since its not reflective of the tone of the message. Apologies to the poster, but since this is a touchy subject I'm going to make this a more technical discussion.) On Mon, 11 Apr 2005, Hanspeter Roth wrote: > - or have an convenient flag in loaders.conf that allows to > run Beastie menu but display some other decoration? I I have an idea and the patch in PR 74577 is about halfway there. I suggest providing a script that forth-ifies a provided ASCII logo, and a loader option to load a banner file from disk. This way, if, say, an OEM wanted to put contact information in there, they could put in loader.conf: banner_enable="YES" banner_file="/boot/oem.banner" and have that displayed instead of the beastie. The forthifier script would turn the file into a forth function definition and then it can be included with standard routines in the loader. Then your banner function would just call it. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with world build in RELENG_5_4
On Mon, 11 Apr 2005, Jose M Rodriguez wrote: > Hi, > > I found a little problem with RELENG_5_4 buildworld in my env. > > I have a little patched RELENG_5_4 src in a local cvs server, mounted > ro,-L in the build machine (/usr/src) > > No rpc.lockd or rpc.statd daemon running in both machines. build > machine timesync with cvs server by ntpdate before build. > > Every time I do a rm -rf /usr/obj/* && cd /usr/src && make buildworld I > get: > > ===> share/info > ===> include > rm -f osreldate.h version vers.c > rm: version: Read-only file system > *** Error code 1 > > The only thing I change form previous week builds are the -L mount and > disabling the rpc.lockd and rpc.statd daemons in both machines. > > I can solve the problem doing a make obj before make buildworld. Sounds like these files may be leftovers from a local build on the NFS server. You might try doing 'make cleandir; make cleandir' on the server to remove any remnants. Areyou setting MAKEOBJDIRPREFIX in /etc/make.conf? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: suboptimal handling of accidentally pulled usb devices (5.4)
On Sat, 9 Apr 2005, Matthias Buelow wrote:
> every so often, I forget to unmount my ipod (usb2) before pulling it
> from my PC. While this and the mess that ensues is clearly a user
> error, it would be nice if this exceptional situation would get handled
> a bit more gracefully by the OS. What happens now is that I cannot use
> the device anymore ("Resource unavailable") until I reboot. Trying to
> unmount the still mounted filesystem (no matter if the device is plugged
> back in or not) simply gives:
Please see the archives for a lenghty explanation of why this is not going
to be fixed in the near-term future.
--
Doug White| FreeBSD: The Power to Serve
[EMAIL PROTECTED] | www.FreeBSD.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
