Re: Broadcom NIC issues
Hi! Installed Ubuntu 14.04.2 (amd64) and the NIC does not work: it does not configure through DHCP and it simply does not work if I set a static IP address. Ran FreeBSD 10.1 (amd64) Live CD and the network worked fine. It seems this machine does not like Linux. I have no more ideas about what might be wrong. Anyone has more ideas? 2015-03-13 16:30 GMT+00:00 Kevin Kwan kkwan@gmail.com: Try booting it up using a more modern OS live image (like, say, Ubuntu 14 or Fedora 21), and then go back to CentOS. CentOS itself is kind of old even as far as Linux is concerned. It could be as simple as some internal register not being re-initialized properly after the swap. What does the relevant boot lines look like in the CentOS dmesg? On Mar 13, 2015 12:21 PM, Steven McDonald ste...@steven-mcdonald.id.au wrote: On Fri, 13 Mar 2015 15:48:02 + Miguel Barbosa Gonçalves m...@mbg.pt wrote: I recently installed OpenBSD 5.6 on an amd64 platform. Everything went smoothly. After installation, at the first boot, OpenBSD updated the firmware of some devices. I found this strange... OpenBSD runs fw_update(8) on first boot. fw_update simply downloads firmware packages and installs firmware onto the filesystem (not directly into the devices that use it) for drivers that need to load it at runtime. Linux has a similar firmware-loading mechanism, but it typically ships the firmware embedded in the kernel. I had to reinstall this machine with CentOS and now the NIC does not work. Did the machine work with CentOS previously? It seems extremely unlikely that fw_update would be able to break Linux's use of the hardware, since that firmware is loaded on every boot by the relevant driver in both operating systems. I reinstalled OpenBSD again and it works. I tried to reflash the NIC's firmware and the installer does not recognize the NIC. At the moment, the machine only works with OpenBSD... Some details as to specifically what you did and what failed, as well as a dmesg, would be useful here. All I can say with the information given is that, if your Broadcom NIC requires non-free firmware to be loaded by the driver, the OpenBSD installer would not be able to use it because it does not include non-free firmware. If fw_update was able to run on first boot, though, it sounds like your NIC is usable without firmware. Again, a dmesg would help (I'm not even sure which of the three Broadcom NIC drivers in OpenBSD you're using).
Autoinstall without PXE.
Hello misc@, Looking around the man pages for 5.6 and -current it doesn't seem like it, but is it possible to perform an autoinstall/autoupgrade with out utilizing pxe and an http server. I would like to put the autoinstall/autoupgrade file on a usbkey or embed it on a custom cd. Thanks, -- Joshua Smith Lead Systems Administrator WVNET Montani Semper Liberi
Re: Broadcom NIC issues
Eh...this won't happen to be a Broadcom Tigon (tg3), would it? I remember that due to some licensing quirk, more than a few Linux distros do not bundle the firmware to make certain NICs work out of the box, at least not until you explicitly install firmware-bad or whatever the heck the Linux guys call it. The old Intel e100s and their busted checksumming also comes to mind. Also, do you have the dmesg/lspci -v off the centos or the Ubuntu in both cases? On Mar 13, 2015 3:40 PM, Miguel Barbosa Gonçalves m...@mbg.pt wrote: Hi! Installed Ubuntu 14.04.2 (amd64) and the NIC does not work: it does not configure through DHCP and it simply does not work if I set a static IP address. Ran FreeBSD 10.1 (amd64) Live CD and the network worked fine. It seems this machine does not like Linux. I have no more ideas about what might be wrong. Anyone has more ideas? 2015-03-13 16:30 GMT+00:00 Kevin Kwan kkwan@gmail.com: Try booting it up using a more modern OS live image (like, say, Ubuntu 14 or Fedora 21), and then go back to CentOS. CentOS itself is kind of old even as far as Linux is concerned. It could be as simple as some internal register not being re-initialized properly after the swap. What does the relevant boot lines look like in the CentOS dmesg? On Mar 13, 2015 12:21 PM, Steven McDonald ste...@steven-mcdonald.id.au wrote: On Fri, 13 Mar 2015 15:48:02 + Miguel Barbosa Gonçalves m...@mbg.pt wrote: I recently installed OpenBSD 5.6 on an amd64 platform. Everything went smoothly. After installation, at the first boot, OpenBSD updated the firmware of some devices. I found this strange... OpenBSD runs fw_update(8) on first boot. fw_update simply downloads firmware packages and installs firmware onto the filesystem (not directly into the devices that use it) for drivers that need to load it at runtime. Linux has a similar firmware-loading mechanism, but it typically ships the firmware embedded in the kernel. I had to reinstall this machine with CentOS and now the NIC does not work. Did the machine work with CentOS previously? It seems extremely unlikely that fw_update would be able to break Linux's use of the hardware, since that firmware is loaded on every boot by the relevant driver in both operating systems. I reinstalled OpenBSD again and it works. I tried to reflash the NIC's firmware and the installer does not recognize the NIC. At the moment, the machine only works with OpenBSD... Some details as to specifically what you did and what failed, as well as a dmesg, would be useful here. All I can say with the information given is that, if your Broadcom NIC requires non-free firmware to be loaded by the driver, the OpenBSD installer would not be able to use it because it does not include non-free firmware. If fw_update was able to run on first boot, though, it sounds like your NIC is usable without firmware. Again, a dmesg would help (I'm not even sure which of the three Broadcom NIC drivers in OpenBSD you're using).
Re: hw.sensors and high fan RPM
I have a T410 as well and I don't use it because of the fan noise. I bought it to replace my T61, but I continue to use the T61 because it's slightly less noisy at 2935 RPM. I looked for solutions several times but never found one. I even laid down new Arctic Silver 5 thermal paste and installed brand new fans on both laptops, but no change. The CPUs run cool in the 30s for the T410 and in the lower 40s for the T61, but the fans just spin loudly. Even `apm -L` doesn't help. Both laptops had Windows on them when I bought them and the fans were silent. So I know it's a possibility. Joseph Oficre wrote, On 03/11/15 05:33: Hi, some time ago i created the mail like this, but i have some new information about my problem. So, there is my hw.sensors: # sysctl hw.sensors hw.sensors.cpu0.temp0=34.00 degC hw.sensors.cpu1.temp0=34.00 degC hw.sensors.cpu2.temp0=34.00 degC hw.sensors.cpu3.temp0=34.00 degC hw.sensors.acpitz0.temp0=53.00 degC (zone temperature) hw.sensors.acpibtn0.indicator0=On (lid open) hw.sensors.acpibat0.volt0=10.80 VDC (voltage) hw.sensors.acpibat0.volt1=11.77 VDC (current voltage) hw.sensors.acpibat0.power0=34.30 W (rate) hw.sensors.acpibat0.watthour0=42.96 Wh (last full capacity) hw.sensors.acpibat0.watthour1=2.15 Wh (warning capacity) hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity) hw.sensors.acpibat0.watthour3=29.21 Wh (remaining capacity), OK hw.sensors.acpibat0.watthour4=47.52 Wh (design capacity) hw.sensors.acpibat0.raw0=2 (battery charging), OK hw.sensors.acpiac0.indicator0=On (power supply) hw.sensors.acpithinkpad0.temp0=53.00 degC hw.sensors.acpithinkpad0.temp1=53.00 degC hw.sensors.acpithinkpad0.temp2=53.00 degC hw.sensors.acpithinkpad0.temp3=53.00 degC hw.sensors.acpithinkpad0.temp4=53.00 degC hw.sensors.acpithinkpad0.temp5=53.00 degC hw.sensors.acpithinkpad0.temp6=53.00 degC hw.sensors.acpithinkpad0.temp7=53.00 degC hw.sensors.acpithinkpad0.fan0=4510 RPM hw.sensors.itherm0.temp0=0.00 degC (Thermometer) hw.sensors.itherm0.temp1=51.03 degC (Core 1) hw.sensors.itherm0.temp4=54.00 degC (CPU/GPU Max temp) hw.sensors.itherm0.temp9=54.00 degC (GPU/Memory controller abs.) hw.sensors.itherm0.temp10=59.00 degC (PCH abs.) hw.sensors.itherm0.power0=7.00 W (CPU power consumption) hw.sensors.aps0.temp0=45.00 degC hw.sensors.aps0.temp1=45.00 degC hw.sensors.aps0.indicator0=Off (Keyboard Active) hw.sensors.aps0.indicator1=Off (Mouse Active) hw.sensors.aps0.indicator2=On (Lid Open) hw.sensors.aps0.raw0=511 (X_ACCEL) hw.sensors.aps0.raw1=505 (Y_ACCEL) hw.sensors.aps0.raw2=511 (X_VAR) hw.sensors.aps0.raw3=505 (Y_VAR) So. i have 34 cpu temperature. And only problem i see is 59C PCH temp. And as u can see i have 4500 RPM, and its SO DAMN LOUD. This notebook (thinkpad t410) ran freebsd, several linux systems, and i NEVER have this kind of problems. apmd daemon with -L, -C option do nothing about this. Can i somehow decrease RPM manually? Cuz i cant sleep at night, lol. When i boot freebsd system - everything works quite nice.
Re: athn at usb fixes
On Wed, Mar 11, 2015 at 09:13:54AM +0100, Martin Pieuchot wrote: I reverted the previous diff because the fix introduced a regression. I posted a new fix that should solve your problem on tech@, please test this diff and report back, this will speedup the integration process: https://marc.info/?l=openbsd-techm=142591741103252w=2 Sorry for the delay, I will apply this patch now and test. I post here the result -- Regards Henrique Lengler
Re: Autoinstall without PXE.
On Sat, 14 Mar 2015 02:27:56 + Raf Czlonka rczlo...@gmail.com wrote:
On Fri, Mar 13, 2015 at 09:02:23PM GMT, Joshua Smith wrote:
Hello misc@,
Hi Joshua,
Looking around the man pages for 5.6 and -current it doesn't seem like
it, but is it possible to perform an autoinstall/autoupgrade with out
utilizing pxe and an http server.
I would like to put the autoinstall/autoupgrade file on a usbkey or
embed it on a custom cd.
Well, probably not the way you have in mind (i.e. full autoinstall) as
you still have to point the installer to the {install,upgrade}.conf
manually: i.e. choose (A) for autoinstall, it'll then fail, escape to
shell, mount the disk with your config file, go back to the installer
and point it to the file - the rest of the installation/upgrade is then
fully automatic.
I use a 3-line (that includes a keyboard layout) 'upgrade.conf' to
upgrade to new snapshots.
Regards,
Raf
there is a better way using rdsetroot to actually put the *.conf files in the
bsd.rd kernel itself. it was discussed previously here:
https://marc.info/?l=openbsd-miscm=141552533922277w=2
carp over vlan on trunk
OpenBSD r0 5.6 GENERIC#0 i386 soekris net6501, dmesg below r0:/etc# cat hostname.trunk1 trunkproto failover trunkport em4 trunkport em5 up r0:/etc# cat hostname.vlan111 inet 10.1.11.2 255.255.255.0 10.1.11.255 vlandev trunk1 up r0:/etc# cat hostname.carp111 inet 10.1.11.1 255.255.255.0 10.1.11.255 vhid 111 carpdev vlan111 pass *** r0:/etc# ifconfig carp111 10.1.11.1 netmask 255.255.255.0 vhid 111 carpdev vlan111 pass *** ifconfig: SIOCAIFADDR: Can't assign requested address the trunk and vlans work fine. its the carp part thats not. is this possible? if so, how? ive tried google, but my search skills are weak. the goal is to have redundant access to a stacked pair of switches with 3 vlans. t pci8 dev 0 function 0 IDT 89HPES4T4 rev 0x0e pci9 at ppb8 bus 9 ppb9 at pci9 dev 2 function 0 IDT 89HPES4T4 rev 0x0e pci10 at ppb9 bus 10 em2 at pci10 dev 0 function 0 Intel 82574L rev 0x00: msi, address 00:00:24:d0:1f:3a ppb10 at pci9 dev 3 function 0 IDT 89HPES4T4 rev 0x0e pci11 at ppb10 bus 11 em3 at pci11 dev 0 function 0 Intel 82574L rev 0x00: msi, address 00:00:24:d0:1f:3b ppb11 at pci9 dev 4 function 0 IDT 89HPES4T4 rev 0x0e pci12 at ppb11 bus 12 ppb12 at pci0 dev 26 function 0 Intel E600 PCIE rev 0x00 pci13 at ppb12 bus 13 ppb13 at pci13 dev 0 function 0 IDT 89HPES5T5ZB rev 0x0e pci14 at ppb13 bus 14 ppb14 at pci14 dev 2 function 0 IDT 89HPES5T5ZB rev 0x0e pci15 at ppb14 bus 15 em4 at pci15 dev 0 function 0 Intel 82574L rev 0x00: msi, address 00:00:24:d0:5a:80 ppb15 at pci14 dev 3 function 0 IDT 89HPES5T5ZB rev 0x0e pci16 at ppb15 bus 16 em5 at pci16 dev 0 function 0 Intel 82574L rev 0x00: msi, address 00:00:24:d0:5a:81 ppb16 at pci14 dev 4 function 0 IDT 89HPES5T5ZB rev 0x0e pci17 at ppb16 bus 17 em6 at pci17 dev 0 function 0 Intel 82574L rev 0x00: msi, address 00:00:24:d0:5a:82 ppb17 at pci14 dev 5 function 0 IDT 89HPES5T5ZB rev 0x0e pci18 at ppb17 bus 18 em7 at pci18 dev 0 function 0 Intel 82574L rev 0x00: msi, address 00:00:24:d0:5a:83 tcpcib0 at pci0 dev 31 function 0 Intel E600 LPC rev 0x00: 14318179 Hz timer, watchdog isa0 at tcpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ti16750, 64 byte fifo com0: console pcppi0 at isa0 port 0x61 spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (c91be0c14866fd66.a) swap on sd0b dump on sd0b syncing disks... n 0 OpenBSD 5.6-stable (GENERIC) #0: Sat Mar 7 12:18:28 PST 2015 root@r0:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Genuine Intel(R) CPU @ 1.60GHz (GenuineIntel 686-class) 1.61 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF real mem = 2146840576 (2047MB) avail mem = 2099326976 (2002MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 20/21/15, BIOS32 rev. 0 @ 0xfac40 mpbios0 at bios0: Intel MP Specification 1.4 cpu0 at mainbus0: apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu at mainbus0: not configured mpbios0: bus 0 is type PCI mpbios0: bus 64 is type ISA ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins pcibios0 at bios0: rev 2.0 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf3880/96 (4 entries) pcibios0: no compatible PCI ICU found: ICU vendor 0x8086 product 0x8186 pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #18 is the last bus bios0: ROM list: 0xc8000/0x2400 0xca800/0x4c00 0xcf800/0xee00 cpu0: unknown Enhanced SpeedStep CPU, msr 0x060f101606001016 cpu0: using only highest and lowest power states cpu0: Enhanced SpeedStep 1601 MHz: speeds: 1600, 600 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel E600 Host rev 0x05 pchb1 at pci0 dev 1 function 0 Intel E600 Config rev 0x00 ppb0 at pci0 dev 23 function 0 Intel E600 PCIE rev 0x00 pci1 at ppb0 bus 1 ppb1 at pci1 dev 0 function 0 Intel EG20T PCIE rev 0x01 pci2 at ppb1 bus 2 Intel EG20T Packet Hub rev 0x01 at pci2 dev 0 function 0 not configured Intel EG20T Ethernet rev 0x01 at pci2 dev 0 function 1 not configured Intel EG20T GPIO rev 0x00 at pci2 dev 0 function 2 not configured ohci0 at pci2 dev 2 function 0 Intel EG20T USB rev 0x01: apic 0 int 19, version 1.0, legacy support ohci1 at pci2 dev 2 function 1 Intel EG20T USB rev 0x01: apic 0 int 19, version 1.0, legacy support ohci2 at pci2 dev 2 function 2 Intel EG20T USB rev 0x01: apic 0 int 19, version 1.0, legacy support ehci0 at pci2 dev 2 function 3 Intel EG20T USB rev 0x01: apic 0 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 Intel EG20T USB Client rev 0x01 at pci2 dev 2 function 4 not configured sdhc0 at pci2 dev 4 function 0 Intel EG20T SDIO rev 0x01: apic 0 int
Re: Autoinstall without PXE.
On Fri, Mar 13, 2015 at 09:02:23PM GMT, Joshua Smith wrote:
Hello misc@,
Hi Joshua,
Looking around the man pages for 5.6 and -current it doesn't seem like
it, but is it possible to perform an autoinstall/autoupgrade with out
utilizing pxe and an http server.
I would like to put the autoinstall/autoupgrade file on a usbkey or
embed it on a custom cd.
Well, probably not the way you have in mind (i.e. full autoinstall) as
you still have to point the installer to the {install,upgrade}.conf
manually: i.e. choose (A) for autoinstall, it'll then fail, escape to
shell, mount the disk with your config file, go back to the installer
and point it to the file - the rest of the installation/upgrade is then
fully automatic.
I use a 3-line (that includes a keyboard layout) 'upgrade.conf' to
upgrade to new snapshots.
Regards,
Raf
Re: Broadcom NIC issues
On 03/13/15 15:38, Miguel Barbosa Gonçalves wrote: Hi! Installed Ubuntu 14.04.2 (amd64) and the NIC does not work: it does not configure through DHCP and it simply does not work if I set a static IP address. Ran FreeBSD 10.1 (amd64) Live CD and the network worked fine. It seems this machine does not like Linux. ... *looking around* As this is an OpenBSD list, I think it sounds like it is working just fine. ;) Nick.
Re: athn at usb fixes
On Fri, Mar 13, 2015 at 09:03:35PM -0300, Henrique Lengler wrote: Sorry for the delay, I will apply this patch now and test. I post here the result I applied this and I continue with my internet getting down every time and receiving the message: athn0: device timeout So I need to re-run /etc/netstart -- Regards Henrique Lengler
Just a thank you.
Hi, This seems non-sequitur somehow, but I would simply like thank all the developers of OpenBSD for continuing work on the only OS that I really trust. I learn plenty just by lurking on this list. I also appreciate having a set of developers with the fortitude to entirely reject very flawed systems, and I like that simply because someone has to. Just thanks. Ben.
Re: Broadcom NIC issues
Uh...just out of curiosity, you did run pfctl -d to disable the firewall first, right? On Mar 13, 2015 6:55 PM, Miguel Barbosa Gonçalves m...@mbg.pt wrote: Hi Kevin! It is indeed a tg3. I have another two machines using this driver and there's a package installed for the firmware. I really don't recall if the firmware was installed. The strange thing that happened on this machine was that the NIC sent packets but never received the replies. I know this because I pinged the default gateway from this machine and was seeing the ARP requests and replies on default gateway for its IP address. Then I added a static ARP mapping and pinged an outside IP address (8.8.8.8). Again, on the default gateway I would see packets going out and returning but never reaching the machine. Odd... I will reinstall again to see if the package with the firmware is installed or not. Thanks! 2015-03-13 21:30 GMT+00:00 Kevin Kwan kkwan@gmail.com: Eh...this won't happen to be a Broadcom Tigon (tg3), would it? I remember that due to some licensing quirk, more than a few Linux distros do not bundle the firmware to make certain NICs work out of the box, at least not until you explicitly install firmware-bad or whatever the heck the Linux guys call it. The old Intel e100s and their busted checksumming also comes to mind. Also, do you have the dmesg/lspci -v off the centos or the Ubuntu in both cases? On Mar 13, 2015 3:40 PM, Miguel Barbosa Gonçalves m...@mbg.pt wrote: Hi! Installed Ubuntu 14.04.2 (amd64) and the NIC does not work: it does not configure through DHCP and it simply does not work if I set a static IP address. Ran FreeBSD 10.1 (amd64) Live CD and the network worked fine. It seems this machine does not like Linux. I have no more ideas about what might be wrong. Anyone has more ideas? 2015-03-13 16:30 GMT+00:00 Kevin Kwan kkwan@gmail.com: Try booting it up using a more modern OS live image (like, say, Ubuntu 14 or Fedora 21), and then go back to CentOS. CentOS itself is kind of old even as far as Linux is concerned. It could be as simple as some internal register not being re-initialized properly after the swap. What does the relevant boot lines look like in the CentOS dmesg? On Mar 13, 2015 12:21 PM, Steven McDonald ste...@steven-mcdonald.id.au wrote: On Fri, 13 Mar 2015 15:48:02 + Miguel Barbosa Gonçalves m...@mbg.pt wrote: I recently installed OpenBSD 5.6 on an amd64 platform. Everything went smoothly. After installation, at the first boot, OpenBSD updated the firmware of some devices. I found this strange... OpenBSD runs fw_update(8) on first boot. fw_update simply downloads firmware packages and installs firmware onto the filesystem (not directly into the devices that use it) for drivers that need to load it at runtime. Linux has a similar firmware-loading mechanism, but it typically ships the firmware embedded in the kernel. I had to reinstall this machine with CentOS and now the NIC does not work. Did the machine work with CentOS previously? It seems extremely unlikely that fw_update would be able to break Linux's use of the hardware, since that firmware is loaded on every boot by the relevant driver in both operating systems. I reinstalled OpenBSD again and it works. I tried to reflash the NIC's firmware and the installer does not recognize the NIC. At the moment, the machine only works with OpenBSD... Some details as to specifically what you did and what failed, as well as a dmesg, would be useful here. All I can say with the information given is that, if your Broadcom NIC requires non-free firmware to be loaded by the driver, the OpenBSD installer would not be able to use it because it does not include non-free firmware. If fw_update was able to run on first boot, though, it sounds like your NIC is usable without firmware. Again, a dmesg would help (I'm not even sure which of the three Broadcom NIC drivers in OpenBSD you're using).
Re: Broadcom NIC issues
Hi Kevin! It is indeed a tg3. I have another two machines using this driver and there's a package installed for the firmware. I really don't recall if the firmware was installed. The strange thing that happened on this machine was that the NIC sent packets but never received the replies. I know this because I pinged the default gateway from this machine and was seeing the ARP requests and replies on default gateway for its IP address. Then I added a static ARP mapping and pinged an outside IP address (8.8.8.8). Again, on the default gateway I would see packets going out and returning but never reaching the machine. Odd... I will reinstall again to see if the package with the firmware is installed or not. Thanks! 2015-03-13 21:30 GMT+00:00 Kevin Kwan kkwan@gmail.com: Eh...this won't happen to be a Broadcom Tigon (tg3), would it? I remember that due to some licensing quirk, more than a few Linux distros do not bundle the firmware to make certain NICs work out of the box, at least not until you explicitly install firmware-bad or whatever the heck the Linux guys call it. The old Intel e100s and their busted checksumming also comes to mind. Also, do you have the dmesg/lspci -v off the centos or the Ubuntu in both cases? On Mar 13, 2015 3:40 PM, Miguel Barbosa Gonçalves m...@mbg.pt wrote: Hi! Installed Ubuntu 14.04.2 (amd64) and the NIC does not work: it does not configure through DHCP and it simply does not work if I set a static IP address. Ran FreeBSD 10.1 (amd64) Live CD and the network worked fine. It seems this machine does not like Linux. I have no more ideas about what might be wrong. Anyone has more ideas? 2015-03-13 16:30 GMT+00:00 Kevin Kwan kkwan@gmail.com: Try booting it up using a more modern OS live image (like, say, Ubuntu 14 or Fedora 21), and then go back to CentOS. CentOS itself is kind of old even as far as Linux is concerned. It could be as simple as some internal register not being re-initialized properly after the swap. What does the relevant boot lines look like in the CentOS dmesg? On Mar 13, 2015 12:21 PM, Steven McDonald ste...@steven-mcdonald.id.au wrote: On Fri, 13 Mar 2015 15:48:02 + Miguel Barbosa Gonçalves m...@mbg.pt wrote: I recently installed OpenBSD 5.6 on an amd64 platform. Everything went smoothly. After installation, at the first boot, OpenBSD updated the firmware of some devices. I found this strange... OpenBSD runs fw_update(8) on first boot. fw_update simply downloads firmware packages and installs firmware onto the filesystem (not directly into the devices that use it) for drivers that need to load it at runtime. Linux has a similar firmware-loading mechanism, but it typically ships the firmware embedded in the kernel. I had to reinstall this machine with CentOS and now the NIC does not work. Did the machine work with CentOS previously? It seems extremely unlikely that fw_update would be able to break Linux's use of the hardware, since that firmware is loaded on every boot by the relevant driver in both operating systems. I reinstalled OpenBSD again and it works. I tried to reflash the NIC's firmware and the installer does not recognize the NIC. At the moment, the machine only works with OpenBSD... Some details as to specifically what you did and what failed, as well as a dmesg, would be useful here. All I can say with the information given is that, if your Broadcom NIC requires non-free firmware to be loaded by the driver, the OpenBSD installer would not be able to use it because it does not include non-free firmware. If fw_update was able to run on first boot, though, it sounds like your NIC is usable without firmware. Again, a dmesg would help (I'm not even sure which of the three Broadcom NIC drivers in OpenBSD you're using).
Re: Broadcom NIC issues
2015-03-14 0:17 GMT+00:00 Kevin Kwan kkwan@gmail.com: of curiosity, you did run pfctl -d to disable the firewall first, right? firewalls disabled of course :-)
subscribe
subscribe
Broadcom NIC issues
Hi! I recently installed OpenBSD 5.6 on an amd64 platform. Everything went smoothly. After installation, at the first boot, OpenBSD updated the firmware of some devices. I found this strange... I had to reinstall this machine with CentOS and now the NIC does not work. I reinstalled OpenBSD again and it works. I tried to reflash the NIC's firmware and the installer does not recognize the NIC. At the moment, the machine only works with OpenBSD... What did OpenBSD do and how can I revert this? TIA, Miguel
Diffs for OpenBSD /src
Good morning, What is an appropriate channel for relaying diffs for review? -- Matthew Markfort Microsoft Certified Professional
Re: Diffs for OpenBSD /src
On Fri, 13 Mar 2015 10:42:21 -0500, Matthew Markfort wrote: What is an appropriate channel for relaying diffs for review? The t...@openbsd.org list is usually the right place for diffs to be reviewed. - todd
Re: Why generate SSH keys at startup?
On Thu, Mar 12, 2015 at 08:27:03PM +, Christian Weisgerber wrote: On 2015-03-12, John Long codeb...@inbox.lv wrote: By setting PubkeyAcceptedKeyTypes accordingly in sshd_config. Thanks, I looked and looked and could not find it in the man page. It appears to be only in -current? Is this possible in prior versions (i.e. undocumented but works) or is it totally new? Unfortunately, it is quite new. It was added ... *checks CVS history* ... eight weeks ago. Thank you. Motivation for keeping boxes current ;-) /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04
Re: Why generate SSH keys at startup?
On Thu, Mar 12, 2015 at 07:19:25PM +, Stuart Henderson wrote: On 2015-03-12, John Long codeb...@inbox.lv wrote: On Thu, Mar 12, 2015 at 04:20:47PM +, Christian Weisgerber wrote: On 2015-03-12, John Long codeb...@inbox.lv wrote: You can simply configure HostKey in /etc/ssh/sshd_config. With that done a client can still do pubkey auth with a DSA key. (How) can I stop sshd from accepting client keys a user might include in ~/.ssh/authorized_keys other than RSA keys? By setting PubkeyAcceptedKeyTypes accordingly in sshd_config. Thanks, I looked and looked and could not find it in the man page. It appears to be only in -current? Is this possible in prior versions (i.e. undocumented but works) or is it totally new? By looking with cvs blame sshd_config.5 | grep PubkeyAcceptedKeyTypes and examine the cvs log, you can see that it was added on 2015/01/13. Thanks for the info and tip! /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04
Re: Why generate SSH keys at startup?
On Thu, Mar 12, 2015 at 04:00:30PM -0400, Josh Grosse wrote: On Thu, Mar 12, 2015 at 07:19:25PM +, Stuart Henderson wrote: By looking with cvs blame sshd_config.5 | grep PubkeyAcceptedKeyTypes and examine the cvs log, you can see that it was added on 2015/01/13. Blame? Blame? When did this wonderful, utterly brilliant but undocumented synonym for annotate get added to cvs? And then I found the commit: CVSROOT:/cvs Module name:src Changes by: j...@cvs.openbsd.org 2010/07/22 04:31:10 Good one :-) Thanks. /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04
Re: Broadcom NIC issues
2015-03-13 15:56 GMT+00:00 John Merriam j...@johnmerriam.net: On Fri, 13 Mar 2015, Miguel Barbosa Gon?alves wrote: Hi! I recently installed OpenBSD 5.6 on an amd64 platform. Everything went smoothly. After installation, at the first boot, OpenBSD updated the firmware of some devices. I found this strange... I had to reinstall this machine with CentOS and now the NIC does not work. I reinstalled OpenBSD again and it works. I tried to reflash the NIC's firmware and the installer does not recognize the NIC. At the moment, the machine only works with OpenBSD... What did OpenBSD do and how can I revert this? Maybe a silly question, but have you power cycled (turn computer completely off then back on) the machine between running OpenBSD and running CentOS? If you haven't tried a power cycle and it works, that won't solve what the problem is but might at least allow you to run CentOS again. Hi John! Yes, I completely removed the power cable from the machine. I even tried running an older version of CentOS and it did not work. I am completely clueless... Thanks!
Re: Broadcom NIC issues
On Fri, 13 Mar 2015, Miguel Barbosa Gon?alves wrote: 2015-03-13 15:56 GMT+00:00 John Merriam j...@johnmerriam.net: On Fri, 13 Mar 2015, Miguel Barbosa Gon?alves wrote: Hi! I recently installed OpenBSD 5.6 on an amd64 platform. Everything went smoothly. After installation, at the first boot, OpenBSD updated the firmware of some devices. I found this strange... I had to reinstall this machine with CentOS and now the NIC does not work. I reinstalled OpenBSD again and it works. I tried to reflash the NIC's firmware and the installer does not recognize the NIC. At the moment, the machine only works with OpenBSD... What did OpenBSD do and how can I revert this? Maybe a silly question, but have you power cycled (turn computer completely off then back on) the machine between running OpenBSD and running CentOS? If you haven't tried a power cycle and it works, that won't solve what the problem is but might at least allow you to run CentOS again. Hi John! Yes, I completely removed the power cable from the machine. I even tried running an older version of CentOS and it did not work. I am completely clueless... Thanks! I would recommend replying to this thread with the output from the dmesg and pcidump -v commands under OpenBSD. That may give someone here a clue as to what your problem may be. If you don't get any replies a few days after posting the output of those commands then you could try submitting a bug report using the sendbug program under OpenBSD. -- John Merriam
Re: Broadcom NIC issues
On Fri, 13 Mar 2015 15:48:02 + Miguel Barbosa Gonçalves m...@mbg.pt wrote: I recently installed OpenBSD 5.6 on an amd64 platform. Everything went smoothly. After installation, at the first boot, OpenBSD updated the firmware of some devices. I found this strange... OpenBSD runs fw_update(8) on first boot. fw_update simply downloads firmware packages and installs firmware onto the filesystem (not directly into the devices that use it) for drivers that need to load it at runtime. Linux has a similar firmware-loading mechanism, but it typically ships the firmware embedded in the kernel. I had to reinstall this machine with CentOS and now the NIC does not work. Did the machine work with CentOS previously? It seems extremely unlikely that fw_update would be able to break Linux's use of the hardware, since that firmware is loaded on every boot by the relevant driver in both operating systems. I reinstalled OpenBSD again and it works. I tried to reflash the NIC's firmware and the installer does not recognize the NIC. At the moment, the machine only works with OpenBSD... Some details as to specifically what you did and what failed, as well as a dmesg, would be useful here. All I can say with the information given is that, if your Broadcom NIC requires non-free firmware to be loaded by the driver, the OpenBSD installer would not be able to use it because it does not include non-free firmware. If fw_update was able to run on first boot, though, it sounds like your NIC is usable without firmware. Again, a dmesg would help (I'm not even sure which of the three Broadcom NIC drivers in OpenBSD you're using).
Re: Broadcom NIC issues
On Fri, 13 Mar 2015, Miguel Barbosa Gon?alves wrote: Hi! I recently installed OpenBSD 5.6 on an amd64 platform. Everything went smoothly. After installation, at the first boot, OpenBSD updated the firmware of some devices. I found this strange... I had to reinstall this machine with CentOS and now the NIC does not work. I reinstalled OpenBSD again and it works. I tried to reflash the NIC's firmware and the installer does not recognize the NIC. At the moment, the machine only works with OpenBSD... What did OpenBSD do and how can I revert this? Maybe a silly question, but have you power cycled (turn computer completely off then back on) the machine between running OpenBSD and running CentOS? If you haven't tried a power cycle and it works, that won't solve what the problem is but might at least allow you to run CentOS again. I have seen strange things happen in the past when switching between OSes but that was a very long time ago. -- John Merriam
Re: Broadcom NIC issues
Try booting it up using a more modern OS live image (like, say, Ubuntu 14 or Fedora 21), and then go back to CentOS. CentOS itself is kind of old even as far as Linux is concerned. It could be as simple as some internal register not being re-initialized properly after the swap. What does the relevant boot lines look like in the CentOS dmesg? On Mar 13, 2015 12:21 PM, Steven McDonald ste...@steven-mcdonald.id.au wrote: On Fri, 13 Mar 2015 15:48:02 + Miguel Barbosa Gonçalves m...@mbg.pt wrote: I recently installed OpenBSD 5.6 on an amd64 platform. Everything went smoothly. After installation, at the first boot, OpenBSD updated the firmware of some devices. I found this strange... OpenBSD runs fw_update(8) on first boot. fw_update simply downloads firmware packages and installs firmware onto the filesystem (not directly into the devices that use it) for drivers that need to load it at runtime. Linux has a similar firmware-loading mechanism, but it typically ships the firmware embedded in the kernel. I had to reinstall this machine with CentOS and now the NIC does not work. Did the machine work with CentOS previously? It seems extremely unlikely that fw_update would be able to break Linux's use of the hardware, since that firmware is loaded on every boot by the relevant driver in both operating systems. I reinstalled OpenBSD again and it works. I tried to reflash the NIC's firmware and the installer does not recognize the NIC. At the moment, the machine only works with OpenBSD... Some details as to specifically what you did and what failed, as well as a dmesg, would be useful here. All I can say with the information given is that, if your Broadcom NIC requires non-free firmware to be loaded by the driver, the OpenBSD installer would not be able to use it because it does not include non-free firmware. If fw_update was able to run on first boot, though, it sounds like your NIC is usable without firmware. Again, a dmesg would help (I'm not even sure which of the three Broadcom NIC drivers in OpenBSD you're using).
Re: [cwm] remote shell colorization hack
On Thu, Mar 12, 2015 at 09:54:59PM +0100, Dimitri Sokolyuk wrote: Hello I would like to propose a simple, but imho really useful hack for cwm. It boils down to colorization of remote terminals (Meta-Dot command) based on crc24 of a hostname. This way each remote connection gets its own color, such that different hosts are easier to distinguish. On the same time, different sessions to the same host gets always same color, which improves visual feedback. Is it idea from recent screenshots form LOR? )
