Re: [OpenIndiana-discuss] How is this possible? (Solved]

2021-05-05 Thread Gerard Arthus 
Good points here.

Best wishes,

Gerry

Gerard Arthus
409 Lowell Avenue East
Mishawaka, Indiana
United States
46545
Cell - 574-302-7731
Home - 574-520-1337 <574-217-8726>

Instructor ITT-Tech - Mathematics, Electrical Engineering, and Computer
Engineering.

garthus...@gmail.com
Notary The State of Indiana #685426
http://www.OpenEducation.org
http://openeducation.org/moodle/  (For Course Portal) Log In as Guest
http://www.linkedin.com/profile/edit?trk=tab_pro
http://www.facebook.com/gerard.arthus
https://archive.org/details/arthusgerardphilosophicalwritings (Philosophical
Discussions)
https://archive.org/details/arthusgerardpoems (Poems)
https://archive.org/details/arthusgerardzoe?sort=titleSorter (Zoe Book)
https://archive.org/details/@garthus1=collections (Gerard Arthus
Collections Page)
https://archive.org/details/arthusgerardhack

(Hacking The World)
https://archive.org/details/arthusgerardmedical=about
(Medical Records)
https://archive.org/details/arthusgerardrec=collection
(Musical Recordings)

https://archive.org/details/arthusgerardpackagingandinstructionmanuals
(Packaging
Collection)
https://archive.org/details/@garthus1=uploads  (All Items Uploaded to
Date)
https://archive.org/details/What_Have_We_Wrought_ (Selected Poem)
https://archive.org/details/A_World_Where_We_Consume_Our_Hearts_ (Selected
Poem)
https://archive.org/details/Here_There_Is_No_Lesson_To_Be_Learned_ (Selected
Poem)
https://archive.org/details/Deception_And_The_Self_Created_Terrorist_Threat_American_Complicity_In_World_W
(Selected
Poem)
https://archive.org/details/Solitary_Horsemen_Reflections_On_Life_In_Cyberspace
(Selected
Poem)


On Wed, May 5, 2021 at 5:00 PM Lou Picciano  wrote:

