Re: [RFC/RFT] calloutng
On Wed, Jan 02, 2013 at 09:52:37PM -0800, Kevin Oberman wrote: On Wed, Jan 2, 2013 at 2:06 PM, Alexander Motin m...@freebsd.org wrote: On 02.01.2013 18:08, Adrian Chadd wrote: .. I'm pretty damned sure we're going to need to enforce a never earlier than X latency. Do you mean here that we should never wake up before specified time (just as specified by the most of existing APIs), or that we should not allow sleep shorter then some value to avoid DoS? At least on x86 nanosleep(0) doesn't allow to block the system. Also there is already present mechanism for specifying minimum timer programming interval in eventtimers(9) KPI. I can see serious performance issues with some hardware (wireless comes to mind) if things happen too quickly. Intuition is that it could also play hob with VMs. I believe that the proper way is to wake between T_X and T_X + D. This assumes that D is max_wake_delay, not deviation, which leaves us at the original of (T_X) = event_time = (T_X + D). i think max delay was the intended meaning of the D parameter. We picked bad names (tolerance, deviation,...) for it. cheers luigi ___ 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: loopback interface broken on current
Hello, There is still ifa_del_loopback_route: deletion failed: 3 that wasn't there before,but the 127.0.0.1 seems to be configured now: Do you have a line like network_interfaces=lo0 bge0 in /etc/rc.conf? If you have it, try to remove it. I think something broken, but people using automatic configuration don't notice the breakage. -- k...@elam.kais.kyoto-u.ac.jp ___ 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: loopback interface broken on current
At 03:30 AM 1/3/2013, KAHO Toshikazu wrote: Hello, There is still ifa_del_loopback_route: deletion failed: 3 that wasn't there before,but the 127.0.0.1 seems to be configured now: Do you have a line like network_interfaces=lo0 bge0 in /etc/rc.conf? If you have it, try to remove it. I think something broken, but people using automatic configuration don't notice the breakage. -- k...@elam.kais.kyoto-u.ac.jp -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. I have : network_interfaces=auto ifconfig_bge0=inet 192.168.0.5 netmask 255.255.255.0 I will try to comment out the above line and see what happens. But I think it might screw up my routing || n...@pozo.com || || Ph. (415) 681-6235 || -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed 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
Re: loopback interface broken on current
At 03:30 AM 1/3/2013, KAHO Toshikazu wrote: Hello, There is still ifa_del_loopback_route: deletion failed: 3 that wasn't there before,but the 127.0.0.1 seems to be configured now: Do you have a line like network_interfaces=lo0 bge0 in /etc/rc.conf? If you have it, try to remove it. I think something broken, but people using automatic configuration don't notice the breakage. -- k...@elam.kais.kyoto-u.ac.jp -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Hi If I comment out : ifconfig_bge0=inet 192.168.0.5 netmask 255.255.255.0 Network doesn't work. || n...@pozo.com || || Ph. (415) 681-6235 || -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed 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
Re: loopback interface broken on current
Hello, If I comment out : ifconfig_bge0=inet 192.168.0.5 netmask 255.255.255.0 Network doesn't work. Yes, you should not commnet out it, you cannot connect from/to outside. network_interfaces=auto is same as /etc/default/rc.conf, so that you can remove it safely from /etc/rc.conf. I cannot identify the problematic line caused the problem. -- vi...@elam.kais.kyoto-u.ac.jp ___ 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
steady stream of ath errors
Experimenting with ath under RELENG8,9 and HEAD at home on my wifi
router, I found that with current from today (r244989) gives a steady
stream of errors. How can I debug the issue in my setup ?
input(Total) output
packets errs idrops bytespackets errs bytes colls
72 7 0 38865 78 0 76117 0
57 4 0989 32 0 2062 0
47 0 0 3369 29 0 5724 0
162511 01394179 2214 02779765 0
314620 02369588 3955 04723911 0
326914 02499654 4130 04984206 0
357019 02549189 4330 05082261 0
339915 02485682 4201 04956613 0
353022 02612967 4375 05207076 0
334016 02371278 4040 04728272 0
328114 02321800 3947 04628010 0
309215 02263990 3826 04514317 0
2905 8 02124069 3572 04235585 0
301718 02229250 3722 0773 0
270111 01709542 3064 03407885 0
224511 01918413 3038 03824605 0
342812 02508519 4251 05001890 0
342814 02473616 4180 04931945 0
322711 02264217 3886 04514416 0
322314 02403237 4016 04792172 0
331317 02402811 4048 04791158 0
ath0@pci0:2:0:0:class=0x028000 card=0x2c371a3b chip=0x002b168c
rev=0x01 hdr=0x00
vendor = 'Atheros Communications Inc.'
device = 'AR9285 Wireless Network Adapter (PCI-Express)'
class = network
bar [10] = type Memory, range 64, base 0xfe9f, size 65536, enabled
cap 01[40] = powerspec 3 supports D0 D1 D3 current D0
cap 05[50] = MSI supports 1 message
cap 10[60] = PCI-Express 2 legacy endpoint max data 128(128) link x1(x1)
speed 2.5(2.5)
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0002[140] = VC 1 max VC0
ecap 0003[160] = Serial 1
ecap 0004[170] = Power Budgeting 1
stats etc attached.
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
0{zotac}# ifconfig ath0
ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290
ether 74:2f:68:af:b9:47
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng hostap
status: running
0{zotac}# ifconfig wlan0
wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
ether 74:2f:68:af:b9:47
inet6 fe80::762f:68ff:feaf:b947%wlan0 prefixlen 64 tentative scopeid
0x5
inet 192.168.241.129 netmask 0xff00 broadcast 192.168.241.255
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng hostap
status: running
ssid policevan2 channel 6 (2437 MHz 11g ht/20) bssid 74:2f:68:af:b9:47
regdomain 96 indoor ecm authmode WPA privacy MIXED deftxkey 2
TKIP 2:128-bit TKIP 3:128-bit txpower 20 scanvalid 60 protmode CTS
ampdulimit 64k ampdudensity 8 shortgi wme burst dtimperiod 1 -dfs
0{zotac}#
0{zotac}# sysctl -a dev.ath
dev.ath.0.%desc: Atheros 9285
dev.ath.0.%driver: ath
dev.ath.0.%location: slot=0 function=0 handle=\_SB_.PCI0.NBP1.NP1S
dev.ath.0.%pnpinfo: vendor=0x168c device=0x002b subvendor=0x1a3b
subdevice=0x2c37 class=0x028000
dev.ath.0.%parent: pci2
dev.ath.0.smoothing_rate: 75
dev.ath.0.sample_rate: 10
dev.ath.0.sample_stats: 0
dev.ath.0.countrycode: 0
dev.ath.0.regdomain: 96
dev.ath.0.slottime: 9
dev.ath.0.acktimeout: 64
dev.ath.0.ctstimeout: 48
dev.ath.0.softled: 0
dev.ath.0.ledpin: 0
dev.ath.0.ledon: 0
dev.ath.0.ledidle: 2700
dev.ath.0.hardled: 0
dev.ath.0.led_net_pin: -1
dev.ath.0.led_pwr_pin: -1
dev.ath.0.txantenna: 0
dev.ath.0.rxantenna: 1
dev.ath.0.txintrperiod: 5
dev.ath.0.diag: 0
dev.ath.0.tpscale: 0
dev.ath.0.tpc: 0
dev.ath.0.tpack: 63
dev.ath.0.tpcts: 63
dev.ath.0.txagg: 0
dev.ath.0.forcebstuck: 0
dev.ath.0.intmit: 1
dev.ath.0.monpass: 24
dev.ath.0.hwq_limit: 2
dev.ath.0.tid_hwq_lo: 2
dev.ath.0.tid_hwq_hi: 4
dev.ath.0.txq_data_minfree: 10
dev.ath.0.txq_mcastq_maxdepth: 512
dev.ath.0.clear_stats: 0
dev.ath.0.stats.ast_watchdog: 0
dev.ath.0.stats.ast_hardware: 0
dev.ath.0.stats.ast_bmiss: 0
dev.ath.0.stats.ast_bmiss_phantom: 0
dev.ath.0.stats.ast_bstuck: 0
dev.ath.0.stats.ast_rxorn: 0
dev.ath.0.stats.ast_rxeol: 0
Re: [RFC/RFT] calloutng
On Wed, 2 Jan 2013, Alexander Motin wrote: On 02.01.2013 19:09, Konstantin Belousov wrote: On Wed, Jan 02, 2013 at 05:22:06PM +0100, Luigi Rizzo wrote: Probably one way to close this discussion would be to provide a sysctl so the sysadmin can decide which point in the interval to pick when there is no suitable callout already scheduled. Isn't trying to synchronize to the external events in this way unsafe ? I remember, but cannot find the reference right now, a scheduler exploit(s) which completely hide malicious thread from the time accounting, by making it voluntary yielding right before statclock should fire. If statistic gathering could be piggy-backed on the external interrupt, and attacker can control the source of the external events, wouldn't this give her a handle ? Fine-grained timeouts complete fully opening this security hole. Synchronization without fine-grained timeouts might allow the same, but is harder to exploit since you can't control the yielding points directly. With fine-grained timeouts, you just have to predict the statclock firing points. Use one timeout to arrange to yield just before statclock fires and another to regain control just after it has fired. If the timeout resolution is say 50 usec, then this can hope to run for all except 100 usec out of every 1/stathz seconds. With stathz = 128, 1/stathz is 7812 usec, so this gives 7712/7812 of the CPU with 0 statclock ticks. Since the scheduler never sees you running, your priority remains minimal, so the scheduler should prefer to run you whenever a timeout expires, with only round-robin with other minimal-priority threads preventing you getting 7712/7812 of the (user non-rtprio) CPU. The previous stage of fully opening this security hole was changing (the default) HZ from 100 to 1000. HZ must not be much smaller than stathz, else the security hole is almost fully open. With HZ = 100 being less than stathz and timeout granularity limiting the fine control to 2/HZ = 20 msec (except you can use a periodic itimer to get a 1/HZ granularity at a minor cost of getting more SIGALRMs), it is impossible to get near 100% of the CPU with 0 statclock ticks. After yielding, you can't get control for another 100 or 200 msec. Since this exceeds 1/stathz = 78.12 usec, you can only hide from statclock ticks by not running very often or for very long. Limited hiding is possible by wasting even more CPU to determine when to hide: since the timeout granularity is large, it is also ineffective for determining when to yield. So when running, you must poll the current time a lot to determine when to yield. Yield just before statclock fires, as above. (Do it 50 usec early, as above, to avoid most races involving polling the time.) This actually has good chances of not limiting the hiding too much, depending on the details of the scheduling. It yields just before a statclock tick. After this tick fires, if the scheduler reschedules for any reason, then the hiding process would most likely be run again, since its priority is minimal. But at least the old 4BSD scheduler doesn't reschedule after _every_ statclock tick. This depends on the bugfeature that the priority is not checked on _every_ return to user mode (sched_clock() does change the priority, but this is not acted on until much later). Without this bugfeature, there would be excessive context switches. OTOH, with timeouts, at least old non-fine-grained ones, you can force a rescheduling that is acted on soon enough simply by using timeouts (since timeouts give a context switch to the softclock thread, the scheduler has no option to skip checking the priority on return to user mode). After the previous stage of changing HZ to 1000, the granuarity is fine enough for using timeouts to hide from the scheduler. Using a periodic itimer to get a granularity of 1000 usec, start hiding 50-1000 usec before each statclock tick and regain control 1000 usec later. With stathz = 128, 6812/7812 of the CPU with 0 statclock ticks. Not much worse (for the hider) than 7712/7812. Statclock was supposed to be aperiodic to avoid hiding (see statclk-usenix93.ps), but this was never implemented in FreeBSD. With fine-grained timeouts, it would have to be very aperiodic, to the point of giving large inaccuracies, to limit the hiding very much. For example, suppose that it has an average period of 7812 usec with +-50% jitter. You would try to hide from it most of the time by running for a bit less than 7812/2 usec before yielding in most cases. If too much scheduling is done on each statclock tick, then you are likely to regain control after each one (as above) and then know that there is almost a full minimal period until the next one. Otherwise, it seems to be necessary to determine when the previous statclock tick occurred, so as to determine the minimum time until the next one. There are many different kinds of accounting with different characteristics. Run time for each thread
Re: installworld failure due to cross-device links
Am 02.01.2013 14:26, schrieb Nathan Whitehorn: On 01/02/13 07:04, Stefan Esser wrote: I'd be interested in the general policy on LINKS vs. SYMLINKS between directories that might end up on different file systems. There seems to be an assumption that system directories in /usr (e.g. /usr/bin, /usr/sbin, /usr/libexec) are on the same file system, but I do not think that this assumption is documented. I'm using a ZFS only installation of -CURRENT and have separate file systems for several of the directories in / and /usr, that usually share a file system (e.g. /bin, /sbin, but also /usr/bin/, /usr/sbin and /usr/libexec are independent file systems). An older case is the link from /usr/bin/chgrp to /usr/sbin/chown (see usr.sbin/chown/Makefile), which is easily fixed by using a SMYLINK instead of a LINK. And now there is usr.sbin/bsdinstall/partedit/Makefile, which as of r244859 creates a link from /usr/libexec/bsdinstall to /usr/sbin/sade. This breaks with /usr/bin and /usr/sbin on different file systems, while it should not according to the commit message: Thanks for the patch! I've committed it (slightly modified) as r244958. I haven't taken any action on the chgrp/chown issue, though. Thanks for the fix. Seems I had a wrong idea of the semantics of the (SYM)LINKS macro, as I had assumed that the build target would be linked to the list of names (instead of pairs of source/dest). I did not expect you to do anything with chown/chgrp, but I still think there should be a policy on whether hard links may be used to connect files in different directories (which might be in different file systems). Regards, STefan ___ 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: [RFC/RFT] calloutng
On 03.01.2013 16:45, Bruce Evans wrote: On Wed, 2 Jan 2013, Alexander Motin wrote: More important for scheduling fairness thread's CPU percentage is also based on hardclock() and hiding from it was trivial before, since all sleep primitives were strictly aligned to hardclock(). Now it is slightly less trivial, since this alignment was removed and user-level APIs provide no easy way to enforce it. %cpu is actually based on statclock(), and not even used for scheduling. May be for SCHED_4BSD, but not for SCHED_ULE. In SCHED_ULE both %cpu and thread priority based on the same ts_ticks counter, that is based on hardclock() as time source. Interactivity calculation uses alike logic and uses the same time source. -- Alexander Motin ___ 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: problem after installkernel going from 9.0 to CURRENT
On Wed, 2 Jan 2013, Robert Huff wrote: (While this may not be a strictly CURRENT issue, I asked on questions@, but have not found a solution.) Situation: One of my boxes failed, and for various reasons it became easier to just scrub and rebuild it. Like its predecessor it will run CURRENT 1) Using BSDinstall, I flushed then created the first disk: ada2p1 freebsd-boot128k ada2p2 freebsd-swap4g ada2p3 freebsd-ufs 25g (There are non-bootable disks at ada0, -1, and -3.) 2) Installed off the 9.0 CD, got it up and running, everything was good. 3) Used csup (tag=.) to update the source tree as of 00:01 on 12/30. 4a) Built world - OK. 4b) Build kernel - OK. 4c) Ran mergemaster - OK. 4d) Installed kernel - OK. 5) On rebooting, the loader(??) claims to not be able to find a bootable partition - i.e. I get a screen that ends in mountroot . Providing the presumptive value by hand returns error 19. 6) Boot using installation CD and use gpart show to double check device names and partitions; everything looks good. 7) Try normal booting again, no go. This is my first time installing to a completely GPT partitioned system, and I have (obviously) failed to grok something. I checked src/UPDATING and found nothing which covered this. What have I bungled, and how do I fix it? It really does not sound like a GPT problem, because 9.0 booted. The -current kernel can't find/detect the device. Scrolling back in the console buffer might find a problem. buildworld/kernel/installworld do not affect the disk partitioning, but can change the code that looks for those partitions. ___ 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: [RFC/RFT] calloutng
On Thu, 3 Jan 2013, Alexander Motin wrote: On 03.01.2013 16:45, Bruce Evans wrote: On Wed, 2 Jan 2013, Alexander Motin wrote: More important for scheduling fairness thread's CPU percentage is also based on hardclock() and hiding from it was trivial before, since all sleep primitives were strictly aligned to hardclock(). Now it is slightly less trivial, since this alignment was removed and user-level APIs provide no easy way to enforce it. %cpu is actually based on statclock(), and not even used for scheduling. May be for SCHED_4BSD, but not for SCHED_ULE. In SCHED_ULE both %cpu and thread priority based on the same ts_ticks counter, that is based on hardclock() as time source. Interactivity calculation uses alike logic and uses the same time source. Hmm. I missed this because it hacks on the 'ticks' global. It is clearer in intermediate versions which use the scheduler API sched_tick(), which is the hardclock analogue of sched_clock() for statclock. sched_tick() is now bogus since it is null for all schedulers. Bruce ___ 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: problem after installkernel going from 9.0 to CURRENT
On 1/3/2013 11:40 AM, Warren Block wrote: On Wed, 2 Jan 2013, Robert Huff wrote: (While this may not be a strictly CURRENT issue, I asked on questions@, but have not found a solution.) Situation: One of my boxes failed, and for various reasons it became easier to just scrub and rebuild it. Like its predecessor it will run CURRENT 1) Using BSDinstall, I flushed then created the first disk: ada2p1freebsd-boot128k ada2p2freebsd-swap4g ada2p3freebsd-ufs25g 5) On rebooting, the loader(??) claims to not be able to find a bootable partition - i.e. I get a screen that ends in mountroot . Providing the presumptive value by hand returns error 19. It really does not sound like a GPT problem, because 9.0 booted. I don't (at the moment) think it's GPT caused; but I do think it may be GPT related. The -current kernel can't find/detect the device. Scrolling back in the console buffer might find a problem. buildworld/kernel/installworld do not affect the disk partitioning, but can change the code that looks for those partitions. Exactly. I'm looking for help figuring out how the hand-off from loader to kernel got broken and what I have to do to fix it. One possibility: I believe I labeled each of the partitions during the gpt creation process. Can I use those labels to (hopefully) by-pass this issue? Robert Huff ___ 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: problem after installkernel going from 9.0 to CURRENT
On Wed, Jan 2, 2013 at 12:03 PM, Robert Huff roberth...@rcn.com wrote: On 1/2/2013 1:57 PM, Benjamin Kaduk wrote: On Wed, 2 Jan 2013, Robert Huff wrote: For a full clean install, I believe that bsdinstall should prompt about installing bootcode around here. I don't really understand from your procedure how bsdinstall was used; there might be some edge case where there is no prompt about bootcode. 2) Installed off the 9.0 CD, got it up and running, everything was good. Let me elaborate on this: 2) Installed off the 9.0 CD, had a fully bootable system connected to the Internet, everything was good. I think you should investigate the 'bootcode' subcommand of gpart(8). Does the above change things? It was my expectation installkernel would Do The Right Thing with respect to new bootcode, and I am surprised it did not. installkernel does absolutely nothing to the boot partition. You need to use bsdinstall or gpart to write the new image to disk. That said, I know of no reason that the boot code written by the 9.0 install would fail to boot head. I am running 9.1 on a GPT disk and it works fine, but I that disk is ada1 and I have booteasy installed on the MBR of ada0. It has no problems booting the 9.1 system. (Windows 7 in on ada0.) Then again, I am hardly an expert on the subject. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: problem after installkernel going from 9.0 to CURRENT
On Thu, Jan 3, 2013 at 3:23 PM, Robert Huff roberth...@rcn.com wrote: On 1/3/2013 11:40 AM, Warren Block wrote: On Wed, 2 Jan 2013, Robert Huff wrote: (While this may not be a strictly CURRENT issue, I asked on questions@, but have not found a solution.) Situation: One of my boxes failed, and for various reasons it became easier to just scrub and rebuild it. Like its predecessor it will run CURRENT 1) Using BSDinstall, I flushed then created the first disk: ada2p1freebsd-boot128k ada2p2freebsd-swap4g ada2p3freebsd-ufs25g 5) On rebooting, the loader(??) claims to not be able to find a bootable partition - i.e. I get a screen that ends in mountroot . Providing the presumptive value by hand returns error 19. It really does not sound like a GPT problem, because 9.0 booted. I don't (at the moment) think it's GPT caused; but I do think it may be GPT related. The -current kernel can't find/detect the device. Scrolling back in the console buffer might find a problem. buildworld/kernel/installworld do not affect the disk partitioning, but can change the code that looks for those partitions. Exactly. I'm looking for help figuring out how the hand-off from loader to kernel got broken and what I have to do to fix it. One possibility: I believe I labeled each of the partitions during the gpt creation process. Can I use those labels to (hopefully) by-pass this issue? Yes! This is the current recommended way of doing it. cat /etc/fstab # DeviceMountpoint FStype Options DumpPass# /dev/gpt/swap noneswapsw 0 0 /dev/gpt/root / ufs rw 1 1 /dev/gpt/tmp/tmpufs rw 2 2 /dev/gpt/usr/usrufs rw 2 2 /dev/gpt/var/varufs rw 2 2 -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: problem after installkernel going from 9.0 to CURRENT
On Thu, 3 Jan 2013, Kevin Oberman wrote: One possibility: I believe I labeled each of the partitions during the gpt creation process. Can I use those labels to (hopefully) by-pass this issue? Yes! This is the current recommended way of doing it. cat /etc/fstab # DeviceMountpoint FStype Options DumpPass# /dev/gpt/swap noneswapsw 0 0 /dev/gpt/root / ufs rw 1 1 /dev/gpt/tmp/tmpufs rw 2 2 /dev/gpt/usr/usrufs rw 2 2 /dev/gpt/var/varufs rw 2 2 To avoid collisions, I recommend people use unique labels on each system. I sometimes pick a couple of letters from the system name or drive: xfswap, xfrootfs, xftmpfs, xfusrfs, xfvarfs. ___ 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
[head tinderbox] failure on ia64/ia64
TB --- 2013-01-04 02:04:44 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-04 02:04:44 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-04 02:04:44 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-01-04 02:04:44 - cleaning the object tree TB --- 2013-01-04 02:04:44 - /usr/local/bin/svn stat /src TB --- 2013-01-04 02:04:48 - At svn revision 245019 TB --- 2013-01-04 02:04:49 - building world TB --- 2013-01-04 02:04:49 - CROSS_BUILD_TESTING=YES TB --- 2013-01-04 02:04:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-04 02:04:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-04 02:04:49 - SRCCONF=/dev/null TB --- 2013-01-04 02:04:49 - TARGET=ia64 TB --- 2013-01-04 02:04:49 - TARGET_ARCH=ia64 TB --- 2013-01-04 02:04:49 - TZ=UTC TB --- 2013-01-04 02:04:49 - __MAKE_CONF=/dev/null TB --- 2013-01-04 02:04:49 - cd /src TB --- 2013-01-04 02:04:49 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Fri Jan 4 02:04:54 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Fri Jan 4 03:40:35 UTC 2013 TB --- 2013-01-04 03:40:35 - generating LINT kernel config TB --- 2013-01-04 03:40:35 - cd /src/sys/ia64/conf TB --- 2013-01-04 03:40:35 - /usr/bin/make -B LINT TB --- 2013-01-04 03:40:35 - cd /src/sys/ia64/conf TB --- 2013-01-04 03:40:35 - /usr/sbin/config -m LINT TB --- 2013-01-04 03:40:35 - building LINT kernel TB --- 2013-01-04 03:40:35 - CROSS_BUILD_TESTING=YES TB --- 2013-01-04 03:40:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-04 03:40:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-04 03:40:35 - SRCCONF=/dev/null TB --- 2013-01-04 03:40:35 - TARGET=ia64 TB --- 2013-01-04 03:40:35 - TARGET_ARCH=ia64 TB --- 2013-01-04 03:40:35 - TZ=UTC TB --- 2013-01-04 03:40:35 - __MAKE_CONF=/dev/null TB --- 2013-01-04 03:40:35 - cd /src TB --- 2013-01-04 03:40:35 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Jan 4 03:40:35 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Fri Jan 4 04:15:09 UTC 2013 TB --- 2013-01-04 04:15:09 - cd /src/sys/ia64/conf TB --- 2013-01-04 04:15:09 - /usr/sbin/config -m GENERIC TB --- 2013-01-04 04:15:09 - building GENERIC kernel TB --- 2013-01-04 04:15:09 - CROSS_BUILD_TESTING=YES TB --- 2013-01-04 04:15:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-04 04:15:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-04 04:15:09 - SRCCONF=/dev/null TB --- 2013-01-04 04:15:09 - TARGET=ia64 TB --- 2013-01-04 04:15:09 - TARGET_ARCH=ia64 TB --- 2013-01-04 04:15:09 - TZ=UTC TB --- 2013-01-04 04:15:09 - __MAKE_CONF=/dev/null TB --- 2013-01-04 04:15:09 - cd /src TB --- 2013-01-04 04:15:09 - /usr/bin/make -B buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri Jan 4 04:15:09 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/firewire/if_fwip.c:499: undefined reference to `crom_add_simple_text' /src/sys/dev/firewire/if_fwip.c:500: undefined reference to `crom_add_entry' /src/sys/dev/firewire/if_fwip.c:501: undefined reference to `crom_add_simple_text' if_fwip.o: In function `fwip_stream_input': /src/sys/dev/firewire/if_fwip.c:840: undefined reference to `fw_noderesolve_nodeid' if_fwip.o: In function `fwip_unicast_input': /src/sys/dev/firewire/if_fwip.c:939: undefined reference to `fw_noderesolve_nodeid' if_fwip.o:(.data.rel+0x80): undefined reference to `sysctl__hw_firewire_children' *** [kernel.debug] Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-04 04:23:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-04 04:23:26 - ERROR: failed to build GENERIC kernel TB --- 2013-01-04 04:23:26 - 6534.29 user 1389.55 system 8321.70 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full ___ 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
SOLVED: problem after installkernel going from 9.0 to CURRENT
Using the GPT labels is a winning solution. Thanks to all those who helped, Robert Huff ___ 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: problem after installkernel going from 9.0 to CURRENT
On Thu, Jan 3, 2013 at 7:24 PM, Warren Block wbl...@wonkity.com wrote: On Thu, 3 Jan 2013, Kevin Oberman wrote: One possibility: I believe I labeled each of the partitions during the gpt creation process. Can I use those labels to (hopefully) by-pass this issue? Yes! This is the current recommended way of doing it. cat /etc/fstab # DeviceMountpoint FStype Options Dump Pass# /dev/gpt/swap noneswapsw 0 0 /dev/gpt/root / ufs rw 1 1 /dev/gpt/tmp/tmpufs rw 2 2 /dev/gpt/usr/usrufs rw 2 2 /dev/gpt/var/varufs rw 2 2 To avoid collisions, I recommend people use unique labels on each system. I sometimes pick a couple of letters from the system name or drive: xfswap, xfrootfs, xftmpfs, xfusrfs, xfvarfs. Good point (as usual). The example was from my laptop where this is not an issue, but in larger environments it is an excellent suggestion. I would put the unique ID at the end of the label as the eye tends to read from left to right (at least in most language so you can recognize whether it is usr or swap or home pretty much instantly. Sticking letters at the start make the most fundamental information harder to see. swaprxf xfswap usrfsxf xfusrfs Still, this is a nit and I appreciate the suggestion!.. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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
