Re: panic after starting X with r238120
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08.07.2012 15:06, Konstantin Belousov wrote: You know, this is not much useful ? Backtrace is. Sorry, I forgot to mention that I had the same backtrace than Steve. I'll buildworld again (probably not today) and report back. - -- Jean-Sébastien Pédron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/6kY4ACgkQa+xGJsFYOlMvHgCeNW76VSjVkf4/on2LYFKGR5Bs R7UAoNYkQtmvpzlblqd3mudp57Kg2K22 =oIqg -END PGP SIGNATURE- ___ 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: Occassional permission denied in the middle of a large transfer over NFS
Hello again,
On Sun, Jul 08, 2012 at 06:35:50PM +0100, Vincent Hoffman wrote:
Replying to myself just as a record, I have tried nfse and I didnt get
the permission denied at all.
The only issue I had with it is that it strictly adheres to the syntax
in exports(5) while mountd is a little more flexible.
I had
/usr/local/export -alldirs -maproot=root 85.xx.xx.xx
/usr is the root of that filesystem
mountd - allowed this but actually silently exports /usr (and all dirs
below)
nfse - didnt allow this, it needed to be the correct
/usr -alldirs -maproot=root 85.xx.xx.xx
which is I guess a POLA violation but follows the documentation.
this was using nfse in mountd compatibility mode. I havent played with
its more advanced features.
The -alldirs option in the exports(5) file does not mean only
all directories.
Please read these lines from exports(5) DESCRIPTION:
The second is to specify the pathname of the root of the file system fol-
lowed by the -alldirs flag; this form allows the host(s) to mount at any
point within the file system, including regular files if the -r option is
used on mountd(8).
The -alldirs option specifies that this pathname must be the root (mount
point) of some file system.
And read these lines from EXAMPLES:
The file system rooted at /cdrom will be exported read-only to the entire
network 192.168.33.0/24, including all its subdirectories. Since /cdrom
is the conventional mountpoint for a CD-ROM device, this export will fail
if no CD-ROM medium is currently mounted there since that line would then
attempt to export a subdirectory of the root file system with the
-alldirs option which is not allowed. The -quiet option will then sup-
press the error message for this condition that would normally be sys-
logged. As soon as an actual CD-ROM is going to be mounted, mount(8)
will notify mountd(8) about this situation, and the /cdrom file system
will be exported as intended. Note that without using the -alldirs
option, the export would always succeed. While there is no CD-ROM medium
mounted under /cdrom, it would export the (normally empty) directory
/cdrom of the root file system instead.
Here -alldirs means that /cdrom should be a file system. As I remember
this even worked before revision 1.85 of mountd/mountd.c, then mountd.c
began to use nmount(2). Now if one puts /cdrom in /etc/exports and
there is no file system mounted on /cdrom, then the entire / will be
exported.
Just create /etc/exports with one line /cdrom -alldirs and try to
mount server:/ on another system, you will get access to the / of
the server.
The current version of mountd is not little more flexible, it does
not follow traditional -alldirs option's logic and does not follow
description of the -alldirs option in the exports(5) manual page, I guess
this is a POLA violation.
Now let's back to your example where /usr is the root of the file system:
/usr/local/export -alldirs -maproot=root 1.2.3.4
1. mountd exports /usr and all subdirectories under it for NFSv2/3 clients.
Actually it has to export /usr/local/export only and all subdirectories
under it only if /usr/local/export is or will be the root of some
file system.
2. nfse in the compatibility mode sees that there is the -alldirs option
and will export /usr/local/export and all subdirectories under it
only if /usr/local/exports is or will be the root of some file system.
If one runs nfse -Ct ... for this file then its output will be:
configure: reading file /etc/exports
configure: converting configuration to native format
Pathname /usr/local/export
Export specifications:
-rw -sec sys -maproot 0:0:5 -host 1.2.3.4
Subdirectories for NFSv2/3:
/usr/local/export
-alldirs -host 1.2.3.4
Warning: subdirectories exports are insecure
This is output in nfse native format. Using NFSE part in the kernel,
nfse verifies whether /usr/local/export is a mount point, whether file
system supports NFS, and only if everything is correct, it starts to
export it. When file system is unmounted or when another file system
is mounted, then NFSE part in the kernel is informed by EVENTHANDLERs
vfs_mount_event/vfs_unmount_event and NFS server verifies whether it
still can export this file system (it can be unmounted or it can be
shadowed). The userland utility nfse got information of VFS events
via kevents VQ_MOUNT/VQ_UNMOUNT and only the verifies using NFSE
part in the kernel whether some file system is still exported or can
become exported.
There is one implementation mistake when nfse -C ... is used. The
nfse utility follows implementation mistake from mountd and verifies
what is a file system and what is not a file system using the f_mntonname
field in the struct mount{}. This is wrong since parts of mount point
directory can be renamed and this is not reflected in the f_mntonname
value. That's why I do not
Re: Occassional permission denied in the middle of a large transfer over NFS
On Sun, Jul 08, 2012 at 07:48:11PM -0400, Rick Macklem wrote: Replying to myself just as a record, I have tried nfse and I didnt get the permission denied at all. The only issue I had with it is that it strictly adheres to the syntax in exports(5) while mountd is a little more flexible. I had /usr/local/export -alldirs -maproot=root 85.xx.xx.xx /usr is the root of that filesystem mountd - allowed this but actually silently exports /usr (and all dirs below) Not exactly correct. mountd exports the entire file system in the kernel for the NFS server, since exports can only be attached to the mount points in the kernel. However, when the client's mount protocol requests a mount file handle for anything other than /usr/local/export, it will refuse that. (Which means that to mount anything other than /usr/local/export, the client must maliciously guess the file handle for mounting.) Put another way, a non-malicious NFSv3 client will only be able to mount /usr/local/export. Robert Watson calls this an administrative control and feels that it is necessary. According to the exports(5) manual page and this example (/usr is the mount point and the -alldir option is given), this example means the following: export /usr/local/export only if it is or will be a mount point and administratively export all subdirectories under it for NFSv2/3 clients. Good description of the -alldirs option is given in the EXAMPLES section from exports(5) in paragraph about /cdrom -alldirs. ___ 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: Use of C99 extra long double math functions after r236148
Hi, On 9 Jul 2012, at 06:02, Steve Kargl wrote: If you're doing accouting, hopefully, you're using BCD. Would be nice, but it's far too slow for financial analysis; the chip designers go out of their way to provide fast floating point. Fortunately 53 bits is usually plenty with 2dp max. -- Bob Bishop r...@gid.co.uk ___ 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: Occassional permission denied in the middle of a large transfer over NFS
On 09/07/2012 02:08, Rick Macklem wrote: Vincent Hoffman: On 08/07/2012 00:26, Rick Macklem wrote: Vincent Hoffman wrote: Hi Rick, I'm afraid this didnt make any real difference for me. Since I couldnt test it on the live system I tried it on a test vm. on the vm (nfs server) I set a looping mount/umount while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; done and on the client I set a loop of tars of large directorys to the nfs mount running under time to see how well it survived. Then replicated the test with the patch and without. Just to confirm, you patched both the kernel and mountd and replaced both on the server? Also, I'm not sure how ZFS handles it's exports. I can't remember if you've tried an exported UFS volume. It might be something ZFS specific? rick Hi Rick, yes I patched both the kernel and mountd, rebuilt kernel and world (to be sure), added the -S flag to mountd in rc.conf and rebooted. This is a test VM running -CURRENT and is only exporting a ufs2 filesystem. (11:43:05 ~) 0 $ cat /etc/exports /usr/local/export -maproot=root -alldirs XX.XX.XX.XX Client is a 8.3-RELEASE box but I see the same with linux clients. (I can confirm that it works fine when I am not running the mount/umount loop) Oops, the patch I sent you worked for NFSv4 only. If you also apply the attached patch, it seems to work for NFSv3 as well. The patch is also at: http://people.freebsd.org/~rmacklem/atomic-export2.patch You must also run the new/experimental server. (I can't remember if I mentioned that before.) rick You did mention that :) Thanks I'll give this one a go. Vince The production system has been fine since I removed the SIGHUP call in mount.c so thanks for that suggestion. Vince [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt x nopatch.txt + atomicpatch.txt +--+ | * | | * | | x* | | xx* x | | +x** xx | | xxx x | | xxx +x+ + | | +*xx +x+ x + | | +*xx + + x | | *+*xx+ +++x * x x | | x**++*x+***x+ x*+ x ++*+ + x+ +x + + +| |||___M_M_A__A___|__| | +--+ N Min Max Median Avg Stddev x 101 1.25 106.8 14.08 21.892178 22.196005 + 101 1.21 186.93 18.46 27.995842 30.523218 No difference proven at 95.0% confidence (excuse wrapped ascii art) I think I'll have a look at the nfse patch set and see how that performs. Thanks for all your work on NFS on FreeBSD. Vince Also, you could easily hack mount.c so that it doesn't send a SIGHUP to mountd (which causes the exports to be reloaded) every time a local fs is mounted. True and I may have to do that for the production NAS for the time being. Thanks for looking at this. Vince rick thanks, Vince ___ 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 ___ 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 ___ 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: side note on the X220 running CURRENT: head phone jack works
Hi, On Friday, July 06, 2012 03:24:34 AM Kevin Oberman wrote: On Wed, Jul 4, 2012 at 8:49 PM, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: Hi, there have been some people here - including me - wondering whether the head phone jack works. Yes, it does. I just have had the chance to connect the head phone jack. It works when vlc is set to use /dev/dsp1.0. Using /dev/dsp0.1 brings sound to the built-in speakers. The proper fix is to add the following to /boot/loader.conf: it is the general way as it should work with all applications. # Out : speaker + headphones hint.hdac.0.cad0.nid25.config=as=1 seq=15 # In : mic + external mic hint.hdac.0.cad0.nid35.config=as=2 hint.hdac.0.cad0.nid27.config=as=2 seq=15 I added this to the loader.conf file and will test when I will get my hands on the equipment. Thanks! Erich ___ 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
ifconfig create breaks between r238227 - r238290?
Just finished updating from r238227 to r238290 on the head slice of my laptop, and was unable to make use of the wlan(4) NIC; I captured the following via cut/paste from ttyv0: ... Setting hostname: localhost. Starting dhclient. em0: no link .. giving up /etc/rc.d/dhclient: WARNING: failed to start dhclient Starting wpa_supplicant. ioctl[SIOCG80211, op 98, len 32]: Invalid argument /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant Starting dhclient. dhclient: /etc/dhclient-enter-hooks invoked with reason PREINIT dhclient: Setting hostname from localhost to null string ifconfig: ioctl (SIOCAIFADDR): Invalid argument dhclient: /etc/dhclient-exit-hooks invoked with reason PREINIT dhclient: reason was PREINIT; no action taken dhclient: Exiting /etc/dhclient-exit-hooks (PREINIT) with exit_status 0 wlan0: not found exiting. /etc/rc.d/dhclient: WARNING: failed to start dhclient Starting Network: lo0 em0 iwn0 fwe0 fwip0. lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=63RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff00 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=4219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL _MAGIC,VLAN_HWTSO ether 00:24:e8:9c:11:0f nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect status: no carrier iwn0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:21:6a:26:34:c0 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier fwe0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 4a:4f:c0:37:06:01 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL ch 1 dma -1 fwip0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 lladdr 4a.4f.c0.0.10.37.6.1.a.2.ff.fe.0.0.0.0 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL Starting devd. ifconfig: create: bad value Starting wpa_supplicant. ioctl[SIOCG80211, op 98, len 32]: Invalid argument /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant Starting dhclient. dhclient: /etc/dhclient-enter-hooks invoked with reason PREINIT dhclient: Leaving hostname set to ifconfig: ioctl (SIOCAIFADDR): Invalid argument dhclient: /etc/dhclient-exit-hooks invoked with reason PREINIT dhclient: reason was PREINIT; no action taken dhclient: Exiting /etc/dhclient-exit-hooks (PREINIT) with exit_status 0 wlan0: not found exiting. /etc/rc.d/dhclient: WARNING: failed to start dhclient Starting Network: iwn0. iwn0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:21:6a:26:34:c0 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ifconfig: create: bad value Starting wpa_supplicant. ioctl[SIOCG80211, op 98, len 32]: Invalid argument /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant Yesterday, I had updated to: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #614 238227M: Sun Jul 8 06:47:51 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 and things seemed OK -- I was certainly able to use the NIC. :-} uname output from this morning: FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #615 238290M: Mon Jul 9 05:39:15 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 I glanced through the list of commits to head in that range, but didn't note anything glaringly obvious (yet). I hadn't tried a wired NIC on the laptop; I can, if there's anything likely to be of value in doing so. I've attached a copy of the associated dmesg.boot. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. Copyright (c) 1992-2012 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 10.0-CURRENT #615 238290M: Mon Jul 9 05:39:15 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: MEMGUARD map base: 0xc840 MEMGUARD map limit: 0xcad34000 MEMGUARD map size: 42192 KBytes CPU: Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz (2793.07-MHz 686-class CPU) Origin = GenuineIntel Id = 0x10676
Re: Interfacing devices with multiple parents within newbus
On Friday, July 06, 2012 4:45:55 pm Arnaud Lacombe wrote: Hi, On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore free...@damnhippie.dyndns.org wrote: On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: Hi, On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe lacom...@gmail.com wrote: That's neither correct nor robust in a couple of way: 1) you have no guarantee a device unit will always give you the same resource. this raises the following question: how can a device, today, figure out which parent in a given devclass would give it access to resources it needs. Say, you have gpiobus0 provided by a superio and gpiobus1 provided by the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 attachment is conditional to some BIOS setting. How can you tell gpioled(4) to attach on the chipset provided GPIO without hardcoding unit number either way ? AFAIK, you can not. Even hints provided layout description is defeated. Each device in a given devclass need to have a set of unique attribute to allow a child to distinguish it from other potential parent in the same devclass... - Arnaud Talking about a child being unable to choose the correct parent seems to indicate that this whole problem is turned upside-down somehow; children don't choose their parents. actually, I think I was wrong, I thought device were attached to a devclass, but they are truly attached to a given device. My mistake. Just blue-sky dreaming here on the fly... what we really have is a resource-management problem. A device comes along that needs a GPIO resource, how does it find and use that resource? Well, we have a resource manager, could that help somehow? Could a driver that provides access to GPIO somehow register its availability so that another driver can find and access it? The resource may be a callable interface, it doesn't really matter, I'm just wondering if the current rman stuff could be leveraged to help make the connection between unrelated devices. I think that implies that there would have to be something near the root of the hiearchy willing to be the owner/manager of dynamic resources. AFAIR, rman is mostly there to manage memory vs. i/o mapped resources. The more I think about it, the more FTD is the answer. The open question now being how to map a flexible device structure (FTD) to a less flexible structure (Newbus) :/ Note that IRQs are also managed in rman. However, that is a complicated beast. Generally there is some sideband way for interrupt controllers to register their available interrupt pins with the platform's nexus driver (often the actual PIC is not managed via new-bus). You then need something else to let a given device know which interrupt pin it wants (e.g. PCI interrupt routing). However, you could make a similar approach work for GPIO perhaps, where devices make GPIO pins available to a rman that other devices then allocate from. -- John Baldwin ___ 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: sleeping thread panic?
On Sunday, July 08, 2012 9:46:09 am Michael Butler wrote: On 07/08/12 09:34, Konstantin Belousov wrote: On Sun, Jul 08, 2012 at 08:46:32AM -0400, Michael Butler wrote: Sorry, no symbols but this happened twice last night while being the target of a dump over NFS .. root@mail:/var/crash # less info.0 Dump header from device /dev/ada0s1 Architecture: i386 Architecture Version: 2 Dump Length: 252809216B (241 MB) Blocksize: 512 Dumptime: Sun Jul 8 00:21:23 2012 Hostname: mail.auburn.protected-networks.net Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.0-CURRENT #87: Sat Jul 7 22:39:55 EDT 2012 r...@mail.auburn.protected-networks.net:/usr/obj/usr/src/sys/AUBURN Panic String: sleeping thread Dump Parity: 2996346376 Bounds: 0 Dump Status: good (kgdb) bt #0 0xc07530cd in doadump () #1 0xc0753656 in kern_reboot () #2 0xc0753cfc in panic () #3 0xc079a34e in propagate_priority () #4 0xc079b5e4 in turnstile_wait () #5 0xc073ea71 in _mtx_lock_sleep () #6 0xc09c4772 in vm_page_unwire () #7 0xc07db039 in vfs_vmio_release () #8 0xc07dd476 in getnewbuf () #9 0xc07de50b in getblk () #10 0xc0966d99 in ffs_balloc_ufs2 () #11 0xc099281e in ffs_write () #12 0xc0a38b05 in VOP_WRITE_APV () #13 0xc068a65e in nfsvno_write () #14 0xc06882e7 in nfsrvd_write () #15 0xc066ea05 in nfsrvd_dorpc () #16 0xc067d42f in nfssvc_program () #17 0xc09356e2 in svc_run_internal () #18 0xc0935b70 in svc_thread_start () #19 0xc07204fb in fork_exit () #20 0xc09fe7a4 in fork_trampoline () You need to provide: 1. exact version of your kernel sources This is the CVS equivalent of SVN r238221 2. complete panic message. There should be backtrace of the 'sleeping thread', not the paniced thread, right after the panic message. Sorry, that is the entire info file - nothing more than I've posted is logged, For future reference, you can look at the core.txt.0 file generated by crashinfo. It should contain the dmesg near the bottom and you could have gotten the stack trace of the broken thread from that. -- John Baldwin ___ 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: newbus' ivar's limitation..
On Monday, July 09, 2012 12:39:03 am Warner Losh wrote:
On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:
Hi,
On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh i...@bsdimp.com wrote:
On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.
There's one pointer for the ivars. The bus code gets to determine what
the ivar looks like, because the interface is totally private to the bus. So
long as it returns the right thing for any key that's presented, it doesn't
matter quite how things are done.
So I'm not sure I understand what you are saying here.
The problem, more basically, is that the ivar keys are not unique.
Currently, there's no bits used in the key to define the values to be non-
overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
We could easily reserve the upper 16-bits of this field to be that key.
This value could then be used to differentiate them. But this wouldn't scale
too well. Given that there's only about a dozen or two in the tree, that's
right at the moment, it wouldn't be hard to do something like:
enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16
and the above could be changed to:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
and then we'd have an unambiguous key, and the bus could easily implement
multiple interfaces.
but then again, most of the existing interfaces in the kernel are
mutually exclusive, so you could implement this just for your new interfaces.
ok, I think I got it now. You and I are exactly saying the same thing,
just in different terms; there is no way to currently specify multiple
independent (/overlapping) ivars in a child...
There's no way to support overlapping IVAR keys, yes. However, if you are
designing the ivars for multiple inheritance, then you'll need to make them
non-overlapping. Thankfully, this is trivial to do.
Also, I think we should do this in general. We already have one example (e.g.
ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can
provide both ACPI and PCI IVARs to child devices). I think we should assign
each bus it's own IVAR range. It would make it easier to determine if a
specific IVAR is event supported. Certainly I think ISA and PCI at a minimum
should be changed to start at, say, 200 and 300.
--
John Baldwin
___
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: Use of C99 extra long double math functions after r236148
On Sunday, July 08, 2012 7:56:52 pm David Schultz wrote: On Sun, Jul 08, 2012, Steve Kargl wrote: The question remains of what to do about the missing functions. Bruce and Steve have been working on expl and logl for years. If those ever get in the tree, the remaining long double functions are easy. Those functions are basically done, modulo a bunch of cleanup and testing, and I encourage any mathematically inclined folks who are interested in pushing things along to get in touch with them. I'm not going to have any time myself for a few months at least. Where can I find these? I've posted expl() a few times for the ld80 version. I don't have an ld128 version, which is why I have yet to submit a formal patch for expl(). I also have an ld80 expm1l(). I have a copy of bde's ld80 logl(). IIRC, bde wrote an ld128, but I don't have nor do I know if it has been tested. Yes, Bruce has ld128 versions, and clusteradm very kindly got us a sparc64 machine to test on. That was about the time I ran out of time to keep working on it. If someone wants to pick it up, that would be great. PS: I also wrote sincos[fl](), which is very handy for the complex trig functions. Yes, you should commit that! So it sounds like there are at least some outstanding patches that should go into the tree. Can we at least get these things committed (even if they are only enabled for certain platforms for now)? -- John Baldwin ___ 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: XSAVEOPT
On Sunday, July 08, 2012 11:02:25 am Konstantin Belousov wrote: Please find at http://people.freebsd.org/~kib/misc/xsaveopt.1.patch a patch to finally add suport for using XSAVEOPT for our amd64 context switch code. See Intel SDM for description of the XSAVEOPT instruction. Summary is that the instruction allows to not write parts of the FPU state which was not touched by the thread. Context switch then would write less to the PCB when thread is moved out from CPU. This is mainly to facilitate the ever-growing size of the FPU register file, in particular, AVX/YMM registers. Normal applications do not touch YMM, so saving them on each context switch if FPU was used is waste. Main complication is that any consumer of the ucontext_t still expect to see fully populated machine state, including the extended states which were not saved. Since CPU only avoids save when corresponding state is pristine, we can use the copy of initial state. CPUID provides an enumerator that allows OS to easily pick up neccesary area and copy over. I tried hard, but was unable to measure any statistically significant difference in the context switch times between XSAVE and XSAVEOPT using lmbench lat_ctx, on Core i7 2600K. Hmm, I thought one of the ideas of xsaveopt was to let you just always execute it during a context switch and dispense with the need for using the CR0_TS flag at all? Maybe that isn't true though. It would seem rather silly to switch out the state if you don't need to (when preempting a thread that uses the FPU to run a thread that doesn't and then switching back for example). -- John Baldwin ___ 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: sleeping thread panic?
On 07/09/12 11:22, John Baldwin wrote: On Sunday, July 08, 2012 9:46:09 am Michael Butler wrote: [ .. snip .. ] Sorry, that is the entire info file - nothing more than I've posted is logged, For future reference, you can look at the core.txt.0 file generated by crashinfo. It should contain the dmesg near the bottom and you could have gotten the stack trace of the broken thread from that. While that's usually the case in my experience, none was written with this :-( imb ___ 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: sleeping thread panic?
On Monday, July 09, 2012 11:41:38 am Michael Butler wrote: On 07/09/12 11:22, John Baldwin wrote: On Sunday, July 08, 2012 9:46:09 am Michael Butler wrote: [ .. snip .. ] Sorry, that is the entire info file - nothing more than I've posted is logged, For future reference, you can look at the core.txt.0 file generated by crashinfo. It should contain the dmesg near the bottom and you could have gotten the stack trace of the broken thread from that. While that's usually the case in my experience, none was written with this :-( Humm, you can also get to it in kgdb via this: printf %s, msgbufp-msg_ptr -- John Baldwin ___ 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: no keyboard after booting r235646 in laptop FS Amilo D 7830
On Friday, July 06, 2012 7:25:55 pm Kaho Toshikazu wrote: Hello, John Baldwin j...@freebsd.org wrote: Almost all systems use one of the IDs we do support as a _CID if not a _HID. In fact, in this case it likely seems to be a BIOS bug as it used the same value for the _CID and _HID. I suspect it is supposed to be using 0303 as its _CID. I don't think the BIOS should say PNP0303 as a keyboard _CID. Using _CID may help some systems, but it may not be helpful for many systems having keyboard probe problem. I think it's a specification bug made by Microsoft, same devices connected different type devices should not have different ID but same ID. Well, my point is that having a _HID and _CID with the same ID is pointless. It really does look like a typo in the BIOS source. People with this problem can override AML code, but I don't think it is a bad idea adding other IDs to the list for probing. Adding IDs is cheap, so I'm fine with doing so. -- John Baldwin ___ 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: sleeping thread panic?
On 07/09/12 11:54, John Baldwin wrote: On Monday, July 09, 2012 11:41:38 am Michael Butler wrote: On 07/09/12 11:22, John Baldwin wrote: On Sunday, July 08, 2012 9:46:09 am Michael Butler wrote: [ .. snip .. ] Sorry, that is the entire info file - nothing more than I've posted is logged, For future reference, you can look at the core.txt.0 file generated by crashinfo. It should contain the dmesg near the bottom and you could have gotten the stack trace of the broken thread from that. While that's usually the case in my experience, none was written with this :-( Humm, you can also get to it in kgdb via this: printf %s, msgbufp-msg_ptr Thanks! Archived for future reference :-) imb ___ 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: XSAVEOPT
On Mon, Jul 09, 2012 at 11:24:52AM -0400, John Baldwin wrote: On Sunday, July 08, 2012 11:02:25 am Konstantin Belousov wrote: Please find at http://people.freebsd.org/~kib/misc/xsaveopt.1.patch a patch to finally add suport for using XSAVEOPT for our amd64 context switch code. See Intel SDM for description of the XSAVEOPT instruction. Summary is that the instruction allows to not write parts of the FPU state which was not touched by the thread. Context switch then would write less to the PCB when thread is moved out from CPU. This is mainly to facilitate the ever-growing size of the FPU register file, in particular, AVX/YMM registers. Normal applications do not touch YMM, so saving them on each context switch if FPU was used is waste. Main complication is that any consumer of the ucontext_t still expect to see fully populated machine state, including the extended states which were not saved. Since CPU only avoids save when corresponding state is pristine, we can use the copy of initial state. CPUID provides an enumerator that allows OS to easily pick up neccesary area and copy over. I tried hard, but was unable to measure any statistically significant difference in the context switch times between XSAVE and XSAVEOPT using lmbench lat_ctx, on Core i7 2600K. Hmm, I thought one of the ideas of xsaveopt was to let you just always execute it during a context switch and dispense with the need for using the CR0_TS flag at all? Maybe that isn't true though. It would seem rather silly to switch out the state if you don't need to (when preempting a thread that uses the FPU to run a thread that doesn't and then switching back for example). To always execute XSAVEOPT, we would need always execute XRSTOR. Not executing XSAVEOPT is always faster then executing it. In fact, during the testing, I never seen a situation when x87 of XMM areas would be not saved by XSAVEOPT. Only YMM registers were omited if the process did not touched them since start. pgpcXMKYgF0D8.pgp Description: PGP signature
ada,ata and cd?
I'm on amd64 r238259. I'm still not clear on the /usr/src/UPDATING entry from 20110424 on replacing the ATA drivers by CAM drivers. If I *do not* have device ata in the kernel, I have neither /dev/cd* or /dev/acd*, even though I have in the kernel: options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering device ada device cd # CD If I then add device ata to the kernel, then /dev/cd0 appears: cd0 at ata0 bus 0 scbus1 target 0 lun 0 cd0: MATSHITA DVD-RAM UJ-861H 1.50 Removable CD-ROM SCSI-0 device cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: cd present [248633 x 2048 byte records] Is that expected? My understanding of the above /usr/src/UPDATING entry is that device ata should not be needed. Am I wrong? # cat /etc/fstab # DeviceMountpoint FStype Options DumpPass# /dev/ada0s1bnoneswapsw 0 0 /dev/ada0s1a/ ufs rw 1 1 /dev/cd0/cdrom cd9660 ro,noauto 0 0 /dev/da0s1 /mntmsdosfs rw,noauto 0 0 # Many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: ada,ata and cd?
On Mon, Jul 09, 2012 at 11:52:10PM +0100, Anton Shterenlikht wrote: I'm on amd64 r238259. I'm still not clear on the /usr/src/UPDATING entry from 20110424 on replacing the ATA drivers by CAM drivers. If I *do not* have device ata in the kernel, I have neither /dev/cd* or /dev/acd*, even though I have in the kernel: options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering device ada device cd # CD man 4 cam I suspect that you are missing 'device scbus' in your config file. -- Steve ___ 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: ada,ata and cd?
On Mon, Jul 9, 2012 at 4:38 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, Jul 09, 2012 at 11:52:10PM +0100, Anton Shterenlikht wrote: I'm on amd64 r238259. I'm still not clear on the /usr/src/UPDATING entry from 20110424 on replacing the ATA drivers by CAM drivers. If I *do not* have device ata in the kernel, I have neither /dev/cd* or /dev/acd*, even though I have in the kernel: options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering device ada device cd # CD man 4 cam I suspect that you are missing 'device scbus' in your config file. device scbus # SCSI bus (required for ATA/SCSI) Probably. And as the fine print says... Note that to use CAM-based ATA kernel should include CAM devices scbus, pass, da (or explicitly ada), cd and optionally others. Thanks, -Garrett ___ 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 powerpc/powerpc
TB --- 2012-07-10 03:01:42 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 03:01:42 - 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 --- 2012-07-10 03:01:42 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-10 03:01:42 - cleaning the object tree TB --- 2012-07-10 03:01:42 - cvsupping the source tree TB --- 2012-07-10 03:01:42 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-10 03:02:24 - building world TB --- 2012-07-10 03:02:24 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 03:02:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 03:02:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 03:02:24 - SRCCONF=/dev/null TB --- 2012-07-10 03:02:24 - TARGET=powerpc TB --- 2012-07-10 03:02:24 - TARGET_ARCH=powerpc TB --- 2012-07-10 03:02:24 - TZ=UTC TB --- 2012-07-10 03:02:24 - __MAKE_CONF=/dev/null TB --- 2012-07-10 03:02:24 - cd /src TB --- 2012-07-10 03:02:24 - /usr/bin/make -B buildworld World build started on Tue Jul 10 03:02:24 UTC 2012 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 Tue Jul 10 05:17:19 UTC 2012 TB --- 2012-07-10 05:17:19 - generating LINT kernel config TB --- 2012-07-10 05:17:19 - cd /src/sys/powerpc/conf TB --- 2012-07-10 05:17:19 - /usr/bin/make -B LINT TB --- 2012-07-10 05:17:19 - cd /src/sys/powerpc/conf TB --- 2012-07-10 05:17:19 - /usr/sbin/config -m LINT TB --- 2012-07-10 05:17:19 - building LINT kernel TB --- 2012-07-10 05:17:19 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 05:17:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 05:17:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 05:17:19 - SRCCONF=/dev/null TB --- 2012-07-10 05:17:19 - TARGET=powerpc TB --- 2012-07-10 05:17:19 - TARGET_ARCH=powerpc TB --- 2012-07-10 05:17:19 - TZ=UTC TB --- 2012-07-10 05:17:19 - __MAKE_CONF=/dev/null TB --- 2012-07-10 05:17:19 - cd /src TB --- 2012-07-10 05:17:19 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Jul 10 05:17:20 UTC 2012 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 [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq
[head tinderbox] failure on sparc64/sparc64
TB --- 2012-07-10 04:39:59 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 04:39:59 - 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 --- 2012-07-10 04:39:59 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-10 04:39:59 - cleaning the object tree TB --- 2012-07-10 04:39:59 - cvsupping the source tree TB --- 2012-07-10 04:39:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-10 04:41:35 - building world TB --- 2012-07-10 04:41:35 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 04:41:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 04:41:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 04:41:35 - SRCCONF=/dev/null TB --- 2012-07-10 04:41:35 - TARGET=sparc64 TB --- 2012-07-10 04:41:35 - TARGET_ARCH=sparc64 TB --- 2012-07-10 04:41:35 - TZ=UTC TB --- 2012-07-10 04:41:35 - __MAKE_CONF=/dev/null TB --- 2012-07-10 04:41:35 - cd /src TB --- 2012-07-10 04:41:35 - /usr/bin/make -B buildworld World build started on Tue Jul 10 04:41:36 UTC 2012 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 Tue Jul 10 05:41:59 UTC 2012 TB --- 2012-07-10 05:41:59 - generating LINT kernel config TB --- 2012-07-10 05:41:59 - cd /src/sys/sparc64/conf TB --- 2012-07-10 05:41:59 - /usr/bin/make -B LINT TB --- 2012-07-10 05:41:59 - cd /src/sys/sparc64/conf TB --- 2012-07-10 05:41:59 - /usr/sbin/config -m LINT TB --- 2012-07-10 05:41:59 - building LINT kernel TB --- 2012-07-10 05:41:59 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 05:41:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 05:41:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 05:41:59 - SRCCONF=/dev/null TB --- 2012-07-10 05:41:59 - TARGET=sparc64 TB --- 2012-07-10 05:41:59 - TARGET_ARCH=sparc64 TB --- 2012-07-10 05:41:59 - TZ=UTC TB --- 2012-07-10 05:41:59 - __MAKE_CONF=/dev/null TB --- 2012-07-10 05:41:59 - cd /src TB --- 2012-07-10 05:41:59 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Jul 10 05:41:59 UTC 2012 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100
