Re: Intel D2500cc video problem: no scrolling
On Mon, 23 Jul 2012, Claude Buisson wrote: Both stable/9 and head suffer from no scrolling issue: from the beginning of booting the kernel, all output overrides the last line on the screen, while others keep the loader phase. just catched up with older mails on -current... ... it looks like PHK has already committed a fix into current: http://svnweb.freebsd.org/base/head/sys/dev/fb/fbreg.h?view=logpathrev=237223 MFCed on July 17 by kib@ r238555 for stable/9 r238556 for stable/8 Thanks a lot! Somehow google results does not show this even when phk has exactly the same mobo... I'll try contemporary -current tomorrow. For the archives: yes, kernel after this commit performs screen writes properly. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pxeboot with jumbo frame network
On Jul 23, 2012, at 1:58 PM, Bob Healey wrote: I know I have this working, however I don't remember what I did. I know I can pxeboot and install RHEL on a 9K frame network from a FreeBSD tftp server/NAT gateway. I do know the first thing in my RHEL install script is to set the MTU to 9K. If I have a chance later today, I'll dig into one of my install servers and try to figure out what options I used with DHCP to get it working. The trick is setting the boot time options on the client. The server side (TFTP server) is the easy part as it's already setup and running. But if the client boots and it's not jumbo frame enabled, TFTP will surely hang on getting the PXEboot as the server will be trying to send 9K UDP frames to a client that's probably defaulted to 1500. If there is a DHCP option to set the client MTU, I've not found it anywhere. -- Robert Blayzor INOC, LLC rblay...@inoc.net http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: local APIC error 0x40
On Mon, Jul 23, 2012 at 03:49:37PM -0600, Dan Allen wrote: Running FreeBSD 8.3 -- and updating sources on a daily base and building everything -- I found a new APIC/ACPI problem introduced in the past week. I have a Toshiba Satellite U205 with an Intel Core Duo (not a Core 2). It used to work fine with both cores but then sometime in on the road to BSD 8.0 the machine began hanging. So I added to /boot/loader.conf hint.apic.0.disabled=1 and the machine only had one core but it went back to being reliable. The laptop sits idle a lot, so I also have in /etc/rc.conf performance_cx_lowest=LOW and the fans stay off unless I am doing a build. Everything was good. I went away on a trip last week for five days, came home, did a csup to RELENG_8 and rebuilt the world, as usual, and now the fans are always running full! If I comment out hint.apic.0.disabled=1 from /boot/loader.conf and reboot, the results are a mixed bag: 1) I get my 2nd core back, and it no longer hangs! Hurray. 2) The fans go back to usually being off and silent. Hurray! 3) I get zillions of error messages streaming saying: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 No good! I am sitting at a prompt, no X-Windows, no apps running (other than the usual demons), and every few seconds I get another pair of these error messages. 4) The error appears benign other than flooding the console. Everything works, nothing hangs, I can build the OS and everything appears fine. So how do I get rid of these messages? What does error 0x40 mean? Does your system slows down with these messages ? 0x40 means that some code tried to send IPI with interrupt number from the range of assigned CPU faults. I believe that FreeBSD code never does that. Is there a BIOS upgrade for your machine ? pgp0dUHOcpb02.pgp Description: PGP signature
9-STABLE (238719) compilation fails on i386
Hi all. When building procstat I get this: clang -O2 -pipe -march=athlon-xp -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c /usr/src/usr.bin/procstat/procstat_vm.c /usr/src/usr.bin/procstat/procstat_vm.c:76:36: error: use of undeclared identifier 'KVME_FLAG_GROWS_UP' printf(%-1s , kve-kve_flags KVME_FLAG_GROWS_UP ? U : ^ /usr/src/usr.bin/procstat/procstat_vm.c:77:24: error: use of undeclared identifier 'KVME_FLAG_GROWS_DOWN' kve-kve_flags KVME_FLAG_GROWS_DOWN ? D : -); ^ 2 errors generated. *** [procstat_vm.o] Error code 1 Stop in /usr/src/usr.bin/procstat. -- Sphinx of black quartz judge my vow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pxeboot with jumbo frame network
On 7/24/12 6:07 AM, Robert Blayzor wrote: On Jul 23, 2012, at 1:58 PM, Bob Healey wrote: I know I have this working, however I don't remember what I did. I know I can pxeboot and install RHEL on a 9K frame network from a FreeBSD tftp server/NAT gateway. I do know the first thing in my RHEL install script is to set the MTU to 9K. If I have a chance later today, I'll dig into one of my install servers and try to figure out what options I used with DHCP to get it working. The trick is setting the boot time options on the client. The server side (TFTP server) is the easy part as it's already setup and running. But if the client boots and it's not jumbo frame enabled, TFTP will surely hang on getting the PXEboot as the server will be trying to send 9K UDP frames to a client that's probably defaulted to 1500. If there is a DHCP option to set the client MTU, I've not found it anywhere. If it's isc-dhcpd, option interface-mtu works. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
HPET broken on Dell 1950's?
I have an old Dell 1950 that I've rescued from Linux and tossed a copy of -STABLE on it, but am seeing a constant 0.5 load average. With the system completely idle, and kern.eventtimer.timer=LACPI, the load drops to the expected value of zero. This feels like it should be an FAQ, but short of noting that the load is non-zero, is there a programatic way to determine if the event timer is broken? The system was functioning just fine, but it always had a constant load even when doing absolutely nothing. ? FreeBSD ops05.internal 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #3: Tue Jul 24 17:56:59 UTC 2012 root@ops05.internal:/usr/obj/usr/src/sys/GENERIC amd64 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) LAPIC(400) i8254(100) RTC(0) kern.eventtimer.timer: HPET kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 749769877 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.hardware: HPET kern.timecounter.choice: TSC(-1000) ACPI-fast(900) HPET(950) i8254(0) dummy(-100) dev.hpet.0.%desc: High Precision Event Timer dev.hpet.0.%driver: hpet dev.hpet.0.%location: handle=\_SB_.HPET dev.hpet.0.%pnpinfo: _HID=PNP0103 _UID=0 dev.hpet.0.%parent: acpi0 -- Sean Chittenden se...@freebsd.org signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Broadcom NetXtreme bcm5720 in the 9.1 beta
I just got done installing FreeBSD-9.0 on a Dell R720. I can tell you
that none of the broadcom products will work. There is no driver that
I have been able to find. I wound up having to replace them with
Intel nics. I used the i350 quad-port 1G and the x520 for 10G Fiber.
I also had an issue with the perc h710 raid controller. ( it uses the
LSI SAS 2208 controller chip ) The FreeBSD hardware compatibility list
shows that it uses the mtp driver which is incorrect.
Below are the things I did to get them both to work
Track STABLE
csup /root/stable-supfile ; cd /usr/src/ make buildworld
Time to get the new driver source code. The SVN checkout link is here,
http://svn.freebsd.org/base/projects/head_mfi/sys/dev/mfi/
svn co http://svn.freebsd.org/base/projects/head_mfi/sys/dev/mfi/
/usr/local/src/mfi/ ; cp *.* /usr/src/sys/dev/mfi/
The new code actually added 2 new C files, so we need to add them to
one of the included make files so when we build our kernel, it will
see these new files.
Fire up vi and edit /usr/src/sys/conf/files. Find the lines with the
mfi driver files by searching for mfi, and add the following lines
after those:
dev/mfi/mfi_syspd.c optional mfi
dev/mfi/mfi_tbolt.c optional mfi
Now, since we are using stable source files, we will get the updated
mpt driver to get around the bug were this driver incorrectly tries to
attach to our RAID controller. To be safe we also edit the GENERIC
kernel config file and comment out the mpt driver altogether.
The x520 uses the 82599 drivers. they too had a few small issues
The ixgbe-2.4.4 driver had this error
In file included from ixgbe_type.h:38,
from ixgbe_api.h:38,
from ixgbe.h:96,
from ixgbe.c:40:
ixgbe_osdep.h:104: error: conflicting types for 'bool'
@/sys/types.h:271: error: previous declaration of 'bool' was here
*** Error code 1
Stop in /usr/local/src/ixgbe-2.4.4/src
I edited the /sys/types.h
#if __STDC_VERSION__ 199901L __GNUC__ 3
!defined(__INTEL_COMPILER)
typedefint_Bool;
#endif
-typedef_Boolbool;
+// typedef_Boolbool;
#endif /* !__bool_true_false_are_defined !__cplusplus */
and
ixgbe_osdep.h
+#ifndef bool
typedef boolean_t bool;
+#endif
something buggy in the ipv6 support. My netowrk doesnt use it So i
commented out the #ifdef in ixgbe.c and the code that goes with it.
3332 /* #ifdef INET6
* struct ip6_hdr *ip6;
3334 *
3335 * #endif
3336 */
3359 /*
3360 ** #ifdef INET6
3361 ** case ETHERTYPE_IPV6:
3362 ** if (mp-m_len len + sizeof(struct ip6_hdr))
3363 ** return FALSE;
3364 ** ip6 = (struct ip6_hdr *)(mp-m_data + ehdrlen);
3365 ** XXX-BZ For now we do not pretend to support ext. hdrs.
3366 ** if (ip6-ip6_nxt != IPPROTO_TCP)
3367 ** return FALSE;
3368 ** ip_hlen = sizeof(struct ip6_hdr);
3369 ** th = (struct tcphdr *)((caddr_t)ip6 + ip_hlen);
3370 ** th-th_sum = in6_cksum_pseudo(ip6, 0, IPPROTO_TCP, 0);
3371 ** type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_IPV6;
3372 ** break;
3373 ** #endif
3374 */
cd /usr/local/src/ixgbe/ ; svn co
http://svn.freebsd.org/base/stable/9/sys/dev/ixgbe/
/usr/local/src/ixgbe/ ; cp *.* /usr/src/sys/dev/ixgbe/
then edited the /usr/src/sys/conf/files and make sure that the
following lines are there
dev/ixgb/ixgb_hw.c optional ixgb
dev/ixgbe/ixgbe.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixv.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_phy.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_api.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_common.coptional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_mbx.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_vf.coptional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_82598.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_82599.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_x540.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
Built the kernel
cd /usr/src make buildkernel KERNCONF=GENERIC
Make the release so I can get an .iso image with everything i need to
get those things working
cd /usr/src/release make release
ISO file will be located here when completed
/usr/obj/usr/src/release/release.iso
From there I open the drac console and use the virtual media to mount
that iso and install FreeBSD-9.0 and both the RAID and Intel nics
work.
Best of Luck
Pete
On Mon, Jul 23, 2012 at 6:52 PM,
Re: freebsd-stable Digest, Vol 470, Issue 7
On Sat, 21 Jul 2012, Matthew D. Fuller fulle...@over-yonder.net writes I'm running a M5A97 Evo just fine on -CURRENT, and I'd be shocked it it had any problem with 9 (or 8 or 7, for that matter). The external SATA ports on that board aren't AHCI. To quote an authority[1], apart from that, he's *perfectly* alright. regards, Ross [1] M. Python -- Ross Alexander, (780) 675-6823 / (780) 689-0749, r...@athabascau.ca Always do right. This will gratify some people, and astound the rest. -- Samuel Clemens -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Latest stable/8 broken for mozilla ports
For both firefox and thunderbird I'm getting this: firefox Fatal error 'locklevel = 0' at line 98 in file /frontier/svn/stable/8/lib/libthr/thread/thr_kern.c (errno = 2) Redirecting call to abort() to mozalloc_abort Segmentation fault: 11 (core dumped) This is on r238752, previous working version was r238655 thr_kern.c hasn't been updated since the last 8-release, so it would seem to be something else. Insights welcome, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: local APIC error 0x40
On 24 Jul 2012, at 4:26 AM, Konstantin Belousov kostik...@gmail.com wrote: Does your system slows down with these messages ? 0x40 means that some code tried to send IPI with interrupt number from the range of assigned CPU faults. I believe that FreeBSD code never does that. Is there a BIOS upgrade for your machine ? No, the system does not slow down. I am checking on the BIOS upgrade. Dan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Latest stable/8 broken for mozilla ports (fwd)
Hi Doug; Perhaps you are using -O2 in you CFLAGS? There were reports of gcc issues when optimizing but we never found the smoking gun. Pedro. From: Doug Barton do...@freebsd.org Since I know many of you don't read -stable ... please follow up there though. -- Forwarded message -- From: Doug Barton do...@freebsd.org To: freebsd-stable@FreeBSD.org Date: Tue, 24 Jul 2012 13:41:58 Organization: http://SupersetSolutions.com/ User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Subject: Latest stable/8 broken for mozilla ports For both firefox and thunderbird I'm getting this: firefox Fatal error 'locklevel = 0' at line 98 in file /frontier/svn/stable/8/lib/libthr/thread/thr_kern.c (errno = 2) Redirecting call to abort() to mozalloc_abort Segmentation fault: 11 (core dumped) This is on r238752, previous working version was r238655 thr_kern.c hasn't been updated since the last 8-release, so it would seem to be something else. Insights welcome, Doug -- This mail is for the internal use of the FreeBSD project committers, and as such is private. This mail may not be published or forwarded outside the FreeBSD committers' group or disclosed to other unauthorised parties without the explicit permission of the author(s). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Latest stable/8 broken for mozilla ports (fwd)
On 7/24/2012 2:09 PM, Pedro Giffuni wrote: Hi Doug; Perhaps you are using -O2 in you CFLAGS? I use the standard CFLAGS, so I'm assuming the answer is yes. :) And in case my previous message wasn't clear, this worked fine until just today. Also, I forgot to add that recompiling firefox didn't help. Doug -- Change is hard. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Latest stable/8 broken for mozilla ports
On Tue, Jul 24, 2012 at 01:41:58PM -0700, Doug Barton wrote: For both firefox and thunderbird I'm getting this: firefox Fatal error 'locklevel = 0' at line 98 in file /frontier/svn/stable/8/lib/libthr/thread/thr_kern.c (errno = 2) Redirecting call to abort() to mozalloc_abort Segmentation fault: 11 (core dumped) This is on r238752, previous working version was r238655 thr_kern.c hasn't been updated since the last 8-release, so it would seem to be something else. Insights welcome, Doug Does reverting of r238715 fix your issue ? pgppa2aWpKvGa.pgp Description: PGP signature
Re: Broadcom NetXtreme bcm5720 in the 9.1 beta
On Tue, 2012-07-24 at 12:16 -0700, Peter Feger wrote: I just got done installing FreeBSD-9.0 on a Dell R720. I can tell you that none of the broadcom products will work. There is no driver that I have been able to find. I wound up having to replace them with Intel nics. I used the i350 quad-port 1G and the x520 for 10G Fiber. Confirmed over here at Yahoo. The intel replacement board seems to just work with stable/9 for me. I also had an issue with the perc h710 raid controller. ( it uses the LSI SAS 2208 controller chip ) The FreeBSD hardware compatibility list shows that it uses the mtp driver which is incorrect. Yeah, we should get that corrected. This card is supported by stable/9 mfi(4) Sean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Latest stable/8 broken for mozilla ports
On Wed, 25 Jul 2012, Konstantin Belousov wrote: On Tue, Jul 24, 2012 at 01:41:58PM -0700, Doug Barton wrote: For both firefox and thunderbird I'm getting this: firefox Fatal error 'locklevel = 0' at line 98 in file /frontier/svn/stable/8/lib/libthr/thread/thr_kern.c (errno = 2) Redirecting call to abort() to mozalloc_abort Segmentation fault: 11 (core dumped) This is on r238752, previous working version was r238655 thr_kern.c hasn't been updated since the last 8-release, so it would seem to be something else. Insights welcome, Doug Does reverting of r238715 fix your issue ? Yes, it certainly seems to. Previously firefox dumped immediately when I tried to start it. Now it is running Ok. I'll try thunderbird after I finish this message. This should probably be reverted ASAP before other stable/8 users run into it. Also, FWIW, looking at the log that MFC put mergeinfo directly onto the 2 files affected. It almost certainly should have been done at lib/libthr instead. Doug ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Broadcom NetXtreme bcm5720 in the 9.1 beta
yes, it is only the NIC's I want/need. I have an Intel card in it right
now, but its just a single port the onboard NIC's would be a nice to have.
The raid worked out of the box for me, please remember 9.1beta thou.
Thanks
On 25/07/12 05:16, Peter Feger wrote:
I just got done installing FreeBSD-9.0 on a Dell R720. I can tell you
that none of the broadcom products will work. There is no driver that
I have been able to find. I wound up having to replace them with
Intel nics. I used the i350 quad-port 1G and the x520 for 10G Fiber.
I also had an issue with the perc h710 raid controller. ( it uses the
LSI SAS 2208 controller chip ) The FreeBSD hardware compatibility list
shows that it uses the mtp driver which is incorrect.
Below are the things I did to get them both to work
Track STABLE
csup /root/stable-supfile ; cd /usr/src/ make buildworld
Time to get the new driver source code. The SVN checkout link is here,
http://svn.freebsd.org/base/projects/head_mfi/sys/dev/mfi/
svn co http://svn.freebsd.org/base/projects/head_mfi/sys/dev/mfi/
/usr/local/src/mfi/ ; cp *.* /usr/src/sys/dev/mfi/
The new code actually added 2 new C files, so we need to add them to
one of the included make files so when we build our kernel, it will
see these new files.
Fire up vi and edit /usr/src/sys/conf/files. Find the lines with the
mfi driver files by searching for mfi, and add the following lines
after those:
dev/mfi/mfi_syspd.c optional mfi
dev/mfi/mfi_tbolt.c optional mfi
Now, since we are using stable source files, we will get the updated
mpt driver to get around the bug were this driver incorrectly tries to
attach to our RAID controller. To be safe we also edit the GENERIC
kernel config file and comment out the mpt driver altogether.
The x520 uses the 82599 drivers. they too had a few small issues
The ixgbe-2.4.4 driver had this error
In file included from ixgbe_type.h:38,
from ixgbe_api.h:38,
from ixgbe.h:96,
from ixgbe.c:40:
ixgbe_osdep.h:104: error: conflicting types for 'bool'
@/sys/types.h:271: error: previous declaration of 'bool' was here
*** Error code 1
Stop in /usr/local/src/ixgbe-2.4.4/src
I edited the /sys/types.h
#if __STDC_VERSION__ 199901L __GNUC__ 3
!defined(__INTEL_COMPILER)
typedefint_Bool;
#endif
-typedef_Boolbool;
+// typedef_Boolbool;
#endif /* !__bool_true_false_are_defined !__cplusplus */
and
ixgbe_osdep.h
+#ifndef bool
typedef boolean_t bool;
+#endif
something buggy in the ipv6 support. My netowrk doesnt use it So i
commented out the #ifdef in ixgbe.c and the code that goes with it.
3332 /* #ifdef INET6
* struct ip6_hdr *ip6;
3334 *
3335 * #endif
3336 */
3359 /*
3360 ** #ifdef INET6
3361 ** case ETHERTYPE_IPV6:
3362 ** if (mp-m_len len + sizeof(struct ip6_hdr))
3363 ** return FALSE;
3364 ** ip6 = (struct ip6_hdr *)(mp-m_data + ehdrlen);
3365 ** XXX-BZ For now we do not pretend to support ext. hdrs.
3366 ** if (ip6-ip6_nxt != IPPROTO_TCP)
3367 ** return FALSE;
3368 ** ip_hlen = sizeof(struct ip6_hdr);
3369 ** th = (struct tcphdr *)((caddr_t)ip6 + ip_hlen);
3370 ** th-th_sum = in6_cksum_pseudo(ip6, 0, IPPROTO_TCP, 0);
3371 ** type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_IPV6;
3372 ** break;
3373 ** #endif
3374 */
cd /usr/local/src/ixgbe/ ; svn co
http://svn.freebsd.org/base/stable/9/sys/dev/ixgbe/
/usr/local/src/ixgbe/ ; cp *.* /usr/src/sys/dev/ixgbe/
then edited the /usr/src/sys/conf/files and make sure that the
following lines are there
dev/ixgb/ixgb_hw.c optional ixgb
dev/ixgbe/ixgbe.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixv.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_phy.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_api.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_common.coptional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_mbx.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_vf.coptional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_82598.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_82599.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_x540.c optional ixgbe inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
Built the kernel
cd /usr/src make buildkernel KERNCONF=GENERIC
Make the release so I can get an .iso image with everything i need to
get those things working
cd
Re: local APIC error 0x40
On 24 Jul 2012, at 4:26 AM, Konstantin Belousov kostik...@gmail.com wrote: Does your system slows down with these messages ? 0x40 means that some code tried to send IPI with interrupt number from the range of assigned CPU faults. I believe that FreeBSD code never does that. So, I reverted to $FreeBSD: src/sys/i386/i386/machdep.c,v 1.688.2.31 2012/06/13 15:25:52 jhb Exp $ and rebuilt the kernel. By making that one change my fan problem is fixed! No more 0x40 msgs, although I only have 1 core again due to my use of hint.apic.0.disabled=1 in /boot/loader.conf. So, the most recent changes done to machdep.c are the culprit! I also booted from a FreeBSD 9.0 CD and it has the same string of 0x40 error messages with its default configuration and an empty /boot/loader.conf file, so both the latest changes to BSD 8.3 as well as the BSD 9.0+ tree have got dealing with Intel Core Duo chips wrong. (My Pentium 4 and Intel Atom machines running RELENG_9 are fine and show no problems. It is just my old Toshiba Satellite U205 w/Core Duo that has these problems.) I booted from an OpenBSD 5.0 CD and it works just fine in every way. Maybe I'll just run OpenBSD 5 on the Toshiba and call it a day. Dan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Regression in stable for ThinkPad T520 with Intel GPU (Sandybridge) between June 22 and July 18
I will shortly spend a bit of time tracking down the breakage more closely, but my 9-Stable system of June 22 runs fine. After an update on about July 10, I noted that it would hang after Xorg was started, but usually worked. After an upgrade to July 18, my system could no longer start Gnome. It would start Xorg and Gnome would start normally, getting many apps started, but about 10 seconds after the wallpaper loaded, the system would freeze solid. No network access and no response to mouse or keyboard. I have looked into commits to 9-STABLE during the time at issue and very little seems to have changed due to the pre-9.1 freeze. Similarly, nothing much has changed in any of the X11 ports. This really smells a lot like a race condition. I can trigger the same behavior by enabling VT-x (not VT-d) in BIOS. In all cases where it was intermittent, if my desktop completed startup, the system runs fine until re-booted. This is probably the primary reason I might not have realized that there was a problem as I don't boot the system often except when traveling, which I was between July 1 and July 6 and again July 18 when the system died. Any idea what I might try looking at? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Broadcom NetXtreme bcm5720 in the 9.1 beta
Peter Feger magick...@gmail.com wrote in CAD_3y4wAPp+8ZSveB6mbOF7M1Ne-zAvz4Uf=vv9quohuu23...@mail.gmail.com: ma I just got done installing FreeBSD-9.0 on a Dell R720. I can tell you ma that none of the broadcom products will work. There is no driver that ma I have been able to find. I wound up having to replace them with ma Intel nics. I used the i350 quad-port 1G and the x520 for 10G Fiber. I recently bought a Dell R420 which had BCM 5720 as the LOM. The output of pciconf was the following: bge0@pci0:2:0:0:class=0x02 card=0x04f81028 chip=0x165f14e4 rev=0x00 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM5720 Gigabit Ethernet PCIe' class = network subclass = ethernet On 9.1-PRERELEASE as of Jul 23, it was recognized but did not work properly first (the link-status went back and forth between up and down). However, after setting dev.bge.0.msi=0 it worked. I am not sure of whether it had decent communication speed or not, but I saw it worked with 50MB/s or so at least. IPMI over LAN did not work even if hw.bge.allow_asf was set to 1. -- Hiroki pgp5uvlqIwwQg.pgp Description: PGP signature
