> Date: Thu, 25 Nov 2021 15:14:27 -0700
> From: Ted Bullock
Hi Ted,
I made some small changes to the code and committed it. I chose to
use device_type in the end since that better reflects the intention of
disabling devices that use the Open Firmware driver for IDE devices.
Thanks for getting
On 2021-11-25 5:22 a.m., Ted Bullock wrote:
> On 2021-11-25 5:05 a.m., Mark Kettenis wrote:
>> From: Ted Bullock
>>> On 2021-11-25 3:55 a.m., Otto Moerbeek wrote:
> + parent = OF_parent(handle);
I think the OF_parent call can go inside the !strcmp(buf, "block")
block.
>>>
On 2021-11-25 5:05 a.m., Mark Kettenis wrote:
From: Ted Bullock
On 2021-11-25 3:55 a.m., Otto Moerbeek wrote:
+ parent = OF_parent(handle);
I think the OF_parent call can go inside the !strcmp(buf, "block") block.
I worried that the following re-assignment of the handle would cause
> Date: Thu, 25 Nov 2021 04:28:55 -0700
> Content-Language: en-US
> Cc: Theo de Raadt ,
> Mark Kettenis , bugs@openbsd.org
> From: Ted Bullock
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 2021-11-25 3:55 a.m., Otto Moerbeek wrote:
> >> + parent = OF_parent(handle);
>
On 2021-11-25 4:29 a.m., Mark Kettenis wrote:
And I think it is better to use "device_type" here.
https://github.com/openbios/openboot/blob/master/obp/dev/ide/ide.fth
The obp source list both identifiers, however, the 1275 spec says:
3.2.1.1 Node names
Each node in the device tree is
> Date: Thu, 25 Nov 2021 11:55:24 +0100
> From: Otto Moerbeek
>
> On Wed, Nov 24, 2021 at 02:48:29PM -0700, Ted Bullock wrote:
>
> > On 2021-11-20 2:49 p.m., Ted Bullock wrote:
> > > This patch disables fchmod in the bootblock for IDE drives on sparc64
> > >
> > > I can confirm that this
On 2021-11-25 3:55 a.m., Otto Moerbeek wrote:
+ parent = OF_parent(handle);
I think the OF_parent call can go inside the !strcmp(buf, "block") block.
I worried that the following re-assignment of the handle would cause
problems, so I chose an order of operations and placed the parent
On Wed, Nov 24, 2021 at 02:48:29PM -0700, Ted Bullock wrote:
> On 2021-11-20 2:49 p.m., Ted Bullock wrote:
> > This patch disables fchmod in the bootblock for IDE drives on sparc64
> >
> > I can confirm that this allows my sunblade 100 to boot -current
> Hi folks,
>
> I'm requesting to have the
On Wed, Nov 24, 2021 at 11:29:09PM +0100, Mark Kettenis wrote:
> > Date: Wed, 24 Nov 2021 14:48:29 -0700
> > From: Ted Bullock
>
> Hi Ted,
>
> Yes, I think your idea is sane and the diff looks good. But I'd like
> to test it myself before I commit it and I haven't found the time to
> do so
> Date: Wed, 24 Nov 2021 14:48:29 -0700
> From: Ted Bullock
Hi Ted,
Yes, I think your idea is sane and the diff looks good. But I'd like
to test it myself before I commit it and I haven't found the time to
do so yet.
Do remind me if I haven't done so in a week or so.
Thanks,
Mark
> On
On 2021-11-20 2:49 p.m., Ted Bullock wrote:
> This patch disables fchmod in the bootblock for IDE drives on sparc64
>
> I can confirm that this allows my sunblade 100 to boot -current
Hi folks,
I'm requesting to have the patch I sent in a previous mail reviewed and
committed. I also attached the
On 2021-11-18 6:25 p.m., Ted Bullock wrote:
> On 2021-11-15 2:41 p.m., Ted Bullock wrote:
>> On 2021-11-15 2:21 p.m., Theo de Raadt wrote:
>>> I do want fchmod for random reuse on most sparc64 machines. But if
>>> OFW "write"
>>> support isn't working on some machines, we should nop it out.
On 2021-11-15 2:41 p.m., Ted Bullock wrote:
> On 2021-11-15 2:21 p.m., Theo de Raadt wrote:
>> I do want fchmod for random reuse on most sparc64 machines. But if
>> OFW "write"
>> support isn't working on some machines, we should nop it out. Luckily
>> this is
>> in MD code.
>
> It's probably
On 2021-11-15 2:21 p.m., Theo de Raadt wrote:
I do want fchmod for random reuse on most sparc64 machines. But if OFW "write"
support isn't working on some machines, we should nop it out. Luckily this is
in MD code.
It's probably reasonable for any version older than OpenBoot 4.17.1
should
Ted Bullock wrote:
> On 2021-11-15 12:28 p.m., Theo de Raadt wrote:
> > Otto Moerbeek wrote:
> >> So you build code with just the struct fs_ops change, while
> >> keeping everything else the same?
> >>
> >> Very puzzling...
> > indeed, you are losing us Ted.
> > Just comment out the fchmod()
On 2021-11-15 12:28 p.m., Theo de Raadt wrote:
Otto Moerbeek wrote:
So you build code with just the struct fs_ops change, while
keeping everything else the same?
Very puzzling...
indeed, you are losing us Ted.
Just comment out the fchmod() call.
Does it work then?
Yes the system boots
Otto Moerbeek wrote:
> On Mon, Nov 15, 2021 at 11:59:07AM -0700, Ted Bullock wrote:
>
> > On 2021-11-14 7:57 p.m., Theo de Raadt wrote:
> > > But I fear the "write" operation was never been tested by the Sun,
> > > or maybe we are not doing something
> > >
> > > but only on earlier
On Mon, Nov 15, 2021 at 11:59:07AM -0700, Ted Bullock wrote:
> On 2021-11-14 7:57 p.m., Theo de Raadt wrote:
> > But I fear the "write" operation was never been tested by the Sun,
> > or maybe we are not doing something
> >
> > but only on earlier generations
> I perused the change log of
On 2021-11-14 7:57 p.m., Theo de Raadt wrote:
But I fear the "write" operation was never been tested by the Sun,
or maybe we are not doing something
but only on earlier generations
I perused the change log of stand.h and revision 1.67 also might/will
trigger the same bug on upgrading
Ted Bullock wrote:
> On 2021-11-14 7:36 p.m., Theo de Raadt wrote:
> > So maybe the "write" operation is broken on these older roms.
>
> Is there any more verbose way of seeing what's happening as it starts?
> I'm fairly certain that ddb isn't available since this is happening
> before the
On 2021-11-14 7:36 p.m., Theo de Raadt wrote:
So maybe the "write" operation is broken on these older roms.
Is there any more verbose way of seeing what's happening as it starts?
I'm fairly certain that ddb isn't available since this is happening
before the kernel is even loaded. I'm kind of
Ted Bullock wrote:
> OK more specifics,
>
> I repeated my tests from last night and the boot does indeed fail
> after revision 1.35 on sys/arch/sparc64/stand/ofboot/boot.c
>
> >
> >> Random was added to the bootblocks before 6.7. But then code was
> >> added to fchmod the random file, so
OK more specifics,
I repeated my tests from last night and the boot does indeed fail after
revision 1.35 on sys/arch/sparc64/stand/ofboot/boot.c
Random was added to the bootblocks before 6.7. But then code was
added to fchmod the random file, so that it would not be reused.
That fchmod is
Heyo Theo (and Mark),
On 2021-11-13 4:12 p.m., Theo de Raadt wrote:
If you say that 6.7 works, then the changes in the logs to look at are
the following.
It isn't that many diffs, see below.
I went through every diff to sys/arch/sparc64/stand between release 6.7
(working) until things
Nope, this is also needed ahead of time
# cd /usr/src/sys
# make obj
otherwise, sys/stand and sys/lib don't have obj@ subtrees, and the
later compile will reach into the wrong places.
Experienced developers can forget about this because they always have
obj subtrees...
> # cd
If you say that 6.7 works, then the changes in the logs to look at are
the following.
It isn't that many diffs, see below.
Compiling the bootblocks is not hard
cd /usr/src
make obj # YES FROM THE TOP OF THE TREE
cd sys/arch/sparc64/stand
make
> Date: Sat, 13 Nov 2021 15:45:19 -0700
> From: Ted Bullock
>
> On 2021-11-04 4:04 p.m., Ted Bullock wrote:
> > On 2021-11-02 5:36 p.m., Ted Bullock wrote:
> >> Reporting an issue that is causing my SunBlade 100 (ultrasparc64)
> >> workstation to be unable too boot.
> >
> > I've identified
On 2021-11-04 4:04 p.m., Ted Bullock wrote:
On 2021-11-02 5:36 p.m., Ted Bullock wrote:
Reporting an issue that is causing my SunBlade 100 (ultrasparc64)
workstation to be unable too boot.
I've identified the malfunctioning component that is causing installs
after 6.7 to fail for this
On 2021-11-02 5:36 p.m., Ted Bullock wrote:
Reporting an issue that is causing my SunBlade 100 (ultrasparc64)
workstation to be unable too boot.
I've identified the malfunctioning component that is causing installs
after 6.7 to fail for this system, although I'm not certain yet which
patch
29 matches
Mail list logo
