Re: [CentOS] lshw in centos 7 withdrawn

[Warren Young]

On Jan 15, 2018, at 9:10 AM, david  wrote:
> 
> - SATA3 is faster than USB3 (I think)

Almost always, yes.

> But sometimes one has no choice.

Only if you have no PCI slots, and hence can’t put a better interface into the 
system.

> The Mac pro may look cute in its black cylinder, for example, but there's no 
> place to add anything to it.

The old trashcan Mac Pro has *six* Thunderbolt 2 ports in 3 separate busses, 
running at a reliable 20 GBit/sec per bus.  Contrast USB 3.0, which might 
deliver its promised 5 Gbit/sec on a perfect bench test with uncommonly good 
cabling and other hardware, and where there’s a fair chance you have only 1 or 
2 busses per system, with the bandwidth shared among the ports on each bus.

Much of the difference in quality between USB and Thunderbolt comes from the 
fact that Thunderbolt is almost exclusively found on professional-grade 
machines, so there isn’t as much drive behind the old race to the bottom, so 
that there actually are reliable Thunderbolt cables and enclosures available, 
and the vendors of same tend not to cheap out on things like power supplies.

You won’t pay $13.64 for a Thunderbolt enclosure and cable, though.

The same is true of other professional-grade storage busses like Fibre Channel. 
 You gets what you pays for.

Contrast eSATA, which I’ve found to be about as troublesome as USB, again due 
to a race to the bottom.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] lshw in centos 7 withdrawn

[david]

Warren
Thanks for the thoughts.  Even with 'dmesg', I 
found nothing.  The reboot got rid of the problem 
and it continues to run perfectly in the same configuration.


I, too, have a slight dislike for external USB 
disks, and much prefer internal drives for esveral reasons:
- Internal drives are protected by being inside a 
tower and thus have less chance of falling or 
being bumped than free-standing external boxes

- Fewer plugs and wires
- Power-up sequencing is coordinated with CPU power
- SATA3 is faster than USB3 (I think)

But sometimes one has no choice.  The Mac pro may 
look cute in its black cylinder, for example, but 
there's no place to add anything to it.  External 
drives are the only choice that I know of.


David




At 07:57 AM 1/15/2018, Warren Young wrote:

On Jan 12, 2018, at 3:18 PM, david  wrote:
>
> Or is it related to the annoying spin-down 
and spin-up delay of external USB disks.


More likely, crap hardware, which is awfully hard to avoid in USB-land.

Just the other day, I traced a machine that 
failed to reboot to an external USB 
disk.  Unplug it, machine boots right up.  Move 
the same disk to a machine as different as can 
be — different hardware, different OS, different 
firmware… — and it kernel panic’d that box 
within about a minute of plugging it in.

in.

Then there was the time a USB enclosure ate my 
data.  Only the filesystem’s strong checksums 
saved me that time.  I moved the disk to another 
enclosure, and the bad sector writes stopped 
occurring; all else remained the same.


The problem is a market conditioned to believe 
that it should expect to pay $13.64 for an 
enclosure, power supply, and interface cable and 
get a 5-star product.  If you put a $200 
enclosure in front of the vast majority of 
members of that market, they’d either 
disbelieve the price or rate it 1 star for bad 
value, even if it was guaranteed to outlast the 
prevalence of the USB standard it supports, had 
a higher transfer rate, and had guaranteed data 
corruption rates best given in scientific 
notation with large negative exponents.


Whenever I have a machine with an unkillable 
userspace program, I run dtrace, and almost 
always get told exactly which bit of hardware 
(and therefore which kernel driver) is holding the machine hostage.


You might be able to dig the same info out of 
/var/log/messages, given close-enough timestamps.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] lshw in centos 7 withdrawn

[Warren Young]

On Jan 15, 2018, at 8:57 AM, Warren Young  wrote:
> 
> Whenever I have a machine with an unkillable userspace program, I run dtrace

Sorry, got my OS wires crossed: I mean dmesg.  Though dtrace could help, too, 
if you’ve managed to build that for CentOS; I hear it can be dnoe. :)

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] lshw in centos 7 withdrawn

[Warren Young]

On Jan 12, 2018, at 3:18 PM, david  wrote:
> 
> Or is it related to the annoying spin-down and spin-up delay of external USB 
> disks.

More likely, crap hardware, which is awfully hard to avoid in USB-land.

Just the other day, I traced a machine that failed to reboot to an external USB 
disk.  Unplug it, machine boots right up.  Move the same disk to a machine as 
different as can be — different hardware, different OS, different firmware… — 
and it kernel panic’d that box within about a minute of plugging it in.

