Re: [gentoo-user] Re: Heads up: A reason *NOT* to have xorg.conf file
On 170402-20:52+0300, Nikos Chantziaras wrote: ... > xorg.conf. Instead, I have an xorg.conf.d/nvidia.conf file: > >https://pastebin.com/raw/0GsxaFRj > Why not add those 30-something lines in an attachment, or straight into the body of the message? The paste don't last really, and then when people read on the web, how do they understand? It was already pointed out by others on this mailing list. And esp. this one is just 28 lines ... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" Option "TripleBuffer" "True" Option "NoLogo" "True" Option "DynamicTwinView" "False" EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor"XG2703-GS" DefaultDepth 24 Option "UseEdidFreqs" "TRUE" Option "TwinView" "0" SubSection "Display" Depth 24 EndSubSection EndSection Section "ServerFlags" Option "BlankTime" "0" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0" EndSection =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Regards! -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr signature.asc Description: Digital signature
Re: [gentoo-user] Re: Firefox occasionally stalls
Alan McKinnon wrote: > > I got fed up dealing with Firefox addons, so took the alternate route I > used about every 6 months or so: > > emerge -et world > > and everything is nice and stable now after 48 hours running. I actually > suspect an intel driver/mesa problem as I would often also get visual > artifacts, plasma flashing the panel in odd ways and other stuff, often > co-incident with Firefox just stalling. It was recalling that Firefox > does some sophisticated accelaration that prompted me to try this. > > I think you can turn that acceleration off in the settings. I have to admit tho, I've had that emerge -e world fix some weird problems as well. I think sometimes there is a mismatch somewhere that emerge and friends just can't detect. Dale :-) :-)
Re: [gentoo-user] eclean-pkg strips everything out
Peter Humphrey wrote: > > Hello list, > > > > Has anyone else noticed that running "eclean-pkg -d" removes all > packages, or nearly so? I've had it happen recently on a few amd64 > systems and an x86 system, and it's becoming annoying. Well, no, > actually it's long since become annoying. > > > > -- > > Regards > > Peter > > > If it is removing to much, leave out the -d option. With -d, it only leaves the minimum needed to re-emerge the packages currently installed. It works the same way with -dist as well. From the man page: -d, --deeponly keep the minimum for a reinstallation I think if you leave off the -d option it leaves anything that is still in the tree, may include overlays as well. Dale :-) :-)
Re: [gentoo-user] Re: Heads up: A reason *NOT* to have xorg.conf file
Neil Bothwick wrote: > On Tue, 4 Apr 2017 16:45:07 -0500, Dale wrote: > >> Until I do >> that, I won't know if I need a xorg file or just a couple files in >> xorg.conf.d or something else. That also is not to mention that I have >> no idea what needs to go into those new files at this time, if anything >> is needed. > The files in xorg.conf.d are just xorg.conf split up into manageable > chunks. It's analogous to having /etc/portage/package.use as a file or a > directory. > > That helps. At least I know if I have a mouse problem, I can copy the mouse section into its file and fix that. I sort of figured it would be something like that but wasn't sure. Knowing helps. One thing I would like to do, set up my monitor and TV properly. I'd like my TV to work separate from my monitor. I'm pretty sure I can do that with the video card I have. I use the DB15HD output for my monitor and the HDMI for my TV. I read somewhere that the card can drive each independently. In other words, one can have one picture and the other something else. I'd like to have smplayer go to the TV and my desktop be, well, what it is now. Maybe one of these days I'll get around to working on this stuff. Right now, I'm cutting trees, planting tree seeds, and planting garden stuff and building beds for the garden. Not to mention, there's always a friend needing something. Thanks for the info. Dale :-) :-)
[gentoo-user] eclean-pkg strips everything out
Hello list, Has anyone else noticed that running "eclean-pkg -d" removes all packages, or nearly so? I've had it happen recently on a few amd64 systems and an x86 system, and it's becoming annoying. Well, no, actually it's long since become annoying. -- Regards Peter
[gentoo-user] Re: soliciting a DHCP lease / carrier lost
Am Tue, 4 Apr 2017 15:05:57 -0700 schrieb Daniel Frey : > On 04/04/2017 02:49 PM, Kai Krakow wrote: > > No, if you have the same wrong on both sides, the LEDs will still > > show correct blinking order. Think of it like this: If you use order > > 7-5-3-1-2-4-6-8 on both sides, blinking LED 1 on one side will blink > > the same LED on the other side because they both connect to wire 7. > > But the twisted pairs that should be twisted are no longer because > > now you connected pair 1 in the connector to wire 7 and 5 which > > belong to different pairs in the wire. The wire twists pair (7,8) > > and (4,5). On the long run, interference now cannot be canceled out > > because this only works if wires are twisted in the same pair. The > > connector (and ethernet standard) expects the following pairs on > > the connector: > > > > A-A-B-C-C-B-D-D > > 1-2-3-4-5-6-7-8 > > > > For electrical reasons it also expects a white wire alternating > > with a colored pair, which makes the following pairs: > > > > A = (1,2) > > B = (3,6) > > C = (5,4) > > D = (7,8) > > > > Or: > > > > A-a B c-C b D-d > > ^_^ > > > > With the capital letters being either all white or all colored (this > > doesn't depend as long as it's the same on both sides). > > > > You could open the problematic wall outlets and check the cabling > > yourself. Keep in mind that unmounting the wall outlet may make the > > problem of bent cables even worse due to moving and bending the > > wires even more. > > I'll pitch in one interesting thing of note: the local supplier here > went with el-cheapo Chinese made punch down and crimp ends some years > ago. These are supposed to be 22 AWG wire size, but after dealing with > bad connections I found out these Chinese punch downs were more like > 24-26 AWG, meaning when punched down it would not make proper contact > with the properly spec'ed wire. That's a good note. I think punch down is similar to LSA plus here in Germany, tho the tools look very different. But with LSA you also push the wire between to cutting contacts. -- Regards, Kai Replies to list-only preferred.
Re: [gentoo-user] Re: soliciting a DHCP lease / carrier lost
On 04/04/2017 02:49 PM, Kai Krakow wrote: > No, if you have the same wrong on both sides, the LEDs will still show > correct blinking order. Think of it like this: If you use order > 7-5-3-1-2-4-6-8 on both sides, blinking LED 1 on one side will blink > the same LED on the other side because they both connect to wire 7. But > the twisted pairs that should be twisted are no longer because now you > connected pair 1 in the connector to wire 7 and 5 which belong to > different pairs in the wire. The wire twists pair (7,8) and (4,5). On > the long run, interference now cannot be canceled out because this > only works if wires are twisted in the same pair. The connector (and > ethernet standard) expects the following pairs on the connector: > > A-A-B-C-C-B-D-D > 1-2-3-4-5-6-7-8 > > For electrical reasons it also expects a white wire alternating with a > colored pair, which makes the following pairs: > > A = (1,2) > B = (3,6) > C = (5,4) > D = (7,8) > > Or: > > A-a B c-C b D-d > ^_^ > > With the capital letters being either all white or all colored (this > doesn't depend as long as it's the same on both sides). > > You could open the problematic wall outlets and check the cabling > yourself. Keep in mind that unmounting the wall outlet may make the > problem of bent cables even worse due to moving and bending the wires > even more. I'll pitch in one interesting thing of note: the local supplier here went with el-cheapo Chinese made punch down and crimp ends some years ago. These are supposed to be 22 AWG wire size, but after dealing with bad connections I found out these Chinese punch downs were more like 24-26 AWG, meaning when punched down it would not make proper contact with the properly spec'ed wire. Dan
Re: [gentoo-user] Re: Heads up: A reason *NOT* to have xorg.conf file
On Tue, 4 Apr 2017 16:45:07 -0500, Dale wrote: > Until I do > that, I won't know if I need a xorg file or just a couple files in > xorg.conf.d or something else. That also is not to mention that I have > no idea what needs to go into those new files at this time, if anything > is needed. The files in xorg.conf.d are just xorg.conf split up into manageable chunks. It's analogous to having /etc/portage/package.use as a file or a directory. -- Neil Bothwick Windows '96 artificial intelligence: Unable to FORMAT A: Having a go at C: pgpDeUb45O6_O.pgp Description: OpenPGP digital signature
[gentoo-user] Re: soliciting a DHCP lease / carrier lost
Am Tue, 4 Apr 2017 15:05:13 -0600 schrieb the...@sys-concept.com: > On 04/04/2017 02:56 PM, Kai Krakow wrote: > > Am Tue, 4 Apr 2017 14:28:23 -0600 > > schrieb the...@sys-concept.com: > > > [snip] > >> > >> I have reconnected another cable and the unit in remote location > >> works. Both cable have a good pinout but one is working and the > >> other is not. Both cable are sunning inside wall (I presume same > >> path). Without special tools/testing equipment it is hard to trace > >> these problems. > > > > You could try the problematic cable with only 100 MBit. If this > > works, I'm pretty sure that some of the wires are broken or have > > incorrect order. Keep in mind, tho, that the inverse assumption of > > such tests is not true. > > Yes, the testing took was cheap it came with the stripper. > Though, if the cable order was wrong, wouldn't the light on the tester > jump in different order? The light on the tester lights up > sequentially, so I assume the order is correct. Besides that "bad" > cable was working OK for a day. No, if you have the same wrong on both sides, the LEDs will still show correct blinking order. Think of it like this: If you use order 7-5-3-1-2-4-6-8 on both sides, blinking LED 1 on one side will blink the same LED on the other side because they both connect to wire 7. But the twisted pairs that should be twisted are no longer because now you connected pair 1 in the connector to wire 7 and 5 which belong to different pairs in the wire. The wire twists pair (7,8) and (4,5). On the long run, interference now cannot be canceled out because this only works if wires are twisted in the same pair. The connector (and ethernet standard) expects the following pairs on the connector: A-A-B-C-C-B-D-D 1-2-3-4-5-6-7-8 For electrical reasons it also expects a white wire alternating with a colored pair, which makes the following pairs: A = (1,2) B = (3,6) C = (5,4) D = (7,8) Or: A-a B c-C b D-d ^_^ With the capital letters being either all white or all colored (this doesn't depend as long as it's the same on both sides). You could open the problematic wall outlets and check the cabling yourself. Keep in mind that unmounting the wall outlet may make the problem of bent cables even worse due to moving and bending the wires even more. Usually, the company that installed the cabling should've done a frequency spectrum test on each wire pair. If you didn't get it you should ask for it. In my company, we deny any network problems of our delivered equipment unless such a test has been done and presented to us. Such a test may cost a few extra bucks but should be part of such an installation (done by the electrician before handling the project over to its customer). Depending on the inside of the RJ45 wall outlet, you can fix it yourself. For the cheaper LSA based internal connectors you need an LSA tool (it's inexpensive). Don't try to use a screw driver to mount the wires. The more expensive modular connectors are easy to mount: Just insert the wire pairs properly into the holes, properly and cleanly cut the wires off the other end, and push the connector module in place (take care of proper alignment). The modular connectors also properly connect shielding, so properly connect that. Usually those connectors come with a small manual how to do it. Order new ones, don't reuse. Cut off 1-2 inches from the old connector cabling. At least in Germany I know those two kinds of connector outlets. > And yes, the room the cable is passing by has all kind or x-ray > machine. There's definitely problems with x-ray machines. Usually, those are connected by fiber optics (at least dental x-ray machines). You want to find a separate cabling way for your network, and also ensure that the power circuits are different between those machines and your network equipment. Ensure that shielding is properly passed along the complete cabling, including the patch cable from the wall outlet to your machine. Proper shielding is essential in such environments. We had one issue at a company running cooling generators and having unstable network. It was eventually resolved somehow but we think that the generators induced some non-harmonic distortion into the cabling of the complete building. I think it was resolved when they rechecked proper shielding on all cabling and machines. > I'll try to test it 100Mbit (limit the speed); just need to find out > how. Maybe this can be done with ethtool. -- Regards, Kai Replies to list-only preferred.
Re: [gentoo-user] Ryzen initial results.
On 04/04/2017 10:37 PM, Alan Grimes wrote: > I installed my Ryzen system today, using a mATX b350 mobo. > > My existing kernel mostly works, > > > > .00] Linux version 4.6.7 (root@tortoise) (gcc version 5.4.0 (Gentoo > 5.4.0-r3 p1.3, pie-0.6.5) ) #6 SMP Tue Apr 4 22:34:38 EDT 2017 >From what I've been reading, Ryzen support wasn't added until 4.10, with partial support in 4.9. So you probably won't get everything out of your new hardware. I am using 4.9.16 on my laptop with binary nvidia drivers, I haven't had issues yet. Although, it is one of those dual-gpu models, intel and nvidia - but the nvidia kernel module loads with no erroneous messages. If you have bleeding edge hardware you really need to use a newer kernel for proper support. I didn't even try my new laptop with an old kernel (most of my other machines are on 4.1 LTS still.) Dan
Re: [gentoo-user] Re: Heads up: A reason *NOT* to have xorg.conf file
Nikos Chantziaras wrote: > On 04/02/2017 07:35 AM, Dale wrote: >> Nikos Chantziaras wrote: >>> On 04/02/2017 06:55 AM, Walter Dnes wrote: My best guess is that the problem was due to a recent update to x11-base/xorg-server On both my systems it now requires USE="glamor". This may require changes to xorg.conf. On my main desktop, with no xorg.conf, X does the detection and configuration "auto-magically". The hot backup machine would have an old xorg.conf with old (i.e. wrong) settings for the updated xorg-server. >>> >>> This has been the case for many years now. Anyway, better late than >>> never :-P >>> >>> You do sometimes need some custom settings though. This goes in >>> seperate *.conf files now, which must be inside the >>> /etc/X11/xorg.conf.d/ directory. Some packages can place a config file >>> there automatically. >> >> I still have a xorg.conf file here. May have to test removing it one >> day. I also have a file in the xorg.conf.d/ directory. After it reads >> my file, will it also read the file in the directory or does it ignore >> anything else since I have the old file? The file is named >> 20opengl.conf. >> >> I seem to recall trying to run without it ages ago and something not >> working. Can't recall what it was since it was a good long while back. > > If you don't *need* an xorg.conf (and you don't, otherwise you'd know > :-P) then it's best to not have one. It's nothing dangerous to try. > Just move it somewhere else and logout/login. If something breaks, > just move the file back (or better, see what option you have in it > that seems you need to provide manually, and split that into a .conf > file inside xorg.conf.d. That's how I configure my nvidia driver. I > have no xorg.conf. Instead, I have an xorg.conf.d/nvidia.conf file: > > https://pastebin.com/raw/0GsxaFRj > > It's a good system. I can do small, "surgical" tweaks to options > without having to maintain a full xorg.conf file. > > > As I mentioned earlier, I tried it without a xorg file a while back and it didn't work. That is how I knew I had to keep my old one. Until I try it again, then I won't know if I need one or not. I didn't have anything special when I tried it last time, single monitor and a normal video card, and it was needed then. Now I have a monitor but also a TV connected that I watch shows on. My current setup is a bit more complicated now than it was then. Thing is, I don't have time to test this right now. I don't want to start to test it, get involved in getting it working and only get part way through only to find out I have something else I have to go do. If I'm going to start it, I'd like to have time to finish it. Until I do that, I won't know if I need a xorg file or just a couple files in xorg.conf.d or something else. That also is not to mention that I have no idea what needs to go into those new files at this time, if anything is needed. Maybe some day soon. Dale :-) :-)
[gentoo-user] Ryzen initial results.
I installed my Ryzen system today, using a mATX b350 mobo. My existing kernel mostly works, .00] Linux version 4.6.7 (root@tortoise) (gcc version 5.4.0 (Gentoo 5.4.0-r3 p1.3, pie-0.6.5) ) #6 SMP Tue Apr 4 22:34:38 EDT 2017 0.00] Command line: BOOT_IMAGE=/vmlinuz-4.6.7 root=/dev/sda3 ro check_enable_amd_mmconf amd_iommu=fullflush iommu=soft 0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 ### <<< might need to update my command line, can't find where I stored the config for this. 0.277728] smpboot: CPU0: AMD Ryzen 7 1800X Eight-Core Processor (family: 0x17, model: 0x1, stepping: 0x1) 0.278242] Performance Events: ## Unsupported hardware. =O 0.165887] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 0.277728] smpboot: CPU0: AMD Ryzen 7 1800X Eight-Core Processor (family: 0x17, model: 0x1, stepping: 0x1) 0.278242] Performance Events: 0.278296] core perfctr but no constraints; unknown hardware! 0.278693] no PMU driver, software events only. 0.279047] MCE: In-kernel MCE decoding enabled. 0.601176] smpboot: Total of 16 processors activated (114890.88 BogoMIPS) heheheheh; roughly 3.5x as fast as my previous cpu, acknowledging limitations of this as a benchmark... There was a stack dump: ### 1.022172] sit: IPv6 over IPv4 tunneling driver 1.022534] NET: Registered protocol family 17 1.022743] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this. 1.023511] [ cut here ] 1.023717] WARNING: CPU: 15 PID: 1 at lib/kobject.c:210 kobject_add_internal+0x221/0x2d0 1.023927] kobject: (8807face5140): attempted to be registered with empty name! 1.024134] Modules linked in: 1.024384] CPU: 15 PID: 1 Comm: swapper/0 Not tainted 4.6.7 #6 1.024591] Hardware name: System manufacturer System Product Name/PRIME B350M-A, BIOS 0514 03/30/2017 1.024946] 88081e89fc98 81440186 88081e89fce8 1.025355] 88081e89fcd8 8104bd93 00d21e89fd20 1.025791] 8807face5140 ffea 8807faa1c810 0003 1.026199] Call Trace: 1.026398] [] dump_stack+0x4d/0x67 1.026609] [] __warn+0xd3/0xf0 1.026811] [] warn_slowpath_fmt+0x4a/0x50 1.030653] [] kobject_add_internal+0x221/0x2d0 1.030858] [] ? kfree_const+0x1d/0x30 1.031062] [] kobject_add+0x6f/0xc0 1.031267] [] ? kmem_cache_alloc+0xdb/0xe0 1.031483] [] kobject_create_and_add+0x3c/0x80 1.031690] [] threshold_create_device+0x163/0x330 1.031896] [] ? mcheck_vendor_init_severity+0x1a/0x1a 1.032102] [] threshold_init_device+0x30/0x46 1.032314] [] do_one_initcall+0x81/0x1a0 1.032520] [] kernel_init_freeable+0x14a/0x1d5 1.032726] [] kernel_init+0x9/0x100 1.032930] [] ret_from_fork+0x22/0x40 1.033133] [] ? rest_init+0x70/0x70 1.033345] ---[ end trace d0f146be7512a988 ]--- 1.033551] kobject_create_and_add: kobject_add error: -22 1.033770] microcode: CPU0: patch_level=0x08001105 1.033981] microcode: CPU1: patch_level=0x08001105 ### I should probably break my version freeze on my kernel but I am deeply concerned about nvidia_drivers compatibility... =\ I was emptytree world'ing my system and it died at: ## /bin/sh ./libtool --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/var/tmp/portage/media-libs/libid3tag-0.15.1b-r4/work/libid3tag-0.15.1b -I. -Wall -pipe -march=native -fomit-frame-pointer -c -o file.lo /var/tmp/portage/media-libs/libid3tag-0.15.1b-r4/work/libid3tag-0.15.1b/file.c /var/tmp/portage/media-libs/libid3tag-0.15.1b-r4/work/libid3tag-0.15.1b/render.c: In function 'id3_render_latin1': /var/tmp/portage/media-libs/libid3tag-0.15.1b-r4/work/libid3tag-0.15.1b/render.c:119:12: warning: pointer targets in assignment differ in signedness [-Wpointer-sign] latin1 = ""; ^ compat.gperf:116:1: error: conflicting types for 'id3_compat_lookup' In file included from compat.gperf:37:0: /var/tmp/portage/media-libs/libid3tag-0.15.1b-r4/work/libid3tag-0.15.1b/compat.h:36:26: note: previous declaration of 'id3_compat_lookup' was here struct id3_compat const *id3_compat_lookup(register char const *, ### Does not appear to be CPU related, going to skipfirst resume and get as much done as I can... -- Strange Game. The only winning move is not to play. Powers are not rights.
Re: [gentoo-user] Re: Heads up: A reason *NOT* to have xorg.conf file
On Tue, 4 Apr 2017 22:27:57 +0200 (CEST), k...@aspodata.se wrote: > > I have an /etc/X11/xorg.conf.d/mouse.conf file. I use it to set the > > default acceleration profile. In your case, you should be able to > > delete your xorg.conf and instead just use this in mouse.conf: > > > >Section "InputDevice" > >Identifier "Mouse0" > >Driver "mouse" > >Option "Device" "/dev/whatever_you_use_currently" > >Option "Protocol" "MouseMan" > >EndSection > > Thanks for the idea, will check how xorg.conf and xorg.conf.d relate to > each other. They are the same thing. One approach puts everything in one file, one puts it in separate files that are easier to maintain. The system doesn't care, it's there for your convenience. However using both is not documented and probably not a good idea for that reason. -- Neil Bothwick Nothing is illegal if one hundred businessmen decide to do it. pgpvnrCNDs_Pm.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: soliciting a DHCP lease / carrier lost
On 04/04/2017 02:56 PM, Kai Krakow wrote: > Am Tue, 4 Apr 2017 14:28:23 -0600 > schrieb the...@sys-concept.com: > [snip] >> >> I have reconnected another cable and the unit in remote location >> works. Both cable have a good pinout but one is working and the other >> is not. Both cable are sunning inside wall (I presume same path). >> Without special tools/testing equipment it is hard to trace these >> problems. > > You could try the problematic cable with only 100 MBit. If this works, > I'm pretty sure that some of the wires are broken or have incorrect > order. Keep in mind, tho, that the inverse assumption of such tests is > not true. Yes, the testing took was cheap it came with the stripper. Though, if the cable order was wrong, wouldn't the light on the tester jump in different order? The light on the tester lights up sequentially, so I assume the order is correct. Besides that "bad" cable was working OK for a day. And yes, the room the cable is passing by has all kind or x-ray machine. I'll try to test it 100Mbit (limit the speed); just need to find out how. -- Thelma.
[gentoo-user] Re: soliciting a DHCP lease / carrier lost
Am Tue, 4 Apr 2017 14:28:23 -0600 schrieb the...@sys-concept.com: > On 04/04/2017 10:02 AM, Mick wrote: > > On Tuesday 04 Apr 2017 09:12:16 the...@sys-concept.com wrote: > >> On 04/04/2017 01:26 AM, Mick wrote: > [...] > > > [...] > > > > This may merely indicate they have been wired correctly (pin to > > pin). Unless your tester is 'intelligent' to also measure things > > like attenuation, DC loop resistance and cross talk and it can also > > calculate attenuation to cross talk ratio, you cannot be sure your > > cable will perform to specification. > > > > > [...] > >> > >> Shouldn't CAT5 be able to handle 100m run? > >> Am not sure I understand, "keep their runs separate from mains > >> cables"? > > > > Cat5e should be able to perform as specified in lengths up to 100m, > > when correctly terminated and without high cross talk. If your > > ethernet cable installation is running parallel to mains power and > > in close physical proximity, it may pick up noise, which will > > reduce its performance. It is better where ethernet and mains runs > > come together to cross them at 90 degrees angles to minimise the > > effect of interference. > > > > Either way, you have lost carrier errors. Random google result on > > causes of lost carrier errors, in case it helps: > > > > https://supportforums.cisco.com/discussion/9543606/what-causes-output-errors-ethernet-interface > > > > I have reconnected another cable and the unit in remote location > works. Both cable have a good pinout but one is working and the other > is not. Both cable are sunning inside wall (I presume same path). > Without special tools/testing equipment it is hard to trace these > problems. You could try the problematic cable with only 100 MBit. If this works, I'm pretty sure that some of the wires are broken or have incorrect order. Keep in mind, tho, that the inverse assumption of such tests is not true. -- Regards, Kai Replies to list-only preferred.
[gentoo-user] Re: soliciting a DHCP lease / carrier lost
Am Tue, 4 Apr 2017 09:12:16 -0600 schrieb the...@sys-concept.com: > On 04/04/2017 01:26 AM, Mick wrote: > > On Monday 03 Apr 2017 20:21:28 the...@sys-concept.com wrote: > >> The new box I installed in remote location has a problem obtaining > >> IP address. The box was working perfectly on my local LAN. > >> > >> In remote location I assigned static IP to it 10.10.0.5 > > > > Where and how? At the router IP address table, against the PC's > > MAC address? At the PC itself using a static IP address and gateway > > in /etc/conf.d/net? > > The remote location router runs DD-WRT (dhcpd), so all static IP's > are assigned via DD-WRT and MAC address. > > >> Previously this IP was assigned to a Virtual Box but I no longer > >> use it, so I assign this IP to a new box. > >> > >> The box was working for a day, but now when I boot the box I get > >> - soliciting a DHCP lease > >> - carrier lost > > > > The "carrier lost" error indicates a link going down. The lease > > renewal is likely to fail at least while the link is down. The > > link failure may be due to an electrical hard fault, e.g. faulty > > Cat5e cable, RJ45 socket/plug; or due to high electromagnetic > > interference. Check the router stats for carrier lost errors. If > > the counters show the link is being dropped regularly you should > > try to eliminate each component in the circuit the cause of the > > fault. > > The cable tester I have (cheap) is showing the CAT5 cable is OK. > http://www.primecables.com/p-309139-cab-ss35407-tester-network-cable-tester-crimping-tools-combo-for-rj-45-rj-11-primecables?gclid=CJzU2JKJi9MCFQYMaQodEyIHeA Such testers just test the correct order of the wires and that at least some signal reaches the other end. They don't test signal quality. If you use cheap connectors (the ones made only of plastic), the shielding won't be connected from one connector to the other which may be part of your problem. Also, such testers don't detect if you bent your cable too much: A bent wire still shows perfect connectivity for simple LED testers but high frequency signals get distorted too much by such cable issues. Also, they don't test the pairs are correctly twisted which each other. You could simply use wrong pairing like (1,2)(3,4)(5,6)(7,8) and the tester will show every wire okay. But the signals won't run correctly because twisted pair cables use pairs of (1,2)(3,6)(5,4)(7,8) - it is even important that one pair is reversed as you can see. In the connector it always has to be color-white-color-white-color-white alternating where one pair is split around the middle pair. Only the correct ordering of wires will ensure proper signal quality. If you made your cables yourself, you should check that. Here's a very good reference and explanation I always use: http://www.elektronik-kompendium.de/sites/net/0510151.htm It's German but the tables should be easy enough to understand. For the text you can try some translation tool. > >> Could the old IP get stuck somewhere in DD-WRT router? > >> > >> ping 10.10.0.5 - gives me no response. > > > > You may find arping a better instrument for investigating the use > > of IP addresses in your LAN. > > > > > >> The Cat5 is about 15-20meter long, I test it with a cable tester, > >> it is good (all the lights light up in correct order). > >> Cable is plugged in into a new switch. > > > > Long cables are more susceptible to electromagnetic interference - > > keep their runs separate from mains cables. > > Shouldn't CAT5 be able to handle 100m run? > Am not sure I understand, "keep their runs separate from mains > cables"? > > Electromagnetic interference - could be a problem, and it is hard to > troubleshoot. Wasn't it you that asked before about IP address assignment problems which appear in one location but not in the other? Maybe it is simply an environmental problem: Your cables may run along main power cables or high power cables attached to power demanding devices. This may well impose problems. If this is the problem you should consider using fiber optics on the longer runs or use CAT7 cabling. Tho, you can usually not attach normal crimping RJ45 connectors to such cables as the cables are too thick. There are special connectors for such cables. Keep also in mind that real CAT7 connectors are incompatible to your RJ45 switches. You would use normal CAT6 connectors which more or less caps your cabling at CAT6 then but still you benefit from CAT7 cabling on the long runs. -- Regards, Kai Replies to list-only preferred.
Re: [gentoo-user] soliciting a DHCP lease / carrier lost
On 04/04/2017 10:02 AM, Mick wrote: > On Tuesday 04 Apr 2017 09:12:16 the...@sys-concept.com wrote: >> On 04/04/2017 01:26 AM, Mick wrote: >>> On Monday 03 Apr 2017 20:21:28 the...@sys-concept.com wrote: > The Cat5 is about 15-20meter long, I test it with a cable tester, it is good (all the lights light up in correct order). Cable is plugged in into a new switch. > > This may merely indicate they have been wired correctly (pin to pin). Unless > your tester is 'intelligent' to also measure things like attenuation, DC loop > resistance and cross talk and it can also calculate attenuation to cross talk > ratio, you cannot be sure your cable will perform to specification. > > >>> Long cables are more susceptible to electromagnetic interference - keep >>> their runs separate from mains cables. >> >> Shouldn't CAT5 be able to handle 100m run? >> Am not sure I understand, "keep their runs separate from mains cables"? > > Cat5e should be able to perform as specified in lengths up to 100m, when > correctly terminated and without high cross talk. If your ethernet cable > installation is running parallel to mains power and in close physical > proximity, it may pick up noise, which will reduce its performance. It is > better where ethernet and mains runs come together to cross them at 90 > degrees > angles to minimise the effect of interference. > > Either way, you have lost carrier errors. Random google result on causes of > lost carrier errors, in case it helps: > > https://supportforums.cisco.com/discussion/9543606/what-causes-output-errors-ethernet-interface I have reconnected another cable and the unit in remote location works. Both cable have a good pinout but one is working and the other is not. Both cable are sunning inside wall (I presume same path). Without special tools/testing equipment it is hard to trace these problems. -- Thelma
Re: [gentoo-user] Re: Heads up: A reason *NOT* to have xorg.conf file
Nikos: > On 04/04/2017 12:11 AM, k...@aspodata.se wrote: > > Walter Dnes: > > ... > >> This state of affairs seems to have evolved slowly. There wasn't one > >> version where it worked for nobody, immediately followed by the next > >> version that worked for everybody. Years ago, X would not run without > >> an xorg.conf file. Then X started being able to properly autoconfigure > >> without an xorg.conf file for 10% of users... then 20%... then 30%, > >> etc. Today it works for just about everybody. > > > > No for me, I still use a serial mouse with mman protocol. > > I have an /etc/X11/xorg.conf.d/mouse.conf file. I use it to set the > default acceleration profile. In your case, you should be able to delete > your xorg.conf and instead just use this in mouse.conf: > >Section "InputDevice" >Identifier "Mouse0" >Driver "mouse" >Option "Device" "/dev/whatever_you_use_currently" >Option "Protocol" "MouseMan" >EndSection Thanks for the idea, will check how xorg.conf and xorg.conf.d relate to each other. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57
Re: [gentoo-user] soliciting a DHCP lease / carrier lost
On Tuesday 04 Apr 2017 09:12:16 the...@sys-concept.com wrote: > On 04/04/2017 01:26 AM, Mick wrote: > > On Monday 03 Apr 2017 20:21:28 the...@sys-concept.com wrote: > >> The Cat5 is about 15-20meter long, I test it with a cable tester, it is > >> good (all the lights light up in correct order). > >> Cable is plugged in into a new switch. This may merely indicate they have been wired correctly (pin to pin). Unless your tester is 'intelligent' to also measure things like attenuation, DC loop resistance and cross talk and it can also calculate attenuation to cross talk ratio, you cannot be sure your cable will perform to specification. > > Long cables are more susceptible to electromagnetic interference - keep > > their runs separate from mains cables. > > Shouldn't CAT5 be able to handle 100m run? > Am not sure I understand, "keep their runs separate from mains cables"? Cat5e should be able to perform as specified in lengths up to 100m, when correctly terminated and without high cross talk. If your ethernet cable installation is running parallel to mains power and in close physical proximity, it may pick up noise, which will reduce its performance. It is better where ethernet and mains runs come together to cross them at 90 degrees angles to minimise the effect of interference. Either way, you have lost carrier errors. Random google result on causes of lost carrier errors, in case it helps: https://supportforums.cisco.com/discussion/9543606/what-causes-output-errors-ethernet-interface -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] soliciting a DHCP lease / carrier lost
On 04/04/2017 01:26 AM, Mick wrote: > On Monday 03 Apr 2017 20:21:28 the...@sys-concept.com wrote: >> The new box I installed in remote location has a problem obtaining IP >> address. The box was working perfectly on my local LAN. >> >> In remote location I assigned static IP to it 10.10.0.5 > > Where and how? At the router IP address table, against the PC's MAC address? > > At the PC itself using a static IP address and gateway in /etc/conf.d/net? The remote location router runs DD-WRT (dhcpd), so all static IP's are assigned via DD-WRT and MAC address. >> Previously this IP was assigned to a Virtual Box but I no longer use it, >> so I assign this IP to a new box. >> >> The box was working for a day, but now when I boot the box I get >> - soliciting a DHCP lease >> - carrier lost > > The "carrier lost" error indicates a link going down. The lease renewal is > likely to fail at least while the link is down. The link failure may be due > to an electrical hard fault, e.g. faulty Cat5e cable, RJ45 socket/plug; or > due > to high electromagnetic interference. Check the router stats for carrier > lost > errors. If the counters show the link is being dropped regularly you should > try to eliminate each component in the circuit the cause of the fault. The cable tester I have (cheap) is showing the CAT5 cable is OK. http://www.primecables.com/p-309139-cab-ss35407-tester-network-cable-tester-crimping-tools-combo-for-rj-45-rj-11-primecables?gclid=CJzU2JKJi9MCFQYMaQodEyIHeA >> Could the old IP get stuck somewhere in DD-WRT router? >> >> ping 10.10.0.5 - gives me no response. > > You may find arping a better instrument for investigating the use of IP > addresses in your LAN. > > >> The Cat5 is about 15-20meter long, I test it with a cable tester, it is >> good (all the lights light up in correct order). >> Cable is plugged in into a new switch. > > Long cables are more susceptible to electromagnetic interference - keep their > runs separate from mains cables. Shouldn't CAT5 be able to handle 100m run? Am not sure I understand, "keep their runs separate from mains cables"? Electromagnetic interference - could be a problem, and it is hard to troubleshoot. >> I'll try to assign different address to it tomorrow and will try a new >> router on Friday. > > The new router should eliminate the router as the cause of the problem. > -- Thelma
[gentoo-user] Re: [OT] Tools for putting HDD back to new state
On 04/04/2017 04:07 PM, Harry Putnam wrote: I've googled fairly extensively on the subject and did not find a way described anywhere to return a disk to what is called its raw state. There's not such thing. When shipping, the disk might contain all zero-bytes, or random bytes. There may even be legal ramifications I suppose along the line of selling used discs as new after some kind of processing. Wiping the disk does not change the internal book-keeping data of the device. It's stored in its SMART memory, which lists how many hours the disk has been used, and whether there's any errors that have been detected. That data cannot be wiped since it's not on the disk. It's on a chip. That data can be viewed with any SMART viewer (like sys-apps/gsmartcontrol).
[gentoo-user] Re: [OT] Tools for putting HDD back to new state
Mike Gilbert writes: [...] > If you are not worried about securely removing all data and simply > want to fool fdisk into thinking your drive is empty, use the wipefs > utility. This will zero-out key bytes like the MBR, partition table, > filesystem magic numbers, etc. > > You'll want to run it once for each partition, and then once for the > whole device. > > wipefs -a /dev/sdx1 > wipefs -a /dev/sdx2 > wipefs -a /dev/sdx This sounds like more what I had in mind... there is no worry about making data irrecoverable. I'll check this out... booting the hardware with a liveCD of some sort that I know has that tool on it. SystemrescueCD probabably has it. Nikos Chantziaras writes: [...] > You can use cfdisk (or another partitioning tool) and delete all partitions. > > Then, delete the MBR (Master Boot Record), which is where boot > managers put themselves. You do that with: > > dd if=/dev/zero of=/dev/your_hard_disk bs=446 count=1 [...] This may be all I really need. I had considered it to start but had the notion that it might not be that hard to return a disk to its new condition ... apparently that is not really all that easy or in this case ... even necessary. I've googled fairly extensively on the subject and did not find a way described anywhere to return a disk to what is called its raw state. Or, put another way, the state a disk is in why you buy one new. There may even be legal ramifications I suppose along the line of selling used discs as new after some kind of processing.
[gentoo-user] Re: [OT] Tools for putting HDD back to new state
On 04/03/2017 09:11 PM, Harry Putnam wrote: I probably should know this, but off the top of my head I don't remember ever running into anything like this. I'd like to do what ever is done to set a used disk back to the state it was in when new... Not sure what that state is, but at least no evidence of boot manager or fs having been installed. You can use cfdisk (or another partitioning tool) and delete all partitions. Then, delete the MBR (Master Boot Record), which is where boot managers put themselves. You do that with: dd if=/dev/zero of=/dev/your_hard_disk bs=446 count=1 It's not necessary to write zeroes all over the disk. You only need to delete the partitions and the boot manager, unless you also want to make the old data on the disk irrecoverable instead of it just appearing empty out of the box. In that case, following the advise of the other posters here and write zeroes all over the disk with dd is a good idea.
[gentoo-user] Re: Heads up: A reason *NOT* to have xorg.conf file
On 04/04/2017 12:11 AM, k...@aspodata.se wrote: Walter Dnes: ... This state of affairs seems to have evolved slowly. There wasn't one version where it worked for nobody, immediately followed by the next version that worked for everybody. Years ago, X would not run without an xorg.conf file. Then X started being able to properly autoconfigure without an xorg.conf file for 10% of users... then 20%... then 30%, etc. Today it works for just about everybody. No for me, I still use a serial mouse with mman protocol. I have an /etc/X11/xorg.conf.d/mouse.conf file. I use it to set the default acceleration profile. In your case, you should be able to delete your xorg.conf and instead just use this in mouse.conf: Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Device" "/dev/whatever_you_use_currently" Option "Protocol" "MouseMan" EndSection
Re: [gentoo-user] soliciting a DHCP lease / carrier lost
On Monday 03 Apr 2017 20:21:28 the...@sys-concept.com wrote: > The new box I installed in remote location has a problem obtaining IP > address. The box was working perfectly on my local LAN. > > In remote location I assigned static IP to it 10.10.0.5 Where and how? At the router IP address table, against the PC's MAC address? At the PC itself using a static IP address and gateway in /etc/conf.d/net? > Previously this IP was assigned to a Virtual Box but I no longer use it, > so I assign this IP to a new box. > > The box was working for a day, but now when I boot the box I get > - soliciting a DHCP lease > - carrier lost The "carrier lost" error indicates a link going down. The lease renewal is likely to fail at least while the link is down. The link failure may be due to an electrical hard fault, e.g. faulty Cat5e cable, RJ45 socket/plug; or due to high electromagnetic interference. Check the router stats for carrier lost errors. If the counters show the link is being dropped regularly you should try to eliminate each component in the circuit the cause of the fault. > Could the old IP get stuck somewhere in DD-WRT router? > > ping 10.10.0.5 - gives me no response. You may find arping a better instrument for investigating the use of IP addresses in your LAN. > The Cat5 is about 15-20meter long, I test it with a cable tester, it is > good (all the lights light up in correct order). > Cable is plugged in into a new switch. Long cables are more susceptible to electromagnetic interference - keep their runs separate from mains cables. > I'll try to assign different address to it tomorrow and will try a new > router on Friday. The new router should eliminate the router as the cause of the problem. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
