tty process group use-after-free fix RFC

[Jonathan A. Kollasch]

I've discovered that there's a use-after-free bug that is triggered by
multiply-opened tty(4) devices where one process uses FIOSETOWN and then
exits.  It occurs, for example, when first ntpd(8) opens a GPS_NMEA(0)
refclock (/dev/gps0 -> /dev/ttyU0), and subsequently gpsd(8) opens the
same tty.  ntpd(8) does a FIOSETOWN ioctl on this tty soon after startup
that sets tp->t_pgrp.  (gpsd does not seem to explicitly FIOSETOWN or
TIOCSCTTY.)  Subsequently when you stop the ntpd process (with
gpsd still running) tp->t_pgrp points to freed chunk of memory.  Soon,
ttysigintr() tries to send SIGIO to this process group, and things
explode (the symptom may vary, as the pgrp memory could have been
re-used, or kASan may have intercepted it, or you just segfault in the
kernel).

I see that the TIOCSCTTY case in ttioctl() calls proc_sesshold(), but
the FIOSETOWN or TIOCSPGRP cases, which are vaguely similar, do not.

The attached patch prevents the UAF bug I observed, but I'm not confident
it's correct; and I'm even less confident for the TIOCSPGRP case which I
was unable to test.  I am mostly concerned it may result in a memory leak,
or at worst a deadlock, but perhaps that's better than crashing the kernel.

    Jonathan Kollasch
Index: src/sys/kern/tty.c
===
RCS file: /cvsroot/src/sys/kern/tty.c,v
retrieving revision 1.312
diff -d -u -a -p -r1.312 tty.c
--- src/sys/kern/tty.c	7 Dec 2023 09:00:32 -	1.312
+++ src/sys/kern/tty.c	24 Apr 2024 01:58:14 -
@@ -1441,6 +1441,7 @@ unlock_constty:	mutex_exit(_lock
 			return (EPERM);
 		}
 		mutex_spin_enter(_lock);
+		proc_sesshold(pgrp->pg_session);
 		tp->t_pgrp = pgrp;
 		mutex_spin_exit(_lock);
 		mutex_exit(_lock);
@@ -1464,6 +1465,7 @@ unlock_constty:	mutex_exit(_lock
 			return (EPERM);
 		}
 		mutex_spin_enter(_lock);
+		proc_sesshold(pgrp->pg_session);
 		tp->t_pgrp = pgrp;
 		mutex_spin_exit(_lock);
 		mutex_exit(_lock);

Re: UEFI: caveats about not utf-8 dir entries

[Jonathan A. Kollasch]

On Thu, Jan 12, 2023 at 09:20:34AM +0100, tlaro...@polynum.com wrote:
> I don't know if this is for tech-kern or tech-userlevel (perhaps the
> two).
> 
> I just read today, on the devel UEFI edk2 devel list, from patches for
> ext4, a comment on the problem of the encoding of dir entries.
> 
> The problem is that, generally in fs, no encoding is specified: dir
> entries are just a sequence of bytes, whether nul byte terminated or
> with the length of the entry given (the later for ext4).
> 
> UEFI (edk2) deals, internally, with UCS-2 strings.
> 
> With ext4 (and I expect this is the same for other fs drivers),
> conversion is attempted from utf-8. Here, if the "from utf-8" conversion
> errors (not utf-8), the dir entry is skipped, meaning that not anything
> on a fs read can be reached by the UEFI code.
> 
> This has to be kept in mind when populating a msdos partition for
> booting and for people wandering in a filesystem using the UEFI shell:
> even if the fs is readable, perhaps not everything will be accessible.

Not a problem, none of our boot code is likely to use anything
beyond ACSII-compatible code points, and for the foreseeable future
we'll be using the FAT-formatted ESP, where the long file name support
is supposed to be UCS-2 anyway (that is, not UTF-16).

If you need multi-astral-plane-codepoint Unicode emoji to boot an OS
you're doing something very wrong.

Re: Problems with implementing EFI runtime support for x86

[Jonathan A. Kollasch]

On Tue, Sep 13, 2022 at 04:16:19PM +0200, Paweł Cichowski wrote:
> Hello,
> 
> I am currently trying to implement efi runtime for x86-based ports, and I

In https://github.com/3mdeb/NetBSD-src/pull/2/files
I see you define EFI_ATTRIBUTES, but then never seem to invoke
EFI_ATTRIBUTES on any of the function signatures for the RT services
functions (the ones that call into platform firmware function pointers).

(On IA-32 and x86_64, {,U}EFI uses the Microsoft ABI calling conventions,
which are not the same as the System V calling conventions.  On ARM,
both System V and UEFI use the same ARM-defined AAPCS standard.)

Re: questions about undocumented USB drivers

[Jonathan A. Kollasch]

On Fri, Jul 08, 2022 at 09:18:47AM +, nia wrote:
> I'd like to know more about these drivers so I can write man pages
> for them, so any input is welcome.
> 
 ~
 ~
> sys/dev/usb/slurm.c
> 
>   This one caught my eye because it doesn't have the "u" prefix.
>   Log message, from jakllsch@ in 2013:
>   "Add slurm(4), a radio(4) driver for USB FM radio modules based
>   on the Silicon Labs reference design."
>   I can get a rough idea of the driver's capabilities by reading
>   the code. It seems much better than udsbr(4), the only USB
>   radio(4) driver we do document.

I'm somewhat of the belief that the 'u' prefix denotes a USB "class
device" driver; and there's no USB class number or specification for
these devices, and as such the 'u' prefix isn't strongly suggested.
Plus, that reasoning allowed me to make a reference to pop culture.

The hardware I developed against is an Instant FM Music, model RDX-155,
from ADS Tech.  I still have it around.

A slurm(4) page should reference uaudio(4), as there's always/often no
other way to get the audio signal out of the device.

Re: VirtIO MMIO for amd64

[Jonathan A. Kollasch]

On Wed, Feb 23, 2022 at 12:28:36PM +0200, el16095 wrote:
> I've been working on a NetBSD-based unikernel and trying to make it
> compatible with the Firecracker VMM. Seeing as Firecracker only supports the
> MMIO transport method for VirtIO, I wanted to implement MMIO support for my
> unikernel.
> 
> I've seen that newer versions of NetBSD than what my source code was using
> have code for MMIO and specifically that Virtio MMIO support was implemented
> for ARM in NetBSD 9.0. So, what I want to ask is there similar support for
> amd64 also and if not are there some basics I could imitate from how it was
> implemented for ARM to get it working for amd64 also? Alternatively, is
> there any reading material you can suggest that explains how the device
> system works in NetBSD, so that I might possibly understand what changes
> would be needed by myself?

There shouldn't be anything preventing our existing Virtio MMIO via ACPI
code from working on amd64 in -current.  Probably just needs enabling
and testing. 

The "virtio* at acpi?" attachment is not currently included in the i386
or amd64 GENERIC kernels however.

I don't even know that Firecracker informs the guest about Virtio
MMIO devices via ACPI (or FDT).  If not, you'll need to create glue code
similar to virtio_acpi.c or virtio_mmio_fdt.c.

Re: Ext4 support

[Jonathan A. Kollasch]

On Fri, Apr 30, 2021 at 12:56:04PM +0200, tlaro...@polynum.com wrote:
> There is excellent support, thanks to Reinoud Zandijk, in NetBSD for
> UDF. And this is cross-system (I use it to share---not distribute: it's
> not a NFS or a Samba---back-ups between NetBSD and MS Windows).
> 

It's only excellent if you have access to a functional UDF fsck
program.  NetBSD and Linux do not have a functional UDF fsck.

Re: Sample boot.cfg for upgraded systems (rndseed & friends)

[Jonathan A. Kollasch]

On Tue, Sep 22, 2020 at 05:53:49PM +0100, David Brownlee wrote:
> Should NetBSD be shipping a default boot.cfg in /usr/share/examples
> (*) - thinking primarily of people who have upgraded from earlier
> NetBSD versions.
> 
> I was looking to add in rndseed & just generally sync with the latest
> version but there doesn't seem to be a default example shipped with
> the system
> 

/boot.cfg is already shipped as part of the 'etc' set, and is handled by
etcupdate(8) like any other configuration file.

Re: Proposal to enable WAPBL by default for 10.0

[Jonathan A. Kollasch]

On Wed, Jul 22, 2020 at 11:24:16PM +0200, Kamil Rytarowski wrote:
> I propose to enable WAPBL ("log" in fstab(5)) by default for 10.0 and newer.

I oppose such a move.  I will not be able to support any such change
until https://gnats.netbsd.org/47231 is satisfactorily resolved.

Jonathan

Re: UEFI boot and PCI interrupt routing (amd64)

[Jonathan A. Kollasch]

On Thu, Jun 04, 2020 at 01:23:59AM +0200, Jaromír Doleček wrote:
> Hi,
> 
> I'm working on a driver for some PCI device, I'm far enough to execute
> operations which should trigger interrupt, but the interrupt handler
> (registered via pci_intr_establish()) is not called. It looks like
> there is some kind of interrupt routing problem, maybe.
> 
> Any hints on what could/should I check?
> 
> Unfortunately can't boot the machine in legacy mode, to check whether
> it's due to mission initialisation by BIOS.
> 
> Jaromir

If the operation in question is DMA: can you confirm the Bus Master
Enable bit in the PCI Command register is in the enabled state?  Also
the Interrupt Disable bit is disabled xor MSI(-X) is enabled?  You
might also confirm that the device is capable of classic INTx
interrupts, or if you must use MSI(-X).

