Re: what do I do when git cherry-pick works, but results are bogus?
On Wed, 17 May 2023, 17:44 Rick Macklem, wrote: > So, the subject line basically says it. > I do a git cherry-pick to MFC. It works, but the resultant file(s) are not > correct. What do I do to fix this? > (If the merge fails, then it's easy, but there doesn't seem to be an option > on cherry-pick that forces it into "merge failed", so you can edit/add > the file > and then "git cherry-pick --continue".) > If you're cherry-picking multiple commits then you can turn the problem into a rebase After the cherry-pick commits are created, then run git rebase -i Then change the `i` at the start of the line for the broken commit to `e` (edit) before saving the plan file
RE: UEFI GOP: screen goes blank during boot after loader is finished
-Original Message- From: owner-freebsd-virtualizat...@freebsd.org On Behalf Of Warner Losh Sent: 15 November 2018 02:57 To: Kyle Evans Cc: FreeBSD Current ; Rodney W. Grimes ; freebsd-virtualizat...@freebsd.org Subject: Re: UEFI GOP: screen goes blank during boot after loader is finished On Wed, Nov 14, 2018 at 4:00 PM Kyle Evans wrote: > On Wed, Nov 14, 2018 at 4:55 PM Subbsd wrote: > > > > On Thu, Nov 15, 2018 at 1:33 AM Kyle Evans wrote: > > > > > > On Wed, Nov 14, 2018 at 4:30 PM Kyle Evans wrote: > > > > > > > > On Wed, Nov 14, 2018 at 4:23 PM Subbsd wrote: > > > > > > > > > > On Thu, Nov 15, 2018 at 1:05 AM Subbsd wrote: > > > > > > > > > > > > On Thu, Nov 15, 2018 at 12:21 AM Rebecca Cran < > rebe...@bluestop.org> wrote: > > > > > > > > > > > > > > On November 14, 2018 at 2:18:04 PM, Subbsd > > > > > > > (sub...@gmail.com) > wrote: > > > > > > >> > > > > > > >> > > > > > > >> My current host: FreeBSD 13.0-CURRENT r340319 and the > > > > > > >> problem > is > > > > > > >> still present. > > > > > > > > > > > > > > Rod was asking about the guest OS version, not the host though. > > > > > > > > > > > > > > > > > > > > > > > > > > I apologize, it seemed to me that I wrote earlier) Guest version: > > > > > > > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0 > /FreeBSD-13.0-CURRENT-amd64-20181101-r339979-disc1.iso.xz > > > > > > > > > > Hm, it seems the problem is 'boot_serial' which is sets to YES > > > > > by > default in gop > > > > > > > > > > set boot_serial=NO > > > > > boot > > > > > > > > > > solve this issue > > > > > > > > Huh? This is perhaps going to be a stupid question, but where is > > > > boot_serial=YES getting set? Loader will not set it by itself > > > > and > UEFI > > > > doesn't respect /boot.config, so this must be explicitly set in > > > > /boot/loader.conf or /boot/defaults/loader.conf, but it's not > > > > clear > to > > > > me what's putting it there. > > > > > > > http://src.illumos.org/source/xref/freebsd-head/usr.sbin/bhyveload/bhy > veload.c#832 > > > is the only place I can see immediately that this might be > > > happening, but do UEFI boots go through bhyveload? I'm ignorant here. > > > > This is UEFI GOP methodvia bootrom/uefi-firmware, no bhyveload: > > > > bhyve -AHP -s 0:0,hostbridge -s 31:0,lpc -s > > 4:0,ahci-cd,/tmp/FreeBSD-13.0-CURRENT-amd64-20181101-r339979-disc1.i > > so -c 1 -m 1024M -s 29,fbuf,tcp=0.0.0.0:5900,w=1024,h=768,wait -l > > bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd freebsd1 > > > > https://snag.gy/0MH7zU.jpg > > https://snag.gy/kF5cxZ.jpg > > https://snag.gy/htHMG0.jpg > > https://snag.gy/vK1ALN.jpg > > https://snag.gy/qKNPGU.jpg > > What does your /boot/loader.conf look like? > >What is the ConOut evifar look like? We set serial when the UEFI env says to >do so. >Warner I can confirm that 11.2-REL boots fine but 12.0-BETA4 goes blank just after the loader, using the exact same bhyve configuration. (This is on an 11.2 host) A few lines are output just before going blank but I can't catch what they say. I'm using the official ISO files with no other configuration so it does seem that 12.0 will currently not boot under UEFI-GOP bhyve. I can check the efivars if someone lets me know how. Matt ___ freebsd-virtualizat...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ``make buildkernel'' fails when /usr/obj is empty
On May 31 22:50, Konstantin Belousov wrote: On Thu, May 31, 2018 at 08:19:20PM +0200, Dimitry Andric wrote: On 31 May 2018, at 20:11, Warner Losh wrote: > > On Thu, May 31, 2018 at 11:47 AM, Dimitry Andric wrote: > On 31 May 2018, at 18:04, Benjamin Kaduk wrote: > > On Thu, May 31, 2018 at 09:58:50AM +0200, Gary Jennejohn wrote: > >> On Thu, 31 May 2018 09:52:22 +0200 > >> Gary Jennejohn wrote: ... > > Whatever happened to the "run buildworld or kernel-toolchain before > > buildkernel" requirement? > > That is still a requirement, yes. Otherwise, you might have outdated > toolchain components are in your /usr/obj. > > Usually you can get away without doing that, and now that clang is the toolchain that's rebuilt (and that's not fast) people try to get away with it more and more... Actually clang doesn't get updated *that* often, but there is a minor snag that one of llvm's config files (lib/clang/include/llvm/Config/config.h) includes , so each time __FreeBSD_version is bumped, quite a lot of dependencies get triggered... The version is only used for two checks: #if __FreeBSD_version >= 152 /* Define to 1 if you have the `backtrace' function. */ #define HAVE_BACKTRACE TRUE and: /* Define to 1 if you have the `futimens' function. */ #if __FreeBSD_version >= 1100056 #define HAVE_FUTIMENS 1 #endif Maybe the first check could be dropped, assuming that backtrace() is always available, but I'm not sure about futimens(). Is there any supported version of FreeBSD left that does *not* have it? Or you can manually define the symbols as needed on each branch, eliminating the need for osreldate.h and reusable if some other configuration variable needs to be conditionally set. Are these the kind of things that could get done in current and stable? Currently llvm/clang is rebuilt on pretty much every buildworld cycle that I do because of this which makes using things like WITH_META_MODE pretty pointless. It would be great to get this kind of change in the trees. -- Matt ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: @r324591: panic: UNR inconsistency: items 0 found 7 (line 361)
On 10/13/2017 05:33, David Wolfskill wrote: > On Fri, Oct 13, 2017 at 02:44:50PM +0300, Konstantin Belousov wrote: >> ... >>> panic: UNR inconsistency: items 0 found 7 (line 361) >>> >> Revert r324542 and try again. >> >> This revision was not tested with DIAGNOSTIC enabled. > OK; I believe we have a winner! Thanks! :-) In that revision I neglected to zero the "first" field of the unrhdr. Sorry about that. I also inadvertently wasn't testing with DIAGNOSTIC on. I will commit a fix. Matt ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: building world via ccache broken?
On 10/02/2017 15:23, Pete Wright wrote:
>
>
> On 10/02/2017 13:07, Pete Wright wrote:
>> hey there,
>> i've been unable to buildworld using ccache for a while. initially i
>> assumed it was due to some incompatibilities on the drm-next branch
>> which i was running, but i've since cut over to CURRENT and am still
>> having issues. running "make buildworld" i am running into this
>> exception:
>>
>> /usr/home/pwright/git/freebsd/lib/libufs/cgroup.c:217:11: error: no
>> member named 'fs_metackhash' in 'struct fs'
>> if ((fs->fs_metackhash & CK_CYLGRP) != 0) {
>> ~~ ^
>>
>>
>> full exception here:
>> https://gist.github.com/nomadlogic/30771aacd05d6dbb1c0cbebfb2ef6b61
>>
>> I am going to re-run this w/o ccache - to verify that this is a
>> ccache related issue. I guess my first question - is anyone else
>> using ccache successfully?
>>
>
> fwiw building the world without ccache works as expected. perhaps my
> make.conf is not correctly configured?
>
> $ cat /etc/make.conf
> .if !defined(NO_CCACHE)
> CC= /usr/local/libexec/ccache/world/cc
> CXX= /usr/local/libexec/ccache/world/c++
> .endif
>
> cheers,
> -pete
>
Someone can correct me if I'm wrong but I believe the current "correct"
way to get ccache builds is WITH_CCACHE_BUILD set in src.conf.
src.conf(5) seems to indicate as much as well. To answer your question,
yes, I am I'm sure many others are building world on HEAD with ccache
without issue.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Install FreeBSD from source into VM image
On 08/14/2017 11:42, Panagiotes Mousikides wrote: > I am working on the FreeBSD test suite, and need to create an image > file from source. How can I do that? > > I need to run something similar to make installkernel && make > installworld with an image file as the target, such that the end > result is a ready-made FreeBSD system that can be started up with > bhyve. How can I do that, including creating the correct /etc files, > and the correct boot code and partitioning? > See release(7), https://www.freebsd.org/cgi/man.cgi?release(7). The relevant section is under virtual machine disk images and the vm-image target. The VMFORMATS for bhyve is "raw". That will generate an image that "just works" with vmrun.sh Matt Joras ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
On Sep 25 01:00, Don Lewis wrote: On 25 Sep, Matt Smith wrote: On Sep 24 21:52, Kurt Jaeger wrote: Hi! > > Try dropping the attached patch in net/mediatomb/files. I submitted it > > in March, in PR198436: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > Eh, now with an actual patch. :) Thanks, helps to build it. Still fails on 9.3a, but I *have* to go to bed now. It's done. This seems to create a run time dependency on GCC. Should it not just be a build time dependency which allows you to uninstall GCC afterwards? If the executable(s) link to any of the shared libraries bundled with the gcc port, then gcc needs to be a run time dependency. If you point ldd at one of the executables, what does it say? Good point. I remember now that some things like against libgcc provided with the GCC package. If this is the case then I apologise for the noise and feel free to ignore me! Unfortunately I don't currently have access to the box where I compiled it using GCC last night using the updated port. I only have access to another box where it was compiled using clang (on -STABLE). This shows the below. So I can see that it is linked against libgcc, although in this case the base system version. $ ldd `which mediatomb` /usr/local/bin/mediatomb: libthr.so.3 => /lib/libthr.so.3 (0x80094b000) librt.so.1 => /usr/lib/librt.so.1 (0x800b6f000) libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x800d75000) libmagic.so.4 => /usr/lib/libmagic.so.4 (0x801029000) libz.so.6 => /lib/libz.so.6 (0x801248000) libavformat.so.56 => /usr/local/lib/libavformat.so.56 (0x80145e000) libavutil.so.54 => /usr/local/lib/libavutil.so.54 (0x801821000) libffmpegthumbnailer.so.4 => /usr/local/lib/libffmpegthumbnailer.so.4 (0x801a86000) libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x801c9b000) libc++.so.1 => /usr/lib/libc++.so.1 (0x801ec1000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x80218) libm.so.5 => /lib/libm.so.5 (0x80239c000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8025c5000) libc.so.7 => /lib/libc.so.7 (0x8027d3000) libavcodec.so.56 => /usr/local/lib/libavcodec.so.56 (0x802c0) libssl.so.8 => /usr/local/lib/libssl.so.8 (0x803f0e000) libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x80420) libbz2.so.4 => /usr/lib/libbz2.so.4 (0x804651000) libswscale.so.3 => /usr/local/lib/libswscale.so.3 (0x804863000) libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x804af5000) libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x804d27000) libswresample.so.1 => /usr/local/lib/libswresample.so.1 (0x804f8) libx264.so.144 => /usr/local/lib/libx264.so.144 (0x80519b000) libmp3lame.so.0 => /usr/local/lib/libmp3lame.so.0 (0x8054fd000) libfdk-aac.so.1 => /usr/local/lib/libfdk-aac.so.1 (0x805776000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x805a43000) -- Matt ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
On Sep 25 09:18, Kurt Jaeger wrote: Hi! >> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 This seems to create a run time dependency on GCC. Should it not just be a build time dependency which allows you to uninstall GCC afterwards? Maybe, I have not looked into that. Can you suggest a patch ? Unfortunately not I'm afraid. I'm not familiar enough with the newer intricacies of the ports system these days. I'm just a little OCD about only having ports installed which are needed for runtime and I usually run pkg_clean after every port update run to remove unneeded things. GCC just popped out as being unneeded to run mediatomb. -- Matt ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
On Sep 24 21:52, Kurt Jaeger wrote: Hi! > > Try dropping the attached patch in net/mediatomb/files. I submitted it > > in March, in PR198436: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > Eh, now with an actual patch. :) Thanks, helps to build it. Still fails on 9.3a, but I *have* to go to bed now. It's done. This seems to create a run time dependency on GCC. Should it not just be a build time dependency which allows you to uninstall GCC afterwards? -- Matt ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: EFI boot failure
On Tue, 23 Sep, at 08:00:31AM, Nathan Whitehorn wrote: > Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9? Do you pull the -mno-redzone flag anywhere? I'm looking through the loader sources now, and I see that switch in sys/conf/kern.mk, but it doesn't look like that's being pulled in for the boot loader source. Calling into EFI will trash the x86-64 redzone, if you've got it enabled. -- Matt Fleming, Intel Open Source Technology Center ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Back in the day we didn't have Google to ask the oracle for cut and paste answers. If the man page is accurate that should be good enough. On Jul 18, 2014 8:26 AM, "krad" wrote: > this is also another important point. If you go onto google and search on > how to do this and that under pf, you get a mix of freebsd, and openbsd > stuff coming up. I havent analysed it but i think the majority of the stuff > is openbsd related. THerefore I find some nice solution to my problem, only > to find out a bit later I cant use it because its not supported under > freebsd. This is anoying, but more importantly confuses new sysadmins and > puts them off adopting pf and possibly a bsd at all. > > > On 18 July 2014 14:12, Gerrit Kühn wrote: > > > On Fri, 18 Jul 2014 15:06:45 +0400 Gleb Smirnoff > > wrote about Re: Future of pf / firewall in FreeBSD ? - does it have one > ?: > > > > GS> The pf mailing list is about a dozen of active people. Yes, they are > > GS> vocal on the new syntax. But there also exist a large number of > common > > GS> FreeBSD users who simply use pf w/o caring about syntax and reading > pf > > GS> mailing list. If we destroy the syntax compatibility a very large > > GS> population of users would be hurt, for the sake of making a dozen > > GS> happy. > > > > I have thought about this for some time now, and I think I do not agree. > I > > do remember quite well when OpenBSD changed from ipf to pf, and I had to > > come up with new rules files. Yes, this is a burden for people > maintaining > > these systems, but if the thing is well documented and comes with > benefits > > (like staying in sync with other developers, allowing new features etc.) > I > > doubt that many people will really be minding this. > > > > > > cu > > Gerrit > > ___ > > freebsd-questi...@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to " > > freebsd-questions-unsubscr...@freebsd.org" > > > ___ > freebsd-questi...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Leaving the Desktop Market
On Wed, Apr 2, 2014 at 5:24 AM, Jordan Hubbard wrote: > > On Apr 1, 2014, at 10:11 PM, Matt Olander wrote: > >> This is like trying to predict automobile technology and dominant >> car-makers by 1905. There's always room for competition. Take a look >> at what's happening right now in the auto-industry. Tesla came out of >> nowhere 125 years after the invention of the automobile and is doing >> pretty well. > > I think you're kind of making my point for me, Matt. :-) > > Tesla benefitted entirely from deep pockets on the part of its investors. > Over $160M went into starting the company, of which $70M came from the > personal checking account of Elon Musk, the current visionary and CEO, and to > quote the wikipedia page: "Tesla Motors is a public company that trades on > the NASDAQ stock exchange under the symbol TSLA.[5] In the first quarter of > 2013, Tesla posted profits for the first time in its ten year history." > > Yep, in other words, Tesla has been losing money for over 10 years and only > just started turning a profit, after raising a "mere" $187M in investment and > $485M in loans from the US DOE. Your tax dollars at work! On top of all > that Tesla has only managed to make money at all by focusing exclusively the > highest end of the luxury car market, where profit margins are also the > highest (the first car, the roadster, would set you back $110,000). > > Getting back to computer operating systems, it would make most readers of > these lists choke on their Doritos to know how much Apple had to invest in > Mac OS X before it became a viable desktop operating system and of course > you've already seen folks screaming about how Apple gear is too expensive and > they'll never buy it. > > You just don't get a consumer-grade desktop Unix OS, or a practical > all-electric sedan, without serious monetary investment and a luxury marquee > to match, assuming you'd like to actually make any of that money *back*. > > So, back to BSD on the desktop. Anyone got a spare $200M they'd like to > just throw away? That's what it's going to take! :) > > Don't believe me? Go ask someone who knows first-hand then. Ask Mark > Shuttleworth: > http://arstechnica.com/information-technology/2013/08/why-ubuntus-creator-still-invests-his-fortune-in-an-unprofitable-company/ > Yeah, no doubt it will cost a bit of money to compete on that level. However, have you ever heard the phrase pioneers suffer where settlers prosper? Meaning it may (or may not!) take significantly less to compete once a lot of the harder problems are solved. If we take the fact that PCs are on the decline but device adoption is on the rise, perhaps we could focus on an Android competitor (*cough* Cyb0rg *cough). Wouldn't it be possible to run Android apps on *BSD via a java vm? I will get you an Ubuntu phone for Christmas and we can try it :P -matt P.S., I do not have 200 million but I'm good for 10k :P ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Leaving the Desktop Market
On Tue, Apr 1, 2014 at 12:11 AM, Jordan Hubbard wrote: > > On Apr 1, 2014, at 10:46 AM, Eitan Adler wrote: > >> That is why on this date I propose that we cease competing on the >> desktop market. FreeBSD should declare 2014 to be "year of the Linux >> desktop" and start to rip out the pieces of the OS not needed for >> server or embedded use. >> >> Some of you may point to PCBSD and say that we have a chance, but I >> must ask you: how does one flavor stand up to the thousands in the >> Linux world? > > The fact that this posting comes out on April 1st makes me wonder if it's > just an elaborate April Fool's joke, but then the notion of *BSD (or Linux, > for that matter) on the Desktop is just another long-running April fool's > joke, so I'm willing to postulate that two April Fools jokes would simply > cancel each other out and make this posting a serious one again. :-) > > I'll choose to be serious and say what I'm about to say in spite of the fact > that I work for the primary sponsor of PC-BSD and actually like the fact that > it has created some interesting technologies like PBIs, the Jail Warden, > Life-preserver and a ZFS boot environment menu. > > There is no such thing as a desktop market for *BSD or Linux. There never > has been and there never will be. Why do you think we chose "the power to > serve" as FreeBSD's first marketing slogan? It makes a fine server OS and > it's easy to defend its role in the server room. It's also becoming easier > to defend its role as an embedded OS, which is another excellent niche to > pursue and I am happy to see all the recent developments there. > > A desktop? Unless you consider Mac OS X to be "BSD on the desktop" (and > while they share some common technologies, it's increasingly a stretch to say > that), it's just never going to happen for (at least) the following reasons: As you may imagine, I completely disagree! The Internet just had it's 20th birthday (it can't even drink yet!) and it's anyone's game. This is like trying to predict automobile technology and dominant car-makers by 1905. There's always room for competition. Take a look at what's happening right now in the auto-industry. Tesla came out of nowhere 125 years after the invention of the automobile and is doing pretty well. I bet there were a lot of people at Apple saying they couldn't compete in the music-player market, or the mobile-phone market, etc. In fact, if I look at the stats on freenas.org, we have about 350k visitors each month, with nearly 2% of them running FreeBSD and clearly using it to surf the internet. Sounds like a market to me! Long live the FreeBSD desktop, long live PC-BSD :P Cheers, -matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD 9.1 Server hanging while backing up full disk with Amanda
Hello, I think I am having almost the same issue as was reported here: http://thr3ads.net/freebsd-stable/2008/11/388646-System-deadlock-when-using- mksnap_ffs I would have thought something that old would have been patched by this point, but perhaps not? It looks like when the Amanda process is running on the server and doing the Dump phase, it hangs during when the snapshot is being created (mksnap_ffs) for about 20 mins. The box is pingable, but most services stop responding during that time. Then after that 20 mins or so, it clears up and the dump continues on and finishes successfully. I have 9 servers that are backed up with Amanda, and this is the only one giving me this issue. It is the only one running FreeBSD 9.1 as well as the only one with one partition instead of separate partitions for the various directories (/usr, /var /home etc). Disk size: FilesystemSizeUsed Avail Capacity Mounted on /dev/da0p23.5T133G3.1T 4%/ Any one having similar issues or know of a fix? Thanks, Matt Rauch ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fixing X220 Video The Right Way
Not sure that it did :) I tried it once early on, and it concerned me enough I never tried again. It was clearly in a violently erroneous state! At one point, X *could* resume the display. This makes me think the problem is solved via the graphics "chip" state, but it could be an acpi thing. I can't remember if I ever tried to startx after the resume on the "blind" console. Matt On 08/09/13 23:00, Adrian Chadd wrote: > when did it start working? > > > -adrian > > On 9 August 2013 20:10, matt wrote: >> hw.acpi.reset_video used to send this machine X220 into a reboot >> loop, with flashing thinklight. Interesting that it no longer >> causes this problem. I kind of paused since the trackpad sucks so >> much in X. >> >> I think since ssh still works, that just the display or graphics >> port is off. >> >> It may be worth trying to do some acpi_calls via ssh to try to >> hack the display back on... >> >> Matt >> >> On 08/09/13 08:57, John Baldwin wrote: >>> On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote: >>>> Hi! >>>> >>>> Hm, resurrecting this thread, I'll try this on my X230 >>>> tomorrow and see if it makes the (non-xorg, console only) >>>> video work on resume. >>>> >>>> If it does, what will it take to automatically determine >>>> that this kind of work-around is needed? >>> >>> >>> This does not affect suspend/resume. It only fixes LCD >>> brightness handling via acpi_video(4). >>> >> > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fixing X220 Video The Right Way
hw.acpi.reset_video used to send this machine X220 into a reboot loop, with flashing thinklight. Interesting that it no longer causes this problem. I kind of paused since the trackpad sucks so much in X. I think since ssh still works, that just the display or graphics port is off. It may be worth trying to do some acpi_calls via ssh to try to hack the display back on... Matt On 08/09/13 08:57, John Baldwin wrote: > On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote: >> Hi! >> >> Hm, resurrecting this thread, I'll try this on my X230 tomorrow >> and see if it makes the (non-xorg, console only) video work on >> resume. >> >> If it does, what will it take to automatically determine that >> this kind of work-around is needed? > > > This does not affect suspend/resume. It only fixes LCD brightness > handling via acpi_video(4). > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes with current on X220
On 07/06/13 19:40, Super Bisquit wrote: > Look in the mailing list for "Fixing X220 Video the right way." > Did I miss something? I'm not sure it's related at all...? Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fixing X220 Video The Right Way
On 06/14/13 08:39, John Baldwin wrote: > I got this to work by using 4 backslashes. At that point the patch > worked. (I recently got access to an X220.) I get a local APIC > error each time I adjust the brightness though (probably the BIOS > is doing something wonky). > That's awesome! I've asked -CURRENT about the I tried single quotes, double quotes, double backslash, and I meant to try ascii escapes next :) I'm glad you got this working, it makes the X220 (and probably other laptops with similar issues) more usable on FreeBSD. I'll have to bring my X220 back up to current and start looking at sleep issues next. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel fails in zlib (all)
On 04/27/13 19:33, Adrian Chadd wrote: > Do it this time without -j6, so we can see where it failed. > > Another good one is to add | tee buildworld.log to the end of the build command as a matter of course, since you can then search the log if the error was beyond scrollback. AN, if your sources are about 12h old, they are probably failing because of the removal of MAKE_IDEA from some makefiles but not others. If that's the case, update sources and run it again...Buildworld failed for me last night for this reason. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r249939+ not detecting ata trim
On 04/27/13 19:13, Steven Hartland wrote: > > Thats correct, the mps controllers I have here announce UNMAP support for > SATA disks that support TRIM and then do firmware translation on the > commands sent from the OS before passing them to the disks. > > This is why I was expecting your controller to still do support delete's > eventhough ATA_TRIM wasn't enabled yet. > > > I'd be interested to see the details of your controller e.g. > Apr 28 01:36:17 host01 kernel: mps0: port 0xf000-0xf0ff > mem 0xfbe0-0xfbe03fff,0xfbd8-0xfbdb irq 56 at device 0.0 > on pci129 > Apr 28 01:36:17 host01 kernel: mps0: Reserved 0x4000 bytes for rid > 0x14 type 3 at 0xfbe0 > Apr 28 01:36:17 host01 kernel: mps0: Firmware: 14.00.00.00, Driver: > 14.00.00.01-fbsd > Apr 28 01:36:17 host01 kernel: mps0: IOCCapabilities: > 185c > Apr 28 01:36:17 host01 kernel: mps0: attempting to allocate 1 MSI-X > vectors (15 supported) > >Regards >Steve > > > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained in > it. > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmas...@multiplay.co.uk. > > Here are the delete methods: deleteflag: ATA_TRIM (2) = 1 da4: Delete methods: deleteflag: ATA_TRIM (2) = 1 da3: Delete methods: deleteflag: ATA_TRIM (2) = 1 Here is a truncated dmesg | fgrep mps mps0: port 0xb000-0xb0ff mem 0xfe83c000-0xfe83,0xfe84-0xfe87 irq 32 at device 0.0 on pci3 mps0: Firmware: 15.00.00.00, Driver: 14.00.00.02-fbsd mps0: IOCCapabilities: 1285c mps0: attempting to allocate 1 MSI-X vectors (15 supported) mps0: using IRQ 263 for MSI-X My firmware is ahead of the driver, and the card itself is an IBM M1015 cross-flashed to what is supposedly identical to a 9210-8i. Thanks, Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r249939+ not detecting ata trim
On 04/27/13 18:51, Steven Hartland wrote: > - Original Message - From: "matt" >>> FYI: Change only requires kernel, world would be identical, which >>> should save you some time. >> >> And some untrimmed deletes! >> >> Thanks, with geom/cam/disk stuff I usually assume that it could affect >> userland out of caution. >> >> BTW...ata identify is working fine, as even before the patch camcontrol >> identify indicated trim support. > > Could you confirm the output you got from the debug as I would have > expected to see UNMAP supported on your machine if you mps? Output for sysctls kern.cam.da.3.delete_method: ATA_TRIM kern.cam.da.3.delete_max: 17179607040 kern.cam.da.3.minimum_cmd_size: 6 kern.cam.da.3.sort_io_queue: 0 kern.cam.da.3.error_inject: 0 kern.cam.da.4.delete_method: ATA_TRIM kern.cam.da.4.delete_max: 17179607040 Output for printf deleteflag: ATA_TRIM (2) = 1 I thought UNMAP was a SCSI command (for SAS disks), unless we're calling it UNMAP and then running ATA's TRIM? > I can envisage people wanting to know what delete methods are detected > as supported so I've created a new little patch which will print this > out from a verbose boot. > > Its attached if you want to try it, again only a kernel change, I'd > be interested in the output you get. You should see something like:- > da0: Delete methods: I'll give it a try and send the results. Thanks, Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r249939+ not detecting ata trim
On 04/27/13 18:32, Steven Hartland wrote: > > FYI: Change only requires kernel, world would be identical, which > should save you some time. > >Regards >Steve > > And some untrimmed deletes! Thanks, with geom/cam/disk stuff I usually assume that it could affect userland out of caution. BTW...ata identify is working fine, as even before the patch camcontrol identify indicated trim support. Thanks, Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r249939+ not detecting ata trim
On 04/27/13 15:58, Steven Hartland wrote: > > If your controller doesn't support UNMAP then this will be the reason, > however mps should support this. > > Could you confirm if previously you where seeing UNMAP as the reported > delete_method? > >Regards >Steve > > > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained in > it. > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmas...@multiplay.co.uk. I am rebuilding world and kernel with the patches now. Congratulations/thanks on getting all this committed! I'll post the dmesg output from the printf patch afterward. Previously, the delete_method was reported as ATA_TRIM, with a very large delete max. Thanks, Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r249939+ not detecting ata trim
I had been updating/porting Steve Hartland's patches for zfs trim on mps for 8.3 stable. Trim was working fine for me before r249939. When I saw that this functionality was being added to current, I built world/kernel without the patches. Indeed, many of the commits are quite similar to the updated patch I worked on (patch claims most of it is 'already applied'). HOWEVER, I am not seeing a delete method detected for either of my Samsung 830s, which I did under my updated patch. It looks like scsi ata identify is not working. Are there still outstanding commits to enable this, or is something now a tunable/sysctl I'm missing? Previously it was working: kstat.zfs.misc.zio_trim.bytes: 47546368 kstat.zfs.misc.zio_trim.success: 2618 kstat.zfs.misc.zio_trim.unsupported: 0 kstat.zfs.misc.zio_trim.failed: 0 Current: kstat.zfs.misc.zio_trim.bytes: 0 kstat.zfs.misc.zio_trim.success: 0 kstat.zfs.misc.zio_trim.unsupported: 264 kstat.zfs.misc.zio_trim.failed: 0 kern.cam.da.3.delete_method: NONE kern.cam.da.3.delete_max: 0 kern.cam.da.4.delete_method: NONE kern.cam.da.4.delete_max: 0 Thanks, Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Intel D2500CC motherboard and strange RS232/UART behavior
On 04/07/13 12:43, Lev Serebryakov wrote: > How could I debug this? Does this board have any fancy BIOS -> RS232 redirection? Could something like that cause these symptoms? Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fixing X220 Video The Right Way
On 02/28/13 09:09, John Baldwin wrote: > On Thursday, February 28, 2013 8:15:46 am matt wrote: >> On 02/27/13 12:27, John Baldwin wrote: >>> On Wednesday, February 27, 2013 1:35:43 pm matt wrote: >>>> On 02/27/13 09:00, John Baldwin wrote: >>>>> If that is true, it's because your BIOS is lying. Do you have a URL to >>>>> your ASL lying around already? >>>> Too big for pastebin :( +500k >>>> >>>> https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing >>> Here is where I find _DOD and _DOS methods: >>> >>> Device (PCI0) >>> Device (VID) >>> Name (_ADR, 0x0002) // _ADR: Address >>> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output >>> Switching >>> Method (_DOD, 0, NotSerialized) // _DOD: Display Output >>> Devices >>> Device (PEG) >>> Name (_ADR, 0x0001) // _ADR: Address >>> Device (VID) >>> Name (_ADR, 0x00) // _ADR: Address >>> Method (_DOS, 1, NotSerialized) // _DOS: Disable >>> Output Switching >>> Method (_DOD, 0, NotSerialized) // _DOD: Display >>> Output Devices >>> >>> PCI0.VID is a PCI device at pci0:0:2:0. >>> PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0. >>> It would have a child device at 0:0 that would be PCI0.PEG.VID. Does the >>> X220 >>> have a switchable GPU (e.g. it has built-in Intel graphics, but also has an >>> Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel >>> graphics >>> and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful to >>> determine >>> that. If both PCI devices exist you shoudl have both acpi_video0 and >>> acpi_video1. >>> However, it may be that the acpi_video driver doesn't cope well with having >>> multiple >>> devices. >> Only Intel graphics, there is no option for switchable graphics. >> I initially thought that PEG was for Optimus usage, and left in the bios >> by accident (i.e. Lenovo using a generic DSDT for many machines) >> >> Here is pciconf -lcf, truncated >> hostb0@pci0:0:0:0:class=0x06 card=0x21da17aa chip=0x01048086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '2nd Generation Core Processor Family DRAM Controller' >> class = bridge >> subclass = HOST-PCI >> cap 09[e0] = vendor (length 12) Intel cap 0 version 1 >> vgapci0@pci0:0:2:0:class=0x03 card=0x21da17aa chip=0x01268086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '2nd Generation Core Processor Family Integrated >> Graphics Controller' >> class = display >> subclass = VGA >> cap 05[90] = MSI supports 1 message enabled with 1 message >> cap 01[d0] = powerspec 2 supports D0 D3 current D0 >> cap 13[a4] = PCI Advanced Features: FLR TP >> none0@pci0:0:22:0:class=0x078000 card=0x21da17aa chip=0x1c3a8086 >> rev=0x04 hdr=0x00 >> vendor = 'Intel Corporation' >> >> As you can see there is no device at pci0:0:1:0. So no dev_t with for >> acpi_video to probe or attach to. >> >> Nonetheless, only PEGs ACPI methods work, which is quite broken. This is >> true for a large number of Lenovo devices, back to x61 (non-attaching >> AGP adr) and probably including some other x series and t series. >> >> Unfortunately the ASL will not compile which makes fixing the DSDT an >> exercise in fixing broken ACPI. >> >> What I find interesting is that as far as I can tell, there's no special >> case handling for this device in Linux, yet backlight controls work out >> of the box since about 3.0. Installing Linux as the OSI via loader.conf >> is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows >> 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs >> _BCM... :( >> >> Is Linux getting this to work by doing it wrong, essentially? > Yes. I think the best way to fix this is to add a way to specify a > hint to override the ACPI path associated with a PCI device. Something > like: > > hw.pci0.0.2.0.handle="\_SB_.PCI0.PEG.VID" > > I think this patch should do the trick: > > Index: sys/dev/acpica/acpi_pci.
Re: Fixing X220 Video The Right Way
On 02/28/13 09:09, John Baldwin wrote: > On Thursday, February 28, 2013 8:15:46 am matt wrote: >> On 02/27/13 12:27, John Baldwin wrote: >>> On Wednesday, February 27, 2013 1:35:43 pm matt wrote: >>>> On 02/27/13 09:00, John Baldwin wrote: >>>>> If that is true, it's because your BIOS is lying. Do you have a URL to >>>>> your ASL lying around already? >>>> Too big for pastebin :( +500k >>>> >>>> https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing >>> Here is where I find _DOD and _DOS methods: >>> >>> Device (PCI0) >>> Device (VID) >>> Name (_ADR, 0x0002) // _ADR: Address >>> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output >>> Switching >>> Method (_DOD, 0, NotSerialized) // _DOD: Display Output >>> Devices >>> Device (PEG) >>> Name (_ADR, 0x0001) // _ADR: Address >>> Device (VID) >>> Name (_ADR, 0x00) // _ADR: Address >>> Method (_DOS, 1, NotSerialized) // _DOS: Disable >>> Output Switching >>> Method (_DOD, 0, NotSerialized) // _DOD: Display >>> Output Devices >>> >>> PCI0.VID is a PCI device at pci0:0:2:0. >>> PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0. >>> It would have a child device at 0:0 that would be PCI0.PEG.VID. Does the >>> X220 >>> have a switchable GPU (e.g. it has built-in Intel graphics, but also has an >>> Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel >>> graphics >>> and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful to >>> determine >>> that. If both PCI devices exist you shoudl have both acpi_video0 and >>> acpi_video1. >>> However, it may be that the acpi_video driver doesn't cope well with having >>> multiple >>> devices. >> Only Intel graphics, there is no option for switchable graphics. >> I initially thought that PEG was for Optimus usage, and left in the bios >> by accident (i.e. Lenovo using a generic DSDT for many machines) >> >> Here is pciconf -lcf, truncated >> hostb0@pci0:0:0:0:class=0x06 card=0x21da17aa chip=0x01048086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '2nd Generation Core Processor Family DRAM Controller' >> class = bridge >> subclass = HOST-PCI >> cap 09[e0] = vendor (length 12) Intel cap 0 version 1 >> vgapci0@pci0:0:2:0:class=0x03 card=0x21da17aa chip=0x01268086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '2nd Generation Core Processor Family Integrated >> Graphics Controller' >> class = display >> subclass = VGA >> cap 05[90] = MSI supports 1 message enabled with 1 message >> cap 01[d0] = powerspec 2 supports D0 D3 current D0 >> cap 13[a4] = PCI Advanced Features: FLR TP >> none0@pci0:0:22:0:class=0x078000 card=0x21da17aa chip=0x1c3a8086 >> rev=0x04 hdr=0x00 >> vendor = 'Intel Corporation' >> >> As you can see there is no device at pci0:0:1:0. So no dev_t with for >> acpi_video to probe or attach to. >> >> Nonetheless, only PEGs ACPI methods work, which is quite broken. This is >> true for a large number of Lenovo devices, back to x61 (non-attaching >> AGP adr) and probably including some other x series and t series. >> >> Unfortunately the ASL will not compile which makes fixing the DSDT an >> exercise in fixing broken ACPI. >> >> What I find interesting is that as far as I can tell, there's no special >> case handling for this device in Linux, yet backlight controls work out >> of the box since about 3.0. Installing Linux as the OSI via loader.conf >> is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows >> 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs >> _BCM... :( >> >> Is Linux getting this to work by doing it wrong, essentially? > Yes. I think the best way to fix this is to add a way to specify a > hint to override the ACPI path associated with a PCI device. Something > like: > > hw.pci0.0.2.0.handle="\_SB_.PCI0.PEG.VID" > > I think this patch should do the trick: > > Index: sys/dev/acpica/acpi_pci.
Re: Fixing X220 Video The Right Way
On 02/27/13 12:27, John Baldwin wrote: On Wednesday, February 27, 2013 1:35:43 pm matt wrote: On 02/27/13 09:00, John Baldwin wrote: If that is true, it's because your BIOS is lying. Do you have a URL to your ASL lying around already? Too big for pastebin :( +500k https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing Here is where I find _DOD and _DOS methods: Device (PCI0) Device (VID) Name (_ADR, 0x0002) // _ADR: Address Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices Device (PEG) Name (_ADR, 0x0001) // _ADR: Address Device (VID) Name (_ADR, 0x00) // _ADR: Address Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices PCI0.VID is a PCI device at pci0:0:2:0. PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0. It would have a child device at 0:0 that would be PCI0.PEG.VID. Does the X220 have a switchable GPU (e.g. it has built-in Intel graphics, but also has an Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel graphics and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful to determine that. If both PCI devices exist you shoudl have both acpi_video0 and acpi_video1. However, it may be that the acpi_video driver doesn't cope well with having multiple devices. Only Intel graphics, there is no option for switchable graphics. I initially thought that PEG was for Optimus usage, and left in the bios by accident (i.e. Lenovo using a generic DSDT for many machines) Here is pciconf -lcf, truncated hostb0@pci0:0:0:0:class=0x06 card=0x21da17aa chip=0x01048086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family DRAM Controller' class = bridge subclass = HOST-PCI cap 09[e0] = vendor (length 12) Intel cap 0 version 1 vgapci0@pci0:0:2:0:class=0x03 card=0x21da17aa chip=0x01268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family Integrated Graphics Controller' class = display subclass = VGA cap 05[90] = MSI supports 1 message enabled with 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP none0@pci0:0:22:0:class=0x078000 card=0x21da17aa chip=0x1c3a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' As you can see there is no device at pci0:0:1:0. So no dev_t with for acpi_video to probe or attach to. Nonetheless, only PEGs ACPI methods work, which is quite broken. This is true for a large number of Lenovo devices, back to x61 (non-attaching AGP adr) and probably including some other x series and t series. Unfortunately the ASL will not compile which makes fixing the DSDT an exercise in fixing broken ACPI. What I find interesting is that as far as I can tell, there's no special case handling for this device in Linux, yet backlight controls work out of the box since about 3.0. Installing Linux as the OSI via loader.conf is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs _BCM... :( Is Linux getting this to work by doing it wrong, essentially? Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fixing X220 Video The Right Way
On 02/27/13 09:00, John Baldwin wrote: > If that is true, it's because your BIOS is lying. Do you have a URL to > your ASL lying around already? Too big for pastebin :( +500k https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing Thanks, Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU0: Local APIC error 0x80
On 02/27/13 09:08, John Baldwin wrote: > On Sunday, February 24, 2013 2:57:32 pm matt wrote: >> What does this mean exactly? >> >> Whenever I call/evaluate certain ACPI paths, this gets printed on console. >> >> I assume it's a concurrent access issue or something, or perhaps just a >> bios/uefi problem? > #define APIC_ESR_ILLEGAL_REGISTER 0x0080 > > It means something wrote to an invalid lapic register. It is probably a bug > in your BIOS, yes. > Not surprising, is there any potential damage from allowing it to continue? Thanks, Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Response of *.freebsd.org websites are very slow
On 02/27/13 06:28, Mehmet Erol Sanliturk wrote: > > > nslookup ftp.freebsd.org > > ;; connection timed out ; trying next origin > ;; connection timed out ; no servers could be reached > > > > netbsd , openbsd , dragonflybsd is working . > ftp.tr.freebsd.org is working . > > > > What is `cat /etc/resolv.conf` (any of those OS) Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fixing X220 Video The Right Way
On 02/26/13 10:46, John Baldwin wrote: > On Monday, February 25, 2013 11:20:29 pm matt wrote: >> On 02/25/13 18:33, Adrian Chadd wrote: >>> [101232] acpi_video0: on vgapci0 >>> found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 >>> >>> And what do I do with acpi_get_handle ? >>> >>> >>> >>> >> I threw printfs into acpi_video, not sure if that would work for both >> vgapci or not. >> I'm not sure if I wiped out my debug patches yet, I may have a patch. >> Basically the idea is to figure out which paths in the DSDT are getting >> attached to the vgapci devices. > devinfo -v already tells you that. > > For example: > > nexus0 > acpi0 > pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 > pci0 > hostb0 pnpinfo vendor=0x8086 device=0x0100 subvendor=0x8086 > subdevice=0x2010 class=0x06 at slot=0 function=0 > pcib1 pnpinfo vendor=0x8086 device=0x0101 subvendor=0x8086 > subdevice=0x2010 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.PEG1 > pci1 > vgapci0 pnpinfo vendor=0x10de device=0x0605 subvendor=0x3842 > subdevice=0xc973 class=0x03 at slot=0 function=0 > > (My desktop doesn't have acpi_video and doesn't have an ACPI handle for the > vgapci device, but you can see how it displays the handle for other PCI > devices like pcib1 which are in the ACPI namespace.) > >> It seems like we could either try to find these paths on affected >> models, or have a tunable override for acpi_video. > Note that the Linux discussion you posted seems a bit off. The _ADR is > not supposed to be unique to the entire system. For PCI devices, _ADR > contains the PCI device (slot) and function (as slot << 16 | func), and > the domain:bus portion of the address is implied by the parent PCI bus > device in the ACPI namespace. Thus, the specific handle assigned by ACPI > is for the exact PCI location of the requisite vgapci device. If your > BIOS lies it is hard for us to do anything useful, at least automatically. > > Do the other devices in your system that have _DOD or _DOS methods show > up as unknown ACPI devices in your devinfo -v output? It's not in devinfo at all for me, Adrian may have a different situation. So my laptop has _SB.PCI0.PEG.VID and _SB.PCI0.VID Only _SB.PCI0.VID is represented in devinfo -rv. As far as I know, PEG is not a "real" device, but an abstraction, possibly for Optimus use. It makes calls to \VIGD (integrated graphics?) and \ISOP (isOptimus?) This is potentially the broken bios part of things. I think I have multiple ACPI devices for a single physical device, and pci is attaching the wrong ACPI device to the physical device in an ivar. acpi_video happily uses this ivar to attempt to control video brightness. I could be entirely wrong on that, all I do know is that the working handle doesn't get used and the useless handle does. Matt Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fixing X220 Video The Right Way
On 02/25/13 18:33, Adrian Chadd wrote: > [101232] acpi_video0: on vgapci0 > found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 > > And what do I do with acpi_get_handle ? > > > > I threw printfs into acpi_video, not sure if that would work for both vgapci or not. I'm not sure if I wiped out my debug patches yet, I may have a patch. Basically the idea is to figure out which paths in the DSDT are getting attached to the vgapci devices. This dsdt patch from Mitsuru Iwasaki illustrates fixing a similar issue to X220 via a custom dsdt http://people.freebsd.org/~iwasaki/acpi/tpx61.asl.diff <http://people.freebsd.org/%7Eiwasaki/acpi/tpx61.asl.diff> It seems like we could either try to find these paths on affected models, or have a tunable override for acpi_video. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fixing X220 Video The Right Way
On 02/25/13 18:19, Adrian Chadd wrote: > > My T400 has: > > > vgapci0@pci0:0:2:0: class=0x03 card=0x20e417aa chip=0x2a428086 > rev=0x07 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Mobile 4 Series Chipset Integrated Graphics Controller' > class = display > subclass = VGA > vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086 > rev=0x07 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Mobile 4 Series Chipset Integrated Graphics Controller' > class = display > > And I get glitches in xorg on 9.1 when I have multiple windows of > different sizes. > > > > Adrian > Does acpi_video like either one? Does acpi_get_handle return the same path? Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fixing X220 Video The Right Way
On 02/25/13 10:30, John Baldwin wrote: > > Is there a better place to "correct" the ACPI_PATH that gets stored in > vgapci's ivar? Is there already a tunable I can use to fix this? > vgapci's ivar is set by the PCI address. Do you have multiple vgapci devices? > No, just one. I think that the DSDT is very creative on recent Lenovos (read: broken). There are multiple video devices defined, with "functional" calls that nonetheless don't work to actually do anything. The acpi_get_handle() call in acpi_video returns a handle that has no active outputs and doesn't have any control over the brightness. The other path can control brightness. Here's a related discussion on Linux, I'm not sure how much applies other than the situation discussed: http://comments.gmane.org/gmane.linux.acpi.devel/57228 The same thing happens on AGP thinkpads, I believe, based on Mitsuru Iwasaki's comment a long time ago to an X220 thread. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
CPU0: Local APIC error 0x80
What does this mean exactly? Whenever I call/evaluate certain ACPI paths, this gets printed on console. I assume it's a concurrent access issue or something, or perhaps just a bios/uefi problem? Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Fixing X220 Video The Right Way
I am working on fixing acpi_video for X220. My X220 is back to FreeBSD land, and I always felt \VBRC calls were dirty. So I've set out to fix acpi_video to work naturally, as it does in linux land. Background: Lenovo laptops boot in a mode where the brightness keys automagically work, under BIOS/EC control. This gets blown away (for us) shortly after Kernel attach. At this point, the acpi method \NBCF will return 0, which means acpi cannot control video brightness. Once we touch the _BCL method on the video output (even inactive ones), \NBCF returns 1 and will allow acpi control. You may remember that acpi_video records some brightness value that changes with keypresses, but does not work on X220. Current status: If I modify acpi video to attach to \_SB.PCI0.PEG.VID, brightness works via sysctl but not keypress (\NBCF = 1) If I leave that alone, but just redirect the brightness set function to \_SB.PCI0.PEG.VID.LCD0._BCM, the keyboard works That is obviously a hack, but it indicates something is going on here. I think that get_acpi_handle() on the X220 vgapci is returning the wrong ACPI_HANDLE. Perhaps this is why the screen stays off when resume used to work? Obviously it can be fixed by hard coding this path into acpi_video, but I feel like that is definitely the wrong way. A tunable for an acpi_video override might be useful, but it still leaves potentially the wrong path in vgapci's IVARs. Is there a better place to "correct" the ACPI_PATH that gets stored in vgapci's ivar? Is there already a tunable I can use to fix this? Thanks! Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD current rev today about 1-2pm
On 02/21/13 19:58, Chris wrote: > On 2/21/2013 9:54 PM, Steve Kargl wrote: >> On Thu, Feb 21, 2013 at 09:50:11PM -0600, Chris wrote: >>> I updated current today and now the system refuses to boot and my 3ware >>> card constantly has it's LED on and it resets. booting the old kernel >>> boots up fine ? >> Which timezone? 1-2pm is a little ambiguous. >> Do you have sources with revision 247117 or later? >> > Timezone is CST -6 GMT > > Working kernel is from 02-11-2012 non working kernel is from today > around that time. I am not on the FreeBSD box to check actual rev. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscr...@freebsd.org" > Sounds like the problem from yesterday, my mps0 didn't get to come up before the system hung. It looked like a storage system failure. Get newer sources and try again. Get them from svn, not sure what csup is doing anymore. The patch came around 19:13 GMT. http://freshbsd.org/commit/freebsd/r247117 Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r247095 Boot Failure
OK here as well. Tested sandybridge & opteron. Matt On Thu, Feb 21, 2013 at 10:28 PM, O. Hartmann wrote: > > > Works for me, too. > > Thanks a lot. > > oh > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r247095 Boot Failure
> On Thu, Feb 21, 2013 at 3:46 PM, Sergey Kandaurov wrote: > >> >> >> Currently that corresponds to: >> set kern.smp.disabled=1 >> set hw.ata.ata_dma=0 >> set hw.ata.atapi_dma=0 >> set hw.ata.wc=0 >> set hw.eisa_slots=0 >> set kern.eventtimer.periodic=1 >> set kern.geom.part.check_integrity=0 >> >> See /boot/menu-commands.4th >> >> -- >> wbr, >> pluknet >> > > > > It's kern.smp.disabled=1 that allows boot. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r247095 Boot Failure
On Thu, Feb 21, 2013 at 3:46 PM, Sergey Kandaurov wrote: > > > Currently that corresponds to: > set kern.smp.disabled=1 > set hw.ata.ata_dma=0 > set hw.ata.atapi_dma=0 > set hw.ata.wc=0 > set hw.eisa_slots=0 > set kern.eventtimer.periodic=1 > set kern.geom.part.check_integrity=0 > > See /boot/menu-commands.4th > > -- > wbr, > pluknet > Enabling beastie, safe mode boots. The userland thread wasn't terribly descriptive about symptoms, and this sure doesn't *look* like a userland problem. Trying to reduce it to a specific option First, no variables or alternate kernels work until I type show (that seems broken) Setting all of the kern variables allow it to boot Setting all of the hw.ata.*dma doesn't change anything Setting hw.ata.wc causes a panic/reboot Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r247095 Boot Failure
On Thu, Feb 21, 2013 at 3:34 PM, Navdeep Parhar wrote: > > Take a look at the "-CURRENT userland regression" thread. You may be > able to boot if you choose "safe mode" in the boot loader menu. > > Regards, > Navdeep > > What is safe mode as far as boot flags? boot -sv doesn't work on my system... Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Kernel hang r247079 mps/vfs/zfs?
--Meant to reply to list as well-- On Thu, Feb 21, 2013 at 2:32 PM, Steve Wills wrote: > > I am experiencing a similar hang when updating from r246190 to r247017 on > my all zfs system. The system has two drives in a zfs mirror and hangs > after detecting the hard drives. The last thing seen is the "ada1: > Previously was known as ad8" message, then it hangs completely, unable to > even ctrl-alt-del or even get the numlock key to toggle the light. System > is: > > CPU: AMD Phenom(tm) II X4 955 Processor (3214.39-MHz K8-class CPU) > > with ASUS M4A78LT-M board. Let me know if other details will help. > > Steve > > > Symptoms are identical to mine as far as I can tell. I did see fatal trap flash in one case, but couldn't read the crash info. It doesn't always just hang, once I got fatal trap and a reboot, other times I got a hard reboot without fatal trap printout. Unfortunately I wasn't able to catch anything other than "fatal trap..." before the machine cycled. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Kernel hang r247079 mps/vfs/zfs?
I was testing a patch on r246300 or so, and wanted to see if it would apply cleanly to a newer copy of HEAD. Well it did, except I had a hang at boot, shortly after ZFS version and the last scsi devices appear. This easily could have been related to the patch I was testing, so I wiped /usr/src/ and /usr/obj (after booting kernel.old) and rebuilt world and kernel cleanly. I assumed that would resolve the issue, but it did not. The hang happens right after zfs is announced, and the last da devices (some of which are usb) are reported. It comes before the noisy output of mps. Hang is complete, and single user or verbose don't yield much. I'm having trouble exfiltrating a dmesg from it, but it may be unrelated to the userland issues reported earlier, as single user does not resolve it for me. The svn up was at 11:20 pacific (GMT +8). Anyone else seeing similar issues? Hardware is an LSI mps device, "9210" crossflashed m1015. Pool is a zfs mirror. Works fine booting from r246300 kernel. Motherboard is an AMD Tyan. Pulling USB headers off the board didn't resolve it. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH] USB power usage reporting
The following patch adds the ability to read power draw on usb devices.
I have used ioctl 135. I don't know what the protocol is for assigning
numbers, so this may be unacceptable?
ugen is patched to export the data via ioctl
libusb20 and usbconfig are patched to make use of it (end-of-line):
[mattb@falcon ~]$ usbconfig
ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=SAVE (0mA)
ugen1.1: at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps)
pwr=SAVE (0mA)
ugen2.1: at usbus2, cfg=0 md=HOST spd=SUPER (5.0Gbps)
pwr=SAVE (0mA)
ugen3.1: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=SAVE (0mA)
ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen3.3: at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps)
pwr=ON (70mA)
ugen3.4: at usbus3, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (98mA)
ugen3.5: at usbus3, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (0mA)
ugen3.6: at usbus3, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (100mA)
diff --git a/lib/libusb/libusb20.3 b/lib/libusb/libusb20.3
index af80c6c..8753e06 100644
--- a/lib/libusb/libusb20.3
+++ b/lib/libusb/libusb20.3
@@ -149,6 +149,8 @@ USB access library (libusb -lusb)
.Fn libusb20_dev_set_power_mode "struct libusb20_device *pdev" "uint8_t
power_mode"
.Ft uint8_t
.Fn libusb20_dev_get_power_mode "struct libusb20_device *pdev"
+.Ft uint16_t
+.Fn libusb20_dev_get_power_usage "struct libusb20_device *pdev"
.Ft int
.Fn libusb20_dev_set_alt_index "struct libusb20_device *pdev" "uint8_t
iface_index" "uint8_t alt_index"
.Ft struct LIBUSB20_DEVICE_DESC_DECODED *
@@ -740,6 +742,11 @@ USB device.
.
.Pp
.
+.Fn libusb20_dev_get_power_usage
+returns the reported power usage in milliamps for the given USB device.
+.
+.Pp
+.
.Fn libusb20_dev_set_alt_index
will try to set the given alternate index for the given
USB interface index.
diff --git a/lib/libusb/libusb20.c b/lib/libusb/libusb20.c
index aa45991..ce75511 100644
--- a/lib/libusb/libusb20.c
+++ b/lib/libusb/libusb20.c
@@ -71,6 +71,7 @@ dummy_callback(struct libusb20_transfer *xfer)
#definedummy_check_connected (void *)dummy_int
#definedummy_set_power_mode (void *)dummy_int
#definedummy_get_power_mode (void *)dummy_int
+#definedummy_get_power_usage (void *)dummy_int
#definedummy_kernel_driver_active (void *)dummy_int
#definedummy_detach_kernel_driver (void *)dummy_int
#definedummy_do_request_sync (void *)dummy_int
@@ -717,6 +718,18 @@ libusb20_dev_get_power_mode(struct libusb20_device *pdev)
return (power_mode);
}
+uint16_t
+libusb20_dev_get_power_usage(struct libusb20_device *pdev)
+{
+ int error;
+ uint16_t power_usage;
+
+ error = pdev->methods->get_power_usage(pdev, &power_usage);
+ if (error)
+ power_usage = 0;
+ return (power_usage);
+}
+
int
libusb20_dev_set_alt_index(struct libusb20_device *pdev, uint8_t ifaceIndex,
uint8_t altIndex)
{
diff --git a/lib/libusb/libusb20.h b/lib/libusb/libusb20.h
index 87e0572..81928b1 100644
--- a/lib/libusb/libusb20.h
+++ b/lib/libusb/libusb20.h
@@ -255,6 +255,7 @@ int libusb20_dev_reset(struct libusb20_device *pdev);
intlibusb20_dev_check_connected(struct libusb20_device *pdev);
intlibusb20_dev_set_power_mode(struct libusb20_device *pdev, uint8_t
power_mode);
uint8_tlibusb20_dev_get_power_mode(struct libusb20_device *pdev);
+uint16_t libusb20_dev_get_power_usage(struct libusb20_device *pdev);
intlibusb20_dev_set_alt_index(struct libusb20_device *pdev, uint8_t
iface_index, uint8_t alt_index);
intlibusb20_dev_get_info(struct libusb20_device *pdev, struct
usb_device_info *pinfo);
intlibusb20_dev_get_iface_desc(struct libusb20_device *pdev, uint8_t
iface_index, char *buf, uint8_t len);
diff --git a/lib/libusb/libusb20_int.h b/lib/libusb/libusb20_int.h
index 0251c5f..6705c63 100644
--- a/lib/libusb/libusb20_int.h
+++ b/lib/libusb/libusb20_int.h
@@ -105,6 +105,7 @@ typedef int (libusb20_process_t)(struct libusb20_device
*pdev);
typedef int (libusb20_reset_device_t)(struct libusb20_device *pdev);
typedef int (libusb20_set_power_mode_t)(struct libusb20_device *pdev, uint8_t
power_mode);
typedef int (libusb20_get_power_mode_t)(struct libusb20_device *pdev, uint8_t
*power_mode);
+typedef int (libusb20_get_power_usage_t)(struct libusb20_device *pdev,
uint16_t *power_usage);
typedef int (libusb20_set_alt_index_t)(struct libusb20_device *pdev, uint8_t
iface_index, uint8_t alt_index);
typedef int (libusb20_set_config_index_t)(struct libusb20_device *pdev,
uint8_t index);
typedef int (libusb20_check_connected_t)(struct libusb20_device *pdev);
@@ -127,6 +128,7 @@ typedef void (libusb20_tr_cancel_async_t)(struct
libusb20_transfer *xfer);
m(n, check_connected) \
m(n, set_power_mode) \
m(n, get_power_mode) \
+ m(n, get_power_usage) \
m(n, set_alt_index) \
m(n, set_config_index) \
m(n, tr_cancel_async)
[PATCH] Minor spelling error in sound/pci/hda
Only a simple spelling error, but it's been driving me nuts...
--- a/sys/dev/sound/pci/hda/hdaa.c
+++ b/sys/dev/sound/pci/hda/hdaa.c
@@ -557,7 +557,7 @@ hdaa_presence_handler(struct hdaa_widget *w)
HDA_BOOTVERBOSE(
if (connected || old != 2) {
device_printf(devinfo->dev,
- "Pin sense: nid=%d sence=0x%08x (%sconnected)\n",
+ "Pin sense: nid=%d sense=0x%08x (%sconnected)\n",
w->nid, res, !connected ? "dis" : "");
}
);
@@ -706,7 +706,7 @@ hdaa_eld_handler(struct hdaa_widget *w)
}
HDA_BOOTVERBOSE(
device_printf(devinfo->dev,
- "Pin sense: nid=%d sence=0x%08x "
+ "Pin sense: nid=%d sense=0x%08x "
"(%sconnected, ELD %svalid)\n",
w->nid, res,
(res & HDA_CMD_GET_PIN_SENSE_PRESENCE_DETECT) ? "" : "dis",
--
Sorry for the following...
The information contained in this message is confidential and intended for the
addressee only. If you have received this message in error, or there are any
problems with its content, please contact the sender.
iCritical is a trading name of Critical Software Ltd. Registered in England:
04909220.
Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH.
This message has been scanned for security threats by iCritical.
www.icritical.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Intel 82574 issue reported on Slashdot
On 02/09/13 09:15, Johnny Eriksson wrote: >> In all honesty.. The blog post (and your email) are basically >> information free, they don't name names and provide no script >> or downloadable code that will allow end users to check if they >> are affected. > A link with a little bit more information: > > http://blog.krisk.org/2013/02/packets-of-death.html > >> Daniel O'Connor software and network engineer > --Johnny > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Did anyone check to see if the Intel announcement had a 2 at 0x47f? :) I do have a machine with these controllers that had a bridge "hang" in a very odd fashion a while back, but it didn't repeat. It wasn't a SuperMicro board, which is what some posters were saying were affected. I would imagine a large ping packet (as used to test MTU) should inoculate any affected interface if issued at boot, I don't think our padding lines up with the problem. Once an interface sees a packet with anything else at 0x47f, it's no longer affected, so there's a narrow window of vulnerability in affected NICs. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[patch] Userland DTrace
I've been spending some time trying to get the fasttrap provider to work
on FreeBSD without panicing. I believe I have succeeded, at least to the
point where it's no longer panicing.
There were two panic causes. The first was
http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of
fasttrap.c caused ftp_rcount to be left >0. To fix this I've got rid of
the early return and reverted to the opensolaris way.
A second panic then showed up intermittently when fasttrap_pid_cleanup_cb
was run while something in userland had locks. Using sx_try_xlock calls
has stopped the panics and shouldn't affect operation AFAICT.
This is against r246454.
Although this has fixed the panics for me, I'm finding a lot of stuff just
isn't actually working, with dtrace and the traced process just chewing
CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I
have no idea what the target is doing... CPU time is split 2:1
dtrace:target
Also noteworthy is the LOR on the first time you try to use the fasttrap
provider: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165479
The lock order there seems right, so I'm guessing "something else" must
have done it wrong first? How can I find out what the "something else"
is?
Thanks
--- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c
@@ -7536,9 +7536,23 @@ dtrace_unregister(dtrace_provider_id_t id)
return (EBUSY);
}
} else {
+#if defined(sun)
mutex_enter(&dtrace_provider_lock);
mutex_enter(&mod_lock);
mutex_enter(&dtrace_lock);
+#else
+ if (sx_try_xlock(&dtrace_provider_lock) == 0)
+ return (EBUSY);
+ if (sx_try_xlock(&mod_lock) == 0) {
+ mutex_exit(&dtrace_provider_lock);
+ return (EBUSY);
+ }
+ if (sx_try_xlock(&dtrace_lock) == 0) {
+ mutex_exit(&mod_lock);
+ mutex_exit(&dtrace_provider_lock);
+ return (EBUSY);
+ }
+#endif
}
/*
--- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c
@@ -1116,23 +1116,28 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void
*parg)
ASSERT(id == probe->ftp_id);
- mutex_enter(&provider->ftp_mtx);
-
/*
* We won't be able to acquire a /proc-esque lock on the process
* iff the process is dead and gone. In this case, we rely on the
* provider lock as a point of mutual exclusion to prevent other
* DTrace consumers from disabling this probe.
*/
- if ((p = pfind(probe->ftp_pid)) == NULL) {
- mutex_exit(&provider->ftp_mtx);
- return;
+
+#if defined(sun)
+ if ((p = sprlock(probe->ftp_pid)) != NULL) {
+ ASSERT(!(p->p_flag & SVFORK));
+ mutex_exit(&p->p_lock);
+ }
+#else
+ if ((p = pfind(probe->ftp_pid)) != NULL) {
+ _PHOLD(p);
+ PROC_UNLOCK(p);
}
-#ifdef __FreeBSD__
- _PHOLD(p);
- PROC_UNLOCK(p);
#endif
+ mutex_enter(&provider->ftp_mtx);
+
+
/*
* Disable all the associated tracepoints (for fully enabled probes).
*/
@@ -1154,6 +1159,13 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void
*parg)
if (provider->ftp_retired && !provider->ftp_marked)
whack = provider->ftp_marked = 1;
mutex_exit(&provider->ftp_mtx);
+
+#if defined(sun)
+ mutex_enter(&p->p_lock);
+ sprunlock(p);
+#else
+ PRELE(p);
+#endif
} else {
/*
* If the process is dead, we're just waiting for the
@@ -1167,9 +1179,6 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void
*parg)
if (whack)
fasttrap_pid_cleanup();
-#ifdef __FreeBSD__
- PRELE(p);
-#endif
if (!probe->ftp_enabled)
return;
--
Sorry for the following...
The information contained in this message is confidential and intended for the
addressee only. If you have received this message in error, or there are any
problems with its content, please contact the sender.
iCritical is a trading name of Critical Software Ltd. Registered in England:
04909220.
Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH.
This message has been scanned for security threats by iCritical.
www.icritical.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ZFS Trim on mps?
Should I be getting trim with ZFS on an mps device? Disks are SATA ssd (830s), only "unsupported" is being reported. Do I need to set the cam "da" delete method to something (unmap?), or is ZFS trim only supported on ahci sata controllers? vfs.zfs.trim_disable: 0 vfs.zfs.trim_txg_limit: 64 kstat.zfs.misc.zio_trim.bytes: 0 kstat.zfs.misc.zio_trim.success: 0 kstat.zfs.misc.zio_trim.unsupported: 281 Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: installworld failure due to cross-device links
On 01/02/13 13:26, Nathan Whitehorn wrote: > Thanks for the patch! I've committed it (slightly modified) as r244958. > I haven't taken any action on the chgrp/chown issue, though. Similarly, 'make distribution' fails when /root is a separate filesystem: cd /usr/src/etc/root; install -o root -g wheel -m 644 dot.profile /tmproot/root/.profile; rm -f /tmproot/.profile; ln /tmproot/root/.profile /tmproot/.profile ln: /tmproot/.profile: Cross-device link *** [distribution] Error code 1 Is there any real advantage of hard links over symlinks nowadays? -- Sorry for the following... The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lenovo x220 suspend/resume broken
On 12/14/12 04:55, Ganael LAPLANCHE wrote: > Hi everyone, > > Following this thread : > > http://lists.freebsd.org/pipermail/freebsd-current/2012-March/032519.html > > I have finally taken time to track this regression. It occurs with > revision 231797 : > > http://svnweb.freebsd.org/base?view=revision&revision=231797 > > Could anyone have a look at it ? > > Best regards, > > -- > Ganael LAPLANCHE > http://www.martymac.org | http://contribs.martymac.org > FreeBSD: martymac , http://www.FreeBSD.org Thanks for digging for that... Perhaps revert the spinlocks to the the intr_suspend/intr_resume code and see if it has an effect? It's an uneducated guess :) Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.1-RC3 LiveCD missing features
On 12/07/12 17:20, Kevin Oberman wrote: > > ports/sysutils/smartmontools? Most modern disks support S.M.A.R.T and > will log read or write errors as well as perform non-destructive > (though far from comprehensive) testing. This is the correct way, since the drive could be hiding bad blocks by reallocating dying sectors. Look at your pending sector count, this should be 0 on a good disk. If it does have a value, it should go away when the sector is moved/reallocated. Personally, I don't expect much advanced disk diagnosis out of a system installer (be it Linux, Windows or Freebsd). Use this (it's freedos): http://hddguru.com/software/2005.10.02-MHDD/ It can deallocate bad sectors (will require reformat) and show "slow" sectors as well, in a waterfall-type display. As far as in the base system, it may be a little late for this, but ZFS would indicate unreadable blocks via checksum errors after a scrub, would it not? Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New jail does not understand nullfs
Sorry I meant man jail, as jail.conf has it as mount.devfs On Mon, Dec 3, 2012 at 11:23 PM, Matt Donovan wrote: > Below is the output of truss jail -c poudriere > > __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x1c) > = 0 (0x0) > __sysctl(0x7fffd450,0x7,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 > (0x0) > __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x1b) > = 0 (0x0) > __sysctl(0x7fffd450,0x6,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 > (0x0) > __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x20) > = 0 (0x0) > __sysctl(0x7fffd450,0x7,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 > (0x0) > __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x1f) > = 0 (0x0) > __sysctl(0x7fffd450,0x7,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 > (0x0) > __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x26) > ERR#2 'No such file or directory' > jail: write(2,"jail: ",6) = 6 (0x6) > poudriere: unknown parameter: allow.mount.nullfswrite(2,"poudriere: > unknown parameter: al"...,48) = 48 (0x30) > > write(2,"\n",1) = 1 (0x1) > __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x25) > = 0 (0x0) > __sysctl(0x7fffd450,0x7,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 > (0x0) > __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x23) > = 0 (0x0) > __sysctl(0x7fffd450,0x7,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 > (0x0) > __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x21) > = 0 (0x0) > __sysctl(0x7fffd450,0x7,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 > (0x0) > __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x22) > = 0 (0x0) > __sysctl(0x7fffd450,0x6,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 > (0x0) > __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x18) > = 0 (0x0) > __sysctl(0x7fffd450,0x6,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 > (0x0) > __sysctl(0x7fffd458,0x4,0x7fffd4b4,0x7fffd8b8,0x0,0x0) = 0 > (0x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > = 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > = 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > = 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > = 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > = 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > process exit, rval = 1 > > I just updated the system before my last reply. So I am sure that all is > in sync. The documentation of jail.conf though is off as it states > allow.mount.devfs should be used but this errors out mount.devfs works. > > > > On Mon, Dec 3, 2012 at 4:35 AM, Mateusz Guzik wrote: > >> On Mon, Dec 03, 2012 at 02:45:09AM -0600, Matt Donovan wrote: >> > Updated system to r243801 the allow.mount.nullfs still errors out. >> > On Dec 2, 2012 8:15 PM, "Matt Donovan" wrote: >> > >> >> Can you post output of truss jail -c poudriere? Are you sure that both >> jail(8) and libjail are updated? (or that world and kernel are in sync) >> >> -- >> Mateusz Guzik >> > > > > -- > Technological progress is like an ax in the hands of a pathological > criminal. > -*Albert Einstein > > Breadth of Unix experience and depth of knowledge in the world of servers. > > * > > -- Technological progress is like an ax in the hands of a pathological criminal. -*Albert Einstein Breadth of Unix experience and depth of knowledge in the world of servers. * ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New jail does not understand nullfs
Below is the output of truss jail -c poudriere __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x1c) = 0 (0x0) __sysctl(0x7fffd450,0x7,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x1b) = 0 (0x0) __sysctl(0x7fffd450,0x6,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x20) = 0 (0x0) __sysctl(0x7fffd450,0x7,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x1f) = 0 (0x0) __sysctl(0x7fffd450,0x7,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x26) ERR#2 'No such file or directory' jail: write(2,"jail: ",6) = 6 (0x6) poudriere: unknown parameter: allow.mount.nullfswrite(2,"poudriere: unknown parameter: al"...,48) = 48 (0x30) write(2,"\n",1) = 1 (0x1) __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x25) = 0 (0x0) __sysctl(0x7fffd450,0x7,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x23) = 0 (0x0) __sysctl(0x7fffd450,0x7,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x21) = 0 (0x0) __sysctl(0x7fffd450,0x7,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x22) = 0 (0x0) __sysctl(0x7fffd450,0x6,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffd450,0x2,0x7fffd458,0x7fffd8c0,0x7fffd4b4,0x18) = 0 (0x0) __sysctl(0x7fffd450,0x6,0x7fffd4b0,0x7fffd8b8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffd458,0x4,0x7fffd4b4,0x7fffd8b8,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) process exit, rval = 1 I just updated the system before my last reply. So I am sure that all is in sync. The documentation of jail.conf though is off as it states allow.mount.devfs should be used but this errors out mount.devfs works. On Mon, Dec 3, 2012 at 4:35 AM, Mateusz Guzik wrote: > On Mon, Dec 03, 2012 at 02:45:09AM -0600, Matt Donovan wrote: > > Updated system to r243801 the allow.mount.nullfs still errors out. > > On Dec 2, 2012 8:15 PM, "Matt Donovan" wrote: > > > > Can you post output of truss jail -c poudriere? Are you sure that both > jail(8) and libjail are updated? (or that world and kernel are in sync) > > -- > Mateusz Guzik > -- Technological progress is like an ax in the hands of a pathological criminal. -*Albert Einstein Breadth of Unix experience and depth of knowledge in the world of servers. * ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New jail does not understand nullfs
Updated system to r243801 the allow.mount.nullfs still errors out.
On Dec 2, 2012 8:15 PM, "Matt Donovan" wrote:
> Attached is my jail.conf. according to my logs I am using r243464. Going
> to do another svn update and try again as well.
> On Dec 2, 2012 7:12 PM, "Mateusz Guzik" wrote:
>
>> On Sun, Dec 02, 2012 at 08:09:39AM -0700, Ian Lepore wrote:
>> > On Sun, 2012-12-02 at 01:17 -0600, Matt Donovan wrote:
>> > > When attempting to start the jail in question the following happens
>> > >
>> > >
>> > > server# jail -c poudriere
>> > > jail: poudriere: unknown parameter: allow.mount.nullfs
>> > >
>> > >
>> > > Below is my jail.conf
>> > >
>> > > poudriere {
>> > > name=poudriere;
>> > > host.hostname=poudriere;
>> > > ip4.addr="192.168.1.30";
>> > >persist;
>> > > children.max=10;
>> > > allow.mount;
>> > > mount.devfs;
>> > > allow.mount.nullfs;
>> > > allow.raw_sockets;
>> > > allow.socket_af;
>> > > allow.sysvipc;
>> > > enforce_statfs=1;
>> > > path=/newsystem/jail/poudriere;
>> > > exec.stop="umount -a";
>> > > }
>> > >
>> > > Does the switch not work yet? As I am using CURRENT with the latest
>> > > revision.
>> > >
>> >
>> > That "mount.devfs" doesn't look right, should that have "allow." on the
>> > front? I wonder if that's the problem and the error report is off by
>> > one line or something?
>> >
>>
>> mount.devfs means "mount devfs" :)
>>
>> However, it indeed may be some issue with config parsing, e.g. some
>> mishandled whitespace.
>>
>> Matt, in general this should work just fine. What revision are you using
>> to test? Can you attach this config instead of copy-pasting it?
>>
>> --
>> Mateusz Guzik
>>
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New jail does not understand nullfs
Attached is my jail.conf. according to my logs I am using r243464. Going to
do another svn update and try again as well.
On Dec 2, 2012 7:12 PM, "Mateusz Guzik" wrote:
> On Sun, Dec 02, 2012 at 08:09:39AM -0700, Ian Lepore wrote:
> > On Sun, 2012-12-02 at 01:17 -0600, Matt Donovan wrote:
> > > When attempting to start the jail in question the following happens
> > >
> > >
> > > server# jail -c poudriere
> > > jail: poudriere: unknown parameter: allow.mount.nullfs
> > >
> > >
> > > Below is my jail.conf
> > >
> > > poudriere {
> > > name=poudriere;
> > > host.hostname=poudriere;
> > > ip4.addr="192.168.1.30";
> > >persist;
> > > children.max=10;
> > > allow.mount;
> > > mount.devfs;
> > > allow.mount.nullfs;
> > > allow.raw_sockets;
> > > allow.socket_af;
> > > allow.sysvipc;
> > > enforce_statfs=1;
> > > path=/newsystem/jail/poudriere;
> > > exec.stop="umount -a";
> > > }
> > >
> > > Does the switch not work yet? As I am using CURRENT with the latest
> > > revision.
> > >
> >
> > That "mount.devfs" doesn't look right, should that have "allow." on the
> > front? I wonder if that's the problem and the error report is off by
> > one line or something?
> >
>
> mount.devfs means "mount devfs" :)
>
> However, it indeed may be some issue with config parsing, e.g. some
> mishandled whitespace.
>
> Matt, in general this should work just fine. What revision are you using
> to test? Can you attach this config instead of copy-pasting it?
>
> --
> Mateusz Guzik
>
jail.conf
Description: Binary data
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
New jail does not understand nullfs
When attempting to start the jail in question the following happens
server# jail -c poudriere
jail: poudriere: unknown parameter: allow.mount.nullfs
Below is my jail.conf
poudriere {
name=poudriere;
host.hostname=poudriere;
ip4.addr="192.168.1.30";
persist;
children.max=10;
allow.mount;
mount.devfs;
allow.mount.nullfs;
allow.raw_sockets;
allow.socket_af;
allow.sysvipc;
enforce_statfs=1;
path=/newsystem/jail/poudriere;
exec.stop="umount -a";
}
Does the switch not work yet? As I am using CURRENT with the latest
revision.
--
Technological progress is like an ax in the hands of a pathological
criminal.
-*Albert Einstein
Breadth of Unix experience and depth of knowledge in the world of servers.
*
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pw keeps setting /etc/group to 0600
On 11/17/12 07:24, Ryan Stone wrote: > /etc/group is supposed to be world-reable, right? Tools like groups or pw > groupshow certainly seem to think so: > > [rstone@rstone-server ~]groups > 1001 920 > [rstone@rstone-server ~]ls -l /etc/group > -rw--- 1 root 0 482 Nov 14 21:02 /etc/group > [rstone@rstone-server ~]sudo chmod a+r /etc/group > Password: > [rstone@rstone-server ~]groups > rstone vboxusers > [rstone@rstone-server ~]sudo pw groupadd foo > [rstone@rstone-server ~]ls -l /etc/group > -rw--- 1 root 0 494 Nov 17 10:19 /etc/group > [rstone@rstone-server ~] > > I'm not sure what caused the regression. I've been seeing the problem > since I first installed -CURRENT on the machine a couple of weeks ago. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Interesting, I noticed my pw segfaulted twice on 'pw groupdel' twice out of three groups deleted. Not sure if related. I'm at r243502. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
On 10/12/12 00:54, Claude Buisson wrote:
On 10/12/2012 05:00, matt wrote:
I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of
"USE_GCC=any" to a port's Makefile, and then committed that change to
various ports. In most (but not all!) cases this will tell the port
"build with gcc instead of clang" (*) .
Why not USE_GCC ?= any for the poor guys like me who build (some)
ports with
USE_GCC=4.6 ?
For those users with CC installed as gcc (including -stable), this
patch should have no effect. Variations of combinations have been
heavily tested on pointyhat-west. If there are any regressions,
please
contact me.
Does this override setting CC explicitly in make.conf?
Sorry if it's a dumb question, not sure exactly the hierarchy of USE_GCC
vs CC in the make system.
Dumb as I am, I also wonder when I see that in multimedia/x264:
...
USE_GCC=any
...
.if ${PORT_OPTIONS:MGCC44}
USE_GCC?=4.4+
.endif
...
which seems to deny the intent of the GCC44 option
Sorry but I can not make the test at this present time
Matt
Claude Buisson
I tested, and can confirm two things. CC is overpowered by USE_GCC=any,
which means that I end up with no sse4a and limited support for my arch
(Opteron 4xxx) because I can't set a better -march/cputype than
opteron-sse3. As far as I know base gcc doesn't even support sse4a. This
is really perhaps an issue with me setting CC in make.conf moreso than
ports, however this was the approved method of using clang by default as
well as the approved method of using ports gcc in the ports system. Is
there a new approved method?
M. Buisson's test case also fails, with base gcc being used even though
the gcc44 option is chosen. This may not break as many ports as it
might, but it will certainly create low performing editions of many
multimedia ports given the CPU features supported by either later clang
or gcc. Some will probably break?
If I missed something, please let me know, or if my testing is somehow
compromised. I removed make.conf (as mine is customized) for Claude's
test case, but it's possible something else may have affected my test
results. USE_GCC=any was manually added to the ports makefiles (test
case was editors/nano and multimedia/x264).
Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Buying recommendation for silent router/fileserver
On 10/11/12 07:54, Ulrich Spörlein wrote: Hey guys, I need to replace an aging Pentium IV system that has been serving as my router, access point, file- and mediaserver for quite some time now. The replacement should have: - amd64 CPU (for ZFS, obviously) - 2x GigE (igress, egress interfaces) - some form of wlan interface (I currently use an Atheros based PCI card) - eSATA for attaching a backup disk where I stream ZFS snapshots to - serial port is always nice, for when I mess up an upgrade - fan-less if possible So far, this here seems to fit the bill perfectly http://www.fit-pc.com/web/fit-pc/intensepc/ but pricing seems to defy any reality. It does not state directly which chipsets are used for Wifi and Ethernet, the block diagram claims Ethernet chips to be Intel 82579 and RTL8111D, but I don't trust that fully. For Wifi I can always fall back to sticking in a supported USB stick, although that's kinda hacky. So how well is networking going to be supported by FreeBSD? Should I just bite the bullet and find out? Cheers, Uli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" http://www.intel.com/p/en_US/embedded/designcenter/tools/seed-board-program Might be an option...not sure if you mind a discontinued processor. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of "USE_GCC=any" to a port's Makefile, and then committed that change to various ports. In most (but not all!) cases this will tell the port "build with gcc instead of clang" (*) . Why not USE_GCC ?= any for the poor guys like me who build (some) ports with USE_GCC=4.6 ? For those users with CC installed as gcc (including -stable), this patch should have no effect. Variations of combinations have been heavily tested on pointyhat-west. If there are any regressions, please contact me. Does this override setting CC explicitly in make.conf? Sorry if it's a dumb question, not sure exactly the hierarchy of USE_GCC vs CC in the make system. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: squealing/whistling audio
On 09/18/12 23:00, Doug Barton wrote: On 9/18/2012 10:56 PM, matt wrote: On 09/18/12 18:01, Doug Barton wrote: Sometime in the last couple of months an old problem has resurfaced on HEAD, a sort of squealing/whistling sound in the audio, even without anything playing. The sound is similar to the wind whistling through something. Before I blindly go off on a bisecting spree, does anyone have a suggestion as to where I might look? Doug Electrically that's usually oscillation (too high gain or too much electrical feedback) or an unshielded input. Sorry, I should have been more clear. This problem doesn't occur in windows, or linux, and last time I checked, didn't occur in freebsd 8. I have everything irrlevant zeroed out in mixer. Doug It was worth a shot. It is possible that each OS (and version) is setting the associations up properly though except HEAD on your machine. Is it a laptop or a desktop board? Any difference in the nid configuration between freebsd 8 and HEAD? Does changing any of the hw.snd sysctls (latency, exact rate, vpc_0db) have any effect on the sound? http://freshbsd.org/commit/freebsd/r230551 might be worth a look. I couldn't find anything newer that looked like it would have an effect. Their are some earlier commits around January that are dealing with signal gain that could also have an effect. Otherwise, I'm not sure where else to look. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: squealing/whistling audio
On 09/18/12 18:01, Doug Barton wrote: Sometime in the last couple of months an old problem has resurfaced on HEAD, a sort of squealing/whistling sound in the audio, even without anything playing. The sound is similar to the wind whistling through something. Before I blindly go off on a bisecting spree, does anyone have a suggestion as to where I might look? Doug Electrically that's usually oscillation (too high gain or too much electrical feedback) or an unshielded input. My guess would be that there is an input that is defined and active in software, but is a loose, ungrounded pin in real life. Like a second microphone input on the chip, but not actually connected, would be my guess. Can you try purging out nids that you don't use with loader tunables (set their as to 0)? Or sysctls as reboots aren't as necessary anymore with snd_hda? Maybe something changed in software that is seeing inputs that were not present. Also just try muting all inputs with mixer... Just a guess, but when I hear squealing/whistling/howling I think "analog" before I think "digital"... Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mfi driver performance
On 09/13/12 13:13, Garrett Cooper wrote:
On Thu, Sep 13, 2012 at 12:54 PM, matt wrote:
On 09/10/12 19:31, Garrett Cooper wrote:
...
It seems hw.mfi.max_cmds is read only. The performance is pretty close to
expected with no nvram or bbu on this card and commodity disks from 1.5
years ago, as far as I'm concerned. I'd love better write performance, but
it's probably being held back by the single platter in the mirror when it is
writing far from its edge.
Try loader.conf:
$ grep -r hw.mfi.max_cmds /sys/dev/mfi/
/sys/dev/mfi/mfi.c:TUNABLE_INT("hw.mfi.max_cmds", &mfi_max_cmds);
Cheers,
-Garrett
Here are the results for differing values of max_cmds with same test
conditions as against mps
Original mfi performance (max_cmds=128)
Version 1.96 --Sequential Output-- --Sequential Input-
--Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
/sec %CP
flatline.local 32G 125 99 71443 24 53177 21 317 99 220280 33
255.3 52
Latency 533ms 566ms1134ms 86565us 357ms 252ms
Version 1.96 --Sequential Create-- Random
Create
flatline.local -Create-- --Read--- -Delete-- -Create-- --Read---
-Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
/sec %CP
16 22347 94 12389 30 16804 100 18729 99 27798 99
5317 99
Latency 33818us 233ms 558us 26581us 75us 12319us
1.96,1.96,flatline.local,1,1347329123,32G,,125,99,71443,24,53177,21,317,99,220280,33,255.3,52,16,22347,94,12389,30,16804,100,18729,99,27798,99,5317,99,533ms,566ms,1134ms,86565us,357ms,252ms,33818us,233ms,558us,26581us,75us,12319us
max_cmds=256
Version 1.96 --Sequential Output-- --Sequential Input-
--Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
/sec %CP
flatline.local 32G 125 99 70856 24 53503 21 327 98 232650 33
265.1 60
Latency 637ms 522ms1050ms 121ms 318ms 339ms
Version 1.96 --Sequential Create-- Random
Create
flatline.local -Create-- --Read--- -Delete-- -Create-- --Read---
-Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
/sec %CP
16 17126 76 11865 31 17134 99 18265 99 27169 100
5006 99
Latency 114ms 522ms 875us 24250us 87us 14324us
1.96,1.96,flatline.local,1,1347580235,32G,,125,99,70856,24,53503,21,327,98,232650,33,265.1,60,16,17126,76,11865,31,17134,99,18265,99,27169,100,5006,99,637ms,522ms,1050ms,121ms,318ms,339ms,114ms,522ms,875us,24250us,87us,14324us
max_cmds=64
Version 1.96 --Sequential Output-- --Sequential Input-
--Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
/sec %CP
flatline.local 32G 125 99 71161 24 54035 21 288 90 229860 34
254.2 62
Latency 310ms 378ms 809ms 567ms 308ms 447ms
Version 1.96 --Sequential Create-- Random
Create
flatline.local -Create-- --Read--- -Delete-- -Create-- --Read---
-Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
/sec %CP
16 22570 95 14243 35 13170 99 23503 99 + +++
5 99
Latency 18111us 282ms1165us 24786us 117us 80us
1.96,1.96,flatline.local,1,1347584224,32G,,125,99,71161,24,54035,21,288,90,229860,34,254.2,62,16,22570,95,14243,35,13170,99,23503,99,+,+++,5,99,310ms,378ms,809ms,567ms,308ms,447ms,18111us,282ms,1165us,24786us,117us,80us
Still digesting the differences, but 256 seems to get more random seeks
and better sequential reads at the expense of higher latencies (some
probably identical). I think with lots of small files like a buildworld,
it looks like 64 would excel slightly more than 128, but the differences
between 128 and 64 are less extreme than the difference between 128 and
256. Interestingly, sequential read appears better at 64 and 256 than
128, but I assume this is a testing fluke...sample set is small.
Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mfi driver performance
On 09/13/12 13:13, Garrett Cooper wrote:
> On Thu, Sep 13, 2012 at 12:54 PM, matt wrote:
>> On 09/10/12 19:31, Garrett Cooper wrote:
> ...
>
>> It seems hw.mfi.max_cmds is read only. The performance is pretty close to
>> expected with no nvram or bbu on this card and commodity disks from 1.5
>> years ago, as far as I'm concerned. I'd love better write performance, but
>> it's probably being held back by the single platter in the mirror when it is
>> writing far from its edge.
> Try loader.conf:
>
> $ grep -r hw.mfi.max_cmds /sys/dev/mfi/
> /sys/dev/mfi/mfi.c:TUNABLE_INT("hw.mfi.max_cmds", &mfi_max_cmds);
>
> Cheers,
> -Garrett
$ cat /usr/src/sys/dev/mfi/*.c | fgrep 'max_cmds'
static intmfi_max_cmds = 128;
TUNABLE_INT("hw.mfi.max_cmds", &mfi_max_cmds);
SYSCTL_INT(_hw_mfi, OID_AUTO, max_cmds, CTLFLAG_RD, &mfi_max_cmds,
ncmds = MIN(mfi_max_cmds, sc->mfi_max_fw_cmds);
Definitely a loader tunable, thanks. I'll try increasing and decreasing
the value and running bonnie again...Still not sure whether I'm getting
3gb/s and 6gb/s negotiation with my drives. MPS correctly reported da
devices with 600mb/s and 300mb/s transfers where appropriate. mfiutil
doesn't seem to know, and mfip devices appear as 150mb/s. No transfer
speed message when mfisyspd devices attach.
Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mfi driver performance
On 09/10/12 19:31, Garrett Cooper wrote: On Mon, Sep 10, 2012 at 7:15 PM, matt wrote: ... mfip was necessary, and allowed smartctl to work with '-d sat' bonnie++ comparison. Run with no options immediately after system boot. In both cases the same disks are used, two Seagate Barracuda 1TB 3G/S (twin platter) and a Barracuda 500G 3G/s (single platter) in a zfs triple mirror that the system was booted from. All are 7200 RPM drives with 32mb cache, and mediocre performance compared to my hitachi 7k3000s or the 15k sas cheetahs at work etc. Firmwares were the latest 2108it vs the latest imr_fw that work on the 9240/9220/m1015/drake skinny. I wish I had some 6g ssds to try! MPS: Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP flatline.local 32G 122 99 71588 24 53293 20 284 90 222157 33 252.6 49 Latency 542ms 356ms 914ms 991ms 337ms 271ms Version 1.96 --Sequential Create-- Random Create flatline.local -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 22197 93 9367 27 16821 99 23555 99 + +++ 23717 99 Latency 31650us 290ms 869us 23036us 66us 131us 1.96,1.96,flatline.local,1,1347322810,32G,,122,99,71588,24,53293,20,284,90,222157,33,252.6,49,16,22197,93,9367,27,16821,99,23555,99,+,+++,23717,99,542ms,356ms,914ms,991ms,337ms,271ms,31650us,290ms,869us,23036us,66us,131us MFI: Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP flatline.local 32G 125 99 71443 24 53177 21 317 99 220280 33 255.3 52 Latency 533ms 566ms 1134ms 86565us 357ms 252ms Version 1.96 --Sequential Create-- Random Create flatline.local -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 22347 94 12389 30 16804 100 18729 99 27798 99 5317 99 Latency 33818us 233ms 558us 26581us 75us 12319us 1.96,1.96,flatline.local,1,1347329123,32G,,125,99,71443,24,53177,21,317,99,220280,33,255.3,52,16,22347,94,12389,30,16804,100,18729,99,27798,99,5317,99,533ms,566ms,1134ms,86565us,357ms,252ms,33818us,233ms,558us,26581us,75us,12319us A close race, with some wins for each. Latency on sequential input and deleted files per second appear to be interesting salients. A lot of the other stuff is back and forth and probably not statistically significant (although not much of a sample set :) ). I tried to control as many variables as possible, but obviously it's one controller in one configuration, Your Mileage May Vary. Try upping the queue depth (hw.mfi.max_cmds); this is controller dependent. Cheers, -Garrett It seems hw.mfi.max_cmds is read only. The performance is pretty close to expected with no nvram or bbu on this card and commodity disks from 1.5 years ago, as far as I'm concerned. I'd love better write performance, but it's probably being held back by the single platter in the mirror when it is writing far from its edge. Is there any way to check the interface speed with an mfisyspd? When I added mfip to my kernel config, the pass devices are all reporting 150MB/S which is incorrect. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Clang as default compiler November 4th
On 09/10/12 14:22, Daniel Eischen wrote:
On Mon, 10 Sep 2012, Brooks Davis wrote:
[Please confine your replies to toolch...@freebsd.org to keep the thread
on the most relevant list.]
For the past several years we've been working towards migrating from
GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD
10.0 with Clang as the default compiler on i386 and amd64 platforms. To
this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64
platforms on November 4th.
What does the mean to you?
* When you build world after the default is changed /usr/bin/cc, cpp,
and
c++ will be links to clang.
* This means the initial phase of buildworld and "old style" kernel
compilation will use clang instead of gcc. This is known to work.
* It also means that ports will build with clang by default. A major
of ports work, but a significant number are broken or blocked by
broken ports. For more information see:
http://wiki.freebsd.org/PortsAndClang
What issues remain?
* The gcc->clang transition currently requires setting CC, CXX, and CPP
in addition to WITH_CLANG_IS_CC. I will post a patch to toolchain@
to address this shortly.
I assume this will be done, tested and committed before 2012-11-04
(or whenever the switchover date is).
* Ports compiler selection infrastructure is still under development.
This should be a prerequisite before making the switch, given
that ports will be broken without a work-around for building
them with gcc.
I've been using a somewhat dirty method of doing this by checking the
presence of a file in the port's main directory, e.g. if "basegcc" is
present, build with that, if "clang" is present use it, otherwise
default to gcc47. Obviously that configuration is system specific, but
the fundamental idea is look for a file in the ports directory that
dictates the compiler. Perhaps even add a make ccconfig. It works quite
nicely because you can resume a portmaster spree without having to
suspend and change CC manually, or build all clang ports first etc.
Further csup doesn't touch files it doesn't no about, so updating the
tree (without wiping it out) preserves the fact you'd prefer or need to
build a given port with something else.
There are definitely some ports that have been ignoring libmap.conf,
which tends to require me to build some of their dependencies with base
gcc, but otherwise I've been running this system for a few months and it
works quite well...portmaster can upgrade without user intervention, and
it's quite easy to add cflags logic.
Granted this works for me and is probably not the ideal solution...also
hacked on it to post, so probably typos :)
Something like this in make.conf (with fstack-protector-all for all
ports which works great)
.if !empty(.CURDIR:M/usr/ports/*)
CFLAGS+= -fstack-protector-all
.endif
.if empty(.CURDIR:M/usr/ports/*) && exists(/usr/local/bin/gcc47) &&
!exists(basegcc) && !exists(clang)
# this was occasionally necessary
#LDFLAGS+=-lintl
# custom cflags if desired
#CFLAGS+=-custom cflags for gcc47
#custom cputype if desired
CPUTYPE=amdfam10
CC=gcc47
CPP=cpp47
CXX=g++47
.endif
.if empty(.CURDIR:M/usr/ports/*) && exists(/usr/bin/clang) && exists(clang)
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang-cpp
.endif
NO_WERROR=
WERROR=
.endif
Usage is as simple as "touch basegcc" in the port dir or "touch clang"
etc. to select appropriate compiler
Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mfi driver performance
On 09/10/12 11:35, Andrey Zonov wrote:
On 9/10/12 9:14 PM, matt wrote:
On 09/10/12 05:38, Achim Patzner wrote:
Hi!
We’re testing a new Intel S2600GL-based server with their recommended RAID adapter
("Intel(R) Integrated RAID Module RMS25CB080”) which is identified as
mfi0: port 0x2000-0x20ff mem
0xd0c6-0xd0c63fff,0xd0c0-0xd0c3 irq 34 at device 0.0 on pci5
mfi0: Using MSI
mfi0: Megaraid SAS driver Ver 4.23
mfi0: MaxCmd = 3f0 MaxSgl = 46 state = b75003f0
or
mfi0@pci0:5:0:0:class=0x010400 card=0x35138086 chip=0x005b1000 rev=0x03
hdr=0x00
vendor = 'LSI Logic / Symbios Logic'
device = 'MegaRAID SAS 2208 [Thunderbolt]'
class = mass storage
subclass = RAID
and seems to be doing quite well.
As long as it isn’t used…
When the system is getting a bit more IO load it is getting close to unusable
as soon as there are a few writes (independent of configuration, it is even
sucking as a glorified S-ATA controller). Equipping it with an older
(unsupported) controller like an SRCSASRB
(mfi0@pci0:10:0:0: class=0x010400 card=0x100a8086 chip=0x00601000
rev=0x04 hdr=0x00
vendor = 'LSI Logic / Symbios Logic'
device = 'MegaRAID SAS 1078'
class = mass storage
subclass = RAID) solves the problem but won’t make Intel’s support happy.
Has anybody similar experiences with the mfi driver? Any good ideas besides
running an unsupported configuration?
Achim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
I just set up an IBM m1015 (aka LSI 9240lite aka Drake Skinny) with mfi.
Performance was excellent for mfisyspd volumes, as I compared using the
same hardware but with firmware (2108it.bin) that attaches under mps.
Bonnie++ results on random disks were very close if not identical
between mfi and mps. ZFS performance was also identical between a
mfisysd JBOD volume and a mps "da" raw volume. It was also quite clear
mfisyspd volumes are true sector-for-sector pass through devices.
However, I could not get smartctl to see an mfisyspd volume (it claimed
there was no such file...?) and so I flashed the controller back to mps
for now. A shame, because I really like the mfi driver better, and
mfiutil worked great (even to flash firmware updates).
Have you got /dev/pass* when the controller run under mfi driver? If
so, try to run smartctl on them. If not, add 'device mfip' in your
kernel config file.
mfip was necessary, and allowed smartctl to work with '-d sat'
bonnie++ comparison. Run with no options immediately after system boot.
In both cases the same disks are used, two Seagate Barracuda 1TB 3G/S
(twin platter) and a Barracuda 500G 3G/s (single platter) in a zfs
triple mirror that the system was booted from. All are 7200 RPM drives
with 32mb cache, and mediocre performance compared to my hitachi 7k3000s
or the 15k sas cheetahs at work etc. Firmwares were the latest 2108it vs
the latest imr_fw that work on the 9240/9220/m1015/drake skinny. I wish
I had some 6g ssds to try!
MPS:
Version 1.96 --Sequential Output-- --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
flatline.local 32G 122 99 71588 24 53293 20 284 90 222157 33 252.6 49
Latency 542ms 356ms 914ms 991ms 337ms 271ms
Version 1.96 --Sequential Create-- Random Create
flatline.local -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 22197 93 9367 27 16821 99 23555 99 + +++ 23717 99
Latency 31650us 290ms 869us 23036us 66us 131us
1.96,1.96,flatline.local,1,1347322810,32G,,122,99,71588,24,53293,20,284,90,222157,33,252.6,49,16,22197,93,9367,27,16821,99,23555,99,+,+++,23717,99,542ms,356ms,914ms,991ms,337ms,271ms,31650us,290ms,869us,23036us,66us,131us
MFI:
Version 1.96 --Sequential Output-- --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
flatline.local 32G 125 99 71443 24 53177 21 317 99 220280 33 255.3 52
Latency 533ms 566ms 1134ms 86565us 357ms 252ms
Version 1.96 --Sequential Create-- Random Create
flatline.local -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 22347 94 12389 30 16804 100 18729 99 27798 99 5317 99
Latency 33818us 233ms 558us 26581us 75us 12319us
1.96,1.96,flatline.local,1,1347329123,32G,,125,99,71443,24,53177,21,317,99,220280,33,255.3,52,16,22347,94,12389,30,16804,100,18729,99,27798,99,5317,99,533ms,566ms,1134ms,
Re: mfi driver performance
On 09/10/12 11:35, Andrey Zonov wrote:
> On 9/10/12 9:14 PM, matt wrote:
>> On 09/10/12 05:38, Achim Patzner wrote:
>>> Hi!
>>>
>>> We’re testing a new Intel S2600GL-based server with their recommended RAID
>>> adapter ("Intel(R) Integrated RAID Module RMS25CB080”) which is identified
>>> as
>>>
>>> mfi0: port 0x2000-0x20ff mem
>>> 0xd0c6-0xd0c63fff,0xd0c0-0xd0c3 irq 34 at device 0.0 on pci5
>>> mfi0: Using MSI
>>> mfi0: Megaraid SAS driver Ver 4.23
>>> mfi0: MaxCmd = 3f0 MaxSgl = 46 state = b75003f0
>>>
>>> or
>>>
>>> mfi0@pci0:5:0:0:class=0x010400 card=0x35138086 chip=0x005b1000
>>> rev=0x03 hdr=0x00
>>> vendor = 'LSI Logic / Symbios Logic'
>>> device = 'MegaRAID SAS 2208 [Thunderbolt]'
>>> class = mass storage
>>> subclass = RAID
>>>
>>> and seems to be doing quite well.
>>>
>>> As long as it isn’t used…
>>>
>>> When the system is getting a bit more IO load it is getting close to
>>> unusable as soon as there are a few writes (independent of configuration,
>>> it is even sucking as a glorified S-ATA controller). Equipping it with an
>>> older (unsupported) controller like an SRCSASRB
>>> (mfi0@pci0:10:0:0: class=0x010400 card=0x100a8086 chip=0x00601000
>>> rev=0x04 hdr=0x00
>>> vendor = 'LSI Logic / Symbios Logic'
>>> device = 'MegaRAID SAS 1078'
>>> class = mass storage
>>> subclass = RAID) solves the problem but won’t make Intel’s support
>>> happy.
>>>
>>> Has anybody similar experiences with the mfi driver? Any good ideas besides
>>> running an unsupported configuration?
>>>
>>>
>>> Achim
>>>
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>> I just set up an IBM m1015 (aka LSI 9240lite aka Drake Skinny) with mfi.
>> Performance was excellent for mfisyspd volumes, as I compared using the
>> same hardware but with firmware (2108it.bin) that attaches under mps.
>> Bonnie++ results on random disks were very close if not identical
>> between mfi and mps. ZFS performance was also identical between a
>> mfisysd JBOD volume and a mps "da" raw volume. It was also quite clear
>> mfisyspd volumes are true sector-for-sector pass through devices.
>>
>> However, I could not get smartctl to see an mfisyspd volume (it claimed
>> there was no such file...?) and so I flashed the controller back to mps
>> for now. A shame, because I really like the mfi driver better, and
>> mfiutil worked great (even to flash firmware updates).
>>
> Have you got /dev/pass* when the controller run under mfi driver? If
> so, try to run smartctl on them. If not, add 'device mfip' in your
> kernel config file.
>
I will try mfi firmware again tonight. With ZFS it seemed happy whether
the pool was /dev/da* or /dev/mfisyspd*. Is the mfisyspd device name set
in stone? It's quite long!
Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mfi driver performance
On 09/10/12 05:38, Achim Patzner wrote:
> Hi!
>
> We’re testing a new Intel S2600GL-based server with their recommended RAID
> adapter ("Intel(R) Integrated RAID Module RMS25CB080”) which is identified as
>
> mfi0: port 0x2000-0x20ff mem
> 0xd0c6-0xd0c63fff,0xd0c0-0xd0c3 irq 34 at device 0.0 on pci5
> mfi0: Using MSI
> mfi0: Megaraid SAS driver Ver 4.23
> mfi0: MaxCmd = 3f0 MaxSgl = 46 state = b75003f0
>
> or
>
> mfi0@pci0:5:0:0:class=0x010400 card=0x35138086 chip=0x005b1000
> rev=0x03 hdr=0x00
> vendor = 'LSI Logic / Symbios Logic'
> device = 'MegaRAID SAS 2208 [Thunderbolt]'
> class = mass storage
> subclass = RAID
>
> and seems to be doing quite well.
>
> As long as it isn’t used…
>
> When the system is getting a bit more IO load it is getting close to unusable
> as soon as there are a few writes (independent of configuration, it is even
> sucking as a glorified S-ATA controller). Equipping it with an older
> (unsupported) controller like an SRCSASRB
> (mfi0@pci0:10:0:0: class=0x010400 card=0x100a8086 chip=0x00601000
> rev=0x04 hdr=0x00
> vendor = 'LSI Logic / Symbios Logic'
> device = 'MegaRAID SAS 1078'
> class = mass storage
> subclass = RAID) solves the problem but won’t make Intel’s support
> happy.
>
> Has anybody similar experiences with the mfi driver? Any good ideas besides
> running an unsupported configuration?
>
>
> Achim
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
I just set up an IBM m1015 (aka LSI 9240lite aka Drake Skinny) with mfi.
Performance was excellent for mfisyspd volumes, as I compared using the
same hardware but with firmware (2108it.bin) that attaches under mps.
Bonnie++ results on random disks were very close if not identical
between mfi and mps. ZFS performance was also identical between a
mfisysd JBOD volume and a mps "da" raw volume. It was also quite clear
mfisyspd volumes are true sector-for-sector pass through devices.
However, I could not get smartctl to see an mfisyspd volume (it claimed
there was no such file...?) and so I flashed the controller back to mps
for now. A shame, because I really like the mfi driver better, and
mfiutil worked great (even to flash firmware updates).
Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Speaking of ship blockers for 9....
On 08/07/12 11:43, Garrett Cooper wrote: On Aug 7, 2012, at 11:17 AM, Ian FREISLICH wrote: Garrett Cooper Is this is in 9.1 -PRERELEASE, -RELEASE (or whatever the official label is...)? If so, it seems like this would be a ship blocker. I have a problem that's been getting progressively worse as the source progresses. So much so that it's had me searching all the way from 8.0-RELEASE to 10-CURRENT without luck on both amd64 and i386. pf(4) erroneously mismatches state and then blocks an active flow. It seems that 8.X does so silently and 9 to -CURRENT do so verbosely. Whether silent or loud, the effect on traffic makes it impracticle to use FreeBSD+PF for a firewall in any setting (my use is home, small office, large office and moderately large datacenter core router). It appears that this has actually been a forever problem that just being tickled more now. Here's from my home firewall: Status: Enabled for 7 days 02:57:58 Debug: Urgent State Table Total Rate current entries 1653 searches45792251 74.4/s inserts 4283750.7/s removals 4267220.7/s ... state-mismatch 15860.0/s Here's from a moderately busy firewall: Status: Enabled for 0 days 21:40:44 Debug: Urgent State Table Total Rate current entries 122395 searches 442864168556745.4/s inserts202644593 2596.5/s removals 202522198 2595.0/s ... state-mismatch2777673.6/s That's 277767 flows terminated in the last almost 22 hours due to this pf bug. (!!!) 9.1-PRERELEASE logs (as does -CURRENT): Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:60985, a1: 192.41.162.30:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:52995, a1: 41.154.2.100:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:60095, a1: 206.223.136.200:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:50463, a1: 206.223.136.200:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:56748, a1: 192.41.162.30:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:60793, a1: 192.41.162.30:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Filed a PR yet with packet captures? Thanks, -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" I was having this problem on one machine but not another (different pf.confs). Are you using synproxy state or modulate state? Feel OK posting a basic pf.conf that experiences the issue? I feel like there was something with either scrub or synproxy I had to remove to make the hurting stop. Obviously that means something is probably borked, and I will share in the no-pr shame. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make installworld fails
On 05/03/12 20:49, Tim Kientzle wrote: On May 3, 2012, at 1:34 PM, AN wrote: Thu May 3 16:25:27 EDT 2012 FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #13 r234872: Tue May 1 13:09:55 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 # svn up Updated to revision 234981 I did build world/kernel, after booting into single user mode and trying make installworld I get the following error: /usr/src/Makefile Line:219 check date and time I have seen this failure before, previously I was able to open the make file and comment out the date and time check, but this time the file seems corrupted, I am not able to open the file in vi. What causes this check to fail? Is there any way to detect this possibility before rebboting to single user? Try looking very critically at the system date and time: $ date This check is comparing the system time to the timestamps of the files on disks to try to detect whether your system clock is correct. Since the 'make' program relies on comparing timestamps, you can get very strange results if your system clock is not consistent. You can use the date utility to set the system clock to the approximately correct time (it doesn't need to be very exact). If you have networking, you can use "ntpdate pool.ntp.org" to set the clock from the network. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Did you run "adjkerntz -i" before mounting disks in single user? Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: X220 and all.14.5.patch
On 05/03/12 22:12, Artem Tuchinsky wrote: it's russian, not greek :) and this is my posts. Try to remove /usr/src and checkout clean source before applying patch, it helped me. And check FAQ, paragraphs 7 and 8 - http://wiki.freebsd.org/Intel_GPU sorry for my bad english 2012/5/4 Erich Dollansky: Hi, I just applied this patch and tried to compile getting this error: /usr/src/sys/dev/drm/i915_mem.c:216: warning: no previous prototype for 'i915_mem_release' [-Wmissing-prototypes] /usr/src/sys/dev/drm/i915_mem.c:246: warning: no previous prototype for 'i915_mem_takedown' [-Wmissing-prototypes] /usr/src/sys/dev/drm/i915_mem.c: In function 'get_heap': /usr/src/sys/dev/drm/i915_mem.c:266: error: 'drm_i915_private_t' has no member named 'agp_heap' /usr/src/sys/dev/drm/i915_mem.c: At top level: /usr/src/sys/dev/drm/i915_mem.c:276: warning: no previous prototype for 'i915_mem_alloc' [-Wmissing-prototypes] /usr/src/sys/dev/drm/i915_mem.c:314: warning: no previous prototype for 'i915_mem_free' [-Wmissing-prototypes] /usr/src/sys/dev/drm/i915_mem.c:342: warning: no previous prototype for 'i915_mem_init_heap' [-Wmissing-prototypes] /usr/src/sys/dev/drm/i915_mem.c:366: warning: no previous prototype for 'i915_mem_destroy_heap' [-Wmissing-prototypes] *** [i915_mem.o] Error code 1 I found this: http://pastebin.com/ySPxJNUF and http://www.linux.org.ru/news/bsd/7658822/page6 which is a bit like Greek for me. It would be easy to fix the prototype errors. Does anybody know what agp_heap is all about? The machine: FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Wed May 2 06:59:48 WIT 2012 er...@x220.ovitrap.com:/usr/obj/usr/src/sys/X220 amd64 Erich Is it possibly that the patch got applied twice? I had some errors a while back that were resulting from an inconsistent mixture of pre-patch, post-patch and double patched files...I deleted /usr/src and followed the patching instructions after doing a fresh csup. There is also (or was) some sed command that fixes some issues in the files that must not be skipped due to cvs tags. Don't forget to rm /usr/obj. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On 05/03/12 11:18, Adrian Chadd wrote: Hi, First off, let me say "thankyou" to you, ray@ and all the people who have chipped away at this little problem. I look very forward to having rt2xxx 802.11n support, as do many users on the forums. :) I haven't yet done a pass or two to see what the state of the locking/concurrency handling is. Don't let that stop you from committing it though, I'm sure we can find/fix whatever issues creep up post-commit. Thanks again! Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Thanks Bernhard! I'm sure there are many people with this chipset that are going to be very happy. It's good that we have something homegrown as well. I'll try to test it this weekend on my rt3090. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x220 notes
On 04/30/12 04:54, Ganael LAPLANCHE wrote: On Mon, 19 Mar 2012 12:03:13 -0700, matt wrote Hi Matt, I'll have to try again without the patch to see if it's Xorg/KMS or FreeBSD base that has changed. FYI, I've just tried suspend/resume with all.14.5.patch and sources from 2012/04/28, but I still get a black screen on resume :/ Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac, http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Try setting hw.pci.do_power_resume=0 and hw.pci.do_power_suspend=0 in sysctl.conf If that doesn't work for you try setting each to one separately, and together if all fails. Also try setting resume beep and see whether it's getting that far (debug.acpi.resume_beep=1). When mine failed I would get a beep, but it would hang during the beep, making a warbling/modem type sound. The pci options plus a custom kernel conf seemed to fix it, but I am not near that machine right now...I think the pci options were all that were needed, but it may have been the kernel conf as well. I haven't tried the very latest current either, as I filled up my 4g USB...I need to wipe it out and start again, it's not a good environment for buildworld. Sorry for the late response! Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Status on X220
On 04/19/12 17:01, Erich Dollansky wrote: Hi, there are so many different news about the X220 here that it is not so clear to me whether an install will result in a usable system. If everything works fine, there should be one for me tomorrow ready to get FreeBSD. My plan is to start with a plain 9.0 installation and upgrade it then to 10.0 before installing any ports. All I saw from the list is that 10.0 is the best option to get a usable system. Is there a better option? Erich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" That's what I've been using. I'm about ready to say goodbye to gentoo permanently on mine, although it's a work machine so I'm taking my time. * *What works: suspend/resume (must use Xorg KMS to have display on resume), needs sysctl twiddling for PCI resume/suspend backlight (via hack for now) keyboard (needs sed -e 's/IBM0068/LEN0068/g' on acpi_ibm.c, or nicer patch as circulated in the past) trackpad (could be better, no scrolling yet...psm doesn't seem to attach synaptics properly) ethernet intel wireless (no rt8192) graphics (via Konstantin's KMS work! thanks!) speaker.ko! Fan control works, but stops displaying fan speed sometimes (see hack for acpi_ibm.c) Expresscard Turbocore Powerd/Cpufreq VESA modes for syscons (1024x768 looks fine) * *What is unknown (to me): Card reader Fingerprint for PAM (works if you already registered it in Windows for boot) Sound (just haven't tried it probably ok it's HDA Connexant) DPMS WWAN What doesn't work: Standard consoles after X is started with KMS (this is true for all intel KMS) Display after resume (unless you use KMS/Xorg) Power saving...I'm still using more power than I'd like with KMS loaded for now Random miniPCIe cards in second slot...this is BIOS problem I assume Scrolling with psm and/or xf86-input-synaptics I'm probably forgetting some stuff that doens't work and some stuff that does (especially if obvious) Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel builds, but crashes at boot (amd64, Revision: 234306)
On 04/16/12 14:49, Conrad J. Sabatier wrote: On Tue, Apr 17, 2012 at 03:53:27AM +0200, Edward Tomasz Napieraa wrote: Wiadomo�� napisana przez Rainer Hurling w dniu 16 kwi 2012, o godz. 19:58: On 16.04.2012 19:31 (UTC+1), Konstantin Belousov wrote: On Mon, Apr 16, 2012 at 06:15:32PM +0200, Rainer Hurling wrote: I just updated my system to r234342, only downgraded /usr/src/sys/cam/scsi/scsi_da.c to r233746, and now the system is booting again. So obviously there is something wrong with the newest patch to scsi_da.c. It is too broad, try to revert exactly one patch and see whether it works. Sorry for my bad english. I wanted to say, that I only reverted exactly one patch (file scsi_da.c from 234177 back to 233746 manually). The rest is up to r234342. Could you try the patch below? Index: sys/cam/scsi/scsi_da.c === --- sys/cam/scsi/scsi_da.c (revision 234314) +++ sys/cam/scsi/scsi_da.c (working copy) @@ -938,7 +938,9 @@ daopen(struct disk *dp) if (error != 0) xpt_print(periph->path, "unable to retrieve capacity data"); - if (periph->flags& CAM_PERIPH_INVALID) + if (periph->flags& CAM_PERIPH_INVALID || + softc->disk->d_sectorsize == 0 || + softc->disk->d_mediasize == 0) error = ENXIO; if (error == 0&& (softc->flags& DA_FLAG_PACK_REMOVABLE) != 0&& This patch fixed the problem for me. Thank you! It's fixed here too where problem device was a front-panel with a USBest UT330 chip...stupid thing presents *every* card slot as a LUN whether used or not, da0-da4. Thanks Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver available
On Apr 4, 2012 10:02 PM, "Matt Thyer" wrote: > > On 3 April 2012 23:12, Gary Palmer wrote: >> >> I think you should contact either SuperMicro or LSI and open a support >> case as it looks like there could be a problem with either the controller >> or the firmware when presented with mixed speed devices. Either way I think >> this needs to be escalated to the manufacturer. >> >> Regards, >> >> Gary > > > I'm now having no problems since moving the SATA 3 drive to the on board Intel controller. > I'll try to report this to Super Micro & LSI. I spoke too soon. The problem of the SATA 3 drive being FAULTED in the raidz2 pool has indeed been solved by moving that drive from the Super micro (SAS 6G) controller to the onboard Intel (SATA 2) controller. However, the 157k interrupts per second problem remained (its not apparent immediately after boot). However, even this problem has been resolved by upgrading from 8-STABLE to 9-STABLE (as I reported in the freebsd-stable list). So I'm happy now but still no closer to understanding the cause. I'm guessing that it was either USB related or something to do with the on CPU package Intel graphics of the Core i3 530 CPU. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel builds, but crashes at boot (amd64, Revision: 234306)
rnel: ugen3.7: at usbus3 > Apr 12 15:32:33 telesto kernel: ums0: 0/0, rev 2.00/56.01, addr 7> on usbus3 > Apr 12 15:32:33 telesto kernel: ums0: 8 buttons and [XYZT] coordinates ID=0 > Apr 12 15:32:33 telesto kernel: Trying to mount root from > ufs:/dev/gpt/root [rw]... > Apr 12 15:32:33 telesto kernel: nvidia0: on vgapci0 > Apr 12 15:32:33 telesto kernel: vgapci0: child nvidia0 requested > pci_enable_io > Apr 12 15:32:33 telesto kernel: vgapci0: child nvidia0 requested > pci_enable_io > Apr 12 15:32:33 telesto kernel: vboxdrv: fAsync=0 offMin=0x2d8 offMax=0x603c > Apr 12 15:32:33 telesto kernel: module_register: module ng_ether already > exists! > Apr 12 15:32:33 telesto kernel: Module ng_ether failed to register: 17 > Disconnect "Generic Ultra HS-SD/MMC" device which is presenting da0...same problem here. System will boot if da0 is either not present or has media (I think). In my case it was a different card reader that had no cards in it, which seem to be similar to your case. My guess is that this problem is related to recent changes in da, but I couldn't pinpoint in the diff what's going wrong in a quick look. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver available
On 3 April 2012 23:12, Gary Palmer wrote: > On Tue, Apr 03, 2012 at 10:52:25PM +0930, Matt Thyer wrote: > > I forgot to mention that I'm still having problems after this phase 11 > > firmware upgrade with the 6 Gbps drive being kicked out of the raidz2 > with > > write errors (even though a SMART full surface test says the drive is > OK). > > > > This leads me to think that both the old and new drivers have a problem > > with the 6 Gbps WD20EARX-00P AB51 drive. > > > > Now that the 6 Gbps drive is on the Intel SATA controller things seem OK > > but it's a bit early to tell. > > > > Stay tuned! > > I think you should contact either SuperMicro or LSI and open a support > case as it looks like there could be a problem with either the controller > or the firmware when presented with mixed speed devices. Either way I > think > this needs to be escalated to the manufacturer. > > Regards, > > Gary > I'm now having no problems since moving the SATA 3 drive to the on board Intel controller. I'll try to report this to Super Micro & LSI. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver available
On Mar 27, 2012 11:50 PM, "Matt Thyer" wrote: > > I was having problems with the WD20EARX-00P AB51 drive being faulted by ZFS until I updated the firmware to 11 and now ZFS is happy (I've also done a full extended drive SMART test and the drive is fine). > I forgot to mention that I'm still having problems after this phase 11 firmware upgrade with the 6 Gbps drive being kicked out of the raidz2 with write errors (even though a SMART full surface test says the drive is OK). This leads me to think that both the old and new drivers have a problem with the 6 Gbps WD20EARX-00P AB51 drive. Now that the 6 Gbps drive is on the Intel SATA controller things seem OK but it's a bit early to tell. Stay tuned! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver available
On 28 March 2012 03:51, Kenneth D. Merry wrote: > On Tue, Mar 27, 2012 at 23:50:31 +1030, Matt Thyer wrote: > > On 26 March 2012 23:55, Gary Palmer wrote: > > > > > On Mon, Mar 26, 2012 at 08:05:59PM +1030, Matt Thyer wrote: > > > > On Mar 26, 2012 3:43 AM, "Garrett Cooper" > wrote: > > > > > > > > > > On Sun, Mar 25, 2012 at 5:16 AM, Matt Thyer > > > wrote: > > > > > > Has this driver been MFC to 8-STABLE yet ? > > > > > > > > > > > > I'm asking because I updated my NAS on the 4th of March from > 8-STABLE > > > > > > r225723 to r232477 and am now seeing 157,000 interrupts per > second on > > > > irq > > > > > > 16 where my SuperMicro AOC-USAS2-L8i resides (this card uses the > LSI > > > > > > SAS2008 chip). > > > > > > > [snip] > > > > > > > > After encountering this problem I updated my firmware from phase 7 to > > > phase > > > > 11 but this did not fix things. > > > > > > > > My question is: "Is the LSI driver even in 8-STABLE yet?". > > > > > > > > If not I'll upgrade to 9-STABLE to get the new driver. > > > > > > > > If it is, then I want to downgrade to just before it came in to see > if > > > this > > > > high interrupt rate problem is fixed. > > > > > > I'm no export in svn, however: > > > > > > http://svnweb.freebsd.org/base?view=revision&revision=230922 > > > > > > would appear to suggest that the new driver is in 8-Stable > > > > > > Gary > > > > > > > It's painful to take this system back to r230921 due to intolerance for > > downtime from it's users so I'd like to investigate the cause of the > > problem and try patches/sysctls/whatever first. > > > > The drives I'm using are 7 x WDC WD20EARS-00M (3 are AB50, 4 are AB51) > and > > 1 x WD20EARX-00P AB51. > > The WD20EARX-00P AB51 is a SATA 3 (6 Gbps) drive but the others are all > > SATA 2 (3 Gbps). > > > > I know the driver doesn't like mixed speeds in IR mode but I'm flashed > with > > IT firmware as ZFS is doing my RAID (raidz2). > > > > I was having problems with the WD20EARX-00P AB51 drive being faulted by > ZFS > > until I updated the firmware to 11 and now ZFS is happy (I've also done a > > full extended drive SMART test and the drive is fine). > > > > So what do people suggest (before reversion to r230921) ? > > If you're going to prove that it's the new LSI driver, you will probably > have to go back to the old driver. > > You don't have to back out your entire tree, you can just back out the > driver itself if you have an SVN tree. You can go into sys/dev/mps and do: > > svn update -r 230714 > > And then edit sys/conf/files and comment out these three lines: > > dev/mps/mps_config.coptional mps > dev/mps/mps_mapping.c optional mps > dev/mps/mps_sas_lsi.c optional mps > > Then you should be able to rebuild your kernel with the old driver and see > if the problem occurs again. > > Ken > -- > Kenneth Merry > k...@freebsd.org > This didn't work for me so I removed my /usr/src and checked out 8-STABLE at revision 230921 (svn checkout -r 230921 http://svn.freebsd.org/base/stable/8 /usr/src). I've built world, kernel etc and installed it using GENERIC kernel done my mergemaster, delete old, delete old-libs and I still have the problem. I'm wondering if it's due to the single 6 Gb drive in my raidz2 (the other 7 are 3 Gb). I've heard that the new driver doesn't like mixed speeds in a raid set when using -IR firmware but I wouldn't expect an issue with ZFS with -IT firmware. It seems that there may be a general incompatibility with both the old and new drivers and the Western Digital WD20EARX-00P 6 Gbps drive. Unfortunately I cannot get the old 3 Gb drive anymore. I'll try moving the WD20EARX-00P drive to the on board SATA ports next. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x220 notes
On 04/02/12 18:42, Любомир Григоров wrote: Interesting. So brightness value "is" changed, but not acted upon then when using the hotkeys? Yes, value changes with no effect when hotkeys are pressed...I am not sure why there is no effect. I could care less about suspend/resume as I don't really use it. Brightness and the fan (thanks for reminding me about the corruption) are what is killing my use. I have a SSD so even though boot isn't 5sec on FreeBSD, I can still live with waiting 10 extra seconds. Having brightness eat up my battery time and fan spinning like crazy is a problem, though. The fan is horribly noisy on this model. However, it will quiet down a bit on its own when temperature goes down...enabling C states and running "powerd -a adaptive -b adaptive" should help a lot...I don't recommend manual fan control as at least my i7 already runs way too hot in linux and win7 (for the 10 minutes I had it :) ). Run Lenovo bios updates as well, many complaints about post tsunami fans from Lenovo China instead of Lenovo Japan... What do you mean by the fan controls still work in manual and automatic? Does that mean every time brightness is changed, fan speed needs to be set to auto again for it to work properly? Only the fan speed value shows as 0x or something, however it can still be set 1-7 or back to automatic as usual Also, I assume the dimming from inactivity will not work until EC is responsible for brightness change? I'm not sure...that might be accomplished with dpms.ko, haven't tried ... and then I have the issue with Konstantin's latest patch for STABLE where after I exit X, I have no monitor or keyboard control. I guess I can bypass this with a login manager. http://wiki.freebsd.org/Intel_GPU On Konstantin's page he mentions this...it's a known issue Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x220 notes
On 04/01/12 22:49, Kevin Oberman wrote: 2012/4/1 Любомир Григоров: Well I can't do the brightness switching. acpi_call port is installed, but: # kldload acpi_call kldload: can't load acpi_call: No such file or directory # acpi_call -p '\VBRC' -i 14 ioctl: Device not configured At least closing the lid turns off the monitor (not going to sleep), which is OK to conserve energy when not using. I would like to be able to change brightness, however. And have dimming. A minor problem, with the KMS Intel patch, when I log out of X (startx or xfce4), screen goes black. I don't know if this is acpi related. I typed reboot, and nothing happened. Using all.13.7-stable-9.patch with 9.0-STABLE. # cd /usr/ports/sysutils/acpi_call&& make install clean # rehash # kld_load acpi_call # acpi_call -p '\VBRC' -i 5 Exactly...I'd like to add it does require appropriate kernel sources, something I discovered as I'm currently testing off a 4gb USB...appropriately to current discussions, /usr/obj /usr/ports/distfiles /tmp /var/run are all tmpfs :) (we'll see how that goes too!). Some general followup/status of brightness: The hotkeys are working just fine out of the box, at least as far as they seem to adjust the brightness value seen by acpi_video, however as we know this doesn't actually seem to do much. There are a couple of branches in the ACPI code when brightness is called, one of which checks for integrated or discrete graphics (why I do not know as discrete is not an option). If \VIGD returns 1 (which I think means graphics are integrated) it talks to the \_SB.PCI0.LPC.EC.BRNS method, which doesn't seem to do anything for us. If \VIGD returns 0 (which I think would mean discrete graphics if available) it calls \VBRC The above method simply bypasses the VIGD switch and calls \VBRC directly. There are other ACPI methods which seem to be related, but I have yet to figure out what they mean...VBTC is one, and some _Q(X)(X) methods also seem to talk to the EC about the panel and brightness etc. It seems like we need to find how to make the EC be in charge of brightness instead of whatever VBRC is doing (it's an SMI call). I think brightness might just work fine...another note is the fact that acpi_video sees lcd0 as inactive...not sure why. Regarding acpi_ibm, it appears that it is also talking to the EC, which is why brightness cannot work there. Although for some reason, probably an alignment or address change, the fan speed appears corrupt after setting brightness via acpi_ibm, the fan controls still work fine in both manual and automatic as far as I can tell. It seems like if we can determine why the EC does not care for brightness settings, or isn't in charge of brightness, that we would be a small patch away from fixing acpi_ibm for this model. HOWEVER, it appears resume is now toast on CURRENT, since at least a few months, with or without Konstantin's patches. I'm not sure what's hanging, although setting suspend_beep=1 creates a horrible sound during the failing resume, which may indicate it's something fairly early in the resume, or even concurrent with "beeping". Even bounce does not work, and debugging is complicated by the lack of display. If anyone has anyone ideas for fixing resume on CURRENT, we'd be awful close to having a pretty damn nice laptop for FreeBSD. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Using TMPFS for /tmp and /var/run?
On 03/30/12 11:15, Steve Kargl wrote: > On Fri, Mar 30, 2012 at 05:56:06PM +, Chris Rees wrote: >> On 30 March 2012 17:31, C. P. Ghost wrote: >>> On Fri, Mar 30, 2012 at 3:18 PM, wrote: >>>>>> However, if you always want to use tmpfs instead of stable storage, >>>>> please do not. Some people expect /tmp to be persistent. This is why >>>>> /etc/defaults/rc.conf has clear_tmp_enable="NO". Changing this would >>>>> break >>>>> the POLA. >>>>> This is a mistake. >>>>> >>>>> The default should be clear_tmp_enable="YES" >>>>> if only to uncover those broken configurations that expect /tmp to be >>>>> persistent. >>>> If you want to break POLA and make a lot of people angry, sure. >>>> Otherwise no. >>> I couldn't agree more. Not clearing /tmp on reboot has been >>> the norm for way too long and it is too late to change now. >>> It's not just POLA, it also involves deleting data of unaware >>> users, and that should be avoided. >>> >>> Anyone willing to change policy w.r.t. /tmp can do so on their >>> own machines. Nothing is preventing them from doing so. >>> But by changing defaults, one should err on the side of >>> caution and remain conservative, IMHO. > Well stated. > >> >From man hier: >> >> /tmp/ temporary files that are not guaranteed to persist across >> system reboots > There is also a difference between "not guaranteed to persist" > and knowingly blowing the files away by explictly clearing > /tmp. > > PS: > How many users of FreeBSD know that hier(7) exists? > How many new users even know about man pages? > man hier is a unix standard. a new user will eventually find man pages if they're meant to, just as small turtles will eventually find the sea... In general you may receive some advantages by not blowing away /tmp such as better performance in programs that cache there, but my understanding (think historically in context of hier) is that *users* should not expect the *admin* to not blow away /tmp for space on a multiuser system. It might be there tomorrow, but it might not. Many larger multiuser systems had/have such folders, as many users = many crap files that some admin or script needs to clear to preserve storage for things that actually need to be stored. In some cases, the script would only clear it on Fridays in the middle of night, so temporary files might persist from say 1 week to a few hours..."you were warned". Dunno, but tmpfs + unionfs for the ports tree is where it would really be awesome! Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Using TMPFS for /tmp and /var/run?
On Mar 30, 2012 6:22 AM, "Eric van Gyzen" wrote: > However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable="NO". Changing this would break the POLA. > This is a mistake. The default should be clear_tmp_enable="YES" if only to uncover those broken configurations that expect /tmp to be persistent. I was going to say "At least on -CURRENT" but in reality it should be the default on -RELEASE too when it's clearly a bug to expect /tmp to be persistent. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Awkward booting issue
On 03/28/12 06:40, Mark wrote: >> (...snip...) >>> Disable everything you can to reduce the attachable devices and see >>> if it will still boot. This will help identify which device if any >>> is causing the hang >> Yes, I considered this. But even after having disabled everything >> that's possible in the bios, the boot issue persists... >> > Any more suggestions? I'd really like to get this solved, please... > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" If you have access to another FreeBSD machine, you could try compiling a minimal kernel (remove drivers that are unneeded, but also those that attach but are unnecessary) and booting from that kernel instead. Can you type characters onto the terminal after the boot hangs? If no, does capslocks change keyboard LEDs? Does 9-RELEASE boot? Or does no FreeBSD boot? Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Awkward booting issue
On 03/27/12 09:22, Mark wrote: > 03:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet > Controller > 04:02.0 VGA compatible controller: XGI Technology Inc. (eXtreme Graphics > Innovation) Z7/Z9 (XG20 core) > 04:03.0 IDE interface: Integrated Technology Express, Inc. IT8213 IDE > Controller Can you disable any of these in BIOS? Sometimes last message isn't the cause of the hang, I was having igb issues a while ago that "ended" with ada, but were caused by igb hanging shortly after attach. Disable everything you can to reduce the attachable devices and see if it will still boot. This will help identify which device if any is causing the hang Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver available
On 26 March 2012 23:55, Gary Palmer wrote: > On Mon, Mar 26, 2012 at 08:05:59PM +1030, Matt Thyer wrote: > > On Mar 26, 2012 3:43 AM, "Garrett Cooper" wrote: > > > > > > On Sun, Mar 25, 2012 at 5:16 AM, Matt Thyer > wrote: > > > > Has this driver been MFC to 8-STABLE yet ? > > > > > > > > I'm asking because I updated my NAS on the 4th of March from 8-STABLE > > > > r225723 to r232477 and am now seeing 157,000 interrupts per second on > > irq > > > > 16 where my SuperMicro AOC-USAS2-L8i resides (this card uses the LSI > > > > SAS2008 chip). > [snip] > > After encountering this problem I updated my firmware from phase 7 to > phase > > 11 but this did not fix things. > > > > My question is: "Is the LSI driver even in 8-STABLE yet?". > > > > If not I'll upgrade to 9-STABLE to get the new driver. > > > > If it is, then I want to downgrade to just before it came in to see if > this > > high interrupt rate problem is fixed. > > I'm no export in svn, however: > > http://svnweb.freebsd.org/base?view=revision&revision=230922 > > would appear to suggest that the new driver is in 8-Stable > > Gary > It's painful to take this system back to r230921 due to intolerance for downtime from it's users so I'd like to investigate the cause of the problem and try patches/sysctls/whatever first. The drives I'm using are 7 x WDC WD20EARS-00M (3 are AB50, 4 are AB51) and 1 x WD20EARX-00P AB51. The WD20EARX-00P AB51 is a SATA 3 (6 Gbps) drive but the others are all SATA 2 (3 Gbps). I know the driver doesn't like mixed speeds in IR mode but I'm flashed with IT firmware as ZFS is doing my RAID (raidz2). I was having problems with the WD20EARX-00P AB51 drive being faulted by ZFS until I updated the firmware to 11 and now ZFS is happy (I've also done a full extended drive SMART test and the drive is fine). So what do people suggest (before reversion to r230921) ? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver available
On Mar 26, 2012 3:43 AM, "Garrett Cooper" wrote: > > On Sun, Mar 25, 2012 at 5:16 AM, Matt Thyer wrote: > > On 21 January 2012 09:58, Kenneth D. Merry wrote: > > > >> On Fri, Jan 20, 2012 at 23:14:20 -, Steven Hartland wrote: > >> > - Original Message - > >> > From: "Kenneth D. Merry" > >> > To: ; > >> > Sent: Friday, January 20, 2012 8:44 PM > >> > Subject: LSI supported mps(4) driver available > >> > > >> > > >> > > > >> > >The LSI-supported version of the mps(4) driver that supports their 6Gb > >> SAS > >> > >HBAs as well as WarpDrive controllers, is available here: > >> > > > >> > >http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt > >> > > > >> > >I plan to check it in to head next week, and then MFC it into stable/9 a > >> > >week after that most likely. > >> > > >> > Great to see this being done, thanks to everyone! Be even better to see > >> > this MFC'ed to 8.x as well if all goes well. Do you think this will > >> > possible? > >> > >> Yes, that should be doable as well. It's unlikely that all of the CAM > >> changes will get merged back, but the driver itself shouldn't be a problem. > >> > >> Ken > >> > > > > Has this driver been MFC to 8-STABLE yet ? > > > > I'm asking because I updated my NAS on the 4th of March from 8-STABLE > > r225723 to r232477 and am now seeing 157,000 interrupts per second on irq > > 16 where my SuperMicro AOC-USAS2-L8i resides (this card uses the LSI > > SAS2008 chip). > > > > More details are in a thread on the freebsd-stable mailing list entitled > > "157k interrupts per second causing 60% CPU load on idle system". The > > first message is here: > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=152290+156717+/usr/local/www/db/text/2012/freebsd-stable/20120325.freebsd-stable > > > > If this new driver isn't in 8-STABLE yet I think I'll try upgrading the > > whole system to 9-STABLE. > >Be sure to update your firmware beforehand. v11 firmware from LSI > (or the OEM vendor) is required in order for all drives to be detected > in FreeBSD in certain configs. > Cheers, > -Garrett After encountering this problem I updated my firmware from phase 7 to phase 11 but this did not fix things. My question is: "Is the LSI driver even in 8-STABLE yet?". If not I'll upgrade to 9-STABLE to get the new driver. If it is, then I want to downgrade to just before it came in to see if this high interrupt rate problem is fixed. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver available
On 21 January 2012 09:58, Kenneth D. Merry wrote: > On Fri, Jan 20, 2012 at 23:14:20 -, Steven Hartland wrote: > > - Original Message - > > From: "Kenneth D. Merry" > > To: ; > > Sent: Friday, January 20, 2012 8:44 PM > > Subject: LSI supported mps(4) driver available > > > > > > > > > >The LSI-supported version of the mps(4) driver that supports their 6Gb > SAS > > >HBAs as well as WarpDrive controllers, is available here: > > > > > >http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt > > > > > >I plan to check it in to head next week, and then MFC it into stable/9 a > > >week after that most likely. > > > > Great to see this being done, thanks to everyone! Be even better to see > > this MFC'ed to 8.x as well if all goes well. Do you think this will > > possible? > > Yes, that should be doable as well. It's unlikely that all of the CAM > changes will get merged back, but the driver itself shouldn't be a problem. > > Ken > Has this driver been MFC to 8-STABLE yet ? I'm asking because I updated my NAS on the 4th of March from 8-STABLE r225723 to r232477 and am now seeing 157,000 interrupts per second on irq 16 where my SuperMicro AOC-USAS2-L8i resides (this card uses the LSI SAS2008 chip). More details are in a thread on the freebsd-stable mailing list entitled "157k interrupts per second causing 60% CPU load on idle system". The first message is here: http://www.freebsd.org/cgi/getmsg.cgi?fetch=152290+156717+/usr/local/www/db/text/2012/freebsd-stable/20120325.freebsd-stable If this new driver isn't in 8-STABLE yet I think I'll try upgrading the whole system to 9-STABLE. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x220 notes
On 03/19/12 06:25, Ganael LAPLANCHE wrote: > On Wed, 14 Mar 2012 11:24:24 -0700, matt wrote > > Hi, > >> Can anyone verify that suspend/resume is now broken on x220 >> with latest HEAD and the KMS patches? Suspend bounce causes >> crash, resume beep makes modem sound and hangs, logs indicate >> only suspend. hw.pci.do_power_resume=0 causes no change. > Damn, I can confirm that I only get a black screen on resume (after > being able to quickly see my desktop appear and disappear) with kernel > from 2012/03/17 and http://people.freebsd.org/~kib/drm/all.13.6.patch. > > Best regards, > > -- > Ganael LAPLANCHE > http://www.martymac.org | http://contribs.martymac.org > FreeBSD: martymac , http://www.FreeBSD.org > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Yes, same here. I'll have to try again without the patch to see if it's Xorg/KMS or FreeBSD base that has changed. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x220 notes
On 03/13/12 21:38, matt wrote: On 03/13/12 17:43, matt wrote: On 03/12/12 17:00, Kevin Oberman wrote: On Fri, Mar 9, 2012 at 7:24 PM, matt wrote: On 03/08/12 01:28, Ganael LAPLANCHE wrote: On Wed, 07 Mar 2012 20:29:16 +0200, Vrachnis Ilias-Dimitrios wrote Hi, 2. I've read bad reviews about webcam having poor quality on GNU/Linux, so I would assume it will be the same on FreeBSD with webcamd and not worth the $30? (which also frees up space for 3x3 antenna) Yep, the webcam works with webcamd but the quality is not great... 4. How far is the AMD64 kernel suspend/resume? What do you mean by video doesn't resume? I run 10-CURRENT : FreeBSD laptop.martymac.org 10.0-CURRENT FreeBSD 10.0-CURRENT #12 r231062M: Mon Feb 6 10:29:35 CET 2012 marty...@laptop.martymac.org:/usr/obj/files/Src/sys/GENERIC amd64 with all.13.1 patch (no more available) from : http://people.freebsd.org/~kib/drm/ 3D acceleration works well, as well as suspend/resume when Xorg has been started (black screen if on console). Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac, http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" This is great news! I just finished some other stuff, so hopefully I can take a renewed look at brightness and the fan issue. Thanks for woking on this, Matt. I, for one, would be happy to have the volume and de-lighted to have brightness working on my T520! (Sorry or the weak pun.) So far it looks like acpi_video attaches, but the lcd0 device is not active. More interestingly, if you press brightness shortcuts, acpi_video can see the brightness value change while screen does not actually change. My conclusion based on bullshit and poking around in the acpidump, is that possibly either: 1) We need to call some ACPI handle to put ACPI in charge of brightness (google acpi brightness trapdoor) 2) acpi_video is attaching to the nvidia optimus hooks (yes, they're there, I know we don't have that option) and is missing the IGD video (VIGD/PEG etc) 3) Something else is wrong with either acpi, acpi_video, or bios that is preventing ACPI from working? I am going to take more of a look tonight. I think I can just hack in some ACPI calls straight to the ec if that will work, which might also include the correct ones to resume the display without KMS? Calling some _ON function or something perhaps Thanks! Matt I have brightness control through raw acpi..."\_BCL" and friends seem to do nothing. Most of the video methods differentiate between \VIGD (which seems to be a check for integrated graphics vs optimus, but that's still a guess) If \VIGD is true, brightness commands are sent to the EC, where they don't seem to do much yet. This is probably where we could enable something via EC/ibm-acpi? If \VIGD is false, brightness commands are handled in ACPI, although coarsely, via \VBRC. \VBRC seems to allow control over the backlight, at least, so those of you with sore eyes or the 3-cell battery may have some success using the acpi_call port (Danger!) kldload acpi_call acpi_call -p '\VBRC' -i n (where n is 0-10) Still hacking :)! Matt Can anyone verify that suspend/resume is now broken on x220 with latest HEAD and the KMS patches? Suspend bounce causes crash, resume beep makes modem sound and hangs, logs indicate only suspend. hw.pci.do_power_resume=0 causes no change. The acpi_call hack works on console as well, so at least we have some ability to control brightness for now. The next step is going to be figuring out why EC does nothing, or it would work out of the box I think. If that's a dead end, we can patch acpi_ibm to use \VBRC maybe. Also, once xorg & xfce load, my power usage goes from 9W tuned to 24W...I'm sure that's because patch is still in development. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x220 notes
On 03/13/12 17:43, matt wrote: On 03/12/12 17:00, Kevin Oberman wrote: On Fri, Mar 9, 2012 at 7:24 PM, matt wrote: On 03/08/12 01:28, Ganael LAPLANCHE wrote: On Wed, 07 Mar 2012 20:29:16 +0200, Vrachnis Ilias-Dimitrios wrote Hi, 2. I've read bad reviews about webcam having poor quality on GNU/Linux, so I would assume it will be the same on FreeBSD with webcamd and not worth the $30? (which also frees up space for 3x3 antenna) Yep, the webcam works with webcamd but the quality is not great... 4. How far is the AMD64 kernel suspend/resume? What do you mean by video doesn't resume? I run 10-CURRENT : FreeBSD laptop.martymac.org 10.0-CURRENT FreeBSD 10.0-CURRENT #12 r231062M: Mon Feb 6 10:29:35 CET 2012 marty...@laptop.martymac.org:/usr/obj/files/Src/sys/GENERIC amd64 with all.13.1 patch (no more available) from : http://people.freebsd.org/~kib/drm/ 3D acceleration works well, as well as suspend/resume when Xorg has been started (black screen if on console). Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac, http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" This is great news! I just finished some other stuff, so hopefully I can take a renewed look at brightness and the fan issue. Thanks for woking on this, Matt. I, for one, would be happy to have the volume and de-lighted to have brightness working on my T520! (Sorry or the weak pun.) So far it looks like acpi_video attaches, but the lcd0 device is not active. More interestingly, if you press brightness shortcuts, acpi_video can see the brightness value change while screen does not actually change. My conclusion based on bullshit and poking around in the acpidump, is that possibly either: 1) We need to call some ACPI handle to put ACPI in charge of brightness (google acpi brightness trapdoor) 2) acpi_video is attaching to the nvidia optimus hooks (yes, they're there, I know we don't have that option) and is missing the IGD video (VIGD/PEG etc) 3) Something else is wrong with either acpi, acpi_video, or bios that is preventing ACPI from working? I am going to take more of a look tonight. I think I can just hack in some ACPI calls straight to the ec if that will work, which might also include the correct ones to resume the display without KMS? Calling some _ON function or something perhaps Thanks! Matt I have brightness control through raw acpi..."\_BCL" and friends seem to do nothing. Most of the video methods differentiate between \VIGD (which seems to be a check for integrated graphics vs optimus, but that's still a guess) If \VIGD is true, brightness commands are sent to the EC, where they don't seem to do much yet. This is probably where we could enable something via EC/ibm-acpi? If \VIGD is false, brightness commands are handled in ACPI, although coarsely, via \VBRC. \VBRC seems to allow control over the backlight, at least, so those of you with sore eyes or the 3-cell battery may have some success using the acpi_call port (Danger!) kldload acpi_call acpi_call -p '\VBRC' -i n (where n is 0-10) Still hacking :)! Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x220 notes
On 03/12/12 17:00, Kevin Oberman wrote: On Fri, Mar 9, 2012 at 7:24 PM, matt wrote: On 03/08/12 01:28, Ganael LAPLANCHE wrote: On Wed, 07 Mar 2012 20:29:16 +0200, Vrachnis Ilias-Dimitrios wrote Hi, 2. I've read bad reviews about webcam having poor quality on GNU/Linux, so I would assume it will be the same on FreeBSD with webcamd and not worth the $30? (which also frees up space for 3x3 antenna) Yep, the webcam works with webcamd but the quality is not great... 4. How far is the AMD64 kernel suspend/resume? What do you mean by video doesn't resume? I run 10-CURRENT : FreeBSD laptop.martymac.org 10.0-CURRENT FreeBSD 10.0-CURRENT #12 r231062M: Mon Feb 6 10:29:35 CET 2012 marty...@laptop.martymac.org:/usr/obj/files/Src/sys/GENERIC amd64 with all.13.1 patch (no more available) from : http://people.freebsd.org/~kib/drm/ 3D acceleration works well, as well as suspend/resume when Xorg has been started (black screen if on console). Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac, http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" This is great news! I just finished some other stuff, so hopefully I can take a renewed look at brightness and the fan issue. Thanks for woking on this, Matt. I, for one, would be happy to have the volume and de-lighted to have brightness working on my T520! (Sorry or the weak pun.) So far it looks like acpi_video attaches, but the lcd0 device is not active. More interestingly, if you press brightness shortcuts, acpi_video can see the brightness value change while screen does not actually change. My conclusion based on bullshit and poking around in the acpidump, is that possibly either: 1) We need to call some ACPI handle to put ACPI in charge of brightness (google acpi brightness trapdoor) 2) acpi_video is attaching to the nvidia optimus hooks (yes, they're there, I know we don't have that option) and is missing the IGD video (VIGD/PEG etc) 3) Something else is wrong with either acpi, acpi_video, or bios that is preventing ACPI from working? I am going to take more of a look tonight. I think I can just hack in some ACPI calls straight to the ec if that will work, which might also include the correct ones to resume the display without KMS? Calling some _ON function or something perhaps Thanks! Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: growfs remove ufs/label and can't reset it with tunefs
2012/3/9 Olivier Cochard-Labbé > Hi all, > > once run growfs on a partition that had an UFS label, this label is > removed and it's no more possible to re-set it with tunefs. > Here is how to reproduce (tested on 8.3 and 9.0): > > mdconfig -a -t malloc -s 10MB > gpart create -s mbr /dev/md0 > gpart add -t freebsd -s 5MB /dev/md0 > newfs -L THELABEL /dev/md0s1 > glabel status | grep THELABEL > => Label is present, now we resize the slice: > gpart resize -i 1 /dev/md0 > glabel status | grep THELABEL > => Label is still present, now we growfs the slice: > growfs /dev/md0s1 > glabel status | grep THELABEL > => UFS label disapear ! > Ok, I will try to re-set it: > tunefs -L THELABEL /dev/md0s1 > glabel status | grep THELABEL > => Still no label !?! > > Should I create a PR about this problem ? > > Regards, > > Olivier > Yes, It is important to record this problem in the PR system. I suspect that the problem is with growfs as it needs to be taught to not overwrite the end of the volume where the label information is stored. (It will need to examine the volume to see if GEOM has information stored at the end of the volume such that the grow should not overwrite the GEOM metadata). Matthew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: More of that "Rune" business
On 03/09/12 22:19, Conrad J. Sabatier wrote: > On Fri, 9 Mar 2012 23:53:50 -0600 > "Conrad J. Sabatier" wrote: > > [snip] > >> Well, now, this is interesting. Just for curiosity's sake, I tried >> building a new kernel with the fresh source tree I just fetched from >> the svn repository, and it succeeded! Still can't build world, >> though. >> >> The question now is: do I dare install this new kernel and give it a >> try? Cant afford to do any harm to my existing installation. >> >> My latest working kernel is from Feb 23. Just how dangerous might it >> be to try the new one? > Well, alright. The kernel built, installed and booted OK (I used the > old-fashioned kernel build method with config(8)), but buildworld still > fails the same as before: > > ===> games/fortune/strfile (obj,depend,all,install) > /usr/obj/usr/src/tmp/usr/src/games/fortune/strfile created > for /usr/src/games/fortune/strfile rm -f .depend > CC='clang' mkdep -f .depend -a > -I/usr/obj/usr/src/tmp/legacy/usr/include > -std=gnu99 /usr/src/games/fortune/strfile/strfile.c echo > strfile: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >>> .depend clang -Wall -Wno-error -O2 -pipe -fomit-frame-pointer >>> -std=gnu99 -I/usr/obj/usr/src/tmp/legacy/usr/include >>> -c /usr/src/games/fortune/strfile/strfile.c clang -Wall -Wno-error >>> -O2 -pipe -fomit-frame-pointer -std=gnu99 >>> -I/usr/obj/usr/src/tmp/legacy/usr/include -static >>> -L/usr/obj/usr/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy >>> clang: warning: argument unused during compilation: '-std=gnu99' > strfile.o: In function `main': > /usr/src/games/fortune/strfile/strfile.c:(.text+0x2cc): undefined > reference to > `_ThreadRuneLocale' /usr/src/games/fortune/strfile/strfile.c:(.text+0x372): > undefined reference to `_ThreadRuneLocale' strfile.o: In function > `cmp_str': /usr/src/games/fortune/strfile/strfile.c:(.text+0x839): > undefined reference to > `_ThreadRuneLocale' /usr/src/games/fortune/strfile/strfile.c:(.text+0x898): > undefined reference to > `_ThreadRuneLocale' /usr/src/games/fortune/strfile/strfile.c:(.text+0x981): > undefined reference to `_ThreadRuneLocale' > strfile.o:/usr/src/games/fortune/strfile/strfile.c:(.text+0x9d9): more > undefined references to `_ThreadRuneLocale' follow clang: error: linker > command failed with exit code 1 (use -v to see invocation) *** > [strfile] Error code 1 > > Stop in /usr/src/games/fortune/strfile. > *** [bootstrap-tools] Error code 1 > > Stop in /usr/src. > *** [_bootstrap-tools] Error code 1 > > Stop in /usr/src. > *** [buildworld] Error code 1 > > Stop in /usr/src. > > > That sound you're hearing right now is me gnashing my teeth. :-) > blow away /usr/obj, /usr/src, csup to current, then do "cd /usr/src/include && make install"? That may fix your system headers enough to allow a buildworld... The rune curse was lifted long ago...sounds like there are some remnants still on your system. Matt "Klaatu barada xlocale..." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x220 notes
On 03/08/12 01:28, Ganael LAPLANCHE wrote: On Wed, 07 Mar 2012 20:29:16 +0200, Vrachnis Ilias-Dimitrios wrote Hi, 2. I've read bad reviews about webcam having poor quality on GNU/Linux, so I would assume it will be the same on FreeBSD with webcamd and not worth the $30? (which also frees up space for 3x3 antenna) Yep, the webcam works with webcamd but the quality is not great... 4. How far is the AMD64 kernel suspend/resume? What do you mean by video doesn't resume? I run 10-CURRENT : FreeBSD laptop.martymac.org 10.0-CURRENT FreeBSD 10.0-CURRENT #12 r231062M: Mon Feb 6 10:29:35 CET 2012 marty...@laptop.martymac.org:/usr/obj/files/Src/sys/GENERIC amd64 with all.13.1 patch (no more available) from : http://people.freebsd.org/~kib/drm/ 3D acceleration works well, as well as suspend/resume when Xorg has been started (black screen if on console). Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac, http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" This is great news! I just finished some other stuff, so hopefully I can take a renewed look at brightness and the fan issue. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x220 notes
On 03/06/12 15:25, Любомир Григоров wrote: > I will be buying a X220 soon and have some questions: > > 1. Which wireless has better support? > > ThinkPad 11b/g/n Wireless (Realtek RTL8192SE / RTL8188CE) > Intel Centrino Wireless-N 1000 > > 2. I've read bad reviews about webcam having poor quality on > GNU/Linux, so I would assume it will be the same on FreeBSD with > webcamd and not worth the $30? (which also frees up space for 3x3 antenna) > > 3. Any disadvantages in usage for turning off the UEFI? > > 4. How far is the AMD64 kernel suspend/resume? What do you mean by > video doesn't resume? > > 5. I'll be getting the IPS screen and want to make sure all the > brightness issues won't f it up. Is there yet a working way to control > brightness without interrupting the fan? > > Cheers. > > 2012/2/18 matt mailto:sendtom...@gmail.com>> > > I got 10-CURRENT installed on the x220 again. > > 1. Standard GENERIC kernel > 2. Buildworld/installworld from today's CVS > 3. No DRM/KMS patches or any other "factors" > 4. Witness KDB disabled in loader.conf (otherwise panic on suspend). > 5. setting hw.pci.do_power_suspend=0 wil prevent some AE_NO_METHOD > errors where it tries to set PCI express ports to D2 (the ports > themselves, I think...not the attached device) > > This is what I've found as I investigate the backlight/resume issue. I > am not very good at understanding ASL, but here's what I see. > > 1. _WAK calls a number of display related methods > 2. There are apparently brightness related calls here, as well as some > other video related calls > 3. Some of this behavior depends on /VIGD, whatever that is. > 4. The brightness calls seem to connect over LPC to the embedded > controller > 5. Some of the brightness methods check OSI for WIN7 > > I will add that iasl finds 35 errors in this fine piece of lenovo > work. > However, none of the errors appear to be near _wak. I've attached an > acpidump asl if it helps anyone who has a better eye for ASL and > resume/brightness problems. I think we can control brightness at least > with acpi_video, it attaches but not correctly..."active=0"...I > haven't > gone back over its source in comparison with ASL yet either. Probably > acpi_ibm will work also, as the acpi methods seem to just call the > embedded controller over the lpc bus? Unfortunately it seems something > has changed with the ec, as some of the data becomes corrupt when > acpi_ibm is loaded. > > Resume obviously works fine in Win7, works 80-95% of the time in Linux > (seems like KMS fail when it doesn't resume on Linux), and it resumes > fine on FreeBSD except no video. No bad messages in logs after resume. > > Matt > > > ___ > freebsd-a...@freebsd.org <mailto:freebsd-a...@freebsd.org> mailing > list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to > "freebsd-acpi-unsubscr...@freebsd.org > <mailto:freebsd-acpi-unsubscr...@freebsd.org>" > > > > > -- > Lyubomir Grigorov (bgalakazam) > Ditch the webcam...it's grainy under linux, probably would be the same under FreeBSD...haven't even tried. Intel wireless is THE way to go...that Realtek is barely supported on Linux (I believe 8192SU is still staging drivers...) FreeBSD only legacy boots, however "UEFI USB Support" must be on to allow USB booting for some reason. I have IPS...it's very nice, but still no brightness yet. I'll get a chance to look at again this weekend most likely. I think it's just an issue with our acpi_ibm that isn't talking to the embedded controller right. Resume works, but the screen is not on. I can now confirm it is *off* and not just "dimmed/no backlight". Setting BIOS to use an external monitor and disabling internal exhibits same behavior as internal display, i.e external monitor set as BIOS primary does not come back from power save. I have tried typing dpms force commands, did not work. Once resume & brightness work, it will be great for FreeBSD...everything else seemed fine, although I have not used fingerprint reader or card reader... An interesting note is that the BIOS does whitelist the wireless card, and the wwan slot defaults to being a mSATA until it detects a whitelisted USB ID or perhaps has no PCIe lines...not sure but my ral card I'm working with will not detect in the second slot at all. The slot may start as PCIe only in earlier bios, haven't checked (google x220 egpu & x220 msata issue). Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r232623 breaks buildworld (or a recent commit...)B
On 03/06/12 14:01, Dimitry Andric wrote: > On 2012-03-06 22:21, Larry Rosenman wrote: >> buildworld broken by r232623. >> >> -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer >> -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include >> -I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE >> -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc >> -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE >> -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime >> -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN >> -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 >> -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k >> -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/string/wmemset.c >> -o wmemset.So >> ctfconvert -L VERSION wmemset.So >> building shared library libc.so.7 >> setrunelocale.So: In function `__getCurrentRuneLocale': >> setrunelocale.c:(.text+0x0): multiple definition of `__getCurrentRuneLocale' >> nomacros.So:nomacros.c:(.text+0x0): first defined here > Should be fixed now by r232626, sorry for the breakage. :( > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" And now I see the problem is fixed. Sorry for the noise...thanks for fixing Dimitry! Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
