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: 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: PNP0c01 can't assign resources (memory) unknown: PNP0303 can't assign resources (port) unknown: PNP0f13 can't assign resources (irq) unknown: PNP0501 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0400 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-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: 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 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: 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: 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: 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: 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: 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: LSILogic MegaRAID 1.51 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 Version 1.1 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=51READY,DSC,ERROR error=84ICRC,ABORTED 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=51READY,DSC,ERROR error=4ABORTED ad5: FAILURE - SETFEATURES SET TRANSFER MODE status=51READY,DSC,ERROR error=4ABORTED ad5: FAILURE - SETFEATURES ENABLE RCACHE status=51READY,DSC,ERROR error=4ABORTED ad5: FAILURE - SETFEATURES ENABLE WCACHE status=51READY,DSC,ERROR error=4ABORTED ad5: FAILURE - SET_MULTI status=51READY,DSC,ERROR error=4ABORTED ad4: FAILURE - WRITE_DMA timed out LBA=234441585 ad4: write metadata failed ad5: FAILURE - WRITE_DMA status=59READY,DSC,DRQ,ERROR error=4ABORTED dma=0x06 LBA=234441585 ad5: write metadata failed ad6: req=0xc853c190 WRITE_DMA semaphore timeout !! DANGER Will Robinson !! [dmesg] atapci0: Promise PDC20267 UDMA100 controller port 0xa400-0xa407,0xa800-0xa803,0xac00-0xac07,0xb000-0xb003,0xb400-0xb43f mem 0xf812-0xf813 irq 18 at device 12.0 on pci0 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 ad4: 114473MB WDC WD1200JB-00DUA3 75.13B75 at ata2-master UDMA100 ad5: 114473MB WDC WD1200JB-00DUA3 75.13B75 at ata2-slave UDMA100 ad6: 114473MB WDC WD1200JB-00GVA0 08.02D08 at ata3-master UDMA100 ad7: 114473MB WDC WD1200JB-00GVA0 08.02D08 at ata3-slave UDMA100 ar0: 228946MB Promise Fasttrak RAID0+1 (stripe 64 KB) 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: 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: 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: 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 Generic ISA VGA unknown: PNP0303 can't assign resources (port) unknown: PNP0c02 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0400 can't assign resources (port) unknown: PNP0700 can't assign resources (port) Timecounter [...] Timecounters [...] Waiting 15 seconds for SCSI md0 preloaded image /mfsroot 4423680 bytes at 0xc0a34270 da0 at bt0 bus 0 target 0 lun 0 da0: SEAGATE ST39173LW 6246 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: 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: 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: 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: 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: INTEL SWV25 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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x400CNTX-ID 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: 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) 6pid 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: 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]
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: 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]
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: 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: 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: 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: 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: 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: 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: 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-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 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 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-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: 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: 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 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: Keyboard controller (i8042) 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: 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: Diskless boot problem
On Mon, 23 May 2005, [ISO-8859-2] Sawek 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: 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' repeats 245 times
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 = 12
ss = 16
esp = 0
softseg = {ssd_base = 0, ssd_limit = 1048575,
ssd_type = 27,
ssd_dpl = 0, ssd_p = 1,
ssd_xx = 0, ssd_xx1 = 0, ssd_def32 = 1, ssd_gran = 1}
#4 0xc0642535 in trap (frame=
{tf_fs = 24, tf_es = -1066598384, tf_ds =
-1066532848, tf_edi =
-1053916800, tf_esi = -1049515008, tf_ebp = -945025988, tf_isp =
-945026060, tf_ebx = -1053916800, tf_edx = -1053937024,
tf_ecx = 56,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip =
-1068480504, tf_cs =
8, tf_eflags = 65683, tf_esp = -1053914880, tf_ss = 582}) at
/usr/src/sys/i386/i386/trap.c:255
p = (struct proc *) 0xc12e754c
sticks = 3241036032
i = 0
ucode = 0
type = 12
code = 0
eva = 36
#5 0xc062da3a in calltrap () at
/usr/src/sys/i386/i386/exception.s:140
No locals.
#6 0x0018 in ?? ()
No symbol table info
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: 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: 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] Sawek 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: 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' repeats 245 times
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 = 12
ss = 16
esp = 0
softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27, ssd_dpl
= 0, ssd_p = 1,
ssd_xx = 0, ssd_xx1 = 0, ssd_def32 = 1, ssd_gran = 1}
#4 0xc0642535 in trap (frame=
{tf_fs = 24, tf_es = -1066598384, tf_ds = -1066532848, tf_edi =
-1053916800, tf_esi = -1049515008, tf_ebp = -945025988, tf_isp = -945026060,
tf_ebx = -1053916800, tf_edx = -1053937024, tf_ecx = 56, tf_eax = 0,
tf_trapno = 12, tf_err = 0, tf_eip = -1068480504, tf_cs = 8, tf_eflags =
65683, tf_esp = -1053914880, tf_ss = 582}) at
/usr/src/sys/i386/i386/trap.c:255
p = (struct proc *) 0xc12e754c
sticks = 3241036032
i = 0
ucode = 0
type = 12
code = 0
eva = 36
#5 0xc062da3a in calltrap () at /usr/src/sys/i386/i386/exception.s:140
No locals.
#6 0x0018 in ?? ()
No symbol table info available.
#7 0xc06d0010 in ipq ()
No symbol table info available.
#8 0xc06e0010 in sc_buffer.3 ()
No symbol table info available.
#9 0xc12e8180 in ?? ()
No symbol table info available.
#10 0xc171ac00 in ?? ()
No symbol table info available.
#11 0xc7ac0c3c in ?? ()
No symbol table info available.
#12 0xc7ac0bf4 in ?? ()
No symbol table info available.
#13 0xc12e8180 in ?? ()
No symbol table info available.
#14 0xc12e3280 in ?? ()
No symbol table info available.
#15 0x0038 in ?? ()
No symbol table info available.
#16 0x in ?? ()
No symbol table info available.
#17 0x000c in ?? ()
No symbol table info available.
#18 0x in ?? ()
No symbol table info available.
#19 0xc0504808 in turnstile_wait (ts=0xc12e3280, lock=0xc06d022c,
owner=0xc171ac00)
at /usr/src/sys/kern/subr_turnstile.c:243
tc = (struct turnstile_chain *) 0xc06cb770
td1 = (struct thread *) 0xc12e8180
#20 0xc04d2b7f in _mtx_lock_sleep (m=0xc06d022c, td=0xc12e8180, opts=0,
file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:552
ts = (struct turnstile *) 0x0
owner = (struct thread *) 0xc171ac00
v = 0
#21 0xc058a592 in tcp_isn_tick (xtp=0x0) at
/usr/src/sys/netinet/tcp_subr.c:1380
projected_offset = 0
#22 0xc04ed069 in softclock (dummy=0x0) at
/usr/src/sys/kern/kern_timeout.c:279
c_func = (void (*)(void *)) 0xc058a4d0 tcp_isn_tick
c_arg = (void *) 0x0
c_flags = 14
c = (struct callout *) 0x0
bucket = (struct callout_tailq *) 0xc39ba4a8
steps = 14
depth = 2
mpcalls = 2
gcalls = 0
wakeup_cookie = 14
#23 0xc04c460a in ithread_loop (arg=0xc12fd500) at
/usr/src/sys/kern/kern_intr.c:547
ih = (struct intrhand *) 0xc12e2c80
p = (struct proc *) 0xc12e754c
count = 0
warming = 5000
warned = 0
#24 0xc04c32c2 in fork_exit (callout=0xc04c4550 ithread_loop, arg=0x0,
frame=0x0)
at /usr/src/sys/kern/kern_fork.c:791
p = (struct proc *) 0xc12e754c
#25 0xc062da9c in fork_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
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: 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: 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: DELL VIRTUAL DISK IM 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: 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: 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: 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: Promise PDC20378 SATA150 controller 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: nForce 4, SATA Drive only runs at UDMA33?
-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: 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: 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: 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: 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: 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: 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: 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: 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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 1073479680 (1023 MB) avail memory = 1040789504 (992 MB) ACPI APIC Table: DELL PE BKC 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 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 32-55 on motherboard ioapic2 Version 2.0 irqs 64-87 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: DELL PE BKC 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: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 amr0: LSILogic MegaRAID 1.51 mem 0xdfee-0xdfef,0xd80f-0xd80f irq 46 at device 14.0 on pci2 amr0: LSILogic PERC 4e/Si Firmware 513O, BIOS H418, 256MB RAM pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge at device 4.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge at device 5.0 on pci0 pci5: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge at device 0.0 on pci5 pci6: ACPI PCI bus on pcib6 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 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: ACPI PCI-PCI bridge at device 0.2 on pci5 pci7: ACPI PCI bus on pcib7 em1: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 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: ACPI PCI-PCI bridge at device 6.0 on pci0 pci8: ACPI PCI bus on pcib8 pcib9: ACPI PCI-PCI bridge at device 30.0 on pci0 pci9: ACPI PCI bus on pcib9 pci9: display, VGA at device 13.0 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 UDMA100 controller 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: floppy drive controller 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: ISA Option ROMs at iomem 0xec000-0xe,0xce800-0xcf7ff,0xcb000-0xcbfff,0xc-0xcafff on isa0 pmtimer0 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 ppc0: parallel port not found. sc0: System console 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: Generic ISA VGA 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 SAMSUNG CD-ROM SN-124/N104 at ata0-master PIO4 amrd0: LSILogic MegaRAID logical drive on amr0 amrd0: 69880MB (143114240 sectors) RAID 1 (optimal) ses0 at amr0 bus 0 target 6 lun 0 ses0: PE/PV 1x2 SCSI BP 1.0 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
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: Promise PDC20378 SATA150 controller 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: RealTek 8139 10/100BaseTX 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: 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: 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: 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: 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: 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: 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: 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: 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 ip and it works fine. But if I try ping -s 39 ip (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: Broadcom BCM5703X Gigabit Ethernet, ASIC rev. 0x1100 mem 0xf7ef-0xf7 ef irq 24 at device 1.0 on pci3 bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0xf7ef miibus0: MII bus on bge0 brgphy0: BCM5703 10/100/1000baseTX PHY 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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=1aTXCSUM,VLAN_MTU,VLAN_HWTAGGING 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 full-duplex) 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: 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: 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: 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: unexpected panic in idle process (RELENG_5 2005/04/25UTC)
0 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 5.4-RC3 Kernel Panic: vinvalbuf: dirty bufs (backtrace included)
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: ATI Radeon If R250 9000 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: 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: 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: 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: floppy drive controller (FDE) 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: fxp lockups on 5.4-RC1
0 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: 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]
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: 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]
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: 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: Intel 6300ESB (ICH) SMBus controller 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: Intel 6300ESB (ICH) SMBus controller 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: 4.11R panics
On Sun, 10 Apr 2005, Kirill Ponomarew wrote:
On Fri, Apr 08, 2005 at 10:14:17AM -0700, Doug White wrote:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x20202020
Hm, something ran into a bunch of ASCII spaces..
Can you jump to frame #6 and print *kbp? It appears the kernel malloc
bucket list is corrupted, so I'm curious just how badly that struct is
spammed.
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) up 6
#6 0xc0193533 in malloc (size=324, type=0xc030d780, flags=9)
at /usr/src/sys/kern/kern_malloc.c:243
243 va = kbp-kb_next;
(kgdb) print *kbp
$1 = {kb_next = 0x20202020 Address 0x20202020 out of bounds,
kb_last = 0xcc8fa000 , kb_calls = 5704, kb_total = 448, kb_elmpercl = 8,
kb_totalfree = 13, kb_highwat = 40, kb_couldfree = 0}
Not very, apparently.
Dunno what to say ... I'd guess something coughed up a bad address to a
DMA op or something and it just happened to land there. If you can
reproduce this with any sort of regularity there might be a bug, although
that seems unlikely since that code hasn't changed in years and this is
the first such report I've seen of this :)
--
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]
