Re: svn commit: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd
On Thu, Aug 18, 2016 at 09:28:57PM -0600, Warner Losh wrote: > On Thu, Aug 18, 2016 at 12:50 AM, Julian Elischer wrote: > > On 16/08/2016 4:54 AM, John Baldwin wrote: > >> > >> On Monday, August 15, 2016 08:38:02 PM John Baldwin wrote: > >>> > >>> Author: jhb > >>> Date: Mon Aug 15 20:38:02 2016 > >>> New Revision: 304187 > >>> URL: https://svnweb.freebsd.org/changeset/base/304187 > >>> > >>> Log: > >>>Remove the mcd(4) driver for Mitsumi CD-ROM players. > >>> This is a driver for a pre-ATAPI ISA CD-ROM adapter. As noted in > >>>the manpage, this driver is only useful as a backend to cdcontrol to > >>>play audio CDs since it doesn't use DMA, so its data performance is > >>>"abysmal" (and that was true in the mid 90's). > >> > >> No one stepped up to test patches for it either when I last posted patches > >> to > >> convert it from timeout(9) to callout(9). I have a few more drivers that > >> are > >> both very old and that people have no business using in 12 (think ISA > >> adapters that don't do DMA and can't be used with pccard) that I will be > >> removing over the next little while. I brought up a list of drivers on > >> arch@ > >> a couple of years ago and the conversation drifted off into the weeds > >> about > >> trimming GENERIC, etc. No one objected to the specific drivers I listed > >> though (and I got a few pleas of "please remove"). If someone shows up > >> desperately clutching an ISA adapter they can always dig up the source > >> from > >> svn and deal with forward porting it for whatever API changes have > >> happened > >> since it was removed. > > > > > > I would imagine any machine still holding one of these probably has not > > enough memory to run FreeBSD. > > > > would we still run in 2MB? > > With insane levels of tuning, we can run in 32MB userland that can do > things. Even 64MB is tight w/o some tuning. 16MB is almost certainly > right out except for very specialized situations. 2MB? We can't even > load the loader in that :(. Oh, and all these memory configs are only > possible if you tweak the loader's block cache... > 32MB is quite usable. Without any tuning, you get slightly less than 10MB for userspace, which is enough to for many things, and plenty if swap is added. Note that you cannot boot on such configurations since loader was broken, but if you do manage to jump to kernel, things were fine several months ago. I tested my relatively recent OOM changes on 32MB qemu config. > Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304439 - head/sys/dev/usb/net
On 08/19/16 02:50, Pyun YongHyeon wrote:
Modified: head/sys/dev/usb/net/if_axgereg.h
==
--- head/sys/dev/usb/net/if_axgereg.h Fri Aug 19 00:03:41 2016
(r304438)
+++ head/sys/dev/usb/net/if_axgereg.h Fri Aug 19 00:50:32 2016
(r304439)
@@ -156,19 +156,20 @@ enum {
struct axge_frame_txhdr {
#if BYTE_ORDER == LITTLE_ENDIAN
uint32_tlen;
-#defineAXGE_TXLEN_MASK 0x0001
-#defineAXGE_VLAN_INSERT0x2000
-#defineAXGE_CSUM_DISABLE 0x8000
uint32_tmss;
-#defineAXGE_MSS_MASK 0x3FFF
-#defineAXGE_PADDING0x80008000
-#defineAXGE_VLAN_TAG_MASK 0x
#else
uint32_tmss;
uint32_tlen;
#endif
} __packed;
Hi,
Is it correct to switch the order of mss and len variables for
bit/little endian? Looks buggy to me.
--HPS
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304439 - head/sys/dev/usb/net
On Fri, Aug 19, 2016 at 4:50 PM, Hans Petter Selasky wrote:
> On 08/19/16 02:50, Pyun YongHyeon wrote:
>>
>> Modified: head/sys/dev/usb/net/if_axgereg.h
>>
>> ==
>> --- head/sys/dev/usb/net/if_axgereg.h Fri Aug 19 00:03:41 2016
>> (r304438)
>> +++ head/sys/dev/usb/net/if_axgereg.h Fri Aug 19 00:50:32 2016
>> (r304439)
>> @@ -156,19 +156,20 @@ enum {
>> struct axge_frame_txhdr {
>> #if BYTE_ORDER == LITTLE_ENDIAN
>> uint32_tlen;
>> -#defineAXGE_TXLEN_MASK 0x0001
>> -#defineAXGE_VLAN_INSERT0x2000
>> -#defineAXGE_CSUM_DISABLE 0x8000
>> uint32_tmss;
>> -#defineAXGE_MSS_MASK 0x3FFF
>> -#defineAXGE_PADDING0x80008000
>> -#defineAXGE_VLAN_TAG_MASK 0x
>> #else
>> uint32_tmss;
>> uint32_tlen;
>> #endif
>> } __packed;
>>
>
> Hi,
>
> Is it correct to switch the order of mss and len variables for bit/little
> endian? Looks buggy to me.
It probably is a 64bits field. IMHO, using a 64bits field and
mask/shift-op probably will be better here.
Thanks,
sephe
--
Tomorrow Will Never Die
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd
> On 19. aug 2016, at 10:39, Konstantin Belousov wrote: > > On Thu, Aug 18, 2016 at 09:28:57PM -0600, Warner Losh wrote: >> On Thu, Aug 18, 2016 at 12:50 AM, Julian Elischer wrote: >>> On 16/08/2016 4:54 AM, John Baldwin wrote: On Monday, August 15, 2016 08:38:02 PM John Baldwin wrote: > > Author: jhb > Date: Mon Aug 15 20:38:02 2016 > New Revision: 304187 > URL: https://svnweb.freebsd.org/changeset/base/304187 > > Log: > Remove the mcd(4) driver for Mitsumi CD-ROM players. > This is a driver for a pre-ATAPI ISA CD-ROM adapter. As noted in > the manpage, this driver is only useful as a backend to cdcontrol to > play audio CDs since it doesn't use DMA, so its data performance is > "abysmal" (and that was true in the mid 90's). No one stepped up to test patches for it either when I last posted patches to convert it from timeout(9) to callout(9). I have a few more drivers that are both very old and that people have no business using in 12 (think ISA adapters that don't do DMA and can't be used with pccard) that I will be removing over the next little while. I brought up a list of drivers on arch@ a couple of years ago and the conversation drifted off into the weeds about trimming GENERIC, etc. No one objected to the specific drivers I listed though (and I got a few pleas of "please remove"). If someone shows up desperately clutching an ISA adapter they can always dig up the source from svn and deal with forward porting it for whatever API changes have happened since it was removed. >>> >>> >>> I would imagine any machine still holding one of these probably has not >>> enough memory to run FreeBSD. >>> >>> would we still run in 2MB? >> >> With insane levels of tuning, we can run in 32MB userland that can do >> things. Even 64MB is tight w/o some tuning. 16MB is almost certainly >> right out except for very specialized situations. 2MB? We can't even >> load the loader in that :(. Oh, and all these memory configs are only >> possible if you tweak the loader's block cache... >> > > 32MB is quite usable. Without any tuning, you get slightly less than 10MB > for userspace, which is enough to for many things, and plenty if swap is > added. > > Note that you cannot boot on such configurations since loader was broken, > but if you do manage to jump to kernel, things were fine several months > ago. I tested my relatively recent OOM changes on 32MB qemu config. >> Warner > If the target is to go as low memory as possible, sure, you can strip all off, from boot loader point, you should load kernel from stage2 and not use loader at all (you can load and jump kernel even now from stage2, assuming it wont need any special configuration from loader config) etc etc. This means highly specialized build and has nothing to do with generic all purpose system. Also at some point, there is an question about how reasonable it is to have such configuration as part of generic code base for special bits like boot loader itself, as the problem is, testing all those variants is becoming impossible and even keeping reasonable code base in all of the #if #else #endif spaghetti is getting quite hard and error prone. From developers point of view, it is not really encouraging to have possible feedback like “oh, but you did break my 32MB system boot” ;) This does bring back some memories however. For first 2 unix systems I was dealing with, one had 8MB and another had 12MB of memory… it was ~ 1992-1993;) Right now the loader and stage2 are set to use 64MB heap to make it possible to implement zfs feature support and later on, for more features. Also note that UEFI setups are much harder to deal with regard of memory management, because as long as BS are in control, you can not really control the memory management there and can end up with fragmented unusable (for kernel loading) layout. This is especially nasty as apparently some (buggy) systems actually have runtime services using boot services memory areas, so you can end up in setup where you can not re-use BS memory and those chunks can be all over the low memory address space… rgds, toomas ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304439 - head/sys/dev/usb/net
On Fri, Aug 19, 2016 at 10:50:47AM +0200, Hans Petter Selasky wrote:
> On 08/19/16 02:50, Pyun YongHyeon wrote:
> >Modified: head/sys/dev/usb/net/if_axgereg.h
> >==
> >--- head/sys/dev/usb/net/if_axgereg.hFri Aug 19 00:03:41 2016
> >(r304438)
> >+++ head/sys/dev/usb/net/if_axgereg.hFri Aug 19 00:50:32 2016
> >(r304439)
> >@@ -156,19 +156,20 @@ enum {
> > struct axge_frame_txhdr {
> > #if BYTE_ORDER == LITTLE_ENDIAN
> > uint32_tlen;
> >-#define AXGE_TXLEN_MASK 0x0001
> >-#define AXGE_VLAN_INSERT0x2000
> >-#define AXGE_CSUM_DISABLE 0x8000
> > uint32_tmss;
> >-#define AXGE_MSS_MASK 0x3FFF
> >-#define AXGE_PADDING0x80008000
> >-#define AXGE_VLAN_TAG_MASK 0x
> > #else
> > uint32_tmss;
> > uint32_tlen;
> > #endif
> > } __packed;
> >
>
> Hi,
>
> Is it correct to switch the order of mss and len variables for
> bit/little endian? Looks buggy to me.
>
I think the order is right but it was not tested on big-endian
systems.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304439 - head/sys/dev/usb/net
On 08/19/16 10:55, YongHyeon PYUN wrote: I think the order is right but it was not tested on big-endian systems. Hi, I'm pretty sure the ifdef is wrong, because you write the fields one at a time, using htole32(): txhdr.mss = 0; txhdr.len = htole32(AXGE_TXBYTES(m->m_pkthdr.len)); Big endian machines don't re-order variables like this. You should remove the #else part. --HPS ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304439 - head/sys/dev/usb/net
On Fri, Aug 19, 2016 at 11:11:56AM +0200, Hans Petter Selasky wrote: > On 08/19/16 10:55, YongHyeon PYUN wrote: > >I think the order is right but it was not tested on big-endian > >systems. > > Hi, > > I'm pretty sure the ifdef is wrong, because you write the fields one at > a time, using htole32(): > > txhdr.mss = 0; > txhdr.len = htole32(AXGE_TXBYTES(m->m_pkthdr.len)); > > Big endian machines don't re-order variables like this. > > You should remove the #else part. Wouldn't USB stack pass txhdr structure without any modification? And controller want to see len (low 32bits address) first and then mss (high 32bits address). On big endian systems I guess this should be reversed in host memory layout. This is so confusing so I could be wrong. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd
On Fri, Aug 19, 2016 at 11:50:35AM +0300, Toomas Soome wrote: > > > On 19. aug 2016, at 10:39, Konstantin Belousov wrote: > > > > On Thu, Aug 18, 2016 at 09:28:57PM -0600, Warner Losh wrote: > >> On Thu, Aug 18, 2016 at 12:50 AM, Julian Elischer > >> wrote: > >>> On 16/08/2016 4:54 AM, John Baldwin wrote: > > On Monday, August 15, 2016 08:38:02 PM John Baldwin wrote: > > > > Author: jhb > > Date: Mon Aug 15 20:38:02 2016 > > New Revision: 304187 > > URL: https://svnweb.freebsd.org/changeset/base/304187 > > > > Log: > > Remove the mcd(4) driver for Mitsumi CD-ROM players. > > This is a driver for a pre-ATAPI ISA CD-ROM adapter. As noted in > > the manpage, this driver is only useful as a backend to cdcontrol to > > play audio CDs since it doesn't use DMA, so its data performance is > > "abysmal" (and that was true in the mid 90's). > > No one stepped up to test patches for it either when I last posted > patches > to > convert it from timeout(9) to callout(9). I have a few more drivers that > are > both very old and that people have no business using in 12 (think ISA > adapters that don't do DMA and can't be used with pccard) that I will be > removing over the next little while. I brought up a list of drivers on > arch@ > a couple of years ago and the conversation drifted off into the weeds > about > trimming GENERIC, etc. No one objected to the specific drivers I listed > though (and I got a few pleas of "please remove"). If someone shows up > desperately clutching an ISA adapter they can always dig up the source > from > svn and deal with forward porting it for whatever API changes have > happened > since it was removed. > >>> > >>> > >>> I would imagine any machine still holding one of these probably has not > >>> enough memory to run FreeBSD. > >>> > >>> would we still run in 2MB? > >> > >> With insane levels of tuning, we can run in 32MB userland that can do > >> things. Even 64MB is tight w/o some tuning. 16MB is almost certainly > >> right out except for very specialized situations. 2MB? We can't even > >> load the loader in that :(. Oh, and all these memory configs are only > >> possible if you tweak the loader's block cache... > >> > > > > 32MB is quite usable. Without any tuning, you get slightly less than 10MB > > for userspace, which is enough to for many things, and plenty if swap is > > added. > > > > Note that you cannot boot on such configurations since loader was broken, > > but if you do manage to jump to kernel, things were fine several months > > ago. I tested my relatively recent OOM changes on 32MB qemu config. > >> Warner > > > > If the target is to go as low memory as possible, sure, you can strip all > off, from boot loader point, you should load kernel from stage2 and not use > loader at all (you can load and jump kernel even now from stage2, assuming it > wont need any special configuration from loader config) etc etc. This means > highly specialized build and has nothing to do with generic all purpose > system. > Why you describe this as an 'alternative' ? Before that loader changes, I regularly tested on 32MB qemy i386 image and 64MB amd64 image. I do not see anything extreme in these configs. They use normal boot path, which provides kernels with debugging symbols, metadata, loaded modules etc. Why should I use deficient boot2-only loading, which, additionally, cannot work on amd64 ? More, this is the only reasonable way for most developers to ensure that system is still usable on tiny configs found on embedded devices. Right now the min which I have to set up is 128MB, and VM changes are simply not tested on anything smaller. It is guaranteed that small systems will grow regressions fast. And I will not jump through the hoops to mitigate breakage induced by other people' changes. > Also at some point, there is an question about how reasonable it is to have > such configuration as part of generic code base for special bits like boot > loader itself, as the problem is, testing all those variants is becoming > impossible and even keeping reasonable code base in all of the #if #else > #endif spaghetti is getting quite hard and error prone. > > >From developers point of view, it is not really encouraging to have possible > >feedback like ???oh, but you did break my 32MB system boot??? ;) This does > >bring back some memories however. For first 2 unix systems I was dealing > >with, one had 8MB and another had 12MB of memory??? it was ~ 1992-1993;) > Not mine, but you (?) indirectly broke system for people who do use 32MB on other arches, since low memory config on dev systems become 128MB. I cared about 32MB before, but not any longer. > Right now the loader and stage2 are set to use 64MB heap to make it possible > to implement zfs feature support and later on, for more features.
Re: svn commit: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd
> On 19. aug 2016, at 12:24, Konstantin Belousov wrote: > > On Fri, Aug 19, 2016 at 11:50:35AM +0300, Toomas Soome wrote: >> >>> On 19. aug 2016, at 10:39, Konstantin Belousov wrote: >>> >>> On Thu, Aug 18, 2016 at 09:28:57PM -0600, Warner Losh wrote: On Thu, Aug 18, 2016 at 12:50 AM, Julian Elischer wrote: > On 16/08/2016 4:54 AM, John Baldwin wrote: >> >> On Monday, August 15, 2016 08:38:02 PM John Baldwin wrote: >>> >>> Author: jhb >>> Date: Mon Aug 15 20:38:02 2016 >>> New Revision: 304187 >>> URL: https://svnweb.freebsd.org/changeset/base/304187 >>> >>> Log: >>> Remove the mcd(4) driver for Mitsumi CD-ROM players. >>>This is a driver for a pre-ATAPI ISA CD-ROM adapter. As noted in >>> the manpage, this driver is only useful as a backend to cdcontrol to >>> play audio CDs since it doesn't use DMA, so its data performance is >>> "abysmal" (and that was true in the mid 90's). >> >> No one stepped up to test patches for it either when I last posted >> patches >> to >> convert it from timeout(9) to callout(9). I have a few more drivers that >> are >> both very old and that people have no business using in 12 (think ISA >> adapters that don't do DMA and can't be used with pccard) that I will be >> removing over the next little while. I brought up a list of drivers on >> arch@ >> a couple of years ago and the conversation drifted off into the weeds >> about >> trimming GENERIC, etc. No one objected to the specific drivers I listed >> though (and I got a few pleas of "please remove"). If someone shows up >> desperately clutching an ISA adapter they can always dig up the source >> from >> svn and deal with forward porting it for whatever API changes have >> happened >> since it was removed. > > > I would imagine any machine still holding one of these probably has not > enough memory to run FreeBSD. > > would we still run in 2MB? With insane levels of tuning, we can run in 32MB userland that can do things. Even 64MB is tight w/o some tuning. 16MB is almost certainly right out except for very specialized situations. 2MB? We can't even load the loader in that :(. Oh, and all these memory configs are only possible if you tweak the loader's block cache... >>> >>> 32MB is quite usable. Without any tuning, you get slightly less than 10MB >>> for userspace, which is enough to for many things, and plenty if swap is >>> added. >>> >>> Note that you cannot boot on such configurations since loader was broken, >>> but if you do manage to jump to kernel, things were fine several months >>> ago. I tested my relatively recent OOM changes on 32MB qemu config. Warner >>> >> >> If the target is to go as low memory as possible, sure, you can strip all >> off, from boot loader point, you should load kernel from stage2 and not use >> loader at all (you can load and jump kernel even now from stage2, assuming >> it wont need any special configuration from loader config) etc etc. This >> means highly specialized build and has nothing to do with generic all >> purpose system. >> > Why you describe this as an 'alternative' ? Before that loader changes, > I regularly tested on 32MB qemy i386 image and 64MB amd64 image. I do > not see anything extreme in these configs. They use normal boot path, > which provides kernels with debugging symbols, metadata, loaded modules > etc. Why should I use deficient boot2-only loading, which, additionally, > cannot work on amd64 ? > > More, this is the only reasonable way for most developers to ensure that > system is still usable on tiny configs found on embedded devices. Right > now the min which I have to set up is 128MB, and VM changes are simply not > tested on anything smaller. It is guaranteed that small systems will grow > regressions fast. And I will not jump through the hoops to mitigate > breakage induced by other people' changes. > >> Also at some point, there is an question about how reasonable it is to have >> such configuration as part of generic code base for special bits like boot >> loader itself, as the problem is, testing all those variants is becoming >> impossible and even keeping reasonable code base in all of the #if #else >> #endif spaghetti is getting quite hard and error prone. >> >>> From developers point of view, it is not really encouraging to have >>> possible feedback like ???oh, but you did break my 32MB system boot??? ;) >>> This does bring back some memories however. For first 2 unix systems I was >>> dealing with, one had 8MB and another had 12MB of memory??? it was ~ >>> 1992-1993;) >> > Not mine, but you (?) indirectly broke system for people who do use 32MB > on other arches, since low memory config on dev systems become 128MB. > I cared about 32MB before, but not any longer. Yep, I did set it to 64MB. And
Re: svn commit: r304439 - head/sys/dev/usb/net
On 08/19/16 11:22, YongHyeon PYUN wrote: On Fri, Aug 19, 2016 at 11:11:56AM +0200, Hans Petter Selasky wrote: On 08/19/16 10:55, YongHyeon PYUN wrote: I think the order is right but it was not tested on big-endian systems. Hi, I'm pretty sure the ifdef is wrong, because you write the fields one at a time, using htole32(): txhdr.mss = 0; txhdr.len = htole32(AXGE_TXBYTES(m->m_pkthdr.len)); Big endian machines don't re-order variables like this. You should remove the #else part. Wouldn't USB stack pass txhdr structure without any modification? And controller want to see len (low 32bits address) first and then mss (high 32bits address). On big endian systems I guess this should be reversed in host memory layout. This is so confusing so I could be wrong. The USB stack passes TXHDR as-is and the host controller is byte oriented, not 64-bit word oriented. That's why the layout is the same as long as you assign per 32-bit field. --HPS ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304458 - head/sys/dev/usb/net
Author: yongari
Date: Fri Aug 19 10:51:30 2016
New Revision: 304458
URL: https://svnweb.freebsd.org/changeset/base/304458
Log:
Host controller is byte oriented. Fix wrong assumption on big-endian
systems.
Pointed out by: hselasky
Modified:
head/sys/dev/usb/net/if_axgereg.h
Modified: head/sys/dev/usb/net/if_axgereg.h
==
--- head/sys/dev/usb/net/if_axgereg.h Fri Aug 19 09:11:50 2016
(r304457)
+++ head/sys/dev/usb/net/if_axgereg.h Fri Aug 19 10:51:30 2016
(r304458)
@@ -154,21 +154,15 @@ enum {
#defineAXGE_N_FRAMES 16
struct axge_frame_txhdr {
-#if BYTE_ORDER == LITTLE_ENDIAN
uint32_tlen;
- uint32_tmss;
-#else
- uint32_tmss;
- uint32_tlen;
-#endif
-} __packed;
-
#defineAXGE_TXLEN_MASK 0x0001
#defineAXGE_VLAN_INSERT0x2000
#defineAXGE_CSUM_DISABLE 0x8000
+ uint32_tmss;
#defineAXGE_MSS_MASK 0x3FFF
#defineAXGE_PADDING0x80008000
#defineAXGE_VLAN_TAG_MASK 0x
+} __packed;
#defineAXGE_TXBYTES(x) ((x) & AXGE_TXLEN_MASK)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304460 - head/sys/arm/nvidia
Author: mmel
Date: Fri Aug 19 10:53:17 2016
New Revision: 304460
URL: https://svnweb.freebsd.org/changeset/base/304460
Log:
TEGRA: Implement MSI/MSIX interrupts for pcie controller.
Modified:
head/sys/arm/nvidia/tegra_pcie.c
Modified: head/sys/arm/nvidia/tegra_pcie.c
==
--- head/sys/arm/nvidia/tegra_pcie.cFri Aug 19 10:52:39 2016
(r304459)
+++ head/sys/arm/nvidia/tegra_pcie.cFri Aug 19 10:53:17 2016
(r304460)
@@ -33,20 +33,20 @@ __FBSDID("$FreeBSD$");
#include
#include
+#include
+#include
+#include
#include
-#include
#include
#include
#include
-#include
-#include
#include
-#include
-#include
#include
#include
+#include
+#include
#include
#include
@@ -68,8 +68,9 @@ __FBSDID("$FreeBSD$");
#include
#include "ofw_bus_if.h"
+#include "msi_if.h"
#include "pcib_if.h"
-
+#include "pic_if.h"
#defineAFI_AXI_BAR0_SZ 0x000
@@ -93,17 +94,10 @@ __FBSDID("$FreeBSD$");
#defineAFI_MSI_BAR_SZ 0x060
#defineAFI_MSI_FPCI_BAR_ST 0x064
#defineAFI_MSI_AXI_BAR_ST 0x068
-
-
-#defineAFI_AXI_BAR6_SZ 0x134
-#defineAFI_AXI_BAR7_SZ 0x138
-#defineAFI_AXI_BAR8_SZ 0x13c
-#defineAFI_AXI_BAR6_START 0x140
-#defineAFI_AXI_BAR7_START 0x144
-#defineAFI_AXI_BAR8_START 0x148
-#defineAFI_FPCI_BAR6 0x14c
-#defineAFI_FPCI_BAR7 0x150
-#defineAFI_FPCI_BAR8 0x154
+#define AFI_MSI_VEC(x) (0x06c + 4 * (x))
+#define AFI_MSI_EN_VEC(x) (0x08c + 4 * (x))
+#define AFI_MSI_INTR_IN_REG32
+#define AFI_MSI_REGS 8
#defineAFI_CONFIGURATION 0x0ac
#define AFI_CONFIGURATION_EN_FPCI (1 << 0)
@@ -209,6 +203,8 @@ __FBSDID("$FreeBSD$");
#defineTEGRA_PCIE_LINKUP_TIMEOUT 200
+#define TEGRA_PCIB_MSI_ENABLE
+
#defineDEBUG
#ifdef DEBUG
#definedebugf(fmt, args...) do { printf(fmt,##args); } while (0)
@@ -258,6 +254,13 @@ static struct ofw_compat_data compat_dat
{NULL, 0},
};
+#defineTEGRA_FLAG_MSI_USED 0x0001
+struct tegra_pcib_irqsrc {
+ struct intr_irqsrc isrc;
+ u_int irq;
+ u_int flags;
+};
+
struct tegra_pcib_port {
int enabled;
int port_idx; /* chip port index */
@@ -271,6 +274,7 @@ struct tegra_pcib_port {
};
#defineTEGRA_PCIB_MAX_PORTS3
+#defineTEGRA_PCIB_MAX_MSI AFI_MSI_INTR_IN_REG * AFI_MSI_REGS
struct tegra_pcib_softc {
struct ofw_pci_softcofw_pci;
device_tdev;
@@ -303,7 +307,7 @@ struct tegra_pcib_softc {
regulator_t supply_vddio_pex_ctl;
regulator_t supply_avdd_pll_erefe;
- uint32_tmsi_bitmap;
+ vm_offset_t msi_page; /* VA of MSI page */
bus_addr_t cfg_base_addr; /* base address of config */
bus_size_t cfg_cur_offs; /* currently mapped window */
bus_space_handle_t cfg_handle; /* handle of config window */
@@ -311,9 +315,9 @@ struct tegra_pcib_softc {
int lanes_cfg;
int num_ports;
struct tegra_pcib_port *ports[TEGRA_PCIB_MAX_PORTS];
+ struct tegra_pcib_irqsrc *isrcs;
};
-
static int
tegra_pcib_maxslots(device_t dev)
{
@@ -324,13 +328,15 @@ static int
tegra_pcib_route_interrupt(device_t bus, device_t dev, int pin)
{
struct tegra_pcib_softc *sc;
+ u_int irq;
sc = device_get_softc(bus);
- device_printf(bus, "route pin %d for device %d.%d to %ju\n",
+ irq = intr_map_clone_irq(rman_get_start(sc->irq_res));
+ device_printf(bus, "route pin %d for device %d.%d to %u\n",
pin, pci_get_slot(dev), pci_get_function(dev),
- rman_get_start(sc->irq_res));
+ irq);
- return (rman_get_start(sc->irq_res));
+ return (irq);
}
static int
@@ -471,84 +477,320 @@ static int tegra_pci_intr(void *arg)
return (FILTER_HANDLED);
}
-#if defined(TEGRA_PCI_MSI)
+/* ---
+ *
+ * PCI MSI interface
+ */
+static int
+tegra_pcib_alloc_msi(device_t pci, device_t child, int count, int maxcount,
+int *irqs)
+{
+ phandle_t msi_parent;
+
+ /* ofw_bus_msimap() don't
svn commit: r304459 - in head/sys: arm/arm arm/nvidia arm/ti/omap4 arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys
Author: mmel
Date: Fri Aug 19 10:52:39 2016
New Revision: 304459
URL: https://svnweb.freebsd.org/changeset/base/304459
Log:
INTRNG: Rework handling with resources. Partially revert r301453.
- Read interrupt properties at bus enumeration time and store
it into global mapping table.
- At bus_activate_resource() time, given mapping entry is resolved and
connected to real interrupt source. A copy of mapping entry is attached
to given resource.
- At bus_setup_intr() time, mapping entry stored in resource is used
for delivery of requested interrupt configuration.
- For MSI/MSIX interrupts, mapping entry is created within
pci_alloc_msi()/pci_alloc_msix() call.
- For legacy PCI interrupts, mapping entry must be created within
pcib_route_interrupt() by pcib driver itself.
Reviewed by: nwhitehorn, andrew
Differential Revision: https://reviews.freebsd.org/D7493
Modified:
head/sys/arm/arm/nexus.c
head/sys/arm/nvidia/tegra_lic.c
head/sys/arm/ti/omap4/omap4_wugen.c
head/sys/arm64/arm64/nexus.c
head/sys/dev/fdt/simplebus.c
head/sys/dev/gpio/gpiobus.c
head/sys/dev/gpio/gpiobusvar.h
head/sys/dev/gpio/ofw_gpiobus.c
head/sys/dev/iicbus/ofw_iicbus.c
head/sys/dev/ofw/ofw_bus_subr.c
head/sys/dev/ofw/ofw_bus_subr.h
head/sys/dev/ofw/ofwbus.c
head/sys/dev/pci/pci_host_generic.c
head/sys/dev/vnic/mrml_bridge.c
head/sys/dev/vnic/thunder_mdio_fdt.c
head/sys/kern/bus_if.m
head/sys/kern/pic_if.m
head/sys/kern/subr_bus.c
head/sys/kern/subr_intr.c
head/sys/mips/mips/nexus.c
head/sys/sys/bus.h
head/sys/sys/intr.h
Modified: head/sys/arm/arm/nexus.c
==
--- head/sys/arm/arm/nexus.cFri Aug 19 10:51:30 2016(r304458)
+++ head/sys/arm/arm/nexus.cFri Aug 19 10:52:39 2016(r304459)
@@ -64,6 +64,7 @@ __FBSDID("$FreeBSD$");
#ifdef FDT
#include
+#include
#include "ofw_bus_if.h"
#endif
@@ -379,6 +380,11 @@ nexus_activate_resource(device_t bus, de
#endif
rman_set_virtual(r, (void *)vaddr);
rman_set_bushandle(r, vaddr);
+ return (0);
+ } else if (type == SYS_RES_IRQ) {
+#ifdef INTRNG
+ intr_activate_irq(child, r);
+#endif
}
return (0);
}
@@ -390,17 +396,23 @@ nexus_deactivate_resource(device_t bus,
bus_size_t psize;
bus_space_handle_t vaddr;
- psize = (bus_size_t)rman_get_size(r);
- vaddr = rman_get_bushandle(r);
+ if (type == SYS_RES_MEMORY || type == SYS_RES_IOPORT) {
+ psize = (bus_size_t)rman_get_size(r);
+ vaddr = rman_get_bushandle(r);
- if (vaddr != 0) {
+ if (vaddr != 0) {
#ifdef FDT
- bus_space_unmap(fdtbus_bs_tag, vaddr, psize);
+ bus_space_unmap(fdtbus_bs_tag, vaddr, psize);
#else
- pmap_unmapdev((vm_offset_t)vaddr, (vm_size_t)psize);
+ pmap_unmapdev((vm_offset_t)vaddr, (vm_size_t)psize);
+#endif
+ rman_set_virtual(r, NULL);
+ rman_set_bushandle(r, 0);
+ }
+ } else if (type == SYS_RES_IRQ) {
+#ifdef INTRNG
+ intr_deactivate_irq(child, r);
#endif
- rman_set_virtual(r, NULL);
- rman_set_bushandle(r, 0);
}
return (rman_deactivate_resource(r));
@@ -411,11 +423,22 @@ static int
nexus_ofw_map_intr(device_t dev, device_t child, phandle_t iparent, int icells,
pcell_t *intr)
{
-
-#ifdef INTRNG
- return (INTR_IRQ_INVALID);
-#else
+#ifndef INTRNG
return (intr_fdt_map_irq(iparent, intr, icells));
-#endif
+#else
+ u_int irq;
+ struct intr_map_data_fdt *fdt_data;
+ size_t len;
+
+ len = sizeof(*fdt_data) + icells * sizeof(pcell_t);
+ fdt_data = (struct intr_map_data_fdt *)intr_alloc_map_data(
+ INTR_MAP_DATA_FDT, len, M_WAITOK | M_ZERO);
+ fdt_data->iparent = iparent;
+ fdt_data->ncells = icells;
+ memcpy(fdt_data->cells, intr, icells * sizeof(pcell_t));
+ irq = intr_map_irq(NULL, iparent, (struct intr_map_data *)fdt_data);
+ return (irq);
+#endif /* INTRNG */
}
-#endif
+#endif /* FDT */
+
Modified: head/sys/arm/nvidia/tegra_lic.c
==
--- head/sys/arm/nvidia/tegra_lic.c Fri Aug 19 10:51:30 2016
(r304458)
+++ head/sys/arm/nvidia/tegra_lic.c Fri Aug 19 10:52:39 2016
(r304459)
@@ -88,12 +88,12 @@ struct tegra_lic_sc {
};
static int
-tegra_lic_alloc_intr(device_t dev, struct intr_irqsrc *isrc,
+tegra_lic_activate_intr(device_t dev, struct intr_irqsrc *isrc,
struct resource *res, struct intr_map_data *data)
{
struct tegra_lic_sc *sc = device_get_softc(dev);
- return (PIC_ALLOC_INTR(sc->parent, isrc, res, data));
+ return (PIC_ACTIVATE_INTR(sc->parent, isrc, res, data));
}
Re: svn commit: r304439 - head/sys/dev/usb/net
On Fri, Aug 19, 2016 at 12:39:58PM +0200, Hans Petter Selasky wrote: > On 08/19/16 11:22, YongHyeon PYUN wrote: > >On Fri, Aug 19, 2016 at 11:11:56AM +0200, Hans Petter Selasky wrote: > >>On 08/19/16 10:55, YongHyeon PYUN wrote: > >>>I think the order is right but it was not tested on big-endian > >>>systems. > >> > >>Hi, > >> > >>I'm pretty sure the ifdef is wrong, because you write the fields one at > >>a time, using htole32(): > >> > >>txhdr.mss = 0; > >>txhdr.len = > >>htole32(AXGE_TXBYTES(m->m_pkthdr.len)); > >> > >>Big endian machines don't re-order variables like this. > >> > >>You should remove the #else part. > > > >Wouldn't USB stack pass txhdr structure without any > >modification? And controller want to see len (low 32bits address) > >first and then mss (high 32bits address). On big endian systems I > >guess this should be reversed in host memory layout. This is so > >confusing so I could be wrong. > > The USB stack passes TXHDR as-is and the host controller is byte > oriented, not 64-bit word oriented. That's why the layout is the same as > long as you assign per 32-bit field. > Ok, fixed in r304458. Thanks for pointing it out! ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304461 - head/sys/arm/nvidia
Author: mmel
Date: Fri Aug 19 11:12:59 2016
New Revision: 304461
URL: https://svnweb.freebsd.org/changeset/base/304461
Log:
TEGRA: Remove forgotten debug printf.
Modified:
head/sys/arm/nvidia/tegra_pcie.c
Modified: head/sys/arm/nvidia/tegra_pcie.c
==
--- head/sys/arm/nvidia/tegra_pcie.cFri Aug 19 10:53:17 2016
(r304460)
+++ head/sys/arm/nvidia/tegra_pcie.cFri Aug 19 11:12:59 2016
(r304461)
@@ -567,7 +567,6 @@ tegra_pcib_msi_intr(void *arg)
/* Handle one vector. */
while (reg != 0) {
bit = ffs(reg) - 1;
-//printf("%s: i: %d, reg: 0x%08X, bit: 0x%08X, addr: 0x%08llX\n", __func__, i,
reg, bit, rman_get_start(sc->afi_mem_res));
/* Send EOI */
AFI_WR4(sc, AFI_MSI_VEC(i), 1 << bit);
irq = i * AFI_MSI_INTR_IN_REG + bit;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd
On Fri, 19 Aug 2016, Konstantin Belousov wrote: On Thu, Aug 18, 2016 at 09:28:57PM -0600, Warner Losh wrote: On Thu, Aug 18, 2016 at 12:50 AM, Julian Elischer wrote: On 16/08/2016 4:54 AM, John Baldwin wrote: On Monday, August 15, 2016 08:38:02 PM John Baldwin wrote: ,,, Log: Remove the mcd(4) driver for Mitsumi CD-ROM players. This is a driver for a pre-ATAPI ISA CD-ROM adapter. As noted in the manpage, this driver is only useful as a backend to cdcontrol to play audio CDs since it doesn't use DMA, so its data performance is "abysmal" (and that was true in the mid 90's). No one stepped up to test patches for it either when I last posted patches to convert it from timeout(9) to callout(9). I have a few more drivers that are ... I would imagine any machine still holding one of these probably has not enough memory to run FreeBSD. would we still run in 2MB? With insane levels of tuning, we can run in 32MB userland that can do things. Even 64MB is tight w/o some tuning. 16MB is almost certainly right out except for very specialized situations. 2MB? We can't even load the loader in that :(. Oh, and all these memory configs are only possible if you tweak the loader's block cache... 32MB is quite usable. Without any tuning, you get slightly less than 10MB for userspace, which is enough to for many things, and plenty if swap is added. No, 32MB needs lots of needs tuning. -current seems to need about 16MB more than just a few months ago when I last discussed this with you. My i386 system doesn't have many drivers or a bloated userland (*), but it took the following tuning plus my PAE tuning fixes to boot in 32MB: - disable [l]em1 - reduce tx and buffers to 256 for em0. They default to 4096 for em. That is something like 8K * 1500 bytes = 12MB for em0 alone. lem[1] wants another 12MB. I think this is not all statically allocated, but the drivers hang onto that much. This now longer works. -current without my PAE tuning fixes hangs mounting root or in usb initialization with this tuning and 40MB. -current with my PAE tuning fixes hangs similarly with 32MB; with 40MB it boots to the start of multiuser but then hangs (it starts 1 getty, then 2 sendmails and kills them with "out of swap space") and 1 rpcbind (also killed). I don't use swap, but it was needed 20 years ago on a system that actually had 32MB of memory. (*) /bin/sh doing nothing much in -current i386: size 6532K res 1924K /bin/shin my ~5.2 i386: size 864K res 592K The kernel size is 5.5MB text 370K data 2.2MB bss (lots of bloat in bss for debugging and vt). In single user mode, with 40MB to start, there is 22116K wired and 2516K free. A few programs can be run in 2516K without swap if they have res 592K and not 1924K. Note that you cannot boot on such configurations since loader was broken, but if you do manage to jump to kernel, things were fine several months ago. I tested my relatively recent OOM changes on 32MB qemu config. I have no problems booting such configuratations since I don't use the current loader and only use old loader to change the environment to set up special configurations like this. I use my version of biosboot for boot2. This requires fixing 2 layers of complicated breakage in init386(). vm86 is now used before the TSS and PIC resources that it uses are initialized, but only in paths that are not normally used because they are for memory sizing that is normally done by loader :-(. I normally use my version of biosboot for boot2. I improved its caching just a couple of years ago. It was using 9K buffer optimized for 1440K floppies. Now it uses a 32K buffer. Booting a 5.5MB kernel takes a fraction of a second. Of course I don't use modules, so not many seeks are needed. Bruce ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd
On Fri, Aug 19, 2016 at 09:12:53PM +1000, Bruce Evans wrote: > On Fri, 19 Aug 2016, Konstantin Belousov wrote: > > > On Thu, Aug 18, 2016 at 09:28:57PM -0600, Warner Losh wrote: > >> On Thu, Aug 18, 2016 at 12:50 AM, Julian Elischer > >> wrote: > >>> On 16/08/2016 4:54 AM, John Baldwin wrote: > > On Monday, August 15, 2016 08:38:02 PM John Baldwin wrote: > > ,,, > > Log: > >Remove the mcd(4) driver for Mitsumi CD-ROM players. > > This is a driver for a pre-ATAPI ISA CD-ROM adapter. As noted in > >the manpage, this driver is only useful as a backend to cdcontrol to > >play audio CDs since it doesn't use DMA, so its data performance is > >"abysmal" (and that was true in the mid 90's). > > No one stepped up to test patches for it either when I last posted > patches > to > convert it from timeout(9) to callout(9). I have a few more drivers that > are > ... > >>> > >>> I would imagine any machine still holding one of these probably has not > >>> enough memory to run FreeBSD. > >>> > >>> would we still run in 2MB? > >> > >> With insane levels of tuning, we can run in 32MB userland that can do > >> things. Even 64MB is tight w/o some tuning. 16MB is almost certainly > >> right out except for very specialized situations. 2MB? We can't even > >> load the loader in that :(. Oh, and all these memory configs are only > >> possible if you tweak the loader's block cache... > > > > 32MB is quite usable. Without any tuning, you get slightly less than 10MB > > for userspace, which is enough to for many things, and plenty if swap is > > added. > > No, 32MB needs lots of needs tuning. -current seems to need about 16MB > more than just a few months ago when I last discussed this with you. > My i386 system doesn't have many drivers or a bloated userland (*), > but it took the following tuning plus my PAE tuning fixes to boot in > 32MB: > - disable [l]em1 > - reduce tx and buffers to 256 for em0. They default to 4096 for em. That >is something like 8K * 1500 bytes = 12MB for em0 alone. lem[1] wants >another 12MB. I think this is not all statically allocated, but the >drivers hang onto that much. > This now longer works. -current without my PAE tuning fixes hangs mounting > root or in usb initialization with this tuning and 40MB. -current with my > PAE tuning fixes hangs similarly with 32MB; with 40MB it boots to the > start of multiuser but then hangs (it starts 1 getty, then 2 sendmails > and kills them with "out of swap space") and 1 rpcbind (also killed). I > don't use swap, but it was needed 20 years ago on a system that actually > had 32MB of memory. > > (*) /bin/sh doing nothing much in -current i386: size 6532K res 1924K > /bin/shin my ~5.2 i386: size 864K res 592K > > The kernel size is 5.5MB text 370K data 2.2MB bss (lots of bloat in bss > for debugging and vt). In single user mode, with 40MB to start, there > is 22116K wired and 2516K free. A few programs can be run in 2516K > without swap if they have res 592K and not 1924K. > > > Note that you cannot boot on such configurations since loader was broken, > > but if you do manage to jump to kernel, things were fine several months > > ago. I tested my relatively recent OOM changes on 32MB qemu config. > > I have no problems booting such configuratations since I don't use the > current loader and only use old loader to change the environment to > set up special configurations like this. I use my version of biosboot > for boot2. This requires fixing 2 layers of complicated breakage in > init386(). vm86 is now used before the TSS and PIC resources that it > uses are initialized, but only in paths that are not normally used > because they are for memory sizing that is normally done by loader > :-(. > > I normally use my version of biosboot for boot2. I improved its caching > just a couple of years ago. It was using 9K buffer optimized for 1440K > floppies. Now it uses a 32K buffer. Booting a 5.5MB kernel takes a > fraction of a second. Of course I don't use modules, so not many seeks > are needed. Of course I use modules and do not use GENERIC. I just tried: with today HEAD, and old loader on 32MB VM, I get 11MB free in single-user mode. Active+inactive is ~4MB, and 1M is eaten by buffers, which is about right for init+/bin/sh+top idle system. Anyway, judging from the other responses, this is the lost case. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304464 - in head/sys/arm/allwinner: . a10
Author: manu
Date: Fri Aug 19 12:48:32 2016
New Revision: 304464
URL: https://svnweb.freebsd.org/changeset/base/304464
Log:
Allwinner: Move a10_padconf.c into a10 subdirectory.
Added:
head/sys/arm/allwinner/a10/a10_padconf.c
- copied unchanged from r304463, head/sys/arm/allwinner/a10_padconf.c
Deleted:
head/sys/arm/allwinner/a10_padconf.c
Modified:
head/sys/arm/allwinner/a10/files.a10
Copied: head/sys/arm/allwinner/a10/a10_padconf.c (from r304463,
head/sys/arm/allwinner/a10_padconf.c)
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/sys/arm/allwinner/a10/a10_padconf.cFri Aug 19 12:48:32 2016
(r304464, copy of r304463, head/sys/arm/allwinner/a10_padconf.c)
@@ -0,0 +1,231 @@
+/*-
+ * Copyright (c) 2016 Emmanuel Vadot
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ */
+
+#include
+__FBSDID("$FreeBSD$");
+
+#include
+#include
+#include
+#include
+
+#include
+
+#ifdef SOC_ALLWINNER_A10
+
+const static struct allwinner_pins a10_pins[] = {
+ {"PA0", 0, 0, {"gpio_in", "gpio_out", "emac", "spi1", "uart2", NULL,
NULL, NULL}},
+ {"PA1", 0, 1, {"gpio_in", "gpio_out", "emac", "spi1", "uart2", NULL,
NULL, NULL}},
+ {"PA2", 0, 2, {"gpio_in", "gpio_out", "emac", "spi1", "uart2", NULL,
NULL, NULL}},
+ {"PA3", 0, 3, {"gpio_in", "gpio_out", "emac", "spi1", "uart2", NULL,
NULL, NULL}},
+ {"PA4", 0, 4, {"gpio_in", "gpio_out", "emac", "spi1", NULL, NULL,
NULL, NULL}},
+ {"PA5", 0, 5, {"gpio_in", "gpio_out", "emac", "spi3", NULL, NULL,
NULL, NULL}},
+ {"PA6", 0, 6, {"gpio_in", "gpio_out", "emac", "spi3", NULL, NULL,
NULL, NULL}},
+ {"PA7", 0, 7, {"gpio_in", "gpio_out", "emac", "spi3", NULL, NULL,
NULL, NULL}},
+ {"PA8", 0, 8, {"gpio_in", "gpio_out", "emac", "spi3", NULL, NULL,
NULL, NULL}},
+ {"PA9", 0, 9, {"gpio_in", "gpio_out", "emac", "spi3", NULL, NULL,
NULL, NULL}},
+ {"PA10", 0, 10, {"gpio_in", "gpio_out", "emac", NULL, "uart1", NULL,
NULL, NULL}},
+ {"PA11", 0, 11, {"gpio_in", "gpio_out", "emac", NULL, "uart1", NULL,
NULL, NULL}},
+ {"PA12", 0, 12, {"gpio_in", "gpio_out", "emac", "uart6", "uart1", NULL,
NULL, NULL}},
+ {"PA13", 0, 13, {"gpio_in", "gpio_out", "emac", "uart6", "uart1", NULL,
NULL, NULL}},
+ {"PA14", 0, 14, {"gpio_in", "gpio_out", "emac", "uart7", "uart1", NULL,
NULL, NULL}},
+ {"PA15", 0, 15, {"gpio_in", "gpio_out", "emac", "uart7", "uart1", NULL,
NULL, NULL}},
+ {"PA16", 0, 16, {"gpio_in", "gpio_out", NULL, "can", "uart1", NULL,
NULL, NULL}},
+ {"PA17", 0, 17, {"gpio_in", "gpio_out", NULL, "can", "uart1", NULL,
NULL, NULL}},
+
+ {"PB0", 1, 0, {"gpio_in", "gpio_out", "i2c0", NULL, NULL, NULL, NULL,
NULL}},
+ {"PB1", 1, 1, {"gpio_in", "gpio_out", "i2c0", NULL, NULL, NULL, NULL,
NULL}},
+ {"PB2", 1, 2, {"gpio_in", "gpio_out", "pwm", NULL, NULL, NULL, NULL,
NULL}},
+ {"PB3", 1, 3, {"gpio_in", "gpio_out", "ir0", NULL, NULL, NULL, NULL,
NULL}},
+ {"PB4", 1, 4, {"gpio_in", "gpio_out", "ir0", NULL, NULL, NULL, NULL,
NULL}},
+ {"PB5", 1, 5, {"gpio_in", "gpio_out", "i2s", "ac97", NULL, NULL,
NULL, NULL}},
+ {"PB6", 1, 6, {"gpio_in", "gpio_out", "i2s", "ac97", NULL, NULL,
NULL, NULL}},
+ {"PB7", 1, 7, {"gpio_in", "gpio_out", "i2s", "ac97", NULL, NULL,
NULL, NULL}},
+ {"PB8", 1, 8, {"gpio_in", "gpio_out", "i2s", "ac97", NULL, NULL,
NULL, NULL}},
+ {"PB9", 1, 9, {"gpio_in", "gpio_out", "i2s", NULL, NULL, NULL, NULL,
NULL}},
+ {"PB10", 1, 10, {"gpio_in", "gpio_out", "i2s", NU
Re: svn commit: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd
On Fri, Aug 19, 2016 at 09:12:53PM +1000, Bruce Evans wrote: > I normally use my version of biosboot for boot2. I improved its caching > just a couple of years ago. It was using 9K buffer optimized for 1440K > floppies. Now it uses a 32K buffer. Booting a 5.5MB kernel takes a > fraction of a second. That looks like change that everyone would benefit from. Consider posting a patch or committing it yourself. ;-) > Of course I don't use modules, so not many seeks are needed. Why not, they're convenient (apart from "kernel version mismatch" crap that I keep hitting now and then)? AFAIR they were slow to load at some point but that was (not so) recently fixed. ./danfe ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304142 - head/usr.sbin/bsdinstall/partedit
On Fri, Aug 19, 2016 at 12:51 AM, Dag-Erling Smørgrav wrote: > Warner Losh writes: >> Allan Jude writes: >> > Which makes more sense: >> > >> > A) If stripesize == 0, use some sane value like 4096 >> >> I don't like this. >> >> > B) Some other combination that uses the reported stripe size, unless it >> > is 0, in which case it uses 4096 (or some other value controlled by a >> > different new sysctl) >> >> Don't like this so much. >> >> > C) create kern.geom.min_stripe_size with a default of 512, but users can >> > set 4096 if they use only 4k devices. (doesn't really solve the problem >> > for the installer) >> >> Default it to 4k, and allow users to set it to 512. If the drive >> reports < this value >> report this value instead. > > I don't like either option. Option D (which I don't like either, but > which should at least work in most cases) is a sysctl that specifies a > minimum factor, and set the reported stripe size to the least common > multiple of that number and the actual stripe or sector size. This is > what my bsdinstall patch does. However, I think that pushing this down > to a layer where it will affect all applications is a terrible idea, > because we have no way of knowing what will break[*], and it can > seriously mislead users and hinder troubleshooting - especially if it is > enabled by default rather than only when necessary. I took a look into the implications of doing a 4k stripesize 'automatically' this morning. I found a few places in g_part where it would actively hurt when coupled with gpart's insistence on aligning things. So I now think it's a bad idea. This will make it harder for FreeBSD to generate arbitrary disk layouts. And I'm not too sure about what things like gstripe would report as a result and if this would actually interfere if you had a large, but not power of two stripe size. > I don't think it's a good idea to enforce stripe alignment everywhere, > either. It works for partitions because they are very large relative to > the stripe size, and at worst we will waste a few millionths of the disk > on inter-partition gaps, which should only occur between the partition > table and the boot partition, and possibly, if the stripe size is very > large, between the boot partition and the swap partition. But forcing > filesystems to respect the stripe size will lead to no end of trouble, > because RAID volumes can have stripe sizes of 16 kB or more. I think it > is important to align partitions during installation because of the huge > performance impact of misaligned partitions on AF disks, but despite > what Nathan claims, I never advocated applying the same logic > everywhere. Yea, having poked at it for just a little while, I agree. The installer is the right place to make sure we don't cross-thread the 4k sectors. Stripe size means too many other things to have it be useful in that context. Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd
On Fri, Aug 19, 2016 at 3:35 AM, Toomas Soome wrote: > >> On 19. aug 2016, at 12:24, Konstantin Belousov wrote: >> >> On Fri, Aug 19, 2016 at 11:50:35AM +0300, Toomas Soome wrote: >>> On 19. aug 2016, at 10:39, Konstantin Belousov wrote: On Thu, Aug 18, 2016 at 09:28:57PM -0600, Warner Losh wrote: > On Thu, Aug 18, 2016 at 12:50 AM, Julian Elischer > wrote: >> On 16/08/2016 4:54 AM, John Baldwin wrote: >>> >>> On Monday, August 15, 2016 08:38:02 PM John Baldwin wrote: Author: jhb Date: Mon Aug 15 20:38:02 2016 New Revision: 304187 URL: https://svnweb.freebsd.org/changeset/base/304187 Log: Remove the mcd(4) driver for Mitsumi CD-ROM players. This is a driver for a pre-ATAPI ISA CD-ROM adapter. As noted in the manpage, this driver is only useful as a backend to cdcontrol to play audio CDs since it doesn't use DMA, so its data performance is "abysmal" (and that was true in the mid 90's). >>> >>> No one stepped up to test patches for it either when I last posted >>> patches >>> to >>> convert it from timeout(9) to callout(9). I have a few more drivers >>> that >>> are >>> both very old and that people have no business using in 12 (think ISA >>> adapters that don't do DMA and can't be used with pccard) that I will be >>> removing over the next little while. I brought up a list of drivers on >>> arch@ >>> a couple of years ago and the conversation drifted off into the weeds >>> about >>> trimming GENERIC, etc. No one objected to the specific drivers I listed >>> though (and I got a few pleas of "please remove"). If someone shows up >>> desperately clutching an ISA adapter they can always dig up the source >>> from >>> svn and deal with forward porting it for whatever API changes have >>> happened >>> since it was removed. >> >> >> I would imagine any machine still holding one of these probably has not >> enough memory to run FreeBSD. >> >> would we still run in 2MB? > > With insane levels of tuning, we can run in 32MB userland that can do > things. Even 64MB is tight w/o some tuning. 16MB is almost certainly > right out except for very specialized situations. 2MB? We can't even > load the loader in that :(. Oh, and all these memory configs are only > possible if you tweak the loader's block cache... > 32MB is quite usable. Without any tuning, you get slightly less than 10MB for userspace, which is enough to for many things, and plenty if swap is added. Note that you cannot boot on such configurations since loader was broken, but if you do manage to jump to kernel, things were fine several months ago. I tested my relatively recent OOM changes on 32MB qemu config. > Warner >>> >>> If the target is to go as low memory as possible, sure, you can strip all >>> off, from boot loader point, you should load kernel from stage2 and not use >>> loader at all (you can load and jump kernel even now from stage2, assuming >>> it wont need any special configuration from loader config) etc etc. This >>> means highly specialized build and has nothing to do with generic all >>> purpose system. >>> >> Why you describe this as an 'alternative' ? Before that loader changes, >> I regularly tested on 32MB qemy i386 image and 64MB amd64 image. I do >> not see anything extreme in these configs. They use normal boot path, >> which provides kernels with debugging symbols, metadata, loaded modules >> etc. Why should I use deficient boot2-only loading, which, additionally, >> cannot work on amd64 ? >> >> More, this is the only reasonable way for most developers to ensure that >> system is still usable on tiny configs found on embedded devices. Right >> now the min which I have to set up is 128MB, and VM changes are simply not >> tested on anything smaller. It is guaranteed that small systems will grow >> regressions fast. And I will not jump through the hoops to mitigate >> breakage induced by other people' changes. >> >>> Also at some point, there is an question about how reasonable it is to have >>> such configuration as part of generic code base for special bits like boot >>> loader itself, as the problem is, testing all those variants is becoming >>> impossible and even keeping reasonable code base in all of the #if #else >>> #endif spaghetti is getting quite hard and error prone. >>> From developers point of view, it is not really encouraging to have possible feedback like ???oh, but you did break my 32MB system boot??? ;) This does bring back some memories however. For first 2 unix systems I was dealing with, one had 8MB and another had 12MB of memory??? it was ~ 1992-1993;) >>> >> Not mine, but you (?) indirectly broke system for people who do use 32MB >> on oth
Re: svn commit: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd
On Fri, Aug 19, 2016 at 5:27 AM, Konstantin Belousov wrote: > On Fri, Aug 19, 2016 at 09:12:53PM +1000, Bruce Evans wrote: >> On Fri, 19 Aug 2016, Konstantin Belousov wrote: >> >> > On Thu, Aug 18, 2016 at 09:28:57PM -0600, Warner Losh wrote: >> >> On Thu, Aug 18, 2016 at 12:50 AM, Julian Elischer >> >> wrote: >> >>> On 16/08/2016 4:54 AM, John Baldwin wrote: >> >> On Monday, August 15, 2016 08:38:02 PM John Baldwin wrote: >> > ,,, >> > Log: >> >Remove the mcd(4) driver for Mitsumi CD-ROM players. >> > This is a driver for a pre-ATAPI ISA CD-ROM adapter. As noted in >> >the manpage, this driver is only useful as a backend to cdcontrol to >> >play audio CDs since it doesn't use DMA, so its data performance is >> >"abysmal" (and that was true in the mid 90's). >> >> No one stepped up to test patches for it either when I last posted >> patches >> to >> convert it from timeout(9) to callout(9). I have a few more drivers >> that >> are >> ... >> >>> >> >>> I would imagine any machine still holding one of these probably has not >> >>> enough memory to run FreeBSD. >> >>> >> >>> would we still run in 2MB? >> >> >> >> With insane levels of tuning, we can run in 32MB userland that can do >> >> things. Even 64MB is tight w/o some tuning. 16MB is almost certainly >> >> right out except for very specialized situations. 2MB? We can't even >> >> load the loader in that :(. Oh, and all these memory configs are only >> >> possible if you tweak the loader's block cache... >> > >> > 32MB is quite usable. Without any tuning, you get slightly less than 10MB >> > for userspace, which is enough to for many things, and plenty if swap is >> > added. >> >> No, 32MB needs lots of needs tuning. -current seems to need about 16MB >> more than just a few months ago when I last discussed this with you. >> My i386 system doesn't have many drivers or a bloated userland (*), >> but it took the following tuning plus my PAE tuning fixes to boot in >> 32MB: >> - disable [l]em1 >> - reduce tx and buffers to 256 for em0. They default to 4096 for em. That >>is something like 8K * 1500 bytes = 12MB for em0 alone. lem[1] wants >>another 12MB. I think this is not all statically allocated, but the >>drivers hang onto that much. >> This now longer works. -current without my PAE tuning fixes hangs mounting >> root or in usb initialization with this tuning and 40MB. -current with my >> PAE tuning fixes hangs similarly with 32MB; with 40MB it boots to the >> start of multiuser but then hangs (it starts 1 getty, then 2 sendmails >> and kills them with "out of swap space") and 1 rpcbind (also killed). I >> don't use swap, but it was needed 20 years ago on a system that actually >> had 32MB of memory. >> >> (*) /bin/sh doing nothing much in -current i386: size 6532K res 1924K >> /bin/shin my ~5.2 i386: size 864K res 592K >> >> The kernel size is 5.5MB text 370K data 2.2MB bss (lots of bloat in bss >> for debugging and vt). In single user mode, with 40MB to start, there >> is 22116K wired and 2516K free. A few programs can be run in 2516K >> without swap if they have res 592K and not 1924K. >> >> > Note that you cannot boot on such configurations since loader was broken, >> > but if you do manage to jump to kernel, things were fine several months >> > ago. I tested my relatively recent OOM changes on 32MB qemu config. >> >> I have no problems booting such configuratations since I don't use the >> current loader and only use old loader to change the environment to >> set up special configurations like this. I use my version of biosboot >> for boot2. This requires fixing 2 layers of complicated breakage in >> init386(). vm86 is now used before the TSS and PIC resources that it >> uses are initialized, but only in paths that are not normally used >> because they are for memory sizing that is normally done by loader >> :-(. >> >> I normally use my version of biosboot for boot2. I improved its caching >> just a couple of years ago. It was using 9K buffer optimized for 1440K >> floppies. Now it uses a 32K buffer. Booting a 5.5MB kernel takes a >> fraction of a second. Of course I don't use modules, so not many seeks >> are needed. > > Of course I use modules and do not use GENERIC. I just tried: with today > HEAD, and old loader on 32MB VM, I get 11MB free in single-user mode. > Active+inactive is ~4MB, and 1M is eaten by buffers, which is about right > for init+/bin/sh+top idle system. The situation on x86 must be a lot better than arm. My old Atmel boards with 32MB have < 1MB free when booted to the login prompt (more at single user) and need special tuning to reduce the 5MB of network buffers allocated to be anything approaching useful. Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubsc
Re: svn commit: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd
On Fri, 19 Aug 2016, Alexey Dokuchaev wrote: On Fri, Aug 19, 2016 at 09:12:53PM +1000, Bruce Evans wrote: I normally use my version of biosboot for boot2. I improved its caching just a couple of years ago. It was using 9K buffer optimized for 1440K floppies. Now it uses a 32K buffer. Booting a 5.5MB kernel takes a fraction of a second. That looks like change that everyone would benefit from. Consider posting a patch or committing it yourself. ;-) Oops, it is actually loading that takes a fraction of a second. Not much different than with -current boot2 or old loader. -current boot2 also works for me, but I managed to squeeze more of the features that I want into biosboot (everything except ufs2). Booting from the boot1 prompt takes 20-25 seconds here. Of course I don't use modules, so not many seeks are needed. Why not, they're convenient (apart from "kernel version mismatch" crap that I keep hitting now and then)? AFAIR they were slow to load at some point but that was (not so) recently fixed. Same reason that I don't use shared libraries if possible - they are larger, slower and more difficult to debug. For kernel development, the version control problem is large. Modules are good for avoiding rebooting when developing something in a single module, but I usually work on either small changes that panic often or system wide-changes that need recompiling everything. Both require rebooting a lot to test, and I can rebuild a kernel and without modules and reboot it almost faster than I can remember where the modules directories are. Bruce ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304142 - head/usr.sbin/bsdinstall/partedit
On 2016-08-19 00:15, Warner Losh wrote: >> Which makes more sense: >> >> A) If stripesize == 0, use some sane value like 4096 > > I don't like this. > >> B) Some other combination that uses the reported stripe size, unless it >> is 0, in which case it uses 4096 (or some other value controlled by a >> different new sysctl) > > Don't like this so much. > >> C) create kern.geom.min_stripe_size with a default of 512, but users can >> set 4096 if they use only 4k devices. (doesn't really solve the problem >> for the installer) > > Default it to 4k, and allow users to set it to 512. If the drive > reports < this value > report this value instead. You'll need to make this a tunable. Then the upper > layers wouldn't care. There's a small chance that some SD cards might be > reporting values that are too large. But I think it is confined to SD cards > and > if I see too many more I'll do something specific in the SD driver. > > Warner > I think I mentioned this earlier in the thread,, but I do have a USB thumbstick that reports an 8mb stripe size. But I agree, I think a sysctl where you set the minimum (default 4096, but settable to 512), that is a tunable that can be overwritten in loader.conf What do we want for the logic as to what values it can be set to? Any power of 2 greater than or equal to 512? -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: svn commit: r304142 - head/usr.sbin/bsdinstall/partedit
On 2016-08-19 10:13, Warner Losh wrote: > On Fri, Aug 19, 2016 at 12:51 AM, Dag-Erling Smørgrav wrote: >> Warner Losh writes: >>> Allan Jude writes: Which makes more sense: A) If stripesize == 0, use some sane value like 4096 >>> >>> I don't like this. >>> B) Some other combination that uses the reported stripe size, unless it is 0, in which case it uses 4096 (or some other value controlled by a different new sysctl) >>> >>> Don't like this so much. >>> C) create kern.geom.min_stripe_size with a default of 512, but users can set 4096 if they use only 4k devices. (doesn't really solve the problem for the installer) >>> >>> Default it to 4k, and allow users to set it to 512. If the drive >>> reports < this value >>> report this value instead. >> >> I don't like either option. Option D (which I don't like either, but >> which should at least work in most cases) is a sysctl that specifies a >> minimum factor, and set the reported stripe size to the least common >> multiple of that number and the actual stripe or sector size. This is >> what my bsdinstall patch does. However, I think that pushing this down >> to a layer where it will affect all applications is a terrible idea, >> because we have no way of knowing what will break[*], and it can >> seriously mislead users and hinder troubleshooting - especially if it is >> enabled by default rather than only when necessary. > > I took a look into the implications of doing a 4k stripesize 'automatically' > this morning. I found a few places in g_part where it would actively > hurt when coupled with gpart's insistence on aligning things. So I > now think it's a bad idea. This will make it harder for FreeBSD to > generate arbitrary disk layouts. And I'm not too sure about what > things like gstripe would report as a result and if this would actually > interfere if you had a large, but not power of two stripe size. > >> I don't think it's a good idea to enforce stripe alignment everywhere, >> either. It works for partitions because they are very large relative to >> the stripe size, and at worst we will waste a few millionths of the disk >> on inter-partition gaps, which should only occur between the partition >> table and the boot partition, and possibly, if the stripe size is very >> large, between the boot partition and the swap partition. But forcing >> filesystems to respect the stripe size will lead to no end of trouble, >> because RAID volumes can have stripe sizes of 16 kB or more. I think it >> is important to align partitions during installation because of the huge >> performance impact of misaligned partitions on AF disks, but despite >> what Nathan claims, I never advocated applying the same logic >> everywhere. > > Yea, having poked at it for just a little while, I agree. The installer is the > right place to make sure we don't cross-thread the 4k sectors. Stripe size > means too many other things to have it be useful in that context. > > Warner > Maybe instead we just change gpart to default to 4k alignment, but users can always override with -a 512 or some other value? Then the installer behaves the same as a user typing 'gpart', but we don't mess with the entire geom layer? -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: svn commit: r304142 - head/usr.sbin/bsdinstall/partedit
On 08/18/16 22:33, Warner Losh wrote: On Aug 18, 2016, at 11:21 PM, Nathan Whitehorn wrote: On 08/18/16 21:15, Warner Losh wrote: On Thu, Aug 18, 2016 at 6:56 AM, Allan Jude wrote: On 08/18/16 05:50 AM, Dag-Erling Smørgrav wrote: Nathan Whitehorn writes: OK. In which configurations? My Dell servers, for instance, don't do this. How are they set up? What drivers are being used? Is this something that affects passthrough disks, RAIDs, disk images? Most LSI MegaRAID controllers don't have real passthrough, only JBOD. You can query the drive with "camcontrol identify passX", but the controller does not report a stripe size for the volume (mfidY). The point is that *if the reported stripe size is wrong*, more things than partition alignment in the installer will suffer for it. It's not wrong, it's non-existent, and I'm getting really tired of repeating myself. Fixing the installer with a bandaid in the run-up to a release is fine, but *we need to fix the underlying problem*. We can't, because hardware sucks, and I'm getting really tired of repeating myself. DES Which makes more sense: A) If stripesize == 0, use some sane value like 4096 I don't like this. B) Some other combination that uses the reported stripe size, unless it is 0, in which case it uses 4096 (or some other value controlled by a different new sysctl) Don't like this so much. C) create kern.geom.min_stripe_size with a default of 512, but users can set 4096 if they use only 4k devices. (doesn't really solve the problem for the installer) Default it to 4k, and allow users to set it to 512. If the drive reports < this value report this value instead. You'll need to make this a tunable. Then the upper layers wouldn't care. There's a small chance that some SD cards might be reporting values that are too large. But I think it is confined to SD cards and if I see too many more I'll do something specific in the SD driver. Warner That sounds good to me and I think can clean up a lot of code and potential foot-shooting. Who is planning to make the patch? I'm happy to do anything that would be helpful. The patch is super-easy, but I need to get the concept validated and make sure that it does not have unintended side effects. Warner Sounds great. There is no urgency here -- we have a good solution for 11.0 already -- so taking time to do it right sounds good. I believe stripesize is only consumed by disk formatting tools, so unintended side effects at least should be minimal. -Nathan ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304142 - head/usr.sbin/bsdinstall/partedit
On 08/19/16 08:57, Allan Jude wrote: On 2016-08-19 10:13, Warner Losh wrote: On Fri, Aug 19, 2016 at 12:51 AM, Dag-Erling Smørgrav wrote: Warner Losh writes: Allan Jude writes: Which makes more sense: A) If stripesize == 0, use some sane value like 4096 I don't like this. B) Some other combination that uses the reported stripe size, unless it is 0, in which case it uses 4096 (or some other value controlled by a different new sysctl) Don't like this so much. C) create kern.geom.min_stripe_size with a default of 512, but users can set 4096 if they use only 4k devices. (doesn't really solve the problem for the installer) Default it to 4k, and allow users to set it to 512. If the drive reports < this value report this value instead. I don't like either option. Option D (which I don't like either, but which should at least work in most cases) is a sysctl that specifies a minimum factor, and set the reported stripe size to the least common multiple of that number and the actual stripe or sector size. This is what my bsdinstall patch does. However, I think that pushing this down to a layer where it will affect all applications is a terrible idea, because we have no way of knowing what will break[*], and it can seriously mislead users and hinder troubleshooting - especially if it is enabled by default rather than only when necessary. I took a look into the implications of doing a 4k stripesize 'automatically' this morning. I found a few places in g_part where it would actively hurt when coupled with gpart's insistence on aligning things. So I now think it's a bad idea. This will make it harder for FreeBSD to generate arbitrary disk layouts. And I'm not too sure about what things like gstripe would report as a result and if this would actually interfere if you had a large, but not power of two stripe size. I don't think it's a good idea to enforce stripe alignment everywhere, either. It works for partitions because they are very large relative to the stripe size, and at worst we will waste a few millionths of the disk on inter-partition gaps, which should only occur between the partition table and the boot partition, and possibly, if the stripe size is very large, between the boot partition and the swap partition. But forcing filesystems to respect the stripe size will lead to no end of trouble, because RAID volumes can have stripe sizes of 16 kB or more. I think it is important to align partitions during installation because of the huge performance impact of misaligned partitions on AF disks, but despite what Nathan claims, I never advocated applying the same logic everywhere. Yea, having poked at it for just a little while, I agree. The installer is the right place to make sure we don't cross-thread the 4k sectors. Stripe size means too many other things to have it be useful in that context. Warner Maybe instead we just change gpart to default to 4k alignment, but users can always override with -a 512 or some other value? Then the installer behaves the same as a user typing 'gpart', but we don't mess with the entire geom layer? ZFS also looks at this, so we would need it there, and there might be a few others. At the very least, gpart and the installer should have the same behavior. Warner, could you elaborate on what you mean by "cross-threading"? Are you worried about nested partition tables in which the outer one is misaligned? Having the disk drivers report a 4K stripesize seems to have worked so far; I'm not sure how reporting it more often would cause problems. You wouldn't want all drivers, or all GEOM layers, to do this, of course. If the problem is that "stripe size" has an overloaded meaning, we could easily add another GEOM property. -Nathan ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304476 - head/lib/libc/sys
Author: jhb Date: Fri Aug 19 17:37:32 2016 New Revision: 304476 URL: https://svnweb.freebsd.org/changeset/base/304476 Log: Fix various nits in the aio operation manpages. - Avoid double use of "request" in a single sentence. Instead, describe aio_sigevent as being used to request notification of the associated operation's completion. This matches the language used to describe aio_sigevent in aio(4). - Simplify the prohibition on modifying buffers while requests are in flight. - Fix case mismatch. - Drop note about not using stack variables. C programmers should be able to figure out if a stack variable is safe based on the later warning about the life cycle requirements of control blocks. - Remove prohibition on modifying the I/O buffer for aio_fsync() since it does not use an I/O buffer. For aio_mlock(), prohibit modifications to the mapping (e.g. due to mprotect, munmap, mmap, etc.) but do not prohibit modifications to the memory backing the buffer (stores into the pages backing the buffer). Requested by: wblock (1,2), kib (4) Reviewed by: kib, rpokala, wblock MFC after:3 days Sponsored by: Chelsio Communications Differential Revision:https://reviews.freebsd.org/D7462 Modified: head/lib/libc/sys/aio_fsync.2 head/lib/libc/sys/aio_mlock.2 head/lib/libc/sys/aio_read.2 head/lib/libc/sys/aio_write.2 Modified: head/lib/libc/sys/aio_fsync.2 == --- head/lib/libc/sys/aio_fsync.2 Fri Aug 19 17:03:14 2016 (r304475) +++ head/lib/libc/sys/aio_fsync.2 Fri Aug 19 17:37:32 2016 (r304476) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd July 21, 2016 +.Dd August 19, 2016 .Dt AIO_FSYNC 2 .Os .Sh NAME @@ -74,16 +74,14 @@ the call returns without having enqueued .Pp The .Fa iocb->aio_sigevent -structure can be used to request notification of the request's +structure can be used to request notification of the operation's completion as described in .Xr aio 4 . .Sh RESTRICTIONS -The asynchronous I/O Control Block structure pointed to by +The Asynchronous I/O Control Block structure pointed to by .Fa iocb must remain valid until the operation has completed. -For this reason, use of auto (stack) variables -for these objects is discouraged. .Pp The asynchronous I/O control buffer .Fa iocb @@ -91,9 +89,8 @@ should be zeroed before the .Fn aio_fsync call to avoid passing bogus context information to the kernel. .Pp -Modifications of the Asynchronous I/O Control Block structure or the -buffer contents after the request has been enqueued, but before the -request has completed, are not allowed. +Modification of the Asynchronous I/O Control Block structure is not allowed +while the request is queued. .Sh RETURN VALUES .Rv -std aio_fsync .Sh ERRORS Modified: head/lib/libc/sys/aio_mlock.2 == --- head/lib/libc/sys/aio_mlock.2 Fri Aug 19 17:03:14 2016 (r304475) +++ head/lib/libc/sys/aio_mlock.2 Fri Aug 19 17:37:32 2016 (r304476) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd July 21, 2016 +.Dd August 19, 2016 .Dt AIO_MLOCK 2 .Os .Sh NAME @@ -67,7 +67,7 @@ then the call returns without having enq .Pp The .Fa iocb->aio_sigevent -structure can be used to request notification of the request's +structure can be used to request notification of the operation's completion as described in .Xr aio 4 . .Sh RESTRICTIONS @@ -77,8 +77,6 @@ and the buffer that the .Fa iocb->aio_buf member of that structure references must remain valid until the operation has completed. -For this reason, use of auto (stack) variables -for these objects is discouraged. .Pp The asynchronous I/O control buffer .Fa iocb @@ -87,8 +85,8 @@ should be zeroed before the call to avoid passing bogus context information to the kernel. .Pp Modifications of the Asynchronous I/O Control Block structure or the -buffer contents after the request has been enqueued, but before the -request has completed, are not allowed. +memory mapping described by the virtual address range are not allowed +while the request is queued. .Sh RETURN VALUES .Rv -std aio_mlock .Sh ERRORS Modified: head/lib/libc/sys/aio_read.2 == --- head/lib/libc/sys/aio_read.2Fri Aug 19 17:03:14 2016 (r304475) +++ head/lib/libc/sys/aio_read.2Fri Aug 19 17:37:32 2016 (r304476) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd July 21, 2016 +.Dd August 19, 2016 .Dt AIO_READ 2 .Os .Sh NAME @@ -82,7 +82,7 @@ not be referenced after the request is e .Pp The .Fa iocb->aio_sigevent -structure can be used to request notification of the request's +structure can be used to request notification of the operation's completion as described in .Xr aio 4 . .Sh RESTRICTIONS @@ -92,8 +92,6 @
svn commit: r304478 - in head: sys/compat/cloudabi sys/compat/cloudabi64 sys/contrib/cloudabi usr.bin/truss
Author: ed
Date: Fri Aug 19 17:49:35 2016
New Revision: 304478
URL: https://svnweb.freebsd.org/changeset/base/304478
Log:
Import the new automatically generated system call table for CloudABI.
Now that we've switched over to using the vDSO on CloudABI, it becomes a
lot easier for us to phase out old features. System call numbering is no
longer something that's part of the ABI. It's fully based on names. As
long as the numbering used by the kernel and the vDSO is consistent
(which it always is), it's all right.
Let's put this to the test by removing a system call (thread_tcb_set())
that's already unused for quite some time now, but was only left intact
to serve as a placeholder. Sync in the new system call table that uses
alphabetic sorting of system calls.
Obtained from:https://github.com/NuxiNL/cloudabi
Added:
head/sys/contrib/cloudabi/syscalls64.master
Deleted:
head/sys/contrib/cloudabi/syscalls.master
Modified:
head/sys/compat/cloudabi/cloudabi_thread.c
head/sys/compat/cloudabi64/Makefile
head/sys/compat/cloudabi64/cloudabi64_proto.h
head/sys/compat/cloudabi64/cloudabi64_syscall.h
head/sys/compat/cloudabi64/cloudabi64_syscalls.c
head/sys/compat/cloudabi64/cloudabi64_sysent.c
head/sys/compat/cloudabi64/cloudabi64_systrace_args.c
head/sys/contrib/cloudabi/cloudabi64_types.h
head/sys/contrib/cloudabi/cloudabi_types.h
head/sys/contrib/cloudabi/cloudabi_types_common.h
head/sys/contrib/cloudabi/cloudabi_vdso_aarch64.c
head/sys/contrib/cloudabi/cloudabi_vdso_x86_64.c
head/usr.bin/truss/syscalls.c
Modified: head/sys/compat/cloudabi/cloudabi_thread.c
==
--- head/sys/compat/cloudabi/cloudabi_thread.c Fri Aug 19 17:48:47 2016
(r304477)
+++ head/sys/compat/cloudabi/cloudabi_thread.c Fri Aug 19 17:49:35 2016
(r304478)
@@ -60,14 +60,6 @@ cloudabi_sys_thread_exit(struct thread *
}
int
-cloudabi_sys_thread_tcb_set(struct thread *td,
-struct cloudabi_sys_thread_tcb_set_args *uap)
-{
-
- return (cpu_set_user_tls(td, uap->tcb));
-}
-
-int
cloudabi_sys_thread_yield(struct thread *td,
struct cloudabi_sys_thread_yield_args *uap)
{
Modified: head/sys/compat/cloudabi64/Makefile
==
--- head/sys/compat/cloudabi64/Makefile Fri Aug 19 17:48:47 2016
(r304477)
+++ head/sys/compat/cloudabi64/Makefile Fri Aug 19 17:49:35 2016
(r304478)
@@ -8,7 +8,7 @@ sysent: cloudabi64_sysent.c cloudabi64_s
cloudabi64_sysent.c cloudabi64_syscall.h cloudabi64_proto.h \
cloudabi64_syscalls.c cloudabi64_systrace_args.c: \
-../../kern/makesyscalls.sh ../../contrib/cloudabi/syscalls.master \
+../../kern/makesyscalls.sh ../../contrib/cloudabi/syscalls64.master \
syscalls.conf
- sh ../../kern/makesyscalls.sh ../../contrib/cloudabi/syscalls.master \
+ sh ../../kern/makesyscalls.sh ../../contrib/cloudabi/syscalls64.master \
syscalls.conf
Modified: head/sys/compat/cloudabi64/cloudabi64_proto.h
==
--- head/sys/compat/cloudabi64/cloudabi64_proto.h Fri Aug 19 17:48:47
2016(r304477)
+++ head/sys/compat/cloudabi64/cloudabi64_proto.h Fri Aug 19 17:49:35
2016(r304478)
@@ -3,7 +3,7 @@
*
* DO NOT EDIT-- this file is automatically generated.
* $FreeBSD$
- * created from FreeBSD: head/sys/contrib/cloudabi/syscalls.master 297468
2016-03-31 18:50:06Z ed
+ * created from FreeBSD
*/
#ifndef _CLOUDABI64_SYSPROTO_H_
@@ -236,6 +236,14 @@ struct cloudabi64_sys_poll_args {
char out_l_[PADL_(cloudabi64_event_t *)]; cloudabi64_event_t * out;
char out_r_[PADR_(cloudabi64_event_t *)];
char nsubscriptions_l_[PADL_(size_t)]; size_t nsubscriptions; char
nsubscriptions_r_[PADR_(size_t)];
};
+struct cloudabi64_sys_poll_fd_args {
+ char fd_l_[PADL_(cloudabi_fd_t)]; cloudabi_fd_t fd; char
fd_r_[PADR_(cloudabi_fd_t)];
+ char in_l_[PADL_(const cloudabi64_subscription_t *)]; const
cloudabi64_subscription_t * in; char in_r_[PADR_(const
cloudabi64_subscription_t *)];
+ char nin_l_[PADL_(size_t)]; size_t nin; char nin_r_[PADR_(size_t)];
+ char out_l_[PADL_(cloudabi64_event_t *)]; cloudabi64_event_t * out;
char out_r_[PADR_(cloudabi64_event_t *)];
+ char nout_l_[PADL_(size_t)]; size_t nout; char nout_r_[PADR_(size_t)];
+ char timeout_l_[PADL_(const cloudabi64_subscription_t *)]; const
cloudabi64_subscription_t * timeout; char timeout_r_[PADR_(const
cloudabi64_subscription_t *)];
+};
struct cloudabi_sys_proc_exec_args {
char fd_l_[PADL_(cloudabi_fd_t)]; cloudabi_fd_t fd; char
fd_r_[PADR_(cloudabi_fd_t)];
char data_l_[PADL_(const void *)]; const void * data; char
data_r_[PADR_(const void *)];
@@ -302,20 +310,9 @@ struct cloudabi_sys_thread_exit_args {
char lock_l_[PADL_(clouda
svn commit: r304479 - head/sys/dev/cxgbe/common
Author: jhb
Date: Fri Aug 19 17:49:49 2016
New Revision: 304479
URL: https://svnweb.freebsd.org/changeset/base/304479
Log:
Add structures for VF-specific adapter parameters.
While here, mark which parameters are PF-specific and which are
VF-specific.
Sponsored by: Chelsio Communications
Differential Revision:https://reviews.freebsd.org/D7508
Modified:
head/sys/dev/cxgbe/common/common.h
Modified: head/sys/dev/cxgbe/common/common.h
==
--- head/sys/dev/cxgbe/common/common.h Fri Aug 19 17:49:35 2016
(r304478)
+++ head/sys/dev/cxgbe/common/common.h Fri Aug 19 17:49:49 2016
(r304479)
@@ -280,12 +280,52 @@ struct chip_params {
u16 mps_tcam_size;
};
+/* VF-only parameters. */
+
+/*
+ * Global Receive Side Scaling (RSS) parameters in host-native format.
+ */
+struct rss_params {
+ unsigned int mode; /* RSS mode */
+ union {
+ struct {
+ u_int synmapen:1; /* SYN Map Enable */
+ u_int syn4tupenipv6:1; /* enable hashing 4-tuple IPv6 SYNs */
+ u_int syn2tupenipv6:1; /* enable hashing 2-tuple IPv6 SYNs */
+ u_int syn4tupenipv4:1; /* enable hashing 4-tuple IPv4 SYNs */
+ u_int syn2tupenipv4:1; /* enable hashing 2-tuple IPv4 SYNs */
+ u_int ofdmapen:1; /* Offload Map Enable */
+ u_int tnlmapen:1; /* Tunnel Map Enable */
+ u_int tnlalllookup:1; /* Tunnel All Lookup */
+ u_int hashtoeplitz:1; /* use Toeplitz hash */
+ } basicvirtual;
+ } u;
+};
+
+/*
+ * Maximum resources provisioned for a PCI VF.
+ */
+struct vf_resources {
+ unsigned int nvi; /* N virtual interfaces */
+ unsigned int neq; /* N egress Qs */
+ unsigned int nethctrl; /* N egress ETH or CTRL Qs */
+ unsigned int niqflint; /* N ingress Qs/w free list(s) & intr */
+ unsigned int niq; /* N ingress Qs */
+ unsigned int tc;/* PCI-E traffic class */
+ unsigned int pmask; /* port access rights mask */
+ unsigned int nexactf; /* N exact MPS filters */
+ unsigned int r_caps;/* read capabilities */
+ unsigned int wx_caps; /* write/execute capabilities */
+};
+
struct adapter_params {
struct sge_params sge;
- struct tp_params tp;
+ struct tp_params tp; /* PF-only */
struct vpd_params vpd;
struct pci_params pci;
- struct devlog_params devlog;
+ struct devlog_params devlog;/* PF-only */
+ struct rss_params rss; /* VF-only */
+ struct vf_resources vfres; /* VF-only */
unsigned int sf_size; /* serial flash size in bytes */
unsigned int sf_nsec; /* # of flash sectors */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304481 - head/sys/contrib/cloudabi
Author: ed Date: Fri Aug 19 17:51:52 2016 New Revision: 304481 URL: https://svnweb.freebsd.org/changeset/base/304481 Log: Add missing SVN keywords keyword. Modified: Directory Properties: head/sys/contrib/cloudabi/syscalls64.master (props changed) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304482 - head/sys/dev/cxgbe/common
Author: jhb
Date: Fri Aug 19 17:52:48 2016
New Revision: 304482
URL: https://svnweb.freebsd.org/changeset/base/304482
Log:
Adjust t4_port_init() to work with VF devices.
Specifically, the FW_PORT_CMD may or may not work for a VF (the PF
driver can choose whether or not to permit access to this command),
so don't attempt to fetch port information on a VF if permission is
denied by the PF.
Reviewed by: np
Sponsored by: Chelsio Communications
Differential Revision:https://reviews.freebsd.org/D7511
Modified:
head/sys/dev/cxgbe/common/t4_hw.c
Modified: head/sys/dev/cxgbe/common/t4_hw.c
==
--- head/sys/dev/cxgbe/common/t4_hw.c Fri Aug 19 17:51:52 2016
(r304481)
+++ head/sys/dev/cxgbe/common/t4_hw.c Fri Aug 19 17:52:48 2016
(r304482)
@@ -7938,15 +7938,26 @@ int t4_port_init(struct adapter *adap, i
} while ((adap->params.portvec & (1 << j)) == 0);
}
- c.op_to_portid = htonl(V_FW_CMD_OP(FW_PORT_CMD) |
- F_FW_CMD_REQUEST | F_FW_CMD_READ |
- V_FW_PORT_CMD_PORTID(j));
- c.action_to_len16 = htonl(
- V_FW_PORT_CMD_ACTION(FW_PORT_ACTION_GET_PORT_INFO) |
- FW_LEN16(c));
- ret = t4_wr_mbox(adap, mbox, &c, sizeof(c), &c);
- if (ret)
- return ret;
+ if (!(adap->flags & IS_VF) ||
+ adap->params.vfres.r_caps & FW_CMD_CAP_PORT) {
+ c.op_to_portid = htonl(V_FW_CMD_OP(FW_PORT_CMD) |
+ F_FW_CMD_REQUEST | F_FW_CMD_READ |
+ V_FW_PORT_CMD_PORTID(j));
+ c.action_to_len16 = htonl(
+ V_FW_PORT_CMD_ACTION(FW_PORT_ACTION_GET_PORT_INFO) |
+ FW_LEN16(c));
+ ret = t4_wr_mbox(adap, mbox, &c, sizeof(c), &c);
+ if (ret)
+ return ret;
+
+ ret = be32_to_cpu(c.u.info.lstatus_to_modtype);
+ p->mdio_addr = (ret & F_FW_PORT_CMD_MDIOCAP) ?
+ G_FW_PORT_CMD_MDIOADDR(ret) : -1;
+ p->port_type = G_FW_PORT_CMD_PTYPE(ret);
+ p->mod_type = G_FW_PORT_CMD_MODTYPE(ret);
+
+ init_link_config(&p->link_cfg, be16_to_cpu(c.u.info.pcap));
+ }
ret = t4_alloc_vi(adap, mbox, j, pf, vf, 1, addr, &rss_size);
if (ret < 0)
@@ -7959,14 +7970,6 @@ int t4_port_init(struct adapter *adap, i
p->vi[0].rss_size = rss_size;
t4_os_set_hw_addr(adap, p->port_id, addr);
- ret = be32_to_cpu(c.u.info.lstatus_to_modtype);
- p->mdio_addr = (ret & F_FW_PORT_CMD_MDIOCAP) ?
- G_FW_PORT_CMD_MDIOADDR(ret) : -1;
- p->port_type = G_FW_PORT_CMD_PTYPE(ret);
- p->mod_type = G_FW_PORT_CMD_MODTYPE(ret);
-
- init_link_config(&p->link_cfg, be16_to_cpu(c.u.info.pcap));
-
param = V_FW_PARAMS_MNEM(FW_PARAMS_MNEM_DEV) |
V_FW_PARAMS_PARAM_X(FW_PARAMS_PARAM_DEV_RSSINFO) |
V_FW_PARAMS_PARAM_YZ(p->vi[0].viid);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304483 - head/sys/contrib/cloudabi
Author: ed Date: Fri Aug 19 17:53:37 2016 New Revision: 304483 URL: https://svnweb.freebsd.org/changeset/base/304483 Log: Use the proper value for svn:keywords. Pointy hat to:me Modified: Directory Properties: head/sys/contrib/cloudabi/syscalls64.master (props changed) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304484 - head/sys/compat/cloudabi64
Author: ed
Date: Fri Aug 19 17:54:06 2016
New Revision: 304484
URL: https://svnweb.freebsd.org/changeset/base/304484
Log:
Regenerate system call table after r304483.
Modified:
head/sys/compat/cloudabi64/cloudabi64_proto.h
head/sys/compat/cloudabi64/cloudabi64_syscall.h
head/sys/compat/cloudabi64/cloudabi64_syscalls.c
head/sys/compat/cloudabi64/cloudabi64_sysent.c
Modified: head/sys/compat/cloudabi64/cloudabi64_proto.h
==
--- head/sys/compat/cloudabi64/cloudabi64_proto.h Fri Aug 19 17:53:37
2016(r304483)
+++ head/sys/compat/cloudabi64/cloudabi64_proto.h Fri Aug 19 17:54:06
2016(r304484)
@@ -3,7 +3,7 @@
*
* DO NOT EDIT-- this file is automatically generated.
* $FreeBSD$
- * created from FreeBSD
+ * created from FreeBSD: head/sys/contrib/cloudabi/syscalls64.master 304483
2016-08-19 17:53:37Z ed
*/
#ifndef _CLOUDABI64_SYSPROTO_H_
Modified: head/sys/compat/cloudabi64/cloudabi64_syscall.h
==
--- head/sys/compat/cloudabi64/cloudabi64_syscall.h Fri Aug 19 17:53:37
2016(r304483)
+++ head/sys/compat/cloudabi64/cloudabi64_syscall.h Fri Aug 19 17:54:06
2016(r304484)
@@ -3,7 +3,7 @@
*
* DO NOT EDIT-- this file is automatically generated.
* $FreeBSD$
- * created from FreeBSD
+ * created from FreeBSD: head/sys/contrib/cloudabi/syscalls64.master 304483
2016-08-19 17:53:37Z ed
*/
#defineCLOUDABI64_SYS_cloudabi_sys_clock_res_get 0
Modified: head/sys/compat/cloudabi64/cloudabi64_syscalls.c
==
--- head/sys/compat/cloudabi64/cloudabi64_syscalls.cFri Aug 19 17:53:37
2016(r304483)
+++ head/sys/compat/cloudabi64/cloudabi64_syscalls.cFri Aug 19 17:54:06
2016(r304484)
@@ -3,7 +3,7 @@
*
* DO NOT EDIT-- this file is automatically generated.
* $FreeBSD$
- * created from FreeBSD
+ * created from FreeBSD: head/sys/contrib/cloudabi/syscalls64.master 304483
2016-08-19 17:53:37Z ed
*/
const char *cloudabi64_syscallnames[] = {
Modified: head/sys/compat/cloudabi64/cloudabi64_sysent.c
==
--- head/sys/compat/cloudabi64/cloudabi64_sysent.c Fri Aug 19 17:53:37
2016(r304483)
+++ head/sys/compat/cloudabi64/cloudabi64_sysent.c Fri Aug 19 17:54:06
2016(r304484)
@@ -3,7 +3,7 @@
*
* DO NOT EDIT-- this file is automatically generated.
* $FreeBSD$
- * created from FreeBSD
+ * created from FreeBSD: head/sys/contrib/cloudabi/syscalls64.master 304483
2016-08-19 17:53:37Z ed
*/
#include
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304485 - head/sys/dev/cxgbe
Author: jhb Date: Fri Aug 19 17:54:51 2016 New Revision: 304485 URL: https://svnweb.freebsd.org/changeset/base/304485 Log: Reorder sysctls so that nodes shared with the VF driver are added first. This permits a single early return for VF devices in the routines that add sysctl nodes. Reviewed by: np Sponsored by: Chelsio Communications Differential Revision:https://reviews.freebsd.org/D7512 Modified: head/sys/dev/cxgbe/t4_main.c Modified: head/sys/dev/cxgbe/t4_main.c == --- head/sys/dev/cxgbe/t4_main.cFri Aug 19 17:54:06 2016 (r304484) +++ head/sys/dev/cxgbe/t4_main.cFri Aug 19 17:54:51 2016 (r304485) @@ -4592,6 +4592,32 @@ t4_sysctls(struct adapter *sc) SYSCTL_ADD_INT(ctx, children, OID_AUTO, "nports", CTLFLAG_RD, NULL, sc->params.nports, "# of ports"); + SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "doorbells", + CTLTYPE_STRING | CTLFLAG_RD, doorbells, sc->doorbells, + sysctl_bitfield, "A", "available doorbells"); + + SYSCTL_ADD_INT(ctx, children, OID_AUTO, "core_clock", CTLFLAG_RD, NULL, + sc->params.vpd.cclk, "core clock frequency (in KHz)"); + + SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "holdoff_timers", + CTLTYPE_STRING | CTLFLAG_RD, sc->params.sge.timer_val, + sizeof(sc->params.sge.timer_val), sysctl_int_array, "A", + "interrupt holdoff timer values (us)"); + + SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "holdoff_pkt_counts", + CTLTYPE_STRING | CTLFLAG_RD, sc->params.sge.counter_val, + sizeof(sc->params.sge.counter_val), sysctl_int_array, "A", + "interrupt holdoff packet counter values"); + + t4_sge_sysctls(sc, ctx, children); + + sc->lro_timeout = 100; + SYSCTL_ADD_INT(ctx, children, OID_AUTO, "lro_timeout", CTLFLAG_RW, + &sc->lro_timeout, 0, "lro inactive-flush timeout (in us)"); + + SYSCTL_ADD_INT(ctx, children, OID_AUTO, "debug_flags", CTLFLAG_RW, + &sc->debug_flags, 0, "flags to enable runtime debugging"); + SYSCTL_ADD_INT(ctx, children, OID_AUTO, "hw_revision", CTLFLAG_RD, NULL, chip_rev(sc), "chip hardware revision"); @@ -4612,10 +4638,6 @@ t4_sysctls(struct adapter *sc) SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "cfcsum", CTLFLAG_RD, NULL, sc->cfcsum, "config file checksum"); - SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "doorbells", - CTLTYPE_STRING | CTLFLAG_RD, doorbells, sc->doorbells, - sysctl_bitfield, "A", "available doorbells"); - #define SYSCTL_CAP(name, n, text) \ SYSCTL_ADD_PROC(ctx, children, OID_AUTO, #name, \ CTLTYPE_STRING | CTLFLAG_RD, caps_decoder[n], sc->name, \ @@ -4632,19 +4654,6 @@ t4_sysctls(struct adapter *sc) SYSCTL_CAP(fcoecaps, 8, "FCoE"); #undef SYSCTL_CAP - SYSCTL_ADD_INT(ctx, children, OID_AUTO, "core_clock", CTLFLAG_RD, NULL, - sc->params.vpd.cclk, "core clock frequency (in KHz)"); - - SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "holdoff_timers", - CTLTYPE_STRING | CTLFLAG_RD, sc->params.sge.timer_val, - sizeof(sc->params.sge.timer_val), sysctl_int_array, "A", - "interrupt holdoff timer values (us)"); - - SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "holdoff_pkt_counts", - CTLTYPE_STRING | CTLFLAG_RD, sc->params.sge.counter_val, - sizeof(sc->params.sge.counter_val), sysctl_int_array, "A", - "interrupt holdoff packet counter values"); - SYSCTL_ADD_INT(ctx, children, OID_AUTO, "nfilters", CTLFLAG_RD, NULL, sc->tids.nftids, "number of filters"); @@ -4652,15 +4661,6 @@ t4_sysctls(struct adapter *sc) CTLFLAG_RD, sc, 0, sysctl_temperature, "I", "chip temperature (in Celsius)"); - t4_sge_sysctls(sc, ctx, children); - - sc->lro_timeout = 100; - SYSCTL_ADD_INT(ctx, children, OID_AUTO, "lro_timeout", CTLFLAG_RW, - &sc->lro_timeout, 0, "lro inactive-flush timeout (in us)"); - - SYSCTL_ADD_INT(ctx, children, OID_AUTO, "debug_flags", CTLFLAG_RW, - &sc->debug_flags, 0, "flags to enable runtime debugging"); - #ifdef SBUF_DRAIN /* * dev.t4nex.X.misc. Marked CTLFLAG_SKIP to avoid information overload. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304487 - in head/sys: kern sys
Author: markj
Date: Fri Aug 19 17:57:14 2016
New Revision: 304487
URL: https://svnweb.freebsd.org/changeset/base/304487
Log:
Don't set P2_PTRACE_FSTP in a process that invokes ptrace(PT_TRACE_ME).
Such processes are stopped synchronously by a direct call to
ptracestop(SIGTRAP) upon exec. P2_PTRACE_FSTP causes the exec()ing thread
to suspend itself while waiting for a SIGSTOP that never arrives.
Reviewed by: kib
MFC after:3 days
Differential Revision:https://reviews.freebsd.org/D7576
Modified:
head/sys/kern/kern_fork.c
head/sys/kern/sys_process.c
head/sys/sys/proc.h
Modified: head/sys/kern/kern_fork.c
==
--- head/sys/kern/kern_fork.c Fri Aug 19 17:55:34 2016(r304486)
+++ head/sys/kern/kern_fork.c Fri Aug 19 17:57:14 2016(r304487)
@@ -1074,7 +1074,7 @@ fork_return(struct thread *td, struct tr
* parent's children, do it now.
*/
dbg = p->p_pptr->p_pptr;
- proc_set_traced(p);
+ proc_set_traced(p, true);
CTR2(KTR_PTRACE,
"fork_return: attaching to new child pid %d: oppid %d",
p->p_pid, p->p_oppid);
Modified: head/sys/kern/sys_process.c
==
--- head/sys/kern/sys_process.c Fri Aug 19 17:55:34 2016(r304486)
+++ head/sys/kern/sys_process.c Fri Aug 19 17:57:14 2016(r304487)
@@ -693,12 +693,13 @@ sys_ptrace(struct thread *td, struct ptr
#endif
void
-proc_set_traced(struct proc *p)
+proc_set_traced(struct proc *p, bool stop)
{
PROC_LOCK_ASSERT(p, MA_OWNED);
p->p_flag |= P_TRACED;
- p->p_flag2 |= P2_PTRACE_FSTP;
+ if (stop)
+ p->p_flag2 |= P2_PTRACE_FSTP;
p->p_ptevents = PTRACE_DEFAULT;
p->p_oppid = p->p_pptr->p_pid;
}
@@ -910,7 +911,7 @@ kern_ptrace(struct thread *td, int req,
switch (req) {
case PT_TRACE_ME:
/* set my trace flag and "owner" so it can read/write me */
- proc_set_traced(p);
+ proc_set_traced(p, false);
if (p->p_flag & P_PPWAIT)
p->p_flag |= P_PPTRACE;
CTR1(KTR_PTRACE, "PT_TRACE_ME: pid %d", p->p_pid);
@@ -927,7 +928,7 @@ kern_ptrace(struct thread *td, int req,
* The old parent is remembered so we can put things back
* on a "detach".
*/
- proc_set_traced(p);
+ proc_set_traced(p, true);
if (p->p_pptr != td->td_proc) {
proc_reparent(p, td->td_proc);
}
Modified: head/sys/sys/proc.h
==
--- head/sys/sys/proc.h Fri Aug 19 17:55:34 2016(r304486)
+++ head/sys/sys/proc.h Fri Aug 19 17:57:14 2016(r304487)
@@ -1010,7 +1010,7 @@ void proc_linkup(struct proc *p, struct
struct proc *proc_realparent(struct proc *child);
void proc_reap(struct thread *td, struct proc *p, int *status, int options);
void proc_reparent(struct proc *child, struct proc *newparent);
-void proc_set_traced(struct proc *p);
+void proc_set_traced(struct proc *p, bool stop);
struct pstats *pstats_alloc(void);
void pstats_fork(struct pstats *src, struct pstats *dst);
void pstats_free(struct pstats *ps);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304488 - head/sys/arm/arm
Author: manu
Date: Fri Aug 19 18:02:36 2016
New Revision: 304488
URL: https://svnweb.freebsd.org/changeset/base/304488
Log:
Keep boot parameters in ARM trampoline code
Currently boot parameters (r0 - r3) are forgotten in ARM trampoline code.
This patch save them at startup and restore them before jumping into kernel
_start() routine.
This is usefull when booting with Linux ABI and/or custom bootloader.
Submitted by: Grégory Soutadé
Reviewed by: imp
Differential Revision:https://reviews.freebsd.org/D7395
Modified:
head/sys/arm/arm/elf_trampoline.c
Modified: head/sys/arm/arm/elf_trampoline.c
==
--- head/sys/arm/arm/elf_trampoline.c Fri Aug 19 17:57:14 2016
(r304487)
+++ head/sys/arm/arm/elf_trampoline.c Fri Aug 19 18:02:36 2016
(r304488)
@@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
extern char kernel_start[];
extern char kernel_end[];
@@ -47,7 +48,7 @@ extern void *_end;
void _start(void);
void __start(void);
-void __startC(void);
+void __startC(unsigned r0, unsigned r1, unsigned r2, unsigned r3);
extern unsigned int cpu_ident(void);
extern void armv6_idcache_wbinv_all(void);
@@ -124,6 +125,10 @@ static int arm_dcache_l2_nsets;
static int arm_dcache_l2_assoc;
static int arm_dcache_l2_linesize;
+/*
+ * Boot parameters
+ */
+static struct arm_boot_params s_boot_params;
extern int arm9_dcache_sets_inc;
extern int arm9_dcache_sets_max;
@@ -172,12 +177,17 @@ bzero(void *addr, int count)
static void arm9_setup(void);
void
-_startC(void)
+_startC(unsigned r0, unsigned r1, unsigned r2, unsigned r3)
{
int tmp1;
unsigned int sp = ((unsigned int)&_end & ~3) + 4;
unsigned int pc, kernphysaddr;
+ s_boot_params.abp_r0 = r0;
+ s_boot_params.abp_r1 = r1;
+ s_boot_params.abp_r2 = r2;
+ s_boot_params.abp_r3 = r3;
+
/*
* Figure out the physical address the kernel was loaded at. This
* assumes the entry point (this code right here) is in the first page,
@@ -211,8 +221,15 @@ _startC(void)
/* Temporary set the sp and jump to the new location. */
__asm __volatile(
"mov sp, %1\n"
+ "mov r0, %2\n"
+ "mov r1, %3\n"
+ "mov r2, %4\n"
+ "mov r3, %5\n"
"mov pc, %0\n"
- : : "r" (target_addr), "r" (tmp_sp));
+ : : "r" (target_addr), "r" (tmp_sp),
+ "r" (s_boot_params.abp_r0), "r" (s_boot_params.abp_r1),
+ "r" (s_boot_params.abp_r2), "r" (s_boot_params.abp_r3),
+ : "r0", "r1", "r2", "r3");
}
#endif
@@ -487,6 +504,7 @@ load_kernel(unsigned int kstart, unsigne
vm_offset_t lastaddr = 0;
Elf_Addr ssym = 0;
Elf_Dyn *dp;
+ struct arm_boot_params local_boot_params;
eh = (Elf32_Ehdr *)kstart;
ssym = 0;
@@ -555,6 +573,12 @@ load_kernel(unsigned int kstart, unsigne
if (!d)
return ((void *)lastaddr);
+ /*
+* Now the stack is fixed, copy boot params
+* before it's overrided
+*/
+ memcpy(&local_boot_params, &s_boot_params, sizeof(local_boot_params));
+
j = eh->e_phnum;
for (i = 0; i < j; i++) {
volatile char c;
@@ -604,7 +628,10 @@ load_kernel(unsigned int kstart, unsigne
"mcr p15, 0, %0, c1, c0, 0\n" /* CP15_SCTLR(%0)*/
: "=r" (ssym));
/* Jump to the entry point. */
- ((void(*)(void))(entry_point - KERNVIRTADDR + curaddr))();
+ ((void(*)(unsigned, unsigned, unsigned, unsigned))
+ (entry_point - KERNVIRTADDR + curaddr))
+ (local_boot_params.abp_r0, local_boot_params.abp_r1,
+ local_boot_params.abp_r2, local_boot_params.abp_r3);
__asm __volatile(".globl func_end\n"
"func_end:");
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304492 - head/sys/conf
Author: jhb Date: Fri Aug 19 18:45:42 2016 New Revision: 304492 URL: https://svnweb.freebsd.org/changeset/base/304492 Log: Move cxgb and cxgbe down to the non-mii PCI NIC section. Modified: head/sys/conf/NOTES Modified: head/sys/conf/NOTES == --- head/sys/conf/NOTES Fri Aug 19 18:40:47 2016(r304491) +++ head/sys/conf/NOTES Fri Aug 19 18:45:42 2016(r304492) @@ -2116,9 +2116,6 @@ devicebce # Broadcom BCM5706/BCM5708 device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device cas # Sun Cassini/Cassini+ and NS DP83065 Saturn -device cxgb# Chelsio T3 10 Gigabit Ethernet -device cxgb_t3fw # Chelsio T3 10 Gigabit Ethernet firmware -device cxgbe # Chelsio T4 and T5 1GbE/10GbE/40GbE device dc # DEC/Intel 21143 and various workalikes device et # Agere ET1310 10/100/Gigabit Ethernet device fxp # Intel EtherExpress PRO/100B (82557, 82558) @@ -2149,6 +2146,9 @@ devicewb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # PCI Ethernet NICs. +device cxgb# Chelsio T3 10 Gigabit Ethernet +device cxgb_t3fw # Chelsio T3 10 Gigabit Ethernet firmware +device cxgbe # Chelsio T4 and T5 1GbE/10GbE/40GbE device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel Pro/1000 Gigabit Ethernet device igb # Intel Pro/1000 PCIE Gigabit Ethernet ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304498 - in head: . share/man/man4 sys/conf sys/dev/scd sys/modules sys/modules/scd
Author: jhb
Date: Fri Aug 19 19:31:55 2016
New Revision: 304498
URL: https://svnweb.freebsd.org/changeset/base/304498
Log:
Remove the scd(4) driver for Sony CDU31/33 CD-ROM drives.
This is a driver for a pre-ATAPI ISA CD-ROM adapter. The driver only
uses PIO.
Deleted:
head/share/man/man4/scd.4
head/sys/dev/scd/
head/sys/modules/scd/
Modified:
head/ObsoleteFiles.inc
head/share/man/man4/Makefile
head/sys/conf/NOTES
head/sys/conf/files
head/sys/modules/Makefile
Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc Fri Aug 19 19:30:00 2016(r304497)
+++ head/ObsoleteFiles.inc Fri Aug 19 19:31:55 2016(r304498)
@@ -38,6 +38,8 @@
# xargs -n1 | sort | uniq -d;
# done
+# 20160819: Remove scd(4)
+OLD_FILES+=usr/share/man/man4/scd.4.gz
# 20160815: Remove mcd(4)
OLD_FILES+=usr/share/man/man4/mcd.4.gz
# 20160703: POSIXify locales with variants
Modified: head/share/man/man4/Makefile
==
--- head/share/man/man4/MakefileFri Aug 19 19:30:00 2016
(r304497)
+++ head/share/man/man4/MakefileFri Aug 19 19:31:55 2016
(r304498)
@@ -441,7 +441,6 @@ MAN=aac.4 \
sbp.4 \
sbp_targ.4 \
scc.4 \
- scd.4 \
sched_4bsd.4 \
sched_ule.4 \
screen.4 \
Modified: head/sys/conf/NOTES
==
--- head/sys/conf/NOTES Fri Aug 19 19:30:00 2016(r304497)
+++ head/sys/conf/NOTES Fri Aug 19 19:31:55 2016(r304498)
@@ -2411,15 +2411,10 @@ options SND_OLDSTEREO
#
# Miscellaneous hardware:
#
-# scd: Sony CD-ROM using proprietary (non-ATAPI) interface
# bktr: Brooktree bt848/848a/849a/878/879 video capture and TV Tuner board
# joy: joystick (including IO DATA PCJOY PC Card joystick)
# cmx: OmniKey CardMan 4040 pccard smartcard reader
-# for the Sony CDU31/33A CDROM
-device scd
-hint.scd.0.at="isa"
-hint.scd.0.port="0x230"
device joy # PnP aware, hints for non-PnP only
hint.joy.0.at="isa"
hint.joy.0.port="0x201"
Modified: head/sys/conf/files
==
--- head/sys/conf/files Fri Aug 19 19:30:00 2016(r304497)
+++ head/sys/conf/files Fri Aug 19 19:31:55 2016(r304498)
@@ -2506,8 +2506,6 @@ dev/scc/scc_core.coptional scc
dev/scc/scc_dev_quicc.coptional scc quicc
dev/scc/scc_dev_sab82532.c optional scc
dev/scc/scc_dev_z8530.coptional scc
-dev/scd/scd.c optional scd isa
-dev/scd/scd_isa.c optional scd isa
dev/sdhci/sdhci.c optional sdhci
dev/sdhci/sdhci_if.m optional sdhci
dev/sdhci/sdhci_pci.c optional sdhci pci
Modified: head/sys/modules/Makefile
==
--- head/sys/modules/Makefile Fri Aug 19 19:30:00 2016(r304497)
+++ head/sys/modules/Makefile Fri Aug 19 19:31:55 2016(r304498)
@@ -322,7 +322,6 @@ SUBDIR= \
${_safe} \
${_sbni} \
scc \
- scd \
${_scsi_low} \
sdhci \
sdhci_pci \
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304501 - head/tools/kerneldoc/subsys
Author: jhb Date: Fri Aug 19 20:53:55 2016 New Revision: 304501 URL: https://svnweb.freebsd.org/changeset/base/304501 Log: Remove doxygen files for mcd(4) and scd(4) drivers. Submitted by: ak Deleted: head/tools/kerneldoc/subsys/Doxyfile-dev_mcd head/tools/kerneldoc/subsys/Doxyfile-dev_scd ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304502 - in head: . share/man/man4 sys/amd64/conf sys/conf sys/dev/si sys/i386/conf sys/modules sys/modules/si targets/pseudo/userland tools/kerneldoc/subsys usr.sbin usr.sbin/sicontrol
Author: jhb
Date: Fri Aug 19 21:14:27 2016
New Revision: 304502
URL: https://svnweb.freebsd.org/changeset/base/304502
Log:
Remove the si(4) driver and sicontrol(8) for Specialix serial cards.
The si(4) driver supported multiport serial adapters for ISA, EISA, and
PCI buses. This driver does not use bus_space, instead it depends on
direct use of the pointer returned by rman_get_virtual(). It is also
still locked by Giant and calls for patch testing to convert it to use
bus_space were unanswered.
Relnotes: yes
Deleted:
head/share/man/man4/si.4
head/sys/dev/si/
head/sys/modules/si/
head/tools/kerneldoc/subsys/Doxyfile-dev_si
head/usr.sbin/sicontrol/
Modified:
head/ObsoleteFiles.inc
head/share/man/man4/Makefile
head/sys/amd64/conf/NOTES
head/sys/conf/files
head/sys/i386/conf/NOTES
head/sys/modules/Makefile
head/targets/pseudo/userland/Makefile.depend
head/usr.sbin/Makefile.amd64
head/usr.sbin/Makefile.i386
Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc Fri Aug 19 20:53:55 2016(r304501)
+++ head/ObsoleteFiles.inc Fri Aug 19 21:14:27 2016(r304502)
@@ -38,6 +38,10 @@
# xargs -n1 | sort | uniq -d;
# done
+# 20160819: Remove si(4) and sicontrol(8)
+OLD_FILES+=usr/share/man/man4/si.4.gz
+OLD_FILES+=usr/sbin/sicontrol
+OLD_FILES+=usr/share/man/man8/sicontrol.8.gz
# 20160819: Remove scd(4)
OLD_FILES+=usr/share/man/man4/scd.4.gz
# 20160815: Remove mcd(4)
Modified: head/share/man/man4/Makefile
==
--- head/share/man/man4/MakefileFri Aug 19 20:53:55 2016
(r304501)
+++ head/share/man/man4/MakefileFri Aug 19 21:14:27 2016
(r304502)
@@ -453,7 +453,6 @@ MAN=aac.4 \
sf.4 \
${_sfxge.4} \
sge.4 \
- si.4 \
siba.4 \
siftr.4 \
siis.4 \
Modified: head/sys/amd64/conf/NOTES
==
--- head/sys/amd64/conf/NOTES Fri Aug 19 20:53:55 2016(r304501)
+++ head/sys/amd64/conf/NOTES Fri Aug 19 21:14:27 2016(r304502)
@@ -542,7 +542,6 @@ hint.pbio.0.port="0x360"
device smbios
device vpd
device asmc
-device si
device tpm
device padlock_rng # VIA Padlock RNG
device rdrand_rng # Intel Bull Mountain RNG
Modified: head/sys/conf/files
==
--- head/sys/conf/files Fri Aug 19 20:53:55 2016(r304501)
+++ head/sys/conf/files Fri Aug 19 21:14:27 2016(r304502)
@@ -2511,12 +2511,6 @@ dev/sdhci/sdhci_if.m optional sdhci
dev/sdhci/sdhci_pci.c optional sdhci pci
dev/sf/if_sf.c optional sf pci
dev/sge/if_sge.c optional sge pci
-dev/si/si.coptional si
-dev/si/si2_z280.c optional si
-dev/si/si3_t225.c optional si
-dev/si/si_eisa.c optional si eisa
-dev/si/si_isa.coptional si isa
-dev/si/si_pci.coptional si pci
dev/siba/siba_bwn.coptional siba_bwn pci
dev/siba/siba_core.c optional siba_bwn pci
dev/siis/siis.coptional siis pci
Modified: head/sys/i386/conf/NOTES
==
--- head/sys/i386/conf/NOTESFri Aug 19 20:53:55 2016(r304501)
+++ head/sys/i386/conf/NOTESFri Aug 19 21:14:27 2016(r304502)
@@ -880,7 +880,6 @@ device spic
hint.spic.0.at="isa"
hint.spic.0.port="0x10a0"
device asmc
-device si
device tpm
device padlock_rng # VIA Padlock RNG
device rdrand_rng # Intel Bull Mountain RNG
Modified: head/sys/modules/Makefile
==
--- head/sys/modules/Makefile Fri Aug 19 20:53:55 2016(r304501)
+++ head/sys/modules/Makefile Fri Aug 19 21:14:27 2016(r304502)
@@ -330,7 +330,6 @@ SUBDIR= \
${_sf} \
${_sfxge} \
sge \
- ${_si} \
siba_bwn \
siftr \
siis \
@@ -584,7 +583,6 @@ _rdma= rdma
.endif
_safe= safe
_scsi_low= scsi_low
-_si= si
_speaker= speaker
_splash= splash
_sppp= sppp
Modified: head/targets/pseudo/userland/Makefile.depend
==
--- head/targets/pseudo/userland/Makefile.dependFri Aug 19 20:53:55
2016(r304501)
+++ head/targets/pseudo/userland/Makefile.dependFri Aug 19 21:14:27
2016(r304502)
@@ -834,7 +834,6 @@ DIRDEPS.amd64= \
usr.sbin/lptcont
svn commit: r304503 - in head: etc release/doc/en_US.ISO8859-1/hardware sys/conf sys/dev/wds sys/modules sys/modules/wds sys/pc98/conf sys/sparc64/conf tools/kerneldoc/subsys
Author: jhb
Date: Fri Aug 19 21:51:42 2016
New Revision: 304503
URL: https://svnweb.freebsd.org/changeset/base/304503
Log:
Remove the wds(4) driver for the WD700 ISA SCSI HBA.
While this driver does do DMA, it bounce buffers all transactions through
a single 64k buffer. It also does not have a manpage.
Relnotes: yes
Deleted:
head/sys/dev/wds/
head/sys/modules/wds/
head/tools/kerneldoc/subsys/Doxyfile-dev_wds
Modified:
head/etc/devd.conf
head/release/doc/en_US.ISO8859-1/hardware/article.xml
head/sys/conf/NOTES
head/sys/conf/files
head/sys/modules/Makefile
head/sys/pc98/conf/NOTES
head/sys/sparc64/conf/NOTES
Modified: head/etc/devd.conf
==
--- head/etc/devd.conf Fri Aug 19 21:14:27 2016(r304502)
+++ head/etc/devd.conf Fri Aug 19 21:51:42 2016(r304503)
@@ -20,7 +20,7 @@ options {
#XXX Yes, these are gross -- imp
set scsi-controller-regex
"(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|\
- esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)\
+ esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm)\
[0-9]+";
set wifi-driver-regex
"(ath|bwi|bwn|ipw|iwi|iwm|iwn|malo|mwl|ral|rsu|rum|run|uath|\
Modified: head/release/doc/en_US.ISO8859-1/hardware/article.xml
==
--- head/release/doc/en_US.ISO8859-1/hardware/article.xml Fri Aug 19
21:14:27 2016(r304502)
+++ head/release/doc/en_US.ISO8859-1/hardware/article.xml Fri Aug 19
21:51:42 2016(r304503)
@@ -751,9 +751,6 @@
&hwlist.vpo;
- [&arch.i386;] The wds(4) driver supports the WD7000 SCSI
- controller.
-
With all supported SCSI controllers, full support is
provided for SCSI-I, SCSI-II, and SCSI-III peripherals,
including hard disks, optical disks, tape drives (including
Modified: head/sys/conf/NOTES
==
--- head/sys/conf/NOTES Fri Aug 19 21:14:27 2016(r304502)
+++ head/sys/conf/NOTES Fri Aug 19 21:51:42 2016(r304503)
@@ -1560,7 +1560,6 @@ options TERMINAL_KERN_ATTR=(FG_LIGHTRED
# 53C876, 53C885, 53C895, 53C895A, 53C896, 53C897, 53C1510D,
# 53C1010-33, 53C1010-66.
# trm: Tekram DC395U/UW/F DC315U adapters.
-# wds: WD7000
#
# Note that the order is important in order for Buslogic ISA/EISA cards to be
@@ -1602,11 +1601,6 @@ device mpt
device ncr
device sym
device trm
-device wds
-hint.wds.0.at="isa"
-hint.wds.0.port="0x350"
-hint.wds.0.irq="11"
-hint.wds.0.drq="6"
# The aic7xxx driver will attempt to use memory mapped I/O for all PCI
# controllers that have it configured only if this option is set.
Unfortunately,
Modified: head/sys/conf/files
==
--- head/sys/conf/files Fri Aug 19 21:14:27 2016(r304502)
+++ head/sys/conf/files Fri Aug 19 21:51:42 2016(r304503)
@@ -2930,7 +2930,6 @@ dev/vxge/vxgehal/vxgehal-channel.coptio
dev/vxge/vxgehal/vxgehal-fifo.coptional vxge
dev/watchdog/watchdog.cstandard
dev/wb/if_wb.c optional wb pci
-dev/wds/wd7000.c optional wds isa
dev/wi/if_wi.c optional wi
dev/wi/if_wi_pccard.c optional wi pccard
dev/wi/if_wi_pci.c optional wi pci
Modified: head/sys/modules/Makefile
==
--- head/sys/modules/Makefile Fri Aug 19 21:14:27 2016(r304502)
+++ head/sys/modules/Makefile Fri Aug 19 21:51:42 2016(r304503)
@@ -390,7 +390,6 @@ SUBDIR= \
${_vxge} \
wb \
${_wbwd} \
- ${_wds} \
${_wi} \
${_wl} \
wlan \
@@ -718,7 +717,6 @@ _sbni= sbni
_streams= streams
_stg= stg
_svr4= svr4
-_wds= wds
.if ${MACHINE} == "i386"
.if ${MK_EISA} != "no"
_ahb= ahb
Modified: head/sys/pc98/conf/NOTES
==
--- head/sys/pc98/conf/NOTESFri Aug 19 21:14:27 2016(r304502)
+++ head/sys/pc98/conf/NOTESFri Aug 19 21:51:42 2016(r304503)
@@ -595,7 +595,6 @@ nodeviceahb
nodevice ahd
nodevice mpt
nodevice trm
-nodevice wds
nodevice dpt
nodevice ciss
nodevice iir
Modified: head/sys/sparc64/conf/NOTES
==
--- head/sys/sparc64/conf/NOTES Fri Aug 19 21:14:27 2016(r304502)
+++ head/sys/sparc64/conf/NOTES Fri Aug 19 21:51:42 2016(r304503)
@@ -121,7 +121,6 @@ nodevicesnd_vibes
no
svn commit: r304504 - head/etc
Author: jhb
Date: Fri Aug 19 22:05:22 2016
New Revision: 304504
URL: https://svnweb.freebsd.org/changeset/base/304504
Log:
Remove stale drivers (amd(4) and asr(4)) from the SCSI controller regex.
Modified:
head/etc/devd.conf
Modified: head/etc/devd.conf
==
--- head/etc/devd.conf Fri Aug 19 21:51:42 2016(r304503)
+++ head/etc/devd.conf Fri Aug 19 22:05:22 2016(r304504)
@@ -19,7 +19,7 @@ options {
# Setup some shorthand for regex that we use later in the file.
#XXX Yes, these are gross -- imp
set scsi-controller-regex
- "(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|\
+ "(aac|adv|adw|aha|ahb|ahc|ahd|aic|amr|bt|ciss|ct|dpt|\
esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm)\
[0-9]+";
set wifi-driver-regex
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304505 - head/release/doc/en_US.ISO8859-1/hardware
Author: jhb Date: Fri Aug 19 22:13:01 2016 New Revision: 304505 URL: https://svnweb.freebsd.org/changeset/base/304505 Log: Remove mentions of the mcd(4), scd(4), and si(4) drivers. Relnotes: yes Modified: head/release/doc/en_US.ISO8859-1/hardware/article.xml Modified: head/release/doc/en_US.ISO8859-1/hardware/article.xml == --- head/release/doc/en_US.ISO8859-1/hardware/article.xml Fri Aug 19 22:05:22 2016(r304504) +++ head/release/doc/en_US.ISO8859-1/hardware/article.xml Fri Aug 19 22:13:01 2016(r304505) @@ -772,23 +772,9 @@ - [&arch.i386;] Sony proprietary interface (all models) - (&man.scd.4;) - - - ATAPI IDE interface (&man.acd.4;) - - [&arch.i386;] The following device is unmaintained: - - - - Mitsumi proprietary CD-ROM interface (all models) - (&man.mcd.4;) - - @@ -1235,13 +1221,6 @@ &hwlist.rc; - [&arch.i386;, &arch.amd64;] Specialix SI/XIO/SX multiport - serial cards, with both the older SIHOST2.x and the - enhanced (transputer based, aka JET) host cards - (ISA, EISA and PCI) are supported. Note that the newer SX+ - PCI cards are not currently supported. (&man.si.4; - driver) - [&arch.pc98;] Internel serial interfaces (&man.sio.4; driver) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304506 - in head: . release/doc/en_US.ISO8859-1/hardware share/man/man4/man4.i386 sys/conf sys/dev/wl sys/i386/conf sys/modules sys/modules/wl targets/pseudo/userland tools/build/mk to...
Author: jhb
Date: Fri Aug 19 22:27:14 2016
New Revision: 304506
URL: https://svnweb.freebsd.org/changeset/base/304506
Log:
Remove the wl(4) driver and wlconfig(8) utility.
The wl(4) driver supports pre-802.11 PCCard wireless adapters that
are slower than 802.11b. They do not work with any of the 802.11
framework and the driver hasn't been reported to actually work in a
long time.
Relnotes: yes
Deleted:
head/share/man/man4/man4.i386/wl.4
head/sys/dev/wl/
head/sys/modules/wl/
head/tools/kerneldoc/subsys/Doxyfile-dev_wl
head/usr.sbin/wlconfig/
Modified:
head/ObsoleteFiles.inc
head/release/doc/en_US.ISO8859-1/hardware/article.xml
head/share/man/man4/man4.i386/Makefile
head/sys/conf/files
head/sys/conf/options
head/sys/i386/conf/NOTES
head/sys/modules/Makefile
head/targets/pseudo/userland/Makefile.depend
head/tools/build/mk/OptionalObsoleteFiles.inc
head/usr.sbin/Makefile.i386
Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc Fri Aug 19 22:13:01 2016(r304505)
+++ head/ObsoleteFiles.inc Fri Aug 19 22:27:14 2016(r304506)
@@ -38,6 +38,10 @@
# xargs -n1 | sort | uniq -d;
# done
+# 20160819: Remove wl(4) and wlconfig(8)
+OLD_FILES+=usr/share/man/man4/i386/wl.4.gz
+OLD_FILES+=usr/sbin/wlconfig
+OLD_FILES+=usr/share/man/man8/i386/wlconfig.8.gz
# 20160819: Remove si(4) and sicontrol(8)
OLD_FILES+=usr/share/man/man4/si.4.gz
OLD_FILES+=usr/sbin/sicontrol
Modified: head/release/doc/en_US.ISO8859-1/hardware/article.xml
==
--- head/release/doc/en_US.ISO8859-1/hardware/article.xml Fri Aug 19
22:13:01 2016(r304505)
+++ head/release/doc/en_US.ISO8859-1/hardware/article.xml Fri Aug 19
22:27:14 2016(r304506)
@@ -1023,9 +1023,6 @@
Intersil PRISM-2.5, Intersil Prism-3, and Symbol Spectrum24
chipsets (&man.wi.4; driver)
- [&arch.i386;] NCR / AT&T / Lucent Technologies WaveLan
- T1-speed ISA/radio LAN cards (&man.wl.4; driver)
-
[&arch.i386;, &arch.amd64;] Intel PRO/Wireless 3945ABG
MiniPCI network adapters (&man.wpi.4; driver)
Modified: head/share/man/man4/man4.i386/Makefile
==
--- head/share/man/man4/man4.i386/Makefile Fri Aug 19 22:13:01 2016
(r304505)
+++ head/share/man/man4/man4.i386/Makefile Fri Aug 19 22:27:14 2016
(r304506)
@@ -31,8 +31,7 @@ MAN= aic.4 \
streams.4 \
svr4.4 \
vpd.4 \
- vx.4 \
- wl.4
+ vx.4
MLINKS=CPU_ELAN.4 CPU_SOEKRIS.4
MLINKS+=pae.4 PAE.4
Modified: head/sys/conf/files
==
--- head/sys/conf/files Fri Aug 19 22:13:01 2016(r304505)
+++ head/sys/conf/files Fri Aug 19 22:27:14 2016(r304506)
@@ -2933,7 +2933,6 @@ dev/wb/if_wb.coptional wb pci
dev/wi/if_wi.c optional wi
dev/wi/if_wi_pccard.c optional wi pccard
dev/wi/if_wi_pci.c optional wi pci
-dev/wl/if_wl.c optional wl isa
dev/wpi/if_wpi.c optional wpi pci
wpifw.coptional wpifw
\
compile-with"${AWK} -f $S/tools/fw_stub.awk wpi.fw:wpifw:153229
-mwpi -c${.TARGET}" \
Modified: head/sys/conf/options
==
--- head/sys/conf/options Fri Aug 19 22:13:01 2016(r304505)
+++ head/sys/conf/options Fri Aug 19 22:27:14 2016(r304506)
@@ -218,8 +218,6 @@ SW_WATCHDOG opt_watchdog.h
TURNSTILE_PROFILING
UMTX_PROFILING
VERBOSE_SYSINIT
-WLCACHEopt_wavelan.h
-WLDEBUGopt_wavelan.h
# POSIX kernel options
P1003_1B_MQUEUEopt_posix.h
Modified: head/sys/i386/conf/NOTES
==
--- head/sys/i386/conf/NOTESFri Aug 19 22:13:01 2016(r304505)
+++ head/sys/i386/conf/NOTESFri Aug 19 22:27:14 2016(r304506)
@@ -648,11 +648,6 @@ hint.sbni.0.port="0x210"
hint.sbni.0.irq="0xefdead"
hint.sbni.0.flags="0"
device vmx # VMware VMXNET3 Ethernet
-device wl
-hint.wl.0.at="isa"
-hint.wl.0.port="0x300"
-optionsWLCACHE # enables the signal-strength cache
-optionsWLDEBUG # enables verbose debugging output
device wpi # Intel 3945ABG wireless NICs.
# IEEE 802.11 adapter firmware modules
Modified: head/sys/modules/Makefile
==
--- head/sys/modules/Makefile Fri A
svn commit: r304508 - in head: . share/man/man4 sys/conf sys/i386/conf sys/i386/isa
Author: jhb
Date: Fri Aug 19 23:39:08 2016
New Revision: 304508
URL: https://svnweb.freebsd.org/changeset/base/304508
Log:
Remove the spic(4) driver for the Sony Vaoi Jogdial.
This hardware is not present on any modern systems. The driver is quite
hackish (raw inb/outb instead of bus_space, and raw inb/outb to random
I/O ports to enable ACPI since it predated proper ACPI support).
Relnotes: yes
Deleted:
head/share/man/man4/spic.4
head/sys/i386/isa/spic.c
head/sys/i386/isa/spicreg.h
Modified:
head/ObsoleteFiles.inc
head/share/man/man4/Makefile
head/sys/conf/files.i386
head/sys/i386/conf/NOTES
Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc Fri Aug 19 23:31:56 2016(r304507)
+++ head/ObsoleteFiles.inc Fri Aug 19 23:39:08 2016(r304508)
@@ -38,6 +38,8 @@
# xargs -n1 | sort | uniq -d;
# done
+# 20160819: Remove spic(4)
+OLD_FILES+=usr/share/man/man4/spic.4.gz
# 20160819: Remove wl(4) and wlconfig(8)
OLD_FILES+=usr/share/man/man4/i386/wl.4.gz
OLD_FILES+=usr/sbin/wlconfig
Modified: head/share/man/man4/Makefile
==
--- head/share/man/man4/MakefileFri Aug 19 23:31:56 2016
(r304507)
+++ head/share/man/man4/MakefileFri Aug 19 23:39:08 2016
(r304508)
@@ -496,7 +496,6 @@ MAN=aac.4 \
snd_via82c686.4 \
snd_vibes.4 \
snp.4 \
- spic.4 \
${_spkr.4} \
splash.4 \
sppp.4 \
Modified: head/sys/conf/files.i386
==
--- head/sys/conf/files.i386Fri Aug 19 23:31:56 2016(r304507)
+++ head/sys/conf/files.i386Fri Aug 19 23:39:08 2016(r304508)
@@ -516,7 +516,6 @@ i386/isa/elink.coptional ep | ie
i386/isa/npx.c optional npx
i386/isa/pmtimer.c optional pmtimer
i386/isa/prof_machdep.coptional profiling-routine
-i386/isa/spic.coptional spic
i386/linux/imgact_linux.c optional compat_linux
i386/linux/linux_dummy.c optional compat_linux
i386/linux/linux_machdep.c optional compat_linux
Modified: head/sys/i386/conf/NOTES
==
--- head/sys/i386/conf/NOTESFri Aug 19 23:31:56 2016(r304507)
+++ head/sys/i386/conf/NOTESFri Aug 19 23:39:08 2016(r304508)
@@ -834,7 +834,6 @@ device hyperv # HyperV drivers
# vpd: Vital Product Data kernel interface
# pmtimer: Adjust system timer at wakeup time
# pbio: Parallel (8255 PPI) basic I/O (mode 0) port (e.g. Advantech PCL-724)
-# spic: Sony Programmable I/O controller (VAIO notebooks)
# asmc: Apple System Management Controller
# si: Specialix International SI/XIO or SX intelligent serial card driver
# tpm: Trusted Platform Module
@@ -871,9 +870,6 @@ device pmtimer
device pbio
hint.pbio.0.at="isa"
hint.pbio.0.port="0x360"
-device spic
-hint.spic.0.at="isa"
-hint.spic.0.port="0x10a0"
device asmc
device tpm
device padlock_rng # VIA Padlock RNG
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304509 - head/sys/arm/allwinner
Author: manu
Date: Fri Aug 19 23:44:07 2016
New Revision: 304509
URL: https://svnweb.freebsd.org/changeset/base/304509
Log:
if_emac: Before generating a random MAC address, try using the SID rootkey
to generate one. This is was U-Boot does to generate a random MAC so we end
up with the same MAC address as if U-Boot did generate it.
MFC after:1 week
Modified:
head/sys/arm/allwinner/if_emac.c
Modified: head/sys/arm/allwinner/if_emac.c
==
--- head/sys/arm/allwinner/if_emac.cFri Aug 19 23:39:08 2016
(r304508)
+++ head/sys/arm/allwinner/if_emac.cFri Aug 19 23:44:07 2016
(r304509)
@@ -77,6 +77,7 @@ __FBSDID("$FreeBSD$");
#include
#include
+#include
#include
@@ -167,12 +168,17 @@ static void
emac_get_hwaddr(struct emac_softc *sc, uint8_t *hwaddr)
{
uint32_t val0, val1, rnd;
+ u_char rootkey[16];
/*
* Try to get MAC address from running hardware.
* If there is something non-zero there just use it.
*
* Otherwise set the address to a convenient locally assigned address,
+* using the SID rootkey.
+* This is was uboot does so we end up with the same mac as if uboot
+* did set it.
+* If we can't get the root key, generate a random one,
* 'bsd' + random 24 low-order bits. 'b' is 0x62, which has the locally
* assigned bit set, and the broadcast/multicast bit clear.
*/
@@ -186,13 +192,23 @@ emac_get_hwaddr(struct emac_softc *sc, u
hwaddr[4] = (val0 >> 8) & 0xff;
hwaddr[5] = (val0 >> 0) & 0xff;
} else {
- rnd = arc4random() & 0x00ff;
- hwaddr[0] = 'b';
- hwaddr[1] = 's';
- hwaddr[2] = 'd';
- hwaddr[3] = (rnd >> 16) & 0xff;
- hwaddr[4] = (rnd >> 8) & 0xff;
- hwaddr[5] = (rnd >> 0) & 0xff;
+ if (aw_sid_get_rootkey(rootkey) == 0) {
+ hwaddr[0] = 0x2;
+ hwaddr[1] = rootkey[3];
+ hwaddr[2] = rootkey[12];
+ hwaddr[3] = rootkey[13];
+ hwaddr[4] = rootkey[14];
+ hwaddr[5] = rootkey[15];
+ }
+ else {
+ rnd = arc4random() & 0x00ff;
+ hwaddr[0] = 'b';
+ hwaddr[1] = 's';
+ hwaddr[2] = 'd';
+ hwaddr[3] = (rnd >> 16) & 0xff;
+ hwaddr[4] = (rnd >> 8) & 0xff;
+ hwaddr[5] = (rnd >> 0) & 0xff;
+ }
}
if (bootverbose)
printf("MAC address: %s\n", ether_sprintf(hwaddr));
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304510 - head/sys/dev/ixl
Author: erj
Date: Sat Aug 20 00:08:10 2016
New Revision: 304510
URL: https://svnweb.freebsd.org/changeset/base/304510
Log:
ixlv(4): Fix ixlv(4) not loading when loaded as a kernel module and netmap is
enabled.
Define (unused) netmap variables; ixlv(4) doesn't support netmap yet.
Reported by: sergey.koz...@intel.com
Sponsored by: Intel Corporation
Modified:
head/sys/dev/ixl/if_ixlv.c
Modified: head/sys/dev/ixl/if_ixlv.c
==
--- head/sys/dev/ixl/if_ixlv.c Fri Aug 19 23:44:07 2016(r304509)
+++ head/sys/dev/ixl/if_ixlv.c Sat Aug 20 00:08:10 2016(r304510)
@@ -217,6 +217,10 @@ TUNABLE_INT("hw.ixlv.tx_itr", &ixlv_tx_i
SYSCTL_INT(_hw_ixlv, OID_AUTO, tx_itr, CTLFLAG_RDTUN,
&ixlv_tx_itr, 0, "TX Interrupt Rate");
+/* Fix when building as a standalone module when netmap is enabled */
+#if defined(DEV_NETMAP) && !defined(NETMAP_IXL_MAIN)
+int ixl_rx_miss, ixl_rx_miss_bufs, ixl_crcstrip;
+#endif
/*
* Device identification routine
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304506 - in head: . release/doc/en_US.ISO8859-1/hardware share/man/man4/man4.i386 sys/conf sys/dev/wl sys/i386/conf sys/modules sys/modules/wl targets/pseudo/userland tools/build/mk t
On Fri, Aug 19, 2016 at 4:27 PM, John Baldwin wrote:
> Author: jhb
> Date: Fri Aug 19 22:27:14 2016
> New Revision: 304506
> URL: https://svnweb.freebsd.org/changeset/base/304506
>
> Log:
> Remove the wl(4) driver and wlconfig(8) utility.
>
> The wl(4) driver supports pre-802.11 PCCard wireless adapters that
> are slower than 802.11b. They do not work with any of the 802.11
> framework and the driver hasn't been reported to actually work in a
> long time.
s/PC Card/ISA/g
There never were any PC Card wl cards. These cards were ISA only
and ran at up to 1Mbps.
Warner
> Relnotes: yes
>
> Deleted:
> head/share/man/man4/man4.i386/wl.4
> head/sys/dev/wl/
> head/sys/modules/wl/
> head/tools/kerneldoc/subsys/Doxyfile-dev_wl
> head/usr.sbin/wlconfig/
> Modified:
> head/ObsoleteFiles.inc
> head/release/doc/en_US.ISO8859-1/hardware/article.xml
> head/share/man/man4/man4.i386/Makefile
> head/sys/conf/files
> head/sys/conf/options
> head/sys/i386/conf/NOTES
> head/sys/modules/Makefile
> head/targets/pseudo/userland/Makefile.depend
> head/tools/build/mk/OptionalObsoleteFiles.inc
> head/usr.sbin/Makefile.i386
>
> Modified: head/ObsoleteFiles.inc
> ==
> --- head/ObsoleteFiles.inc Fri Aug 19 22:13:01 2016(r304505)
> +++ head/ObsoleteFiles.inc Fri Aug 19 22:27:14 2016(r304506)
> @@ -38,6 +38,10 @@
> # xargs -n1 | sort | uniq -d;
> # done
>
> +# 20160819: Remove wl(4) and wlconfig(8)
> +OLD_FILES+=usr/share/man/man4/i386/wl.4.gz
> +OLD_FILES+=usr/sbin/wlconfig
> +OLD_FILES+=usr/share/man/man8/i386/wlconfig.8.gz
> # 20160819: Remove si(4) and sicontrol(8)
> OLD_FILES+=usr/share/man/man4/si.4.gz
> OLD_FILES+=usr/sbin/sicontrol
>
> Modified: head/release/doc/en_US.ISO8859-1/hardware/article.xml
> ==
> --- head/release/doc/en_US.ISO8859-1/hardware/article.xml Fri Aug 19
> 22:13:01 2016(r304505)
> +++ head/release/doc/en_US.ISO8859-1/hardware/article.xml Fri Aug 19
> 22:27:14 2016(r304506)
> @@ -1023,9 +1023,6 @@
> Intersil PRISM-2.5, Intersil Prism-3, and Symbol Spectrum24
> chipsets (&man.wi.4; driver)
>
> - [&arch.i386;] NCR / AT&T / Lucent Technologies WaveLan
> - T1-speed ISA/radio LAN cards (&man.wl.4; driver)
> -
>[&arch.i386;, &arch.amd64;] Intel PRO/Wireless 3945ABG
> MiniPCI network adapters (&man.wpi.4; driver)
>
>
> Modified: head/share/man/man4/man4.i386/Makefile
> ==
> --- head/share/man/man4/man4.i386/Makefile Fri Aug 19 22:13:01 2016
> (r304505)
> +++ head/share/man/man4/man4.i386/Makefile Fri Aug 19 22:27:14 2016
> (r304506)
> @@ -31,8 +31,7 @@ MAN= aic.4 \
> streams.4 \
> svr4.4 \
> vpd.4 \
> - vx.4 \
> - wl.4
> + vx.4
>
> MLINKS=CPU_ELAN.4 CPU_SOEKRIS.4
> MLINKS+=pae.4 PAE.4
>
> Modified: head/sys/conf/files
> ==
> --- head/sys/conf/files Fri Aug 19 22:13:01 2016(r304505)
> +++ head/sys/conf/files Fri Aug 19 22:27:14 2016(r304506)
> @@ -2933,7 +2933,6 @@ dev/wb/if_wb.coptional wb pci
> dev/wi/if_wi.c optional wi
> dev/wi/if_wi_pccard.c optional wi pccard
> dev/wi/if_wi_pci.c optional wi pci
> -dev/wl/if_wl.c optional wl isa
> dev/wpi/if_wpi.c optional wpi pci
> wpifw.coptional wpifw
> \
> compile-with"${AWK} -f $S/tools/fw_stub.awk wpi.fw:wpifw:153229
> -mwpi -c${.TARGET}" \
>
> Modified: head/sys/conf/options
> ==
> --- head/sys/conf/options Fri Aug 19 22:13:01 2016(r304505)
> +++ head/sys/conf/options Fri Aug 19 22:27:14 2016(r304506)
> @@ -218,8 +218,6 @@ SW_WATCHDOG opt_watchdog.h
> TURNSTILE_PROFILING
> UMTX_PROFILING
> VERBOSE_SYSINIT
> -WLCACHEopt_wavelan.h
> -WLDEBUGopt_wavelan.h
>
> # POSIX kernel options
> P1003_1B_MQUEUEopt_posix.h
>
> Modified: head/sys/i386/conf/NOTES
> ==
> --- head/sys/i386/conf/NOTESFri Aug 19 22:13:01 2016(r304505)
> +++ head/sys/
svn commit: r304513 - in head: . share/man/man4/man4.i386 sys/conf sys/dev/ie sys/i386/conf sys/modules sys/modules/ie sys/pc98/conf
Author: jhb
Date: Sat Aug 20 00:49:29 2016
New Revision: 304513
URL: https://svnweb.freebsd.org/changeset/base/304513
Log:
Remove the ie(4) driver for Intel 82586 ISA Ethernet adapters.
This driver only supports 10Mb Ethernet using PIO (the hardware supports
DMA, but the driver only does PIO). There are not any PCCard adapters
supported by this driver, only ISA cards. In addition, it does not use
bus_space but instead uses bcopy with volatile pointers triggering a
host of warnings. (if_ie.c is one of 3 files always built with
-Wno-error)
Relnotes: yes
Deleted:
head/share/man/man4/man4.i386/ie.4
head/sys/dev/ie/
head/sys/modules/ie/
Modified:
head/ObsoleteFiles.inc
head/share/man/man4/man4.i386/Makefile
head/sys/conf/files
head/sys/i386/conf/NOTES
head/sys/modules/Makefile
head/sys/pc98/conf/NOTES
Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc Sat Aug 20 00:34:19 2016(r304512)
+++ head/ObsoleteFiles.inc Sat Aug 20 00:49:29 2016(r304513)
@@ -38,6 +38,8 @@
# xargs -n1 | sort | uniq -d;
# done
+# 20160819: Remove ie(4)
+OLD_FILES+=usr/share/man/man4/i386/ie.4.gz
# 20160819: Remove spic(4)
OLD_FILES+=usr/share/man/man4/spic.4.gz
# 20160819: Remove wl(4) and wlconfig(8)
Modified: head/share/man/man4/man4.i386/Makefile
==
--- head/share/man/man4/man4.i386/Makefile Sat Aug 20 00:34:19 2016
(r304512)
+++ head/share/man/man4/man4.i386/Makefile Sat Aug 20 00:49:29 2016
(r304513)
@@ -16,7 +16,6 @@ MAN= aic.4 \
fe.4 \
glxiic.4 \
glxsb.4 \
- ie.4 \
longrun.4 \
mse.4 \
npx.4 \
Modified: head/sys/conf/files
==
--- head/sys/conf/files Sat Aug 20 00:34:19 2016(r304512)
+++ head/sys/conf/files Sat Aug 20 00:49:29 2016(r304513)
@@ -1579,8 +1579,6 @@ dev/ida/ida.c optional ida
dev/ida/ida_disk.c optional ida
dev/ida/ida_eisa.c optional ida eisa
dev/ida/ida_pci.c optional ida pci
-dev/ie/if_ie.c optional ie isa nowerror
-dev/ie/if_ie_isa.c optional ie isa
dev/iicbus/ad7418.coptional ad7418
dev/iicbus/ds1307.coptional ds1307
dev/iicbus/ds133x.coptional ds133x
Modified: head/sys/i386/conf/NOTES
==
--- head/sys/i386/conf/NOTESSat Aug 20 00:34:19 2016(r304512)
+++ head/sys/i386/conf/NOTESSat Aug 20 00:49:29 2016(r304513)
@@ -624,12 +624,6 @@ hint.ed.0.at="isa"
hint.ed.0.port="0x280"
hint.ed.0.irq="5"
hint.ed.0.maddr="0xd8000"
-device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc.
-# Hints only required for Starlan
-hint.ie.2.at="isa"
-hint.ie.2.port="0x300"
-hint.ie.2.irq="5"
-hint.ie.2.maddr="0xd"
device ipw # Intel 2100 wireless NICs.
device iwi # Intel 2200BG/2225BG/2915ABG wireless NICs.
device iwn # Intel 4965/1000/5000/6000 wireless NICs.
Modified: head/sys/modules/Makefile
==
--- head/sys/modules/Makefile Sat Aug 20 00:34:19 2016(r304512)
+++ head/sys/modules/Makefile Sat Aug 20 00:49:29 2016(r304513)
@@ -141,7 +141,6 @@ SUBDIR= \
${_ibcs2} \
${_ichwd} \
${_ida} \
- ${_ie} \
if_bridge \
if_disc \
if_edsc \
@@ -705,7 +704,6 @@ _elink= elink
_glxiic= glxiic
_glxsb=glxsb
#_ibcs2= ibcs2
-_ie= ie
_mse= mse
_ncr= ncr
_ncv= ncv
Modified: head/sys/pc98/conf/NOTES
==
--- head/sys/pc98/conf/NOTESSat Aug 20 00:34:19 2016(r304512)
+++ head/sys/pc98/conf/NOTESSat Aug 20 00:49:29 2016(r304513)
@@ -390,11 +390,6 @@ hint.ed.0.at="isa"
hint.ed.0.port="0x280"
hint.ed.0.irq="5"
hint.ed.0.maddr="0xd8000"
-device ie # Hints only required for Starlan
-hint.ie.2.at="isa"
-hint.ie.2.port="0x300"
-hint.ie.2.irq="5"
-hint.ie.2.maddr="0xd"
#devicele
# Hint for the PC98-only C-NET(98)S C-bus front-end of le(4).
hint.le.0.at="isa"
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r304514 - head/sys/powerpc/booke
Author: jhibbits Date: Sat Aug 20 00:55:58 2016 New Revision: 304514 URL: https://svnweb.freebsd.org/changeset/base/304514 Log: Skip HID1 initialization on e6500 cores, it doesn't exist. With this, and some drivers removed, a T2080 dev board boots to mountroot. Submitted by: Ivan Krivonos Modified: head/sys/powerpc/booke/locore.S Modified: head/sys/powerpc/booke/locore.S == --- head/sys/powerpc/booke/locore.S Sat Aug 20 00:49:29 2016 (r304513) +++ head/sys/powerpc/booke/locore.S Sat Aug 20 00:55:58 2016 (r304514) @@ -140,6 +140,8 @@ __start: beq 1f cmpli 0, 0, %r3, FSL_E5500 beq 1f + cmpli 0, 0, %r3, FSL_E6500 + beq 1f lis %r3, HID1_E500_DEFAULT_SET@h ori %r3, %r3, HID1_E500_DEFAULT_SET@l ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
