Re: inteldrm suspend/resume regression (Was: Suspend/resume in Gnome)
On Fri, Mar 07, 2014 at 05:00:43PM -0700, Theo de Raadt wrote: > Any feedback? > [...] A current CVS checkout + cold=2 suspends fine and hangs on resume. By "hang", I mean the display stays black and the little halfmoon LED continues blinking instead of turning off. I suppose that means the kernel is busy printing a shitton of "TSLEEP" and takes a _very_ long time to come up again. Sadly, I don't have a serial console on my laptop, so I can't verify that. For the record, I have vga1 at pci0 dev 2 function 0 "Intel GM965 Video" rev 0x0c Is there anything I can do to further assist? Thanks a lot by the way for the explanation of DVACT_RESUME vs. DVACT_WAKEUP. -- Gregor Best
Re: 5.5 and dual-boot
> On Sat, 8 Mar 2014, Theo de Raadt wrote:
> > > I follow "-current" for several years but recently a thing puzzles me.
> > >
> > > My "x200" is a dual-boot system ("Seven"/OpenBSD "-current") and since (I
> > > think) the "amd64/i386 installboot" change, each time I upgrade via
> > > "bsd.rd", I have to generate a new "openbsd.pbr" and copy it to "Seven".
> > >
> > > If I miss that, I get an "ERR M" and can't go further.
> > >
> > > First I was thinking about changes but I checked code and last
> > > modification on boot(8) was made 2 weeks ago (I did 2 updates since it).
> > >
> > > I used that setup for several years without any need to do that, what do
> > > I miss here, is it now normal ?
> >
> > The old installboot would reuse the same file, very carefully.
>
> To be clear, the old amd64/i386 installboot never updated /boot - it only
> ever
> patched biosboot and installed it into the PBR. It was entirely up to the
> user (or the install script) to copy /usr/mdec/boot file to /boot - if you
> used cp or cat the old PBR may have continued to work, but there was no
> guarantee.
It was entirely up to something but, but you removed it and replaced it
(incorrectly).
You removed a line like this from various places:
- cat /mnt/usr/mdec/boot >/mnt/boot
and then replaced it with a line which writes a fresh new file, on fresh
disk blocks. It matters, because at that moment primary bootblocks (of
various sorts) point at the old blocks, including ones that installboot
itself is not handling.
It is fundamental to the way that primary and secondary bootblocks
operate on many architectures.
(Those that do not understand multiboot are doomed to break it :)
> > Joel's new installboot does not do that, and chooses to be careful
> > about handling a different problem instead.
> >
> > Can't easily solve both problems. I think he should revert to the
> > old method.
Incorrect. The problem is that the new code does not emulate the
try-to-reuse-the-same-blocks mechanism that was in use before.
Re: 5.5 and dual-boot
> To be clear, the old amd64/i386 installboot never updated /boot - it only
> ever
> patched biosboot and installed it into the PBR. It was entirely up to the
> user (or the install script) to copy /usr/mdec/boot file to /boot - if you
> used cp or cat the old PBR may have continued to work, but there was no
> guarantee.
This improperly describes what the previous sequence did.
It did not "copy" the content to /boot. In fact, it "cat'd" it to the
existing file, thereby replacing the existing ffs blocks with new ffs
blocks. The block numbers in use do not change (typically). It is
not a published semantic of the ffs code, but...
Furthermore, this is not a new or surprising idiom; it has been used
all over the place in the past for bootblocks.
This mechanism is commonly used when the primary bootcode have a very
small space to remember where the secondary code is. That is why the
primary loader has to (generally) be modified afterwards. In the
common case, for re-installing bootblocks, they do land in the same
place, and ... thus, your change broke things for people.
Here's the old code, and the new code.
Index: install.md
===
RCS file: /cvs/src/distrib/i386/common/install.md,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -p -u -r1.56 -r1.57
--- install.md 16 Nov 2013 18:37:27 - 1.56
+++ install.md 20 Jan 2014 05:14:05 - 1.57
@@ -39,10 +39,7 @@ NCPU=$(sysctl -n hw.ncpufound)
((NCPU > 1)) && { DEFAULTSETS="bsd bsd.rd bsd.mp" ; SANESETS="bsd bsd.mp" ; }
md_installboot() {
- # LBA biosboot uses /boot's i-node number. Using 'cat' preserves that
- # number, so multiboot setups (NTLDR) can work across upgrades.
- cat /mnt/usr/mdec/boot >/mnt/boot
- if ! /mnt/usr/mdec/installboot /mnt/boot /mnt/usr/mdec/biosboot ${1} ;
then
+ if ! installboot -r /mnt ${1} ; then
echo "\nFailed to install bootblocks."
echo "You will not be able to boot OpenBSD from ${1}."
exit
Re: 5.5 and dual-boot
On Sat, 8 Mar 2014, Theo de Raadt wrote:
> > I follow "-current" for several years but recently a thing puzzles me.
> >
> > My "x200" is a dual-boot system ("Seven"/OpenBSD "-current") and since (I
> > think) the "amd64/i386 installboot" change, each time I upgrade via
> > "bsd.rd", I have to generate a new "openbsd.pbr" and copy it to "Seven".
> >
> > If I miss that, I get an "ERR M" and can't go further.
> >
> > First I was thinking about changes but I checked code and last
> > modification on boot(8) was made 2 weeks ago (I did 2 updates since it).
> >
> > I used that setup for several years without any need to do that, what do
> > I miss here, is it now normal ?
>
> The old installboot would reuse the same file, very carefully.
To be clear, the old amd64/i386 installboot never updated /boot - it only ever
patched biosboot and installed it into the PBR. It was entirely up to the
user (or the install script) to copy /usr/mdec/boot file to /boot - if you
used cp or cat the old PBR may have continued to work, but there was no
guarantee.
> Joel's new installboot does not do that, and chooses to be careful
> about handling a different problem instead.
>
> Can't easily solve both problems. I think he should revert to the
> old method.
--
"Action without study is fatal. Study without action is futile."
-- Mary Ritter Beard
