Re: ZFS problems
Fixed in r247540. If you are using a post-247265 zfs module please install the new module first. On 27.2.2013 22:56, Derrick Dantavious Edwards wrote: > I updated sources a couple of days ago and when I rebooted to continue > to > the upgrade process I received errors when I attempted to mount zfs > filesystem. The error looked like this. > > zpool mount -a > > internal error: Invalid arugment > pid 25 (zfs), uid 0, exited on signal 6 > Abort trap > > I get the same error if I just type zpool status -v, except the (zfs) is > replace with (zpool). The kernel module is loaded and visible by kldstat. > Any ideas? > ___ > 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" -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ 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: ARM pcpu changes, was Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Tue, Feb 26, 2013 at 1:39 PM, Konstantin Belousov wrote: > On Tue, Feb 26, 2013 at 09:06:51PM +1300, Andrew Turner wrote: >> Does anyone know if it is only curthread that needs to be atomic? If so >> this should work. Reading the cpuid from the system currently is a >> single instruction, however it appears the code will need to be reworked >> for use with multiple levels of affinity, for example when there >> are clusters of cores the current code will number two cores on >> different clusters with the same id. >> >> I don't think we need to use ldrex/strex to read/write the values, my >> understanding is the rest should be safe to access without atomic >> functions. > > I read about ARM architecture some time ago. What I am saying below is not > a proposal, but rather a way for me to learn more about the architecture. > > From my reading of the docs, ARM has the shadow registers, in particular, > the r13 (stack pointer) is shadowed for all privileged modes. Is the shadow > used by our kernel, is it correctly restored on the context switch ? > > If yes, you can easily recover the pcb address from the current sp, > without accessing any coprocessor registers, and even without any > assignment of the global register for curthread (which needs to be > done at the kernel entry). Just align the stack > start on the 2*PAGE_SIZE boundary (like it is already done for MIPS), > and do the mask operation on the sp value to get the end of pcb. > This is atomic and context-switch safe. > > pcb us already per-thread, and can store the thread pointer. > More, you can store the curcpu or cpuid pointer into pcb too, > and update it on the context switch. > > amd64 has an architecturally-defined special register (k)gsbase, which > effectively must be correctly initialized at each kernel entry, and > restored on the return to usermode. Since the initialization on entry > and restoration on exit is not atomic wrt the entry/exit itself, amd64 > periodically gets a bugs which cause kernel running with user gsbase. > This is the fatal bug, destroying the kernel structures and allowing the > CPU privilege mode switch for normal user. > > Using the shadow registers for this purpose eliminate the whole source > of the bugs. Well, IMHO, the both kernel and user thread stacks must correctly be set for current threads, otherwise it doesn't work. So, the idea to save things on a thread stack and update them on a context switch will work in general. However, the stack must be aligned to its size. And this is the price. I have no idea how this kernel stack alignment can impact kernel virtual space fragmentation. OTOH, as you say, this kernel stack storage can be used for many things. Svata ___ 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: Divert socket issues.
On Fri, Mar 01, 2013 at 11:44:48AM +1100, Varun Chandramohan wrote:
V> I sent this email to net group, unfortunately I got no response. Iam sorry
V> if that was the wrong group. Trying it again in this group. I wrote a small
V> program using divert sockets to capture packets using ipfw at outgoing. The
V> packets that are captured is for application mangling (mostly http headers)
V> and resent it back to browser. That means I need to reinject it back in
V> incoming instead of outgoing. I believe this is possible based on what is
V> said in the man pages.
V>
V> Man page:
V>
V> if sendto(2) is used with a destination IP address of INADDR_ANY, then the
V> packet is treated as if it were outgoing, i.e., destined for a non-local
V> address. Otherwise, the packet is assumed to be incoming and full packet
V> routing is done.
V>
V> In the latter case, the IP address specified must match the address of some
V> local interface, or an interface name must be found after the IP address.
V> If an interface name is found, that interface will be used and the value
V> of the IP
V> address will be ignored (other than the fact that it is not INADDR_ANY).
V> This is to indicate on which interface the packet ``arrived.''
V>
V> According to these instructions, I want my packet In-bound so I set my
V> local ip address for the sendto data structure using the below code.
V>
V> ssize_t
V> divert_get(int sd, struct sockaddr_in *sa, char *pkt_buf, int buflen){
V> ssize_t len;
V> unsigned int addrlen;
V>
V> addrlen = sizeof(*sa);
V> len = recvfrom(sd, pkt_buf, buflen, 0,
V>(struct sockaddr *) sa, &addrlen);
V> if(len == -1) {
V> bps_log(LOG_ERR, "Unable to recieve message from socket", errno);
V> }
V> return(len);}
V>
V>
V> /* addr is passed &sa from the above code */
V> rebuild_header(void *ptr, struct sockaddr_in *addr) {
V> ssize_t new_len = change_header(ptr);struct ip *ip = (struct ip*)ptr;
V> /* this is to divert it to input instead of output */
V> addr->sin_addr.s_addr = ip->ip_src.s_addr;
V>
V> /* Recompute checksums */
V> ip->ip_len = htons(new_len);
V>
V>cal_ip_cksum(ptr);
V>cal_tcp_cksum(ptr);
V>
V>if(divert_send(sd, addr, ptr, pkt_len) < 0) {
V> printf("No data sent from divert socket %d", errno);
V> }
V> }
V>
V>
V> I expect the packet to now be inbound but my application is not getting the
V> response sent by me. The possible case could be kernel dropping the packet.
V> I even set the port number which is the rule I want to match for example, I
V> have only two rules 1 and 65535. I tried setting port number to 0,1 and
V> even 65535 but still the kernel drops the packet.
V>
V> addr->sin_port = htons(65535);
V>
V> sento seems to work fine but the packet does not go through. If I re-inject
V> the packet back in the outgoing path (same place I took the packet) things
V> seem to work fine. Can someone please tell me whats wrong here? I don't
V> seem to understand. The man page is not very clear. I looked a bit into
V> divert code and it seem to call ip_input() for the packet I re-injected. If
V> thats the case, won't my packet get dropped because it has src address as
V> my local address (it expects it to be other way around if server has
V> responded)? Can someone please clarify this? If I have to still do it, do I
V> need to modify TCP/IP header fields as well?
Right, the packet is dropped due to its destination in IP header doesn't
match any local addresses.
Rewriting IP header to your destionation address of any random TCP packet
won't be enough, though, since in this case packet still would be dropped
due to it doesn't match any existing connection.
--
Totus tuus, Glebius.
___
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: ARM pcpu changes, was Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Fri, Mar 01, 2013 at 02:20:16PM +0100, Svatopluk Kraus wrote: > On Tue, Feb 26, 2013 at 1:39 PM, Konstantin Belousov > wrote: > > On Tue, Feb 26, 2013 at 09:06:51PM +1300, Andrew Turner wrote: > >> Does anyone know if it is only curthread that needs to be atomic? If so > >> this should work. Reading the cpuid from the system currently is a > >> single instruction, however it appears the code will need to be reworked > >> for use with multiple levels of affinity, for example when there > >> are clusters of cores the current code will number two cores on > >> different clusters with the same id. > >> > >> I don't think we need to use ldrex/strex to read/write the values, my > >> understanding is the rest should be safe to access without atomic > >> functions. > > > > I read about ARM architecture some time ago. What I am saying below is not > > a proposal, but rather a way for me to learn more about the architecture. > > > > From my reading of the docs, ARM has the shadow registers, in particular, > > the r13 (stack pointer) is shadowed for all privileged modes. Is the shadow > > used by our kernel, is it correctly restored on the context switch ? > > > > If yes, you can easily recover the pcb address from the current sp, > > without accessing any coprocessor registers, and even without any > > assignment of the global register for curthread (which needs to be > > done at the kernel entry). Just align the stack > > start on the 2*PAGE_SIZE boundary (like it is already done for MIPS), > > and do the mask operation on the sp value to get the end of pcb. > > This is atomic and context-switch safe. > > > > pcb us already per-thread, and can store the thread pointer. > > More, you can store the curcpu or cpuid pointer into pcb too, > > and update it on the context switch. > > > > amd64 has an architecturally-defined special register (k)gsbase, which > > effectively must be correctly initialized at each kernel entry, and > > restored on the return to usermode. Since the initialization on entry > > and restoration on exit is not atomic wrt the entry/exit itself, amd64 > > periodically gets a bugs which cause kernel running with user gsbase. > > This is the fatal bug, destroying the kernel structures and allowing the > > CPU privilege mode switch for normal user. > > > > Using the shadow registers for this purpose eliminate the whole source > > of the bugs. > > Well, IMHO, the both kernel and user thread stacks must correctly be > set for current threads, otherwise it doesn't work. So, the idea to > save things on a thread stack and update them on a context switch will > work in general. However, the stack must be aligned to its size. And > this is the price. I have no idea how this kernel stack alignment can > impact kernel virtual space fragmentation. > OTOH, as you say, this kernel stack storage can be used for many things. > Hi, FWIW, I have a proof-of-ooncept patch that does just that, and it seems to work well. Regards, Olivier ___ 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: Boot crash with HEAD on Thinkpad X220...
On Feb 25, 2013, at 21:33 , George Neville-Neil wrote: > Howdy, > > This has been happening since I updated on Saturday. I updated my tree today > (Monday) as well: > > http://people.freebsd.org/~gnn/X220bootcrash25Feb2013.jpg > > The system boots and works well enough to connect to the network and build a > new kernel > if I use safe mode. > > Thoughts? > Happily jhb@ pointed out that there was an issue in binutils recently. A buildworld plus buildkernel on bits from HEAD on 28 Feb did the trick and all is well again. Best, George signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Dtrace: Module is no longer loaded
on 21/02/2013 11:12 Eggert, Lars said the following: > Hi, > > On Feb 19, 2013, at 16:03, Andriy Gapon wrote: >> Couple of thoughts: >> - is your kernel installed in the typical location? > > yup. > >> - what does the following produce? >> readelf -a -W /boot/kernel/kernel | fgrep shstrtab >> readelf -a -W /boot/kernel/kernel | fgrep SUNW_ctf > > # readelf -a -W /boot/kernel/kernel | fgrep shstrtab > [24] .shstrtab STRTAB 7975ee 000124 00 > 0 0 1 > > # readelf -a -W /boot/kernel/kernel | fgrep SUNW_ctf > [22] .SUNW_ctf PROGBITS 74ed68 048872 00 > 0 0 4 > > And then: > > # dtrace -n 'syscall:::' > dtrace: invalid probe specifier syscall "/usr/lib/dtrace/psinfo.d", line > 90: failed to resolve type kernel`struct thread * for identifier curthread: > Module is no longer loaded How does kldstat output look on that machine? -- Andriy Gapon ___ 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] Fix build after r247570
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi, Marius,
The attached patch fixes two places where 'count' is not properly
initialized. They should be merged together when 247570 is merged.
Cheers,
- --
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
iQEcBAEBCgAGBQJRMSJpAAoJEG80Jeu8UPuzsxsH/2cArvN1kjTXod8IlSVh3ImV
81pjIcBoNRDAOes6lptsdOOdOeNg4/MweG2PT1ZpxQ5yUQHdBld9eIsaruYnD2/y
RcfGeMdSJCZ216yaFHLu54nxvlJJXK1lsO1R1cdeBDdSoQChXulVv38FnKiB9J1m
ldFCC8oBdPX6yCRR5ZIuLXHXYXZjGw0Vyvta74NFTNwysrUcgtLT/1tpDpcVtDdd
Kd+hJtBif4+3zk4py6IS9qiiiO5wC2YkCC5oNhKy2Dh48l/QIagj0Fx/dWRNW8Q4
VUnKJMn4wnnrEmXAFxKMECaFWXKMmI7pQ/dxLMCaMSl2WJgVxHt5skv4iLKcgxc=
=Ah/7
-END PGP SIGNATURE-
Index: sys/dev/aac/aac_pci.c
===
--- sys/dev/aac/aac_pci.c (revision 247583)
+++ sys/dev/aac/aac_pci.c (working copy)
@@ -340,7 +340,7 @@ aac_pci_attach(device_t dev)
{
struct aac_softc *sc;
const struct aac_ident *id;
- int count, error, reg, rid;
+ int count = 0, error, reg, rid;
fwprintf(NULL, HBA_FLAGS_DBG_FUNCTION_ENTRY_B, "");
Index: sys/dev/bce/if_bce.c
===
--- sys/dev/bce/if_bce.c(revision 247583)
+++ sys/dev/bce/if_bce.c(working copy)
@@ -1039,7 +1039,7 @@ bce_attach(device_t dev)
struct bce_softc *sc;
struct ifnet *ifp;
u32 val;
- int count, error, rc = 0, rid;
+ int count = 0, error, rc = 0, rid;
sc = device_get_softc(dev);
sc->bce_dev = dev;
___
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"
[head tinderbox] failure on i386/i386
TB --- 2013-03-01 21:40:18 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-03-01 21:40:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2013-03-01 21:40:18 - starting HEAD tinderbox run for i386/i386
TB --- 2013-03-01 21:40:18 - cleaning the object tree
TB --- 2013-03-01 21:40:18 - /usr/local/bin/svn stat /src
TB --- 2013-03-01 21:40:23 - At svn revision 247583
TB --- 2013-03-01 21:40:24 - building world
TB --- 2013-03-01 21:40:24 - CROSS_BUILD_TESTING=YES
TB --- 2013-03-01 21:40:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-03-01 21:40:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-03-01 21:40:24 - SRCCONF=/dev/null
TB --- 2013-03-01 21:40:24 - TARGET=i386
TB --- 2013-03-01 21:40:24 - TARGET_ARCH=i386
TB --- 2013-03-01 21:40:24 - TZ=UTC
TB --- 2013-03-01 21:40:24 - __MAKE_CONF=/dev/null
TB --- 2013-03-01 21:40:24 - cd /src
TB --- 2013-03-01 21:40:24 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Mar 1 21:40:28 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Sat Mar 2 00:26:38 UTC 2013
TB --- 2013-03-02 00:26:38 - generating LINT kernel config
TB --- 2013-03-02 00:26:38 - cd /src/sys/i386/conf
TB --- 2013-03-02 00:26:38 - /usr/bin/make -B LINT
TB --- 2013-03-02 00:26:38 - cd /src/sys/i386/conf
TB --- 2013-03-02 00:26:38 - /usr/sbin/config -m LINT
TB --- 2013-03-02 00:26:38 - building LINT kernel
TB --- 2013-03-02 00:26:38 - CROSS_BUILD_TESTING=YES
TB --- 2013-03-02 00:26:38 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-03-02 00:26:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-03-02 00:26:38 - SRCCONF=/dev/null
TB --- 2013-03-02 00:26:38 - TARGET=i386
TB --- 2013-03-02 00:26:38 - TARGET_ARCH=i386
TB --- 2013-03-02 00:26:38 - TZ=UTC
TB --- 2013-03-02 00:26:38 - __MAKE_CONF=/dev/null
TB --- 2013-03-02 00:26:38 - cd /src
TB --- 2013-03-02 00:26:38 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Mar 2 00:26:38 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
/src/sys/dev/aac/aac_pci.c:397:6: note: remove the '&&' if its condition is
always true
if (aac_enable_msi != 0 && pci_find_cap(dev, PCIY_MSI, ®) == 0) {
^~
/src/sys/dev/aac/aac_pci.c:343:11: note: initialize the variable 'count' to
silence this warning
int count, error, reg, rid;
^
= 0
2 errors generated.
*** [aac_pci.o] Error code 1
Stop in /obj/i386.i386/src/sys/LINT.
*** [buildkernel] Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2013-03-02 00:33:40 - WARNING: /usr/bin/make returned exit code 1
TB --- 2013-03-02 00:33:40 - ERROR: failed to build LINT kernel
TB --- 2013-03-02 00:33:40 - 8410.23 user 1279.35 system 10402.19 real
http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full
___
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"
[head tinderbox] failure on amd64/amd64
TB --- 2013-03-01 21:40:18 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-03-01 21:40:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2013-03-01 21:40:18 - starting HEAD tinderbox run for amd64/amd64
TB --- 2013-03-01 21:40:18 - cleaning the object tree
TB --- 2013-03-01 21:40:18 - /usr/local/bin/svn stat /src
TB --- 2013-03-01 21:40:23 - At svn revision 247583
TB --- 2013-03-01 21:40:24 - building world
TB --- 2013-03-01 21:40:24 - CROSS_BUILD_TESTING=YES
TB --- 2013-03-01 21:40:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-03-01 21:40:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-03-01 21:40:24 - SRCCONF=/dev/null
TB --- 2013-03-01 21:40:24 - TARGET=amd64
TB --- 2013-03-01 21:40:24 - TARGET_ARCH=amd64
TB --- 2013-03-01 21:40:24 - TZ=UTC
TB --- 2013-03-01 21:40:24 - __MAKE_CONF=/dev/null
TB --- 2013-03-01 21:40:24 - cd /src
TB --- 2013-03-01 21:40:24 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Mar 1 21:40:28 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> stage 5.1: building 32 bit shim libraries
>>> World build completed on Sat Mar 2 01:00:13 UTC 2013
TB --- 2013-03-02 01:00:13 - generating LINT kernel config
TB --- 2013-03-02 01:00:13 - cd /src/sys/amd64/conf
TB --- 2013-03-02 01:00:13 - /usr/bin/make -B LINT
TB --- 2013-03-02 01:00:13 - cd /src/sys/amd64/conf
TB --- 2013-03-02 01:00:13 - /usr/sbin/config -m LINT
TB --- 2013-03-02 01:00:13 - building LINT kernel
TB --- 2013-03-02 01:00:13 - CROSS_BUILD_TESTING=YES
TB --- 2013-03-02 01:00:13 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-03-02 01:00:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-03-02 01:00:13 - SRCCONF=/dev/null
TB --- 2013-03-02 01:00:13 - TARGET=amd64
TB --- 2013-03-02 01:00:13 - TARGET_ARCH=amd64
TB --- 2013-03-02 01:00:13 - TZ=UTC
TB --- 2013-03-02 01:00:13 - __MAKE_CONF=/dev/null
TB --- 2013-03-02 01:00:13 - cd /src
TB --- 2013-03-02 01:00:13 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Mar 2 01:00:13 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
/src/sys/dev/aac/aac_pci.c:397:6: note: remove the '&&' if its condition is
always true
if (aac_enable_msi != 0 && pci_find_cap(dev, PCIY_MSI, ®) == 0) {
^~
/src/sys/dev/aac/aac_pci.c:343:11: note: initialize the variable 'count' to
silence this warning
int count, error, reg, rid;
^
= 0
2 errors generated.
*** [aac_pci.o] Error code 1
Stop in /obj/amd64.amd64/src/sys/LINT.
*** [buildkernel] Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2013-03-02 01:06:33 - WARNING: /usr/bin/make returned exit code 1
TB --- 2013-03-02 01:06:33 - ERROR: failed to build LINT kernel
TB --- 2013-03-02 01:06:33 - 9763.39 user 1658.08 system 12374.78 real
http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full
___
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.c
> ===
> --- acpi_pci.c(revision 247320)
> +++ acpi_pci.c(working copy)
> @@ -264,6 +264,40 @@ acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 le
> return_ACPI_STATUS (AE_OK);
> }
>
> +static void
> +acpi_pci_override_handles(device_t dev)
> +{
> + struct acpi_pci_devinfo *dinfo;
> + device_t *devlist;
> + int error, i, numdevs;
> + char tunable_name[64], *path;
> + ACPI_HANDLE handle;
> +
> + error = device_get_children(dev, &devlist, &numdevs);
> + if (error)
> + return;
> + for (i = 0; i < numdevs; i++) {
> + dinfo = device_get_ivars(devlist[i]);
> + snprintf(tunable_name, sizeof(tunable_name),
> +
HEADS UP: Capsicum overhaul.
I just committed pretty large change that affects not only Capsicum, but also descriptor handling code in the kernel. If you will find some strange problems after r243611 (like panics, unexpected application errors, etc.) I may be at fault. I'll be looking at current@ mailing list closly, so report here if you find problems that look related to my change. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpD8eAHegq2k.pgp Description: PGP signature
[head tinderbox] failure on i386/pc98
TB --- 2013-03-01 23:48:55 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-03-01 23:48:55 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2013-03-01 23:48:55 - starting HEAD tinderbox run for i386/pc98
TB --- 2013-03-01 23:48:55 - cleaning the object tree
TB --- 2013-03-01 23:48:55 - /usr/local/bin/svn stat /src
TB --- 2013-03-01 23:48:58 - At svn revision 247583
TB --- 2013-03-01 23:48:59 - building world
TB --- 2013-03-01 23:48:59 - CROSS_BUILD_TESTING=YES
TB --- 2013-03-01 23:48:59 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-03-01 23:48:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-03-01 23:48:59 - SRCCONF=/dev/null
TB --- 2013-03-01 23:48:59 - TARGET=pc98
TB --- 2013-03-01 23:48:59 - TARGET_ARCH=i386
TB --- 2013-03-01 23:48:59 - TZ=UTC
TB --- 2013-03-01 23:48:59 - __MAKE_CONF=/dev/null
TB --- 2013-03-01 23:48:59 - cd /src
TB --- 2013-03-01 23:48:59 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Mar 1 23:49:03 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Sat Mar 2 02:41:33 UTC 2013
TB --- 2013-03-02 02:41:33 - generating LINT kernel config
TB --- 2013-03-02 02:41:33 - cd /src/sys/pc98/conf
TB --- 2013-03-02 02:41:33 - /usr/bin/make -B LINT
TB --- 2013-03-02 02:41:33 - cd /src/sys/pc98/conf
TB --- 2013-03-02 02:41:33 - /usr/sbin/config -m LINT
TB --- 2013-03-02 02:41:33 - building LINT kernel
TB --- 2013-03-02 02:41:33 - CROSS_BUILD_TESTING=YES
TB --- 2013-03-02 02:41:33 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-03-02 02:41:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-03-02 02:41:33 - SRCCONF=/dev/null
TB --- 2013-03-02 02:41:33 - TARGET=pc98
TB --- 2013-03-02 02:41:33 - TARGET_ARCH=i386
TB --- 2013-03-02 02:41:33 - TZ=UTC
TB --- 2013-03-02 02:41:33 - __MAKE_CONF=/dev/null
TB --- 2013-03-02 02:41:33 - cd /src
TB --- 2013-03-02 02:41:33 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Mar 2 02:41:33 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
/src/sys/dev/bce/if_bce.c:1108:29: error: variable 'count' is uninitialized
when used here [-Werror,-Wuninitialized]
(bce_msi_enable >= 1) && (count == 0)) {
^
/src/sys/dev/bce/if_bce.c:1042:11: note: initialize the variable 'count' to
silence this warning
int count, error, rc = 0, rid;
^
= 0
1 error generated.
*** [if_bce.o] Error code 1
Stop in /obj/pc98.i386/src/sys/LINT.
*** [buildkernel] Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2013-03-02 02:47:56 - WARNING: /usr/bin/make returned exit code 1
TB --- 2013-03-02 02:47:56 - ERROR: failed to build LINT kernel
TB --- 2013-03-02 02:47:56 - 8541.73 user 1329.06 system 10741.77 real
http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full
___
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: HEADS UP: Capsicum overhaul.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/01/13 21:05, Pawel Jakub Dawidek wrote: > I just committed pretty large change that affects not only Capsicum, but > also descriptor handling code in the kernel. If you will find some > strange problems after r243611 (like panics, unexpected application > errors, etc.) I may be at fault. I'll be looking at current@ mailing > list closly, so report here if you find problems that look related to my > change. > Two things I noted with a kernel @ SVN r247608: On reboot .. newsyslog: can't mv /var/log/debug.log.zGwQSBb to /var/log/debug.log: Capabilities insufficient .. and X/intel/KMS fails to start reverting to SVN r247497 (my previous compilation) performs as expected, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (FreeBSD) iEYEARECAAYFAlExcNEACgkQQv9rrgRC1JIJNgCfR6QOCb/lFDqh4yRfmGEoDJ4l y3wAoIc1unEGPyUADUQmf5pkVR8b1V16 =fMvc -END PGP SIGNATURE- ___ 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: HEADS UP: Capsicum overhaul.
On Sat, 2 Mar 2013, Pawel Jakub Dawidek wrote: I just committed pretty large change that affects not only Capsicum, but also descriptor handling code in the kernel. If you will find some strange problems after r243611 (like panics, unexpected application errors, etc.) I may be at fault. I'll be looking at current@ mailing list closly, so report here if you find problems that look related to my change. Similar to another post: vn up Updating '.': Udatabases/py-sqlite3/Makefile Udatabases/py-sqlite3/files/setup.py Udatabases/py-sqlite3/files/setup3.py svn: E93: Can't move '/usr/ports/.svn/tmp/svn-X6U5KQ' to '/usr/ports/databases/py-sqlite3/Makefile': Capabilities insufficient # svn up svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted # svn cleanup svn: E93: Can't move '/usr/ports/.svn/tmp/svn-Bb1iSM' to '/usr/ports/databases/py-sqlite3/Makefile': Capabilities insufficient # -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ 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"
