On Mon, Nov 02, 2015 at 08:55:40PM -0500, Dewey Hylton wrote:
> 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.
>
There is likely something that is not being initialised or reset
correctly. Unfortunately it is hard to think of where to start
looking for the problem.
