FreeBSD Status Report July-September, 2011
FreeBSD Quarterly Status Report - Q3/2011 Introduction This report covers FreeBSD-related projects between July and September 2011. It is the third of the four reports planned for 2011. This quarter was mainly devoted to polishing the bits for the next major version of FreeBSD, 9.0, which is to be released by then end of this year. Thanks to all the reporters for the excellent work! This report contains 28 entries and we hope you enjoy reading it. Please note that the deadline for submissions covering the period between October and December 2011 is January 15th, 2012. __ Projects * GELI status update * HAST (Highly Available Storage) status update * pfSense * Tool for providing FreeBSD VM Images * ZFSguru * ZRouter.org project -- a FreeBSD-based firmware for embedded devices FreeBSD Team Reports * Ports Collection * The FreeBSD Foundation * The FreeBSD Release Engineering Team Network Infrastructure * 802.11n / atheros * DIstributed Firewall and Flow-shaper Using Statistical Evidence (DIFFUSE) * Ethernet Switch Framework Kernel * The new CARP * VM layer for allocations larger than a page Documentation * Doc sprint on IRC, September 5, 2011 * The FreeBSD German Documentation Project Status Report * The FreeBSD Greek Documentation Project * The FreeBSD Japanese Documentation Project Architectures * FreeBSD/arm on Marvell Armada XP * FreeBSD/powerpc on AppliedMicro APM86290 Ports * FreeBSD Haskell Ports * KDE-FreeBSD * OpenAFS port * Portmaster Miscellaneous * bsd_day(2011) * EuroBSDcon 2011 * FreeBSD Developer Summit, Maarssen Google Summer of Code * Multibyte Encoding Support in Nvi __ 802.11n / atheros URL: http://wiki.FreeBSD.org/AdrianChadd/AtherosTxAgg Contact: Adrian Chadd AR5416, AR9160, and AR9280 functions in both station and hostap mode. Performance is good. Software retry of frames is implemented. Aggregation is implemented. BAR TX is not yet handled. HT protection is not implemented; neither is MIMO powersave. Open tasks: 1. BAR TX 2. MIMO powersave 3. Correct handling of flushing TX queues during interface reset/reconfigure 4. Correct handling of 20<->20/40mhz transitions (without dropping frames) 5. More intelligent rate control __ bsd_day(2011) URL: http://bsdday.eu/2011 Contact: Martin Matuska Contact: Gabor Pali The purpose of this one-day event was to gather Central European developers of today's open-source BSD systems to popularize their work and their organizations, and to meet each other in the real life. We wanted to motivate potential future developers and users, especially undergraduate university students, to work with BSD systems. This year's BSD-Day was be held in Bratislava, Slovakia at Slovak University of Technology, Faculty of Electrical Engineering and Information Technology on November 5, 2011. __ DIstributed Firewall and Flow-shaper Using Statistical Evidence (DIFFUSE) URL: http://caia.swin.edu.au/freebsd/diffused/ URL: http://www.FreeBSDFoundation.org/project%20announcements.shtml#diffuse URL: http://caia.swin.edu.au/urp/diffuse/ URL: http://caia.swin.edu.au/urp/diffuse/downloads.html Contact: Sebastian Zander Contact: Lawrence Stewart Contact: Grenville Armitage DIFFUSE enables FreeBSD's IPFW firewall subsystem to classify IP traffic based on statistical traffic properties. With DIFFUSE, IPFW computes statistics (such as packet lengths or inter-packet time intervals) for observed flows, and uses ML (machine learning) to classify flows into classes. In addition to traditional packet inspection rules, IPFW rules may now also be expressed in terms of traffic statistics or classes identified by ML classification. This can be helpful when direct packet inspection is problematic (perhaps for administrative reasons, or because port numbers do not reliably identify applications). DIFFUSE also enables one instance of IPFW to send flow information and classes to other IPFW instances, which then can act on such traffic (e.g. prioritise, accept, deny, etc.) according to its class. This allows for distributed architectures, where classification at one location in your network is used to control fire-walling or rate-shaping actions at other locations. The FreeBSD Foundation has funded the Centre for Advanced Internet Architectures at Swinburne University of Technology to undertake the DIFFUSED (DIFFUSE for freebsD) project,
Re: BUG: 'glabel label' name's lenght, is truncated without err/warn
* Lucas Holt , 2005 15:24:
> --- src/sbin/geom/class/label/geom_label.c2008/11/21 21:05:31 1.3
> +++ src/sbin/geom/class/label/geom_label.c2011/11/05 14:15:23 1.4
> @@ -118,6 +118,12 @@ label_label(struct gctl_req *req)
> return;
> }
>
> + label = gctl_get_ascii(req, "arg0");
> + if (strlen(label) > 15) {
> + gctl_error(req, "Label cannot exceed 15 characters");
> + return;
> + }
> +
> /*
>* Clear last sector first to spoil all components if device exists.
>*/
> @@ -131,7 +137,6 @@ label_label(struct gctl_req *req)
>
> strlcpy(md.md_magic, G_LABEL_MAGIC, sizeof(md.md_magic));
> md.md_version = G_LABEL_VERSION;
> - label = gctl_get_ascii(req, "arg0");
> strlcpy(md.md_label, label, sizeof(md.md_label));
> md.md_provsize = g_get_mediasize(name);
> if (md.md_provsize == 0) {
Why not simply perform the strlcpy and check whether
if (strlcpy(...) >= sizeof(md.md_label)
?
--
Ed Schouten
WWW: http://80386.nl/
pgpiTKtTnUUyN.pgp
Description: PGP signature
Re: incorrect parent refcounting in subr_firmware.c?
On Wednesday, November 02, 2011 3:56:29 pm Navdeep Parhar wrote:
> I built a KLD with multiple firmware images, as shown here:
>
> KMOD=foo
> FIRMWS= foo.bin:foo:1.0.0.0
> FIRMWS+=bar.bin:bar:1.0.0.0
> FIRMWS+= ...
> .include
>
> "foo" is the parent firmware and a firmware_get(foo) can autoload the
> KLD. "bar" and the rest are available only if the KLD is loaded (by
> whatever means). This is reasonable and works as expected. But if I
> just get and then put "foo" back, the KLD is not unloaded automatically.
>
> The problem is that a reference is placed on the parent firmware when
> the other firmwares are registered (during module load). I think this
> reference should be placed during firmware_get on the child.
>
> What do people think about the attached patch? It fixes things for me.
Hmm, what about the use case where a driver does:
f = firmware_get("foo");
firmware_put(f)
f = firmware_get("bar");
firmware_put(f)
Is that going to trigger multiple loads/unloads with this change?
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Panic in 8.1 in softclock(): mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185
On Sunday, November 06, 2011 6:49:43 pm Vijay Singh wrote: > Hackers. I am hitting a panic on 8.1 in the softclock() code. Anyone seen this? > > PANIC : mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185 > > (kgdb-amd64-6.8-71) bt > #0 breakpoint () at ./machine/cpufunc.h:64 > #1 0x803d8b82 in kdb_enter (why=0x806ca339 "panic", > msg=0x806ca339 "panic") at ../../../../sys/kern/subr_kdb.c:365 > #2 0x8039adf0 in panic (fmt=0x806c82d3 "mutex %s not > owned at %s:%d") at ../../../../sys/kern/kern_shutdown.c:950 > #3 0x80386b2e in _mtx_assert (m=0x80c8ed40, what=20, > file=0x806c7d18 "../../../../sys/kern/kern_mutex.c", line=185) > at ../../../../sys/kern/kern_mutex.c:827 > #4 0x8038528e in unlock_mtx (lock=0x80c8ed40) at > ../../../../sys/kern/kern_mutex.c:185 > #5 0x803b73e6 in softclock (arg=0x80c90f40) at > ../../../../sys/kern/kern_timeout.c:461 > #6 0x8036436c in intr_event_execute_handlers > (p=0xff000413a000, ie=0xff000414ad00) at > ../../../../sys/kern/kern_intr.c:1244 > #7 0x80364443 in ithread_execute_handlers > (p=0xff000413a000, ie=0xff000414ad00) at > ../../../../sys/kern/kern_intr.c:1257 > #8 0x8036469f in ithread_loop (arg=0xff00021e92e0) at > ../../../../sys/kern/kern_intr.c:1342 > #9 0x80361d06 in fork_exit (callout=0x80364590 > , arg=0xff00021e92e0, frame=0xff80001e7c80) at > ../../../../sys/kern/kern_fork.c:892 > #10 > > (kgdb-amd64-6.8-71) f 5 > #5 0x803b73e6 in softclock (arg=0x80c90f40) at > ../../../../sys/kern/kern_timeout.c:461 > 461 class->lc_unlock(c_lock); > (kgdb-amd64-6.8-71) l > 456 lastfunc = c_func; > 457 } > 458 #endif > 459 CTR1(KTR_CALLOUT, "callout %p > finished", c); > 460 if ((c_flags & CALLOUT_RETURNUNLOCKED) > == 0) > 461 class->lc_unlock(c_lock); > 462 skip: > 463 CC_LOCK(cc); > 464 /* > 465* If the current callout is locally > (kgdb-amd64-6.8-71) i local > c_func = (void (*)(void *)) 0x8060d550 You'll need to see if there is a way that this routine can drop the lock. If you can reproduce this panic easily, then perhaps try building with KTR and KTR_LOCK traces enabled and use 'show ktr' in ddb to see when this thread dropped Giant. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: BUG: 'glabel label' name's lenght, is truncated without err/warn
Hi Andrew, * Andrew Duane , 2008 16:22: > Checking the return code of strlcpy won't say if the entire string fit > (exactly) correctly, or if it was truncated. It seems they do: RETURN VALUES The strlcpy() and strlcat() functions return the total length of the string they tried to create. For strlcpy() that means the length of src. For strlcat() that means the initial length of dst plus the length of src. While this may seem somewhat confusing, it was done to make trunca‐ tion detection simple. -- Ed Schouten WWW: http://80386.nl/ pgp3k0xKTMyC1.pgp Description: PGP signature
RE: BUG: 'glabel label' name's lenght, is truncated without err/warn
Checking the return code of strlcpy won't say if the entire string fit
(exactly) correctly, or if it was truncated. I think explicitly checking the
length of label first is cleaner and more correct.
I would, however, replace "15" with "sizeof(md.md_label) - 1" both in the check
and the printf.
...
Andrew Duane
Juniper Networks
o +1 978 589 0551
m +1 603-770-7088
adu...@juniper.net
> -Original Message-
> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> hack...@freebsd.org] On Behalf Of Ed Schouten
> Sent: Tuesday, November 08, 2011 6:34 AM
> To: Lucas Holt
> Cc: rank1see...@gmail.com; hack...@freebsd.org
> Subject: Re: BUG: 'glabel label' name's lenght, is truncated without
> err/warn
>
> * Lucas Holt , 2005 15:24:
> > --- src/sbin/geom/class/label/geom_label.c 2008/11/21 21:05:31
> 1.3
> > +++ src/sbin/geom/class/label/geom_label.c 2011/11/05 14:15:23
> 1.4
> > @@ -118,6 +118,12 @@ label_label(struct gctl_req *req)
> > return;
> > }
> >
> > + label = gctl_get_ascii(req, "arg0");
> > + if (strlen(label) > 15) {
> > + gctl_error(req, "Label cannot exceed 15 characters");
> > + return;
> > + }
> > +
> > /*
> > * Clear last sector first to spoil all components if device
> exists.
> > */
> > @@ -131,7 +137,6 @@ label_label(struct gctl_req *req)
> >
> > strlcpy(md.md_magic, G_LABEL_MAGIC, sizeof(md.md_magic));
> > md.md_version = G_LABEL_VERSION;
> > - label = gctl_get_ascii(req, "arg0");
> > strlcpy(md.md_label, label, sizeof(md.md_label));
> > md.md_provsize = g_get_mediasize(name);
> > if (md.md_provsize == 0) {
>
> Why not simply perform the strlcpy and check whether
>
> if (strlcpy(...) >= sizeof(md.md_label)
>
> ?
>
> --
> Ed Schouten
> WWW: http://80386.nl/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
USB FS
Hi, I am trying to write a program that makes use of the USB_FS ioctl calls to achieve it's functionality. Unfortunately I am encountering some difficulties with these ioctl calls and am not exactly sure which call is supposed to do what. Does anyone know of some resource which could help me understand these calls better ? Regards, Daniel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: USB FS
On Tuesday 08 November 2011 17:24:33 Daniel Grech wrote: > Hi, > > I am trying to write a program that makes use of the USB_FS ioctl calls to > achieve it's functionality. Unfortunately I am encountering some > difficulties with these ioctl calls and am not exactly sure which call is > supposed to do what. Does anyone know of some resource which could help me > understand these calls better ? > Hi, You can look at the VirtualBox and libusb sources for examples. I recommend to use libusb and not the USB_FS inteface directly. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: incorrect parent refcounting in subr_firmware.c?
On Tue, Nov 08, 2011 at 10:00:27AM -0500, John Baldwin wrote:
> On Wednesday, November 02, 2011 3:56:29 pm Navdeep Parhar wrote:
> > I built a KLD with multiple firmware images, as shown here:
> >
> > KMOD=foo
> > FIRMWS= foo.bin:foo:1.0.0.0
> > FIRMWS+=bar.bin:bar:1.0.0.0
> > FIRMWS+= ...
> > .include
> >
> > "foo" is the parent firmware and a firmware_get(foo) can autoload the
> > KLD. "bar" and the rest are available only if the KLD is loaded (by
> > whatever means). This is reasonable and works as expected. But if I
> > just get and then put "foo" back, the KLD is not unloaded automatically.
> >
> > The problem is that a reference is placed on the parent firmware when
> > the other firmwares are registered (during module load). I think this
> > reference should be placed during firmware_get on the child.
> >
> > What do people think about the attached patch? It fixes things for me.
>
> Hmm, what about the use case where a driver does:
>
> f = firmware_get("foo");
> firmware_put(f)
> f = firmware_get("bar");
> firmware_put(f)
>
> Is that going to trigger multiple loads/unloads with this change?
Without the patch, the get(bar) always works. But that's because the
KLD is stuck in memory (it's not auto-unloaded even after the two puts
and it can't be unloaded manually either).
With the patch, get(bar) does not work after put(foo, FIRMWARE_UNLOAD).
This is correct behaviour as documented in firmware(9) - the parent
firmware is the only one that the kernel can locate with a simple name
match. Once the KLD is unloaded, the kernel can't find bar. (The get
would probably work after a put(foo, 0) because the KLD won't get
unloaded without a FW_UNLOAD. But I'm not interested in keeping it
around forever so I always specify FW_UNLOAD).
As long as I put all the images back this way, the KLD is auto-unloaded
at the end. Without the patch it just stays around forever.
get(foo) /* autoloads foo.ko which has the "bar" image too. */
get(bar)
put(bar, FIRMWARE_UNLOAD)
put(foo, FIRMWARE_UNLOAD) /* KLD auto-unloaded, user happy. */
Regards,
Navdeep
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kexec or similar for FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/6/11 6:23 AM, Andriy Gapon wrote: > on 24/10/2011 20:55 Russell Cattelan said the following: >> So it has been a while and a lot of hair pulling but kload is >> sorta alive and kicking. It can now load the kernel from >> userspace, copy it over the running kernel and jump the the >> kernel entry point. >> >> I'm still having problems getting through the boot process due >> to interrupts arriving for unconfigured handlers. Fatal Trap >> (30) > > Just in case, is your original kernel running SMP? > I'm working on the SMP stuff now. Trying to get the processors in a state where the restart process can complete. For now I removed the panic call in the unknown interrupt case. What I finally figured out was that starting up the system was overwriting the page tables and caused any of AP's still looking at those locations to cause qemu / kvm to reset :-( - -Russell -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk65m7gACgkQNRmM+OaGhBjkaQCfS4rfmuKAyyPWyseEYJaHbq+G h1sAnjPgX2E6x7CEcvN11iR3qtJAfdPA =OgIO -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: incorrect parent refcounting in subr_firmware.c?
On Tuesday, November 08, 2011 3:47:00 pm Navdeep Parhar wrote:
> On Tue, Nov 08, 2011 at 10:00:27AM -0500, John Baldwin wrote:
> > On Wednesday, November 02, 2011 3:56:29 pm Navdeep Parhar wrote:
> > > I built a KLD with multiple firmware images, as shown here:
> > >
> > > KMOD=foo
> > > FIRMWS= foo.bin:foo:1.0.0.0
> > > FIRMWS+=bar.bin:bar:1.0.0.0
> > > FIRMWS+= ...
> > > .include
> > >
> > > "foo" is the parent firmware and a firmware_get(foo) can autoload the
> > > KLD. "bar" and the rest are available only if the KLD is loaded (by
> > > whatever means). This is reasonable and works as expected. But if I
> > > just get and then put "foo" back, the KLD is not unloaded automatically.
> > >
> > > The problem is that a reference is placed on the parent firmware when
> > > the other firmwares are registered (during module load). I think this
> > > reference should be placed during firmware_get on the child.
> > >
> > > What do people think about the attached patch? It fixes things for me.
> >
> > Hmm, what about the use case where a driver does:
> >
> > f = firmware_get("foo");
> > firmware_put(f)
> > f = firmware_get("bar");
> > firmware_put(f)
> >
> > Is that going to trigger multiple loads/unloads with this change?
>
> Without the patch, the get(bar) always works. But that's because the
> KLD is stuck in memory (it's not auto-unloaded even after the two puts
> and it can't be unloaded manually either).
>
> With the patch, get(bar) does not work after put(foo, FIRMWARE_UNLOAD).
> This is correct behaviour as documented in firmware(9) - the parent
> firmware is the only one that the kernel can locate with a simple name
> match. Once the KLD is unloaded, the kernel can't find bar. (The get
> would probably work after a put(foo, 0) because the KLD won't get
> unloaded without a FW_UNLOAD. But I'm not interested in keeping it
> around forever so I always specify FW_UNLOAD).
>
> As long as I put all the images back this way, the KLD is auto-unloaded
> at the end. Without the patch it just stays around forever.
>
> get(foo) /* autoloads foo.ko which has the "bar" image too. */
> get(bar)
> put(bar, FIRMWARE_UNLOAD)
> put(foo, FIRMWARE_UNLOAD) /* KLD auto-unloaded, user happy. */
Ahh, ok. I think this is fine. It might be worth updating the manpage to
explicitly mention child firmware images and to explain this requirement
(right now it doesn't mention extra firmware images at all).
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: "ps -e" without procfs(5)
On Sun, 6 Nov 2011 20:10:41 +0200 Kostik Belousov wrote: KB> On Sat, Nov 05, 2011 at 10:37:46PM +0200, Mikolaj Golub wrote: >> >> http://people.freebsd.org/~trociny/env.sys.3.patch KB> Oops, I missed this in the previous review. You cannot use fubyte in KB> proc_read_mem(). fubyte reads a byte from the address space of the current KB> process. The fix is easy, use proc_rwmem for 1 byte. KB> I do not think that fall back to single byte read is warranted for KB> proc_read_mem calls e.g. for ps_strings. Add a flag to indicate whether KB> the proc_read_mem should fall back to byte read ? KB> I would prefer using sizeof(uint64_t) and sizeof(uint32_t) instead of 8 KB> and 4 constants in the align checks. KB> Might be, add PROC_ASSERT_HELD() to get_ps_string() ? KB> procfs patch looks good. Thanks. The updated version: http://people.freebsd.org/~trociny/env.sys.4.patch Investigating cases when EFAULT was returned and if the fallback was successful I noticed that most of the cases were when p->p_comm changed during the read, so the process was in exec in that time. In order to avoid this error I added a check for P_INEXEC flag. After this I observed EFAULT (very rarely) only when reading arg or env strings and fallback was successful for those cases. So I modified the patch to do fallback only when reading strings (as it was in one of my earlier versions but with wrong fubyte), and returned your comment which explains why it may happen :-) Also in the procfs patch I have added the check for process state. The userland part has not been changed since my first report: http://people.freebsd.org/~trociny/env.user.patch -- Mikolaj Golub ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kexec or similar for FreeBSD
on 08/11/2011 23:14 Russell Cattelan said the following: > On 11/6/11 6:23 AM, Andriy Gapon wrote: >> on 24/10/2011 20:55 Russell Cattelan said the following: >>> So it has been a while and a lot of hair pulling but kload is sorta >>> alive and kicking. It can now load the kernel from userspace, copy it >>> over the running kernel and jump the the kernel entry point. >>> >>> I'm still having problems getting through the boot process due to >>> interrupts arriving for unconfigured handlers. Fatal Trap (30) > >> Just in case, is your original kernel running SMP? > > I'm working on the SMP stuff now. Trying to get the processors in a state > where the restart process can complete. > > For now I removed the panic call in the unknown interrupt case. > > > What I finally figured out was that starting up the system was overwriting > the page tables and caused any of AP's still looking at those locations to > cause qemu / kvm to reset :-( Very interesting. You might also find the following information useful in case you haven't implemented that yet: http://www.intel.com/design/pentium/datashts/242016.htm specifically the Appendix B.5. That is something that we are not doing right now, but what I would prefer us doing even for a "normal" warm reboot. Namely: In order to do a complete system shutdown, followed by a warm restart if necessary, the operating system should return the system to a state similar to that at power-on. This includes disabling the Local APIC interrupts (LINT0/LINT1/Local APIC Timer/Error interrupt) on all processors, disabling the Local APIC on all APs and disabling all interrupts at all the I/O APICs in the system. I believe that this could be a reason for the spurious interrupts that you get. BTW, I am not completely sure, but it seems that we never disable the timer interrupt(s) during shutdown (unlike interrupts for all/most of other devices). You might also find OpenSolaris code interesting in this respect: http://fxr.watson.org/fxr/source/i86pc/io/pcplusmp/apic_common.c?v=OPENSOLARIS#L1160 http://fxr.watson.org/fxr/source/i86pc/os/machdep.c?v=OPENSOLARIS#L191 All the best! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kexec or similar for FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/8/11 4:10 PM, Andriy Gapon wrote: > on 08/11/2011 23:14 Russell Cattelan said the following: >> On 11/6/11 6:23 AM, Andriy Gapon wrote: >>> on 24/10/2011 20:55 Russell Cattelan said the following: So it has been a while and a lot of hair pulling but kload is sorta alive and kicking. It can now load the kernel from userspace, copy it over the running kernel and jump the the kernel entry point. I'm still having problems getting through the boot process due to interrupts arriving for unconfigured handlers. Fatal Trap (30) >> >>> Just in case, is your original kernel running SMP? >> >> I'm working on the SMP stuff now. Trying to get the processors in >> a state where the restart process can complete. >> >> For now I removed the panic call in the unknown interrupt case. >> >> >> What I finally figured out was that starting up the system was >> overwriting the page tables and caused any of AP's still looking >> at those locations to cause qemu / kvm to reset :-( > > Very interesting. You might also find the following information > useful in case you haven't implemented that yet: > http://www.intel.com/design/pentium/datashts/242016.htm > specifically the Appendix B.5. That is something that we are not > doing right now, but what I would prefer us doing even for a > "normal" warm reboot. > > Namely: In order to do a complete system shutdown, followed by a > warm restart if necessary, the operating system should return the > system to a state similar to that at power-on. This includes > disabling the Local APIC interrupts (LINT0/LINT1/Local APIC > Timer/Error interrupt) on all processors, disabling the Local APIC > on all APs and disabling all interrupts at all the I/O APICs in the > system. Ya I have been slowing figuring that out. I have added a simple routine to tear down the ioapic handlers which seems to be doing the right thing. I do not get the unhandled interrupt message now. Sending an IPI cpustop didn't quite do what I expected in that the cpu is not really stop but just "pause"ed. So what ended up happening was the cpus 1 + were still using the initial page table the from the first boot, cpu 0 has a different page table set up by the kload process. BUT when the boot process / cpu 0 started setting up the page tables again in the same memory cpu 1+ was still referencing for their page tables qemu / kvm would reset and reboot the VM. It took forever with lots of debug prints in both the kernel and qemu to finally put the pieces together. Changing the cpususpend routine to actually halt the cpu has finally allowed the boot process to actually work using kload on a multi cpu qemu vm. Unfortunately it appears that VirtualBox does not handle things the same and now panics when trying to start the AP's. I'm guessing it has to do with exactly what you are saying and that the local APICs need to be shutdown properly. The linux kexec processes that. > > I believe that this could be a reason for the spurious interrupts > that you get. BTW, I am not completely sure, but it seems that we > never disable the timer interrupt(s) during shutdown (unlike > interrupts for all/most of other devices). > > You might also find OpenSolaris code interesting in this respect: > http://fxr.watson.org/fxr/source/i86pc/io/pcplusmp/apic_common.c?v=OPENSOLARIS#L1160 > > http://fxr.watson.org/fxr/source/i86pc/os/machdep.c?v=OPENSOLARIS#L191 Ahh good idea ... I've been trying to make sense of the linux apic code to see how to duplicate the functionality but more examples are always helpful. > > All the best! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6566gACgkQNRmM+OaGhBikggCfZMob4rbk9SQT+YGXksilCmpA ZnIAnjXyEa2uTVhYNP3SHMCpvWBPxCoP =pDTQ -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Set mac address via ioctl
After reading ifconfig source code for hours, I end with this, witch was
suppose to change mac address via a command line:
#include
#include
#include
#include #include
#include
#include /* IP */
#include
#include
#include
#include #include
#include
#include
#include
#include
#include
#include
#include struct afswtch { const char *af_name; /* as given on
cmd line, e.g. "inet" */ short af_af; /* AF_* */ /* * Status
is handled one of two ways; if there is an * address associated with the
interface then the * associated address family af_status method is invoked *
with the appropriate addressin info. Otherwise, if * all possible info is to
be displayed and af_other_status * is defined then it is invoked after all
address status * is presented. */ void(*af_status)(int, const
struct ifaddrs *); void (*af_other_status)(int); /* parse address
method */ void(*af_getaddr)(const char *, int); /* parse prefix
method (IPv6) */ void (*af_getprefix)(const char *, int); void
(*af_postproc)(int s, const struct afswtch *); u_long
af_difaddr; /* set dst if address ioctl */ u_long af_aifaddr;
/* set if address ioctl */ void *af_ridreq; /* */ void
*af_addreq; /* */ struct afswtch*af_next; /* XXX doesn't fit model */
void
(*af_status_tunnel)(int); void (*af_settunnel)(int s, struct
addrinfo *srcres, struct addrinfo *dstres);
}; int
main(int argc, char **argv)
{ int s, error; structifreq ifr; //char name[IFNAMSIZ]; mac_t
label; if (mac_from_text(&label, argv[1]) == -1) { perror(argv[1]); return; }
ifr.ifr_addr.sa_family = AF_INET; if ((s = socket(ifr.ifr_addr.sa_family,
SOCK_DGRAM, 0)) < 0) err(1, "socket(family %u,SOCK_DGRAM",
ifr.ifr_addr.sa_family); memset(&ifr, 0, sizeof(ifr)); strncpy(ifr.ifr_name,
argv[2], sizeof(ifr.ifr_name)); ifr.ifr_ifru.ifru_data = (void *)label; error =
ioctl(s, SIOCSIFMAC, &ifr); mac_free(label); if (error == -1)
perror("setifmac"); return 0;
}
Now, if I try to change mac address of my card, I get this message:
./mactool dc0 00:10:22:33:44:77
mactool: socket(family 18,SOCK_DGRAM: Protocol not supported
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
