Re: kern/162578: 9.0-RC2's regression in power management on VIA Samuel 2
The following reply was made to PR kern/162578; it has been noted by GNATS. From: kron To: bug-follo...@freebsd.org, kro...@gmail.com Cc: Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA Samuel 2 Date: Tue, 22 Nov 2011 09:43:41 +0100 I bisected this down to r216674. Moreover, "AMD Features=0x8000<3DNow!>", which I highlighted in the original bugreport, was just a red herring. I'll try to attract some attention at users@ ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/162578: 9.0-RC2's regression in power management on VIA Samuel 2
The following reply was made to PR kern/162578; it has been noted by GNATS. From: kron To: bug-follo...@freebsd.org Cc: Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA Samuel 2 Date: Tue, 22 Nov 2011 09:48:08 +0100 > I'll try to attract some attention at users@ Sorry, I meant -questions@ ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/153206
The following reply was made to PR bin/153206; it has been noted by GNATS. From: Maxim Konovalov To: bug-follo...@freebsd.org Cc: Subject: bin/153206 Date: Tue, 22 Nov 2011 13:36:19 +0400 (MSK) Added to the audit trail. -- Maxim Konovalov -- Forwarded message -- Date: Tue, 22 Nov 2011 13:13:27 +0400 From: Dennis Yusupoff To: Maxim Konovalov Subject: Re: Bug bin/153206 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 21.11.2011 16:23, Dennis Yusupoff ?: > > > Will test it after finished kernel make. You're patch is working fine on fresh 8.2-STABLE, thank you. == |root@ntsled:/usr/home/dyr (1783) uname -a FreeBSD ntsled.ru 8.2-STABLE FreeBSD 8.2-STABLE #1: Tue Nov 22 11:31:59 MSK 2011 r...@ntsled.ru:/usr/obj/usr/src/sys/DYR_DE amd64 root@ntsled:/usr/home/dyr (1784) netstat -ss -f inet6 tcp: 105 packets sent 83 data packets (9394 bytes) 14 ack-only packets (0 delayed) 8 control packets 109 packets received 81 acks (for 9347 bytes) 4 duplicate acks 82 packets (9240 bytes) received in-sequence 4 connection requests 1 connection accept 5 connections established (including accepts) 33 connections closed (including 0 drops) 77 segments updated rtt (of 78 attempts) 23 correct data packet header predictions 1 syncache entry added 1 completed 1 cookie sent udp: 40 datagrams received 1 dropped due to no socket 2 broadcast/multicast datagrams undelivered 37 delivered 38 datagrams output ip6: 9 packets sent from this host Mbuf statistics: 0 one mbuf 0 one ext mbuf 0 two or more ext mbuf Source addresses selection rule applied: 9 first candidate 9 appropriate scope icmp6: Output histogram: neighbor solicitation: 5 MLDv2 listener report: 4 Histogram of error messages to be generated: rip6: root@ntsled:/usr/home/dyr (1785) netstat -ss -f inet6 -z > /dev/null root@ntsled:/usr/home/dyr (1786) netstat -ss -f inet6 tcp: 4 packets sent 4 data packets (288 bytes) 5 packets received 3 acks (for 288 bytes) 3 packets (156 bytes) received in-sequence 3 segments updated rtt (of 3 attempts) 2 correct data packet header predictions udp: ip6: Mbuf statistics: 0 one mbuf 0 one ext mbuf 0 two or more ext mbuf Source addresses selection rule applied: icmp6: Histogram of error messages to be generated: rip6: root@ntsled:/usr/home/dyr (1787) netstat -ss -f inet6 tcp: 25 packets sent 25 data packets (1716 bytes) 13 packets received 9 acks (for 1716 bytes) 5 packets (260 bytes) received in-sequence 5 segments updated rtt (of 5 attempts) 4 correct data packet header predictions udp: 2 datagrams received 2 broadcast/multicast datagrams undelivered ip6: Mbuf statistics: 0 one mbuf 0 one ext mbuf 0 two or more ext mbuf Source addresses selection rule applied: icmp6: Histogram of error messages to be generated: rip6: root@ntsled:/usr/home/dyr (1788)| == By the way, there is other little bug - ip6 Mbuf statistics show it's zero values under "-ss" command arguments, as you can see. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOy2e3AAoJEBUTaqBS2NB42KoH/RQC82gd04nx0J8X7hbRHdQv VLM2MWnveRlisucycvrRBMRbaPEw9EtUemyjLKpEjwniiM99ju/ztHhMWGImo7Os PBUj7IJJOxaz9h5fOe8/+tG4dPSnhWN7HnNk7j7MD8MXi6Tnvo7w2QS5XbkKLRHi oELsOW4paFR0WZ6bHb7FPzKnhHOjifup4XntqHa2i4j3rosqNV+cy+f2AehNlIl2 RSXI7mA0Zw3OsX4N8+qF6BMqLbQIaWNrgVjheHEbyBy3SVWqigX0I/91A0lVIzf+ 59w+lB3hlB11etHIEoJYTgY3ibw4yxAJKLCXc87tprTzPwU1/JNXuuSEqUwcJh8= =kvDw -END PGP SIGNATURE- ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/162751: [zfs] [panic] kernel panics during file operations
>Number: 162751
>Category: kern
>Synopsis: [zfs] [panic] kernel panics during file operations
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Nov 22 10:40:06 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Jacek Kalamarz
>Release:8.2-RELEASE-p4
>Organization:
>Environment:
FreeBSD kim.rolskiego.net 8.2-RELEASE-p4 FreeBSD 8.2-RELEASE-p4 #0: Tue Oct 25
10:15:05 CEST 2011 r...@kim.rolskiego.net:/usr/obj/usr/src/sys/GENERIC
amd64
Celeron 1.2GHz, 2GB RAM, zpool created on 1TB partition
ZFS details:
simson@kim:usr/src/sys/GENERIC$ zpool status
pool: tank
state: ONLINE
scrub: none requested
config:
NAMESTATE READ WRITE CKSUM
tankONLINE 0 0 0
ad4s1dONLINE 0 0 0
errors: No known data errors
simson@kim:usr/src/sys/GENERIC$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 111G 803G23K none
tank/home 47.7G 52.3G 16.3G /home
tank/storage 54.1G 246G 54.1G /storage
tank/tmp 30.2M 50.0G 30.2M /tmp
tank/usr 2.19G 2.81G 2.19G /usr
tank/var 4.58G 5.42G 4.58G /var
simson@kim:usr/src/sys/GENERIC$ zfs list -H -t snapshot | wc -l
36
>Description:
Since ZFS is used on the machine, the machine crashes about once a week.
Previously (using only UFS2 partitions), the machine was stable for 3 months.
The logs show exactly the same code line each time:
simson@kim:usr/src/sys/GENERIC$ kgdb kernel.debug /var/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x46070c9e
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x80820f37
stack pointer = 0x28:0xff8092280770
frame pointer = 0x28:0xff8092280800
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 38 (arc_reclaim_thread)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0x805f4e0e at kdb_backtrace+0x5e
#1 0x805c2d07 at panic+0x187
#2 0x808ac630 at trap_fatal+0x291
#3 0x808aca0f at trap_pfault+0x28f
#4 0x808aceef at trap+0x3df
#5 0x80894fe4 at calltrap+0x8
#6 0x80821932 at vm_page_remove+0x32
#7 0x80821a7d at vm_page_free_toq+0x6d
#8 0x8082085b at vm_object_page_remove+0x11b
#9 0x80818c33 at vm_map_delete+0x313
#10 0x80818d41 at vm_map_remove+0x51
#11 0x8080d6a5 at uma_large_free+0x55
#12 0x805aff97 at free+0x77
#13 0x80e36351 at arc_buf_destroy+0x101
#14 0x80e39614 at arc_evict+0x2f4
#15 0x80e3a6ec at arc_adjust+0x1bc
#16 0x80e3a9b0 at arc_reclaim_thread+0x1a0
#17 0x805994f8 at fork_exit+0x118
Uptime: 11d9h8m14s
Physical memory: 1997 MB
Dumping 1632 MB: 1617 1601 1585 1569 1553 1537 1521 1505 1489 1473 1457 1441
1425 1409 1393 1377 1361 1345 1329 1313 1297 1281 1265 1249 1233 1217 1201 1185
1169 1153 1137 1121 1105 1089 1073 1057 1041 1025 1009 993 977 961 945 929 913
897 881 865 849 833 817 801 785 769 753 737 721 705 689 673 657 641 625 609 593
577 561 545 529 513 497 481 465 449 433 417 401 385 369 353 337 321 305 289 273
257 241 225 209 193 177 161 145 129 113 97 81 65 49 33 17 1
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/boot/kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /usr/local/modules/fuse.ko...done.
Loaded symbols for /usr/local/modules/fuse.ko
Reading symbols from /boot/kernel/snp.ko...Reading symbols from
/boot/kernel/snp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snp.ko
#0 doadump () at pcpu.h:224
224 __asm("movq %%gs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:224
#1 0x805c28be in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:419
#2 0x805c2cf1 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:592
#3 0x808ac63
Re: kern/162751: [zfs] [panic] kernel panics during file operations
Synopsis: [zfs] [panic] kernel panics during file operations Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Nov 22 11:09:33 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=162751 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/150206: [patch] nmount(2): can't switch root partition to rw using mount flags
Old Synopsis: [libc] [patch] nmount(2): can't switch root partition to rw using mount flags New Synopsis: [patch] nmount(2): can't switch root partition to rw using mount flags Responsible-Changed-From-To: jh->freebsd-bugs Responsible-Changed-By: jh Responsible-Changed-When: Tue Nov 22 17:37:49 UTC 2011 Responsible-Changed-Why: Back to pool. I am not actively working on this. http://www.freebsd.org/cgi/query-pr.cgi?pr=150206 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: ports/162138: wrong file referenced in package - Shared object "libcam.so.5" not found, required by "mkisofs"
Synopsis: wrong file referenced in package - Shared object "libcam.so.5" not found, required by "mkisofs" Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs Responsible-Changed-By: jh Responsible-Changed-When: Tue Nov 22 17:40:16 UTC 2011 Responsible-Changed-Why: Ports bug. http://www.freebsd.org/cgi/query-pr.cgi?pr=162138 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/162741: [PATCH] vm_kmem_size miscalculated due to int type overflow sometimes
On Mon, 21 Nov 2011, Adam McDougall wrote: Description: [Misformatted lines deleted] Fix: Patch attached with submission follows: --- sys/kern/kern_malloc.c.orig 2011-11-21 12:19:25.712591472 -0500 +++ sys/kern/kern_malloc.c 2011-11-21 17:25:11.831042640 -0500 @@ -704,10 +704,10 @@ * Limit kmem virtual size to twice the physical memory. * This allows for kmem map sparseness, but limits the size * to something sane. Be careful to not overflow the 32bit -* ints while doing the check. +* ints while doing the check or the adjustment. */ if (((vm_kmem_size / 2) / PAGE_SIZE) > cnt.v_page_count) - vm_kmem_size = 2 * cnt.v_page_count * PAGE_SIZE; + vm_kmem_size = 2 * mem_size * PAGE_SIZE; #ifdef DEBUG_MEMGUARD tmp = memguard_fudge(vm_kmem_size, vm_kmem_size_max); cnt.v_page_count should probably be spelled as mem_size in the check too. The limit is still garbage for 32-bit systems. 32-bit systems can easily have 2-4GB of physical memory. i386 with PAE can have much more. Overflow can't occur in (2 * cnt.v_page_count * PAGE_SIZE) since the original vm_kmem_size is limited to 4G-1 by u_long bogusly being 32 bits on all supported 32-bit systems. But the user can misconfigure things so that the original vm_kmem_size is only slightly less than 4G. Then there cannot be that much kva. But when there is = 2G physical, clamping kva to <= 2*physical has no effect. VM_KMEM_SIZE_MAX or vm.kmem_size would have to be misconfigured for vm_kmem_size to be impossibly large. This means that the above code usually has no effect on 32-bit systems. Bruce ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/162741: [PATCH] vm_kmem_size miscalculated due to int type overflow sometimes
The following reply was made to PR kern/162741; it has been noted by GNATS. From: Bruce Evans To: Adam McDougall Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/162741: [PATCH] vm_kmem_size miscalculated due to int type overflow sometimes Date: Wed, 23 Nov 2011 03:48:43 +1100 (EST) On Mon, 21 Nov 2011, Adam McDougall wrote: >> Description: > [Misformatted lines deleted] >> Fix: > > Patch attached with submission follows: > > --- sys/kern/kern_malloc.c.orig 2011-11-21 12:19:25.712591472 -0500 > +++ sys/kern/kern_malloc.c 2011-11-21 17:25:11.831042640 -0500 > @@ -704,10 +704,10 @@ > * Limit kmem virtual size to twice the physical memory. > * This allows for kmem map sparseness, but limits the size > * to something sane. Be careful to not overflow the 32bit > - * ints while doing the check. > + * ints while doing the check or the adjustment. > */ > if (((vm_kmem_size / 2) / PAGE_SIZE) > cnt.v_page_count) > -vm_kmem_size = 2 * cnt.v_page_count * PAGE_SIZE; > +vm_kmem_size = 2 * mem_size * PAGE_SIZE; > > #ifdef DEBUG_MEMGUARD > tmp = memguard_fudge(vm_kmem_size, vm_kmem_size_max); cnt.v_page_count should probably be spelled as mem_size in the check too. The limit is still garbage for 32-bit systems. 32-bit systems can easily have 2-4GB of physical memory. i386 with PAE can have much more. Overflow can't occur in (2 * cnt.v_page_count * PAGE_SIZE) since the original vm_kmem_size is limited to 4G-1 by u_long bogusly being 32 bits on all supported 32-bit systems. But the user can misconfigure things so that the original vm_kmem_size is only slightly less than 4G. Then there cannot be that much kva. But when there is >= 2G physical, clamping kva to <= 2*physical has no effect. VM_KMEM_SIZE_MAX or vm.kmem_size would have to be misconfigured for vm_kmem_size to be impossibly large. This means that the above code usually has no effect on 32-bit systems. Bruce ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/162765: [patch] lseek(2) may return successful although no seek operation was actually performed
>Number: 162765 >Category: kern >Synopsis: [patch] lseek(2) may return successful although no seek >operation was actually performed >Confidential: no >Severity: non-critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Tue Nov 22 20:40:01 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Alexander Best >Release:10.0-CURRENT >Organization: >Environment: FreeBSD otaku 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r227803M: Mon Nov 21 23:05:28 CET 2011 arundel@otaku:/usr/obj/usr/subversion-src/sys/ARUNDEL amd64 >Description: in certain situations lseek() will return successful although no seek was performed. this can happen when operating on devices that don't support seeking (older tape drives) or when operating on changeable media devices (such as DVD or Blu-ray devices) without a medium inserted. the attached patch fixes the lseek(2) man page by adding several entries to the BUGS section, along with updating the POSIX compliance to the latest specifications. please note that the real issue doesn't seem fixable atm. lseek() was never designed to confirm a seek operation, but to merely request it. the issue was extensively discussion in this thread: http://lists.freebsd.org/pipermail/freebsd-hackers/2011-November/036842.html (alternative link: http://docs.freebsd.org/cgi/mid.cgi?2015202450.GA73512) cheers. alex >How-To-Repeat: >Fix: Patch attached with submission follows: diff --git a/lib/libc/sys/lseek.2 b/lib/libc/sys/lseek.2 index 874c523..209af51 100644 --- a/lib/libc/sys/lseek.2 +++ b/lib/libc/sys/lseek.2 @@ -28,7 +28,7 @@ .\" @(#)lseek.28.3 (Berkeley) 4/19/94 .\" $FreeBSD$ .\" -.Dd April 5, 2007 +.Dd November 21, 2011 .Dt LSEEK 2 .Os .Sh NAME @@ -113,10 +113,9 @@ of the existing end-of-file of the file. If data is later written at this point, subsequent reads of the data in the gap return bytes of zeros (until data is actually written into the gap). -.Pp -Some devices are incapable of seeking. -The value of the pointer -associated with such a device is undefined. +However, the +.Fn lseek +system call does not, by itself, extend the size of a file. .Pp A .Qq hole @@ -197,13 +196,43 @@ is associated with a pipe, socket, or FIFO. The .Fn lseek system call is expected to conform to -.St -p1003.1-90 . +.St -p1003.1-2008 . +.Pp +The +.Dv SEEK_HOLE +and +.Dv SEEK_DATA +directives, along with the +.Er ENXIO +error, are extensions to that specification. .Sh HISTORY The .Fn lseek function appeared in .At v7 . .Sh BUGS +If the +.Fn lseek +system call is operating on a device which is incapable of seeking, +it will request the seek operation and return successfully, +even though no seek was performed. +Because the +.Ar offset +argument will be stored unconditionally in the file descriptor of that device, +there is no way to confirm, if the seek operation succeeded or not +(e.g. using the +.Fn ftell +function). +Device types which are known to be incapable of seeking include +tape drives. +.Pp +The +.Fn lseek +system call will not detect whether media are present in changeable +media devices such as DVD or Blu-ray devices. +A requested seek operation will therefore return sucessfully when no +medium is present. +.Pp This document's use of .Fa whence is incorrect English, but is maintained for historical reasons. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/162765: [patch] lseek(2) may return successful although no seek operation was actually performed
Synopsis: [patch] lseek(2) may return successful although no seek operation was actually performed Responsible-Changed-From-To: freebsd-bugs->freebsd-doc Responsible-Changed-By: arundel Responsible-Changed-When: Tue Nov 22 20:45:29 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=162765 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/162578: 9.0-RC2's regression in power management on VIA Samuel 2
The following reply was made to PR kern/162578; it has been noted by GNATS. From: kron To: bug-follo...@freebsd.org, j...@freebsd.org, j...@freebsd.org, freebsd-a...@freebsd.org Cc: Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA Samuel 2 Date: Wed, 23 Nov 2011 07:57:57 +0100 Hello, I'm bringing this to -acpi@ as suggested by jhb@. Some time ago while testing 9.0-RC2 I noticed that power management got broken (powerd doesn't start, Cx states disappeared) on a specific class of our minirouters. I created kern/162578, bisected the issue down to r216674 and I contacted the author - jhb@. John was kind to do a further analysis. Verbose boots before and after r216674 differ this way: -Calibrating TSC clock ... TSC clock: 532647138 Hz +Calibrating TSC clock ... TSC clock: 532648183 Hz -ACPI timer: 0/4 0/5 0/4 0/5 0/4 0/5 0/4 0/5 0/4 0/4 -> 0 -Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 -acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 +acpi_timer0: couldn't allocate resource (port 0x4008) -acpi_throttle0: P_CNT from P_BLK 0x4010 +acpi_throttle0: failed to attach P_CNT +device_attach: acpi_throttle0 attach returned 6 John's comment: > So this is the issue, and it seems what happens is that your > BIOS assigns the resources for this range to the pcib0 device > when we expect them to be assigned as a system resource (if > at all): > pcib0: port > 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f > on acpi0 > You could try hacking your ASL to not list the 0x4000-0x407f range > for now, but the real fix is probably to make resources attached > to Host-PCI bridge devices be treated as if they were system > resources and put into the ACPI system resource rman instead. > That requires a fair bit of work however. John also suggested to involve jkim@ and -acpi@. I'm going to experiment with ASL because it would be an acceptable solution to me and the real fix is way above my skills ATM. If anybody is interested in this I have a spare machine affected by this issue and I can do any test. Best regards Oli Kron ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
