Re: FAQ 14.9: installboot example parameters reversed
On 02/26/15 05:44, Rolf Sommerhalder wrote: Hi, While salvaging a CompactFlash with a corrupt partition table, I noticed that the example in http://www.openbsd.org/faq/faq14.html#InstBoot appears to be outdated: # cd /usr/mdec; ./installboot /boot biosboot sd0 According to installboot(8), the syntax is: installboot [-nv] [-r root] disk [stage1 [stage2]] e.g. the example should read: # cd /usr/mdec; ./installboot sd0 biosboot /boot or: installboot -v sd0 /usr/mdec/biosboot /boot or finally, if sd0a is mounted on /mnt: installboot -v -r /mnt/ sd0 /usr/mdec/biosboot /mnt/boot Thanks, Rolf yes, that section is wrong, but your correction is wrong and incomplete. The whole point of the rework of installboot was to de-platform-specific it, and to have sane defaults, thus the new syntax will be just installboot sd0, and (current) installboot is not in /usr/mdec anymore. I got to think about this...I'm not sure there's even any merit to this section anymore. Proper answer might be delete it. Nick.
Re: fix stuck cancelled ehci xfers (ehci_idone: ex=%p is done!)
On Thu, Feb 26, 2015 at 01:51:29AM +0100, Martin Pieuchot wrote:
On 22/02/15(Sun) 00:54, Martin Pieuchot wrote:
On 20/02/15(Fri) 23:15, Stefan Sperling wrote:
In the following configuration I can pretty easily trigger endless
screenfulls of scrolling ehci_idone: ex=%p is done! messages,
where %p is to a constant pointer value (same in each message).
[ehci host]--[usb extension cable (hub 1)]--[usb keyboard (hub
2)]--[usb mouse]
So there's a USB extension cable (hub 1) that I plug a keyboard into.
The keyboard in turn has a built-in hub that has a mouse plugged into it.
The problem happens almost every time I pull the keyboard out of hub 1.
I've also seen it happen without any intervention on my part (In fact
I was in a different city and couldn't use the box until I got home
several hours later and hit the reset switch... that's no fun)
So if a transfer is cancelled (e.g. as a result of pulling the plug),
then:
- usbd_abort_pipe wants to abort a related transfer
- ehci_abort_xfer schedules and waits for ehci_softintr, expecting
the softintr routine to deal with the cancelled transfer:
/*
* Step 3: Make sure the soft interrupt routine has run. This
* should remove any completed items off the queue.
* The hardware has no reference to completed items (TDs).
* It's safe to remove them at any time.
*/
s = splusb();
sc-sc_softwake = 1;
usb_schedsoftintr(sc-sc_bus);
tsleep(sc-sc_softwake, PZERO, ehciab, 0);
- ehci_softintr gets scheduled
- ehci_softintr loops over xfers on the sc_intrhead TAILQ and
invokes ehci_check_intr on each
- ehci_check_intr eventually ends up calling ehci_idone
- ehci_idone does nothing for cancelled transfers... ?!?
if (xfer-status == USBD_CANCELLED ||
xfer-status == USBD_TIMEOUT) {
DPRINTF((ehci_idone: aborted xfer=%p\n, xfer));
return;
}
- something else happens
- ehci_abort_xfer awakes from tsleep and sets ex-isdone, since it
expects the softinterrupt routine to have dealt with the xfer
- something else happens
- the host controller sends an INTERR interrupt
- ehci_intr1 schedules ehci_softintr
- ehci_softintr loops over xfers on the sc_intrhead TAILQ and
invokes ehci_check_intr on each
- the cancelled xfer is still in the intrhead TAILQ and ends up in
ehci_idone
- ehci_idone looks for the isdone flag which is now set, then it
complains and does nothing
- the host controller sends an INTERR interrupt
... same story again, we get an endless loop
This diff breaks the chain of events and fixes the endless loop for me.
I can't reproduce the problem anymore by pulling the keyboard out.
I don't quite understand how this prevents the flood of INTERR interrupts
but it seems to work.
I assume there are nasty tentacles in USB land which I'm unfamiliar with.
Is there any reason this could be a bad idea?
Stefan that's a really good analysis. I think the diff might not be
completely correct though.
So basically you're removing the transfer from the active list. That's
generally done after the USB callback has been executed, in your case in
ehci_device_intr_done().
For interrupt transfers (pipe-repeat is 1) the transfer is kept on the
list while the descriptors are freed/reallocated. That should be safe
since we should be reusing the sames.
So I don't know if we are missing a spl protection of if there's an xfer
leak but I'm afraid that with your diff usb_transfer_complete() might
not be called for the failing xfer.
That's easy to check, look if the ehcixfer pool counter increase when
you detach your device.
I'm afraid I cannot help more as I am currently traveling :)
Here's an alternative diff that removes xfers from the list of
currently pending transfers as soon as they are finished or
cancelled. This should also prevent the race you analysed.
With this diff ehci_idone() should no longer be called on a
CANCELLED or TIMEOUT xfer which mean the 'isdone' check can
be removed.
Does it work for you?
It does, yes. Thanks.
Your diff also stops the vomit of ehci_idone messages for me when
I unplug devices or hubs.
There are other issues which are not fixed by this diff and which
my diff did not fix either.
Sometimes my USB keyboard seems to go insane and keeps pressing a key
repeatedly even though I'm not pressing it. For example, when I typed
make install
today the keyboard kept repeating the letter l so the line looked
like this:
make
install
I've seen this problem with 2 different USB keyboards.
Re-plugging the keyboard or the hub it is connected to now restores normal
behaviour -- before this discussion unplugging usually
Re: [patch]sudo: punctuation fixes
i once tried to fix some of these messages a long time ago, but the diffs got rejected because the errors are considered classic in their current form and are now heritage protected. On 25 Feb 2015, at 9:49 pm, Fritjof Bornebusch frit...@alokat.org wrote: On Wed, Dec 24, 2014 at 01:48:44PM +0100, Fritjof Bornebusch wrote: Ping .. Hi tech@, looks like there are some missing periods regarding the sudo wrong password messages. fritjof Index: ins_csops.h === RCS file: /cvs/src/usr.bin/sudo/ins_csops.h,v retrieving revision 1.5 diff -u -p -r1.5 ins_csops.h --- ins_csops.h 4 Mar 2010 12:21:36 - 1.5 +++ ins_csops.h 24 Dec 2014 12:34:49 - @@ -34,6 +34,6 @@ #endif I've seen penguins that can type better than that., Have you considered trying to match wits with a rutabaga?, -You speak an infinite deal of nothing, +You speak an infinite deal of nothing., #endif /* _SUDO_INS_CSOPS_H */ Index: ins_classic.h === RCS file: /cvs/src/usr.bin/sudo/ins_classic.h,v retrieving revision 1.3 diff -u -p -r1.3 ins_classic.h --- ins_classic.h4 Mar 2010 12:21:36 - 1.3 +++ ins_classic.h24 Dec 2014 12:35:36 - @@ -21,7 +21,7 @@ * Insults from the original sudo(8). */ -Wrong! You cheating scum!, +Wrong! You cheating scum!, #ifdef PC_INSULTS And you call yourself a Rocket Scientist!, #else Index: ins_goons.h === RCS file: /cvs/src/usr.bin/sudo/ins_goons.h,v retrieving revision 1.3 diff -u -p -r1.3 ins_goons.h --- ins_goons.h 4 Mar 2010 12:21:36 - 1.3 +++ ins_goons.h 24 Dec 2014 12:38:56 - @@ -24,25 +24,25 @@ You silly, twisted boy you., He has fallen in the water!, We'll all be murdered in our beds!, -You can't come in. Our tiger has got flu, +You can't come in. Our tiger has got flu., I don't wish to know that., What, what, what, what, what, what, what, what, what, what?, You can't get the wood, you know., You'll starve!, ... and it used to be so popular..., -Pauses for audience applause, not a sausage, +Pauses for audience applause, not a sausage., Hold it up to the light --- not a brain in sight!, Have a gorilla..., There must be cure for it!, There's a lot of it about, you know., You do that again and see what happens..., -Ying Tong Iddle I Po, +Ying Tong Iddle I Po., Harm can come to a young lad like that!, And with that remarks folks, the case of the Crown vs yourself was proven., Speak English you fool --- there are no subtitles in this scene., You gotta go ow!, I have been called worse., It's only your word against mine., -I think ... err ... I think ... I think I'll go home, +I think ... err ... I think ... I think I'll go home., #endif /* _SUDO_INS_GOONS_H */
FAQ 14.9: installboot example parameters reversed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, While salvaging a CompactFlash with a corrupt partition table, I noticed that the example in http://www.openbsd.org/faq/faq14.html#InstBoot appears to be outdated: # cd /usr/mdec; ./installboot /boot biosboot sd0 According to installboot(8), the syntax is: installboot [-nv] [-r root] disk [stage1 [stage2]] e.g. the example should read: # cd /usr/mdec; ./installboot sd0 biosboot /boot or: installboot -v sd0 /usr/mdec/biosboot /boot or finally, if sd0a is mounted on /mnt: installboot -v -r /mnt/ sd0 /usr/mdec/biosboot /mnt/boot Thanks, Rolf -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU7vkWAAoJEEFJy0CVh/JsUCsIAJiI/om+YD6wsqqrPbK2zBWy vurLWytOrEFIwAvobjb6kzsniPOdy7+73JLSAEm4v66dDuU0tbpdl63pc7AQtq5P BrhpCOLWj/QGf0f9dkadjvxvDneTgkZ2HL6Mja2M/dzWLD3Ew06Js9A+luiM/JxG +RChmFoaUk31/L7E6/FYbXgox7QotePhYY45d9gEQmRickkebJmfXp08XtaXl4ru 6y9D7B+uABJ9yJF953a2Gu9jDBRrxo3tepytg7950R4ULuDh48g9GLPjd2URX2Hg W4dmBrZWTnNsfPWp8s+hAly/JtFHOg5uVNhd+ce8zkou/mhD27SjtMBl9W1FNFA= =jcvG -END PGP SIGNATURE-
Re: FAQ 14.9: installboot example parameters reversed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ... and there is a second example further down in 14.10: # cp /usr/mdec/boot /mnt/boot # /usr/mdec/installboot -v /mnt/boot /usr/mdec/biosboot sd0 which should probably read: # cp /usr/mdec/boot /mnt/boot # /usr/mdec/installboot -v -r /mnt/ sd0 /usr/mdec/biosboot /mnt/boot -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU7vx1AAoJEEFJy0CVh/JsJRkIAKWFLL1wYns1sAXls/+NdNiz 0uYTH1sCp2MhfmBOVJ0BGuuJBdDwVy+n0YNurQ4tcdb2lzf1Y4764KoPhcTgGT88 VP62u29ZkqmdkXGr8RLBlq8+5edk8Ogc62JOGZOJOXOu8LhKTNnrAiI+AI1pPTGd 3b7hzqh6cGmefOofIYgHOsgKya0GeF923hNqOkgn98FgJv67jYZT+0FSYmYkc9Jb mQ28B34dzmIWaRWDDG39it1tY6Ll7IiTusrabjwYtYy7ZbNLPgypLwfmpS5uf5kl cwz4kecEyk4/lz4VgDxOJKRYXFt7PZ48OlHEwU1c+bsCVyKBZ7CBpQ663Atn5PU= =oAzj -END PGP SIGNATURE-
