Re: release documentation confusing for 9.1
Aristedes Maniatis wrote: > Could I ask that someone with appropriate access rights review the state > of release documentation for 9.1 beta. It is very confused. > > > 1. This page is the best information available: > http://www.freebsd.org/releases/9.1R/schedule.html > > 2. The link from the front page ( http://www.freebsd.org/ ) is labelled > "Upcoming: 9.1-BETA1" but goes to a page which is mostly about existing > releases, not the next release. http://www.freebsd.org/where.html#helptest > > 3. Clicking on the "view" link for the 9.1 information on that page > takes you to http://wiki.freebsd.org/Releng/9.1TODO which looks a lot > like the information in point [1] but wrong/old. > > 4. On http://www.freebsd.org/where.html#helptest there is a link to > "FreeBSD Snapshot Releases" for people interested in "FreeBSD-CURRENT > (AKA 10.0-CURRENT)". But following the link takes you to a page where > you get linked to "9-CURRENT, 8-STABLE, 7-STABLE, and 6-STABLE" snapshots. > > > > It is possible I'm just stuck in the past, but I've never been able to > navigate the 'new' bowling ball branded FreeBSD site nearly as well as > the older incarnation. And yes, I can eventually figure it all out... > but this information could be a whole lot clearer. I design information > presentation for a living, so perhaps I'm picky about these things, but > I do think that confusion could turn people away from my favourite > operating system. > Hi I can not agree more about what you say, but the pages you mention still let you find what you want and this pages do have a release/modify date stamp somewhere and they are not thaaat old worse and worse it gets when looking for documentation all this pages do not have a date or indication to what version they refer to, most are old, some even wrong for actual releases even if recognizing the work spent by all to write the pages, also recognizing that all docs are well written, organized and understandable, all of it is worthless when not up to date, wrong or incomplete for actual releases (either OS or ports) or merely theoretical this is still more important because a lot of general product docs for, lets say for example xorg or kde, do not apply fully to their FreeBSD ports, forcing the user finding his way elsewhere or getting stuck with eventually not working system or as you say leading to turn away from freeBSD one step forward would be, adding at least the last modified date to each document, but not in tiny light grey chars at the bottom, but big and fat on top of the doc, so at last the user would have the possibility to consider it being old or new documentation []s Hans -- H +55 11 4249. signature.asc Description: OpenPGP digital signature
Re: [stable 9] panic on reboot: ipmi_wd_event()
On Tuesday, July 31, 2012 4:51:19 pm Attilio Rao wrote:
> On 7/31/12, John Baldwin wrote:
> > On Thursday, July 19, 2012 7:58:14 pm Sean Bruno wrote:
> >> Working on the Dell R420 today, got most of it working, even the
> >> broadcom ethernet cards! However, I get the following when I reboot the
> >> system:
> >>
> >> Syncing disks, vnodes remaining...4 Sleeping thread (tid 100107, pid 9)
> >> owns a non-sleepable lock
> >> KDB: stack backtrace of thread 100107:
> >> sched_switch() at sched_switch+0x19f
> >> mi_switch() at mi_switch+0x208
> >> sleepq_switch() at sleepq_switch+0xfc
> >> sleepq_wait() at sleepq_wait+0x4d
> >> _sleep() at _sleep+0x3f6
> >> ipmi_submit_driver_request() at ipmi_submit_driver_request+0x97
> >> ipmi_set_watchdog() at ipmi_set_watchdog+0xb1
> >> ipmi_wd_event() at ipmi_wd_event+0x8f
> >> kern_do_pat() at kern_do_pat+0x10f
> >> sched_sync() at sched_sync+0x1ea
> >> fork_exit() at fork_exit+0x135
> >> fork_trampoline() at fork_trampoline+0xe
> >
> > Hmmm, the watchdog pat should probably happen without holding locks if
> > possible. This is related to the IPMI watchdog being special and wanting
> > to schedule a thread to work.
>
> The watchdog pat without the locks is not easy to do because we
> register the watchdog callbacks in eventhandlers, which are indeed
> locked (and you may also end up racing against watchdog detach, if you
> don't use any lock at all).
No, eventhandlers go through several hoops to not hold any locks while
the eventhandler functions are running. It seems in this case that a
lock is held in a higher layer (sched_sync()) and that is what I was
talking about. Yes, it is the 'sync_mtx' that is held. Something like this
may work:
Index: vfs_subr.c
===
--- vfs_subr.c (revision 238969)
+++ vfs_subr.c (working copy)
@@ -1868,8 +1868,11 @@ sched_sync(void)
continue;
}
- if (first_printf == 0)
+ if (first_printf == 0) {
+ mtx_unlock(&sync_mtx);
wdog_kern_pat(WD_LASTVAL);
+ mtx_lock(&sync_mtx);
+ }
}
if (!LIST_EMPTY(gslp)) {
--
John Baldwin
___
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: [stable 9] panic on reboot: ipmi_wd_event()
On 8/1/12, John Baldwin wrote: > On Tuesday, July 31, 2012 4:51:19 pm Attilio Rao wrote: >> On 7/31/12, John Baldwin wrote: >> > On Thursday, July 19, 2012 7:58:14 pm Sean Bruno wrote: >> >> Working on the Dell R420 today, got most of it working, even the >> >> broadcom ethernet cards! However, I get the following when I reboot >> >> the >> >> system: >> >> >> >> Syncing disks, vnodes remaining...4 Sleeping thread (tid 100107, pid >> >> 9) >> >> owns a non-sleepable lock >> >> KDB: stack backtrace of thread 100107: >> >> sched_switch() at sched_switch+0x19f >> >> mi_switch() at mi_switch+0x208 >> >> sleepq_switch() at sleepq_switch+0xfc >> >> sleepq_wait() at sleepq_wait+0x4d >> >> _sleep() at _sleep+0x3f6 >> >> ipmi_submit_driver_request() at ipmi_submit_driver_request+0x97 >> >> ipmi_set_watchdog() at ipmi_set_watchdog+0xb1 >> >> ipmi_wd_event() at ipmi_wd_event+0x8f >> >> kern_do_pat() at kern_do_pat+0x10f >> >> sched_sync() at sched_sync+0x1ea >> >> fork_exit() at fork_exit+0x135 >> >> fork_trampoline() at fork_trampoline+0xe >> > >> > Hmmm, the watchdog pat should probably happen without holding locks if >> > possible. This is related to the IPMI watchdog being special and >> > wanting >> > to schedule a thread to work. >> >> The watchdog pat without the locks is not easy to do because we >> register the watchdog callbacks in eventhandlers, which are indeed >> locked (and you may also end up racing against watchdog detach, if you >> don't use any lock at all). > > No, eventhandlers go through several hoops to not hold any locks while > the eventhandler functions are running. It seems in this case that a > lock is held in a higher layer (sched_sync()) and that is what I was > talking about. Yes, it is the 'sync_mtx' that is held. Something like this No, EVENTHANDLER_INVOKE() acquires eventhandler internal locks. Look at eventhandler_find_list() for details. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: [stable 9] panic on reboot: ipmi_wd_event()
On 8/1/12, Attilio Rao wrote: > On 8/1/12, John Baldwin wrote: >> On Tuesday, July 31, 2012 4:51:19 pm Attilio Rao wrote: >>> On 7/31/12, John Baldwin wrote: >>> > On Thursday, July 19, 2012 7:58:14 pm Sean Bruno wrote: >>> >> Working on the Dell R420 today, got most of it working, even the >>> >> broadcom ethernet cards! However, I get the following when I reboot >>> >> the >>> >> system: >>> >> >>> >> Syncing disks, vnodes remaining...4 Sleeping thread (tid 100107, pid >>> >> 9) >>> >> owns a non-sleepable lock >>> >> KDB: stack backtrace of thread 100107: >>> >> sched_switch() at sched_switch+0x19f >>> >> mi_switch() at mi_switch+0x208 >>> >> sleepq_switch() at sleepq_switch+0xfc >>> >> sleepq_wait() at sleepq_wait+0x4d >>> >> _sleep() at _sleep+0x3f6 >>> >> ipmi_submit_driver_request() at ipmi_submit_driver_request+0x97 >>> >> ipmi_set_watchdog() at ipmi_set_watchdog+0xb1 >>> >> ipmi_wd_event() at ipmi_wd_event+0x8f >>> >> kern_do_pat() at kern_do_pat+0x10f >>> >> sched_sync() at sched_sync+0x1ea >>> >> fork_exit() at fork_exit+0x135 >>> >> fork_trampoline() at fork_trampoline+0xe >>> > >>> > Hmmm, the watchdog pat should probably happen without holding locks if >>> > possible. This is related to the IPMI watchdog being special and >>> > wanting >>> > to schedule a thread to work. >>> >>> The watchdog pat without the locks is not easy to do because we >>> register the watchdog callbacks in eventhandlers, which are indeed >>> locked (and you may also end up racing against watchdog detach, if you >>> don't use any lock at all). >> >> No, eventhandlers go through several hoops to not hold any locks while >> the eventhandler functions are running. It seems in this case that a >> lock is held in a higher layer (sched_sync()) and that is what I was >> talking about. Yes, it is the 'sync_mtx' that is held. Something like >> this > > No, EVENTHANDLER_INVOKE() acquires eventhandler internal locks. > Look at eventhandler_find_list() for details. Oh, but I guess you misunderstood me -- I didn't mean to say that eventhandler callbacks run with eventhandlers lock held, I meant to say that that it would be nice if EVENTHANDLER_INVOKE() could run lockless. This would have avoided some issues in special context (I recall I had some issues at work years ago, but they could have been predating the STOP_SCHEDULER() patch and in DDB). Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: local APIC error 0x40
On 31 Jul 2012, at 2:39 PM, John Baldwin wrote: > On Tuesday, July 24, 2012 9:32:45 pm Dan Allen wrote: >> >> $FreeBSD: src/sys/i386/i386/machdep.c,v 1.688.2.31 2012/06/13 15:25:52 jhb > So to be clear, does that revision work fine, it's a future revision that > breaks things, or does that revision break? The revision of 2012/06/13 works fine. It is later versions that are broken. (It is also broken in BSD 9.0 and later.) Dan ___ 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: Regression with jails/IPv6/pf
On Thu, 26 Jul 2012, Matthew Seaman wrote:
Hi,
as there have been more people having problems with pf and IPv6 after
the changes I am replying to stable@ cc: pf@.
...
[...]
nat on $ext_if_plus from $xenophobe_int to any -> $xenophobe_ext
rdr inet6 proto tcp from to $xenophobe_ext \
port { 22, 80, 443, 548, 4700 } -> $xenophobe_int
When trying to ssh into the jail with a kernel exhibiting this problem,
tcpdump showed that traffic was reaching the sshd in the jail and
responses were being generated, but they didn't make it out onto the net.
Any of you who are expereincing problems with packets dropped due to
invalid checksums with IPv6 and pf after the recent merges, can you
report back if you also see this without "modulate state" in your
pf.conf (if you have 'modulate' in there, can you try changing it to
'keep' and see if that fixes the problem)?
/bz
--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.
___
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: Regression with jails/IPv6/pf
On 01/08/2012 18:13, Bjoern A. Zeeb wrote: > Any of you who are expereincing problems with packets dropped due to > invalid checksums with IPv6 and pf after the recent merges, can you > report back if you also see this without "modulate state" in your > pf.conf (if you have 'modulate' in there, can you try changing it to > 'keep' and see if that fixes the problem)? Alas, I was already using 'keep state'. I did just try 'modulate state,' just on the off-chance but it makes no difference. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: Regression with jails/IPv6/pf
On Wed, 1 Aug 2012, Matthew Seaman wrote: On 01/08/2012 18:13, Bjoern A. Zeeb wrote: Any of you who are expereincing problems with packets dropped due to invalid checksums with IPv6 and pf after the recent merges, can you report back if you also see this without "modulate state" in your pf.conf (if you have 'modulate' in there, can you try changing it to 'keep' and see if that fixes the problem)? Alas, I was already using 'keep state'. I did just try 'modulate state,' just on the off-chance but it makes no difference. Modulate would only make it worse. -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: local APIC error 0x40
On Wednesday, August 01, 2012 11:41:39 am Dan Allen wrote: > > On 31 Jul 2012, at 2:39 PM, John Baldwin wrote: > > > On Tuesday, July 24, 2012 9:32:45 pm Dan Allen wrote: > >> > >> $FreeBSD: src/sys/i386/i386/machdep.c,v 1.688.2.31 2012/06/13 15:25:52 jhb > > > So to be clear, does that revision work fine, it's a future revision that > > breaks things, or does that revision break? > > The revision of 2012/06/13 works fine. It is later versions that are broken. (It is also broken in BSD 9.0 and later.) Can you use a binary search on the date to narrow down which commit breaks it? -- John Baldwin ___ 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: local APIC error 0x40
On Aug 1, 2012, at 10:06 AM, John Baldwin wrote: > Can you use a binary search on the date to narrow down which commit breaks it? Sadly, I cannot. I upgraded the machine to RELENG_9. The powerd demon appears to control the fan okay now. However I still must use the apic hint in loader.conf to turn off my 2nd core or else I get flooded with that "0x40" error message. Today running in 9.1 PRERELEASE I have a quiet fan, only one core, and I have got a "stray irc7" message a couple of times. This is all on my Core Duo Toshiba Satellite U205. Meanwhile, on a Pentium 4 and a tiny Dell Mini 10 Inspiron with an Intel Atom chip, everything is fine with RELENG_9. It is just this Toshiba, which ran perfectly for years with FreeBSD 6, 7, but things have declined with 8.0 and later. Dan ___ 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: [stable 9] panic on reboot: ipmi_wd_event()
On Wed, 2012-08-01 at 05:53 -0700, John Baldwin wrote:
> Index: vfs_subr.c
> ===
> --- vfs_subr.c (revision 238969)
> +++ vfs_subr.c (working copy)
> @@ -1868,8 +1868,11 @@ sched_sync(void)
> continue;
> }
>
> - if (first_printf == 0)
> + if (first_printf == 0) {
> + mtx_unlock(&sync_mtx);
> wdog_kern_pat(WD_LASTVAL);
> + mtx_lock(&sync_mtx);
> + }
>
> }
> if (!LIST_EMPTY(gslp)) {
>
>
> --
> John Baldwin
This definitely makes the panic go away on reboot.
Sean
___
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: Broadcom NetXtreme bcm5720 in the 9.1 beta
Sean Bruno wrote in <1343243969.2727.2.ca...@powernoodle.corp.yahoo.com>: se> On Tue, 2012-07-24 at 18:46 -0700, Hiroki Sato wrote: se> > Peter Feger wrote se> > in : se> > se> > ma> I just got done installing FreeBSD-9.0 on a Dell R720. I can tell you se> > ma> that none of the broadcom products will work. There is no driver that se> > ma> I have been able to find. I wound up having to replace them with se> > ma> Intel nics. I used the i350 quad-port 1G and the x520 for 10G Fiber. se> > se> > I recently bought a Dell R420 which had BCM 5720 as the LOM. The se> > output of pciconf was the following: se> > se> > bge0@pci0:2:0:0:class=0x02 card=0x04f81028 chip=0x165f14e4 rev=0x00 hdr=0x00 se> > vendor = 'Broadcom Corporation' se> > device = 'NetXtreme BCM5720 Gigabit Ethernet PCIe' se> > class = network se> > subclass = ethernet se> > se> > On 9.1-PRERELEASE as of Jul 23, it was recognized but did not work se> > properly first (the link-status went back and forth between up and se> > down). However, after setting dev.bge.0.msi=0 it worked. I am not se> > sure of whether it had decent communication speed or not, but I saw se> > it worked with 50MB/s or so at least. se> > se> > IPMI over LAN did not work even if hw.bge.allow_asf was set to 1. se> > se> > -- Hiroki se> se> se> se> For the r420/320 ... grab Pyun's latest updates and give it a whirl. se> They seem to work for us at yahoo: se> se> http://people.freebsd.org/~yongari/bge/ Thanks! I am testing his patches... -- Hiroki pgpCoLNDhH26O.pgp Description: PGP signature
base kerberos
Hi. I don't see kgetcred binary, but looks like Heimdal version should have it (or it will lack some functionality) plus I see it in the source tree... Do I miss something ? Thanks. Eugene. ___ 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"
