Freebsd 13.0-BETA*: Asus P9X79-based host not powering down
Hi, I am still using a core-i7-3820 CPU on a Asus P9X79 motherboard that works well on 13.0 BETA, except that when using "shutdown -p" or "halt" commands, the system will reboot instead of powering down. It worked quite well for as long as I had FreeBSD on this machine (since 10 I think?) using UEFI boot and previous BIOS compatibilites disabled, I even reinstalled from scratch (mainly to have a bigger EFI partition). Is there some acpi settings I can play around? Thanks a lot -- Matthieu Volat pgpcpgt2VWpPQ.pgp Description: OpenPGP digital signature
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Wed, 17 Oct 2018 12:27:48 -0600 Warner Losh wrote: > On Wed, Oct 17, 2018 at 11:52 AM Matthieu Volat wrote: > > > Would it be possible to set a wiki page/section in 12 that display the > > current status of removal of those devices? That might be easier for people > > to look at their hardware actual state rather than try to trace every > > answer to this thread... > > > > The FCP is being updated and will be uploaded when that's done. At > this point, it seems that we have all the data to make the right decisions, > at least to tag the drivers deprecated for the 12.0 release when I'm sure > will get us additional data. > > Warner Thanks for the info! pgp4M_S5QLJi5.pgp Description: OpenPGP digital signature
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Wed, 3 Oct 2018 21:05:16 + Brooks Davis wrote: > >>> Please direct replies to freebsd-arch <<< > > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md) > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12 > and remove them in FreeBSD 13 to reduce the burden of maintaining and > improving the network stack. We have discussed this within the > core team and intend to move forward as proposed. We are solictiting > feedback on the list of drivers to be excepted from removal. > > The current list of drivers slated for REMOVAL is: > > ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn, > ste, tl, tx, txp, vx, wb, xe > > The current list of drivers that will STAY in the tree is: > > dc, ffec, fxpl, hme, le, sis, vr, xl > > The criteria for exception are: > - Popular in applications where it is likely to be deployed beyond the >support lifetime of FreeBSD 12 (late 2023). >- 5 reports of uses in the wild on machines running FreeBSD 12 will be > deemed satisfy the "popular" > requirement. > - Required to make a well supported embedded or emulation platform usable. > - Ported to use iflib (reducing future maintenance cost.) > > Please reply to this message with nominations to the exception list. > > The full FCP-0101 is included below. > > -- Brooks > > --- > authors: Brooks Davis > state: feedback > --- > > # FCP 101: Deprecation and removal of 10/100 Ethernet drivers > > Deprecate most 10 and 10/100Mbps Ethernet drivers and remove them before > FreeBSD 13. > > ## Problem Statement > > Each network driver creates drag for the project as we attempt to > improve the network stack or provide new features such as expanded > 32-bit compatibility. For example, the author has edited every single > NIC driver more than once in the past year to update management (`ioctl`) > interfaces. We could improve this situation by converting drivers to > iflib, but each additional driver takes work. > > 10 and 100 megabit Ethernet drivers are largely irrelevant today > and we have a significant number of them in the tree. The ones that > are no longer used and/or are not known to be working need to be > removed due to the significant ongoing 'tax' on new development. > > For at least a decade, most systems (including small embedded > systems) have shipped with gigabit Ethernet devices and virtual > machines commonly emulate popular gigabit devices. We wish to > retain support for popular physical and virtual devices while > removing support for uncommon ones. With a few exceptions these > drivers are unlikely to be used by our user base by the time FreeBSD > 12 is obsolete (approximately 2024). > > ## Proposed Solution > > We propose to deprecate devices which are not sufficiently popular. This > will entail: > - (October 2018) Send this list to freebsd-net and freebsd-stable. > - (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and >attach routines for each device to be removed and merge those changes >to FreeBSD 12. > - (One month after FreeBSD 12.0-RELEASE - January 2018) Remind >freebsd-net and freebsd-stable users of pending deletion. > - (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete deprecated >devices. > > Through out this process, solicit feedback on additions to the exception > list and update this document as required. For a device to be placed on > the exception list the device must meet one of the following criteria: > - Popular in applications where it is likely to be deployed beyond the >support lifetime of FreeBSD 12 (late 2023). >- 5 reports of uses in the wild on machines running FreeBSD 12 will be > deemed satisfy the "popular" > requirement. > - Required to make a well supported embedded or emulation platform usable. > - Ported to use iflib (reducing future maintenance cost.) > > ### Exceptions to removal > > Device | Reason > ---|- > ffec | Onboard Ethernet for Vybrid arm7 boards > fxp| Popular device long recommended by the project. > dc | Popular device for CardBus card. > hme| Built in interface on many supported sparc64 platforms. > le | Emulated by QEMU, alternatives don't yet work for mips64. > sis| Soekris Engineering net45xx, net48xx, lan1621, and lan1641. > vr | Soekris Engineering net5501, some Asus motherboards. > xl | Popular device for CardBus card. > > Note: USB devices have been excluded from consideration in this round. > > ### Device to be removed > > ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn, > ste, tl, tx, txp, vx, wb, xe > > ## Final Disposition > > TBD Would it be possible to set a wiki page/section in 12 that display the current status of removal of those devices? That might be easier for people to look at their hardware actual state rather than try to trace every answer to this thread... Thanks a lot!
Re: Benchmarks results for FreeBSD 11
On Sun, 28 Aug 2016 14:55:37 +0200 Dimitry Andric <d...@freebsd.org> wrote: > On 28 Aug 2016, at 02:10, K. Macy <km...@freebsd.org> wrote: > > > >> The problem here is that Phoronix took a Beta version of FreeBSD 11. > >> Beta versions have a lot of debugging (malloc, invariants, witness) > >> options enabled which make it significantly slower than release > >> versions. This is even obviously when you run a Beta as a desktop. It > >> just feels much slower. > > > > > > I don't know what was going on in these particular tests, but in a > > more recent benchmarking run > > -https://www.phoronix.com/scan.php?page=article=freebsd11-clang-gcc=1 > > - you're seeing the result of openmp being disabled in base. The clang > > maintainer for src refuses to include libomp as required for -fopenmp > > because nothing in base requires it. > > Come on, this is nonsense. I have indicated earlier that I would have > liked to import openmp into base, but this was shot down precisely for > that reason: nothing in base uses it. > > So for now, the solution is simply: install one of the llvm ports, and > use it. These have configuration setting to install every optional > component from the LLVM project. > > -Dimitry > With 11, one can even simply install devel/openmp which will only install the libopenmp bits from llvm, and after that, base cc can do openmp. -- Matthieu Volat <ma...@alkumuna.eu> pgpMac1sRLat2.pgp Description: OpenPGP digital signature
Re: Benchmarks results for FreeBSD 11
On Fri, 26 Aug 2016 13:20:59 +0800 Erich Dollansky <erichsfreebsdl...@alogt.com> wrote: > Hi, > > On Wed, 24 Aug 2016 13:12:24 +0200 > Fernando Herrero Carrón <elfe...@gmail.com> wrote: > > > Many ports offer an option to compile with optimized cflags. See for > > instance http://www.freshports.org/multimedia/ffmpeg: > > > > OPTIMIZED_CFLAGS=off: Use extra compiler optimizations > > > > though: > > > > SSE=on: Use SSE optimized routines > > > > It turns out that optimization options are usually off by default, so > > if we assume Micheal has built the test suite from ports, it is all to > the defaults. I also do not see a compiler option. With the compiler > option, the same compiler could be used on all platforms. I think at some point, he mentionned that PC-BSD could/would be the basis for the FreeBSD benchmarks at phoronix (due to deployment considerations). In that case, the options used in PC-BSD packages should be taken into account... > > I am not even sure if the same compiler was used on the Linux platforms. No, when he does OSes benchmarks, he make them compete with the compiler the OS provides. But he sometimes do compiler benchmarks. > > Erich > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Matthieu Volat <ma...@alkumuna.eu> tel: 06 84 54 39 43 www: <http://500px.com/Mazhe> pgpNHS4wfN_Vr.pgp Description: OpenPGP digital signature
Re: Two questions for FreeBSD 11: libgcc & pkg
First, thanks for your time! On Wed, 27 Jul 2016 15:14:49 -0700 Kevin Oberman <rkober...@gmail.com> wrote: > On Wed, Jul 27, 2016 at 10:42 AM, Matthieu Volat <ma...@alkumuna.eu> wrote: > > > Hi, if somebody would be kind enough to educate me, I've two small > > questions about the 11 release. > > > > > > First, https://wiki.freebsd.org/WhatsNew/FreeBSD11 mention that libgcc > > was replaced by libcompiler_rt, yet after the freebsd-update > > upgrade/install/install/portmaster -af/install routine, I still have a > > (recently updated) libgcc: > > > > # ls -l /lib/libgcc_s.so.1 > > -r--r--r-- 1 root wheel 56608 Jul 26 14:13 /lib/libgcc_s.so.1 > > > > Is it normal? > > > > I think so, but I am not sure. Is libcompiler_rt found? It seems likely the > old library is retrained for existing images linked to it while > libcompiler_rt is now used when new images are linked. (N.B. This is a > guess, though.) Things are a bit strange: there is a static libcompiler_rt library in /usr/lib. A few executable in /usr/bin seems to still use libgcc (groff/troff stuff mainly). So maybe this is still in a transitional stage... Base cc/c+++ seems to be sane since I managed to rebuild all the installed ports. > > > > Second question is about the talks that the base system would be > > pkg-ized (https://wiki.freebsd.org/PkgBase). Do base pkgs share the same > > pkg database as ports pkgs? Can I now damage base installation with bad pkg > > usage? > > > > I don't have the message handy, but several issues popped up that forced > the delay if the packaging of teh base system until at least 11.1. You can > probably look in the current@ archive to find the note. Thanks, I was not sure I did not miss some pre-release instruction to migrate settings as nothing would show up in pkg info and such. > > > > Thanks a lot for answers! > > > > -- > > Matthieu Volat <ma...@alkumuna.eu> > > > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 -- Matthieu Volat <ma...@alkumuna.eu> tel: 06 84 54 39 43 www: <http://500px.com/Mazhe> pgpI2U5PgknPi.pgp Description: OpenPGP digital signature
Two questions for FreeBSD 11: libgcc & pkg
Hi, if somebody would be kind enough to educate me, I've two small questions about the 11 release. First, https://wiki.freebsd.org/WhatsNew/FreeBSD11 mention that libgcc was replaced by libcompiler_rt, yet after the freebsd-update upgrade/install/install/portmaster -af/install routine, I still have a (recently updated) libgcc: # ls -l /lib/libgcc_s.so.1 -r--r--r-- 1 root wheel 56608 Jul 26 14:13 /lib/libgcc_s.so.1 Is it normal? Second question is about the talks that the base system would be pkg-ized (https://wiki.freebsd.org/PkgBase). Do base pkgs share the same pkg database as ports pkgs? Can I now damage base installation with bad pkg usage? Thanks a lot for answers! -- Matthieu Volat <ma...@alkumuna.eu> pgpTlNwuwx_nj.pgp Description: OpenPGP digital signature
Re: MFC r282973 (disable libgomp build) and r283060 (disable libgcov build)?
On Fri, 24 Jul 2015 21:40:32 + Brooks Davis bro...@freebsd.org wrote: On Fri, Jul 24, 2015 at 02:15:28PM -0700, Don Lewis wrote: On 24 Jul, Matthieu Volat wrote: I'm not fond of lang/gcc as openmp provider: if a port use c++, it will cause linkage headaches with libc++ (I never was able to have graphics/darktable working, for example). You might want to try out lang/clang-devel with devel/libiomp5-devel. See this thread on freebsd-ports@ http://docs.freebsd.org/cgi/mid.cgi?55AE0474.5050207. Just a heads up in case you try this next week, devel/libiomp5-devel is about to be deleted and the openmp library (as well as clang-devel) will be installed by the llvm-devel port. The clang-devel port will become a metaport to aid people in finding clang while we wait for multiple packages-per-port support. -- Brooks Thanks, and nicely done, I just tested it this morning, this may come in handy! -- Matthieu Volat ma...@alkumuna.eu pgpohWs7jVfyc.pgp Description: OpenPGP digital signature
Re: MFC r282973 (disable libgomp build) and r283060 (disable libgcov build)?
On Mon, 20 Jul 2015 14:03:01 -0700 (PDT) Don Lewis truck...@freebsd.org wrote: Should r282973 and r283060 be MFCed to FreeBSD 10? On amd64 and i386, which use clang as their base compiler and don't have gcc in base by default, the math/scilab port uses clang for cc and c++ compilation, but finds /usr/include/omp.h (and links to libgomp from lang/gcc). The build succeeds, but I suspect this may not run properly. Does it mean the door to an openmp-enabled cc in base is closed? I'm not fond of lang/gcc as openmp provider: if a port use c++, it will cause linkage headaches with libc++ (I never was able to have graphics/darktable working, for example). -- Matthieu Volat ma...@alkumuna.eu pgpS7ek1wt4jg.pgp Description: OpenPGP digital signature
Re: 9.2-PRE: switch off that stupid Nakatomi Socrates
Le 30 sept. 2013 à 01:54, Ricardo Ferreira ricardo.ferre...@sotechdatacenter.com.br a écrit : Em 29-09-2013 19:11, Charles Sprickman escreveu: On Sep 29, 2013, at 3:28 PM, C. P. Ghost wrote: On 28.09.2013 11:32, Phil Regnauld wrote: Teske, Devin (Devin.Teske) writes: If you work seriously on serious issues long enough... you'll become burned- out. Let me just come right out and say it... I coded it. And thanks, you got me chuckling - nice to see some humor once in a while. To the offended poster: read the last line of tunefs(8) - there's probably many more places you could use serious time looking for deviations from corporate correctnes. Humor can even be etched in silicon, like e.g. on an IC created by Siemens: http://micro.magnet.fsu.edu/creatures/pages/bunny.html Cisco too, besides weird Star Wars ROM messages, you have stuff like the BFR (Big F*cking Router, after Big F*cking Gun in Doom) screened on the PCB: https://www.kumari.net/gallery/index.php/Technology/Networking/BFR_2_001 https://www.kumari.net/gallery/index.php/Technology/Networking/BFR_2 I have no idea what Sluggo and Nancy are doing on this board: https://www.kumari.net/gallery/index.php/Technology/Networking/CIMG0988 Charles ;-) -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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 ___ 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 keep it cool u have others like: man chmod... BUGS There is no perm option for the naughty bits of a horse. and so many others. So... I find strange nobody mentioned the one in make :) % make love Not War. -- Mazhe signature.asc Description: Message signed with OpenPGP using GPGMail
9.2-RC1, nfe, auto_linklocal : ioctl(SIOCGIFINFO_IN6): Invalid argument
Hi, I've noticed that with 9.2-RC1, I cannot set/unset the auto_locallink flag on the nfe network interface on my laptop: # ifconfig nfe0 -auto_linklocal ifconfig: ioctl(SIOCGIFINFO_IN6): Invalid argument The error is also raised at boot if net.inet6.ip6.auto_linklocal sysctl is set to 0. I can't test for now if this problem was also present in 9.1 (I've just began to use this flag instead of removing local addresses in rc.conf), but I can give more information if given the commands/files to read. -- Mazhe signature.asc Description: PGP signature
Re: 9.2-RC1, nfe, auto_linklocal : ioctl(SIOCGIFINFO_IN6): Invalid argument
On Wed, 14 Aug 2013 23:02:40 +0400 Andrey V. Elsukov bu7c...@yandex.ru wrote: On 14.08.2013 22:55, Matthieu Volat wrote: Hi, I've noticed that with 9.2-RC1, I cannot set/unset the auto_locallink flag on the nfe network interface on my laptop: # ifconfig nfe0 -auto_linklocal ifconfig: ioctl(SIOCGIFINFO_IN6): Invalid argument I think you should use `ifconfig nfe0 inet6 -auto_linklocal`. -- WBR, Andrey V. Elsukov My bad, you are definitively right! I wonder why the global sysctl would not disable linklocal adress on this interface, but I'd prefer to control it through the ifconfig_*_ipv6 fields interface by interface, so that's not really a problem. Thanks! -- Mazhe signature.asc Description: PGP signature
Re: IKEv2/IPSEC Road Warrior VPN Tunneling?
On Thu, 11 Apr 2013 17:31:37 -0500 Karl Denninger k...@denninger.net wrote: Is there a cookbook for setting this up? There are examples for setting up a tunnel between two fixed-address networks (e.g. a remote LAN that needs to be integrated with a central LAN over IPSec but I can't find anything addressing the other situation -- remote user(s) where the connecting IPs are not known in advance, such as a person with a laptop or smartphone in a random hotel. (And is there a better list for this in the freebsd-* paradigm for the question?) Sorry for answering this late, As mentionned in another answer, you can start with the roadwarrior server/client configuration in ipsec-tools examples. To work with FreeBSD, the phase1-up.sh and phase1-down.sh scripts must be customized. I've attached both scripts, tell me if it does not work, I'll upload them somewhere (maybe propose them for inclusion in the port tree?) -- Matthieu Volat ma...@alkumuna.eu ___ 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
9.0-Release and Asus P5-NE motherboard
Hello, For a week, I have been trying to boot the FreeBSD 9 installation media (usb, cdrom) on a computer with an Asus P5-NE motherboard (amd64, nvidia MCP51 controller), but the kernel fails to initialize correctly. Using the verbose mode, I was able to capture the following warnings/errors : ahcich0: AHCI reset... ugen0.1: nVidia at usbu0 uhub0: nVidia OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: nVidia at usbu1 uhub1: nVidia EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus2 ahacih0: SATA connect timeout time=1us status= ahacih0: AHCI reset: device not found ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=00 stat1=00 devices=0x3 (aprobe0:ata0:0:0:0): SIGNATURE: eb14 ata1: reset tp1 mask=03 ostat0=60 ostat1=70 ata1: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata1: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 ata1: reset tp2 stat0=20 stat1=30 devices=0x0 ata2: SATA connect time=0ms status=0123 ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 (aprobe1:ata2:0:0:0): SIGNATURE: ata3: SATA connect time=0ms status=0123 ata3: reset tp1 mask=01 ostat0=50 ostat1=00 uhub0: 8 ports with 8 removable, self powered ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 (aprobe2:ata3:0:0:0): SIGNATURE: ata4: SATA connect timeout status=000 ata5: SATA connect timeout status=000 uhub1: 8 ports with 8 removable, self powered usb_alloc_device: net address 2 failed (USB_ERR_TIMEOUT, ignored) usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) ata3: stat0=0xd8 err=0x00 lsb=0x00 msb=0x00 ata3: stat0=0xd8 err=0x00 lsb=0x00 msb=0x00 ata3: stat0=0xd8 err=0x00 lsb=0x00 msb=0x00 [message repeated a lot of times] ata3: reset tp2 stat0=d8 stat1=00 devices=0x0 (aprobe2:ata3:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 (aprobe2:ata3:0:0:0): CAM status: Command timeout ata0: reset tp1 mask=03 ostat0=58 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=00 stat1=00 devices=0x3 (aprobe0:ata0:0:0:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata0:0:0:0): CAM status: Command timeout (aprobe0:ata0:0:1:0): SIGNATURE: eb14 ata2: SATA connect time=0ms status=0123 ata2: reset tp1 mask=01 ostat0=58 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 (aprobe1:ata:ata2:0:0:0) ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 (aprobe1:ata:ata2:0:0:0) CAM status: Command timeout run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config ugen1.2: Unknown at usbus1 (disconnected) usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) ata0: reset tp1 mask=03 ostat0=00 ostat1=58 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=00 stat1=00 devices=0x3 (aprobe0:ata0:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata0:0:1:0): CAM status: Command timeout run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config This machine worked (and still works) fine with 8.2... If somebody have an idea... -- Matthieu Volat ma...@alkumuna.eu ___ 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: 9.0-Release and Asus P5-NE motherboard
On Fri, 20 Jan 2012 09:28:55 -0500
John Baldwin j...@freebsd.org wrote:
On Friday, January 20, 2012 8:21:28 am Matthieu Volat wrote:
Hello,
For a week, I have been trying to boot the FreeBSD 9 installation media
(usb, cdrom) on a computer with an Asus P5-NE motherboard (amd64, nvidia
MCP51
controller), but the kernel fails to initialize correctly.
I think the problem is with the nvidia chipset and MSI support. There's not
an easy way to fix it via a tunable unfortunately. You can try hacking
sys/dev/pci/pci.c to disable this code:
#if defined(__i386__) || defined(__amd64__) || defined(__powerpc__)
/*
* Enable the MSI mapping window for all HyperTransport
* slaves. PCI-PCI bridges have their windows enabled via
* PCIB_MAP_MSI().
*/
if (cfg-ht.ht_slave != 0 cfg-ht.ht_msimap != 0
!(cfg-ht.ht_msictrl PCIM_HTCMD_MSI_ENABLE)) {
device_printf(pcib,
Enabling MSI window for HyperTransport slave at pci%d:%d:%d:%d\n,
cfg-domain, cfg-bus, cfg-slot, cfg-func);
cfg-ht.ht_msictrl |= PCIM_HTCMD_MSI_ENABLE;
WREG(cfg-ht.ht_msimap + PCIR_HT_COMMAND, cfg-ht.ht_msictrl,
2);
}
#endif
--
John Baldwin
Thanks, you are absolutely right, I compiled a kernel disabling MSI-X support
and it booted.
I wonder how this worked previously and not now. From what I see, there is a
blacklist to disable unsupported chipsets...
Maybe this chipset should be added as a workaround (I wonder if I'm the only
one with the problem)...
The only references I found about MCP51 and MSI-X
(http://lists.freebsd.org/pipermail/svn-src-head/2010-November/022551.html)
seems to indicates that the chipset should work, but maybe with extra code...
I'm willing to test patches so if somebody wants to have a look.
--
Matthieu Volat ma...@alkumuna.eu
___
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