Then there was the time a USB enclosure ate my data.  Only the filesystem’s 
strong checksums saved me that time.  I moved the disk to another enclosure, 
and the bad sector writes stopped occurring; all else remained the same.

The problem is a market conditioned to believe that it should expect to pay 
$13.64 for an enclosure, power supply, and interface cable and get a 5-star 
product.  If you put a $200 enclosure in front of the vast majority of members 
of that market, they’d either disbelieve the price or rate it 1 star for bad 
value, even if it was guaranteed to outlast the prevalence of the USB standard 
it supports, had a higher transfer rate, and had guaranteed data corruption 
rates best given in scientific notation with large negative exponents.

Whenever I have a machine with an unkillable userspace program, I run dtrace, 
and almost always get told exactly which bit of hardware (and therefore which 
kernel driver) is holding the machine hostage.

You might be able to dig the same info out of /var/log/messages, given 
close-enough timestamps.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] lshw in centos 7 withdrawn

[david]

John--
Thanks for the suggestion.  I finally had a chance to get to the 
system in question,  It was the only one of many that exhibited the 
USB hang.  I tried a reboot with the two USB disks 
disconnected.  Everything worked.  I plugged them in, and then did 
both "lsusb -v" and "lshw", and again, everything worked.


Continuing my test:
Reboot with both drives plugged in:  all worked.

Power off, wait 1 minute for everything to quiet down, power on:  all worked.

So, I can't reproduce the problem.  I guess I have to blame cosmic 
rays or those nasty gremlins that inhabit our IC's.  :-)  Or is it 
related to the annoying spin-down and spin-up delay of external USB 
disks.  I have issues with the spin-up delay on other CentOS 
platforms, and have managed to find a kludge to avoid it most of the 
time.  Windows 10 seems to handle the delay well.


Thanks for your idea.  At least it led me to "lsusb -v".

David



At 05:33 PM 1/11/2018, Stephen John Smoogen wrote:

On 11 January 2018 at 20:23, david  wrote:
> Folks
>
> I've been running lshw for years in both Centos 6 and Centos 7, yet just
> recently it started hanging.  Neither a Control^C nor a "kill" of the
> process cured the hang; only a reboot.
>

Is this just one system or a range of boxes? I just ran it on 2
different ones running CentOS 7 and it worked fine there. If it is
just one particular hardware then look through the lshw man page and
try the versions of something like

lshw -disable usb

to see if it still happens. [It might require other tests also.]


> When I run it by hand from the command line, it displays stuff on the next
> line overwriting it with things like PCI, USB.  And USB is the last thing I
> see.  A Control-C does not unlock it.
>
> I am running lshw-B.02.18-7.el7.x86_64.  The CPU is an Intel I7-3770K,
> running CentOS 7.4.1708
>
> Is there any idea? Is there some alternate program that could list the
> hardware?
>
> Thanks
>
> David
>





___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] lshw in centos 7

[James Pearson]

Stephen John Smoogen wrote:
> 
> On 11 January 2018 at 20:23, david  wrote:
>> Folks
>>
>> I've been running lshw for years in both Centos 6 and Centos 7, yet just
>> recently it started hanging.  Neither a Control^C nor a "kill" of the
>> process cured the hang; only a reboot.
>>
> 
> Is this just one system or a range of boxes? I just ran it on 2
> different ones running CentOS 7 and it worked fine there. If it is
> just one particular hardware then look through the lshw man page and
> try the versions of something like
> 
> lshw -disable usb
> 
> to see if it still happens. [It might require other tests also.]

You could also try running it via strace - it might give you a clue as 
to where it is hanging :

  strace -f lshw

James Pearson
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] lshw in centos 7

[Stephen John Smoogen]

On 11 January 2018 at 20:23, david  wrote:
> Folks
>
> I've been running lshw for years in both Centos 6 and Centos 7, yet just
> recently it started hanging.  Neither a Control^C nor a "kill" of the
> process cured the hang; only a reboot.
>

Is this just one system or a range of boxes? I just ran it on 2
different ones running CentOS 7 and it worked fine there. If it is
just one particular hardware then look through the lshw man page and
try the versions of something like

lshw -disable usb

to see if it still happens. [It might require other tests also.]


> When I run it by hand from the command line, it displays stuff on the next
> line overwriting it with things like PCI, USB.  And USB is the last thing I
> see.  A Control-C does not unlock it.
>
> I am running lshw-B.02.18-7.el7.x86_64.  The CPU is an Intel I7-3770K,
> running CentOS 7.4.1708
>
> Is there any idea? Is there some alternate program that could list the
> hardware?
>
> Thanks
>
> David
>
>
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos



-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos