t feature on this display.
Anyway, it's fine for now. I don't think it's necessary to switch
drivers just yet.
btw, is there a tool in base that I can use to grab a screenshot of
what X is showing?
--
Ted Bullock
On 2021-12-05 5:15 p.m., Theo de Raadt wrote:
> Jonathan Gray wrote:
>> On Sun, Dec 05, 2021 at 04:54:28PM -0700, Ted Bullock wrote:
>>> Hey folks,
>>>
>>> Looking into another usability fault with the SunBlade 100. This time
>>> with the onboa
upgrading between versions for these machines.
--
Ted Bullock
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
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
.1
should get this treatment (This is the most recent ofw for the blade
100/150)
--
Ted Bullock
says otherwise.
--
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 the malfunctioning component that is causing installs
after 6.7 to fail
tested the latest forth bootblock with an older version of
ofwboot and the system has started fine, so it might not actually be
otto's change that introduce the bug? More testing IS required.
--
Ted Bullock
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
utely be moved later in the function call.
Notably there is quite a bit of variable re-use and re-purposing in the
devopen function so I chose the place I thought would be safest.
--
Ted Bullock
at Ted and mail a new diff?
Yes, it will have to wait until later today when I'm at the machine
though. Thanks for taking the time to review in the meantime.
--
Ted Bullock
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 w
t : Failure, fault introduced before this date
Resetting to 2020-05-26
Checking 2020-05-26
Result : Boots
Updating to "2020-05-26 16:29 UTC"
Result : Boots
Updating to "2020-05-26 16:35 UTC"
Result : Fault
introduced/triggered at R1.35 on sys/arch/sparc64/stand/ofboot/boot.c
--
Ted Bullock
. I'm kind of worried that the only way
to see into what is happening is with a logic analyzer but maybe there
is higher level stuff in the obp?
--
Ted Bullock
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_paren
on those
versions at all). For example on -current all that I get on boot is this:
Rebooting with command: boot
Boot Device: disk File and args:
OpenBSD IEEE 1275 Bootblock 2.1
..>> OpenBSD BOOT 1.21
Trying BSD...
/
Evaluating:
Flushbuf error
read header: short read (only 0 of 64)
--
Ted B
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
On 2021-12-09 6:46 p.m., Ted Bullock wrote:
> On 2021-12-06 4:21 p.m., Ted Bullock wrote:
> I think that there is an bug triggered by endian code here:
>
>> radeondrm0: RV100
>> BIOS signature incorrect 0 0
>
> in sys/dev/pci/drm/radeon/radeon_bios.c:840
>
>
On 2021-12-06 4:21 p.m., Ted Bullock wrote:
> Ok, so this time I plugged in a discrete GPU into this ultrasparc
> system, the sun XVR-100 which is a PCI card with vga and dvi ports. The
> card uses an ati radeon r100 generation video chip.
I think that there is an bug triggered by en
0 dev 8 function 0 "Acer Labs M5451 Audio" rev 0x01: ivec 0x7e3
ac97: codec id 0x41445348 (Analog Devices AD1881A)
ac97: codec features headphone, Analog Devices Phat Stereo
audio0 at autri0
midi0 at autri0: <4DWAVE MIDI UART>
pciide0 at pci0 dev 13 function 0 "Acer Labs M5229 IDE" rev 0xc3: DMA, channel
0 configured to native-PCI, channel 1 configured to native-PCI
pciide0: using ivec 0x7cc for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 19092MB, 39102336 sectors
atapiscsi0 at pciide0 channel 0 drive 1
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: removable
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
cd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 4
pciide0: channel 1 disabled (no drives)
ppb0 at pci0 dev 5 function 0 "DEC 21152" rev 0x03
pci1 at ppb0 bus 1
machfb0 at pci0 dev 19 function 0 "ATI Rage XL" rev 0x27
machfb0: ATY,RageXL, 1280x1024
wsdisplay0 at machfb0 mux 1: console (std, sun emulation)
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 configuration 1 interface 0 "Sun OHCI root hub" rev 1.00/1.00
addr 1
dt: 451 probes
uhidev0 at uhub0 port 1 configuration 1 interface 0 "Logitech USB Receiver" rev
2.00/24.00 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd0 at ukbd0: console keyboard, using wsdisplay0
uhidev1 at uhub0 port 1 configuration 1 interface 1 "Logitech USB Receiver" rev
2.00/24.00 addr 2
uhidev1: iclass 3/1, 8 report ids
ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir
wsmouse0 at ums0 mux 0
ucc0 at uhidev1 reportid 3: 652 usages, 18 keys, array
wskbd1 at ucc0 mux 1
wskbd1: connecting to wsdisplay0
uhid0 at uhidev1 reportid 4: input=1, output=0, feature=0
uhid1 at uhidev1 reportid 8: input=1, output=0, feature=0
uhidev2 at uhub0 port 1 configuration 1 interface 2 "Logitech USB Receiver" rev
2.00/24.00 addr 2
uhidev2: iclass 3/0, 33 report ids
uhidpp0 at uhidev2 device 1 mouse "M720 Triathlon" serial c0-3f-17-e5 error
20203648
uhid2 at uhidev2 reportid 32: input=14, output=14, feature=0
uhid3 at uhidev2 reportid 33: input=31, output=31, feature=0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
bootpath: /pci@1f,0/ide@d,0/disk@0,0
root on wd0a (23db8712359b0545.a) swap on wd0b dump on wd0b
--
Ted Bullock
On 2021-12-10 12:53 a.m., Jonathan Gray wrote:
> On Thu, Dec 09, 2021 at 10:01:30PM -0700, Ted Bullock wrote:
>> Thoughts folks? This is clearly going to impact all big endian + radeon gear.
>>
>> Actually, I bet that the macppc platform has the same problem too.
>
&
On 2021-12-11 4:41 a.m., Mark Kettenis wrote:
Date: Fri, 10 Dec 2021 17:24:58 -0700
From: Ted Bullock
So the real problem is:
[drm] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD)
[drm] *ERROR* radeon: cp isn't working (-22).
drm:pid0:r100_startup *ERROR* failed initializing CP
On 2021-12-11 5:39 a.m., Mark Kettenis wrote:
>> Date: Sat, 11 Dec 2021 05:10:41 -0700
>> From: Ted Bullock
>
> The are several reasons why that test can fail though. It can be an
> endian-ness issue or on sparc64 it could also be an IOMMU issue where
> the wro
24 matches
Mail list logo
