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.
