On Sat, Oct 31, 2015 at 11:20 AM, Dewey Hylton <dewey.hyl...@gmail.com> wrote:
> 2015-10-31 10:56 GMT-04:00 Dewey Hylton <dewey.hyl...@gmail.com>: > >> On Sat, Oct 31, 2015 at 12:49 AM, Jonathan Gray <j...@jsg.id.au> wrote: >> >>> On Fri, Oct 30, 2015 at 11:32:16AM -0400, Dewey Hylton wrote: >>> > > >>> > didn't have -current onhand, but was able to perform this function on >>> a 5.8 >>> > system ... i have 3 of these devices i'd really like to get going on >>> > openbsd. THANKS! >>> >>> ... >>> >>> > Invalid PHY ID 0xA0044E90 >>> >>> This shouldn't be possible, perhaps something isn't powering up >>> correctly. >>> >>> You could try the following patch which will force the id to a known one: >>> >>> Index: if_em_hw.c >>> =================================================================== >>> RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v >>> retrieving revision 1.88 >>> diff -u -p -r1.88 if_em_hw.c >>> --- if_em_hw.c 12 Sep 2015 02:38:14 -0000 1.88 >>> +++ if_em_hw.c 31 Oct 2015 04:43:49 -0000 >>> @@ -5369,6 +5369,9 @@ em_match_gig_phy(struct em_hw *hw) >>> hw->phy_id |= (uint32_t) (phy_id_low & PHY_REVISION_MASK); >>> hw->phy_revision = (uint32_t) phy_id_low & ~PHY_REVISION_MASK; >>> >>> + if (hw->phy_id == 0xA0044E90) >>> + hw->phy_id = I210_I_PHY_ID; >>> + >>> switch (hw->mac_type) { >>> case em_82543: >>> if (hw->phy_id == M88E1000_E_PHY_ID) >>> Index: if_em_osdep.h >>> =================================================================== >>> RCS file: /cvs/src/sys/dev/pci/if_em_osdep.h,v >>> retrieving revision 1.12 >>> diff -u -p -r1.12 if_em_osdep.h >>> --- if_em_osdep.h 5 Oct 2011 02:52:10 -0000 1.12 >>> +++ if_em_osdep.h 29 Oct 2015 03:27:36 -0000 >>> @@ -44,7 +44,8 @@ POSSIBILITY OF SUCH DAMAGE. >>> >>> #define MSGOUT(S, A, B) printf(S "\n", A, B) >>> #define DEBUGFUNC(F) DEBUGOUT(F); >>> -#ifdef DBG >>> +//#ifdef DBG >>> +#if 1 >>> #define DEBUGOUT(S) printf(S "\n") >>> #define DEBUGOUT1(S,A) printf(S "\n",A) >>> #define DEBUGOUT2(S,A,B) printf(S "\n",A,B) >>> >> >> THANKS for your time and assistance. >> >> i now have enough networking to commence an installation, which is in >> progress. i'll have to build >> and copy in a new kernel of course to use the booted system afterward. >> assuming nothing is shown >> broken in the dmesg below, what do i need to do in order to get this >> change (or another fix which >> would not require this change, if this was just an improper hack) >> committed? >> >> > HOLD THE PRESSES! > > after the installation and reboot, just prior to copying the rebuild > kernel that was to provide networking, > i notice that networking is in fact working. so somehow, with regard to > this specific network interface, > there was a disparity between bsd.rd and bsd (GENERIC) kernels. i'll try > to run this through its paces > with vlans and other such things, but at the moment it looks like GENERIC > from 5.8 actually works as > it should without any changes. perhaps it's time to dust off the old usb > installer sticks and forgo pxe for > these little devices. at least for the time being ... > > is it safe to assume that the disparity between bsd.rd and bsd is due to > trimming to keep the image at > a minimum? i know other things are removed from bsd.rd for this purpose > ... and if not, does this point > to a bug for which i need to make a report? > > thanks again for your assistance, Jonathan! > > > Jonathan wondered whether the issue was related to trimming of bsd.rd or possibly pxe leaving the interface in an incorrect state. the email never came to me, but i saw it on the list so i'll reply to this, the last message i do see in my inbox. i installed 5.8 to a usb stick and used that to boot bsd.rd on the fitlet. the problem did not show up there - so the issue must be related to pxe. if this means i should be reporting somehow, please point me in the right direction; i'm not sure if that would be a bug in the pxe code on the interface firmware or in the pxeboot code from openbsd. and i'd have no idea how to find the answer.