Version nomenclature [was RELENG_7 to 8]
Wanted to put in a suggestion. Users are constantly confused and asking questions about the FreeBSD version naming scheme, somehow not quite picking it up right, which is which, where to use it, etc. And though I know what it is, it still seems silly to me. Because we've got logical pointers _loosely_ correlating to formal repo tag and branch names. Worst case I've seen was when FreeBSD had 4, 5, 6 all in flux at once. STABLE and CURRENT could only point to two things and there were about 10 potential tags involved. Basically, I'm proposing FreeBSD should relegate the terms STABLE and CURRENT out to the marketing portion of the web team. You can't check them out of any repo as tags, 4 and 5 were 'stable' when 6 was 'current' and so on. CURRENT means nothing more than cvs HEAD or svn trunk or git . So use those terms instead of leading people think they can check out 'CURRENT' or that it has some magical command line, config file or source properties. website: 'The latest snapshots from our FreeBSD-STABLE and FreeBSD-CURRENT branches are also available'... checking out those branch names gets you HEAD. There are references to 7-STABLE, 8-CURRENT and parhaps other bastardizations on a theme :-) in the handbook that are not valid tags. STABLE is pretty much the same way, only more confusing if more than one thing is 'stable'. Back in the 4/5/6 days it could have referred to any number of branches. And on the main page, we now have more buzzwords... 'production' and 'legacy'. In fact, I'd venture that the proper place for such words, CURRENT/STABLE/production/legacy, is only on the release/download/support related pages of the website, with little '->'s to the actual tag they imply. More importanly, with descriptions that say something like which trains are developed/supported when, for how long. ie: why the deserve such words to be applied to them. Anyone who has a need to refer to CURRENT/STABLE is obviously getting beyond the release iso's and into the cvs/svn/git level of things. So just use the right terms then. Encourage people to use proper tags and for reporting bugs and things. They could probably make it into uname somehow. RELENG_x_y_RELEASE RELENG_x_y [date/serial] RELENG_x [date/serial] HEAD/trunk [date/serial] uname: '7.2-STABLE #0 ' isn't quite the same solid reference as RELENG_7 as of yesterdays code. Which is what it is, not the zero-eth 7.2 errata/security/stability commit. And maybe figure out a way that each commit bumps a serial counter in UPDATING or some stampfile or uname so people can report the serial. Or maybe use the git crypto hash thing. FreeBSD needs a crypto hash reference inside the primary source tree anyways, not just on the n steps removed iso's. I dunno, just seen year after year of these questions on the lists :) Thought I'd put at least something out there. Not meant to be a bikeshed or anything. More like something to be addressed by doc project or whatever. ___ 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: Multiple USB drives stability question
I just tested my 2nd 1TB gmirror device on another system with FBSD 7.2. I was getting full throughput on the drive and no lockup using bonnie++ and also monitoring with gstat. I then moved those drives back on my main server. When I booted the system I hung on the 320GB gmirror devices. Previously the 1st 1TB gmirror and 320GB gmirror were attached to the integrated USB ports on the motherboard. I moved the 320GB gmirror to a PCI USB adapter. The 2 320GB drives in the gmirror were da5 and da6. Here's what I saw on the console: (da6:umass-sim6:6:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 (da6:umass-sim6:6:0:0): CAM Status: SCSI Status Error (da6:umass-sim6:6:0:0): SCSI Status: Check Condition (da6:umass-sim6:6:0:0): ILLEGAL REQUEST asc:20,0 (da6:umass-sim6:6:0:0): Invalid command operation mode (da6:umass-sim6:6:0:0): Unretryable error GEOM_MIRROR: Request failed (error=5), da6[READ(offset=512, length=512)] GEOM_MIRROR: Device gm-san: provider da6 disconnected. (da5:umass-sim5:5:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 (da5:umass-sim5:5:0:0): CAM Status: SCSI Status Error (da5:umass-sim5:5:0:0): SCSI Status: Check Condition (da5:umass-sim5:5:0:0): ILLEGAL REQUEST asc:20,0 (da5:umass-sim5:5:0:0): Invalid command operation mode (da5:umass-sim5:5:0:0): Unretryable error GEOM_JOURNAL: BIO_FLUSH not supported by mirror/gm-san. I waited for a few minutes with no change in the console. I then detached one of the USB drives (which happened to be da6) and saw this: umass6: at uhub7 port 4 (addr 4) disconnected (da6:umass-sim6:6:0:0): lost device Nothing else changed for a few minutes so I powered off the system. When I brought it back up the 320GB gmirror device was out of sync, but apart from that all devices were online. Below are the kernel messages from the second boot: Copyright (c) 1992-2009 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 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009 r...@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 2.26GHz (2266.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf49 Stepping = 9 Features=0xbfebfbff Features2=0x441d AMD Features2=0x1 real memory = 1877868544 (1790 MB) avail memory = 1826934784 (1742 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 6fde (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfe80-0xfe8003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xc000-0xcfff,0xfb00-0xfbff irq 16 at device 0.0 on pci1 pcib2: irq 27 at device 2.0 on pci0 pci2: on pcib2 pcib3: irq 31 at device 3.0 on pci0 pci3: on pcib3 atapci0: port 0xfc00-0xfc07,0xf800-0xf803,0xf400-0xf407,0xf000-0xf003,0xec00-0xec0f,0xe800-0xe8ff irq 21 at device 15.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe400-0xe40f at device 15.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] uhci0: port 0xe000-0xe01f irq 20 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xdc00-0xdc1f irq 22 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xd800-0xd81f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xd400-0xd41f irq 23 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfdfff000-0xfdfff0ff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered umass0: on uhub4 umass1: on uhub4 umass2: on uhub4 umass3: on uhub4 isab0: at device 17.0 on pci0 isa0: on isab0 vr0: port 0xd000-0xd0ff mem 0xfdffe000-0xfdffe0ff irq 23 at device 18.0 on pci0 vr
Multiple USB drives stability question
Is there a practical limit on the number of active USB drives with FreeBSD? I've had stability issues using multiple USB drives as storage. My initial design goal was cheap, hot-swappable storage. I am only using a 100MB network currently so throughput on the storage is not a problem as I can't push the data to/from the drives faster than what my network requests are. I first tried my setup on 7.0, then migrated to a newer PC, then upgraded to 7.2. I have the following USB drive setup: 1 320GB gmirror (320x2) + gjournal + ufs2 1 1TB gmirror (1TBx2) + gjournal + ufs2 1 150GB gjournal + ufs2 I also have another 1TB gmirror (1TBx2) + gjournal but removed it. The system crashed when I used these drives (bacula or bonnie++) so I pulled them to test on another system. Recently my stability issue has been when I have been writing data to the 150GB gjournal drive from the 320GB gmirror device (USB device -> USB device). It will be working fine, then all I/O stops on the 150GB drive. The system remains responding to other USB devices etc. for a while. I try rebooting and the system crashes with gjournal errors (didn't write down, but I will later). Every time this happens the 1TB gmirror comes up fine but one of the 320GB providers is missing. No problem after 'gmirror forget' and 'gmirror insert'. Everything rebuilds fine. The 150GB gjournal drive is fine after a 'fsck -y'. I do pair the gmirror drives to the same USB adapter. Found out after initial testing with multiple USB adapters that they do not appear standard enough to cross adapters like I would for a production server at work to prevent SPOF with an adapter. I have tried Linux as well with softraid and LVM2 on the same hardware. It worked fine until I applied software updates and the udev took 30+ minutes to boot. I went back to FreeBSD. Even when I crashed I was back up in 2-5 minutes. I can and will provide more detail if requested. My concern is that the issue seems to continue no matter what hardware/OS changes I try. Thanks in advance. ___ 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: Going to BSD 8 from RELENG_7
> Date: Fri, 14 Aug 2009 10:17:55 +0200 > From: "Johan Hendriks" > Sender: owner-freebsd-sta...@freebsd.org > > >I cvsup and build RELENG_7 many times a week. This has served me well > > >(except for the ZFS boot problem I had that went in and was backed > >out) for quite a while. > > >I like to track a STABLE release. When BSD 7 went to 7.1 and to 7.2, > >it all just happened automatically with the way I do things. > > >Now I am interested on one of my BSD machines to try 8.0. I need to > >change my cvsup target from RELENG_7 to CURRENT I believe. Is that > >true? When will STABLE become 8.0? > > >Also, does anyone know if there is a project page that talks about > >8.0, its timeline, its features, etc? If you type "8.0" into the main > > >freebsd.org web page it find nothing on the entire web site. > >Obviously something is wrong... > > >Thanks! > > >Dan Allen > >Spring Lake, Utah > > Change your target to tag=RELENG_8 to track 8.0-Stable Or to > tag=RELENG_8_0 to get the release (When it is released) > If you want to track CURRENT change your target to tag=. < do not forget > the dot it is CURRENT ;-) > Tag=. Will become FreeBSD 9 when 8 is released. > > > To see some big changes go to the following page. > http://ivoras.sharanet.org/freebsd/freebsd8.html > > It give you one nice overview of things changed. > > > Be aware that if you go from 7 to 8 you will need to rebuild all your > installed ports. > ALso if you do a buildworld from 7 to 8 do not do the make delete-old > and the make delete-old-libs before you have rebuild your ports. > If you do the make delete-old and make delete-old-libs runs, all ports > depending on the FreeBSD 7 libs will not work any more. << read: most > likely all your ports. > If you have changed for example your Shell for root to a ports based > shell like bash and you do the make delete-old-libs you can not log in > anymore, because bash depends on the 7 libs wich are not there anymore. One other suggestion: if you have the libusb port installed, be sure to delete it BEFORE you try updating any ports. libusb is now in the base system and is incompatible with the ports version, so anything that is linked to it will fail with the new USB stack in 8.0. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: Panic due to junk pointer in pf(4)
On Wednesday 12 August 2009 21:16:09 Peter Jeremy wrote:
> My firewall (7.2p3/i386) recently panic'd:
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x1065e
> fault code = supervisor read, page not present
> ...
> I have a crashdump that shows:
> #6 0xc06c9c1b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
> #7 0xc044ecd0 in pf_state_tree_lan_ext_RB_REMOVE_COLOR (head=0xc2a256a8,
> parent=0xc442c6a0, elm=0xc40aa8e0) at
> /usr/src/sys/contrib/pf/net/pf.c:391 #8 0xc044ef79 in
> pf_state_tree_lan_ext_RB_REMOVE (head=0xc2a256a8, elm=0xc404a11c) at
> /usr/src/sys/contrib/pf/net/pf.c:391
> #9 0xc045383e in pf_unlink_state (cur=0xc404a11c)
> at /usr/src/sys/contrib/pf/net/pf.c:1158
> #10 0xc0456b6e in pf_purge_expired_states (maxcheck=119)
> at /usr/src/sys/contrib/pf/net/pf.c:1242
> #11 0xc04570f9 in pf_purge_thread (v=0x0)
> at /usr/src/sys/contrib/pf/net/pf.c:998
> #12 0xc0535781 in fork_exit (callout=0xc0456f50 , arg=0x0,
> frame=0xd2d4cd38) at /usr/src/sys/kern/kern_fork.c:810
> #13 0xc06c9c90 in fork_trampoline () at
> /usr/src/sys/i386/i386/exception.s:264
>
> Working up, 'parent' in pf_state_tree_lan_ext_RB_REMOVE_COLOR() has
> a garbage u.s.entry_lan_ext:
> (kgdb) p parent->u
> $3 = {s = {entry_lan_ext = {rbe_left = 0x10602, rbe_right = 0x5,
> rbe_parent = 0xc40aa8e0, rbe_color = -1002258432}, entry_ext_gwy = {
> rbe_left = 0xc3c42238, rbe_right = 0x1, rbe_parent = 0x0,
> rbe_color = 0}, entry_id = {rbe_left = 0xc3c54470, rbe_right = 0x0,
> rbe_parent = 0x0, rbe_color = 0}, entry_list = {tqe_next =
> 0xc41f9e6c, tqe_prev = 0x0}, kif = 0xc442c58c},
> ifname = "\002\006\001\000\000\000\005\000à¨\nÄ\000ÀBÄ"}
>
> Does anyone have any suggestions on where to look next?
You could try the attached patch that I just set to re@ for inclusion. There
is an obvious error in how I handle the pf_consistency_lock in the purge
thread that might well be the culprit for the error you are seeing. I assume
you can't trigger the panic at will, though. In any case I'd be interested in
your feedback, thanks.
--
/"\ Best regards, | mla...@freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mla...@efnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: sys/contrib/pf/net/pfvar.h
===
--- sys/contrib/pf/net/pfvar.h (revision 196216)
+++ sys/contrib/pf/net/pfvar.h (working copy)
@@ -1593,8 +1593,13 @@ extern struct pool pf_state_pl, pf_altq_pl, pf_p
extern struct pool pf_state_scrub_pl;
#endif
extern void pf_purge_thread(void *);
+#ifdef __FreeBSD__
+extern int pf_purge_expired_src_nodes(int);
+extern int pf_purge_expired_states(u_int32_t, int);
+#else
extern void pf_purge_expired_src_nodes(int);
extern void pf_purge_expired_states(u_int32_t);
+#endif
extern void pf_unlink_state(struct pf_state *);
extern void pf_free_state(struct pf_state *);
extern int pf_insert_state(struct pfi_kif *,
Index: sys/contrib/pf/net/pf.c
===
--- sys/contrib/pf/net/pf.c (revision 196216)
+++ sys/contrib/pf/net/pf.c (working copy)
@@ -971,6 +971,9 @@ void
pf_purge_thread(void *v)
{
int nloops = 0, s;
+#ifdef __FreeBSD__
+ int locked;
+#endif
for (;;) {
tsleep(pf_purge_thread, PWAIT, "pftm", 1 * hz);
@@ -978,14 +981,19 @@ pf_purge_thread(void *v)
#ifdef __FreeBSD__
sx_slock(&pf_consistency_lock);
PF_LOCK();
+ locked = 0;
if (pf_end_threads) {
- pf_purge_expired_states(pf_status.states);
+ PF_UNLOCK();
+ sx_sunlock(&pf_consistency_lock);
+ sx_xlock(&pf_consistency_lock);
+ PF_LOCK();
+ pf_purge_expired_states(pf_status.states, 1);
pf_purge_expired_fragments();
- pf_purge_expired_src_nodes(0);
+ pf_purge_expired_src_nodes(1);
pf_end_threads++;
- sx_sunlock(&pf_consistency_lock);
+ sx_xunlock(&pf_consistency_lock);
PF_UNLOCK();
wakeup(pf_purge_thread);
kproc_exit(0);
@@ -994,20 +1002,44 @@ pf_purge_thread(void *v)
s = splsoftnet();
/* process a fraction of the state table every second */
+#ifdef __FreeBSD__
+ if(!pf_purge_expired_states(1 + (pf_status.states
+ / pf_default_rule.timeout[PFTM_INTERVAL]), 0)) {
+ PF_UNLOCK();
+ sx_sunlock(&pf_consistency_lock);
+ sx_xlock(&pf_consistency_lock);
+ PF_LOCK();
+ locked = 1;
+
+ pf_purge_expired_states(1 + (pf_status.states
+ / pf_default_rule.timeout[PFTM_INTERVAL]), 1);
+ }
+#else
pf_purge_expired_states(1 + (pf_status.states
/ pf_default_rule.timeout[PFTM_INTERVAL]));
+#endif
/* purge other expired types every PFTM_INTERVAL seconds */
if (++nloops >= pf_default_rule.timeout[PFTM_INTERVAL]) {
pf_purge_expired_fragments();
- pf_purge_expired_src_nodes(0);
+ if (!pf_purge_expired_src_nodes(locked)) {
+PF_UNL
Re: USB mouse not detected on boot of 7-STABLE
On 2009-Aug-13 22:36:24 +0200, Trond Endrestøl wrote: >On Thu, 13 Aug 2009 13:16-0700, Kevin Oberman wrote: >> Hardware that simply would not work on the old stack is operating >> flawlessly on 8.0-BETA2. > >Does this include hardware such as the Huawei E220 HSDPA USB Modem? AFAIK, it does. It definitely works for my E169. -- Peter Jeremy pgpySqwg2cZPO.pgp Description: PGP signature
RE: Going to BSD 8 from RELENG_7
>I cvsup and build RELENG_7 many times a week. This has served me well >(except for the ZFS boot problem I had that went in and was backed >out) for quite a while. >I like to track a STABLE release. When BSD 7 went to 7.1 and to 7.2, >it all just happened automatically with the way I do things. >Now I am interested on one of my BSD machines to try 8.0. I need to >change my cvsup target from RELENG_7 to CURRENT I believe. Is that >true? When will STABLE become 8.0? >Also, does anyone know if there is a project page that talks about >8.0, its timeline, its features, etc? If you type "8.0" into the main >freebsd.org web page it find nothing on the entire web site. >Obviously something is wrong... >Thanks! >Dan Allen >Spring Lake, Utah Change your target to tag=RELENG_8 to track 8.0-Stable Or to tag=RELENG_8_0 to get the release (When it is released) If you want to track CURRENT change your target to tag=. < do not forget the dot it is CURRENT ;-) Tag=. Will become FreeBSD 9 when 8 is released. To see some big changes go to the following page. http://ivoras.sharanet.org/freebsd/freebsd8.html It give you one nice overview of things changed. Be aware that if you go from 7 to 8 you will need to rebuild all your installed ports. ALso if you do a buildworld from 7 to 8 do not do the make delete-old and the make delete-old-libs before you have rebuild your ports. If you do the make delete-old and make delete-old-libs runs, all ports depending on the FreeBSD 7 libs will not work any more. << read: most likely all your ports. If you have changed for example your Shell for root to a ports based shell like bash and you do the make delete-old-libs you can not log in anymore, because bash depends on the 7 libs wich are not there anymore. And as usual MAKE A GOOD BACKUP Regards, Johan ___ 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" No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.55/2301 - Release Date: 08/13/09 18:16:00 No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.55/2301 - Release Date: 08/13/09 18:16:00 ___ 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: Problem with IBM Thinkpad T30 shutting down due to high temperatures
Hi Alexandre, Hello list, 2009/8/14 Alexandre "Sunny" Kovalenko : > On Mon, 2009-08-10 at 23:53 +0200, Christian Walther wrote: >> Hello list, >> [...] > Add something like > > hw.acpi.thermal.tz1.passive_cooling=1 > hw.acpi.thermal.user_override=1 > hw.acpi.thermal.tz1._PSV=75C I did. Well, not 75C, because this value seems to be somewhat low. The critical temperature is 92C, and the original value of _PSV is 86.5C. This might be to hight, so I'm currently experimenting with lower values. So far, 84C really seems to be an acceptable value. Additionally, I'm trying different settings for powerd, which really seems to make a different as Roland stated in my "ACPI/Cpufreq issue?" post. > Also, please, consider following advice on cleaning up dust and possibly > re-applying the thermal paste given elsewhere in the thread -- on my > 2-year old laptop doing both shaved about 3C from the normal operating > temperature. Yes, doing some internal cleaning and applying new thermal paste is on my list. Luckily IBM supplies good manuals and the Thinkpad can be disassembled easily. It's on my list and will be done next week. Luckily, reducing _PSV made it possible to rebuild world and kernel, so my system is up to date in this regard. I yesterday tried to build some complex ports (audio/mumble, which in turn requires QT), and it worked nicely. But I'm not entirely satisfied and will keep tweaking the system (after I did the cleaning...). Christian ___ 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"
