there was a corner case that was missed in
x86/intr.c:intr_establish_xname()
In isa_machdep.c:isa_intr_establish_xname() the legacy_irq parameter
is never set to -1. It is also incorrect to call
isa_intr_establish_xname() with a legacy_irq parameter of -1.
Thus we infer that whenever we see (legacy_irq == -1) in
intr_establish_xname() which is downstream, we were *NOT* called from
isa_machdep.c:isa_intr_establish_xname()
Given that there are no other users of intr_establish_xnam() which
pass a valid legacy_irq != -1, we assume therefore that we *WERE*
called from isa_machdep.c:isa_intr_establish_xname() in this case.
This is an important distinction in the case where a valid
legacy_irq > NUM_LEGACY_IRQS was passed down from
isa_intr_establish_xname() but was ignored by xen_pirq_alloc() and
overwritten with the "pseudo" irq which is then passed back. We thus
pass the incorrect "legacy" irq value to pirq_establish().
Even though non ISA (ie; PCI and MSI(X) cases), this is the correct
behaviour, we need to maintain (bug?) compatibility with the isa
case.
Thus the one liner diff.
CVS: ----------------------------------------------------------------------
CVS: CVSROOT cvs.NetBSD.org:/cvsroot
CVS: please use "PR category/123" to have the commitmsg appended to PR 123
CVS:
CVS: Please evaluate your changes and consider the following.
CVS: Abort checkin if you answer no.
CVS: => For all changes:
CVS: Do the changed files compile?
CVS: Has the change been tested?
CVS: => If you are not completely familiar with the changed components:
CVS: Has the change been posted for review?
CVS: Have you allowed enough time for feedback?
CVS: => If the change is major:
CVS: => If the change adds files to, or removes files from $DESTDIR:
CVS: => If you are changing a library or kernel interface:
CVS: Have you successfully run "./build.sh release"?
- pass intmax to fmtydhmsf instead of time_t to avoid extra conversions.
- make -TTT mean "always keep 3 decimal digits of duration precision" (ie:
always print ms) (including trailing 0's, even .000 if it happens)
- make -T (all forms) be subject to the locale (obey the radix character)
- don't print ymd, since that would require calendar calculations to get
right.
decimal fractions of a second (as they should be) rather than integer
milliseconds (ie nnn.1means nnn seconds and 1/10 of a second, not
nnn seconds, and 1 millisecond). While here convert some inappropriate
time_t usage to intmax_t which works better (int, or long, would probably
work just as well).
It's Cyclone V based and thus includes a dual-core Cortex A9 @925MHz.
Most standard peripherals are supported (USB, SDCard, Ethernet) and
no unusual peripheral is supported yet (FPGA, GPIO, ...)
The 4th argument for in[46]_cksum() should be length of L4 header +
L4 payload. The previous revisions are wrong
- for IPv4 when hdrlen != 0
- for IPv6 always
These functions are used only in net/if_loop.c and
arch/powerpc/booke/dev/pq3etsec.c under some special circumferences.
This should be why the bugs have not been found until today.
OK maxv
commit 1bd0e85c3ce7f6946f5cd4e18e7b45d50767412f
Author: popcornmix <popcornmix@gmail.com>
Date: Mon Sep 17 14:39:10 2018 +0100
Tested by Jun Ebihara as discussed on port-arm
- return -1 for error / no character
- allow 0 as a character
cngetc() itself considers any value >= 0 valid, and this matches
the usage in other drivers that return -1 for "not data", vs
polling until something arrives.
removes ^G from spewing out the askname/etc prompts when no key
has been pressed (these come from cngetsn(), ignoring unknown
non printable characters.)
from @skrll with help from @mlelstv.
as it runs during the interrupts part of configuration now,
and all the devices try attach as early as possible, including
any root or boot required disk or keyboard device, which is
what this flag was for.
- make sure xhci's sc->sc_ios is NULL if failure happens.
- rearrange usb_attach() / usb_doattach() to make it simpler to clean up.
- move usb_async_intr softint into usb_once_init(). previously, each USB
controller would start a new one, and leave the old one leaked.
- handle controller interrupts without a bus attached
Fix kernel crash when console is attached. Now, my MC/R550 boots multiuser.
Thanks Masahiko Ito for encouraging me to do bisection to find this out.
XXX pullup-8, pullup-7
systems with ehci handover to uhci (and maybe ohci), and fix a similar
problem for "boot -s".
there is effort to ensure that all devices attached via USB are probed
before RB_ASKNAME or RB_SINGLE attempts to ask any questions on the console,
and largely this works, often by chance, today, for USB disks and root.
i've recently pushed this more into uhub and general USB device attachment
as well, and kept a config_pending reference across the first explore of
a bus. these fix many issues with directly attached hubs.
however, on systems where devices connected to ehci ports are handed over
to a companion uhci or ohci port, it may not be the first, or even second,
bus explore that finds the device finally before attachment, and at this
point all config_pending references are dropped.
there is no direct communication between drivers, the potentials are
looked up but their device_t is only used for generic things like the name,
so informing the correct companion to expect a device and deal with the
config_pending references is not possible without some fairly ugly layer
violations or multi-level callbacks (eg, we have "ehci0", and usually an
the relevant companion, eg, "uhci2", but it is the uhub that uhci2 has
attached that will deal with the device attachment.)
with the above fixes to generic USB code, the disown happens during the
first explore. the hack works by, at this point, checking if (a) root
is not mounted, (b) single user or ask name are set, and (c) if the hack
as not been triggered already. if all 3 conditions are true, then a
config_pending_incr() is called and a callback is triggered for (default)
5 seconds to call config_pending_decr(). ehci detach pauses waiting for
this callback if scheduled.
this allows enough time for the uhub and the ukbd/wskbd to attach before
the RK_ASKROOT prompts appear. testing shows it takes between 1.5 and
2 seconds for the keyboard to appear after the disown occurs.
Index: dev/usb/ehcivar.c
- new sc_compcallout, sc_compcallout, sc_complock, and a state for th
handover hack.
Index: dev/usb/ehci.c
ehci_init():
- use aprint_normal_dev() instead of manual device_xname().
- initialise sc_compcallout, sc_compcallout, sc_complock, and sc_comp_state.
ehci_detach():
- if there are companion controllers, tear own the above, including waiting
if there is a callback scheduled.
ehci_disown_callback():
- new callout to call config_pending_decr() in the the future.
schedule this ca
ehci_disown_sched_callback():
- if booting to single user or asking names, call config_pending_incr() and
schedule the callout above, default 5 second delay.
ehci_disown():
- if disowning a port call ehci_disown_sched_callback().
- call config_pending_incr() and config_pending_decr() around attaching
devices against "usbdevif" attribute.
uhub:
- convert sc_explorepending and sc_running to bool. add new sc_first_explore.
- call config_pending_incr() at the start of uhub_attach(). dropped in
uhub_explore(), if this is the first explore.
- export root_is_mounted for future USB RB_ASKNAME hack.
- make some things in subr_autoconf.c static
- move device_printf() prototype out from the middle of two sets of
aprint_*() prototypes.
This makes "recent" dwc gmac controllers, as found e.g. on the Cyclone V, work.
The change was also tested working on an Allwinner A20 which doesn't have the
feature.
No negative reaction on port-arm.
The problem arises if we receive three fragments of the kind
3. A -> has MFF
1. B -> doesn't have MFF
2. C -> doesn't have MFF
Because of the received order B->C->A, we don't see that B is !MFF, and
therefore that there is a problem in this chain.
Now we do two checks, and drop us if:
* there is a fragment preceding us, and this fragment is !MFF, or
* there is a fragment following us, and we are !MFF
Spotted a long time ago.
rin