Assuming x86: both BIOS and UEFI boot paths will probably be using the
same ACPI DSDT/SSDTs for interrupt mapping, and the legacy MPBIOS and
PIRQ (we don't consult PIRQ anyway) routing information tables are
being validated by board firmware producers less than they used to be
anyway, sometimes to the point where they don't even work.

Jonathan

Re: kernel stack usage

[Jonathan A. Kollasch]

On Sat, May 30, 2020 at 11:52:18AM +0200, Martin Husemann wrote:
> 1248aubtfwl_attach_hook at aubtfwl.c:273
> 

I took care of this.  It was placing MAXPATHLEN+1 chars on the stack.

While PNBUF_GET/PUT() seemed like a possible choice, I decided on
kmem_asprintf()/kmem_strfree(), as in reality it needs nowhere near a
MAXPATHLEN.

Re: svr4, again

[Jonathan A. Kollasch]

On Sat, Mar 09, 2019 at 11:28:05AM +0100, Maxime Villard wrote:
> Re-reading this thread - which was initially about SVR4 but which diverged in
> all directions -, I see there were talks about retiring COMPAT_ULTRIX and
> COMPAT_OSF1, because these were of questionable utility, in addition to being
> clear dead wood (in terms of use case, commits in these areas, and ability to
> test changes).
> 
> Does anyone have anything to say?

Possibly, although I doubt they'll notice they want to say something in
this thread with the current Subject line...  I'd suggest starting a
new thread, possibly CCing port-pmax@ and port-alpha@ as relevant.

Jonathan Kollasch

Re: aprint_* used outside autoconfiguration step

[Jonathan A. Kollasch]

On Tue, Feb 19, 2019 at 10:49:04AM -0500, Christos Zoulas wrote:
> I've noticed that now the "autoconfiguration print" error messages
> are printing "autoconfiguration error: " we have a situation where
> aprint_ calls are happening outside the autoconfiguration process.
> This is confusing. What makes this difficult to fix is:
> 
>   1. Some of the calls can happen during the autoconfiguration
>  phase and also later (during normal operations). For example
>  the iffoo_init() routine and its children calls.
>   2. We don't have a non-autoconfig-related family of printf
>  calls to handle errors outside autoconfiguration.
> 
> I propose to go for the simplest fix for now, which is to only print
> "autoconfiguration error: " during the autoconfiguration process (i.e.
> once autoconfiguration is done, to skip printing it. This again is
> wrong in some cases (hotplug), but something simplistic such as the
> following might take care of the majority of the cases:

While the primary reason I added this was to expose which parts of the
dmesg were actually errors, a secondary reason was to help curb the
abuse of aprint_error at runtime.  While I'm of the opinion that aprint_*
should be used iff within the autoconf(9) paths, I'm also seeing now
that if you want a perfectly silent AB_SILENT boot, you can't have plain
printfs making a mess.  So, somewhat reluctantly I accept the general
idea of your proposal as an immediate solution.

Jonathan Kollasch

Re: Reserve device major numbers for pkgsrc

[Jonathan A. Kollasch]

On Sat, Feb 16, 2019 at 11:25:36PM +0100, Kamil Rytarowski wrote:
> We started to build and ship kernel modules through pkgsrc.

We did a long time ago, sort of...

> I would like to reserve 3 major numbers for the HAXM case from the base
> pool of devices and prevent potential future conflicts and compatibility
> breakage due to picking up another major number in a 3rd party software.
> 
> Where and how to reserve these major numbers?
> 
> I expect that we will start growing software that uses our kernel module
> framework. (I have got few candidates to get ported in future)
> 

Some history from AFS/OpenAFS/Arla:

Our base system reserves a syscall number (210) for the AFS syscall,
which is used either by the OpenAFS kernel module, or the Arla nnpfs
kernel module.  (Neither of these modules are currently functional with
modern NetBSD.)

Arla nnpfs additionally used a character device major, which it IIRC
allocated dynamically at module load time, which was then somehow
conveyed to userland to mknod the necessary device special before
starting arlad.

I'd suggest similar for this: allocate a MI range of character and block
majors for quasi-external use, and then make registrations for your
needs.

Jonathan Kollasch

P.S.
Maybe reserve the first character major in the block for nnpfs
as a sort of monument to Arla (which is pretty much abandoned these
days).

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

[Jonathan A. Kollasch]

On Fri, Feb 15, 2019 at 10:44:23PM +0900, Rin Okuyama wrote:
> On 2019/02/15 21:57, Jonathan A. Kollasch wrote:
> > On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote:
> > > Hi,
> > > 
> > > On 2019/02/13 3:54, Nick Hudson wrote:
> > > > On 12/02/2019 16:02, Rin Okuyama wrote:
> > > > > Hi,
> > > > > 
> > > > > The system freezes indefinitely with xhci(4) or ehci(4), when NIC with
> > > > > multiple outstanding transfers [axen(4), mue(4), and ure(4)] is 
> > > > > stopped
> > > > > by "ifconfig down" or detached.
> > > > > 
> > > > > As discussed in the previous message, this is due to infinite loop in
> > > > > usbd_ar_pipe(); xfers with USBD_NOT_STARTED remain in a queue forever
> > > > > because upm_abort [= xhci_device_bulk_abort() etc.] cannot remove 
> > > > > them.
> > > > 
> > > > 
> > > > Why not the attached patch instead?
> > > > 
> > > > Nick
> > > 
> > > Thank you so much for your prompt reply!
> > > 
> > > It works if s/ux_state/ux_status/ here:
> > > 
> > > + if (xfer->ux_state == USBD_NOT_STARTED) {
> > > 
> > > Can I commit the revised patch?
> > > 
> > 
> > The revised patch results in
> > https://nxr.netbsd.org/xref/src/sys/dev/usb/ehci.c?r=1.265#1566
> > firing upon `drvctl detach -d bwfm0` on Pinebook.
> > 
> > Jonathan Kollasch
> 
> IMO, this is because NOT_STARTED queues are removed in a way that is
> unexpected to ehci. For my old amd64 box, the attached patch fixes
> assertion failures when devices are detached from ehci. I would like
> to commit it together with the previous patch.
> 

Works for me; please commit.  (I'm not 100% sure it's perfect, but
it's better than it was, and we can fix it again later if necessary.)

Jonathan Kollasch

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

[Jonathan A. Kollasch]

On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote:
> Hi,
> 
> On 2019/02/13 3:54, Nick Hudson wrote:
> > On 12/02/2019 16:02, Rin Okuyama wrote:
> > > Hi,
> > > 
> > > The system freezes indefinitely with xhci(4) or ehci(4), when NIC with
> > > multiple outstanding transfers [axen(4), mue(4), and ure(4)] is stopped
> > > by "ifconfig down" or detached.
> > > 
> > > As discussed in the previous message, this is due to infinite loop in
> > > usbd_ar_pipe(); xfers with USBD_NOT_STARTED remain in a queue forever
> > > because upm_abort [= xhci_device_bulk_abort() etc.] cannot remove them.
> > 
> > 
> > Why not the attached patch instead?
> > 
> > Nick
> 
> Thank you so much for your prompt reply!
> 
> It works if s/ux_state/ux_status/ here:
> 
> + if (xfer->ux_state == USBD_NOT_STARTED) {
> 
> Can I commit the revised patch?
> 

The revised patch results in
https://nxr.netbsd.org/xref/src/sys/dev/usb/ehci.c?r=1.265#1566
firing upon `drvctl detach -d bwfm0` on Pinebook.

Jonathan Kollasch

Re: ppb(4) related changes

[Jonathan A. Kollasch]

On Mon, Jan 28, 2019 at 07:34:29PM +0900, Masanobu SAITOH wrote:
>  Hi.
> 
>  I'm now working to modify PCI bridge stuff. I'd like to do the following
> two modifications:
> 
>  0) ppbreg.h definitions
> 
> All of PCI configuration space's register definitions are in pcireg.h
> The ppbreg.h file also defines the same config registers. I think it's
> good to remove ppbreg.hs' definitions an use pcireg.h's definitions.
> Is it OK?

Seems reasonable, although be sure to fix everything that includes it.

> 
>  1) Mis-configuration of prefetchable memory in pciconf.c::configure_bridge()
> (only for PCI_NETBSD_CONFIGURE)
> 
> In configure_bridge():
> 
> > mem = pci_conf_read(pb->pc, pd->tag, PCI_BRIDGE_PREFETCHMEM_REG);
> 
>   Read register
> 
> > #if ULONG_MAX > 0x
> > if (!PCI_BRIDGE_PREFETCHMEM_64BITS(mem) && mem_limit > 
> > 0xULL) {
> 
>   Test if it's marked as 64bit (the maring is in lower 4bit)
> 
> > printf("Bus %d bridge does not support 64-bit PMEM.  ",
> > pb->busno);
> > printf("Disabling prefetchable-MEM accesses\n");
> > mem_base  = 0x10;   /* 1M */
> > mem_limit = 0x00;
> > }
> > #endif
> > mem = (((mem_base >> 20) & PCI_BRIDGE_PREFETCHMEM_BASE_MASK)
> > << PCI_BRIDGE_PREFETCHMEM_BASE_SHIFT);
> > mem |= (((mem_limit >> 20) & PCI_BRIDGE_PREFETCHMEM_LIMIT_MASK)
> > << PCI_BRIDGE_PREFETCHMEM_LIMIT_SHIFT);
> > pci_conf_write(pb->pc, pd->tag, PCI_BRIDGE_PREFETCHMEM_REG, mem);
> 
>   Regenerate mem value from scratch _WITHOUT_SETTING_LOWER_4BITS_
>   (It's OK because the lower 4bit is read only).
> 
> > /*
> >  * XXX -- 64-bit systems need a lot more than just this...
> >  */
> > if (PCI_BRIDGE_PREFETCHMEM_64BITS(mem)) {
> 
>   Test if it's marked as 64bit or not. It must be wrong because "mem"
>   is not the original value, newly generated and low 4bits are 0.
>   It should always be false.
> 
> > mem_base  = (uint64_t) mem_base  >> 32;
> > mem_limit = (uint64_t) mem_limit >> 32;
> > pci_conf_write(pb->pc, pd->tag, 
> > PCI_BRIDGE_PREFETCHBASE32_REG,
> > mem_base & 0x);
> > pci_conf_write(pb->pc, pd->tag, 
> > PCI_BRIDGE_PREFETCHLIMIT32_REG,
> > mem_limit & 0x);
> > }
> 
>   So, proposed patch:
> --
> Index: pciconf.c
> ===
> RCS file: /cvsroot/src/sys/dev/pci/pciconf.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 pciconf.c
> --- pciconf.c 5 Sep 2014 05:29:16 -   1.37
> +++ pciconf.c 28 Jan 2019 10:30:13 -
> @@ -855,6 +855,7 @@ configure_bridge(pciconf_dev_t *pd)
>   pciconf_bus_t   *pb;
>   pcireg_tio, iohigh, mem, cmd;
>   int rv;
> + boolisprefetchmem64;
>   pb = pd->ppb;
>   /* Configure I/O base & limit*/
> @@ -919,8 +920,9 @@ configure_bridge(pciconf_dev_t *pd)
>   mem_limit = 0x00;
>   }
>   mem = pci_conf_read(pb->pc, pd->tag, PCI_BRIDGE_PREFETCHMEM_REG);
> + isprefetchmem64 = PCI_BRIDGE_PREFETCHMEM_64BITS(mem);
>  #if ULONG_MAX > 0x
> - if (!PCI_BRIDGE_PREFETCHMEM_64BITS(mem) && mem_limit > 0xULL) {
> + if (!isprefetchmem64 && mem_limit > 0xULL) {
>   printf("Bus %d bridge does not support 64-bit PMEM.  ",
>   pb->busno);
>   printf("Disabling prefetchable-MEM accesses\n");
> @@ -936,7 +938,7 @@ configure_bridge(pciconf_dev_t *pd)
>   /*
>* XXX -- 64-bit systems need a lot more than just this...
>*/
> - if (PCI_BRIDGE_PREFETCHMEM_64BITS(mem)) {
> + if (isprefetchmem64) {
>   mem_base  = (uint64_t) mem_base  >> 32;
>   mem_limit = (uint64_t) mem_limit >> 32;
>   pci_conf_write(pb->pc, pd->tag, PCI_BRIDGE_PREFETCHBASE32_REG,
> --
> 
>   I can't test this diff because I have no any machine which can test
>   PCI_NETBSD_CONFIGURE now. Is it OK to commit without test?
> 

This also seems reasonable.  This might be the sort of change that
could break video card console output.  However, I think on the vast
majority of machines where this could be a problem generally a serial
console is used, or PCI_NETBSD_CONFIGURE is not enabled.

Jonathan Kollasch

Re: Question about memory

[Jonathan A. Kollasch]

On Mon, Dec 17, 2018 at 05:15:51PM +, Prowell, Stacy J. wrote:
> I have a question about memory, and hope this is the place to ask.
> 
> I have blades that have 1.5TB of DRAM, and want to run NetBSD if I can, but I 
> am hitting the 512GB limit.  “panic: RAM limit reached: > 512GB not 
> supported” 
> 
> Can someone give me a sense of how much pain would be involved in raising the 
> limit… or let me know to give up and move to another OS?  I can tell you the 
> next round of blades will probably have >2TB of DRAM.
> 
> Thanks in advance for any help,

Please try -current.  It appears that that panic, while present in
NetBSD 8.0, has been removed since.  Additionally, it appears that
currently up to 16TiB of RAM is supported in -current for NetBSD/amd64.

Jonathan Kollasch

Re: CVS commit: src/sys/dev/pci

[Jonathan A. Kollasch]

On Wed, May 16, 2018 at 01:45:36PM -0700, Jason Thorpe wrote:
> 
> 
> > On May 16, 2018, at 1:07 PM, Jonathan A. Kollasch <jakll...@kollasch.net> 
> > wrote:
> > 
> > I'm a bit uneasy about it myself for that same reason.  However, we
> > do not to my knowledge have the infrastructure available to do a
> > complete validation of the resource assignment.  If we did, we'd be
> > able to do hot attach of PCIe ExpressCard with just a little more work.
> 
> 
> We used to have something like this to support CardBus way back in the day, 
> but I will admit I wasn’t entirely happy with it at the time.

rbus?  That's still around, and it's still ugly and doesn't always work.

> I guess I’m frustrated that UEFI isn’t taking care of this.  On the other 
> hand, perhaps UEFI isn’t doing it because they assume that the BARs have to 
> be reprogrammed if power is removed from the device?

Likewise.  I have no idea what their reasoning is.

> What does FreeBSD do?

I'm not sure I'm reading it correctly but..

FreeBSD appears to have a enabled-by-default and kernel-load-time-adjustable
knob for enabling the decodes in the CSR.  (hw.pci.enable_io_modes, AKA
static int pci_enable_io_modes in dev/pci/pci.c)

They also have pci_activate_resource().  But I'm not sure what calls it
and what exactly it does for which devices.


Does the attached patch look to be an improvement?  Admittedly this
added knob would be of the `boot -d`/`gdb -write` sort, but it'd be
there.

Perhaps another way to do this would be to leave this knob disabled,
but turn it on when boot on a UEFI/x86 machine is detected.

Jonathan Kollasch
Index: sys/dev/pci/pci_map.c
===
RCS file: /cvsroot/src/sys/dev/pci/pci_map.c,v
retrieving revision 1.34
diff -d -u -a -p -r1.34 pci_map.c
--- sys/dev/pci/pci_map.c   16 May 2018 19:02:00 -  1.34
+++ sys/dev/pci/pci_map.c   17 May 2018 16:50:39 -
@@ -43,6 +43,8 @@ __KERNEL_RCSID(0, "$NetBSD: pci_map.c,v 
 #include 
 #include 
 
+int pci_enable_decode = 1;
+
 static int
 pci_io_find(pci_chipset_tag_t pc, pcitag_t tag, int reg, pcireg_t type,
 bus_addr_t *basep, bus_size_t *sizep, int *flagsp)
@@ -293,11 +295,6 @@ pci_mapreg_submap(const struct pci_attac
if (PCI_MAPREG_TYPE(type) == PCI_MAPREG_TYPE_IO) {
if ((pa->pa_flags & PCI_FLAGS_IO_OKAY) == 0)
return 1;
-   s = splhigh();
-   csr = pci_conf_read(pa->pa_pc, pa->pa_tag, 
PCI_COMMAND_STATUS_REG);
-   csr |= PCI_COMMAND_IO_ENABLE;
-   pci_conf_write(pa->pa_pc, pa->pa_tag, PCI_COMMAND_STATUS_REG, 
csr);
-   splx(s);
if (pci_io_find(pa->pa_pc, pa->pa_tag, reg, type, ,
, ))
return 1;
@@ -305,11 +302,6 @@ pci_mapreg_submap(const struct pci_attac
} else {
if ((pa->pa_flags & PCI_FLAGS_MEM_OKAY) == 0)
return 1;
-   s = splhigh();
-   csr = pci_conf_read(pa->pa_pc, pa->pa_tag, 
PCI_COMMAND_STATUS_REG);
-   csr |= PCI_COMMAND_MEM_ENABLE;
-   pci_conf_write(pa->pa_pc, pa->pa_tag, PCI_COMMAND_STATUS_REG, 
csr);
-   splx(s);
if (pci_mem_find(pa->pa_pc, pa->pa_tag, reg, type, ,
, ))
return 1;
@@ -339,6 +331,15 @@ pci_mapreg_submap(const struct pci_attac
if (bus_space_map(tag, base, reqsize, busflags | flags, ))
return 1;
 
+   if (pci_enable_decode) {
+   s = splhigh();
+   csr = pci_conf_read(pa->pa_pc, pa->pa_tag, 
PCI_COMMAND_STATUS_REG);
+   csr |= (PCI_MAPREG_TYPE(type) == PCI_MAPREG_TYPE_IO) ?
+   PCI_COMMAND_IO_ENABLE : PCI_COMMAND_MEM_ENABLE;
+   pci_conf_write(pa->pa_pc, pa->pa_tag, PCI_COMMAND_STATUS_REG, 
csr);
+   splx(s);
+   }
+
if (tagp != NULL)
*tagp = tag;
if (handlep != NULL)

Re: CVS commit: src/sys/dev/pci

[Jonathan A. Kollasch]

On Wed, May 16, 2018 at 12:50:22PM -0700, Jason Thorpe wrote:
> 
> 
> > On May 16, 2018, at 12:02 PM, Jonathan A. Kollasch <jakll...@netbsd.org> 
> > wrote:
> > 
> > Module Name:src
> > Committed By:   jakllsch
> > Date:   Wed May 16 19:02:00 UTC 2018
> > 
> > Modified Files:
> > src/sys/dev/pci: pci_map.c
> > 
> > Log Message:
> > Enable the appropriate memory or I/O space decode in the PCI
> > Command/Status Register upon mapping a BAR.
> > 
> > This should fix PR #53286.  It's also possible there are other similar
> > PRs that might be fixed by this.
> 
> This change makes me a tad uneasy, mainly because it doesn’t seem to ensure 
> that that the BAR contains something sensible before enabling the decode.

I'm a bit uneasy about it myself for that same reason.  However, we
do not to my knowledge have the infrastructure available to do a
complete validation of the resource assignment.  If we did, we'd be
able to do hot attach of PCIe ExpressCard with just a little more work.

The worst case scenario is that we deface essential non-volatile memory
somewhere.  However, the more likely failure scenario is that some
bit of memory or MMIO starts getting decoded by the wrong device and
the machine does something between triple fault and hardware deadlock.

Jonathan Kollasch

Re: i386 uniprocessor build

[Jonathan A. Kollasch]

On Wed, Jan 24, 2018 at 01:29:30PM +0100, Fekete Zoltán wrote:
> Hi There,
> 
> I tried to comment out MULTIPROCESSOR option in std.i386. However the system
> could not build a kernel without this option (PREEMPTION first as a
> depenedency).

'options MULTIPROCESSOR' has been a required option for the x86 ports
for years now.

> Is there any way to build a kernel for a certain uniprocessor machine (old
> Pentium 3)?

With 'options MULTIPROCESSOR'.  The code paths are automatically
optimized for uni/multi-processor machines with runtime patching.

Jonathan Kollasch

Re: ndis [was Re: Proposal: Disable autoload of compat_xyz modules]

[Jonathan A. Kollasch]

On Mon, Jul 31, 2017 at 10:56:41PM +, Taylor R Campbell wrote:
> > Date: Tue, 1 Aug 2017 00:45:24 +0200
> > From: Kamil Rytarowski <n...@gmx.com>
> > 
> > > compat_ndis
> > 
> > This one perhaps could stay. It's for network driver.
> 
> On review, it appears this is not actually included in any GENERIC
> kernels at all -- or even the x86 ALL kernels.  It doesn't even seem
> to build.  It is marked as `experimental'.  Does anyone care about it?
> 

I might care about it if it worked.  I couldn't even make it work for
wired NICs some years ago.  I have a feeling it's incomplete and/or
broken.  I don't think it does any syscall compat stuff though.

Jonathan Kollasch

Re: HEADS-UP: jdolecek-ncq branch merge imminent

[Jonathan A. Kollasch]

On Wed, Jun 07, 2017 at 09:45:48PM +0200, Jaromír Doleček wrote:
> Hello,
> 
> I plan to merge the branch to HEAD very soon, likely over the weekend.
> Eventual further fixes will be done on HEAD already, including mvsata(4)
> restabilization, and potential switch of siisata(4) to support NCQ.
> 
> The plan is to get this pulled up to netbsd-8 branch soon also, so that it
> will be part of 8.0.
> 
> Status:
> - ahci(4) fully working with NCQ (confirmed with qemu, and real hw)
> - piixide(4) continues working (no NCQ support of course) (confirmed in
> qemu)
> - siisata(4) continues working (without NCQ still) (confirmed with real hw)
> - mvsata(4) not yet confirmed working after changes, mainly due the DMA not
> really working on Marvell 88SX6042 which I have available - I have same
> issue as kern/52126
> - other ide/sata drivers received mechanical changes, should continue
> working as before
> 
> Jaromir

My limited testing has shown that the device error handling paths need
work yet.  It's unfortunately been a few weeks since I've tested things,
so my memory isn't fresh with the details.  The general issue is that
ata(4) is doing error handling in interrupt context, and NCQ error
handling is straining that assumption.

At this point I advise that the branch could be synced with HEAD and
further testing done before merge.  I can not advise that this be
pulled up to netbsd-8 before more extensive and comprehensive testing
has been done.

I've got siisata(4) NCQ stuff I should commit to the branch.

Jonathan Kollasch

Re: Modules and bus_dmamap_create() failing

[Jonathan A. Kollasch]

On Sat, May 27, 2017 at 11:21:14AM +0200, Jaromír Doleček wrote:
> The driver allocates sizeable, but not excessive amounts of memory - mostly
> working with values like MAXPHYS / PAGE_SIZE * (queue size) for dmamaps/dma
> memory, where queue size is 128 or so.

No, that's excessive for a contiguous chunk.  You can only expect such
large contiguous allocations to work at boot.  Physical memory becomes
too fragmented after the machine has been up and doing things.  We
could really use a way to defrag physical memory, but doing that is not
easy.

    Jonathan Kollasch

Re: Initial ahci(4) NCQ support on jdolecek-ncq branch, test/review wanted

[Jonathan A. Kollasch]

On Thu, Apr 20, 2017 at 12:25:47AM +0200, Jaromír Doleček wrote:
> Hi,
> 
> I've committed the initial NCQ support, it's available at jdolecek-ncq
> branch (branch only over sys). It works under Parallels for now, and
> is ready for brave adventurers. There is sys/dev/ata/TODO.ncq which
> you might want to check, also.
> 
> If people want to try it out and give feedback, I'd really appreciate it.
> 
> I'll be busy for next 2-3 weeks elsewhere, so probably won't have too
> much time for bugfixing during the time. After that I plan to start
> testing with real hardware, and look on remaining bugs.
> 
> One of the more annoying bugs right now is that AHCI NCQ transfers
> pretty frequently timeout for me under Parallels. Maybe interrupt
> handling is not quite right yet in the driver. I only got so far to
> note that every transfer gets two interrupts, one with IS 0x8 and one
> 0x0 The 0x8 is Set device bit and is expected for NCQ, the other not
> so much.
> My understanding of ATA and AHCI specs is not good enough yet, so if
> somebody could look there and sanity check, I would be really glad.
> 
> Also, I've not modified mvsata(4) and siisata(4) drivers yet to enable
> NCQ. While the drivers seem to be mostly prepared, I lack the
> hardware, so have no way to test. I would really appreciate if folks
> with the hardware could check it out and possibly provide patches to
> enable the support there.

I plan to look at siisata(4).  I've got mvsata(4) hardware too.

> Last but not least, there is simply no consideration in AHCI for PMP
> in the changes. I have no idea if it needs special support. I hope
> not, but would be nice if our PMP experts would sanity check.
 
I've also got a port multiplier enclosure.  I suspect there may need to
be adjustments to the PMP paths.

Thanks for looking at this!  I'd been threatening to look at this for a
decade!

Jonathan Kollasch

Re: Using SPI devices from userspace on the RPI, or from anything NetBSD for that matter?

[Jonathan A. Kollasch]

On Sat, Dec 31, 2016 at 11:47:07AM -0600, Jonathan A. Kollasch wrote:
> Example config(5) file addition:
> 
> spigen0 at spi1 slave 0
> 

Also useful:

device-majorspigen  char 159spigen

and then you can use:

# mknod spigen0 c spigen 0

Jonathan Kolasch

Re: Using SPI devices from userspace on the RPI, or from anything NetBSD for that matter?

[Jonathan A. Kollasch]

Yeah... finally managed to find a moment to package them up:

https://ftp.netbsd.org/pub/NetBSD/misc/jakllsch/20161231/spigen-20161231.tar.gz

(this tarball may also be found attached)

Example config(5) file addition:

spigen0 at spi1 slave 0

Included in the tarball is an example that attempts to read a JEDEC ID
number from a "25"-series (such as Winbond W25Q80) SPI NOR Flash ROM.

Hope this helps.

Folks on tech-kern@: Feel free to review the API...  It's probably
lacking flexibility the Linux spidev API has.

    Jonathan Kollasch

On Wed, Dec 14, 2016 at 09:21:52AM -0800, Brian Buhrow wrote:
> 
> Would you be willing to share those local patches? 
> -thanks
> -Brian
> 
> 
> sent on the hoof
> 
> > On Dec 14, 2016, at 7:51 AM, Jonathan A. Kollasch <jakll...@kollasch.net> 
> > wrote:
> > 
> >> On Tue, Dec 13, 2016 at 10:42:26PM -0800, Brian Buhrow wrote:
> >>hello.  I'm working on a project where I think I'll be wanting to talk
> >> to an SPI connected LCD or LED display on an Rasberry Pi.  What I envision
> >> doing with it shouldn't require a kernel level driver given the fact that
> >> we already have the SPI(4) framework.  My question is, how can a user-space
> >> program  read from or write to  a SPI connected peripheral?  I've found the
> >> gpioctl(8) program and gpio( devices for talking to GPIO connected devices,
> >> but I don't see how to speak to SPI connected things.  Can anyone enlighten
> >> me?  I realize I may be asking a very elementary question, but my
> >> documentation searches haven't revealed what I want for NetBSD.  I've found
> >> such documents for Linux, but I'd really like to use NetBSD for this
> >> project.
> >> 
> >> Any thoughts would be greatly appreciated.
> >> -thanks
> >> -Brian
> > 
> > spi(4) does not currently expose access to userland.  I've got local
> > patches that do however..
> > 
> >Jonathan Kollasch
> 


spigen-20161231.tar.gz
Description: Binary data

Re: CVS commit: src/tests/lib/libusbhid

[Jonathan A. Kollasch]

On Sat, Aug 20, 2016 at 09:36:14PM +0700, Robert Elz wrote:
> Date:Wed, 17 Aug 2016 12:10:43 +
> From:    "Jonathan A. Kollasch" <jakll...@netbsd.org>
> Message-ID:  <20160817121043.14eeaf...@cvs.netbsd.org>
> 
>   | Module Name:  src
>   | Committed By: jakllsch
>   | Date: Wed Aug 17 12:10:43 UTC 2016
>   | 
>   | Modified Files:
>   |   src/tests/lib/libusbhid: t_usbhid.c
>   | 
>   | Log Message:
>   | t_usbhid/check_hid_get_data has been failing since it existed, mark as 
> such
> 
> Do we know why it is failing?That is, it is fairly obvious that
> it has a signed/unsigned problem (or problems) somewhere given ...
> 
> t_usbhid.c:254: data != -128: == 128
> t_usbhid.c:256: data != -1: == 255
> t_usbhid.c:265: data != -32768: == 32768
> t_usbhid.c:267: data != -1: == 65535
> 
> All of those indicate either sign extension happening when it shouldn't,
> or not happening when it should.   Do we know which?   Or perhaps more
> relevantly, is it the test that is broken, or the code/structs it is testing?
> 
> I took a (fairly quick) look a while ago, only to get totally lost - but
> this one really ought to be fairly simple for someone who understands what
> is what to figure out.
> 
> kre
> 

The test was/is designed to expose the problems in the library.  I've been
sitting on patches that fix this since shortly after I added the test...

Jonathan Kollasch

Re: device-major question

[Jonathan A. Kollasch]

On Wed, May 11, 2016 at 07:53:09AM -0500, Jonathan A. Kollasch wrote:
> 210 is AFS_SYSCALL, used by both Arla and OpenAFS.

But that's a syscall not a device major.

Re: device-major question

[Jonathan A. Kollasch]

210 is AFS_SYSCALL, used by both Arla and OpenAFS.

On Wed, May 11, 2016 at 11:58:54AM +0100, Nick Hudson wrote:
> On 05/11/16 11:52, Kimihiro Nonaka wrote:
> >2016-05-11 15:41 GMT+09:00 Nick Hudson:
> >
> >>I'd be happy (as a tegra owner/user) to move hdmicec to 206. I don't think
> >>hdmicec is use anywhere else yet.
> >char 206 is already used by seeprom.
> >
> >- sys/conf/majors
> >device-major seeprom char 206 seeprom
> >-
> 
> heh, no idea where I got 206 from. I meant 210 - see diff.
> 
> Nick

> Index: sys/conf/majors
> ===
> RCS file: /cvsroot/src/sys/conf/majors,v
> retrieving revision 1.71
> diff -u -p -r1.71 majors
> --- sys/conf/majors   11 May 2016 06:42:06 -  1.71
> +++ sys/conf/majors   11 May 2016 10:58:32 -
> @@ -55,12 +55,10 @@ device-major seeprom   char 206  seep
>  device-major dtracechar 207 dtrace
>  device-major spiflash  char 208 block 208  spiflash
>  device-major lua   char 209lua
> +device-major hdmicec   char 210hdmicec
>  
>  # 210-219 reserved for MI ws devices
>  # 220-239 reserved for MI usb devices
>  # 240-259 reserved for MI "std" devices
>  # 260-269 reserved for MI tty devices
>  # 310-339 reserved for MI storage devices
> -
> -# XXX conflicts with tty
> -device-major hdmicec   char 260hdmicec
> 

Re: Fixing Netbsd Issue:: Convert kernel printf() to aprint_*() or log()

[Jonathan A. Kollasch]

On Sat, Feb 20, 2016 at 01:13:50PM +0500, Usama Mehboob wrote:
> Hi,
> 
> I am a newbie kernel hacker :) and trying to fix this issue first to get
> involved with complex tasks later.
> 
> *My current NetBsd Setup:*
> VirtualBox, HDD7GB, RAM 1GB Netbsd7.0
> 
> I have updated the /usr/src with latest NetBsd-release branch 7.0 using
> cvs. I have successfully rebuilt and install the kernel.
> Now I am modifying the printfs -> aprint_*() in kernel sources (There are
> thousands of them believe me :) ). Link of this project is at
> http://wiki.netbsd.org/projects/project/aprint/ .
> I am using CVS to checkout at latest netbsd7.0 branch. is that ok or should
> I move to current branch ?.
> Secondly, I had been looking at *man aprint_*()*  and there are multiple
> types as:
> 
>  *aprint_normal*() Sends to the console unless AB_QUIET is set.  
> Always
>  sends to the log.
> 
>  *aprint_naive*()  Sends to the console only if AB_QUIET is set.  
> Never
>  sends to the log.
> 
>  *aprint_verbose*()Sends to the console only if AB_VERBOSE is set.
>  Always sends to the log.
> 
>  *aprint_debug*()  Sends to the console and the log only if AB_DEBUG 
> is
>  set.
> 
>  *aprint_error*()  Like *aprint_normal*(), but also keeps track of the
>  number of times called.  This allows a subsystem to
>  report the number of errors that occurred during a
>  quiet or silent initialization phase.
> 
> 
> I need an advice from senior developer how to proceed on it. How to fit
> each of the abve aprints in kernel sources and send a patch to be merged.

These changes will not be suitable for the netbsd-7 branch.  Please work
on -current.

The aprint_*(9) functions are *only* suitable for use within
autoconf(9) code.  The printf(9) or log(9) functions need to be used if
it is not autoconf(9)-related.  There is existing code that abuses
aprint_*(), please fix that too.

Jonathan Kollasch

Re: oemname still "NetBSD60" in sys/arch/i386/stand/bootxx/pbr.S

[Jonathan A. Kollasch]

On Sat, Jan 02, 2016 at 03:34:08PM +0200, Rares Aioanei wrote:
> 
> Hi, 
> 
> Newb question : is there a reason why oemname is still "NetBSD60" in
> the PBR asm code? Also, what is the purpose of it? I googled, but found
> no clue. Searching through the i386 code of 7-RELEASE I found no other
> refs.  Thanks very much. 
> -- 
> Rares Aioanei

The oemname is basically irrelevant.  No good reason to change it unless
perhaps there are significant changes to the bootloader protocol. And as
there are only 8 characters to work with, and NetBSD 10.0 is probably
going to happen within a decade...

Jonathan Kollasch

PCI MSI for re(4)

[Jonathan A. Kollasch]

Hi,

Attached is a patch that should enable PCI MSI for pci(4)-attached re(4)
NICs.  I would like both review of the code, and additional testing.

I've tested it successfully on amd64 -current with a
8100E/8101E/8102E/8102EL chip.

Jonathan Kollasch
Index: src/sys/dev/pci/if_re_pci.c
===
RCS file: /cvsroot/src/sys/dev/pci/if_re_pci.c,v
retrieving revision 1.44
diff -d -u -a -p -r1.44 if_re_pci.c
--- src/sys/dev/pci/if_re_pci.c	3 May 2015 00:04:06 -	1.44
+++ src/sys/dev/pci/if_re_pci.c	13 Nov 2015 04:29:24 -
@@ -75,6 +75,7 @@ struct re_pci_softc {
 	struct rtk_softc sc_rtk;
 
 	void *sc_ih;
+	pci_intr_handle_t *sc_pihp;
 	pci_chipset_tag_t sc_pc;
 };
 
@@ -174,7 +175,6 @@ re_pci_attach(device_t parent, device_t 
 	struct rtk_softc *sc = >sc_rtk;
 	struct pci_attach_args *pa = aux;
 	pci_chipset_tag_t pc = pa->pa_pc;
-	pci_intr_handle_t ih;
 	const char *intrstr = NULL;
 	const struct rtk_type *t;
 	uint32_t hwrev;
@@ -253,12 +253,14 @@ re_pci_attach(device_t parent, device_t 
 
 	/* Hook interrupt last to avoid having to lock softc */
 	/* Allocate interrupt */
-	if (pci_intr_map(pa, )) {
+	if (pci_intr_alloc(pa, >sc_pihp, NULL, 0)) {
 		aprint_error_dev(self, "couldn't map interrupt\n");
 		return;
 	}
-	intrstr = pci_intr_string(pc, ih, intrbuf, sizeof(intrbuf));
-	psc->sc_ih = pci_intr_establish(pc, ih, IPL_NET, re_intr, sc);
+	intrstr = pci_intr_string(pc, psc->sc_pihp[0], intrbuf,
+	sizeof(intrbuf));
+	psc->sc_ih = pci_intr_establish(pc, psc->sc_pihp[0], IPL_NET,
+	re_intr, sc);
 	if (psc->sc_ih == NULL) {
 		aprint_error_dev(self, "couldn't establish interrupt");
 		if (intrstr != NULL)
@@ -305,6 +307,11 @@ re_pci_detach(device_t self, int flags)
 		psc->sc_ih = NULL;
 	}
 
+	if (psc->sc_pihp != NULL) {
+		pci_intr_release(psc->sc_pc, psc->sc_pihp, 1);
+		psc->sc_pihp = NULL;
+	}
+
 	if (sc->rtk_bsize != 0) {
 		bus_space_unmap(sc->rtk_btag, sc->rtk_bhandle, sc->rtk_bsize);
 		sc->rtk_bsize = 0;

Re: PCI extended configuration support

[Jonathan A. Kollasch]

On Tue, Sep 08, 2015 at 12:58:31PM +0900, MAEKAWA Masahide wrote:
> On 2015/09/08 0:59, Jonathan A. Kollasch wrote:
> >   - abuse of the pcitag_t  (I have patches that fix this.)
> 
> Your patches? Where? your local?

Attached.  This has been successfully tested on a machine that uses
Mode 2 configuration access.  Mode 2 is very rare nowadays, and is being
misdetected more often now that firmware is placing IO ports up in the
0xC000ish range.  The Mode 2 tag is incapable of representing a complete
PCI Bus,Device,Function tuple, and thus has no place being a generic
representation of a BDF for use by any configuration access method.
This patch makes the x86 pcitag_t a simple BDF.

> >   - pci_conf_size() is unnecessary
> 
> Why?

Because there's no need to care.  We already support extended
configuration space on some evbmips/arm, and haven't needed it yet.
Just read back 0x and ignore writes if extended configuration is
inaccessible.  No need to bloat the API and kernel.

Jonathan Kollasch
Index: sys/arch/x86/include/pci_machdep_common.h
===
RCS file: /cvsroot/src/sys/arch/x86/include/pci_machdep_common.h,v
retrieving revision 1.21
diff -d -u -a -p -r1.21 pci_machdep_common.h
--- sys/arch/x86/include/pci_machdep_common.h   17 Aug 2015 06:16:02 -  
1.21
+++ sys/arch/x86/include/pci_machdep_common.h   9 Sep 2015 13:45:19 -
@@ -49,26 +49,24 @@
  *
  * Configuration tag; created from a {bus,device,function} triplet by
  * pci_make_tag(), and passed to pci_conf_read() and pci_conf_write().
- * We could instead always pass the {bus,device,function} triplet to
- * the read and write routines, but this would cause extra overhead.
- *
- * Mode 2 is historical and deprecated by the Revision 2.0 specification.
- *
- *
- * Mode 1 tag:
- *  31  24   16 15 11 10  8
- * +---+
- * |1|  0  |  BUS  |   DEV   |FUNC |   0   |
- * +---+
  */
-union x86_pci_tag_u {
-   uint32_t mode1;
-   struct {
-   uint16_t port;
-   uint8_t enable;
-   uint8_t forward;
-   } mode2;
-};
+
+#define X86_PCITAG_FUNC_BITS   ((uint32_t)__BITS( 2, 0))
+#define X86_PCITAG_DEV_BITS((uint32_t)__BITS( 7, 3))
+#define X86_PCITAG_DEVFUNC_BITS((uint32_t)__BITS( 7, 0))
+#define X86_PCITAG_BUS_BITS((uint32_t)__BITS(15, 8))
+#define X86_PCITAG_BDF_BITS((uint32_t)__BITS(15, 0))
+
+#define X86_PCITAG_FUNC(tag)   __SHIFTOUT(tag, X86_PCITAG_FUNC_BITS)
+#define X86_PCITAG_DEV(tag)__SHIFTOUT(tag, X86_PCITAG_DEV_BITS)
+#define X86_PCITAG_DEVFUNC(tag)__SHIFTOUT(tag, X86_PCITAG_DEVFUNC_BITS)
+#define X86_PCITAG_BUS(tag)__SHIFTOUT(tag, X86_PCITAG_BUS_BITS)
+#define X86_PCITAG_BDF(tag)__SHIFTOUT(tag, X86_PCITAG_BDF_BITS)
+
+#define X86_PCITAG_MAKE(b, d, f) \
+((pcitag_t)(__SHIFTIN(f, X86_PCITAG_FUNC_BITS) | \
+   __SHIFTIN(d, X86_PCITAG_DEV_BITS) | \
+   __SHIFTIN(b, X86_PCITAG_BUS_BITS)))
 
 extern struct x86_bus_dma_tag pci_bus_dma_tag;
 #ifdef _LP64
@@ -82,7 +80,7 @@ struct pci_chipset_tag;
  * Types provided to machine-independent PCI code
  */
 typedef struct pci_chipset_tag *pci_chipset_tag_t;
-typedef union x86_pci_tag_u pcitag_t;
+typedef uint32_t pcitag_t;
 
 struct pci_chipset_tag {
pci_chipset_tag_t pc_super;
Index: sys/arch/x86/pci/pci_machdep.c
===
RCS file: /cvsroot/src/sys/arch/x86/pci/pci_machdep.c,v
retrieving revision 1.70
diff -d -u -a -p -r1.70 pci_machdep.c
--- sys/arch/x86/pci/pci_machdep.c  27 Apr 2015 07:03:58 -  1.70
+++ sys/arch/x86/pci/pci_machdep.c  9 Sep 2015 13:45:19 -
@@ -182,10 +182,20 @@ struct pci_bridge_hook_arg {
 #definePCI_MODE2_ENABLE_REG0x0cf8
 #definePCI_MODE2_FORWARD_REG   0x0cfa
 
-#define _tag(b, d, f) \
-   {.mode1 = PCI_MODE1_ENABLE | ((b) << 16) | ((d) << 11) | ((f) << 8)}
+#define MODE2_SELECTOR_ENABLE_BITS ((uint32_t)__BITS( 7, 0))
+#define MODE2_SELECTOR_FORWARD_BITS((uint32_t)__BITS(15, 8))
+
+#define MODE2_SELECTOR_ENABLE(sel) \
+   __SHIFTOUT(sel, MODE2_SELECTOR_ENABLE_BITS)
+#define MODE2_SELECTOR_FORWARD(sel) \
+   __SHIFTOUT(sel, MODE2_SELECTOR_FORWARD_BITS)
+
+#define MODE2_SELECTOR_COMPOSE(enab, forw) \
+   (__SHIFTIN(enab, MODE2_SELECTOR_ENABLE_BITS) | \
+   __SHIFTIN(forw, MODE2_SELECTOR_FORWARD_BITS))
+
 #define _qe(bus, dev, fcn, vend, prod) \
-   {_tag(bus, dev, fcn), PCI_ID_CODE(vend, prod)}
+   {X86_PCITAG_MAKE(bus, dev, fcn), PCI_ID_CODE(vend, prod)}
 const struct {
pcitag_t tag;
pcireg_t id;
@@ -209,7 +219,6 @@ const struct {
/* VIA Technologies VX900 */
_qe(0, 0, 0, PCI_VENDOR_VIATECH, PCI_PRODU

Re: PCI extended configuration support

[Jonathan A. Kollasch]

On Mon, Sep 07, 2015 at 06:14:59PM +0900, Masanobu SAITOH wrote:
>  Hi, all.
> 
>  nonaka@ wrote code to access PCI extended configuration area.
> Currently, the diff supoorts only on x86.
> 
>   
> http://ftp.netbsd.org/pub/NetBSD/misc/nonaka/tmp/nbsd-pci-extconf-support.diff
> 
> Is it OK to commit?

No.  There are multiple issues.

 - abuse of the pcitag_t  (I have patches that fix this.)

 - pci_conf_size() is unnecessary

 - too much ACPI dependence, there's nothing that says you have to use
   ACPI MCFG to get this information

 - possibility of too much KVA usage on 32-bit kernels

 - on-demand bus mapping may happen in inappropriate (interrupt) context

 - x86 bus_space_read/write functions do not use the %eax/ax/al register,
 as required by the AMD documentation for Family 10h's (and others) extended
 configuration space access.

Jonathan Kollasch

serial console and genfb

[Jonathan A. Kollasch]

Hi,

Attached is a patch to genfb to make it possible to have serial console
but still have genfb enabled.  I'm slightly worried this will break
genfb console on non-x86 machines however, so I'd like some testing.
At the very least a list of machines that need testing would be useful.

Jonathan Kollasch
Index: sys/dev/wsfb/genfb.c
===
RCS file: /cvsroot/src/sys/dev/wsfb/genfb.c,v
retrieving revision 1.51
diff -d -u -a -p -r1.51 genfb.c
--- sys/dev/wsfb/genfb.c	9 Oct 2013 17:20:54 -	1.51
+++ sys/dev/wsfb/genfb.c	30 Dec 2013 14:12:59 -
@@ -99,6 +99,7 @@ genfb_init(struct genfb_softc *sc)
 	printf(prop_dictionary_externalize(dict));
 #endif
 	prop_dictionary_get_bool(dict, is_console, console);
+	console = console  (genfb_is_console() != 0);
 
 	if (!prop_dictionary_get_uint32(dict, width, sc-sc_width)) {
 		GPRINTF(no width property\n);
@@ -205,6 +206,7 @@ genfb_attach(struct genfb_softc *sc, str
 
 	dict = device_properties(sc-sc_dev);
 	prop_dictionary_get_bool(dict, is_console, console);
+	console = console  (genfb_is_console() != 0);
 
 	if (prop_dictionary_get_uint16(dict, cursor-row, crow) == false)
 		crow = 0;

Re: serial console and genfb

[Jonathan A. Kollasch]

On Wed, Jan 15, 2014 at 11:08:41AM -0600, Jonathan A. Kollasch wrote:
 Hi,
 
 Attached is a patch to genfb to make it possible to have serial console
 but still have genfb enabled.  I'm slightly worried this will break
 genfb console on non-x86 machines however, so I'd like some testing.
 At the very least a list of machines that need testing would be useful.
 
   Jonathan Kollasch

Also relevant would be the patch in kern/46376, which I have not tested.

Re: zero-length symlinks

[Jonathan A. Kollasch]

http://lwn.net/Articles/551224/

http://austingroupbugs.net/view.php?id=649

On Fri, Nov 01, 2013 at 04:47:35PM +, David Holland wrote:
 rmind@ points out that it's possible to create zero-length symlinks.
 As zero-length symlinks aren't sensible, this should probably be
 prohibited. Does anyone see any reason they shouldn't be?
 
 (rmind wants me to post this message for some reason)
 
 -- 
 David A. Holland
 dholl...@netbsd.org

Re: siisata tries to attach incompatible devices?

[Jonathan A. Kollasch]

I fixed this recently.

On Mon, Jun 10, 2013 at 11:13:22PM -0400, Thor Lancelot Simon wrote:
 On Mon, Jun 10, 2013 at 11:00:05PM -0400, Thor Lancelot Simon wrote:
  I powered back up a machine that very, very long ago was build.netbsd.org,
  to run some tests.  It worked fine with its old (5.99) kernel, but with a
  kernel built from yesterday's sources, its disks vanished, evidently 
  because:
  
  siisata0 at pci1 dev 5 function 0: vendor 0x1095 product 0x3114 (rev. 0x02)
  siisata0: couldn't map global registers
 
 It looks like the cause of this is that siisata is trying to use the
 SiI3114 in this system, with which it is (as far as I know) not compatible.
 
 With no siisata in the kernel config file, things are much better:
 
 satalink0 at pci1 dev 5 function 0: Silicon Image SATALink 3114 (rev. 0x02)
 satalink0: 33MHz PCI bus
 satalink0: bus-master DMA support present
 satalink0: using ioapic0 pin 19 for native-PCI interrupt
 atabus0 at satalink0 channel 0
 atabus1 at satalink0 channel 1
 atabus2 at satalink0 channel 2
 atabus3 at satalink0 channel 3
 satalink0: port 0: device present, speed: 1.5Gb/s
 satalink0: port 1: device present, speed: 1.5Gb/s
 wd0(satalink0:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
 wd1(satalink0:1:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
 

Re: Thinking about NCQ support for NetBSD

[Jonathan A. Kollasch]

On Tue, May 21, 2013 at 11:14:03PM -0700, Brian Buhrow wrote:
   hello.  Recently I've been working on some fixes for the mpt(4)
 driver.  In the process of getting those fixes working, I began thinking
 about how hard it would be to get NCQ tag queueing working for NetBSD.  In
 the process of getting my head around what is involved, I find I have
 questions.  If someone wants to share what they know here or privately,
 I'd be interested in reading.
 
 1.  I read a document that discussed ahcisata and its advantages over
 traditional IDE mode.  One of the advantages it touted was that ahcisata
 would support NCQ tag queueing.  Is it a requirement in order for NCQ
 tag queueing to work that the interface card support it as well?  For
 example, the viaide(4) driver supports SATA controllers, but says nothing
 about NCQ support or the potential for it.

Yeah, you need something with more than just wdc(4)/pciide(4)-style
registers.  ahcisata(4), siisata(4), and mvsata(4) would be capable of
NCQ.

 2.  Does anyone have any preliminary patches for NCQ support that the never
 got into the system?

The first issue is the ata(4) layer, which doesn't currently support
multiple outstanding commands per drive.  What little work I did on it
I probably swept away, as nothing useful came of it last I tried.

Jonathan Kollasch

Re: Copyright notice

[Jonathan A. Kollasch]

On Sat, Sep 29, 2012 at 07:32:55PM -0500, Frank Zerangue wrote:
 Is there any reason why the current copyright notice:
 
 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
 2006, 2007, 2008, 2009, 2010, 2011, 2012
 The NetBSD Foundation, Inc.  All rights reserved.
 
 could not be changed to:
 
 Copyright (c) 1996-2012
 The NetBSD Foundation, Inc.  All rights reserved.

Yes, supposedly some lawyers say explicitly listing each year is safer.

Jonathan Kollasch

Re: USB 3.0 ?

[Jonathan A. Kollasch]

On Thu, Mar 29, 2012 at 06:26:07PM -0700, Paul Goyette wrote:
 Just curious - is anyone out there working on a USB 3.0 driver for
 NetBSD?

Not working on it yet, but I'm planing on trying someday soon.

Jonathan Kollasch

Re: pci_mapreg_map() with disabled device

[Jonathan A. Kollasch]

On Thu, Dec 01, 2011 at 10:12:44AM +0100, Frank Wille wrote:
 Is there a reason why pci_mapreg_map() calls bus_space_map() for a memory
 or i/o space, even when all spaces have been disabled on the device?

Not necessarily, on x86 it's not uncommon for the I/O or Memory enable
bit to be set wrong by the firmware, even sometimes when the firmware
has allocated resources to the BARs.

 Wouldn't it be better to check whether a space is enabled in the device,
 before trying to map it?

You mean we don't anymore?  I thought that didn't change.

Jonathan Kollasch

Re: USB contigmalloc()

[Jonathan A. Kollasch]

On Thu, Dec 01, 2011 at 05:33:27PM +0100, Thomas Klausner wrote:
 Matthew Dillon implemented a solution for USB/graphics cards problem
 stemming from the fact that some time after the boot, they can't
 acquire enough contiguous memory.
 
 http://thread.gmane.org/gmane.os.dragonfly-bsd.kernel/14431
 
 Anyone interested in porting it or implementing something similar? :)
  Thomas

We have it in the USB stack already.  Though some cardbus and pci drivers
still could use something similar.

It's really Not Good Enough.  These drivers really need to grow proper
scatter/gather support.

Jonathan Kollasch

proposed additions to sys/conf/std

[Jonathan A. Kollasch]

I propose adding

pseudo-device drvctl

and/or

options BUFQ_PRIOCSCAN

to src/sys/conf/std.

The reasons I even bring this up:
 - Many kernels are missing drvctl and thus do not support disk wedges
   (this is arguably due to a flaw in the design of disk wedges, but
   that's a another bikeshed).
 - BUFQ_PRIOCSCAN is superior to BUFQ_DISKSORT, and in fact
   BUFQ_DISKSORT is actually inferior to BUFQ_FCFS in terms of
   interactive disk I/O responsiveness.  There are many kernels that
   default to BUFQ_DISKSORT due to not explicitly adding BUFQ_PRIOCSCAN.

The ominous 
# it's commonly used is NOT a good reason to enable options here.
 line has me a bit apprehensive.  However, pseudo-device cpuctl is there
already.  There are some options that are there for historical reasons,
so this is sort of a slippery slope.  Do we need a new config file for
standard-but-optional-options?

Jonathan Kollasch

Re: UDL driver X11 support

[Jonathan A. Kollasch]

On Fri, Jul 22, 2011 at 03:04:42PM +0200, Piotr Adamus wrote:
 Hello all,
 
 could I obtain information if udl driver support X11 for Displaylink
 devices 1x0/1x5? I am planning to by perhaps UGA-2K-A and I would like
 to be sure if it works under X11.

Should work via xf86-video-wsfb.

Re: ata(4) and NCQ

[Jonathan A. Kollasch]

On Tue, Apr 26, 2011 at 09:05:14PM +0200, Manuel Bouyer wrote:
 On Tue, Apr 26, 2011 at 11:52:00AM -0700, Garrett Cooper wrote:
  [...]
  I've been watching this discussion and one hing i was curious about was -- 
  is it widely known that there are a handful of ATA - SCSI specs that have 
  been released by IEEE over the past decade. I figured someone was aware of 
  this on the list, but was kind of puzzled by the replies about FreeBSD, 
  Linux and windows behavior when in fact the behavior is allowed and 
  standard.
 
 Can you gives pointers about this ? AFAIK ata is still something
 different from SAM or SPC.

T10 has a SCSI / ATA Translation (SAT) standard.
It covers how to translate/encapsulate ATA commands for SCSI.
It's often implemented in many newer USB Mass Storage Class SATA bridges.

Jonathan Kollasch

Re: ffs fsync patch - block devices and wapbl

[Jonathan A. Kollasch]

On Tue, Apr 19, 2011 at 11:38:00AM +0200, Juergen Hannken-Illjes wrote:
 Block devices have two different properties.  First they are device nodes
 having access times etc. and reside on a file system.  Second they may have
 a file system mounted on them.  With WAPBL it is important to handle these
 properties separately.
 
 Relevant PRs are 41189, 41192, 41977, 42149, 42551, 44377 and 44746 at least.
 
 The attached diff should solve these problems by:
 
 - Replace the ugly sync loop in ffs_full_fsync() with vflushbuf().  This
   loop is a left-over of softdeps and not needed anymore.
 
 - Merge ffs_vfs_fsync() with ffs_full_fsync() so we have only on operation
   whether the request comes from ffs or from other file system via 
 VFS_FSYNC().
 
 - Take care which mount to test for WAPBL -- v_mount to update the times and
   wapbl_vptomp() to update the dirty blocks.  Never update times when called
   by VFS_FSYNC().
 
 
 Comments or objections?

You mean we don't have to get a devfs to fix this rather serious problem? :-)

Jonathan Kollasch

ata(4) and NCQ

[Jonathan A. Kollasch]

Hi,

I'm (again) considering adding NCQ support to the ATA subsystem.

I've gained some experience with out of order transaction completion
in a virtio block driver I've worked on, however that was rather
simplistic compared to shoehorning it into existing and somewhat
dissimilar code.

I am rather bewildered by the prospects of redesigning the whole ATA
subsystem.  Basically, I am looking for ideas on a proper design of
NCQ support, so any pointers on where to start would be appreciated.

Jonathan Kollasch

expansion into 64-bit dev_t space

[Jonathan A. Kollasch]

Hi,

Now that dev_t is 64-bits, do we have plans for expanding
device majors and minors beyond their current limits?

Jonathan Kollasch

Re: Status and future of 3rd party ABI compatibility layer

[Jonathan A. Kollasch]

On Fri, Feb 25, 2011 at 10:35:12PM +0100, Joerg Sonnenberger wrote:
 FreeBSD (does it even handle FreeBSD 4?)
 
 
Five or so years ago this could run the distributed.net
proxy.  I don't use this application anymore.

 OSF1
 

As of a few years ago, it could run the distributed.net client.
This was almost preferable to the native NetBSD/alpha client due
to the DEC/Compaq compiler being so much better than GCC.

Haven't run this application in quite some time.

 Ultrix

I've used this only to say I ran Ultrix binaries on a wireless router.
Old AFS-related Ultrix binaries are available in many AFS cells, at
least they were a few years ago.

Jonathan Kollasch

options USB_FRAG_DMA_WORKAROUND

[Jonathan A. Kollasch]

Hi,

I noticed the new USB_FRAG_DMA_WORKAROUND option.
I had previously seen this bug on amd64 during heavy umass(4) use on ehci(4).
Maybe we should enable this everywhere by default?

Jonathan Kollasch

P.S.
... That or we need to stop implementing temporary fixes.

Re: Realtek 8110SC

[Jonathan A. Kollasch]

On Wed, Oct 06, 2010 at 06:17:35PM +0200, Matthias Kretschmer wrote:
 Hello,
 
 according to re(4) the re? driver supports the 8169 realtek family of
 network adapters including the 8110S network chip.  I'm wondering if the
 8110SC is different from 8110S?  Is the 8110SC supported by NetBSD?

I'm not sure if or how they may be different.  However I expect a re(4)
of that vintage should be supported already.

Jonathan Kollasch

pciide detachment

[Jonathan A. Kollasch]

Hi,

The attached patch lays the groundwork for detachment of
pciide(4)-family drivers.  Thoughts?

Jonathan Kollasch
Index: sys/dev/ic/wdcvar.h
===
RCS file: /local/netbsd/anoncvs/src/sys/dev/ic/wdcvar.h,v
retrieving revision 1.90
diff -u -a -p -r1.90 wdcvar.h
--- sys/dev/ic/wdcvar.h 1 Dec 2009 01:06:31 -   1.90
+++ sys/dev/ic/wdcvar.h 10 Sep 2010 20:25:15 -
@@ -47,9 +47,11 @@ struct wdc_regs {
/* Our registers */
bus_space_tag_t   cmd_iot;
bus_space_handle_tcmd_baseioh;
+   bus_size_tcmd_ios;
bus_space_handle_tcmd_iohs[WDC_NREG+WDC_NSHADOWREG];
bus_space_tag_t   ctl_iot;
bus_space_handle_tctl_ioh;
+   bus_size_tctl_ios;
 
/* data32{iot,ioh} are only used for 32-bit data xfers */
bus_space_tag_t   data32iot;
Index: sys/dev/pci/acardide.c
===
RCS file: /local/netbsd/anoncvs/src/sys/dev/pci/acardide.c,v
retrieving revision 1.23
diff -u -a -p -r1.23 acardide.c
--- sys/dev/pci/acardide.c  14 May 2008 13:29:29 -  1.23
+++ sys/dev/pci/acardide.c  10 Sep 2010 20:25:15 -
@@ -115,7 +115,6 @@ acard_chip_map(struct pciide_softc *sc, 
struct pciide_channel *cp;
int i;
pcireg_t interface;
-   bus_size_t cmdsize, ctlsize;
 
if (pciide_chipen(sc, pa) == 0)
return;
@@ -167,8 +166,7 @@ acard_chip_map(struct pciide_softc *sc, 
cp = sc-pciide_channels[i];
if (pciide_chansetup(sc, i, interface) == 0)
continue;
-   pciide_mapchan(pa, cp, interface, cmdsize, ctlsize,
-   pciide_pci_intr);
+   pciide_mapchan(pa, cp, interface, pciide_pci_intr);
}
if (!ACARD_IS_850(sc)) {
u_int32_t reg;
Index: sys/dev/pci/aceride.c
===
RCS file: /local/netbsd/anoncvs/src/sys/dev/pci/aceride.c,v
retrieving revision 1.27
diff -u -a -p -r1.27 aceride.c
--- sys/dev/pci/aceride.c   8 May 2010 19:49:02 -   1.27
+++ sys/dev/pci/aceride.c   10 Sep 2010 20:25:15 -
@@ -113,7 +113,6 @@ acer_chip_map(struct pciide_softc *sc, s
struct pciide_channel *cp;
int channel;
pcireg_t cr, interface;
-   bus_size_t cmdsize, ctlsize;
pcireg_t rev = PCI_REVISION(pa-pa_class);
struct aceride_softc *acer_sc = (struct aceride_softc *)sc;
 
@@ -216,7 +215,7 @@ acer_chip_map(struct pciide_softc *sc, s
continue;
}
/* newer controllers seems to lack the ACER_CHIDS. Sigh */
-   pciide_mapchan(pa, cp, interface, cmdsize, ctlsize,
+   pciide_mapchan(pa, cp, interface,
 (rev = 0xC2) ? pciide_pci_intr : acer_pci_intr);
}
 }
Index: sys/dev/pci/artsata.c
===
RCS file: /local/netbsd/anoncvs/src/sys/dev/pci/artsata.c,v
retrieving revision 1.19
diff -u -a -p -r1.19 artsata.c
--- sys/dev/pci/artsata.c   26 Nov 2009 15:17:08 -  1.19
+++ sys/dev/pci/artsata.c   10 Sep 2010 20:25:15 -
@@ -119,7 +119,6 @@ artsata_attach(device_t parent, device_t
 
 static void
 artisea_mapregs(struct pci_attach_args *pa, struct pciide_channel *cp,
-bus_size_t *cmdsizep, bus_size_t *ctlsizep,
 int (*pci_intr)(void *))
 {
struct pciide_softc *sc = CHAN_TO_PCIIDE(cp-ata_channel);
@@ -320,7 +319,6 @@ static void
 artisea_chip_map_dpa(struct pciide_softc *sc, struct pci_attach_args *pa)
 {
struct pciide_channel *cp;
-   bus_size_t cmdsize, ctlsize;
pcireg_t interface;
int channel;
 
@@ -330,7 +328,7 @@ artisea_chip_map_dpa(struct pciide_softc
interface wired in DPA mode\n);
 
if (pci_mapreg_map(pa, ARTISEA_PCI_DPA_BASE, PCI_MAPREG_MEM_TYPE_64BIT,
-   0, sc-sc_ba5_st, sc-sc_ba5_sh, NULL, NULL) != 0)
+   0, sc-sc_ba5_st, sc-sc_ba5_sh, NULL, sc-sc_ba5_ss) != 0)
return;
 
artisea_mapreg_dma(sc, pa);
@@ -380,7 +378,7 @@ artisea_chip_map_dpa(struct pciide_softc
if (artisea_chansetup(sc, channel, interface) == 0)
continue;
/* XXX We can probably do interrupts more efficiently.  */
-   artisea_mapregs(pa, cp, cmdsize, ctlsize, pciide_pci_intr);
+   artisea_mapregs(pa, cp, pciide_pci_intr);
}
 }
 
@@ -388,7 +386,6 @@ static void
 artisea_chip_map(struct pciide_softc *sc, struct pci_attach_args *pa)
 {
struct pciide_channel *cp;
-   bus_size_t cmdsize, ctlsize;
pcireg_t interface;
int channel;
 
@@ -438,7 +435,6 @@ artisea_chip_map(struct pciide_softc *sc
cp = sc-pciide_channels[channel

Re: Files missing in /usr/include?

[Jonathan A. Kollasch]

On Wed, May 26, 2010 at 12:10:44PM -0500, Matt Smith wrote:
 Hello,
 
 I'm working on porting the OpenAFS client over to NetBSD 5.0.2. In
 trying to compile the LKM for it, the files cpu.h and intr.h in
 /usr/include/x86/ are included. These headers include additional
 headers. The problem, however, is that a couple of the headers they
 try to include are not in /usr/include/x86. For example:
 
 /usr/include/x86/cpu.h includes /x86/via_padlock.h
 /usr/include/x86/intr.h includes /machine/pic.h
 
 Instead, these included headers are located in the src tree
 (/usr/src/sys/arch/x86/include). They can be linked in to satisfy the
 dependency, but intr.h errors out due to missing some expected
 characters.
 
 Does anyone know why these files would be missing from /usr/include?
 Additionally, why would non-compilable files be placed for use in
 /usr/include?

I don't think we have yet bothered to support building 3rd-party kernel
modules without also having various parts of the src tree around.

At least this was the case with Arla.  I believe OpenAFS needs src
trees for OpenBSD and FreeBSD cache manager builds too.

I could see it being hard to integrate, but using bsd.kmodule.mk
may make some things easier.

Jonathan Kollasch

Re: Files missing in /usr/include?

[Jonathan A. Kollasch]

On Wed, May 26, 2010 at 01:35:27PM -0500, Matt Smith wrote:
 Fair enough.
 
 What would be the best way to deal with the existing error with intr.h
 then? It persists in the src tree as well.
 
 /usr/include/x86/intr.h:131: error: expected '=', ',', ';', 'asm' or
 '__attribute__' before 'ipl_cookie_t'
 /usr/include/x86/intr.h:138: error: expected '=', ',', ';', 'asm' or

An excerpt from that file:

126 typedef uint8_t ipl_t;
127 typedef struct {
128 ipl_t _ipl;
129 } ipl_cookie_t;
130 
131 static inline ipl_cookie_t
132 makeiplcookie(ipl_t ipl)
133 {

In short, alone, this code is perfectly valid C99.
Is inline really what you think it is?

From what I know of the OpenAFS codebase, anything could
actually be a macro in disguise.

Jonathan Kollasch

Re: uticom(4)

[Jonathan A. Kollasch]

On Sat, Feb 06, 2010 at 11:10:00PM +0200, Yorick Hardy wrote:
  There's not much point in putting the firmware in the kernel
  by default until we have console-on-ucom(4) support.
 
 I did not figure out how to delay firmware load if the device
 is already connected on boot, then the filesystem is not yet
 available for firmload(9). Can anyone point me in the right
 direction?

Oh, that is an issue.  And as the Catweasel thread shows,
this firmware is trivially small.  Maybe this issue with
firmload can be fixed in the future.

Jonathan Kollasch

Re: uticom(4)

[Jonathan A. Kollasch]

On Fri, Feb 05, 2010 at 12:13:01AM +0200, Yorick Hardy wrote:
 I think uticom(4) is now ready for comment.
 
 The source for uticom(4) is available at
 
  ftp://ftp.NetBSD.org/pub/NetBSD/misc/yhardy/uticom20100204.tar.bz2
 
 (extract in src/) and the additional changes to src at
 
  ftp://ftp.NetBSD.org/pub/NetBSD/misc/yhardy/uticom.diff
 
 This is not a port of OpenBSD uticom(4), nor of the Linux driver.
 This driver uses different firmware from the OpenBSD and Linux drivers.

*NICE*, our own firmware, and sufficent docs (and compilers) to modify
it are public it looks like.

Where do i get one of these devices?
(Says the person with 5+ uplcom(4)s he doesn't use.)

 
 The driver uses a header file (src/sys/dev/microcode/uticom/tusb3410fw.h)
 for the firmware.  The firmware is about 5KB. firmload(9) will be used if
 UTICOM_TUSB3410FW_H is undefined in src/sys/dev/usb/uticom.h (line 68).

There's not much point in putting the firmware in the kernel
by default until we have console-on-ucom(4) support.

 I encountered a problem with uhci_open (probably also ehci). uhci_open
 sets nexttoggle to zero (src/sys/dev/usb/uhci.c line 3186) on every
 pipe open. However, the device endpoint toggle will not reset to zero.
 Since ucomopen seems to open the pipes for the bulk endpoints, this means
 the device bulk endpoint toggle may differ from the pipe's nexttoggle
 on every open.
 
 I worked around the problem by clearing the halt feature on the bulk
 endpoints which resets the data toggle to zero, but this should not
 be necessary.

Oh, that must be the problem I was having with my AVRISP mkII.
It should be fixed where appropriate (in the host
controller driver).

Jonathan Kollasch