> Gentlemen:
>
> This conversation is interesting from a number of perspectives, and none
> of them related to OI (in my case, though they could be at some point…)
>
> Comments about bad sync connections, lousy DVI adapters, etc. got my ears
> perked up. With kids forced back home last year, I’d rarely done so much
> intensive build/install/re-configure cycles in recent memory. Decided to do
> all this on an ‘easy(?)’, bullet-proof, well-tested(?) OS. Yup, Ubuntu*.
> Well, turns out Ubuntu is not quite so bullet-proof. And, among the
> problems which included variable boot results, weird boot loader setup,
> crazy confusion about latest Wifi hardware, etc. were the worst of all:
> those related to VIDEO cards and adapters. biggest single symptom was a
> frequent complete inability for the video adapter to ’sense’ the monitor
> resolution(s).
>
> Real pain in the ass.
>
> Always productive here, even if sometimes in serendipitous ways.
>
> * (I avoid MS like The Black Death.)
>
> > On Apr 16, 2021, at 6:50 PM, Reginald Beardsley via openindiana-discuss <
> openindiana-discuss@openindiana.org> wrote:
> >
> > To summarize:
> >
> > I swapped PSUs and graphics cards including putting the card from #3 in
> #4
> >
> > I booted from the 2020.10 hard disk and Live Image
> >
> > I swapped the KVM cables and ports
> >
> > I tried the other PCIe slot that will take the graphics card.
> >
> > I put a scope on the 5 V and 12 V rails.
> >
> > After all that agony I finally tracked it down. A couple of junk DVI-VGA
> adapters! Somehow in my search for the cause of the kernel panics I failed
> to notice that the display resolution was wrong when I was running 2020.10
> in #4
> >
> > After all this I'm exhausted. But I've never lost a battle with a piece
> of computer HW and was not about to start. I'd like to shoot these, but
> that would require more trouble than they are worth. So I am going to crush
> them with a 20 ton hydraulic press. If there were someone I disliked
> enough, I'd give them away.
> >
> > The moral of this sad tale is, "Don't put untested parts in your spares
> bin!" I bought these to have some spares on hand, but did not test them
> when i received them. They were still in the bags. I damaged my old one for
> #4 while shifting HW.
> >
> > Unfortunately, I still have the kernel panics to deal with :-(
> >
> > Reg
> > ___
> > openindiana-discuss mailing list
> > openindiana-discuss@openindiana.org
> > https://openindiana.org/mailman/listinfo/openindiana-discuss
>
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How is this possible? (Solved]

2021-05-05 Thread Lou Picciano 
Gentlemen:

This conversation is interesting from a number of perspectives, and none of 
them related to OI (in my case, though they could be at some point…)

Comments about bad sync connections, lousy DVI adapters, etc. got my ears 
perked up. With kids forced back home last year, I’d rarely done so much 
intensive build/install/re-configure cycles in recent memory. Decided to do all 
this on an ‘easy(?)’, bullet-proof, well-tested(?) OS. Yup, Ubuntu*. Well, 
turns out Ubuntu is not quite so bullet-proof. And, among the problems which 
included variable boot results, weird boot loader setup, crazy confusion about 
latest Wifi hardware, etc. were the worst of all: those related to VIDEO cards 
and adapters. biggest single symptom was a frequent complete inability for the 
video adapter to ’sense’ the monitor resolution(s).

Real pain in the ass.

Always productive here, even if sometimes in serendipitous ways.

* (I avoid MS like The Black Death.) 

> On Apr 16, 2021, at 6:50 PM, Reginald Beardsley via openindiana-discuss 
>  wrote:
> 
> To summarize:
> 
> I swapped PSUs and graphics cards including putting the card from #3 in #4
> 
> I booted from the 2020.10 hard disk and Live Image
> 
> I swapped the KVM cables and ports
> 
> I tried the other PCIe slot that will take the graphics card. 
> 
> I put a scope on the 5 V and 12 V rails.
> 
> After all that agony I finally tracked it down. A couple of junk DVI-VGA 
> adapters! Somehow in my search for the cause of the kernel panics I failed to 
> notice that the display resolution was wrong when I was running 2020.10 in #4
> 
> After all this I'm exhausted. But I've never lost a battle with a piece of 
> computer HW and was not about to start. I'd like to shoot these, but that 
> would require more trouble than they are worth. So I am going to crush them 
> with a 20 ton hydraulic press. If there were someone I disliked enough, I'd 
> give them away.
> 
> The moral of this sad tale is, "Don't put untested parts in your spares bin!" 
> I bought these to have some spares on hand, but did not test them when i 
> received them. They were still in the bags. I damaged my old one for #4 while 
> shifting HW.
> 
> Unfortunately, I still have the kernel panics to deal with :-( 
> 
> Reg  
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How is this possible? (Solved]

2021-04-16 Thread Reginald Beardsley via openindiana-discuss 
 To summarize:

I swapped PSUs and graphics cards including putting the card from #3 in #4

I booted from the 2020.10 hard disk and Live Image

I swapped the KVM cables and ports

I tried the other PCIe slot that will take the graphics card. 

I put a scope on the 5 V and 12 V rails.

After all that agony I finally tracked it down. A couple of junk DVI-VGA 
adapters! Somehow in my search for the cause of the kernel panics I failed to 
notice that the display resolution was wrong when I was running 2020.10 in #4

After all this I'm exhausted. But I've never lost a battle with a piece of 
computer HW and was not about to start. I'd like to shoot these, but that would 
require more trouble than they are worth. So I am going to crush them with a 20 
ton hydraulic press. If there were someone I disliked enough, I'd give them 
away.

The moral of this sad tale is, "Don't put untested parts in your spares bin!" I 
bought these to have some spares on hand, but did not test them when i received 
them. They were still in the bags. I damaged my old one for #4 while shifting 
HW.

Unfortunately, I still have the kernel panics to deal with :-( 

Reg  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How is this possible?

2021-04-16 Thread Chris 

On 2021-04-16 11:38, Reginald Beardsley via openindiana-discuss wrote:
I have a pair of almost identical Z400s. (In total I have 4.) One has 4x 2 
GB
DIMMs (#3)  and the other has 2x 8 GB DIMMs (#4) .  Both have Quadro FX 1800 
cards
and trayless SATA bays.  Both are connected to the monitor through an 8 port 
KVM

switch.

Hipster 2020.10 was installed on system #3.  The monitor was recognized and
configured properly as 1600x1200 using the 340.108 driver.   If I move the 
disk to
#4 the nVIDIA driver didn't recognize the monitor or the resolution, set 
1024x768

and would not allow me to set it to 1600x1200.

I  moved the KVM switch port for #4  to #3 and rebooted 2020.10 on #3.  It 
behaves

as expected, recognizes the Samsung Monitor and the correct resolution.

After I installed the 2x 8 GB DIMMs S10 u8 kernel panicked on a null pointer
dereference, so I moved the 2020.10 disk to system #4 and ran it for several 
days
to see if fmd would log ECC errors on the DIMMs.  fmdump -eV reports the log 
file
is empty after 3 days.  I don't know what whether fmd in u8 logs ECC errors 
as
I've never seen any, though I have seen occasional ECC errors on system #2 
which

is running 2017.10

This morning  I put the S10 u8 disks back in the system, booted and started 
scrubs
at which point it immediately kernel panicked.  I rebooted in single user 
mode.
Both the root pool 3 way mirror and the RAIDZ1 export pool scrubs completed 
with

no errors.

The 3 disks forming the 2 pools were in a 6 DIMM slot Z400 (#1).  That MB 
appears

to have a failing SATA controller as it logged so many sector R/W errors it
rebooted.  I replaced the suspect disk with a new drive of the same make, 
model

and vintage.  The errors continued so I switched the  u8 disks to #4.  A
subsequent test of the drive that was reported bad showed no errors after a 
4 hr

scan using the BIOS test.

After verifying that 2020.10 worked properly in #3, I moved the disk back to 
#4.
This time it came up at 960x540!  I changed out the video with the card from 
#1

and again it came up in 960x540. I then moved the video card from #3 to #4.
Again, 960x540.  I reset the BIOS to factory defaults, changed the things 
(e.g

AHCI) I knew had to be changed.  Again.  Same behavior.

If I boot the 2020.10 Live Image on #3 it's 1600x1200.  On #4 it's 1024x768. 
 I

tried the video card in the other PCIe slot.  Same result.

I'm completely baffled.I've never seen anything like this.
Cables? IOW if it is working on one but not others. I'd hazard a guess that 
the

system isn't receiving the EDID from the monitor through the KVM. Some KVMs
can be a problem that way by not providing enough of the power to the 
connections.

Other times (often) (cheap) cables are missing the "sync" wire. In any case,
I'd first start by swapping the cable from the working machine to the port
on the "different" machine and see if that doesn't solve it -- it's the 
fastest
and easiest first step. OTOH If the machine that OI was setup on provides 
video
on a different port than the machine your swapping to. That too may be a 
factor.

In any case; w/o any log output. This is all I feel safe offering. ;-)

HTH

--Chris



Reg

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


--

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How is this possible?

2021-04-16 Thread Jacob Ritorto 
Oh but you switched video card into the offending chassis and got same bad
behaviour!!
Shoot sorry, missed that.  Same EFI / BIOS level on both motherboards?

On Fri, Apr 16, 2021 at 2:49 PM Jacob Ritorto 
wrote:

> Off the cuff guess: differing video card firmware.  My kid's crappy linux
> PC had lingering (despite full blow-away-the-whole-disk reinstall) weird
> settings that harassed us for months until I found a more severe reset
> (different OS), which I presume included fw, but things are so candy-coated
> these days with gui installs and hidden antics that it wasn't even clear
> how / why it worked.  A very microsoft-esque experience, to say it the most
> polite way possible.
>
> On Fri, Apr 16, 2021 at 2:38 PM Reginald Beardsley via openindiana-discuss
>  wrote:
>
>> I have a pair of almost identical Z400s. (In total I have 4.) One has 4x
>> 2 GB DIMMs (#3)  and the other has 2x 8 GB DIMMs (#4) .  Both have Quadro
>> FX 1800 cards and trayless SATA bays.  Both are connected to the monitor
>> through an 8 port KVM switch.
>>
>> Hipster 2020.10 was installed on system #3.  The monitor was recognized
>> and configured properly as 1600x1200 using the 340.108 driver.   If I move
>> the disk to #4 the nVIDIA driver didn't recognize the monitor or the
>> resolution, set 1024x768 and would not allow me to set it to 1600x1200.
>>
>> I  moved the KVM switch port for #4  to #3 and rebooted 2020.10 on #3.
>> It behaves as expected, recognizes the Samsung Monitor and the correct
>> resolution.
>>
>> After I installed the 2x 8 GB DIMMs S10 u8 kernel panicked on a null
>> pointer dereference, so I moved the 2020.10 disk to system #4 and ran it
>> for several days to see if fmd would log ECC errors on the DIMMs.  fmdump
>> -eV reports the log file is empty after 3 days.  I don't know what whether
>> fmd in u8 logs ECC errors as I've never seen any, though I have seen
>> occasional ECC errors on system #2 which is running 2017.10
>>
>> This morning  I put the S10 u8 disks back in the system, booted and
>> started scrubs at which point it immediately kernel panicked.  I rebooted
>> in single user mode.  Both the root pool 3 way mirror and the RAIDZ1 export
>> pool scrubs completed with no errors.
>>
>> The 3 disks forming the 2 pools were in a 6 DIMM slot Z400 (#1).  That MB
>> appears to have a failing SATA controller as it logged so many sector R/W
>> errors it rebooted.  I replaced the suspect disk with a new drive of the
>> same make, model and vintage.  The errors continued so I switched the  u8
>> disks to #4.  A subsequent test of the drive that was reported bad showed
>> no errors after a 4 hr scan using the BIOS test.
>>
>> After verifying that 2020.10 worked properly in #3, I moved the disk back
>> to #4.  This time it came up at 960x540!  I changed out the video with the
>> card from #1 and again it came up in 960x540. I then moved the video card
>> from #3 to #4.  Again, 960x540.  I reset the BIOS to factory defaults,
>> changed the things (e.g AHCI) I knew had to be changed.  Again.  Same
>> behavior.
>>
>> If I boot the 2020.10 Live Image on #3 it's 1600x1200.  On #4 it's
>> 1024x768.  I tried the video card in the other PCIe slot.  Same result.
>>
>> I'm completely baffled.I've never seen anything like this.
>>
>> Reg
>>
>> ___
>> openindiana-discuss mailing list
>> openindiana-discuss@openindiana.org
>> https://openindiana.org/mailman/listinfo/openindiana-discuss
>>
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How is this possible?

2021-04-16 Thread Jacob Ritorto 
Off the cuff guess: differing video card firmware.  My kid's crappy linux
PC had lingering (despite full blow-away-the-whole-disk reinstall) weird
settings that harassed us for months until I found a more severe reset
(different OS), which I presume included fw, but things are so candy-coated
these days with gui installs and hidden antics that it wasn't even clear
how / why it worked.  A very microsoft-esque experience, to say it the most
polite way possible.

On Fri, Apr 16, 2021 at 2:38 PM Reginald Beardsley via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:

> I have a pair of almost identical Z400s. (In total I have 4.) One has 4x 2
> GB DIMMs (#3)  and the other has 2x 8 GB DIMMs (#4) .  Both have Quadro FX
> 1800 cards and trayless SATA bays.  Both are connected to the monitor
> through an 8 port KVM switch.
>
> Hipster 2020.10 was installed on system #3.  The monitor was recognized
> and configured properly as 1600x1200 using the 340.108 driver.   If I move
> the disk to #4 the nVIDIA driver didn't recognize the monitor or the
> resolution, set 1024x768 and would not allow me to set it to 1600x1200.
>
> I  moved the KVM switch port for #4  to #3 and rebooted 2020.10 on #3.  It
> behaves as expected, recognizes the Samsung Monitor and the correct
> resolution.
>
> After I installed the 2x 8 GB DIMMs S10 u8 kernel panicked on a null
> pointer dereference, so I moved the 2020.10 disk to system #4 and ran it
> for several days to see if fmd would log ECC errors on the DIMMs.  fmdump
> -eV reports the log file is empty after 3 days.  I don't know what whether
> fmd in u8 logs ECC errors as I've never seen any, though I have seen
> occasional ECC errors on system #2 which is running 2017.10
>
> This morning  I put the S10 u8 disks back in the system, booted and
> started scrubs at which point it immediately kernel panicked.  I rebooted
> in single user mode.  Both the root pool 3 way mirror and the RAIDZ1 export
> pool scrubs completed with no errors.
>
> The 3 disks forming the 2 pools were in a 6 DIMM slot Z400 (#1).  That MB
> appears to have a failing SATA controller as it logged so many sector R/W
> errors it rebooted.  I replaced the suspect disk with a new drive of the
> same make, model and vintage.  The errors continued so I switched the  u8
> disks to #4.  A subsequent test of the drive that was reported bad showed
> no errors after a 4 hr scan using the BIOS test.
>
> After verifying that 2020.10 worked properly in #3, I moved the disk back
> to #4.  This time it came up at 960x540!  I changed out the video with the
> card from #1 and again it came up in 960x540. I then moved the video card
> from #3 to #4.  Again, 960x540.  I reset the BIOS to factory defaults,
> changed the things (e.g AHCI) I knew had to be changed.  Again.  Same
> behavior.
>
> If I boot the 2020.10 Live Image on #3 it's 1600x1200.  On #4 it's
> 1024x768.  I tried the video card in the other PCIe slot.  Same result.
>
> I'm completely baffled.I've never seen anything like this.
>
> Reg
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

[OpenIndiana-discuss] How is this possible?

2021-04-16 Thread Reginald Beardsley via openindiana-discuss 
I have a pair of almost identical Z400s. (In total I have 4.) One has 4x 2 GB 
DIMMs (#3)  and the other has 2x 8 GB DIMMs (#4) .  Both have Quadro FX 1800 
cards and trayless SATA bays.  Both are connected to the monitor through an 8 
port KVM switch.

Hipster 2020.10 was installed on system #3.  The monitor was recognized and 
configured properly as 1600x1200 using the 340.108 driver.   If I move the disk 
to #4 the nVIDIA driver didn't recognize the monitor or the resolution, set 
1024x768 and would not allow me to set it to 1600x1200.

I  moved the KVM switch port for #4  to #3 and rebooted 2020.10 on #3.  It 
behaves as expected, recognizes the Samsung Monitor and the correct resolution.

After I installed the 2x 8 GB DIMMs S10 u8 kernel panicked on a null pointer 
dereference, so I moved the 2020.10 disk to system #4 and ran it for several 
days to see if fmd would log ECC errors on the DIMMs.  fmdump -eV reports the 
log file is empty after 3 days.  I don't know what whether fmd in u8 logs ECC 
errors as I've never seen any, though I have seen occasional ECC errors on 
system #2 which is running 2017.10

This morning  I put the S10 u8 disks back in the system, booted and started 
scrubs at which point it immediately kernel panicked.  I rebooted in single 
user mode.  Both the root pool 3 way mirror and the RAIDZ1 export pool scrubs 
completed with no errors.

The 3 disks forming the 2 pools were in a 6 DIMM slot Z400 (#1).  That MB 
appears to have a failing SATA controller as it logged so many sector R/W 
errors it rebooted.  I replaced the suspect disk with a new drive of the same 
make, model and vintage.  The errors continued so I switched the  u8 disks to 
#4.  A subsequent test of the drive that was reported bad showed no errors 
after a 4 hr scan using the BIOS test.

After verifying that 2020.10 worked properly in #3, I moved the disk back to 
#4.  This time it came up at 960x540!  I changed out the video with the card 
from #1 and again it came up in 960x540. I then moved the video card from #3 to 
#4.  Again, 960x540.  I reset the BIOS to factory defaults, changed the things 
(e.g AHCI) I knew had to be changed.  Again.  Same behavior.

If I boot the 2020.10 Live Image on #3 it's 1600x1200.  On #4 it's 1024x768.  I 
tried the video card in the other PCIe slot.  Same result.

I'm completely baffled.I've never seen anything like this.

Reg

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How is this possible?

2021-04-06 Thread Reginald Beardsley via openindiana-discuss 
 
I'd been working on a script to reformat disk error messages from 
/var/adm/messages to the logical device name and had done a "devfsadm -C -c 
disk" with the scratch pool disk out of the system. Naturally when I put it 
back in, the system couldn't find it.

At this point it is unclear if the MB, cage or both are bad. The current 
configuration only has the disks from the original system installed. Everything 
else has been replaced.

It's possible that the replacement disk is bad. It had been sitting unopened 
for 4 years, but that doesn't guarantee it's good. I'm testing the disk I 
pulled just in case it's OK and the problem was the cage or MB.

Reg

 On Monday, April 5, 2021, 06:55:48 PM CDT, Reginald Beardsley 
 wrote:  
 
 If I come up in single user mode aka "fail safe", I can see all 3 system pools 
and import them.  Two don't mount  properly because / is read only, but I can 
scrub them all without any problems.  I suppose -R would fix that, but it 
really didn't seem important.  I just wanted to scrub the pools.

But when I boot multiuser I can't find one of the 3 pools. "zpool import" 
doesn't report it and "zpool -f import spool" produces a "no such pool" message.

I've been swapping hardware a good bit, but this is beyond weird.

I keep looking to see if Rod Serling is standing near by smoking a cigarette.

Reg
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

[OpenIndiana-discuss] How is this possible?

2021-04-05 Thread Reginald Beardsley via openindiana-discuss 
If I come up in single user mode aka "fail safe", I can see all 3 system pools 
and import them.  Two don't mount  properly because / is read only, but I can 
scrub them all without any problems.  I suppose -R would fix that, but it 
really didn't seem important.  I just wanted to scrub the pools.

But when I boot multiuser I can't find one of the 3 pools. "zpool import" 
doesn't report it and "zpool -f import spool" produces a "no such pool" message.

I've been swapping hardware a good bit, but this is beyond weird.

I keep looking to see if Rod Serling is standing near by smoking a cigarette.

Reg

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss