Re: zpool list -p 's FREE vs. zfs list -p's AVAIL ? FREE-AVAIL == 6_675_374_080 (199G zroot pool)
Mark Millard via freebsd-current wrote: > Context: > > # gpart show -pl da0 > => 40 468862048da0 GPT (224G) > 40 532480 da0p1 efiboot0 (260M) > 532520 2008 - free - (1.0M) > 534528 25165824 da0p2 swp12a (12G) >25700352 25165824 da0p4 swp12b (12G) >50866176 417994752 da0p3 zfs0 (199G) > 468860928 1160 - free - (580K) > > There is just one pool: zroot and it is on zfs0 above. > > # zpool list -p > NAME SIZEALLOC FREE CKPOINT EXPANDSZ FRAG > CAP DEDUPHEALTH ALTROOT > zroot 213674622976 71075655680 142598967296- - 28 > 33 1.00ONLINE - > > So FREE: 142_598_967_296 > (using _ to make it more readable) > > # zfs list -p zroot > NAME USED AVAIL REFER MOUNTPOINT > zroot 71073697792 135923593216 98304 /zroot > > So AVAIL: 135_923_593_216 > > FREE-AVAIL == 6_675_374_080 > > > > The questions: > > Is this sort of unavailable pool-free-space normal? > Is this some sort of expected overhead that just is > not explicitly reported? Possibly a "FRAG" > consequence? >From zpoolprops(8): freeThe amount of free space available in the pool. By contrast, the zfs(8) available property describes how much new data can be written to ZFS filesystems/volumes. The zpool free property is not generally useful for this purpose, and can be substantially more than the zfs available space. This discrepancy is due to several factors, including raidz parity; zfs reservation, quota, refreservation, and refquota properties; and space set aside by spa_slop_shift (see zfs-module-parameters(5) for more information). ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.2-STABLE: Something has broken the bash prompt
Christian Weisgerber wrote: I updated my 12.2-STABLE system from circa December 10 to the last stable/12 SVN commit and now my bash prompt is broken. I use a prompt with properly delineated non-printing characters: PS1="\[$(tput so)\]\u@\h\[$(tput se)\][\w] " Suddenly bash is very confused about the size of the prompt. To reproduce the problem, set PS1 as above, type a few characters, hit ^A to go to the beginning of the line, type some more, see the mess. A prompt without non-printing characters is perfectly fine. The problem is evident with LC_CTYPE=C.UTF-8, but LC_CTYPE=C is fine. Yes, there have been recent updates to the bash port. But I checked several versions, and 5.0.18, 5.1, and 5.1.4 are equally affected. And I was already running 5.1 before the problem appeared after I updated base. So I have reason to suspect that the breakage originates in base. I've looked over the stable/12 commits starting December 10 and I am very suspicious of yuripv's locale changes, in particular "update wcwidth data from utf8proc" looks like a potential culprit. Any insights? Correct, my mistake -- I failed to see the (not so) subtle difference between values returned by wcwidth() and utf8proc_charwidth() for non-printable characters. Will fix once the repos are back; for the moment you can drop the following file to tools/tools/locale/etc/final-maps/ and rebuild/reinstall ctype data in share/ctypedef/ (don't forget `make clean` there first, known issue): https://people.freebsd.org/~yuripv/widths.txt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11-STABLE and 12-STABLE build failures
Don Lewis wrote: On 25 Jul, Don Lewis wrote: On 25 Jul, Don Lewis wrote: On 25 Jul, Warner Losh wrote: Liby.a was retired. Maybe there is some dangling references? # grep yydebug * localedef.c:yydebug = 0; localedef.h:extern int yydebug; I see the same in the 13-CURRENT source and it builds successfully. If I diff the two source trees, I see that the 13-CURRENT references are guarded by #if YYDEBUG. Looks like we need this MFC: %svn log -c 362569 r362569 | jkim | 2020-06-23 19:08:08 -0700 (Tue, 23 Jun 2020) | 2 lines Fix build with recent byacc. Just checked that I see this too trying to build stable/12 on recent head, failing while bootstrapping tools where we use the host system binaries. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ls colour (COLORTERM / CLICOLOR)
James Wright wrote: Updated to 12.1-STABLE r363215 a few days ago (previous build was circa 1st June) but seem to have lost "ls" colour output with "COLORTERM=yes" set in my env. Setting "CLICOLOR=yes" seems to enable it again, however the man page states that setting either should work? It's https://svnweb.freebsd.org/base?view=revision=361818. I'm a bit lost myself what was the intended end result, so CCing Kyle in case he can describe it better. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: URGENT: Microsoft overwrites boot loader!
Don Wilde wrote: On 7/16/20 11:53 PM, Polytropon wrote: On Thu, 16 Jul 2020 13:19:51 -0700, Don Wilde wrote: The [deleted] ones in Redmond have done it again. My multi-OS GRUB2 boot loader is gone, and in its place is a 500M partition called 'Windows boot loader'. They do this all the time. The consensus here is to install "Windows" first, always, restricted to the designated disk space, and _then_ install Linux, FreeBSD, GRUB, or anything else non-"Windows", in order to avoid the exact problem you are describing. Even older versions of "Windows" were known to destroy things like the FreeBSD boot manager when they are installed as a 2nd choice. MICROS~1 always wants you to treat it first class, with golden feet and glockenspiel. However, is my interpretation correct? Did this happen when you _installed_ "Windows" on that machine for the first time, or did it happen after you _booted_ an already installed instance of "Windows", which then did attack "foreign data" on the disk? This machine still maintains the original Windows installation, first with W7, and then (finally, bad mistake) upgraded to W10. The purpose is to force us to look at MS' new version of Edge. All my old boot files are gone. Something like that should never happen. It's absolutely normal that "Windows" installs software without user consent, and then presents it prominently in user-configured areas such as the desktop, the "Start" menu, or the bottom bar (pun absolutely intended), but it should never exceed its authority beyong the border of the "Windows" partition, which clearly means: "Hands off of Grub partition!" Yes. The bastards also screwed up my 128GB backup drive -- again without asking -- when I left it plugged in during a Doze boot. Y'all must have the special edition of Win10 handed as a punishment to those who likes to hijack questions@ (and now stable@) with "the grass was greener" threads :-) I have never seen it do anything with removable media I have attached, be it FreeBSD, illumos installation usb sticks or hard drives, or simply some data disks. Especially with "Windows 10", the PC is no longer a PC, not a _personal_ computer belonging to the user; it's rather a system remotely controlled by MICROS~1, and having installed "Windows" and therefore agreed to the terms of usage (EULA), there is probably nothing "wrong" with it, because you have agreed that they can do whatever they want, and if something goes wrong, it's your fault. Legal business as usual. Yes, agreed. They far outstrip the robber barons of the 1800s in their greed. Even Carnegie finally discovered a heart beating inside of himself, and gave us libraries and Napoleon Hill! Many years (or let's say, decades) I had a similar problem with an OS/2 installation: It messed up the system's partition table, a system where DOS (not that DOS, the other one) was installed, and there was a data loss: Partition D: became C:, E: became D:, F: became E:, and C: along with its content seemed to be gone. But in the overall "disk space calculation" it must still have been on disk, so I used the Norton Disk Editor (DISKEDIT.EXE from Norton Utilities, a great product at that time!), a handheld calculator and pen & paper to re-calculate the correct values for the partition table, entered them, rebooted, prayed unto the holy bringer of peace, Alpha-Omega, and tadaa, C: was there again, with the correct content. I never had that wonderful luxury of being saddled with a "real" IBM machine or OS/2. One would note that they, too (along with MS, eventually), are being relegated to the dustbin of history where they belong. [snip] That's the last time I will allow this, and I'm calling those [deleted]s tomorrow to give them a piece of my mind. After that I will erase every vestige of that obscene OS from my disk. They don't mind. They already have your money. And maybe they even have your name, address, phone number, credit card number or other banking information... I have a few last resort technologies they *don't* know about, though they are not worth any more of my time or psychic energy. :D ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD Quarterly Status Report - Second Quarter 2020
Marek 'Buki' Kozlovský wrote: On Thu, Jul 16, 2020 at 01:29:09AM +0300, Yuri Pankov wrote: Daniel Ebdrup Jensen wrote: [nothing] At least in Thunderbird the text is not inline, and rather shows as attachment. Actually, it shows inline in 68.10.0_CS(32-bit) and text attachment in 68.10.0_EN(64-bit). So take your pick whether it's the arch or locale difference There were 2 versions sent, which one are you talking about? attachment: Message-ID: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> inline: Message-ID: <20200715225934.jfasvsa3g36ssxwx@nerd-thinkpad.local> ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD Quarterly Status Report - Second Quarter 2020
Daniel Ebdrup Jensen wrote: [nothing] At least in Thunderbird the text is not inline, and rather shows as attachment. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Buildworld and buildkernel with very slow compilation, recently
Michael Grimm wrote: Hi, I am following FreeBSD 12.1-STABLE. Clang has been upgraded to version 10.0.0 on May, 1st, and ever since that time, I do observe a dramatic increase in compilation times of building world, kernel and ports. I didn't benchmark the exact times, but compilation times are at least increased by a factor of 1.5. Nothing has changed of the last month besides upgrading 12.1-Stable every other week. Not seeing this after clang update to 10 on both stable/12 and head. I'd check if you are excessively swapping now as (not sure about that, just guessing) newer clang/llvm could consume more memory during compilation, and possibly reducing the make jobs number. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: jedec_dimm fails to boot
On 04.03.2020 19:09, Peter wrote: I met an Issue: When I kldload jedec_dimm durig runtime, it works just as expected, and the DIMM data appears in sysctl. But when I do * load the jedec_dimm at the loader prompt, or * add it to loader.conf, or * compile it into a custom kernel, it does not boot anymore. My custom kernel does just hang somewhere while switching the screen, i.e. no output. The GENERIC does immediate-reboot during the device probe phase. So both are not suitable for gathering additional info in an easy way. (And since my DIMM appear to have neither thermal nor serial, there is not much to gain for me here, so I will not pursue this further, at least not before switching to R.12.) But I fear there are some general problems with sorting out of the modules during system bringup - see also my other message titled "panic: too many modules". Some data for those interested: FreeBSD 11.3-RELEASE-p6 CPU: Intel(R) Core(TM) i5-3570T CPU (IvyBridge) Board: https://www.asus.com/Motherboards/P8B75V/specifications/ Config: hint.jedec_dimm.0.at="smbus12" hint.jedec_dimm.0.addr="0xa0" hint.jedec_dimm.1.at="smbus12" hint.jedec_dimm.1.addr="0xa2" hint.jedec_dimm.2.at="smbus12" hint.jedec_dimm.2.addr="0xa4" hint.jedec_dimm.3.at="smbus12" hint.jedec_dimm.3.addr="0xa6" ichsmb0: port 0xf040-0xf05f mem 0xf7d1500 0-0xf7d150ff irq 18 at device 31.3 on pci0 smbus12: on ichsmb0 smb12: on smbus12 With GENERIC it becomes smbus0 (because drm2 is not loaded) and I need to load "smbus" and "ichsmb" frontup. Could you try backporting r351604 and see if it helps? ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: issue upgradning src
Maciej Jan Broniarz wrote: > > > - Oryginalna wiadomość - > Od: "Yuri Pankov" > Do: "Maciej Jan Broniarz" > DW: "freebsd-stable" > Wysłane: środa, 5 grudzień 2018 17:34:15 > Temat: Re: issue upgradning src > > Maciej Jan Broniarz wrote: >> >> >> - Oryginalna wiadomość - >> Od: "Patrick M. Hausen" >> Do: "Maciej Jan Broniarz" >> DW: "freebsd-stable" >> Wysłane: środa, 5 grudzień 2018 16:56:53 >> Temat: Re: issue upgradning src >> >> Hello, >> >>> Am 05.12.2018 um 16:45 schrieb Maciej Jan Broniarz : >>> I want to upgrade my 12.0-ALPHA8 to the latest release, yet I am unable to >>> update from source: >>> [...] >>> #freebsd-update fetch >> >>> freebsd-update upgrade -r 12.0-RC3 >> >> I have tried that, but it didn't solve the problem: >> >> #/usr/src # freebsd-update upgrade -r 12.0-RC3 >> Looking up update.FreeBSD.org mirrors... 2 mirrors found. >> Fetching public key from update4.freebsd.org... failed. >> Fetching public key from update1.freebsd.org... failed. >> No mirrors remaining, giving up. > >> I don't think you can use freebsd-update to upgrade from ALPHA. > >> For the `svn update`, sources installed from ISO are NOT svn checkout, >> so you need to do that first removing what you currently have in >> /usr/src -- >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html, >> specifically see a note in 23.5.3 with a "Obtaining the Source" header. > > I have downloaded the sources with svn: > > svn checkout https://svn.freebsd.org/base/releng/12.0 > > Still: > # svn info /usr/src > svn: E155007: '/usr/src' is not a working copy If that's the *exact* command you used, you now have a checkout in "12.0" subdirectory of your $CWD. What you need is something like the following: # rm -rf /usr/src/* # svn checkout https://svn.freebsd.org/base/releng/12.0 /usr/src signature.asc Description: OpenPGP digital signature
Re: issue upgradning src
Maciej Jan Broniarz wrote: > > > - Oryginalna wiadomość - > Od: "Patrick M. Hausen" > Do: "Maciej Jan Broniarz" > DW: "freebsd-stable" > Wysłane: środa, 5 grudzień 2018 16:56:53 > Temat: Re: issue upgradning src > > Hello, > >> Am 05.12.2018 um 16:45 schrieb Maciej Jan Broniarz : >> I want to upgrade my 12.0-ALPHA8 to the latest release, yet I am unable to >> update from source: >> [...] >> #freebsd-update fetch > >> freebsd-update upgrade -r 12.0-RC3 > > I have tried that, but it didn't solve the problem: > > #/usr/src # freebsd-update upgrade -r 12.0-RC3 > Looking up update.FreeBSD.org mirrors... 2 mirrors found. > Fetching public key from update4.freebsd.org... failed. > Fetching public key from update1.freebsd.org... failed. > No mirrors remaining, giving up. I don't think you can use freebsd-update to upgrade from ALPHA. For the `svn update`, sources installed from ISO are NOT svn checkout, so you need to do that first removing what you currently have in /usr/src -- https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html, specifically see a note in 23.5.3 with a "Obtaining the Source" header. signature.asc Description: OpenPGP digital signature
Re: FreeBSD 12.0-RC3 Now Available
Yagertiny Алексей wrote: > Hello everyone! > > We have a problem since version 10.3 (bug 209468 [1]). There is no > availability to boot system if some of adaptec raid controllers are used. > Could you be so kind as to pay attention to it? > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209468 I have built a -CURRENT disc1.iso with the patch provided in PR. It seems to work without issues with older ASR 6805 having 8 disks in RAID10 (below). It would be nice if you could try installing this and report if it works for you on newer adapters that you have; if everything looks OK, I'll put it out for review, and hopefully commit. https://people.freebsd.org/~yuripv/FreeBSD-13.0-CURRENT-amd64-20181202-r341364-disc1-aacraid.iso NOTE: as this is a -current snapshot, please use it for testing only. aacraid0: mem 0xdbf0-0xdbff,0xdbebf800-0xdbeb,0xdbebf400-0xdbebf4ff irq 76 at device 0.0 on pci5 aacraid0: Enable Raw I/O aacraid0: Enable 64-bit array aacraid0: using MSI interrupts aacraid0: New comm. interface type1 enabled aacraid0: Adaptec 6805, aacraid driver 3.2.10-1 aacraidp0 on aacraid0 aacraidp1 on aacraid0 aacraidp2 on aacraid0 aacraidp3 on aacraid0 da0 at aacraidp0 bus 0 scbus7 target 0 lun 0 da0: Fixed Direct Access SPC-2 SCSI device da0: Serial Number A12B55B400 da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 1716224MB (3514826752 512 byte sectors) ses0 at aacraidp3 bus 0 scbus10 target 0 lun 0 ses0: Fixed Enclosure Services SPC-3 SCSI device signature.asc Description: OpenPGP digital signature
Re: SCSI and dmesg
Yuri Pankov wrote: > Warner Losh wrote: >> Greetings >> >> a few weeks ago I pointed people to the nycbug dmesg service. I said I was >> looking at data to drive SCSI retirement. I've gatherd some preliminary >> data, which I've uploaded to >> https://github.com/bsdimp/device-data/blob/master/cam.md along with some >> preliminary notions of disposition for the hardware. I'm still working out >> the kinks in the dmesg parsing, but this is interesting data. >> >> If you've not recently submitted, please consider doing so. We'll be >> finalizing the scsi SIMs that I'm going to propose retiring in 13 here in a >> few weeks, and I'm going to base much of what list I come up with based on >> what is submitted. The glitches with FreeBSD dmesgs have been cleared up as >> well. >> >> http://dmesgd.nycbug.org/index.cgi >> >> or >> >> curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d >> "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) $(kenv >> smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@ >> /var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi > > Got another system to submit, but continuously getting "500 Internal > Server Error" using the curl one-liner. dmesg.boot attached in case > it's the source of the problem. It works now, sorry for the noise. signature.asc Description: OpenPGP digital signature
Re: SCSI and dmesg
Warner Losh wrote: > Greetings > > a few weeks ago I pointed people to the nycbug dmesg service. I said I was > looking at data to drive SCSI retirement. I've gatherd some preliminary > data, which I've uploaded to > https://github.com/bsdimp/device-data/blob/master/cam.md along with some > preliminary notions of disposition for the hardware. I'm still working out > the kinks in the dmesg parsing, but this is interesting data. > > If you've not recently submitted, please consider doing so. We'll be > finalizing the scsi SIMs that I'm going to propose retiring in 13 here in a > few weeks, and I'm going to base much of what list I come up with based on > what is submitted. The glitches with FreeBSD dmesgs have been cleared up as > well. > > http://dmesgd.nycbug.org/index.cgi > > or > > curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d > "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) $(kenv > smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@ > /var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi Got another system to submit, but continuously getting "500 Internal Server Error" using the curl one-liner. dmesg.boot attached in case it's the source of the problem. ---<>--- Copyright (c) 1992-2018 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 13.0-CURRENT r340744 GENERIC-NODEBUG amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) VT(efifb): resolution 3440x1440 CPU: Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz (3504.14-MHz K8-class CPU) Origin="GenuineIntel" Id=0x806e9 Family=0x6 Model=0x8e Stepping=9 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c67af Structured Extended Features3=0x9c00 XSAVE Features=0xf VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16472522752 (15709 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads random: unblocking device. ioapic0 irqs 0-119 on motherboard Launching APs: 1 3 2 Timecounter "TSC-low" frequency 1752072050 Hz quality 1000 random: entropy device external interface [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0x8113f150, 0) error 19 kbd0 at kbdmux0 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" netmap: loaded module nexus0 efirtc0: on motherboard efirtc0: registered as a time-of-day clock, resolution 1.00s cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 2400 Hz quality 950 Event timer "HPET" frequency 2400 Hz quality 550 Event timer "HPET1" frequency 2400 Hz quality 440 Event timer "HPET2" frequency 2400 Hz quality 440 Event timer "HPET3" frequency 2400 Hz quality 440 Event timer "HPET4" frequency 2400 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf03f mem 0x2ffe00-0x2ffeff,0x2f-0x2f7fff at device 2.0 on pci0 vgapci0: Boot video device xhci0: mem 0x2fff01-0x2fff01 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 pci0: at device 22.0 (no driver attached) ahci0: port 0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xde424000-0xde425fff,0xde427000-0xde4270ff,0xde426000-0xde4267ff at device 23.0 on pci0 ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 pcib1: at device 28.0 on pci0 pcib1: [GIANT-LOCKED] pcib2: at device 28.5 on pci0 pci1: on pcib2 pci1: at device 0.0 (no driver attached) pcib3: at device 28.7 on pci0 pci2: on pcib3 pci2: at device 0.0 (no driver attached) pcib4: at device 29.0 on pci0 pci3: on pcib4 nvme0: mem 0xde10-0xde103fff at device 0.0 on pci3 isab0: at device 31.0 on pci0 isa0: on isab0 pci0: at device 31.2 (no driver attached) hdac0: mem 0x2fff02-0x2fff023fff,0x2fff00-0x2fff00 at device 31.3 on pci0 em0: mem 0xde40-0xde41 at device 31.6 on pci0
Re: 12-STABLE uname -a misses timestamp of the build
Jakub Lach wrote: > Is there a way to restore it? I liked the old behaviour better, it was useful > info for me. See 20180913 in UPDATING and WITHOUT_REPRODUCIBLE_BUILD in src.conf(5). signature.asc Description: OpenPGP digital signature
Re: kerberized NFS
On Fri, Jan 27, 2012 at 06:58:47PM +0100, Giulio Ferro wrote: I'm trying to setup a kerberized NFS system made of a server and a client (both freebsd 9 amd64 stable) I've tried to follow this howto: http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup But couldn't get much out of it. First question : is this howto still valid or something more recent should be followed? I've searched with Google but I've come up empty. I've set up kerberos heimdal, created the dns entries for both client and server, set up krb5.keytab and copied it to client, set up nfs4 according to man nfsv4: (server) cat /etc/exports V4: /usr/src -sec=krb5:krb5i:krb5p and then tried to mount it from the client: mount_nfs -o ntfsv4,sec=krb5i,gssname=nfs nfsinternal1.dcssrl.it:/usr/src /usr/src but it failed with : [tcp] nfsinternal1.dcssrl.it:/usr/src: Permission denied Can you point me to something that I might have got wrong? Not really related to Kerberos question, but.. Some problems here: - ntfsv4 - probably a typo - more serious one - V4: line specifies the ROOT of NFSv4 exported FS - nfsinternal1.dcssrl.it:/usr/src points to /usr/src/usr/src. What you /etc/exports could look like (the way it works for me, doesn't mean that it's correct though): /usr/src options v3hosts V4: / -sec=krb5:krb5i:krb5p v4hosts Yuri pgppn2KRnhQoB.pgp Description: PGP signature
Re: a bunch of dumb questions about freebsd installing
On Wed, May 11, 2011 at 03:14:28PM +0600, Eugene M. Zheganin wrote: Hi. I have an IBM xSeries server, its ip-kvm and different FreeBSD images. The goal is to perform a remote installation of FreeBSD using server ip-kvm and USB devices it emulates. I can perform a non-remote installation in a wariety of ways but this post is about a remote one. 1) Since USB gives an cd(4) device, it's possible to boot from installation media, but impossible to use it for installation, because sysinstall wants acd0. Is there any way ? I cannot figure one, except using NFS or FTP install, which is not quite acceptable. Pure fixit sheel seems to be missing everything needed, at least I didn't succeeded at guessing where is mount for cd9660 and ls. Try using Options - Re-scan Devices, helped here with USB CD drive. [...] Yuri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: genassym.c:1: error: CPU you selected does not support x86-64 instruction set
On Fri, Mar 18, 2011 at 08:36:48AM -0700, Randy Bush wrote: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=i686 -std=c99 ^^^ This looks suspicious. Yuri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0 stable if_bwi kmod not exist?
On Tue, Jan 19, 2010 at 01:44:16PM +0800, wsk wrote: folks, There is not exist if_bwi.ko module in /boot/kernel under 8.0 Stable why? Looks like it wasn't hooked up to the build for some reason, no bwi here: http://svn.freebsd.org/viewvc/base/stable/8/sys/modules/Makefile?revision=202410view=markup HTH, Yuri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8-STABLE: support for this SMB controller?
On Tue, Dec 22, 2009 at 06:51:04AM +0100, Oliver Lehmann wrote: Andriy Gapon wrote: BTW, mbmon haven't seen any updates in quite a long while, so it's missing support for many newer chips. Unfortunately, state of hardware/sensors monitoring is relatively poor in FreeBSD. Hm so I guess there is no other way in determining the CPUs temperature? Tried coretemp(4) yet? Why do we have the ichsmb driver then anyway? ;) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.2-STABLE make installworld ERROR
On Tue, Dec 22, 2009 at 01:52:14PM +0800, James Chang wrote: Dears, Today, I use ctm upgrade my FreeBSD source code to src-7 859 When I try to make world, in make buildworld stage it show me World build completed on Tue Dec 22 12:57:30 CST 2009 But when I execute make installworld it show me the following ERROR message: === sys/boot/i386/btx (install) === sys/boot/i386/btx/btx (install) === sys/boot/i386/btx/btxldr (install) === sys/boot/i386/btx/lib (install) === sys/boot/i386/boot2 (install) cc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -S -o boot2.s.tmp /usr/src/sys/boot/i386/boot2/boot2.c sed -e '/align/d' -e '/nop/d' boot2.s.tmp boot2.s rm -f boot2.s.tmp as --32 -o boot2.o boot2.s ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin btxld:No such file or directory *** Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. *** Error code 1 Stop in /usr/src/sys. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. = PS. My uname -a before make installworld FreeBSD db1.books.com.tw 7.2-STABLE FreeBSD 7.2-STABLE #1: Thu Dec 3 23:08:26 CST 2009 r...@db1.books.com.tw:/usr/obj/usr/src/sys/GENERIC amd64 Best Regards! Looks like http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028377.html Yuri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Something since June 8th clobbers my disk...
On Fri, Jun 12, 2009 at 08:24:42PM -0700, Gary Kline wrote: On Fri, Jun 12, 2009 at 08:45:01PM -0600, Dan Allen wrote: On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: Isn't boot part of the kernel build? Why would installing the kernel not cause this problem? No, sys/boot is built during world. Likely some change in /boot/ loader is causing your problem. Can you narrow it down to a specific change under sys/boot? Ok. I updated just the one file since it appeared like one of the few changed files /usr/src/sys/boot/i386/libi386/biosdisk.c and rebuilt things with cd /usr/src/sys/boot; make cleandir obj depend all install and it was okay. No problems. Then I did sync'd all of the changed files for /usr/src/sys/boot and my machine is hung again at boot, so we have narrowed it down to somewhere in /usr/src/sys/boot/. Time to reinstall from a DVD and try it with finer granularity. This will take some time. There appears to be only four files that have changed in /usr/src/sys/ boot from June 8th (all working fine) to June 11th (dead in the water). They are: /usr/src/sys/boot/Makefile /usr/src/sys/boot/i386/Makefile /usr/src/sys/boot/i386/libi386/biosdisk.c /usr/src/sys/boot/i386/loader/Makefile I have ruled out bisodisk.c, as stated above. That means that the Makefiles are building new stuff that previously was not built, namely zfsboot gptzfsboot I believe it has to do with that. More help is needed! I am tired of reinstalling the OS, but I am much more paranoid about updating my other machine in any way now, as it could erase that whole machine. I can't believe I am the only one seeing this... Dan Whew!! i'm giving thanks to every saint, god and daemon known. i rebuilt my kernel in very recent days (7.2) on my ancient 500MHz kayak, but did not go further. So still runing on the 7.0 kernel. Will someone send up a flare when it's *safe*? gary -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org For FBSD list: http://transfinite.thought.org/slicejourney.php The 4.98a release of Jottings: http://jottings.thought.org/index.php How do you know it isn't safe? Noone hasn't provided any useful info (debug, revisions where it works and where it doesn't). Yuri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pending MFC of drm updates
On Tue, Jan 06, 2009 at 11:09:58PM -0500, Robert Noland wrote: On Wed, 2009-01-07 at 02:17 +0100, Torfinn Ingolfsen wrote: On Wed, 07 Jan 2009 01:24:57 +0100 Torfinn Ingolfsen torfinn.ingolf...@broadpark.no wrote: I forgot to tell that I fixed the Makefile in sys/modules/drm/i915 manually. Apparently patch gets confuseed when it finds a file with the same name in the current directory (which was /usr/src), or perhaps I don't know how to tell patch how to find the right file. I just did: cd /usr/src patch /dir/name/patchfile Anyway, a 'make kernel' fails: Which is no wonder, because patch misplaced more files: r...@kg-v2# pwd /usr/src r...@kg-v2# ll *.c *c.orig *.h *h.orig -rw-r--r-- 1 root wheel 1650 Jan 7 01:09 drm_internal.h -rw-r--r-- 1 root wheel 0 Jan 7 01:09 drm_internal.h.orig -rw-r--r-- 1 root wheel 16455 Jan 7 01:09 i915_suspend.c -rw-r--r-- 1 root wheel 0 Jan 7 01:09 i915_suspend.c.orig -rw-r--r-- 1 root wheel 59118 Jan 7 01:09 radeon_microcode.h -rw-r--r-- 1 root wheel 0 Jan 7 01:09 radeon_microcode.h.orig Is ther a secret handshake to make patch put the files in their correct place? (Except for reading through the whole patchfile to determine if all touched filews are in the same directory.) For now I just mv'ed the files into place. Anyway, now the new kernel builds, installs and works correctly. It didn't pick up any drm, but I'm not sure that it should either. This machine[1] has a GeForce 8200 chipset. More info about FreeBSD on this machine here[2], including dmesgs before and after, etc. Nope, sorry no Nvidia support yet. nouveau is on my list to work on, but it's a long list... robert. Any help that we mere mortals can provide other than sending you hardware? HTH References: 1) http://tingox.googlepages.com/asus_v2-m3n8200 2) http://tingox.googlepages.com/asus_v2-m3n8200_freebsd Yuri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Another attempt [Re: Groff is not working in the latest code]
Alex Goncharov wrote:
`groff' is still not working for me, and with it `man' doesn't:
$ uname -srv
FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #34: Tue Aug 26 18:14:46 EDT
2008...
$ man man
/usr/bin/groff: can't find `DESC' file
/usr/bin/groff:fatal error: invalid device `ascii'
[snip]
So, I looked at how things are being built and think that the
following is supposed to happen with respect to `groff' -- a GNU
program:
1. The build is driven by `gnu/usr.bin/groff/Makefile' (all paths in
the following are relative to `/usr/src'.
2. During the build, the original contrib code is used, to be found
in `contrib/groff'.
That code is configured by the pristine `contrib/groff/configure'
and results in setting the prefix to the GNU-usual `/usr/local'
and generating the FreeBSD-unaware `defs.h' and `config.h'.
contrib/groff/configure shouldn't be called at all, looks like there's
something wrong with your local build environment. Check timestamps on
src/contrib/groff and src/gnu/usr.bin/groff contents (try removing them
and checkout again). Posting relevant entries from /etc/{make,src}.conf
and your `env` output could be helpful too.
3. Then some magic is supposed to happen / was happening two weeks
ago for me, when the newly generated `defs.h' and `config.h' are
replaced with the FreeBSD hard versions that had been delivered
from CVS -- and the paths get corrected to eliminate the `local'
component from them and do other path adjustments to bring it all
to the FreeBSD standards:
$ diff contrib/groff/src/include/defs.h gnu/usr.bin/groff/src/include/defs.h
| head -n 12
yuri:/usr/src diff -u contrib/groff/src/include/defs.h
gnu/usr.bin/groff/src/include/defs.h
diff: contrib/groff/src/include/defs.h: No such file or directory
[snip]
4. Then the build happens with whatever `defs.h' and `config.h' will
be found at that time under `contrib/groff/src/include'.
If the step 3 worked before but is not working now, it explains my
current end results.
But how about others: everything works for you? What could have
triggered the change in the process for me a week or so ago?
`man man` works for me on 7.0-RELEASE with groff built from RELENG_7 src.
Anybody is able and willing to lead me out of my lasting misery?
Thanks,
-- Alex -- [EMAIL PROTECTED] --
HTH,
Yuri
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: broken MBR
Jeremy Chadwick wrote: On Wed, Mar 12, 2008 at 01:36:02PM +0100, Marko Lerota wrote: Insted of F1 I get F-| on boot menu and system won't boot. How do I remove FreeBSD boot manager from MBR? I didn't find any docs in man fdisk or boot0cfg. You want boot0cfg -b /boot/mbr disk, where disk is something like ad4, da0, etc.. boot0cfg can't install `mbr', you need to use fdisk for that as shown in boot0cfg(8) manpage, EXAMPLES section. Yuri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make KNOBS
On 02/26/2008 10:35, Chris H. wrote: Hello, and thank you for your reply. Quoting Ruslan Ermilov [EMAIL PROTECTED]: On Mon, Feb 25, 2008 at 09:55:22PM -0800, Chris H. wrote: Hello All, Maintaining a make.conf file can be a fairly daunting task within itself. But when upgrading, it becomes even more laborious. Peeking into the port Makefile to discover any /new/, or /changed/ knobs is standard fare. But it's not always obvious exactly /what/ the WITH_this, or WITHOUT_that actually provides. To the point: Is there, or does anyone maintain a KNOBS list possibly categorized by application/port/version, etc...? If not, are there any resources that might help me facilitate one online for myself and others to refer to? Thank you for all your time and consideration. For src/, there is an src.conf(5) manpage that documents supported WITH_*/WITHOUT_* knobs. For ports/, I'm not aware of such a list. Indeed. I was aware of, and make much use of it. But am struggling with finding the port(s) equivalent. If there isn't one, I'd be more that happy to dedicate a domain/ web site solely to providing this resource. Perhaps a wiki that I, and anyone else can add the WITH_/WITHOUT_ options, along with descriptions of exactly /what/ they provide. Seems like a /real/ valuable, and /needed/ resource. Thanks again for your response. --Chris H There's /usr/ports/KNOBS file, which lists some of most used KNOBS, but, sadly enough, every other port maintainer tries to invent his own knob names :-) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer Yuri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone else seeing this on a make release of 7?
On 12/5/2007 12:55 PM, Lawrence Farr wrote: cc -Os -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -W return-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundan t-decls -Wno-pointer-sign -c /usr/src/bin/ed/main.c *** Error code 1 Stop in /usr/src/bin/ed. *** Error code 1 Stop in /usr/obj/usr/src/release/fixit_crunch. *** Error code 1 Stop in /usr/src/release. *** Error code 1 Stop in /usr/src/release. in.c:106: warning: argument 'argv' might be clobbered by 'longjmp' or 'vfork' + umount /dev Been getting it for a week or so now, it's being built on: 7.0-BETA3 FreeBSD 7.0-BETA3 #0: Mon Nov 26 01:04:55 GMT 2007 Are you sure that you are building from RELENG_7 source? It doesn't have -Werror defined, IIRC. And HEAD should be fixed by this commit: http://lists.freebsd.org/pipermail/cvs-src/2007-December/084624.html HTH, Yuri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[SiS180] SATA drives are not detected on = 6.0
Hi, SATA drives on SiS 180 SATA150 (ASUS P4S800D mobo) controller are not detected on any release 6.0, though they work on 5.5. I've attached dmesg from 5.5 and 7.0-BETA2 in case it may be helpful. It's kinda production system, so I couldn't play much with it. Any suggestions, hints on how to make system recognize drives are very appreciated. TIA, Yuri Copyright (c) 1992-2006 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.5-SECURITY #0: Thu Apr 26 11:43:48 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc0a46000. Preloaded elf module /boot/kernel/acpi.ko at 0xc0a4621c. Calibrating clock(s) ... i8254 clock: 1193254 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2400690582 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2400.69-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 real memory = 536018944 (511 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c25000 - 0x1f602fff, 513662976 bytes (125406 pages) avail memory = 514846720 (490 MB) Table 'FACP' at 0x1ff30290 Table 'APIC' at 0x1ff30390 MADT: Found table at 0x1ff30390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled MADT: Found CPU APIC ID 129 ACPI ID 2: disabled ACPI APIC Table: A M I OEMAPIC bios32: Found BIOS32 Service Directory header at 0xc00f bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0x31 pnpbios: Found PnP BIOS data at 0xc00f68d0 pnpbios: Entry = f:74ca Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's - intpin 0 ioapic0: intpin 0 - ExtINT (edge, high) ioapic0: intpin 1 - ISA IRQ 1 (edge, high) ioapic0: intpin 2 - ISA IRQ 2 (edge, high) ioapic0: intpin 3 - ISA IRQ 3 (edge, high) ioapic0: intpin 4 - ISA IRQ 4 (edge, high) ioapic0: intpin 5 - ISA IRQ 5 (edge, high) ioapic0: intpin 6 - ISA IRQ 6 (edge, high) ioapic0: intpin 7 - ISA IRQ 7 (edge, high) ioapic0: intpin 8 - ISA IRQ 8 (edge, high) ioapic0: intpin 9 - ISA IRQ 9 (edge, high) ioapic0: intpin 10 - ISA IRQ 10 (edge, high) ioapic0: intpin 11 - ISA IRQ 11 (edge, high) ioapic0: intpin 12 - ISA IRQ 12 (edge, high) ioapic0: intpin 13 - ISA IRQ 13 (edge, high) ioapic0: intpin 14 - ISA IRQ 14 (edge, high) ioapic0: intpin 15 - ISA IRQ 15 (edge, high) ioapic0: intpin 16 - PCI IRQ 16 (level, low) ioapic0: intpin 17 - PCI IRQ 17 (level, low) ioapic0: intpin 18 - PCI IRQ 18 (level, low) ioapic0: intpin 19 - PCI IRQ 19 (level, low) ioapic0: intpin 20 - PCI IRQ 20 (level, low) ioapic0: intpin 21 - PCI IRQ 21 (level, low) ioapic0: intpin 22 - PCI IRQ 22 (level, low) ioapic0: intpin 23 - PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 - intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low ioapic0 Version 1.1 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00050014 LDR: 0x0100 DFR: 0x0fff lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff wlan: 802.11 Link Layer random: entropy source, Software, Yarrow io: I/O mem: memory Pentium Pro MTRR support enabled null: null device, zero device npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: A M I OEMXSDT on motherboard acpi0: [MPSAFE] pci_open(1):mode 1 addr port (0x0cf8) is 0x800010c8 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=06551039) pcibios: BIOS version 2.10 Found $PIR table, 10 entries at 0xc00f67a0 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded02A 0x41 3 4 5 7 10 11 12 14 15 embedded02B 0x42 3 4 5 7 10 11 12 14 15 embedded02C 0x43 3 4 5 7 10 11 12 14 15 embedded02D 0x44 3 4 5 7 10 11 12 14 15 embedded03A 0x60 3 4 5 7 10 11 12 14 15 embedded03B 0x61 3 4 5 7 10 11 12 14 15 embedded03C 0x62 3 4 5 7 10 11 12 14 15 embedded03D 0x63 3 4 5 7 10 11 12 14 15 embedded05A 0x42 3 4 5 7 10 11 12 14 15 embedded01A 0x41 3 4 5 7 10 11 12 14 15 embedded01B 0x42 3 4 5 7 10 11 12 14 15 embedded01C 0x43 3 4 5 7 10 11 12 14 15 embedded01D 0x44 3 4 5 7 10 11
Re: Upgrading from FreeBSD 5.4 to 5.5 STABLE
On Tuesday 13 November 2007 06:08:10 Nic Reveles wrote: Hello, I am trying to update my version of FreeBSD from 5.4 to 5.5-STABLE. This is one of the many things I've yet to get my feet wet with yet, and so I'm not entirely sure what it is I am doing. I've made a backup of my most critical work. Some links I've found describing this process: 1. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html 2. http://www.nabble.com/Upgrading-FreeBSD-Questions-t4716949.html So far I've run cvsup with a line in it: *default tag=RELENG_5_5_0_RELEASE After a long time it said that it finished successfully. Regardless, I'm not sure if the line I used is correct to get 5.5 STABLE. No, correct tag for 5-STABLE is RELENG_5 (or, if by 5.5 STABLE you mean 5.5 with security patches, tag should be RELENG_5_5). See http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html Then I ran: % make buildworld === gnu/usr.bin/cvs/contrib sed -e 's,@CSH@,/bin/csh,' -e '[EMAIL PROTECTED]@,/usr/bin/perl,' /usr/src/gnu/usr.bin/cvs/contrib/../../../../contrib/cvs/contrib/Makefile.. in Makefile Makefile, line 15: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in usr/src/gnu/usr.bin/cvs. *** Error code 1 Stop in usr/src/gnu/usr.bin. *** Error code 1 Stop in usr/src/gnu. *** Error code 1 Stop in usr/src. *** Error code 1 Stop in usr/src. *** Error code 1 Stop in usr/src. *** Error code 1 Stop in usr/src. I've seen this error before, it has something to do with timestamps in src/contrib/cvs (I've copied source tree using cp). Try removing /usr/src/contrib/cvs directory and cvsup again. Unfortunately, I typed all that out by hand and so it is quite possible there is a typo or two, but that is the general jist of it all. Is there someone who knows what is going on with this? All answers/tips are greatly appreciated! Nic R. Yuri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compiling freebsd7 kernel
On Sun, 2007-10-28 at 16:26 -0300, Thiago Pollachini wrote: Hi folks! This is my feedback about the new freebsd7... --- cut here -- freebsd7# cat /usr/src/sys/i386/conf/GrayFox cpu I686_CPU ident GrayFox options SCHED_ULE # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # InterNETworking6 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 UFS_GJOURNAL# Enable gjournal-based UFS journaling options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY# BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 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 KBD_INSTALL_CDEV# install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI# Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing # CPU frequency control device cpufreq # Bus support. device eisa device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device kbdmux # keyboard multiplexer device vga # VGA video card driver # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip# TCP/IP over parallel device ppi # Parallel port interface device device miibus # MII bus support device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device rl # RealTek 8129/8139 device sis # Silicon Integrated Systems SiS 900/SiS 7016 device vr # VIA Rhine, Rhine II device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # Wireless NIC cards device wlan# 802.11 support device wlan_wep# 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device wlan_scan_ap# 802.11 AP mode scanning device wlan_scan_sta # 802.11 STA mode scanning device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath device ral # Ralink Technology RT2500 wireless NICs. device wi #
Re: Kernel Fatal trap 12 on 6.2 release p7 how to report it
On Tue, Oct 02, 2007 at 02:55:08PM -0500, Natham wrote: Hi: Im getting a Fatal trap 12 from a freebsd 6.2 release p7, how can i report it and get help?? Check http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html on how to obtain needed information. -- Yuri Pankov [EMAIL PROTECTED] ___ 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 named default configuration in 6-STABLE
On Mon, Jul 16, 2007 at 11:19:41PM +0200, Michael Nottebrock wrote:
I finally updated my desktop from 5.5-RELEASE to 6-STABLE. This got me a new
named.conf, which I modified to run named as a local resolver, like I had
before:
listen-on { 127.0.0.1; };
listen-on-v6{ ::1; };
forward only;
forwarders {
192.168.8.1;
};
Everything else is default. However, with this default configuration, named
will not resolve any hosts of my local domain (my.domain), which uses
addresses in the 192.168.8 subnet. My dns server on 192.168.8.1, running
6.2-RELEASE, has a very simple dynamic dns setup: a zone my.domain and a
reverse zone 8.168.192.in-addr.arpa which are both dynamically updated by
dhcpd.
To make this work again, I had to delete everything in the default named.conf
from /* Slaving the following zones from the root [...]
to zone ip6.int { type master;
file master/empty.db; };.
I'm a DNS n00b, but I suspect that such drastic measures shouldn't be
required
and somehow my setup is flawed. What can I do to make this work right?
Cheers,
--
,_, | Michael Nottebrock | [EMAIL PROTECTED]
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
Hi Michael,
If I understood you correctly, you can't resolve 8.168.192.in-addr.arpa
anymore, and the line below (from default named.conf) is the cause:
zone 168.192.in-addr.arpa { type master; file master/empty.db; };
Yuri
pgp9SIBcG6iJu.pgp
Description: PGP signature
