Re: SunBlade 100: X is very yellow with XVR-100 (radeon r100)

2021-12-10 Thread 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.
> 
> sparc64 maps pci little endian, I don't think macppc does
> 
> can you try the following?

Yeah that did resolve the bios warning; X is yellow still though.

FWIW, I was worried there might be a hardware fault here so I tested on solaris
and it was working appropriately there.

Current relevant dmesg:

radeondrm0: ivec 0x7d5
machfb0 at pci0 dev 19 function 0 "ATI Rage XL" rev 0x27
machfb0: ATY,RageXL, 1152x900
wsdisplay0 at machfb0 mux 1
wsdisplay0: screen 0 added (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
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 (abe1c474.a) swap on wd0b dump on wd0b
radeondrm0: RV100
[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 (-22).
drm:pid0:r100_init *ERROR* Disabling GPU acceleration
[drm] *ERROR* Wait for CP idle timeout, shutting down CP.
Failed to wait GUI idle while programming pipes. Bad things might happen.
radeondrm0: 1280x1024, 8bpp
wsdisplay1 at radeondrm0 mux 1
wsdisplay1: screen 0 added (std, sun emulation)
Bogus possible_clones: [ENCODER:45:TMDS-45] possible_clones=0x6 (full encoder 
mask=0x7)
Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x5 (full encoder 
mask=0x7)
Bogus possible_clones: [ENCODER:48:DAC-48] possible_clones=0x3 (full encoder 
mask=0x7)




-- 
Ted Bullock 



witness with full regress

2021-12-10 Thread Alexander Bluhm
Hi,

I have turned on witness during a full regress run on amd64.  It
found two issues.  Basically I am posting this as baseline, so I
can see if things get better or worse.  If someone wants to fix
them, I can dig into the test logs to see which regress triggered
it.

bluhm

witness: lock order reversal:
 1st 0xfd8774b19310 vmmaplk (>lock)
 2nd 0xfd872022be68 inode (>i_lock)
lock order ">i_lock"(rrwlock) -> ">lock"(rwlock) first seen at:
#0  rw_enter_read+0x38
#1  uvmfault_lookup+0x8a
#2  uvm_fault_check+0x32
#3  uvm_fault+0xfc
#4  kpageflttrap+0x12b
#5  kerntrap+0x91
#6  alltraps_kern_meltdown+0x7b
#7  copyout+0x53
#8  ffs_read+0x1f6
#9  VOP_READ+0x41
#10 vn_rdwr+0xa1
#11 vmcmd_map_readvn+0xa6
#12 exec_process_vmcmds+0x84
#13 sys_execve+0x77d
#14 start_init+0x29f
#15 proc_trampoline+0x1c
lock order ">lock"(rwlock) -> ">i_lock"(rrwlock) first seen at:
#0  rw_enter+0x65
#1  rrw_enter+0x56
#2  VOP_LOCK+0x5b
#3  vn_lock+0xad
#4  uvn_io+0x1cc
#5  uvm_pager_put+0xe6
#6  uvn_flush+0x250
#7  uvm_map_clean+0x1ff
#8  syscall+0x374
#9  Xsyscall+0x128

witness: lock order reversal:
 1st 0xfd886921d8d8 vmmaplk (>lock)
 2nd 0x800022c54130 nfsnode (>n_lock)
lock order data w2 -> w1 missing
lock order ">lock"(rwlock) -> ">n_lock"(rrwlock) first seen at:
#0  rw_enter+0x65
#1  rrw_enter+0x56
#2  VOP_LOCK+0x5b
#3  vn_lock+0xad
#4  vn_rdwr+0x7f
#5  vndstrategy+0x2e6
#6  physio+0x227
#7  spec_write+0x95
#8  VOP_WRITE+0x41
#9  vn_write+0xfc
#10 dofilewritev+0x14d
#11 sys_pwrite+0x5c
#12 syscall+0x374
#13 Xsyscall+0x128