Re: bind mountd to a specified port
Am Donnerstag, 18. Oktober 2012 20:50 CEST, Bob Beck b...@obtuse.com schrieb: Anyways, since in my case, I only need a read-only export, I can also go with sharing the files via http. Both networks that are separated with the firewall, have about the same trust level. So now someone could argue, why the hell a firewall in there at all, but that's a different topic ;) So let me shut up and forget about it. Essentially at that point, allowing the RPC range in from your http servers to your read only NFS server across the firewall doesn't really have any different impact than doing it only with one port. More importantly, having the rules there saying for NFS export are a nice glaring thing reminding people about the why the hell have a firewall there at all issue so it could eventually be solved. Personally I've always done this with the read only nfs server *outside* sharing to the http servers, and an internal server that all the changes are made on, with a publish mechanism (script, or button that runs a script, or even a cron job) that rsync's changes from the internal server to the external server via ssh.. You can then have a tiny little http server on the inside, visible only to the inside. for your people to vet the changes before publishing them. Then you only need to allow ssh outbound to rsync the content out, and your firewall might do something meaningful :) I did not really explained my use-case in the first place, which I probably should do before I really shut up ;) What I'm doing on the NFS server is mirroring installation sources for some Linux distribution in order to have them locally available. In order to not have multiple copies for each network, I need to make them somehow available there. The firewall sits in the middle. My plan was to use export the drive read-only into the other networks, nobody needs to write on it. For my use-case, I can also use http server to accomplish the same. Why NFS in the first place? Its the same way I do it on other places, but from a Linux server, therefore I had a bit of consistency in mind, and wanted to do it the same way here. But as said, for my use case, I can also switch to http to get to the same result. thanks, Sebastian -Bob
Azalia: D0 power state
Hello! I has a problem on my Acer laptop with azalia. The HDA controller did not generate interrupts. And i heard the infinite looping sound. The reason of this is that the laptop BIOS always set the D3 power state for HDA controller during the boot time. This patch solved my problem. The second part of patch enable beep for my laptop. Index: sys/dev/pci/azalia.c === RCS file: /cvs/src/sys/dev/pci/azalia.c,v retrieving revision 1.201 diff -u -p -r1.201 azalia.c --- sys/dev/pci/azalia.c12 Aug 2012 19:32:22 - 1.201 +++ sys/dev/pci/azalia.c19 Oct 2012 08:18:20 - @@ -498,6 +498,8 @@ azalia_pci_attach(struct device *parent, sc-dmat = pa-pa_dmat; + pci_set_powerstate(pa-pa_pc, pa-pa_tag, PCI_PMCSR_STATE_D0); + v = pci_conf_read(pa-pa_pc, pa-pa_tag, ICH_PCI_HDBARL); v = PCI_MAPREG_TYPE_MASK | PCI_MAPREG_MEM_TYPE_MASK; if (pci_mapreg_map(pa, ICH_PCI_HDBARL, v, 0, Index: sys/dev/pci/azalia_codec.c === RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v retrieving revision 1.151 diff -u -p -r1.151 azalia_codec.c --- sys/dev/pci/azalia_codec.c 10 Sep 2010 15:11:23 - 1.151 +++ sys/dev/pci/azalia_codec.c 19 Oct 2012 08:18:20 - @@ -77,6 +77,7 @@ azalia_codec_init_vtbl(codec_t *this) break; case 0x10ec0269: this-name = Realtek ALC269; + this-qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D; break; case 0x10ec0272: this-name = Realtek ALC272;
Re: bind mountd to a specified port
On Thu, 18 Oct 2012 19:11:37 +0200
Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote:
getting NFS through a firewall is not that trivial with mountd binding to a
random port each time it starts.
Hi,
here is how I solved it after my proposal for a fixed-port-option was
rejected:
/etc/rc.local:
[...]
# register (random) rpc ports to pf anchor
rpcinfo -p localhost \
|awk \
'
/tcp/ \
{printf pass in proto %s to port %d\n, $3, $4}
/udp/ \
{printf pass in proto %s to port %d\n, $3, $4; \
printf pass out proto %s from port %d\n, $3, $4}
' \
|pfctl -a rpc -f -
[...]
/etc/pf.conf:
# NFS
# rpc daemons use more or less random ports; they will be put into this anchor
anchor rpc on {tun0 lo0} from nfs to (self)
anchor rpc on {tun0 lo0} from (self) to nfs
# local daemons need access to portmap before the rpc anchor is populated
pass in on lo0 inet proto {udp tcp} from localhost to localhost port portmap
glib threading issues
Hi, As some of you may be aware we're having a lot of issues in the glib port related to threading. And it seems it's now affecting non-GNOME ports as well. irssi just crashed on sparc64: (gdb) bt #0 0x0003781ec820 in ?? () from /usr/lib/libpthread.so.17.0 #1 0x000377ee700c in _thread_tag_init (tag=0xfffd2511) at /usr/src/lib/librthread/rthread_libc.c:46 #2 0x00037e15b404 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.3400.0 #3 0x00037e15b4b0 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.3400.0 #4 0x000173864ac4 in main () from /usr/local/bin/irssi (gdb) I'll rebuild irssi and glib with debugging symbols in order to get a better backtrace...but it seems the issues are far more reaching than we initially feared. It would be great if someone could help robert/ajacoutot/me in tracking down these issues. Thanks, Jasper
CSRG history now available as an SVN repository
I recently converted CSRG's SCCS repository holding the original BSD history to a Subversion repository. As a derivative work of CSRG's code base, this repository is available under the terms of the original UC Berkeley license. You can browse the history at http://svnweb.freebsd.org/csrg/ The repository is also available via FTP or HTTP: - ftp://ftp.freebsd.org/pub/FreeBSD/development/CSRG/csrg_svn.tbz - http://freebsd.isc.org/pub/FreeBSD/development/CSRG/csrg_svn.tbz Thanks to Simon Neilsen for putting the repository up on FreeBSD.org and to Kirk McKusick for preserving this history. -- John Baldwin
SIIG 4S PCIe 4-port Serial Card
The puc(4) man page lists the SIIG Cyber 4S PCI as supported. I just inserted a SIIG Cyber 4S PCIe. I figured it would look the same as the PCI card, considering that the new chip is named OXPCIe954, similar to the old OXPCI954. But obviously that was hopelessly naive. Instead I get: vendor Oxford, unknown product 0xc208 (class communications subclass serial, rev 0x00) at pci13 dev 0 function 0 not configured It looks like the vendor id is PCI_VENDOR_OXFORD2, and not PCI_VENDOR_SIIG. Any pointers on what data structure and defines I should try adding? It looks like the actual PUC driver is simple enough, I just need the card to be recognized. I'm running stock OpenBSD 5.1/amd64 on a Soekris net6501.
Re: SIIG 4S PCIe 4-port Serial Card
William Ahern wrote: The puc(4) man page lists the SIIG Cyber 4S PCI as supported. I just inserted a SIIG Cyber 4S PCIe. I figured it would look the same as the PCI card, considering that the new chip is named OXPCIe954, similar to the old OXPCI954. But obviously that was hopelessly naive. Instead I get: vendor Oxford, unknown product 0xc208 (class communications subclass serial, rev 0x00) at pci13 dev 0 function 0 not configured It looks like the vendor id is PCI_VENDOR_OXFORD2, and not PCI_VENDOR_SIIG. Any pointers on what data structure and defines I should try adding? It looks like the actual PUC driver is simple enough, I just need the card to be recognized. I'm running stock OpenBSD 5.1/amd64 on a Soekris net6501. When I put a variant in, I looked at the following files: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/pucdata.c?annotate=1.51 Search for henning and the section starting on line 551 is the patch in this file you want. This was the other (which didn't go in right away since I mangled the patch in email): http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/pcidevs?annotate=1.1434 Look for miod or 1.1434 to find that one line change. Now, mine mostly worked, except communication was garbled. Mine was one of the cards with a faster crystal. Assuming your just isn't recognized, some work with something like lspci would get the exact identifiers for you. It's been 4-5 years since then, and I had to look up these files, but I suspect this is the areas you are looking for. --Kurt Mosiejczuk
Re: SIIG 4S PCIe 4-port Serial Card
On 2012/10/19 12:44, William Ahern wrote:
The puc(4) man page lists the SIIG Cyber 4S PCI as supported. I just
inserted a SIIG Cyber 4S PCIe. I figured it would look the same as the PCI
card, considering that the new chip is named OXPCIe954, similar to the old
OXPCI954.
But obviously that was hopelessly naive. Instead I get:
vendor Oxford, unknown product 0xc208 (class communications
subclass serial, rev 0x00) at pci13 dev 0 function 0 not configured
It looks like the vendor id is PCI_VENDOR_OXFORD2, and not PCI_VENDOR_SIIG.
Any pointers on what data structure and defines I should try adding? It
looks like the actual PUC driver is simple enough, I just need the card to
be recognized.
I'm running stock OpenBSD 5.1/amd64 on a Soekris net6501.
My original mail about the chip (including diff) is at
http://marc.info/?l=openbsd-techm=126446213208560w=2, there is
some problem I was unable to track down which prevents things from
working when the port is set to the correct frequency, but setting
to half the frequency gets a usable port, you just need to half
the desired baud rate of the serial port (e.g. cu -s 4800 -l cua03).
Diff there won't apply directly as things have changed since then.
The pcidevs change might apply with patch but is simple enough to
hand-apply; after doing this, run make in sys/dev/pci to update
the pcidevs.h/pcidevs_data.h files.
The pucdata.c table has changed format since then to save memory,
something like the below should be about right, you can't get the
speed bang-on with the new table format (rather than recording
actual speed it uses shorthand to allow multipliers or powers-of-two
of the standard COM port UART frequency 1.8432MHz; the exact needed
speed can't be stored in this notation but using a multiplier of 17
should be close enough for other ports to lock onto it - if not
then try 18). This version is untested though as I am lacking
machines with PCIe slots that I can use for testing.
/* Oxford Semiconductor OXPCIe954 PCIe */
{ /* OXPCIe954, */
{ PCI_VENDOR_OXFORD2, PCI_PRODUCT_OXFORD2_OXPCIE954, 0, 0 },
{ 0x, 0x, 0, 0 },
{
/*
* Clock is fixed at 62.5 MHz, derived from PCIe clock.
* But this doesn't work so use half the speed.
* XXX Number of ports should not be hard-coded, it can vary
* and should be fetched from BAR offset 0x0004.
*/
{ PUC_COM_MUL(17), 0x10, 0x1000 },
{ PUC_COM_MUL(17), 0x10, 0x1200 },
{ PUC_COM_MUL(17), 0x10, 0x1400 },
{ PUC_COM_MUL(17), 0x10, 0x1600 },
},
},
Also the first PCIe954 chip can be connected to a companion chip(/s?)
to allow for up to 8 extra ports but you can't determine whether
this has been done just by looking at PCI IDs, you are supposed to
fetch information about how many ports are wired up from information
provided by the chip itself - however hardcoding the first 4 ports
is enough to get the 4-port card working.
Re: CSRG history now available as an SVN repository
On Fri, Oct 19, 2012 at 02:13:02PM -0400, John Baldwin wrote: I recently converted CSRG's SCCS repository holding the original BSD history to a Subversion repository. As a derivative work of CSRG's code base, this repository is available under the terms of the original UC Berkeley license. You can browse the history at http://svnweb.freebsd.org/csrg/ The repository is also available via FTP or HTTP: - ftp://ftp.freebsd.org/pub/FreeBSD/development/CSRG/csrg_svn.tbz - http://freebsd.isc.org/pub/FreeBSD/development/CSRG/csrg_svn.tbz Thanks to Simon Neilsen for putting the repository up on FreeBSD.org and to Kirk McKusick for preserving this history. I have some notes on converting the SCCS to git here: https://github.com/jonathangray/csrg-git-patches if Kirk has consented to the CSRG repository being made available I'll put up the resulting git repository.
