ppc fails to attach to puc on 9.1-STABLE, 7.4-STABLE works

Post by Andre Albsmeier
[Retrying here, maybe anyone can help...}
I want my printer port back on 9.1 ;-(
vendor = 'NetMos Technology'
device = 'PCI 9835 Multi-I/O Controller'
class = simple comms
It attached and worked under 7.4-STABLE (as long as I disabled
puc0: <NetMos NM9835 Dual UART and 1284 Printer port> port

0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07

Post by Andre Albsmeier
,0xdc00-0xdc07,0xdb00-0xdb07,0xda00-0xda0f irq 17 at device 1.0 on pci4
puc0: [FILTER]
uart0: <Non-standard ns8250 class UART with FIFOs> on puc0
uart0: [FILTER]
uart1: <Non-standard ns8250 class UART with FIFOs> on puc0
uart1: [FILTER]
ppc0: <Parallel port> on puc0
ppc0: Generic chipset (ECP/EPP/PS2/NIBBLE) in ECP+EPP mode (EPP 1.9)
ppbus0: <Parallel port bus> on ppc0
lpt0: <Printer> on ppbus0
lpt0: Polled port
Under 9.1 the card does not attach the ppc anymore. The hint entries
hint.ppc.0.at=puc0
hint.ppc.0.irq=""
hint.ppc.0.flags=0x2F
get ignored and so it probes as ppc1 (failing due to the interrupt
puc0: <NetMos NM9835 Dual UART and 1284 Printer port> port

0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07

Post by Andre Albsmeier
,0xdc00-0xdc07,0xdb00-0xdb07,0xda00-0xda0f irq 17 at device 1.0 on pci4
uart2: <Non-standard ns8250 class UART with FIFOs> at port 1 on puc0
uart3: <16550 or compatible> at port 2 on puc0
ppc1: <Parallel port> at port 3 on puc0
ppc1: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
ppc1: failed to register interrupt handler: 6
device_attach: ppc1 attach returned 6
Any ideas? How do I construct the hint entries under 9.1 so that
1. it does not want to use the interrupt (which made it attach under 7.4)
2. it takes the flags 0x2F as it did before.
I have also never understood if ppc itself needs to attach to
the irq as well (I thought this all would be handled by puc).

Well, ppc wants to use puc's interrupt, and it should be finding puc's
interrupt. Ah, I think I found the bug. Try this patch to sys/dev/puc/puc.c:

Index: puc.c
===================================================================
--- puc.c (revision 245225)
+++ puc.c (working copy)
@@ -622,7 +628,7 @@ puc_bus_setup_intr(device_t dev, device_t child, s
if (cookiep == NULL || res != port->p_ires)
return (EINVAL);
/* We demand that serdev devices use filter_only interrupts. */
- if (ihand != NULL)
+ if (port->p_type == PUC_TYPE_SERIAL && ihand != NULL)
return (ENXIO);
if (rman_get_device(port->p_ires) != originator)
return (ENXIO);

This should let your ppc device re-use IRQ 17 from your puc device.

--
John Baldwin

Andre Albsmeier

2013-01-15 07:13:30 UTC

Post by Andre Albsmeier
[Retrying here, maybe anyone can help...}
I want my printer port back on 9.1 ;-(

rev=0x01 hdr=0x00

Post by Andre Albsmeier
vendor = 'NetMos Technology'
device = 'PCI 9835 Multi-I/O Controller'
class = simple comms
It attached and worked under 7.4-STABLE (as long as I disabled
puc0: <NetMos NM9835 Dual UART and 1284 Printer port> port

0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07

Well, ppc wants to use puc's interrupt, and it should be finding puc's
Index: puc.c
===================================================================
--- puc.c (revision 245225)
+++ puc.c (working copy)
@@ -622,7 +628,7 @@ puc_bus_setup_intr(device_t dev, device_t child, s
if (cookiep == NULL || res != port->p_ires)
return (EINVAL);
/* We demand that serdev devices use filter_only interrupts. */
- if (ihand != NULL)
+ if (port->p_type == PUC_TYPE_SERIAL && ihand != NULL)
return (ENXIO);
if (rman_get_device(port->p_ires) != originator)
return (ENXIO);
This should let your ppc device re-use IRQ 17 from your puc device.

John, thanks a lot for looking at this. I have stumbled
over this line as well last weekend but wasn't sure if I
can go this way. I will try your patch and report later...

Thanks,

-Andre

Post by Andre Albsmeier
--
John Baldwin

--
GNU is Not Unix / Linux Is Not UniX

Andre Albsmeier

2013-01-15 15:44:47 UTC

Post by Andre Albsmeier
[Retrying here, maybe anyone can help...}
I want my printer port back on 9.1 ;-(

rev=0x01 hdr=0x00

0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07

True, this really makes ppc use puc's interrupt: I removed
my local hack (more on this later) which brought the lost
hint.ppc.0.flags functionality back and applied the patch.
Now ppc attaches to puc without errors and which also is
confirmed by lpt:

lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port

(And, yes, I even printed a page with it ;-))

I have no idea if this has ever worked before -- in FreeBSD-7 I
also had to use the "do not use interrupt"-flag 0x20 in loader.conf
or ppc wouldn't have attached...

Which brings me back to the initial problem: Hints like

hint.ppc.0.at=puc0
hint.ppc.0.irq=""
hint.ppc.0.flags=0x2F

seems to be ignored in 9.1. While the interrupt thing seems
to be fixed now, one possibly still wants to used the other
flags. I have helped myself with this (ugly) patch to ppc

--- ppc.c.ORI 2013-01-12 18:07:44.000000000 +0100
+++ ppc.c 2013-01-12 18:07:24.000000000 +0100
@@ -1729,6 +1729,11 @@
ppc->ppc_base = rman_get_start(ppc->res_ioport);

ppc->ppc_flags = device_get_flags(dev);
+ if( ppc->ppc_flags == 0 ) {
+ int tmp;
+ if( resource_int_value( "ppc" , device_get_unit( dev ), "flags", &tmp) == 0 )
+ ppc->ppc_flags = tmp;
+ }

if (!(ppc->ppc_flags & 0x20)) {
ppc->res_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ,

in order to get at least the flags applied as it was the case
before in FreeBSD-7. Unfortuantely, I have no idea how to fix
that properly ;-(...

Thanks,

-Andre

Post by Andre Albsmeier
--
John Baldwin

--
Linux is no OS. It's a core dump which boots by accident.

John Baldwin

2013-01-15 20:28:47 UTC

Post by Andre Albsmeier
[Retrying here, maybe anyone can help...}
I want my printer port back on 9.1 ;-(

rev=0x01 hdr=0x00

0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07

Well, ppc wants to use puc's interrupt, and it should be finding puc's
interrupt. Ah, I think I found the bug. Try this patch to
Index: puc.c
===================================================================
--- puc.c (revision 245225)
+++ puc.c (working copy)
@@ -622,7 +628,7 @@ puc_bus_setup_intr(device_t dev, device_t child, s
if (cookiep == NULL || res != port->p_ires)
return (EINVAL);
/* We demand that serdev devices use filter_only interrupts. */
- if (ihand != NULL)
+ if (port->p_type == PUC_TYPE_SERIAL && ihand != NULL)
return (ENXIO);
if (rman_get_device(port->p_ires) != originator)
return (ENXIO);
This should let your ppc device re-use IRQ 17 from your puc device.

Great! I've committed that fix to HEAD and will MFC.

Post by Andre Albsmeier
I have no idea if this has ever worked before -- in FreeBSD-7 I
also had to use the "do not use interrupt"-flag 0x20 in loader.conf
or ppc wouldn't have attached...
Which brings me back to the initial problem: Hints like
hint.ppc.0.at=puc0
hint.ppc.0.irq=""
hint.ppc.0.flags=0x2F
seems to be ignored in 9.1. While the interrupt thing seems
to be fixed now, one possibly still wants to used the other
flags. I have helped myself with this (ugly) patch to ppc
--- ppc.c.ORI 2013-01-12 18:07:44.000000000 +0100
+++ ppc.c 2013-01-12 18:07:24.000000000 +0100
@@ -1729,6 +1729,11 @@
ppc->ppc_base = rman_get_start(ppc->res_ioport);
ppc->ppc_flags = device_get_flags(dev);
+ if( ppc->ppc_flags == 0 ) {
+ int tmp;
+ if( resource_int_value( "ppc" , device_get_unit( dev ), "flags", &tmp) == 0 )
+ ppc->ppc_flags = tmp;
+ }
if (!(ppc->ppc_flags & 0x20)) {
ppc->res_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ,
in order to get at least the flags applied as it was the case
before in FreeBSD-7. Unfortuantely, I have no idea how to fix
that properly ;-(...

This should not be needed for "flags". Look for 'devflags' in
sys/kern/subr_bus.c. The kernel always reads the current 'flags' hint during
device probe and stores them in dev->devflags and leaves them there after a
successful probe (so they should be seen by attach). Specifically, note:

/* Set the winning driver, devclass, and flags. */
if (!child->devclass) {
result = device_set_devclass(child, best->driver->name);
if (result != 0)
return (result);
}
result = device_set_driver(child, best->driver);
if (result != 0)
return (result);
resource_int_value(best->driver->name, child->unit,
"flags", &child->devflags);

This 'devflags' variable is what device_get_flags() returns. You should be
able to just place 'hint.ppc.0.flags=0x2f' in /boot/device.hints (note, no
other hints meaning no "at", etc.) Perhaps try adding some debug printfs
in subr_bus.c to make sure this is fetching the flags you expect?

--
John Baldwin

Andre Albsmeier

2013-01-16 16:34:02 UTC

Post by Andre Albsmeier
[Retrying here, maybe anyone can help...}
I want my printer port back on 9.1 ;-(

rev=0x01 hdr=0x00

0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07

7.4)

Post by Andre Albsmeier
2. it takes the flags 0x2F as it did before.
I have also never understood if ppc itself needs to attach to
the irq as well (I thought this all would be handled by puc).

Great! I've committed that fix to HEAD and will MFC.

Thanks!

== 0 )

Post by Andre Albsmeier
+ ppc->ppc_flags = tmp;
+ }
if (!(ppc->ppc_flags & 0x20)) {
ppc->res_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ,
in order to get at least the flags applied as it was the case
before in FreeBSD-7. Unfortuantely, I have no idea how to fix
that properly ;-(...

This should not be needed for "flags". Look for 'devflags' in
sys/kern/subr_bus.c. The kernel always reads the current 'flags' hint during
device probe and stores them in dev->devflags and leaves them there after a
/* Set the winning driver, devclass, and flags. */
if (!child->devclass) {
result = device_set_devclass(child, best->driver->name);
if (result != 0)
return (result);
}
result = device_set_driver(child, best->driver);
if (result != 0)
return (result);
resource_int_value(best->driver->name, child->unit,
"flags", &child->devflags);
This 'devflags' variable is what device_get_flags() returns. You should be
able to just place 'hint.ppc.0.flags=0x2f' in /boot/device.hints (note, no
other hints meaning no "at", etc.)

Hmm, you are right. It now works even without my hackish patch.

Apparently, the "flags" hints (indicating that no interrupt
should be used) were not observed when I tried to use them to
work around the bug (which you fixed now). But after a
successful attach they are used and this is what's really
important.

Thanks for you help,

-Andre

Bruce Evans

2013-01-17 03:10:52 UTC

Post by Andre Albsmeier
* ...

== 0 )

So the flags interface is unusable before some driver "wins".

Post by Andre Albsmeier
if (!child->devclass) {
result = device_set_devclass(child, best->driver->name);
if (result != 0)
return (result);
}
result = device_set_driver(child, best->driver);
if (result != 0)
return (result);
resource_int_value(best->driver->name, child->unit,
"flags", &child->devflags);
This 'devflags' variable is what device_get_flags() returns. You should be
able to just place 'hint.ppc.0.flags=0x2f' in /boot/device.hints (note, no
other hints meaning no "at", etc.)

Hmm, you are right. It now works even without my hackish patch.
Apparently, the "flags" hints (indicating that no interrupt
should be used) were not observed when I tried to use them to
work around the bug (which you fixed now). But after a
successful attach they are used and this is what's really
important.

This leaves the layering/ordering bug that device flags are unusable
at probe time. But ppc.c only initializes them in ppc_probe(). It
assigns them to ppc->ppc_flags and apparently depends on the whole
of *ppc living across probe/attach. But it mainly uses the ppc_flags
part for the probe, where it is unusable.

resource_int_value() is still used a in a few drivers to find the flags.
Most of the uses are for low level console drivers, where the device
flags are unavailable because new-bus is unavailable. The only new-bus-
level probe that uses this method seems to be nvram2env_probe().

Unstructured environment settings can work in drivers, but new-bus is
even further from being able to support this (by the definition of
"unstructured"). The driver just has to find them using a direct
method in the probe if they are needed in the probe. Then there are
complications linking these with the new-bus part of the configuration.

Bruce

John Baldwin

2013-01-17 18:41:26 UTC

Post by Andre Albsmeier
* ...

== 0 )

So the flags interface is unusable before some driver "wins".

No, we set it twice. Specifically, it is set before each probe, then it is
set again after a winning driver is chosen so that the proper flags exist
during attach as well.

--
John Baldwin

Bruce Evans

2013-01-18 08:06:14 UTC

[reading flags in the driver]

So the flags interface is unusable before some driver "wins".

No, we set it twice. Specifically, it is set before each probe, then it is
set again after a winning driver is chosen so that the proper flags exist
during attach as well.

Why didn't it work for Andre then?

It might be a layering problem, with the flags not working because the
hint says that they are for ppc but the bus name being puc. I thought
that this problem was fixed. In FreeBSD-~5.2, I had to add flags
reading to sio_pci.c and sio_puc.c to get flags for sio actually seen
by sio when the bus is not isa. subr_bus.c does the 2 settings of the
flags much the same in FreeBSD-~5.2, but this certainly doesn't work.

Bruce

John Baldwin

2013-01-18 17:13:47 UTC

[reading flags in the driver]

So the flags interface is unusable before some driver "wins".

No, we set it twice. Specifically, it is set before each probe, then it is
set again after a winning driver is chosen so that the proper flags exist
during attach as well.

Why didn't it work for Andre then?

In followup e-mail he said it did work. The one reason it might not have
worked before is that if he did 'ppc.0.at=foo' and that forced the ppc device
to be ppc1 instead of ppc0 in which case the ppc0 flags wouldn't have applied.

Post by Bruce Evans
It might be a layering problem, with the flags not working because the
hint says that they are for ppc but the bus name being puc. I thought
that this problem was fixed. In FreeBSD-~5.2, I had to add flags
reading to sio_pci.c and sio_puc.c to get flags for sio actually seen
by sio when the bus is not isa. subr_bus.c does the 2 settings of the
flags much the same in FreeBSD-~5.2, but this certainly doesn't work.

I don't know off hand. :(

--
John Baldwin

Andre Albsmeier

2013-01-18 17:40:19 UTC

[reading flags in the driver]

So the flags interface is unusable before some driver "wins".

No, we set it twice. Specifically, it is set before each probe, then it is
set again after a winning driver is chosen so that the proper flags exist
during attach as well.

Why didn't it work for Andre then?

Well, in my despair (before the bug was fixed) I tried
also (and only):

hint.ppc.1.flags=0x2F

but this didn't work as well. If we want to dig into this,
I can plug another puc card in my desktop box (the other
one is sitting in a server where I don't want to do
experiments) and try to reproduce it here...

-Andre