Re: acpi resume related patch
On Mon, Jan 28, 2013 at 10:55 AM, John Baldwin wrote: > On Saturday, January 26, 2013 9:18:57 am Andriy Gapon wrote: >> on 25/01/2013 18:08 Andriy Gapon said the following: >> > on 25/01/2013 15:51 John Baldwin said the following: >> >> On Friday, January 25, 2013 3:43:33 am Andriy Gapon wrote: >> >>> >> >>> If you have ACPI suspend/resume working, if it used to work but stopped >> >>> working >> >>> at some time, if it never worked, but you are still hoping, could you >> >>> please >> >>> test the following patch and report back? >> >>> >> >>> http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch >> >> >> >> This will break systems not using the local APIC since you unconditionally >> >> call lapic_setup() on resume.This was part of the feature of the previous >> >> code that by using a dummy pic it could register it only when the local >> >> APIC >> >> was used. >> > >> > Thank you for drawing my attention to this. I will try to fix this issue. >> > The reason I want to remove lapic from 'pics' (and I already described it >> > in a >> > private email) is that Local APIC is a special kind of PIC. It's already >> > explicitly initialized by APs. Putting it into 'pics' tailq just >> > obfuscates the code. >> > >> >> It should also be registered before any of the I/O APICs are by >> >> the design of the local_apic.c code. >> > >> > In fact, as I see in the code, Local APIC is always registered _after_ I/O >> > APICs. >> > And thus lapic_resume was called after ioapic_resume. >> > Additionally, currently there is no synchronization between initialization >> > of >> > Local APICs on APs and initialization of I/O APICs at the wakeup/resume >> > time. >> > >> >> Here is an updated version of the patch: >> http://people.freebsd.org/~avg/acpi-apic-wakeup.2.patch >> >> John, >> could you please review the PIC-related part? I decided to go back to the >> current approach while fixing the suspend/resume ordering and also order of >> registration for Local APIC. Must say that XEN special casing makes >> apic_setup_io a little bit untidy. >> >> Additionally this patch fixes AP Local APIC initialization ordering on i386. >> In the original patch I changed only amd64 code. > > This looks good to me. No joy here. System graphics turns off as I'd expect, but it never comes back. No wireless. No access. :-( Maybe someday, but not today. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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: hwpmc support for Ivy Bridge Xeon
On Sat, Jan 26, 2013 at 1:58 AM, hiren panchasara wrote: > I've tried to update hwpmc by adding support for xeon class of Ivy > bridge processors. > > Thanks Jim for pointing me to the correct document. (325462-045US Jan 2013) > > I do not have a reference machine to test with. Any help in that > regard would be appreciated. Got a machine with ivy bridge xeon. Will test my changes and update here soon. Hiren > > Here are the diffs against head (245927): > http://www.strugglingcoder.info/patches/hwpmc_ibx.txt > > Thanks, > Hiren ___ 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: mounting root from NFS via ROOTDEVNAME
Lars Eggert wrote: > Hi, > > I'm trying to netboot a system where the root device is specified in > the kernel via ROOTDEVNAME: > > options BOOTP > options BOOTP_NFSROOT > options BOOTP_NFSV3 > options BOOTP_COMPAT > options BOOTP_WIRED_TO=em4 > options ROOTDEVNAME=\"nfs:10.11.12.13:/usr/home/elars/dst\" > > I was under the assumption that specifying a ROOTDEVNAME in the kernel > config would override the "root-path" option in DHCP, or at least take > effect when "root-path" wasn't provided via DHCP, but that doesn't > seem to be the case. The system configures it's address correctly over > em4, but then enters a loop: > > em4: link state changed to UP > Received DHCP Offer packet on em4 from 0.0.0.0 (accepted) (no root > path) > Sending DHCP Request packet from interface em4 (XX:XX:XX:XX:XX:XX) > Received DHCP Ack packet on em4 from 0.0.0.0 (accepted) (no root path) > Received DHCP Ack packet on em4 from 0.0.0.0 (accepted) (no root path) > DHCP/BOOTP timeout for server 255.255.255.255 > Received DHCP Ack packet on em4 from 0.0.0.0 (accepted) (no root path) > DHCP/BOOTP timeout for server 255.255.255.255 > ... > > If I hand out a root path via DHCP the system boots fine, but the idea > here is to be able to boot different root devices without needing to > diddle dhcpd.conf. Can this be done? > Well, just to make it more interesting, there are 2 different ways an NFS root file system can be booted by the kernel. The other one can be configured by: - delete all options that start in BOOTP - add the "options NFS_ROOT" Now, the kernel will use information from a list of environment variables set by the loader, plus the values referenced to rootdevnames[0] and rootdevnames[1], if they are set. (The list of these environment variables is in a comment in sys/nfs/nfs_diskless.c and are normally set by pxeboot.) rootdevnames[0] gets set in nfs_diskless.c, but rootdevnames[1] does not. This source file has the magic for this way of doing it, as you might have guessed. I think rootdevnames[1] gets tried if rootdevnames[0] fails. You could try hacking sys/nfs/nfs_diskless.c and add a line to set rootdevnames[1] to ROOTDEVNAME, if it is defined. (#include "opt_rootdevname.h" so that it will be defined, if the option is specified.) I haven't tried this, but it might work? Btw, for the above to work, you need to use pxeboot and I think you'll need to have enough dhcpd setup so that it loads. (I'm not sure if option root-path is needed for pxeboot to get the loader going?) Short answer is, there may be a way to get this to work with a little source hacking, but it might be easier to just modify your dhcpd.conf;-) Btw, I use this document for how I set things up for the "options NFS_ROOT" version. http://people.freebsd.org/~rodrigc/pxe/freebsd_pxe.txt Good luck with it, rick ps: All BOOTP_NFSROOT does is tell the BOOTP version to use an NFS root and it will then expect the dhcp root-path option as you found out. > Thanks, > Lars > ___ > 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-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 fixing libdtrace dependencies
Please check in this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=175661 MFC 9.X. Yuri ___ 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: Zpool surgery
In the last episode (Jan 28), Fabian Keil said: > Ulrich Spörlein wrote: > > On Mon, 2013-01-28 at 07:11:40 +1100, Peter Jeremy wrote: > > > On 2013-Jan-27 14:31:56 -, Steven Hartland > > > wrote: > > > >- Original Message - > > > >From: "Ulrich Spörlein" > > > >> I want to transplant my old zpool tank from a 1TB drive to a new > > > >> 2TB drive, but *not* use dd(1) or any other cloning mechanism, as > > > >> the pool was very full very often and is surely severely > > > >> fragmented. > > > > > > > >Cant you just drop the disk in the original machine, set it as a > > > >mirror then once the mirror process has completed break the mirror > > > >and remove the 1TB disk. > > > > > > That will replicate any fragmentation as well. "zfs send | zfs recv" > > > is the only (current) way to defragment a ZFS pool. > > It's not obvious to me why "zpool replace" (or doing it manually) > would replicate the fragmentation. "zpool replace" essentially adds your new disk as a mirror to the parent vdev, then deletes the original disk when the resilver is done. Since mirrors are block-identical copies of each other, the new disk will contain an exact copy of the original disk, followed by 1TB of freespace. -- Dan Nelson dnel...@allantgroup.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: ACPI panic on unplugging the power cord.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-26 11:58:16 -0500, Pawel Jakub Dawidek wrote: > On Fri, Jan 25, 2013 at 04:19:44PM -0500, Jung-uk Kim wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 2013-01-25 04:26:02 -0500, Pawel Jakub Dawidek wrote: >>> On Thu, Jan 24, 2013 at 05:18:48PM +0100, Pawel Jakub Dawidek >>> wrote: One is when I leave laptop idle for some time (few hours?): http://people.freebsd.org/~pjd/misc/acpi_idle_panic_0.jpg http://people.freebsd.org/~pjd/misc/acpi_idle_panic_1.jpg >>> >>> Small update. This panic doesn't happen when the system is >>> idle, it happens we I close the lid to the point when display >>> is turned off (which is almost closed, but not entirely >>> closed). >>> >>> Closing lid doesn't trigger suspend or anything like that. It >>> just turns off the display. >> >> Please try the attached patch (with my previous patch). Also, >> available from here: >> >> http://people.freebsd.org/~jkim/acpi_exit.diff > > Your patch fixes panic triggered by unplugging power cable as well > the one triggered by closing the lid. I haven't tried booting from > battery and connecting power cable, but I expect happy end there as > well. Committed, thanks! Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRButnAAoJECXpabHZMqHO+C4IAJVcT97/ZBylUajuBpY/s+rb uiBLHALbXpKiHqRDiaTmkGdROdfMKc8IhnOB97N7YlLMzYhEFKXCL4JCMxGtxT8K sQ3FzKsbdNaEVZl0k1Ql7ogLSMaCLS9Gjbd4/4Rm7oQUf+k90x9aSavsDBPfszgD uPrhBNgAvWVP9rHjMgW7mYsM73j33cbNYE5XBBV6R6RqDF4CjbhpwD4gIIQDsx3y 0ff3lc1RFed9syjlg6suL3jL+2Cnv+JkSVon5KA77n+g1zLkI6TifnWFYJnNt48r P7mhrmknazkoEdIEpDDFJEJTt4QE0qm0VRjCfzUPhsNdR1dJy85Hrijem9HmEWg= =vdbF -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: Zpool surgery
Ulrich Spörlein wrote: > On Mon, 2013-01-28 at 07:11:40 +1100, Peter Jeremy wrote: > > On 2013-Jan-27 14:31:56 -, Steven Hartland > > wrote: > > >- Original Message - > > >From: "Ulrich Spörlein" > > >> I want to transplant my old zpool tank from a 1TB drive to a new 2TB > > >> drive, but *not* use dd(1) or any other cloning mechanism, as the pool > > >> was very full very often and is surely severely fragmented. > > > > > >Cant you just drop the disk in the original machine, set it as a mirror > > >then once the mirror process has completed break the mirror and remove > > >the 1TB disk. > > > > That will replicate any fragmentation as well. "zfs send | zfs recv" > > is the only (current) way to defragment a ZFS pool. It's not obvious to me why "zpool replace" (or doing it manually) would replicate the fragmentation. > But are you then also supposed to be able send incremental snapshots to > a third pool from the pool that you just cloned? Yes. > I did the zpool replace now over night, and it did not remove the old > device yet, as it found cksum errors on the pool: > > root@coyote:~# zpool status -v > pool: tank > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. >see: http://illumos.org/msg/ZFS-8000-8A > scan: resilvered 873G in 11h33m with 24 errors on Mon Jan 28 09:45:32 2013 > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 027 > replacing-0 ONLINE 0 061 > da0.eliONLINE 0 061 > ada1.eli ONLINE 0 061 > > errors: Permanent errors have been detected in the following files: > > > tank/src@2013-01-17:/.svn/pristine/8e/8ed35772a38e0fec00bc1cbc2f05480f4fd4759b.svn-base [...] > tank/ncvs@2013-01-17:/ports/textproc/uncrustify/distinfo,v > > Interestingly, these only seem to affect the snapshot, and I'm now > wondering if that is the problem why the backup pool did not accept the > next incremental snapshot from the new pool. I doubt that. My expectation would be that it only prevents the "zfs send" to finish successfully. BTW, you could try reading the files to be sure that the checksum problems are permanent and not just temporary USB issues. > How does the receiving pool known that it has the correct snapshot to > store an incremental one anyway? Is there a toplevel checksum, like for > git commits? How can I display and compare that? Try zstreamdump: fk@r500 ~ $sudo zfs send -i @2013-01-24_20:48 tank/etc@2013-01-26_21:14 | zstreamdump | head -11 BEGIN record hdrtype = 1 features = 4 magic = 2f5bacbac creation_time = 5104392a type = 2 flags = 0x0 toguid = a1eb3cfe794e675c fromguid = 77fb8881b19cb41f toname = tank/etc@2013-01-26_21:14 END checksum = 1047a3f2dceb/67c999f5e40ecf9/442237514c1120ed/efd508ab5203c91c fk@r500 ~ $sudo zfs send lexmark/backup/r500/tank/etc@2013-01-24_20:48 | zstreamdump | head -11 BEGIN record hdrtype = 1 features = 4 magic = 2f5bacbac creation_time = 51018ff4 type = 2 flags = 0x0 toguid = 77fb8881b19cb41f fromguid = 0 toname = lexmark/backup/r500/tank/etc@2013-01-24_20:48 END checksum = 1c262b5ffe935/78d8a68e0eb0c8e7/eb1dde3bd923d153/9e0829103649ae22 Fabian signature.asc Description: PGP signature
Re: Trouble with recent auto-tuning changes
On 01/28/2013 08:22, Ian Lepore wrote: > On Mon, 2013-01-28 at 00:09 -0600, Alan Cox wrote: >> On Sun, Jan 27, 2013 at 12:11 PM, Ian Lepore wrote: >> >>> I ran into a panic while attempting to un-tar a large file on a >>> DreamPlug (arm-based system) running -current. The source and dest of >>> the un-tar is the root filesystem on sdcard, and I get this: >>> >>> panic: kmem_malloc(4096): kmem_map too small: 12582912 total allocated >>> >>> Just before the panic I see the tar process get hung in a "nokva" wait. >>> 12582912 is the value of VM_KMEM_SIZE from arm/include/vmparam.h. >>> >>> In r245575 the init order for mbuf limits was changed from >>> SI_SUB_TUNABLES to SI_SUB_KMEM so that mbuf limits could be based on the >>> results of sizing kernel memory. Unfortunately, the process of sizing >>> kernel memory relies on the mbuf limits; in kmeminit(): >>> >>> vm_kmem_size = VM_KMEM_SIZE + nmbclusters * PAGE_SIZE; >>> >>> Since r245575, nmbclusters is zero when this line of code runs. If I >>> manually plugin "32768" (the number tunable_mbinit() comes up with for >>> this platform) in that line, the panic stops happening. >>> >>> So we've got two problems here... one is the circular dependency in >>> calculating the mbuf limits. The other is the fact that some >>> non-trivial amount of kernel memory we're allowing for mbufs is actually >>> being used for other things. That is, if my system was actually using >>> all the mbufs that tunable_mbinit() allowed for, then this panic while >>> untarring a huge file would still have happened. >>> >>> >> All of this is factually correct. However, it's a red herring. The real >> problem is that arm, unlike every other architecture in the tree, does not >> enable auto-sizing of the kmem map based on the physical memory size. >> Specifically, you'll find VM_KMEM_SIZE_SCALE defined in >> "arch"/include/vmparam.h on every other architecture, just not on arm. >> This auto-sizing overrides the value of VM_KMEM_SIZE. >> > Aha. I'll investigate what other architectures do with that and try to > get the same thing going for arm. > i386 or (32-bit) MIPS would be the most similar. Also, I would encourage you to look for other definitions that those architectures have that arm doesn't. As physical memory sizes continue to grow on arm-based systems, they may require other changes in vmparam.h and the machine-dependent param.h that were made on those other architectures year ago. If you have any questions about any of the definitions, feel free to e-mail me. Alan P.S. When I get a little more free time, I intend to get in touch with Andre to address the apparent circular dependency. For now just know that unless that circular dependency is combined with a lack of kmem map auto-sizing, like arm, it's basically harmless. ___ 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: acpi resume related patch
On Saturday, January 26, 2013 9:18:57 am Andriy Gapon wrote: > on 25/01/2013 18:08 Andriy Gapon said the following: > > on 25/01/2013 15:51 John Baldwin said the following: > >> On Friday, January 25, 2013 3:43:33 am Andriy Gapon wrote: > >>> > >>> If you have ACPI suspend/resume working, if it used to work but stopped > >>> working > >>> at some time, if it never worked, but you are still hoping, could you > >>> please > >>> test the following patch and report back? > >>> > >>> http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch > >> > >> This will break systems not using the local APIC since you unconditionally > >> call lapic_setup() on resume.This was part of the feature of the previous > >> code that by using a dummy pic it could register it only when the local > >> APIC > >> was used. > > > > Thank you for drawing my attention to this. I will try to fix this issue. > > The reason I want to remove lapic from 'pics' (and I already described it > > in a > > private email) is that Local APIC is a special kind of PIC. It's already > > explicitly initialized by APs. Putting it into 'pics' tailq just > > obfuscates the code. > > > >> It should also be registered before any of the I/O APICs are by > >> the design of the local_apic.c code. > > > > In fact, as I see in the code, Local APIC is always registered _after_ I/O > > APICs. > > And thus lapic_resume was called after ioapic_resume. > > Additionally, currently there is no synchronization between initialization > > of > > Local APICs on APs and initialization of I/O APICs at the wakeup/resume > > time. > > > > Here is an updated version of the patch: > http://people.freebsd.org/~avg/acpi-apic-wakeup.2.patch > > John, > could you please review the PIC-related part? I decided to go back to the > current approach while fixing the suspend/resume ordering and also order of > registration for Local APIC. Must say that XEN special casing makes > apic_setup_io a little bit untidy. > > Additionally this patch fixes AP Local APIC initialization ordering on i386. > In the original patch I changed only amd64 code. This looks good to me. -- John Baldwin ___ 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: some questions on kern_linker and pre-loaded modules
On Saturday, January 26, 2013 6:52:01 am Andriy Gapon wrote: > > I. > It seems that linker_preload checks a module for being a duplicate module > only > if the module has MDT_VERSION. > > This is probably designed to allow different version of the same module to > co-exist (for some definition of co-exist)? Yes, that is likely true, but it is a bit dubious. > But, OTOH, this doesn't work well if the module is version-less (no > MODULE_VERSION in the code) and is pre-loaded twice (e.g. once in kernel and > once in a preloaded file). Yes. > At present a good example of this is zfsctrl module, which could be present > both > in kernel (options ZFS) and in zfs.ko. > > I haven't thought about any linker-level resolution for this issue. > I've just tried a plug the ZFS hole for now. I think we should require all modules declared by DECLARE_MODULE() to have a version. You might be able to enforce that by failing to register a linker file if it contains any modules that do not include at least one version metadata note in the same linker file. You could check this before running the MOD_LOAD handlers (though after running SYSINITs). Truly fixing this would mean making module data true metadata that is parsed by the linker rather than having it all provided to the kernel via SYSINITs so that you could evaluate this before running SYSINITs. That is a larger project however. I think your fix for zfsctrl is correct. > II. > It seems that linker_file_register_modules() for the kernel is called after > linker_file_register_modules() is called for all the pre-loaded files. > linker_file_register_modules() for the kernel is called from > linker_init_kernel_modules via SYSINIT(SI_SUB_KLD, SI_ORDER_ANY) and that > happens after linker_preload() which is executed via SYSINIT(SI_SUB_KLD, > SI_ORDER_MIDDLE). > > Perhaps this is designed to allow modules in the preloaded files to override > modules compiled into the kernel? Yes, likely so. > But this doesn't seem to work well. > Because modules from the kernel are not registered yet, > linker_file_register_modules() would be successful for the duplicate modules > in > a preloaded file and thus any sysinits present in the file will also be > registered. > So, if the module is present both in the kernel and in the preloaded file and > the module has a module event handler (modeventhand_t), then the handler will > registered and called twice. Yes, I think it is too hard at present to safely allow a linker file to override the same module in a kernel, so the duplicate linker file should just be rejected entirely. I'm not sure if your change is completely correct for that. -- John Baldwin ___ 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: Fast gettimeofday(2) and static linking
On Mon, Jan 28, 2013 at 04:45:17PM +0100, Marius Strobl wrote: > On Fri, Jan 25, 2013 at 02:35:54PM +0200, Konstantin Belousov wrote: > > Bruce Evans reported that statically linked binaries on HEAD an stable/9 > > use the syscall for gettimeofday(2) and clock_gettime(2). Apparently, this > > is due to my use of the weak reference to the __vdso* symbols in the > > libc implementations. > > > > Patch below reworks the __vdso* attributes to only make the symbols > > weak, but keep the references strong. Since I have to add a stub for > > each architecture, I would like to ask non-x86 machines owners to test > > the patch. > > > > Hi Konstantin, > > what's the appropriate way to test this? Please rebuild the world with the patch and check that gettimeofday(2) still works on your architecture, both for the static and dynamic binaries. I think that just booting multiuser is enough. pgp8FAd4XY1qW.pgp Description: PGP signature
Re: mounting root from NFS via ROOTDEVNAME
Hi, On Jan 28, 2013, at 16:23, Ian Lepore wrote: > Remove the BOOTP_NFSROOT option, it tells the bootp/dhcp code to keep > querying the server until a root path is delivered. Without it, the > ROOTDEVNAME option should get used (and I think even override a path > from the server, if it delivers one). no luck: em4: link state changed to UP Received DHCP Offer packet on em4 from 0.0.0.0 (accepted) (no root path) Sending DHCP Request packet from interface em4 (XX:XX:XX:XX:XX:XX) Received DHCP Ack packet on em4 from 0.0.0.0 (accepted) (no root path) DHCP/BOOTP timeout for server 255.255.255.255 Received DHCP Ack packet on em4 from 0.0.0.0 (accepted) (no root path) DHCP/BOOTP timeout for server 255.255.255.255 ... The only visible difference is that the first "Received DHCP Ack packet" line is now printed only once, instead of twice as in the previous log. Lars ___ 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: Fast gettimeofday(2) and static linking
On Fri, Jan 25, 2013 at 02:35:54PM +0200, Konstantin Belousov wrote: > Bruce Evans reported that statically linked binaries on HEAD an stable/9 > use the syscall for gettimeofday(2) and clock_gettime(2). Apparently, this > is due to my use of the weak reference to the __vdso* symbols in the > libc implementations. > > Patch below reworks the __vdso* attributes to only make the symbols > weak, but keep the references strong. Since I have to add a stub for > each architecture, I would like to ask non-x86 machines owners to test > the patch. > Hi Konstantin, what's the appropriate way to test this? Marius ___ 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: mounting root from NFS via ROOTDEVNAME
On Mon, 2013-01-28 at 15:13 +, Eggert, Lars wrote: > Hi, > > I'm trying to netboot a system where the root device is specified in the > kernel via ROOTDEVNAME: > > options BOOTP > options BOOTP_NFSROOT > options BOOTP_NFSV3 > options BOOTP_COMPAT > options BOOTP_WIRED_TO=em4 > options ROOTDEVNAME=\"nfs:10.11.12.13:/usr/home/elars/dst\" > > I was under the assumption that specifying a ROOTDEVNAME in the kernel config > would override the "root-path" option in DHCP, or at least take effect when > "root-path" wasn't provided via DHCP, but that doesn't seem to be the case. > The system configures it's address correctly over em4, but then enters a loop: > > em4: link state changed to UP > Received DHCP Offer packet on em4 from 0.0.0.0 (accepted) (no root path) > Sending DHCP Request packet from interface em4 (XX:XX:XX:XX:XX:XX) > Received DHCP Ack packet on em4 from 0.0.0.0 (accepted) (no root path) > Received DHCP Ack packet on em4 from 0.0.0.0 (accepted) (no root path) > DHCP/BOOTP timeout for server 255.255.255.255 > Received DHCP Ack packet on em4 from 0.0.0.0 (accepted) (no root path) > DHCP/BOOTP timeout for server 255.255.255.255 > ... > > If I hand out a root path via DHCP the system boots fine, but the idea here > is to be able to boot different root devices without needing to diddle > dhcpd.conf. Can this be done? Remove the BOOTP_NFSROOT option, it tells the bootp/dhcp code to keep querying the server until a root path is delivered. Without it, the ROOTDEVNAME option should get used (and I think even override a path from the server, if it delivers one). -- Ian ___ 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"
mounting root from NFS via ROOTDEVNAME
Hi, I'm trying to netboot a system where the root device is specified in the kernel via ROOTDEVNAME: options BOOTP options BOOTP_NFSROOT options BOOTP_NFSV3 options BOOTP_COMPAT options BOOTP_WIRED_TO=em4 options ROOTDEVNAME=\"nfs:10.11.12.13:/usr/home/elars/dst\" I was under the assumption that specifying a ROOTDEVNAME in the kernel config would override the "root-path" option in DHCP, or at least take effect when "root-path" wasn't provided via DHCP, but that doesn't seem to be the case. The system configures it's address correctly over em4, but then enters a loop: em4: link state changed to UP Received DHCP Offer packet on em4 from 0.0.0.0 (accepted) (no root path) Sending DHCP Request packet from interface em4 (XX:XX:XX:XX:XX:XX) Received DHCP Ack packet on em4 from 0.0.0.0 (accepted) (no root path) Received DHCP Ack packet on em4 from 0.0.0.0 (accepted) (no root path) DHCP/BOOTP timeout for server 255.255.255.255 Received DHCP Ack packet on em4 from 0.0.0.0 (accepted) (no root path) DHCP/BOOTP timeout for server 255.255.255.255 ... If I hand out a root path via DHCP the system boots fine, but the idea here is to be able to boot different root devices without needing to diddle dhcpd.conf. Can this be done? Thanks, Lars ___ 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: Trouble with recent auto-tuning changes
On Mon, 2013-01-28 at 00:09 -0600, Alan Cox wrote: > On Sun, Jan 27, 2013 at 12:11 PM, Ian Lepore wrote: > > > I ran into a panic while attempting to un-tar a large file on a > > DreamPlug (arm-based system) running -current. The source and dest of > > the un-tar is the root filesystem on sdcard, and I get this: > > > > panic: kmem_malloc(4096): kmem_map too small: 12582912 total allocated > > > > Just before the panic I see the tar process get hung in a "nokva" wait. > > 12582912 is the value of VM_KMEM_SIZE from arm/include/vmparam.h. > > > > In r245575 the init order for mbuf limits was changed from > > SI_SUB_TUNABLES to SI_SUB_KMEM so that mbuf limits could be based on the > > results of sizing kernel memory. Unfortunately, the process of sizing > > kernel memory relies on the mbuf limits; in kmeminit(): > > > > vm_kmem_size = VM_KMEM_SIZE + nmbclusters * PAGE_SIZE; > > > > Since r245575, nmbclusters is zero when this line of code runs. If I > > manually plugin "32768" (the number tunable_mbinit() comes up with for > > this platform) in that line, the panic stops happening. > > > > So we've got two problems here... one is the circular dependency in > > calculating the mbuf limits. The other is the fact that some > > non-trivial amount of kernel memory we're allowing for mbufs is actually > > being used for other things. That is, if my system was actually using > > all the mbufs that tunable_mbinit() allowed for, then this panic while > > untarring a huge file would still have happened. > > > > > All of this is factually correct. However, it's a red herring. The real > problem is that arm, unlike every other architecture in the tree, does not > enable auto-sizing of the kmem map based on the physical memory size. > Specifically, you'll find VM_KMEM_SIZE_SCALE defined in > "arch"/include/vmparam.h on every other architecture, just not on arm. > This auto-sizing overrides the value of VM_KMEM_SIZE. > Aha. I'll investigate what other architectures do with that and try to get the same thing going for arm. -- Ian > > > > I arrive at the latter conclusion based on the fact that this panic > > happens even if no network interfaces (other than lo0) are configured. > > That is, nmbclusters == 0 is a reasonable approximation of my need for > > network mbufs. So something in the system needs to be taken into > > account when sizing kernel memory to allow for whatever it is about > > untarring a huge file that eats kernel memory (buffer cache?). > > > > I can easily reproduce this if you need me to gather any specific info. > > > > -- Ian > > > > > > ___ > > 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-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: acpi resume related patch
On Mon, Jan 28, 2013 at 03:40:18PM +0200, Andriy Gapon wrote: > on 28/01/2013 15:24 Pawel Jakub Dawidek said the following: > > On Mon, Jan 28, 2013 at 03:07:59PM +0200, Andriy Gapon wrote: > >> on 28/01/2013 14:45 Pawel Jakub Dawidek said the following: > >>> FYI, it doesn't change anything for me. Resume seems to work, but > >>> suspend just reset my laptop. > >> > >> Sorry, I am a little confused by this description. > >> How can you know that resume works if suspend resets the machine? > > > > Because everything turns off, including display and the power led starts > > to "throb" and it does that until I try to resume it. > > > > Ah, so "suspend" and "resume" got accidentally reverted... > I see, thank you for the report. I just noticed that, yes, sorry. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpZdzy5Vr92A.pgp Description: PGP signature
Re: devel/gobject-introspection failure on ARM
On Sun, 27 Jan 2013 10:57:19 -0500 George Mitchell wrote: > System: Raspberry Pi > uname: r245840M (Alie Tan's image from 25 January) > ports: svnversion 308518 > > Build dies with message "sizeof(ArrayTypeBlob) is expected to be 8 but > is 12." (Complete build log attached.) I made a naive attempt to fix > it by rearranging the order of the structure members, but obviously I > don't understand structure packing on the ARM and it didn't help. It > also didn't get rid of the huge number of "cast increases required > alignment of target type" warnings. > > I note we're at version 0.10.8 of this package, but upstream is at > 1.34.2. (It requires glib 2.34.1, though, and we're only at 2.28.8). > > What's the best way to proceed? -- George Mitchell Hi, It can be fixed by just change gitypelib.c: CHECK_SIZE (ArrayTypeBlob, 8); to gitypelib.c: CHECK_SIZE (ArrayTypeBlob, 12); But problem not in gobject-introspection, but in old ARM ABI. I was ask andrew@, and he test it with ARM EABI, and it compiled fine with size 8. So if somebody will fix it, please #ifdef that fix to make it only with old ARM ABI. Or, better help with EABI testing :-D Thanks! WBW -- Aleksandr Rybalko ___ 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: acpi resume related patch
on 28/01/2013 15:24 Pawel Jakub Dawidek said the following: > On Mon, Jan 28, 2013 at 03:07:59PM +0200, Andriy Gapon wrote: >> on 28/01/2013 14:45 Pawel Jakub Dawidek said the following: >>> FYI, it doesn't change anything for me. Resume seems to work, but >>> suspend just reset my laptop. >> >> Sorry, I am a little confused by this description. >> How can you know that resume works if suspend resets the machine? > > Because everything turns off, including display and the power led starts > to "throb" and it does that until I try to resume it. > Ah, so "suspend" and "resume" got accidentally reverted... I see, thank you for the report. -- 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"
Re: acpi resume related patch
On Mon, Jan 28, 2013 at 03:07:59PM +0200, Andriy Gapon wrote: > on 28/01/2013 14:45 Pawel Jakub Dawidek said the following: > > FYI, it doesn't change anything for me. Resume seems to work, but > > suspend just reset my laptop. > > Sorry, I am a little confused by this description. > How can you know that resume works if suspend resets the machine? Because everything turns off, including display and the power led starts to "throb" and it does that until I try to resume it. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgp9FvUaKpvfH.pgp Description: PGP signature
Re: acpi resume related patch
on 28/01/2013 14:45 Pawel Jakub Dawidek said the following: > FYI, it doesn't change anything for me. Resume seems to work, but > suspend just reset my laptop. Sorry, I am a little confused by this description. How can you know that resume works if suspend resets the 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"
Re: acpi resume related patch
On Sat, Jan 26, 2013 at 04:18:57PM +0200, Andriy Gapon wrote: > on 25/01/2013 18:08 Andriy Gapon said the following: > > on 25/01/2013 15:51 John Baldwin said the following: > >> On Friday, January 25, 2013 3:43:33 am Andriy Gapon wrote: > >>> > >>> If you have ACPI suspend/resume working, if it used to work but stopped > >>> working > >>> at some time, if it never worked, but you are still hoping, could you > >>> please > >>> test the following patch and report back? > >>> > >>> http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch > >> > >> This will break systems not using the local APIC since you unconditionally > >> call lapic_setup() on resume.This was part of the feature of the previous > >> code that by using a dummy pic it could register it only when the local > >> APIC > >> was used. > > > > Thank you for drawing my attention to this. I will try to fix this issue. > > The reason I want to remove lapic from 'pics' (and I already described it > > in a > > private email) is that Local APIC is a special kind of PIC. It's already > > explicitly initialized by APs. Putting it into 'pics' tailq just > > obfuscates the code. > > > >> It should also be registered before any of the I/O APICs are by > >> the design of the local_apic.c code. > > > > In fact, as I see in the code, Local APIC is always registered _after_ I/O > > APICs. > > And thus lapic_resume was called after ioapic_resume. > > Additionally, currently there is no synchronization between initialization > > of > > Local APICs on APs and initialization of I/O APICs at the wakeup/resume > > time. > > > > Here is an updated version of the patch: > http://people.freebsd.org/~avg/acpi-apic-wakeup.2.patch FYI, it doesn't change anything for me. Resume seems to work, but suspend just reset my laptop. I unload all driver modules (including if_em, sound, nvidia, usb). The only driver I keep is ahci. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpeGRk3y8xZd.pgp Description: PGP signature
Re: ZFS + usb in trouble? [PATCHED]
Roger. This is it. Thanks! On 28.01.2013, at 3:05, Hans Petter Selasky wrote: > Hi, > > Can you try this patch: > > http://svnweb.freebsd.org/changeset/base/245995 > > It fixes the issue for me. Looks like I overlooked a corner case computing > the > DMA addresses. Thanks for reporting! > > zpool status > pool: tank > state: ONLINE > scan: none requested > config: > > NAMESTATE READ WRITE CKSUM > tankONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > da0 ONLINE 0 0 0 > da1 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > > errors: No known data errors > > > --HPS > ___ > 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-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 10, booting from USB failes
Hi, I have several thumb drives and had disks. To be able to exchange the hard disks, all devices are bootable. I have tested the setup some time ago and it did not give me problems to boot from the external media via USB. I will take two hard disks as an example: => 63 976773105 ada0 MBR (465G) 63 1953- free - (976k) 2016 976771152 1 freebsd (465G) =>0 976771152 ada0s1 BSD (465G) 0 1024 1 freebsd-ufs (4.9G) 1024 32768000 2 freebsd-swap (15G) 43008000 1024 4 freebsd-ufs (4.9G) 53248000 1024 5 freebsd-ufs (4.9G) 63488000 10240 6 freebsd-ufs (48G) 165888000 810883144 7 freebsd-ufs (386G) 976771144 8 - free - (4.0k) => 34 976773098 da0 GPT (465G) 341281 freebsd-boot (64k) 162 6 - free - (3.0k) 168 104857602 freebsd-ufs (5.0G) 10485928 335544323 freebsd-swap (16G) 44040360 104857604 freebsd-ufs (5.0G) 54526120 104857605 freebsd-ufs (5.0G) 65011880 1048576006 freebsd-ufs (50G) 169869480 8069036487 freebsd-ufs (384G) 976773128 4 - free - (2.0k) The system started from ada0. It fails to start from da0 now. Before I switch the disks, does anybody know of something which causes the problem? If this matters, I did this with an X220 ThinkPad. 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"
Re: acpi resume related patch
On Mon, Jan 28, 2013 at 10:16:43AM +0200, Andriy Gapon wrote: > on 28/01/2013 04:52 Glen Barber said the following: > > On Fri, Jan 25, 2013 at 10:43:33AM +0200, Andriy Gapon wrote: > >> > >> If you have ACPI suspend/resume working, if it used to work but stopped > >> working > >> at some time, if it never worked, but you are still hoping, could you > >> please > >> test the following patch and report back? > >> > >> http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch > >> > > > > FWIW, I am (very happy) to report my laptop has resumed for longer than > > 10 seconds for the first time ever. > > Just to clarify - you mean that previously it would try to shutdown right > after > resume? Or something else? > Your description is probably the most accurate way to describe post-resume behavior. Glen pgpFUO2RY6Sek.pgp Description: PGP signature
Re: devel/gobject-introspection failure on ARM
On 01/28/13 05:55, Koop Mast wrote: On Sun, 2013-01-27 at 10:57 -0500, George Mitchell wrote: System: Raspberry Pi uname: r245840M (Alie Tan's image from 25 January) ports: svnversion 308518 Build dies with message "sizeof(ArrayTypeBlob) is expected to be 8 but is 12." (Complete build log attached.) I made a naive attempt to fix it by rearranging the order of the structure members, but obviously I don't understand structure packing on the ARM and it didn't help. It also didn't get rid of the huge number of "cast increases required alignment of target type" warnings. I note we're at version 0.10.8 of this package, but upstream is at 1.34.2. (It requires glib 2.34.1, though, and we're only at 2.28.8). What's the best way to proceed? -- George Mitchell I'm currently in the process of making a patch [1] for the ports tree for glib 2.34.3 and gobject-introspection 1.34.1.1. If you want to give this a shot on ARM. Please note that the patch is WIP. Not all ports have been tested yet. -Koop [1] http://people.freebsd.org/~kwm/glib-2.34_1.diff Thanks! I'll try this if I have time later today. -- George ___ 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: devel/gobject-introspection failure on ARM
On Sun, 2013-01-27 at 10:57 -0500, George Mitchell wrote: > System: Raspberry Pi > uname: r245840M (Alie Tan's image from 25 January) > ports: svnversion 308518 > > Build dies with message "sizeof(ArrayTypeBlob) is expected to be 8 but > is 12." (Complete build log attached.) I made a naive attempt to fix > it by rearranging the order of the structure members, but obviously I > don't understand structure packing on the ARM and it didn't help. It > also didn't get rid of the huge number of "cast increases required > alignment of target type" warnings. > > I note we're at version 0.10.8 of this package, but upstream is at > 1.34.2. (It requires glib 2.34.1, though, and we're only at 2.28.8). > > What's the best way to proceed? -- George Mitchell I'm currently in the process of making a patch [1] for the ports tree for glib 2.34.3 and gobject-introspection 1.34.1.1. If you want to give this a shot on ARM. Please note that the patch is WIP. Not all ports have been tested yet. -Koop [1] http://people.freebsd.org/~kwm/glib-2.34_1.diff ___ 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: Zpool surgery
On Monday 28 January 2013 11:29:35 Ulrich Spörlein wrote: > Thanks, will do. Is it supposed to fix this? > > root@coyote:~# geli attach da1 > Segmentation fault > Exit 139 > root@coyote:~# geli status > Name Status Components > gpt/swap.eli ACTIVE gpt/swap > da0.eli ACTIVE da0 > ada1.eli ACTIVE ada1 > > > As you can see geli worked fine, but at some point it stops working and > can no longer attach new volumes. I don't know. If this doesn't happen on 9-stable, yes. --HPS ___ 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: Zpool surgery
On Monday 28 January 2013 11:29:35 Ulrich Spörlein wrote: > What's with the 32 vs 64 byte context size? And do you know of any problems > with the Intel controller? These are two different USB DMA descriptor layouts. --HPS ___ 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: Zpool surgery
On Sun, 2013-01-27 at 20:13:24 +0100, Hans Petter Selasky wrote: > On Sunday 27 January 2013 20:08:06 Ulrich Spörlein wrote: > > I dug out an old ATA-to-USB case and will use that to attach the old > > tank to the new machine and then have a try at this zpool replace thing. > > If you are using -current you might want this patch first: > > http://svnweb.freebsd.org/changeset/base/245995 Thanks, will do. Is it supposed to fix this? root@coyote:~# geli attach da1 Segmentation fault Exit 139 root@coyote:~# geli status Name Status Components gpt/swap.eli ACTIVE gpt/swap da0.eli ACTIVE da0 ada1.eli ACTIVE ada1 As you can see geli worked fine, but at some point it stops working and can no longer attach new volumes. I'm also seeing interrupt storms for USB devices, when I plug in the drives into xhci0 instead of xhci1 (but this needs more testing, first I need to get that damn zpool moved) xhci0: mem 0xe072-0xe072 irq 21 at device 20.0 on pci0 xhci0: 32 byte context size. usbus0 on xhci0 xhci1: mem 0xe050-0xe050,0xe051-0xe0511fff irq 19 at device 0.0 on pci5 xhci1: 64 byte context size. usbus2 on xhci1 xhci0@pci0:0:20:0: class=0x0c0330 card=0x72708086 chip=0x1e318086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '7 Series/C210 Series Chipset Family USB xHCI Host Controller' class = serial bus subclass = USB xhci1@pci0:5:0:0: class=0x0c0330 card=0x chip=0x8241104c rev=0x02 hdr=0x00 vendor = 'Texas Instruments' device = 'TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller' class = serial bus subclass = USB What's with the 32 vs 64 byte context size? And do you know of any problems with the Intel controller? 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"
libproc buffer corruption patch
Please check in this obvious patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=175648 MFC to 9.X, please. Thanks, Yuri ___ 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: Zpool surgery
On Mon, 2013-01-28 at 07:11:40 +1100, Peter Jeremy wrote: > On 2013-Jan-27 14:31:56 -, Steven Hartland > wrote: > >- Original Message - > >From: "Ulrich Spörlein" > >> I want to transplant my old zpool tank from a 1TB drive to a new 2TB > >> drive, but *not* use dd(1) or any other cloning mechanism, as the pool > >> was very full very often and is surely severely fragmented. > > > >Cant you just drop the disk in the original machine, set it as a mirror > >then once the mirror process has completed break the mirror and remove > >the 1TB disk. > > That will replicate any fragmentation as well. "zfs send | zfs recv" > is the only (current) way to defragment a ZFS pool. But are you then also supposed to be able send incremental snapshots to a third pool from the pool that you just cloned? I did the zpool replace now over night, and it did not remove the old device yet, as it found cksum errors on the pool: root@coyote:~# zpool status -v pool: tank state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: resilvered 873G in 11h33m with 24 errors on Mon Jan 28 09:45:32 2013 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 027 replacing-0 ONLINE 0 061 da0.eliONLINE 0 061 ada1.eli ONLINE 0 061 errors: Permanent errors have been detected in the following files: tank/src@2013-01-17:/.svn/pristine/8e/8ed35772a38e0fec00bc1cbc2f05480f4fd4759b.svn-base tank/src@2013-01-17:/.svn/pristine/4f/4febd82f50bd408f958d4412ceea50cef48fe8f7.svn-base tank/src@2013-01-17:/sys/dev/mvs/mvs_soc.c tank/src@2013-01-17:/secure/usr.bin/openssl/man/pkcs8.1 tank/src@2013-01-17:/.svn/pristine/ab/ab1efecf2c0a8f67162b2ed760772337017c5a64.svn-base tank/src@2013-01-17:/.svn/pristine/90/907580a473b00f09b01815a52251fbdc3e34e8f6.svn-base tank/src@2013-01-17:/sys/dev/agp/agpreg.h tank/src@2013-01-17:/sys/dev/isci/scil/scic_sds_remote_node_context.h tank/src@2013-01-17:/.svn/pristine/a8/a8dfc65edca368c5d2af3d655859f25150795bc5.svn-base tank/src@2013-01-17:/contrib/llvm/utils/TableGen/DAGISelMatcher.cpp tank/src@2013-01-17:/contrib/tcpdump/print-babel.c tank/src@2013-01-17:/.svn/pristine/30/30ef0f53aa09a5185f55f4ecac842dbc13dab8fd.svn-base tank/src@2013-01-17:/.svn/pristine/cb/cb32411a6873621a449b24d9127305b2ee6630e9.svn-base tank/src@2013-01-17:/.svn/pristine/03/030d211b1e95f703f9a61201eed63efdbb8e41c0.svn-base tank/src@2013-01-17:/.svn/pristine/27/27f1181d33434a72308de165c04202b6159d6ac2.svn-base tank/src@2013-01-17:/lib/libpam/modules/pam_exec/pam_exec.c tank/src@2013-01-17:/contrib/llvm/include/llvm/PassSupport.h tank/src@2013-01-17:/.svn/pristine/90/90f818b5f897f26c7b301c1ac2d0ce0d3eaef28d.svn-base tank/src@2013-01-17:/sys/vm/vm_pager.c tank/src@2013-01-17:/.svn/pristine/5e/5e9331052e8c2e0fa5fd8c74c4edb04058e3b95f.svn-base tank/src@2013-01-17:/.svn/pristine/1d/1d5d6e75cfb77e48e4711ddd10148986392c4fae.svn-base tank/src@2013-01-17:/.svn/pristine/c5/c55e964c62ed759089c4bf5e49adf6e49eb59108.svn-base tank/src@2013-01-17:/crypto/openssl/crypto/cms/cms_lcl.h tank/ncvs@2013-01-17:/ports/textproc/uncrustify/distinfo,v Interestingly, these only seem to affect the snapshot, and I'm now wondering if that is the problem why the backup pool did not accept the next incremental snapshot from the new pool. How does the receiving pool known that it has the correct snapshot to store an incremental one anyway? Is there a toplevel checksum, like for git commits? How can I display and compare that? 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"
Re: acpi resume related patch
on 28/01/2013 04:52 Glen Barber said the following: > On Fri, Jan 25, 2013 at 10:43:33AM +0200, Andriy Gapon wrote: >> >> If you have ACPI suspend/resume working, if it used to work but stopped >> working >> at some time, if it never worked, but you are still hoping, could you please >> test the following patch and report back? >> >> http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch >> > > FWIW, I am (very happy) to report my laptop has resumed for longer than > 10 seconds for the first time ever. Just to clarify - you mean that previously it would try to shutdown right after resume? Or something else? > root@nucleus:~ # uname -a > FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #56 r245748M: Sun Jan > 27 21:39:55 EST 2013 root@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64 > > root@nucleus:~ # kldstat > Id Refs AddressSize Name > 1 60 0x8020 dfc0d8 kernel > 21 0x80ffd000 21cc80 zfs.ko > 32 0x8121a000 5e08 opensolaris.ko > 41 0x8122 1fc48geom_eli.ko > 52 0x8124 138dd0 linux.ko > 61 0x81379000 2a70 coretemp.ko > 71 0x8137c000 70e8 acpi_video.ko > 81 0x81384000 6668 sem.ko > 91 0x8138b000 8b10 acpi_asus.ko > 101 0x81394000 4a18 aesni.ko > 111 0x81412000 28805pf.ko > 121 0x8143b000 5f590i915kms.ko > 131 0x8149b000 13f2 iicbb.ko > 144 0x8149d000 136f iicbus.ko > 151 0x8149f000 df9 iic.ko > 162 0x814a ab34 agp.ko > 171 0x814ab000 2dce9drm2.ko > 181 0x814d9000 25b linux_adobe.ko > > Current uptime post-resume is about 5 minutes. > > Glen > -- 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"
