RE: Support for Killer E2400 Ethernet

2016-02-19 Thread Tino Engel 
Thanks very much for the quick reply.

So let me shed some words on your input:

First: Limiting the memory size did not help at all, nothing changed.
Unfortunetly I cannot post the whole results of the sysctl, since I cannot get 
this box into the net, and it is quite too much to type it by hand.
Is there any special value you are interested in?

Then I applied your patch.
The requested output is:
alc0: DMA CFG : 0x0c347c54

The bad thing: The error still persists. :(
It always writes "DMA write error" now followed by "DMA CFG : ..."

One more thing:
The ping -s command results in the same error as trying to fetch something from 
the internet.

Do you have any further ideas?

Thanks!

From: pyu...@gmail.com
Date: Fri, 19 Feb 2016 10:26:12 +0900
To: tino.en...@hotmail.com
Subject: Re: Support for Killer E2400 Ethernet
CC: freebsd-net@freebsd.org

On Thu, Feb 18, 2016 at 04:17:30PM +0100, Tino Engel wrote:
> 
> 
> 
> Hello all,
> I am trying to establish support for the Killer E2400 ethernet adapter.
> I am following the approach that works for the linux driver, which is 
> basically:- Add the E2400 device ID- Copy all device related stuff from the 
> E2200
> What works:- DHCP- Ping any host in the internet
> What does not work:- Downloading stuff using "fetch"- Setup pkg- Therefore 
> cannot browse since I even cannot install pkg in order to obtain a browser
> The error message I continously receive is "alc0: DMA write error".
> I have so far played with all the loader tunables and sysctls supported by 
> the alc driver, but no improvement of the situation.
> Any ideas how to proceed?
 
Due to lack of access to Killer E2200 controller, alc(4) was not
fully tested for the controller.  One user also reported that
alc(4) shows DMA errors as you saw.  To narrow down the issue,
could you please add the following to /boot/loader.conf file and
test it again if your system has more than 4GB memory?
 
hw.physmem="3G"
 
The tunable above will limit system memory to 3GB.  Also show me
the output of "sysctl dev.alc.0.stats" before and after running
"ping -s 1472 remote_ip_addr" command. (Note, the ping command
with -s option requires root privilege and you have to reboot to
take changes effect).
 
If limiting system memory have no effect, could you try attached
patch and let me know whether it makes any difference?  The patch
will print "alc0: DMA CFG : 0x".  Let me know the value of
.
 
Thanks.

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"  
  
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 128954] ifconfig(8) deletes valid routes

2016-02-19 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=128954

--- Comment #2 from Marie Helene Kvello-Aune  ---
on 11-current (r295762), steps to reproduce:
# ifconfig igb1 inet 10.0.1.1/24
# route add -net 10.0.2.0/24 10.0.1.2
# netstat -rn
(...)
10.0.2.0/2410.0.1.2   UGSigb1
(...)

# ifconfig igb1 inet 10.0.1.13/24
# netstat -rn
-- the 10.0.2.0/24 route is gone --

Reading about possible causes in the linked thread, I've checked dmesg and the
interface isn't down/up'ed when changing IP.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 196944] [bge] [ipmi] regression IPMI access disabled when bge driver is loaded

2016-02-19 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196944

--- Comment #2 from Andrew Daugherity  ---
I've found the commit that breaks it: base r241438 (which was MFC into stable/9
as 243546).  Reading the commit history between 9.1 and 9.2, I saw that r248226
(MFC onto 9-stable as r248858) claims to fix IPMI on a Sun X2200 that broke
with 241838, so my first test was to see if it was working just before that.

I built a 9.2 kernel with sys/dev/bge/if_bge.c rolled back to the commit before
the "bad" one, 243541 (MFC from 241436), and IPMI works!  (I did not touch any
other files.)  Also works for a stable/9 kernel (identified as 9.3-STABLE #1
r243541:295788) with if_bge.c at 243541.

If I update if_bge.c to the commit in question (241438 aka 243546), IPMI is
broken once more.  I also tried r248858 (248226) which supposedly fixed IPMI on
those Sun servers but it did not help here.  I have not tried any other
commits, as it appears that for my hardware, it works on <=241436 and is broken
for >=241438.

I also fixed my 10.2 kernel in the same way by rolling back if_bge.c to
r241436.  I had to merge r242426 and r242625 to get it to build; after doing so
IPMI works in 10.2!

Obviously rolling all the way back like this isn't the solution for everyone,
as there have been many other commits since then, but at least I found the
breakage point.  I don't know the bge driver or kernel well enough to properly
fix it, but hopefully this is good information for someone who does.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"