Re: 9.0 beta2 & the new bsdinstaller
Fbsd8 wrote: > 6. At the "Complete screen" when the reboot option is selected the > cd/dvd drive should automatically open so the install media can be > removed just like sysinstall does. If disc1.iso or dvd.iso was installed > to memstick and used to boot from to install the system, then a message > screen should pop out saying the memstick has to be removed now before > the reboot starts. Don't let the reboot occur until the memstick is removed. Do NOT alter! More often than not, (1) you keep floppies, optical discs, and memory sticks in your computer without intending to boot from them, and (2) you'll want to use your BIOS's boot-once functionality (press a specific keyboard button to bring up the media choser menu for that boot; otherwise boot from the hard drives) whenever you do want to boot from floppies, optical discs, or memory sticks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0 beta2 & the new bsdinstaller
On Sun, Sep 25, 2011 at 3:01 PM, Fbsd8 wrote: > deeptec...@gmail.com wrote: >> >> Fbsd8 wrote: >>> >>> 6. At the "Complete screen" when the reboot option is selected the >>> cd/dvd drive should automatically open so the install media can be >>> removed just like sysinstall does. If disc1.iso or dvd.iso was installed >>> to memstick and used to boot from to install the system, then a message >>> screen should pop out saying the memstick has to be removed now before >>> the reboot starts. Don't let the reboot occur until the memstick is >>> removed. >> >> Do NOT alter! More often than not, >> (1) you keep floppies, optical discs, and memory sticks in your >> computer without intending to boot from them, and >> (2) you'll want to use your BIOS's boot-once functionality (press a >> specific keyboard button to bring up the media choser menu for that >> boot; otherwise boot from the hard drives) whenever you do want to >> boot from floppies, optical discs, or memory sticks. >> >> >> > You have missed the subject completely of what #6 is addressing. This has > nothing to do with telling the pc hardware which media to boot from at power > up time like you suggest in your post. > > This has to do with the logic of the new bsdinstall process and the > differences between bsdinstall and sysinstall in the way the install media > is removed from the pc before it reboots as part of the normal install > process. I did not suggest anything related to hardware settings. FreeBSD can't and shouldn't manipulate settings of a proprietary BIOS. In fact, proper BIOSes have the option to allow changes to settings only via the hardware-based BIOS menu (ie., to block the OS from changing BIOS settings). Instead, I stated the reason why - unmounting and ejecting the disc, or - unmounting the memory stick and waiting for it to be removed will be a nuisance for the majority of the users, and a convenience for only the minority. As others (Chris Rees, Miroslav Lachman) have said, a simple reminder is sufficient. BTW, let's assume that the user uses WRONG(TM) boot settings in the BIOS, and therefore does want to remove a disc or memory stick at the end of the installation process. What is the manual removability of discs and memory sticks at the end of the installation process? Because - I can't eject discs (via the drive's eject button) while they are mounted, - recently, there were some FreeBSD instability issues when unplugging mounted memory sticks. So it seems that bsdinstall should first unmount the installation media. On the other hand, unacknowledged unmounting is still not desired, because theoretically the user might want to do something via the auxiliary console, for which the installation media is required. To cover the above points, I propose the following dialog: (1) the body text of "Installation has finished. You may now reboot the machine. You also have the option to unmount/eject the installation media before rebooting. Removal of the media may be required to avoid starting the installer again on the next boot.", (2) a button labeled "unmount/eject installation media", (3) a button labeled "reboot", which should be the default selection. Chosing the "unmount/eject installation media" button will unmount the media, and eject it if it's a disc, and the following dialog will be shown: (1) the body text of "Please remove the installation media. Press any key to reboot." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panic: ffs_blkfree_cg: freeing free block
A panic occured while I was ``rm -rf''ing a large file&directory tree (that I just created with untar) on an old drive that I have not used for a long time. Unfortunately I'm not 100% sure that the filesystem was clean when I mounted it today. Could that result in such a panic? I don't have the intermediate object files for the kernel; now I'm building the kernel again (from the appropriate, exact sources). That shouldn't harm debugging, should it? Meanwhile, I'll take any debug info requests, which I'll attempt to address shortly. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: ffs_blkfree_cg: freeing free block
On Fri, Oct 28, 2011 at 3:40 PM, Bjoern A. Zeeb wrote: > On Fri, 28 Oct 2011, deeptec...@gmail.com wrote: >> I don't have the intermediate object files for the kernel; now I'm >> building the kernel again (from the appropriate, exact sources). That >> shouldn't harm debugging, should it? Meanwhile, I'll take any debug >> info requests, which I'll attempt to address shortly. > > Do you know at which revision the kernel was or about from when? Of course. r226289. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: ffs_blkfree_cg: freeing free block
With object files which were built using the original kernel configuration file (no debugging symbols included): #kgdb kernel /var/crash/vmcore.4 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"...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0xc0687d88 in doadump () (kgdb) bt #0 0xc0687d88 in doadump () #1 0xc0688302 in kern_reboot () #2 0xc0688768 in panic () #3 0xc07f92bf in ffs_blkfree_cg () #4 0xc07f9417 in ffs_blkfree () #5 0xc0803259 in ffs_indirtrunc () #6 0xc08042e1 in ffs_truncate () #7 0xc083171c in ufs_inactive () #8 0xc0712718 in vinactive () #9 0xc0716e2a in vputx () #10 0xc071affb in kern_unlinkat () #11 0xc071b1a6 in kern_unlink () #12 0xc071b1ca in sys_unlink () #13 0xc089c954 in syscall () #14 0xc0887021 in Xint0x80_syscall () #15 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) wtf? With object files which were built using a kernel configuration file that had ``makeoptions DEBUG=-g'' inserted compared to the original configuration file: #kgdb kernel.debug /var/crash/vmcore.4 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"... Cannot access memory at address 0x0 (kgdb) bt #0 0x in ?? () wtf? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: ffs_blkfree_cg: freeing free block
On Fri, Oct 28, 2011 at 11:16 AM, deeptec...@gmail.com wrote: > I don't have the intermediate object files for the kernel; now I'm > building the kernel again (from the appropriate, exact sources). That > shouldn't harm debugging, should it? On Sat, Oct 29, 2011 at 2:35 AM, Garrett Cooper wrote: > On Fri, Oct 28, 2011 at 4:34 PM, deeptec...@gmail.com > wrote: >> With object files which were built using the original kernel >> configuration file (no debugging symbols included): >> >> #kgdb kernel /var/crash/vmcore.4 >> 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"...(no debugging >> symbols found)... >> Attempt to extract a component of a value that is not a structure pointer. >> Attempt to extract a component of a value that is not a structure pointer. >> #0 0xc0687d88 in doadump () >> (kgdb) bt >> #0 0xc0687d88 in doadump () >> #1 0xc0688302 in kern_reboot () >> #2 0xc0688768 in panic () >> #3 0xc07f92bf in ffs_blkfree_cg () >> #4 0xc07f9417 in ffs_blkfree () >> #5 0xc0803259 in ffs_indirtrunc () >> #6 0xc08042e1 in ffs_truncate () >> #7 0xc083171c in ufs_inactive () >> #8 0xc0712718 in vinactive () >> #9 0xc0716e2a in vputx () >> #10 0xc071affb in kern_unlinkat () >> #11 0xc071b1a6 in kern_unlink () >> #12 0xc071b1ca in sys_unlink () >> #13 0xc089c954 in syscall () >> #14 0xc0887021 in Xint0x80_syscall () >> #15 0x0033 in ?? () >> Previous frame inner to this frame (corrupt stack?) >> >> wtf? >> >> With object files which were built using a kernel configuration file >> that had ``makeoptions DEBUG=-g'' inserted compared to the original >> configuration file: >> >> #kgdb kernel.debug /var/crash/vmcore.4 >> 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"... >> Cannot access memory at address 0x0 >> (kgdb) bt >> #0 0x in ?? () >> >> wtf? > > Something stomped on the stack. More like: the release build doesn't have enough debug information in itself, and the release build is not debuggable at all using debug objects that have been built posteriorly. > What was the previous version of > FreeBSD (major.minor.subminor, svn revision) at worked? Not applicable. The panic occured, out of nowhere, on an r226289 kernel that has been working well and is still working well, with the exception of the panic. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
lockup during probing because of a memory stick
If a USB mass storage device was connected when the computer was turned on or reset and the device is left connected, then the system locks up somewhere around the ``acpi0: on motherboard'' line (not exactly deterministically at that line). Otherwise (if the device is connected or disconnected just before FreeBSD started booting, or if the device is nowhere near the computer for the whole booting process), the system boots fine. I'm using a -CURRENT kernel. I don't recall this case happening some time ago. But now, this happens with and without the NEW_PCIB option. I mention this because ``acpi0: on motherboard'' is shortly followed by ``acpi0: reservation of 0, a (3) failed'', whatever that means. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: lockup during probing because of a memory stick
Spam: == ``dmesg'' begins == Copyright (c) 1992-2011 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 9.9-CURRENT #0 r226900M: Sat Oct 29 19:06:59 CEST 2011 devhc@:/usr/obj/usr/src/sys/HQ i386 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.72-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Family = f Model = 2 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 536870912 (512 MB) avail memory = 513859584 (490 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 1fef (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xd000-0xd0ff mem 0xd000-0xdfff,0xf7ee-0xf7ee irq 16 at device 0.0 on pci1 drm0: on vgapci0 info: [drm] AGP at 0xf800 64MB info: [drm] Initialized radeon 1.31.0 20080613 vgapci1: mem 0xe000-0xefff,0xf7ef-0xf7ef at device 0.1 on pci1 uhci0: port 0xc880-0xc89f irq 16 at device 29.0 on pci0 usbus0: on uhci0 uhci1: port 0xcc00-0xcc1f irq 19 at device 29.1 on pci0 usbus1: on uhci1 ehci0: mem 0xf7dffc00-0xf7df irq 23 at device 29.7 on pci0 usbus2: EHCI version 1.0 usbus2: on ehci0 pcib2: at device 30.0 on pci0 pcib2: failed to allocate initial memory window: 0xf7f0-0xfbff pci2: on pcib2 skc0: <3Com 3C940 Gigabit Ethernet> port 0xe800-0xe8ff mem 0xf7ffc000-0xf7ff irq 22 at device 5.0 on pci2 skc0: 3Com Gigabit LOM (3C940) rev. (0x1) sk0: on skc0 sk0: Ethernet address: 00:0e:a6:35:15:91 miibus0: on sk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto pcm0: port 0xec00-0xec3f irq 20 at device 12.0 on pci2 pcm0: pcm0: isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xc-0xccfff pnpid ORM on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 p4tcc0: on cpu0 p4tcc1: on cpu1 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ata1: DMA limited to UDMA33, controller found non-ATA66 cable ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 device ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 78167MB (160086528 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). Root mount waiting for: usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 uhub2: 4 ports with 4 removable, self powered Root mount waiting for: usbus2 ugen2.2: at usbus2 umass0: on usbus2 Trying to mount root from ufs:/dev/ada0s1a [rw,noatime]... da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 1955MB (4005886 512 byte sectors: 255H 63S/T 249C) ugen0.2: at usbus0 ums0: on usbus0 ums0: 5 buttons and [XYZT] coordinates ID=1 sk0: link state changed to UP == ``dmesg'' ends == == ``devinfo -u'' begins == Interrupt request lines: 0 (attimer0) 1 (atkbdc0) 3-7 (root0) 8 (atrtc0) 9 (acpi0) 10-13 (root0) 14 (ata0) 15 (ata1) 16 (uhci0) 16 (vgapci0) 17-18 (root0
Re: lockup during probing because of a memory stick
On Sun, Oct 30, 2011 at 9:27 PM, Hans Petter Selasky wrote: > On Saturday 29 October 2011 23:26:29 deeptec...@gmail.com wrote: >> I don't recall this case happening some time ago. But now, this >> happens with and without the NEW_PCIB option. I mention this because >> ``acpi0: on motherboard'' is shortly followed by >> ``acpi0: reservation of 0, a (3) failed'', whatever that means. > ACPI involves some USB BIOS code most likely which is causing the crash. I > think this is maybe not a FreeBSD issue, but if you can binary search the > revisions to find exactly what commit broke your system, them I can look > further at your issue. Actually, I've just tested a pre-compiled 7.3-RELEASE GENERIC kernel, and the lockup also occurs there. > Have you tried to turn off USB legacy support in the BIOS? Hmm. Interesting, only a combination of the following result in the lockup: - Legacy USB Support: Auto (enable if and only if a USB device is connected) or Enabled, - USB 2.0 Controller: Enabled, - USB 2.0 Controller Mode: HiSpeed, - the memory stick is plugged in when the computer starts, and - the memory stick is plugged in when FreeBSD boots. Note that, to reproduce the lockup, it is not sufficient to just have the said BIOS settings (Legacy USB Support: Enabled, etc.), it is also required that the mutherboard recognize the memory stick when the computer starts, and to have the memory stick connected when FreeBSD boots. (If I disable 2.0 support, or set the speed to FullSpeed, or disable legacy support, or do not have the stick plugged in when the computer starts, or do not have the stick plugged in when FreeBSD boots, then the lockup does not occur.) But Windows XP does not produce any lockups in the case where FreeBSD does. Furthermore, in all cases, the memory stick is usable from FreeBSD if FreeBSD boots successfully. So why should I expect FreeBSD to lock up? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: lockup during probing because of a memory stick
On Mon, Oct 31, 2011 at 3:01 AM, Garrett Cooper wrote: > On Oct 30, 2011, at 6:47 PM, deeptec...@gmail.com wrote: > >> On Sun, Oct 30, 2011 at 9:27 PM, Hans Petter Selasky >> wrote: >> >>> On Saturday 29 October 2011 23:26:29 deeptec...@gmail.com wrote: >> >>>> I don't recall this case happening some time ago. But now, this >> >>>> happens with and without the NEW_PCIB option. I mention this because >> >>>> ``acpi0: on motherboard'' is shortly followed by >> >>>> ``acpi0: reservation of 0, a (3) failed'', whatever that means. >> >> >> >>> ACPI involves some USB BIOS code most likely which is causing the crash. I >> >>> think this is maybe not a FreeBSD issue, but if you can binary search the >> >>> revisions to find exactly what commit broke your system, them I can look >> >>> further at your issue. >> >> >> >> Actually, I've just tested a pre-compiled 7.3-RELEASE GENERIC kernel, >> and the lockup also occurs there. >> >> >> >>> Have you tried to turn off USB legacy support in the BIOS? >> >> >> >> Hmm. Interesting, only a combination of the following result in the lockup: >> >> - Legacy USB Support: Auto (enable if and only if a USB device is >> connected) or Enabled, >> >> - USB 2.0 Controller: Enabled, >> >> - USB 2.0 Controller Mode: HiSpeed, >> >> - the memory stick is plugged in when the computer starts, and >> >> - the memory stick is plugged in when FreeBSD boots. >> >> Note that, to reproduce the lockup, it is not sufficient to just have >> the said BIOS settings (Legacy USB Support: Enabled, etc.), it is also >> required that the mutherboard recognize the memory stick when the >> computer starts, and to have the memory stick connected when FreeBSD >> boots. (If I disable 2.0 support, or set the speed to FullSpeed, or >> disable legacy support, or do not have the stick plugged in when the >> computer starts, or do not have the stick plugged in when FreeBSD >> boots, then the lockup does not occur.) >> >> >> >> But Windows XP does not produce any lockups in the case where FreeBSD >> does. Furthermore, in all cases, the memory stick is usable from >> FreeBSD if FreeBSD boots successfully. So why should I expect FreeBSD >> to lock up? > > > Vendor hacks and limited testing on other OSes is the most likely > cause, if it's not a bug within FreeBSD. Just to narrow things down a bit... > 1. Are there are BIOS updates for your motherboard? Yes, and I have the latest non-beta version (v1019 (dated 2004-11-08) for P4P800 mutherboards). > 2. Do you have ACPI 2.0 support enabled in the BIOS (I was reminded of this > because some ASUS MBs default this setting to off -- which may or may not > cause problems with FreeBSD)? Yes (also, I've just tried disabling ACPI 2.0, with no luck). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
WTF mergemaster VCS Id checking?
Every time I run mergemaster, I have to manually confirm all of the local changes I have done to /etc (ie., state how to merge the temporary and existing files), even files have not changed in the upstream since the last mergemaster run (for example, temproot/etc/master.passwd virtually never changes). This behaviour is annoying, but I've already gotten used to it, and thought that it's the preferred one, to force a system administrator to review, periodically, all changes in /etc. I was surprized that today, mergemaster did not mention one of my changes in /etc: *** Temp ./etc/rc.d/bgfsck and installed have the same CVS Id, deleting So it now seems that it actually is intended for mergemaster to mention only files that have changed in the upstream since the last mergemaster run, but that funtionality fails. Apparently, some upstream files have the following VCS Id: # $FreeBSD$ and that anulls version checking. Recently, a lot of files in /etc (ie., rc.d files) have received full VCS Id strings, but not all. Someone ought to touch files in the subversion repository? So in either way you look at it, something is WRONG(TM). BTW, off-topic: 1. mergemaster outputs "CVS Id", while mergemaster's manpage contains "VCS Id". One of these is WRONG(TM). Which one? 2. mergemaster outputs "Use 'i' to install merged file". TODO: add a "the". 3. The BUGS section of mergemaster's manpage is redundant. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
"rm -rf /" fanclub
Well, I did not actually get a full membership to the "rm -rf /" fanclub, but I managed to remove all installed ports, basically requiring a full reinstall. Here's how it happened: Once upon a time, I did a full reinstall (not because of "rm -rf /"-like things). I kept the old installation's full filesystem hierarchy located in /old. I was then going through the old hierarchy to salvage important bits and delete the rest. At one point, I was in /old/usr, and did "rm -rf X11R6/ bin/ lib/ ...". I was a bit hasty, and forgot to remove the ending backslashes from the directory names, which were inserted by csh's autocompletion. And as it turns out, X11R6 is actually a symlink to /usr/local, and not usr/local or .usr/local! Also, /home is a symlink to /usr/home, and not usr/home or ./usr/home, but I managed to stay clear of that deathtrap. In a web search, I found that someone was about to fix the /home symlink in 2004 [1]. Uhm, any time soon? BTW, is the existence of the X11R6 symlink still required for some compatibility? [1] http://lists.freebsd.org/pipermail/freebsd-hackers/2004-January/005391.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "rm -rf /" fanclub
On Thu, Feb 23, 2012 at 11:41 PM, deeptec...@gmail.com wrote: > X11R6 is actually a symlink to /usr/local, and not usr/local or > .usr/local! Also, /home is a symlink to /usr/home, and not usr/home or > ./usr/home I meant to say that X11R6 should be a symlink to local or ./local. About /home: I've just noticed that /home points to usr/home in the newest release. The newest basic installation (base + kernel) doesn't even come with an X11R6 symlink, yet I did have it after a full install (-CURRENTization + ports), so that symlink must be coming from mergemaster or some port. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SeaMonkey eats the CPU as of r232144
As of r232144, SeaMonkey (a web browser) runs rather slowly and is constantly eating 100% CPU time. Before r232144, SeaMonkey would start up and run faster, and when it is not in use (is idling), its CPU usage would slowly converge to 0. I have a P4 processor [with HT], an r232012 world, and similarly recent ports. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
pcib allocation failure
pcib1: at device 1.0 on pci0 pcib1: failed to allocate initial prefetch window: 0xd000-0xfaff the console output is cut shortly after those 2 lines (but the machine seems to continue booting, as i have reset'd the machine, after which "/" was found to be improperly dismounted). this happens with a the r221862 kernel, but not with the r221309 kernel. a quick search reveals something: http://www.freebsd.org/cgi/query-pr.cgi?pr=143874 (i have no idea what that is). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pcib allocation failure
On Sat, May 14, 2011 at 6:27 PM, deeptec...@gmail.com wrote: > pcib1: at device 1.0 on pci0 > pcib1: failed to allocate initial prefetch window: 0xd000-0xfaff > > this happens with a the r221862 kernel, but not with the r221309 kernel. > a quick search reveals something: > http://www.freebsd.org/cgi/query-pr.cgi?pr=143874 (i have no idea what > that is). indeed, r221394 introduced the said behaviour by using a new PCI bus driver or something. with "nooptions NEW_PCIB", even the latest sources (r221970) do not exhibit the said behaviour. i conclude that the new PCI bus driver basically sux. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pcib allocation failure
On Tue, May 17, 2011 at 3:44 PM, John Baldwin wrote: > On Saturday, May 14, 2011 12:27:59 pm deeptec...@gmail.com wrote: >> pcib1: at device 1.0 on pci0 >> pcib1: failed to allocate initial prefetch window: 0xd000-0xfaff >> >> the console output is cut shortly after those 2 lines (but the machine >> seems to continue booting, as i have reset'd the machine, after which >> "/" was found to be improperly dismounted). > > So it actually boots fine, but video output breaks during the boot? Does it > ever come back or it is permanently broken until reboot? the video output is permanently broken until reboot (i was able to gather logs by using delayed rc.d scripts). > Your BIOS is actually violating the PCI spec by assigning the same resource > ranges to two devices on the same PCI bus (the hostb device and the AGP bridge > device). It's also doing so unnecessarily. ok, i've tried changing random BIOS settings, and found that changing "AGP Aperture Size" from 128M to 64M solved the problem with the new PCI bus driver. (i have a computer with 512MiB of RAM and an AGP video card with 128MiB of RAM.) weird. any comments on that? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pcib allocation failure
On Tue, May 17, 2011 at 10:40 PM, John Baldwin wrote: > On Tuesday, May 17, 2011 2:03:42 pm deeptec...@gmail.com wrote: >> On Tue, May 17, 2011 at 3:44 PM, John Baldwin wrote: >> > On Saturday, May 14, 2011 12:27:59 pm deeptec...@gmail.com wrote: >> >> pcib1: at device 1.0 on pci0 >> >> pcib1: failed to allocate initial prefetch window: 0xd000-0xfaff >> >> >> >> the console output is cut shortly after those 2 lines (but the machine >> >> seems to continue booting, as i have reset'd the machine, after which >> >> "/" was found to be improperly dismounted). >> > >> > So it actually boots fine, but video output breaks during the boot? Does >> > it >> > ever come back or it is permanently broken until reboot? >> >> the video output is permanently broken until reboot (i was able to >> gather logs by using delayed rc.d scripts). >> >> > Your BIOS is actually violating the PCI spec by assigning the same resource >> > ranges to two devices on the same PCI bus (the hostb device and the AGP >> > bridge >> > device). It's also doing so unnecessarily. >> >> ok, i've tried changing random BIOS settings, and found that changing >> "AGP Aperture Size" from 128M to 64M solved the problem with the new >> PCI bus driver. (i have a computer with 512MiB of RAM and an AGP video >> card with 128MiB of RAM.) weird. any comments on that? (also, i have noticed a ~64Mi detraction in resource ranges) > Does it still fail to alloc the initial prefetch window in that case? hmm! good question, there does seem to be another failure with pcib2, although without any noticable effect on the system's functionality: pcib2: failed to allocate initial memory window: 0xf7f0-0xfbff for the sake of completeness, here r the logs, coming from an r222043 kernel with the new PCI bus driver: == ``devinfo -rv'' begins == nexus0 npx0 apic0 ram0 I/O memory addresses: 0x0-0x9fbff 0x10-0x1ff2 acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x22-0x3f 0x44-0x5f 0x62-0x63 0x65-0x6f 0x72-0x7f 0x80 0x84-0x86 0x88 0x8c-0x8e 0x90-0x9f 0xa2-0xbf 0xe0-0xef 0x290-0x297 0x480-0x4bf 0x4d0-0x4d1 0x680-0x6ff 0x800-0x87f I/O memory addresses: 0xc-0xd 0xe-0xf 0xfec0-0xfec00fff 0xfed2-0xfed8 0xfee0-0xfee00fff 0xffb0-0xffbf 0xfff0-0x cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU2 p4tcc1 cpufreq1 pcib0 pnpinfo _HID=PNP0A03 _UID=0 at handle=\_SB_.PCI0 I/O ports: 0xcf8-0xcff pci0 hostb0 pnpinfo vendor=0x8086 device=0x2570 subvendor=0x1043 subdevice=0x80f2 class=0x06 at slot=0 function=0 I/O memory addresses: 0xf800-0xfbff agp0 pcib1 pnpinfo vendor=0x8086 device=0x2571 subvendor=0x subdevice=0x class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.P0P1 I/O ports: 0xd000-0xdfff I/O memory addresses: 0xd000-0xf6ff 0xf7e0-0xf7ef pci1 vgapci0 pnpinfo vendor=0x1002 device=0x4150 subvendor=0x17ee subdevice=0x2002 class=0x03 at slot=0 function=0 Interrupt request lines: 16 pcib1 I/O port window: 0xd000-0xd0ff pcib1 memory window: 0xf7ee-0xf7ee pcib1 prefetch window: 0xd000-0xdfff vgapm0 drm0 vgapci1 pnpinfo vendor=0x1002 device=0x4170 subvendor=0x17ee subdevice=0x2003 class=0x038000 at slot=0 function=1 pcib1 memory window: 0xf7ef-0xf7ef pcib1 prefetch window: 0xe000-0xefff drm1 uhci0 pnpinfo vendor=0x8086 device=0x24d2 subvendor=0x1043 subdevice=0x80a6 class=0x0c0300 at slot=29 function=0 handle=\_SB_.PCI0.USB1 Interrupt request lines: 16 I/O ports: 0xc880-0xc89f usbus0 uhub0 uhci1 pnpinfo vendor=0x8086 device=0x24d4 subvendor=0x1043 subdevice=0x80a6 class=0x0c0300 at slot=29 function=1 handle=\_SB_.PCI0.USB2 Interrupt request lines: 19 I/O ports:
Re: pcib allocation failure
On Thu, May 19, 2011 at 2:13 PM, John Baldwin wrote: > Yeah, your BIOS continues to behave very poorly. Please try this hack to see > if it allows your video to still work with any AGP aperture size: > > Index: pci_pci.c > === > --- pci_pci.c (revision 222093) > +++ pci_pci.c (working copy) > @@ -231,7 +231,9 @@ pcib_alloc_window(struct pcib_softc *sc, struct pc > w->name, (uintmax_t)w->base, (uintmax_t)w->limit); > w->base = max_address; > w->limit = 0; > +#if 0 > pcib_write_windows(sc, w->mask); > +#endif > return; > } > pcib_activate_window(sc, type); does not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pcib allocation failure
On Thu, May 19, 2011 at 11:35 PM, John Baldwin wrote:
> On Thursday, May 19, 2011 12:28:46 pm deeptec...@gmail.com wrote:
>> On Thu, May 19, 2011 at 2:13 PM, John Baldwin wrote:
>> > Yeah, your BIOS continues to behave very poorly. Please try this hack to
> see
>> > if it allows your video to still work with any AGP aperture size:
>> >
>> > Index: pci_pci.c
>> > ===
>> > --- pci_pci.c (revision 222093)
>> > +++ pci_pci.c (working copy)
>> > @@ -231,7 +231,9 @@ pcib_alloc_window(struct pcib_softc *sc, struct pc
>> > w->name, (uintmax_t)w->base, (uintmax_t)w->limit);
>> > w->base = max_address;
>> > w->limit = 0;
>> > +#if 0
>> > pcib_write_windows(sc, w->mask);
>> > +#endif
>> > return;
>> > }
>> > pcib_activate_window(sc, type);
>>
>> does not.
>
> Hummm, that should leave the PCI-PCI bridge unchanged until we write the new
> values in place so it's never "turned off" (only updated to use a smaller
> range at some point). You could try patching write_windows to disable IO and
> memory decoding in the PCI command register while the windows are frobbed.
>
> Index: pci_pci.c
> ===
> --- pci_pci.c (revision 222093)
> +++ pci_pci.c (working copy)
> @@ -162,8 +162,13 @@ pcib_write_windows(struct pcib_softc *sc, int mask
> {
> device_t dev;
> uint32_t val;
> + uint16_t cmd;
>
> dev = sc->dev;
> + cmd = pci_read_config(dev, PCIR_COMMAND, 2);
> + if (cmd & (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
> + pci_write_config(dev, PCIR_COMMAND,
> + cmd & ~(PCIM_CMD_PORTEN | PCIM_CMD_MEMEN), 2);
> if (sc->io.valid && mask & WIN_IO) {
> val = pci_read_config(dev, PCIR_IOBASEL_1, 1);
> if ((val & PCIM_BRIO_MASK) == PCIM_BRIO_32) {
> @@ -192,6 +197,8 @@ pcib_write_windows(struct pcib_softc *sc, int mask
> pci_write_config(dev, PCIR_PMBASEL_1, sc->pmem.base >> 16, 2);
> pci_write_config(dev, PCIR_PMLIMITL_1, sc->pmem.limit >> 16,
> 2);
> }
> + if (cmd & (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
> + pci_write_config(dev, PCIR_COMMAND, cmd, 2);
> }
>
> static void
> @@ -231,7 +238,9 @@ pcib_alloc_window(struct pcib_softc *sc, struct pc
> w->name, (uintmax_t)w->base, (uintmax_t)w->limit);
> w->base = max_address;
> w->limit = 0;
> +#if 0
> pcib_write_windows(sc, w->mask);
> +#endif
> return;
> }
> pcib_activate_window(sc, type);
that seems to work.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pcib allocation failure
On Sat, May 21, 2011 at 3:59 PM, deeptec...@gmail.com
wrote:
> On Thu, May 19, 2011 at 11:35 PM, John Baldwin wrote:
>> Index: pci_pci.c
>> ===
>> --- pci_pci.c (revision 222093)
>> +++ pci_pci.c (working copy)
>> @@ -162,8 +162,13 @@ pcib_write_windows(struct pcib_softc *sc, int mask
>> {
>> device_t dev;
>> uint32_t val;
>> + uint16_t cmd;
>>
>> dev = sc->dev;
>> + cmd = pci_read_config(dev, PCIR_COMMAND, 2);
>> + if (cmd & (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
>> + pci_write_config(dev, PCIR_COMMAND,
>> + cmd & ~(PCIM_CMD_PORTEN | PCIM_CMD_MEMEN), 2);
>> if (sc->io.valid && mask & WIN_IO) {
>> val = pci_read_config(dev, PCIR_IOBASEL_1, 1);
>> if ((val & PCIM_BRIO_MASK) == PCIM_BRIO_32) {
>> @@ -192,6 +197,8 @@ pcib_write_windows(struct pcib_softc *sc, int mask
>> pci_write_config(dev, PCIR_PMBASEL_1, sc->pmem.base >> 16, 2);
>> pci_write_config(dev, PCIR_PMLIMITL_1, sc->pmem.limit >> 16,
>> 2);
>> }
>> + if (cmd & (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
>> + pci_write_config(dev, PCIR_COMMAND, cmd, 2);
>> }
>>
>> static void
>> @@ -231,7 +238,9 @@ pcib_alloc_window(struct pcib_softc *sc, struct pc
>> w->name, (uintmax_t)w->base, (uintmax_t)w->limit);
>> w->base = max_address;
>> w->limit = 0;
>> +#if 0
>> pcib_write_windows(sc, w->mask);
>> +#endif
>> return;
>> }
>> pcib_activate_window(sc, type);
>
> that seems to work.
oops, i forgot to set the AGP aperture size to 128M during testing.
that patch actually does NOT work.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pcib allocation failure
On Thu, May 26, 2011 at 3:40 PM, John Baldwin wrote:
> Ohh, you have two devices behind this bridge that have prefetch ranges.
>
> As a hack, can you try this:
>
> Index: pci_pci.c
> ===
> --- pci_pci.c (revision 85)
> +++ pci_pci.c (working copy)
> @@ -162,8 +162,13 @@ pcib_write_windows(struct pcib_softc *sc, int mask
> {
> device_t dev;
> uint32_t val;
> + uint16_t cmd;
>
> dev = sc->dev;
> + cmd = pci_read_config(dev, PCIR_COMMAND, 2);
> + if (cmd & (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
> + pci_write_config(dev, PCIR_COMMAND,
> + cmd & ~(PCIM_CMD_PORTEN | PCIM_CMD_MEMEN), 2);
> if (sc->io.valid && mask & WIN_IO) {
> val = pci_read_config(dev, PCIR_IOBASEL_1, 1);
> if ((val & PCIM_BRIO_MASK) == PCIM_BRIO_32) {
> @@ -192,6 +197,8 @@ pcib_write_windows(struct pcib_softc *sc, int mask
> pci_write_config(dev, PCIR_PMBASEL_1, sc->pmem.base >> 16, 2);
> pci_write_config(dev, PCIR_PMLIMITL_1, sc->pmem.limit >> 16,
> 2);
> }
> + if (cmd & (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
> + pci_write_config(dev, PCIR_COMMAND, cmd, 2);
> }
>
> static void
> @@ -337,6 +344,9 @@ pcib_probe_windows(struct pcib_softc *sc)
> pci_read_config(dev, PCIR_PMLIMITL_1, 2));
> max = 0x;
> }
> + /* XXX: Testing hack */
> + if (device_get_unit(sc->sc_dev) == 1)
i'm assuming that "sc->sc_dev" should be "dev" (this fixes a compilation error).
> + sc->pmem.limit = 0xefff;
> pcib_alloc_window(sc, &sc->pmem, SYS_RES_MEMORY,
> RF_PREFETCHABLE, max);
> }
that seems to work!
btw, is my machine a test-pig for an upcoming change to the PCI bus driver?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pcib allocation failure
On Mon, Jun 6, 2011 at 4:52 PM, John Baldwin wrote: > Can you try out this change. It is a possible "real" solution (or at least a > stopgap until we start using multipass to untangle the resource mess a bit > further): [snip] that doesn't work. i get an allocation failure. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pcib allocation failure
On Tue, Jun 7, 2011 at 4:35 PM, John Baldwin wrote: > On Monday, June 06, 2011 11:02:59 pm deeptec...@gmail.com wrote: >> On Mon, Jun 6, 2011 at 4:52 PM, John Baldwin wrote: >> > Can you try out this change. It is a possible "real" solution (or at > least a >> > stopgap until we start using multipass to untangle the resource mess a bit >> > further): >> [snip] >> >> that doesn't work. i get an allocation failure. > > It is expected to still get an allocation failure. > > Instead what the change does is avoid updating the registers for the window > until after all the devices on the bus have been probed. > > Were you able to save a dmesg somehow from the boot with this patch? == dmesg begins == Copyright (c) 1992-2011 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #0 r222709M: Sun Jun 5 20:01:55 CEST 2011 devhc@:/usr/obj/usr/src/sys/HQ i386 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.71-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Family = f Model = 2 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 536870912 (512 MB) avail memory = 513818624 (490 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 1fef (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xd000-0xd0ff mem 0xd000-0xdfff,0xf7ee-0xf7ee irq 16 at device 0.0 on pci1 drm0: on vgapci0 info: [drm] AGP at 0xf800 64MB info: [drm] Initialized radeon 1.31.0 20080613 vgapci1: mem 0xe000-0xefff,0xf7ef-0xf7ef at device 0.1 on pci1 uhci0: port 0xc880-0xc89f irq 16 at device 29.0 on pci0 usbus0: on uhci0 uhci1: port 0xcc00-0xcc1f irq 19 at device 29.1 on pci0 usbus1: on uhci1 ehci0: mem 0xf7dffc00-0xf7df irq 23 at device 29.7 on pci0 usbus2: EHCI version 1.0 usbus2: on ehci0 pcib2: at device 30.0 on pci0 pcib2: failed to allocate initial memory window: 0xf7f0-0xfbff pci2: on pcib2 skc0: <3Com 3C940 Gigabit Ethernet> port 0xe800-0xe8ff mem 0xf7ffc000-0xf7ff irq 22 at device 5.0 on pci2 skc0: 3Com Gigabit LOM (3C940) rev. (0x1) sk0: on skc0 sk0: Ethernet address: 00:0e:a6:35:15:91 miibus0: on sk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto pcm0: port 0xec00-0xec3f irq 20 at device 12.0 on pci2 pcm0: pcm0: isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xc-0xccfff pnpid ORM on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 p4tcc0: on cpu0 p4tcc1: on cpu1 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ata1: DMA limited to UDMA33, controller found non-ATA66 cable ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 device ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 78167MB (160086528 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). Root mount waiting for: usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self
Re: pcib allocation failure
On Wed, Jun 8, 2011 at 7:56 PM, John Baldwin wrote: > Hmmm, can you revert all your changes to pci_pci.c let me note that so far i had at most 1 of the (4) patches applied at a time (always the last one). if u'd like me to apply "multiple" patches, please send 1 combined patch. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pcib allocation failure
On Wed, Jun 8, 2011 at 7:56 PM, John Baldwin wrote:
> On Wednesday, June 08, 2011 11:20:17 am deeptec...@gmail.com wrote:
>> On Tue, Jun 7, 2011 at 4:35 PM, John Baldwin wrote:
>> found-> vendor=0x1002, dev=0x4170, revid=0x00
>> domain=0, bus=1, slot=0, func=1
>> class=03-80-00, hdrtype=0x00, mfdev=0
>> cmdreg=0x0007, statreg=0x02b0, cachelnsz=4 (dwords)
>> lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns)
>> powerspec 2 supports D0 D1 D2 D3 current D0
>> map[10]: type Prefetchable Memory, range 32, base 0xe000, size 28,
>> enabled
>> pcib1: attempting to grow prefetch window for
>> (0xe000-0xefff,0x1000)
>> pcib1: attempting to grow memory window for
>> (0xe000-0xefff,0x1000)
>
> Odd, I'm not sure why this failed. Hmm, it seems this was always failing for
> you though in the older dmesg's though.
>
> Hmmm, can you revert all your changes to pci_pci.c and try just this change:
>
> Index: pci_pci.c
> ===
> --- pci_pci.c (revision 222863)
> +++ pci_pci.c (working copy)
> @@ -953,7 +975,7 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
> * ok, ensure it is properly aligned for this window.
> * Also check for overflow.
> */
> - if (back <= end && start_free <= back) {
> + if (back <= end + 1 && start_free <= back) {
> if (bootverbose)
> printf("\tback candidate range: %#lx-%#lx\n",
> start_free, back);
failure.
== dmesg begins ==
Copyright (c) 1992-2011 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 is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #0 r222709M: Sun Jun 5 20:01:55 CEST 2011
devhc@:/usr/obj/usr/src/sys/HQ i386
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.72-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf29 Family = f Model = 2 Stepping = 9
Features=0xbfebfbff
Features2=0x4400
real memory = 536870912 (512 MB)
avail memory = 513818624 (490 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
ioapic0 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: on motherboard
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 1fef (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
cpu0: on acpi0
cpu1: on acpi0
pcib0: port 0xcf8-0xcff on acpi0
pci0: on pcib0
agp0: on hostb0
pcib1: at device 1.0 on pci0
pci1: on pcib1
vgapci0: port 0xd000-0xd0ff mem
0xd000-0xdfff,0xf7ee-0xf7ee irq 16 at device 0.0 on
pci1
drm0: on vgapci0
info: [drm] AGP at 0xf800 64MB
info: [drm] Initialized radeon 1.31.0 20080613
vgapci1: mem
0xe000-0xefff,0xf7ef-0xf7ef at device 0.1 on pci1
uhci0: port 0xc880-0xc89f
irq 16 at device 29.0 on pci0
usbus0: on uhci0
uhci1: port 0xcc00-0xcc1f
irq 19 at device 29.1 on pci0
usbus1: on uhci1
ehci0: mem
0xf7dffc00-0xf7df irq 23 at device 29.7 on pci0
usbus2: EHCI version 1.0
usbus2: on ehci0
pcib2: at device 30.0 on pci0
pcib2: failed to allocate initial memory window: 0xf7f0-0xfbff
pci2: on pcib2
skc0: <3Com 3C940 Gigabit Ethernet> port 0xe800-0xe8ff mem
0xf7ffc000-0xf7ff irq 22 at device 5.0 on pci2
skc0: 3Com Gigabit LOM (3C940) rev. (0x1)
sk0: on skc0
sk0: Ethernet address: 00:0e:a6:35:15:91
miibus0: on sk0
e1000phy0: PHY 0 on miibus0
e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto
pcm0: port 0xec00-0xec3f irq 20 at device 12.0 on pci2
pcm0:
pcm0:
isab0: at device 31.0 on pci0
isa0: on isab0
atapci0: port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on
pci0
ata0: on atapci0
ata1: on atapci0
pci0: at device 31.3 (no driver attached)
acpi_button0: on acpi0
attimer0: port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0: port 0x70-0x71 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
atkbdc0: port 0x60,0x64 irq 1 on acpi0
atkbd0: irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
pmtimer0 on isa0
orm0: at iomem 0xc-0xccfff pnpid ORM on isa0
sc0: a
Re: pcib allocation failure
On Thu, Jun 9, 2011 at 3:22 PM, John Baldwin wrote:
> Hmm, I would say 'progress' actually as it's getting better:
>
>
>> map[10]: type Prefetchable Memory, range 32, base 0xe000, size 28,
>> enabled
>> pcib1: attempting to grow prefetch window for
>> (0xe000-0xefff,0x1000)
>> back candidate range: 0xe000-0xf000
>
> It at least attempts to grow it now.
>
> This patch is a slightly more correct fix for the same bug as above but also
> adds extra debugging so I can see why bus_adjust_resource() is failing to
> grow the window. It won't fix it yet, but should output more debug info
> when it fails to grow the window:
see PS.
> Index: pci_pci.c
> ===
> --- pci_pci.c (revision 222863)
> +++ pci_pci.c (working copy)
> @@ -916,7 +934,8 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
>
> /* Move end_free down until it is properly aligned. */
> end_free &= ~(align - 1);
> - front = end_free - count;
> + end_free--;
> + front = end_free - (count - 1);
>
> /*
> * The resource would now be allocated at (front,
> @@ -944,7 +963,7 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
>
> /* Move start_free up until it is properly aligned. */
> start_free = roundup2(start_free, align);
> - back = start_free + count;
> + back = start_free + count - 1;
>
> /*
> * The resource would now be allocated at (start_free,
> @@ -957,7 +976,7 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
> if (bootverbose)
> printf("\tback candidate range: %#lx-%#lx\n",
> start_free, back);
> - back = roundup2(back, w->step) - 1;
> + back = roundup2(back + 1, w->step) - 1;
> back -= rman_get_end(w->res);
> } else
> back = 0;
> @@ -976,6 +995,11 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
> rman_get_end(w->res));
> if (error == 0)
> break;
> + if (bootverbose)
> + device_printf(sc->dev,
> + "failed to grow %s window to %#lx-%#lx: %d\n",
> + w->name, rman_get_start(w->res) - front,
> + rman_get_end(w->res), error);
> front = 0;
> } else {
> error = bus_adjust_resource(sc->dev, type, w->res,
> @@ -983,6 +1007,11 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
> rman_get_end(w->res) + back);
> if (error == 0)
> break;
> + if (bootverbose)
> + device_printf(sc->dev,
> + "failed to grow %s window to %#lx-%#lx: %d\n",
> + w->name, rman_get_start(w->res),
> + rman_get_end(w->res) + back, error);
> back = 0;
> }
> }
== dmesg begins ==
Copyright (c) 1992-2011 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 is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #0 r222709M: Sun Jun 5 20:01:55 CEST 2011
devhc@:/usr/obj/usr/src/sys/HQ i386
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.72-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf29 Family = f Model = 2 Stepping = 9
Features=0xbfebfbff
Features2=0x4400
real memory = 536870912 (512 MB)
avail memory = 513818624 (490 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
ioapic0 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: on motherboard
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 1fef (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
cpu0: on acpi0
cpu1: on acpi0
pcib0: port 0xcf8-0xcff on acpi0
pci0: on pcib0
agp0: on hostb0
pcib1: at device 1.0 on pci0
pci1: on pcib1
vgapci0: port 0xd000-0xd0ff mem
0xd000-0xdfff,0xf7ee-0xf7ee irq 16 at device 0.0 on
pci1
drm0: on vgapci0
info: [drm] AGP at 0xf800 64MB
info: [drm] Initialized radeon 1.31.0 20080613
vgapci1: mem
0xe000-0xefff,0xf7ef-0xf7ef at device 0.1 on pci1
uhci0: port 0xc880-0xc89
Re: pcib allocation failure
On Thu, Jun 9, 2011 at 8:56 PM, John Baldwin wrote:
> On Thursday, June 09, 2011 2:07:31 pm deeptec...@gmail.com wrote:
>> pcib1: attempting to grow prefetch window for
>> (0xe000-0xefff,0x1000)
>> back candidate range: 0xe000-0xefff
>> pcib1: failed to grow prefetch window to 0xd000-0xefff: 6
>
> Hmm, ENXIO is an odd error. rman_adjust_resource() can't fail with that.
>
> Oh, I missed adding bus_adjust_resource() to the x86 "nexus" drivers. :(
>
> Try this patch in addition to the patch to pci_pci.c that you are already
> using:
>
> Index: amd64/amd64/legacy.c
> ===
> --- amd64/amd64/legacy.c (revision 222897)
> +++ amd64/amd64/legacy.c (working copy)
> @@ -81,6 +81,7 @@
> DEVMETHOD(bus_read_ivar, legacy_read_ivar),
> DEVMETHOD(bus_write_ivar, legacy_write_ivar),
> DEVMETHOD(bus_alloc_resource, bus_generic_alloc_resource),
> + DEVMETHOD(bus_adjust_resource, bus_generic_adjust_resource),
> DEVMETHOD(bus_release_resource, bus_generic_release_resource),
> DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
> DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
> Index: dev/acpica/acpi.c
> ===
> --- dev/acpica/acpi.c (revision 222897)
> +++ dev/acpica/acpi.c (working copy)
> @@ -123,6 +123,8 @@
> static struct resource *acpi_alloc_resource(device_t bus, device_t child,
> int type, int *rid, u_long start, u_long end,
> u_long count, u_int flags);
> +static int acpi_adjust_resource(device_t bus, device_t child, int type,
> + struct resource *r, u_long start, u_long end);
> static int acpi_release_resource(device_t bus, device_t child, int type,
> int rid, struct resource *r);
> static void acpi_delete_resource(device_t bus, device_t child, int type,
> @@ -193,6 +195,7 @@
> DEVMETHOD(bus_set_resource, acpi_set_resource),
> DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),
> DEVMETHOD(bus_alloc_resource, acpi_alloc_resource),
> + DEVMETHOD(bus_adjust_resource, acpi_adjust_resource),
> DEVMETHOD(bus_release_resource, acpi_release_resource),
> DEVMETHOD(bus_delete_resource, acpi_delete_resource),
> DEVMETHOD(bus_child_pnpinfo_str, acpi_child_pnpinfo_str_method),
> @@ -1325,29 +1328,40 @@
> }
>
> static int
> -acpi_release_resource(device_t bus, device_t child, int type, int rid,
> - struct resource *r)
> +acpi_is_resource_managed(int type, struct resource *r)
> {
> - struct rman *rm;
> - int ret;
>
> /* We only handle memory and IO resources through rman. */
> switch (type) {
> case SYS_RES_IOPORT:
> - rm = &acpi_rman_io;
> - break;
> + return (rman_is_region_manager(r, &acpi_rman_io));
> case SYS_RES_MEMORY:
> - rm = &acpi_rman_mem;
> - break;
> - default:
> - rm = NULL;
> + return (rman_is_region_manager(r, &acpi_rman_mem));
> }
> + return (0);
> +}
>
> +static int
> +acpi_adjust_resource(device_t bus, device_t child, int type, struct resource
> *r,
> + u_long start, u_long end)
> +{
> +
> + if (acpi_is_resource_managed(type, r))
> + return (rman_adjust_resource(r, start, end));
> + return (bus_generic_adjust_resource(bus, child, type, r, start, end));
> +}
> +
> +static int
> +acpi_release_resource(device_t bus, device_t child, int type, int rid,
> + struct resource *r)
> +{
> + int ret;
> +
> /*
> * If this resource belongs to one of our internal managers,
> * deactivate it and release it to the local pool.
> */
> - if (rm != NULL && rman_is_region_manager(r, rm)) {
> + if (acpi_is_resource_managed(type, r)) {
> if (rman_get_flags(r) & RF_ACTIVE) {
> ret = bus_deactivate_resource(child, type, rid, r);
> if (ret != 0)
> Index: i386/i386/legacy.c
> ===
> --- i386/i386/legacy.c (revision 222897)
> +++ i386/i386/legacy.c (working copy)
> @@ -86,6 +86,7 @@
> DEVMETHOD(bus_read_ivar, legacy_read_ivar),
> DEVMETHOD(bus_write_ivar, legacy_write_ivar),
> DEVMETHOD(bus_alloc_resource, bus_generic_alloc_resource),
> + DEVMETHOD(bus_adjust_resource, bus_generic_adjust_resource),
> DEVMETHOD(bus_release_resource, bus_gener
/var/crash permissions
the FreeBSD Developers' Handbook recommends /var/crash to have drwx-- permissions [1]. ``make installworld'' alters those permissions to drwxr-x---. one of the two is trolling. which one? [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: what is the RIGHT(TM) way to configure background DHCP?
(i intend the discussion to take place primarily on the freebsd-hackers list, i'm CCing the freebsd-current list for a reason stated below.) (original first post: http://lists.freebsd.org/pipermail/freebsd-questions/2011-June/231301.html) On Mon, Jul 4, 2011 at 4:20 PM, Lowell Gilbert wrote: > You might want to try rewording your question, because it didn't make > any sense the first time. very well. though the question should have made perfect sense the first time. > [All of your examples were commented out, so > it was no surprise that they didn't work.] i chose to use # characters to separate rc.conf snippets from the other sentences i wrote. though perhaps #s were an unfortunate choice, because a # has a comment-begins-here meaning in rc.conf. in any case, "attempt 1" and "attempt 2" didn't work, but "attempt 3" did work, and that rules out the use of # for comments in rc.conf. now i will use "= rc.conf snippet begins =" and "= rc.conf snippet ends =" instead of # characters. > I considered trying to use my chrystal ball to guess that you needed > "SYNCDHCP" in your interface config, but you had obviously read the > manual for rc.conf(5), so that seemed unlikely... and "SYNCDHCP" makes things even worse. (i have no idea what "SYNCDHCP" is supposed to do, but in my experience:) "SYNCDHCP" makes the boot process wait until DHCP server replies before proceeding. "SYNCDHCP" is actually almost the same as "DHCP", except that "SYNCDHCP" waits indefinitely, while "DHCP" waits for at most defaultroute_delay, and also, "DHCP" gets "Starting network: lo0 sk0. " printed *before* the IP address assignment process starts, while "SYNCDHCP" gets "Starting network: lo0 sk0. " printed *after* the IP address assignment process finishes. so here is the question rephrased: the boot process of my FreeBSD machines takes a relatively long time. it spends 30 seconds idling at some point, because my network interface (sk0) is supposed to have an IP address assigned via DHCP, and the DHCP server on my LAN takes an extremely long time (~40 seconds) to reply to IP address requests. this is unacceptable for me; i want the FreeBSD boot process to finish 30 seconds earlier, even if i won't get the chance to use the network for ~40 seconds after the booting has finished. this was the actual case when my rc.conf had the following options related to network interfaces: = rc.conf snippet begins = ifconfig_sk0="DHCP" = rc.conf snippet ends = it took me 3 rc.conf configuration attempts to find a configuration in which the boot process does not idle for 30 seconds. the following was the first attempt: = rc.conf snippet begins = background_dhclient="YES" background_dhclient_sk0="YES" = rc.conf snippet ends = with this configuration, the DHCP client isn't even started. ie., the boot process does not idle at all (that's good!), but the network interface will never receive an IP address automatically (that's very bad!). here is the second attempt: = rc.conf snippet begins = ifconfig_sk0="DHCP" background_dhclient="YES" background_dhclient_sk0="YES" = rc.conf snippet ends = with this configuration, the DHCP client is started, but the boot process still idles for 30 seconds at some point (as if the background_dhclient and background_dhclient_ variables had no effect). the final attempt is: = rc.conf snippet begins = ifconfig_sk0="DHCP" defaultroute_delay="0" = rc.conf snippet ends = this configuration works, ie., during the boot process, there is no idling related to waiting for a DHCP server to reply. but this configuration looks hacky. so what is the RIGHT(TM) way to configure the boot process not to idle much in case of a slow DHCP server, and why? i ask this question partially because there is an rc.conf option background_dhclient (also, background_dhclient_), which doesn't seem to do anything, though it should, since it exists (either that, or the option should be removed). (there has been a recent discussion on the freebsd-current list about rc.d parallelization; [reason for CCing:] could recent rc.d changes have made the background_dhclient option useless?) i'd like to have an in-depth explanation on what effect should any combination of the following options should have on the boot process: defaultroute_delay="0", background_dhclient="YES", synchronous_dhclient="YES". (for example, using both background_dhclient="YES" and synchronous_dhclient="YES" seems stupid; i need a clarification if that's not the case.) what's the explanation if there is more than 1 network card (all of which are to have IP addresses assigned via DHCP)? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ghost files
as of recent times, some git rebase operations fail unexpectedly with an error: "cannot create .git/index.lock: file exists". an investigation session was something like the following: $ ls -l .git the index.lock file is not in the shown list. $ ls -l .git/index.lock the file is listed! it's a regular file, its size is ~60KiB. $ cat .git/index.lock some file content is shown. $ mv .git/index.lock .git/someplace moving fails with: index.lock: file does not exist. $ ee .git/index.lock some file content is shown, which i edit and save. then the .git/index.lock file really disappears (cat, direct ls, ee, mv, etc. do not find the file), and the content i put in the .git/index.lock file via ee is now in .git/index. H$X!111 i still have some git rebase operations (which are notably disk-active) fail from time to time with "impossible" reasons (for example: something like "cherry picking failed", or something like "cannot move git-rebase-new to git-rebase-todo: file does not exist"). i'd note that the hard drive is kind of old (>7 years), and i recently had the power cut during port build operations twice, although the (UFS) filesystem is fsck-clean. has anyone experienced anything like this? what is the possibility of a filesystem/kernel bug or fsck bug? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ghost files
On Mon, Aug 8, 2011 at 12:57 AM, Doug Barton wrote: > On 08/06/2011 23:08, deeptec...@gmail.com wrote: >> i'd note that the hard drive is kind of old (>7 years), and i recently >> had the power cut during port build operations twice, although the >> (UFS) filesystem is fsck-clean. > > Have you actually booted single user and run 'fsck -y'? That should > probably be your next step. yes i have already done that. but just for show i double-checked again (single user mode, fsck -y), and the filesystem was reported to be clean. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
kernel build failure without BPF
in the following kernel configuration (notably without ``device bfp''), i get the following kernel build error. which is either a bug, or not; just posting in case it's in someone's interest. build log snippet begins ===> pfsync (all) cc -O2 -fno-strict-aliasing -pipe -march=pentium4 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/pfsync/../../contrib/pf -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/HQ/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/usr/obj/usr/src/sys/HQ -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c /usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c: In function 'pfsync_sendout': /usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c:2163: error: 'm' undeclared (first use in this function) /usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c:2163: error: (Each undeclared identifier is reported only once /usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c:2163: error: for each function it appears in.) *** Error code 1 Stop in /usr/src/sys/modules/pfsync. *** Error code 1 build log snippet ends kernel configuration file begins cpu I686_CPU ident HQ #optionsSCHED_ULE # ULE scheduler options SCHED_4BSD options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking #optionsINET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCL # New Network Filesystem Client options NFSD# New Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=1000 # Delay (in ms) before probing SCSI options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. options KBD_INSTALL_CDEV# install a CDEV entry in /dev options MAC # TrustedBSD MAC Framework # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic# I/O APIC # CPU frequency control device cpufreq # Bus support. device acpi device pci # ATA controllers device ata # Legacy ATA/SATA controllers options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering # ATA/SCSI peripherals device scbus # SCSI bus (required for ATA/SCSI) device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct ATA/SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse #device kbdmux # keyboard multiplexer device vga
