Unable to resume amd64 machine
Hi, I've trying to suspend/resume an amd64 machine. The machine is a fujitsu S710 laptop running: FreeBSD 10.0-CURRENT #4 r237339=e61ad3a-dirty: Sat Jun 23 17:12:58 CEST 2012 I did the tests in the following conditions: - No X running. Everything in console. The machine has an Intel video card, but I did the tests without the i915kms module. - I removed all the modules I could from the kernel. The behavior is basically the machine seems to suspend fine (I see the power led blinking) but when resuming it freezes hard. I see the disk spinning for a while and then it stops. I can't ssh to it, I can't use the keyboard at all so I can issue no command at all. I've tried stripping down the kernel (everything is out except if_ath, em and usb stack). No pccard, no sdhci, no sound, no cuse4bsd, no usb hid devices (I'm using uhidd for hid devices), no acpi_video or acpi_fujitsu there but the same result. I tried enabling debug.acpi.resume_beep=1. When doing this, the laptop beeped like crazy. I tried using the serial console on the laptop. I saw the suspend process taking down some usb devices. Resume showed nothing on the serial console. With sysctl debug.acpi.suspend_bounce=1, the machine stayed alive (this is expected) but the screen went blank (this I think isn't expected). The video never came back. The three-finger-salute rebooted the machine. With acpi.reset_video I got no result. Disabling devices in the BIOS (removing wifi, bluetooth, webcam, etc ...) didn't bring me further. -- --- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Departament d'Enginyeria Telemàtica O O O Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona ___ freebsd-a...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org ___ 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: GPU_KMS still not working CURRENT X220
On Thu, Jun 28, 2012 at 8:15 PM, Kevin Oberman kob6...@gmail.com wrote: On Thu, Jun 28, 2012 at 8:45 AM, Andrey Fesenko f0and...@gmail.com wrote: I have lenovo thinkpad x220 # uname -a FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r237683: Thu Jun 28 08:41:40 MSK 2012 root@bsdx220:/usr/obj/usr/src/sys/MY_INTEL amd64 # pciconf -lvb 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 bar [10] = type Memory, range 64, base 0xf000, size 4194304, enabled bar [18] = type Prefetchable Memory, range 64, base 0xe000, size 268435456, enabled bar [20] = type I/O Port, range 32, base 0x6000, size 64, enabled After # kldload i915kms screen is black, if # kldunload i915kms panic Don't do this. It has been clearly stated that i915kms my not be unloaded and that attempting to unload it WILL panic the system. Also, don't load i945kms. This WILL lock up the system with a blank screen. The modules required are autoloaded during Xorg initialization. Just make absolutely sure that you have the latest version of xf-video-intel. (If you installed a rather early version of the KMS code, it is possible that you have two xf-video.intel* ports in your tree, thought I don't expect this is the case. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com Thank you so much, it worked :) necessary as it is written in the wiki ___ 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
ia64 r235474 panic preceded by LOR : exclusive sleep mutex vnode interlock (vnode interlock)panic: blockable sleep lock (sleep mutex) process lock @ /usr/src/sys/ia64/ia64/trap.c:562
# dump -0aLuf - / | restore -rf - produces this panic: lock order reversal: 1st 0xa0009ca034f8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2652 2nd 0xe0001163ebb0 snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2297 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe000116c78c0) locked @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2257 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe000116c78c0) locked @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2257 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe000116c78c0) locked @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2257 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe000116c78c0) locked @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2257 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe000116c78c0) locked @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2257 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock)panic: blockable sleep lock (sleep mutex) process lock @ /usr/src/sys/ia64/ia64/trap.c:562 cpuid = 1 KDB: enter: panic [ thread pid 956 tid 100089 ] Stopped at kdb_enter+0x92: [I2]addl r14=0xffe25000,gp ;; db db show thread Thread 100089 at 0xe00011f25140: proc (pid 956): 0xe00011d8b6a8 name: dump stack: 0xa000f87a4000-0xa000f87abfff flags: 0x10004 pflags: 0 state: RUNNING (CPU 1) priority: 120 container lock: sched lock 1 (0x9ffc00d8b8c0) db db thread 100089 [ thread pid 956 tid 100089 ] kdb_enter+0x92: [I2]addl r14=0xffe25000,gp ;; db bt Tracing pid 956 tid 100089 td 0xe00011f25140 kdb_enter(0x9ffc00c52c38, 0x9ffc00c52c38, 0x9ffc004eb6b0, 0x793) at kdb_enter+0x92 panic(0x9ffc00c5b748, 0x9ffc00c50f60, 0x9ffc00c50f40, 0x9ffc00c93830, 0x232, 0x9ffc00c93830) at panic+0x420 witness_checkorder(0xe00011d8b7a0, 0x9, 0x9ffc00c93830, 0x232, 0x0) at witness_checkorder+0x1b0 _mtx_lock_flags(0xe00011d8b7a0, 0x0, 0x9ffc00c93830, 0x232, 0x9ffc0097dcc0, 0x716, 0x0) at _mtx_lock_flags+0x160 trap(0x14, 0xa000f87a5800) at trap+0x940 ivt_Data_TLB() at ivt_Data_TLB+0x1d0 --- trapframe at 0xa000f87a5800 ia64_handle_intr(0xa000f87a5c00) at ia64_handle_intr+0x171 ivt_External_Interrupt() at ivt_External_Interrupt+0x30 --- trapframe at 0xa000f87a5c00 __gp(...) at __gp db -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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
ia64 r235474 panic on dump 0aLuf - / | restore -rf - : exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79
# newfs /dev/da2p2 /dev/da2p2: 16384.0MB (33554432 sectors) block size 32768, fragment size 4096 using 27 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. super-block backups (for fsck -b #) at: 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592, 14104832, 15387072, 16669312, 17951552, 19233792, 20516032, 21798272, 23080512, 24362752, 25644992, 26927232, 28209472, 29491712, 30773952, 32056192, 8432 # mount /dev/da2p2 /mnt # cd /mnt # dump 0aLuf - / | restore -rf - results in this panic: KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe0001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe0001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 KDB: stack backtrace: getenv with the following non-sleepablefatal kernel trap (cpu 0): locks held: exclusive sleep mutex vnode interlocktrap vector = 0x18 (General Exception) (vnode interlock)cr.iip = 0x9ffc00967e90 r = 0 (0xe0001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 cr.ipsr = 0x1210080a2018 (KDB: stack backtrace: ac,getenvmfl with the following, non-sleepableic, locks held: dtexclusive sleep mutex vnode interlock, (vnode interlock)dfh r = 0 (0xe0001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 ,rtKDB: stack backtrace: ,cpl=0getenv, with the followingit non-sleepable,ri=1 locks held: ,exclusive sleep mutex vnode interlockbn (vnode interlock)) r = 0 (0xe0001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 cr.isr = 0x230 (KDB: stack backtrace: code=48,vector=0getenv, with the followingei=1 non-sleepable) locks held: cr.ifa = 0xe0001113cd60 exclusive sleep mutex vnode interlockcurthread = 0xe00011d6c000 (vnode interlock)pid = 640, comm = ipmon r = 0 (0xe0001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 KDB: stack backtrace: [ thread pid 640 tid 100076 ] Stopped at cpu_switch+0x201: [I1]mov.i ar.pfs=r36 db db bt Tracing pid 640 tid 100076 td 0xe00011d6c000 cpu_switch(0x0) at cpu_switch+0x201 uart_quicc_class(0xe00011d6c000, 0x0, 0x0, 0x9ffc00979a40, 0x8, 0x9ffc00f2b3b0, 0xe00011d6c000, 0xa000f87434e8) at 0x204 db The panic is reproducible, I now saw it 3 times in a row. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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
no keyboard after booting r235646 in laptop FS Amilo D 7830
Hello, I have a boot-able USB key with r235646 which works fine in all my laptops so far; today I got as a gift an older FS Amilo D 7830 which has enough resources to use it as new build machine (1 GByte RAM, 80 GByte disk). I booted it with from the USB key and after the system is up it does not echo or react on any key-press; before booting the keys are working, for example in the menu to boot into single user etc. What could be the problem? I will later configure that the USB booted system brings Ethernet and SSH up, maybe I can see something when I can login via SSH... matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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: [CFC/CFT] large changes in the loader(8) code
Dimitry Andric d...@freebsd.org writes: On 2012-06-26 14:50, Andrey V. Elsukov wrote: Some time ago i have started reading the code in the sys/boot. Especially i'm interested in the partition tables handling. I found several problems: 1. There are several copies of the same code in the libi386/biosdisk.c and common/disk.c, and partially libpc98/biosdisk.c. 2. ZFS probing is very slow, because the ZFS code doesn't know how many disks and partitions the system has: http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 3. The GPT support doesn't check CRC and even doesn't know anything about the secondary GPT header/table. So, i have created the branch and committed the changes: http://svnweb.freebsd.org/base/user/ae/bootcode/ The patch is here: http://people.freebsd.org/~ae/boot.diff FWIW, I verified it compiles OK with clang, and especially boot2's size isn't increased at all. Does it boot for you? Same if I build zfs.c with gcc -O0: FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.1 (foo@bar, Tue Jun 26 18:52:52 UTC 2012) ZFS: can't find pool by guid ZFS: can't find pool by guid can't load 'kernel' It would be nice if you could check it with clang now and again, before you finally merge this project into head. ___ 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: no keyboard after booting r235646 in laptop FS Amilo D 7830
On Friday 29 June 2012 15:34:23 Matthias Apitz wrote: Hello, I have a boot-able USB key with r235646 which works fine in all my laptops so far; today I got as a gift an older FS Amilo D 7830 which has enough resources to use it as new build machine (1 GByte RAM, 80 GByte disk). I booted it with from the USB key and after the system is up it does not echo or react on any key-press; before booting the keys are working, for example in the menu to boot into single user etc. What could be the problem? I will later configure that the USB booted system brings Ethernet and SSH up, maybe I can see something when I can login via SSH... matthias What does dmesg say about USB? --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
print/foomatic-db-engine : install: *.1: No such file or directory
I'm stuck with this nasty error in print/foomatic-db-engine, which prevents me from updating ports relying on this specific port. This problem is sticky on all FreeBSD 10-CURRENT boxes. /usr/local/bin/perl -p -i -e s:foomatic-templates:/usr/local/share/foomatic//templates:g //usr/local/sbin/foomatic-addpjloptions ln -sf foomatic-ppdfile //usr/local/bin/foomatic-datafile if [ -d /usr/local/libexec/cups ]; then \ ./mkinstalldirs //usr/local/libexec/cups/driver; \ ln -sf /usr/local/bin/foomatic-ppdfile //usr/local/libexec/cups/driver/foomatic; \ fi ./mkinstalldirs //usr/local/man ./mkinstalldirs //usr/local/man/man1 ./mkinstalldirs //usr/local/man/man8 /usr/bin/install -c -o root -g wheel -m 644 *.1 //usr/local/man/man1 install: *.1: No such file or directory gmake: *** [install-man] Error 71 *** [do-install] Error code 2 Stop in /usr/ports/print/foomatic-db-engine. === Installation of foomatic-db-engine-4.0.7,2 (print/foomatic-db-engine) failed === Aborting update Terminated === You can restart from the point of failure with this command line: portmaster flags print/foomatic-db-engine signature.asc Description: OpenPGP digital signature
Re: [RFT] llquantize for FreeBSD's dtrace
On Jun 26, 2012, at 15:06 , Fabian Keil wrote: Pedro Giffuni p...@freebsd.org wrote: --- Mar 26/6/12, Mark Peek m...@freebsd.org ha scritto: Try this, change the assert on line 1429 in file dt_cc.c from: assert(!(arg (UINT16_MAX args[i].shift))); to assert(!(arg ((uint64_t)UINT16_MAX args[i].shift))); This certainly looks correct. Thanks Mark ! I updated the patch: http://people.freebsd.org/~pfg/patches/patch-dtrace-llquantize Thanks a lot. Seems to work for me: And me as well. I tested the example from the web site. Nicely done! Best, 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
MPSAFE VFS -- List of upcoming actions
As already published several times, according to the following plan: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS in 2 months the code dealing with non-MPSAFE filesystem will be removed and filesystems not yet MPSAFE will be disconnected from the tree. Their code will be however available in our official repository yet for 6 months. This leaves a total time of 8 months to do actions. Current list of unmantained filesystems is: HPFS, NWFS, PortalFS and XFS. Coda and SMBFS have current mantainership but the status of the work has still to be determined. NTFS, is being worked for the Summer of Code program. Finally, ReiserFS was successfully locked during this campaign. It is time for community members to step up and offer time and skills to lock a filesystem or test the effort of other developers willing to do so. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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] BSD sort is the default sort in -CURRENT
Now I am going to provide the second informational part about the new BSD sort: the differences between the new BSD sort and the GNU sort programs. Below: NBSD - new BSD sort; OGNU - old BSD/GNU sort, version 5.3.0; NGNU - new GNU sort, version 8.15. There are several areas: 1) -k option (sort fields/keys), with single byte locales. The -k option functionality is described in POSIX standard with deceitfully simple wording. Unfortunately, the real meaning is rather complex, and sometimes it defies the common sense. For example, a sort key can spread across boundaries with subsequent sort keys. A common-sense-based implementation would fail the POSIX standard. The OGNU implementation fails to follow the standard. In our tests, there are thousands various use cases when it does not work properly. The OGNU exact algorithm and the failure pattern is a mystery for us. The NGNU implements the POSIX algorithm properly, and the NBSD is compatible with NGNU when using -k in single-byte locales. 2) -k option (sort fields/keys), with multi-byte locales. Here the situation is reverse. During the -k calculation, NGNU basically ignores the symbol sizes (but it does not ignore the symbol sizes when it compares the fields). The result is that the sort keys are not calculated correctly by the NGNU. OGNU, on the other hand, seems to use the correct symbol sizes, but it is still using incorrect algorithm. So, the overall picture is: - OGNU uses wrong algorithm, but it uses correct symbol sizes; - NGNU uses correct algorithm, but it uses wrong symbol sizes; - NBSD uses NGNU-compatible algorithm with correct symbol sizes. So, for big majority of users who are using only single-byte locales, the NBSD sort key calculation is compatible with NGNU. For the multi-byte locales (like zh_HK.Big5HKSCS), we believe that only NBSD provides the correct results with -k option. 3) NGNU does not allow options -d and/or -i together with numeric sorting. OGNU and NBSD allows that. 4) NBSD adds NGNU-compatible options, which are absent in OGNU: -C (silent version of -c) -h (human numeric sort) -R (random sort) -V (version sort) --batch-size --compress-program --random-source --debug --files0-from 5) NBSD adds several of its own new proprietary options: --mergesort --qsort --heapsort --radixsort --nthreads=... (multi-threaded build only) 6) NBSD does not support option --parallel of NGNU. It has roughly the same meaning as --nthreads in NBSD. This difference will be fixed soon. Thanks Oleg -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Oleg Moskalenko Sent: Wednesday, June 27, 2012 6:45 PM To: FreeBSD Current Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT Hi As promised, I am supplying an example of comparison between several sort programs. The test file is a randomly generated 1,000,000 lines, each line contain a single floating point number. We are going to sort it three ways - as text, as -n numeric sort, and as -g numeric sort, with 4 programs: 1) Old BSD/GNU sort 5.3.0 2) New GNU sort 8.15 3) New BSD sort, single threaded 4) New BSD sort, multi-threaded The system is a 3-CPUs system, 1.5Gb of RAM, FreeBSD version 8.2. All times are in seconds. Locale C. == TEXT SORT sys user real Old BSD/GNU sort:0.0 1.692 2.008 New GNU sort:0.0 2.279 1.605 New BSD sort, st:0.0 1.964 2.300 New BSD sort, mt:0.0 2.385 1.897 == NUMERIC SORT -n sys user real Old BSD/GNU sort:0.0 4.357 4.674 New GNU sort:0.0 8.839 5.134 New BSD sort, st:0.0 5.308 5.592 New BSD sort, mt:0.0 4.581 2.489 == NUMERIC SORT -g sys user real Old BSD/GNU sort:0.0 45.37845.630 New GNU sort: ~450~121 ~300 New BSD sort, st:0.334.334 5.992 New BSD sort, mt:11.140 4.624 8.983 === Thanks Oleg ___ 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: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/29/2012 01:50 PM, Oleg Moskalenko wrote: 5) NBSD adds several of its own new proprietary options: --mergesort --qsort --heapsort --radixsort --nthreads=... (multi-threaded build only) Oleg, First, thank you very much for providing both the performance numbers, and the breakdown in the differences in command line options. Everything looks great, my only concern is the above. Are there similar/identical options in NGNU that correspond to the options above? If so, I would be hesitant to add new names for them because it hurts portability between platforms. If these are totally new features then my assumption is that you have clearly marked them as non-portable in the man page? Once again, I really appreciate you addressing my concerns, and your hard work on this project. Doug ___ 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] BSD sort is the default sort in -CURRENT
Doug, --nthreads option corresponds to --parallel option of NGNU and it will be renamed. The other four proprietary options will be marked as non-portable in the man page. After nthreads==parallel renaming, NBSD will support all NGNU options. Thank you for the suggestion. Oleg -Original Message- From: Doug Barton [mailto:do...@freebsd.org] Sent: Friday, June 29, 2012 2:02 PM To: Oleg Moskalenko Cc: FreeBSD Current Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 06/29/2012 01:50 PM, Oleg Moskalenko wrote: 5) NBSD adds several of its own new proprietary options: --mergesort --qsort --heapsort --radixsort --nthreads=... (multi-threaded build only) Oleg, First, thank you very much for providing both the performance numbers, and the breakdown in the differences in command line options. Everything looks great, my only concern is the above. Are there similar/identical options in NGNU that correspond to the options above? If so, I would be hesitant to add new names for them because it hurts portability between platforms. If these are totally new features then my assumption is that you have clearly marked them as non-portable in the man page? Once again, I really appreciate you addressing my concerns, and your hard work on this project. Doug ___ 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: MPSAFE VFS -- List of upcoming actions
On 06/29/12 16:32, Attilio Rao wrote: As already published several times, according to the following plan: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS in 2 months the code dealing with non-MPSAFE filesystem will be removed and filesystems not yet MPSAFE will be disconnected from the tree. Their code will be however available in our official repository yet for 6 months. This leaves a total time of 8 months to do actions. Current list of unmantained filesystems is: HPFS, NWFS, PortalFS and XFS. Coda and SMBFS have current mantainership but the status of the work has still to be determined. NTFS, is being worked for the Summer of Code program. Finally, ReiserFS was successfully locked during this campaign. What is to become of fusefs and friends, i.e. write-capable NTFS and truecrypt? imb ___ 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: MPSAFE VFS -- List of upcoming actions
On Fri, Jun 29, 2012 at 4:23 PM, Michael Butler i...@protected-networks.net wrote: On 06/29/12 16:32, Attilio Rao wrote: As already published several times, according to the following plan: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS in 2 months the code dealing with non-MPSAFE filesystem will be removed and filesystems not yet MPSAFE will be disconnected from the tree. Their code will be however available in our official repository yet for 6 months. This leaves a total time of 8 months to do actions. Current list of unmantained filesystems is: HPFS, NWFS, PortalFS and XFS. Coda and SMBFS have current mantainership but the status of the work has still to be determined. NTFS, is being worked for the Summer of Code program. Finally, ReiserFS was successfully locked during this campaign. What is to become of fusefs and friends, i.e. write-capable NTFS and truecrypt? fusefs is not a part of the OS.It is a port. I believe gnn@ is working on it, but I have not seen any report on its status for a while. -- 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: GPU_KMS still not working CURRENT X220
Hi, On Thursday, June 28, 2012 11:15:54 PM Kevin Oberman wrote: On Thu, Jun 28, 2012 at 8:45 AM, Andrey Fesenko f0and...@gmail.com wrote: I have lenovo thinkpad x220 # uname -a FreeBSD bsdx220 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r237683: Thu Jun 28 08:41:40 MSK 2012 root@bsdx220:/usr/obj/usr/src/sys/MY_INTEL amd64 it works for me with this: FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #7: Thu Jun 28 09:09:16 WIT 2012 # pciconf -lvb 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 bar [10] = type Memory, range 64, base 0xf000, size 4194304, enabled bar [18] = type Prefetchable Memory, range 64, base 0xe000, size 268435456, enabled bar [20] = type I/O Port, range 32, base 0x6000, size 64, enabled After # kldload i915kms screen is black, if # kldunload i915kms panic Don't do this. It has been clearly stated that i915kms my not be unloaded and that attempting to unload it WILL panic the system. Also, don't load i945kms. This WILL lock up the system with a blank screen. it works for me. I use this kind of script to start X: sudo kldload i915kms sudo kldload acpi_call sudo chmod 666 /dev/acpi startx The modules required are autoloaded during Xorg initialization. Just make absolutely sure that you have the latest version of xf-video-intel. (If you installed a rather early version of the KMS code, it is possible that you have two xf-video.intel* ports in your tree, thought I don't expect this is the case. This could be the real reason why it fails But I must say that it hangs on rare occasions. It might has to do with playing with the mouse or the keyboard during the start-up phase of X. At least, I did not notice a freeze when I did not play around with them during the start of X. 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
[head tinderbox] failure on arm/arm
TB --- 2012-06-30 02:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-30 02:20:00 - 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 --- 2012-06-30 02:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-06-30 02:20:00 - cleaning the object tree TB --- 2012-06-30 02:20:00 - cvsupping the source tree TB --- 2012-06-30 02:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-06-30 02:26:13 - building world TB --- 2012-06-30 02:26:13 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 02:26:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 02:26:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 02:26:13 - SRCCONF=/dev/null TB --- 2012-06-30 02:26:13 - TARGET=arm TB --- 2012-06-30 02:26:13 - TARGET_ARCH=arm TB --- 2012-06-30 02:26:13 - TZ=UTC TB --- 2012-06-30 02:26:13 - __MAKE_CONF=/dev/null TB --- 2012-06-30 02:26:13 - cd /src TB --- 2012-06-30 02:26:13 - /usr/bin/make -B buildworld World build started on Sat Jun 30 02:26:13 UTC 2012 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 Jun 30 03:30:02 UTC 2012 TB --- 2012-06-30 03:30:02 - cd /src/sys/arm/conf TB --- 2012-06-30 03:30:02 - /usr/sbin/config -m AVILA TB --- 2012-06-30 03:30:02 - skipping AVILA kernel TB --- 2012-06-30 03:30:02 - cd /src/sys/arm/conf TB --- 2012-06-30 03:30:02 - /usr/sbin/config -m BWCT TB --- 2012-06-30 03:30:02 - building BWCT kernel TB --- 2012-06-30 03:30:02 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 03:30:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 03:30:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 03:30:02 - SRCCONF=/dev/null TB --- 2012-06-30 03:30:02 - TARGET=arm TB --- 2012-06-30 03:30:02 - TARGET_ARCH=arm TB --- 2012-06-30 03:30:02 - TZ=UTC TB --- 2012-06-30 03:30:02 - __MAKE_CONF=/dev/null TB --- 2012-06-30 03:30:02 - cd /src TB --- 2012-06-30 03:30:02 - /usr/bin/make -B buildkernel KERNCONF=BWCT Kernel build for BWCT started on Sat Jun 30 03:30:02 UTC 2012 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 Kernel build for BWCT completed on Sat Jun 30 03:32:12 UTC 2012 TB --- 2012-06-30 03:32:12 - cd /src/sys/arm/conf TB --- 2012-06-30 03:32:12 - /usr/sbin/config -m CAMBRIA TB --- 2012-06-30 03:32:12 - skipping CAMBRIA kernel TB --- 2012-06-30 03:32:12 - cd /src/sys/arm/conf TB --- 2012-06-30 03:32:12 - /usr/sbin/config -m CNS11XXNAS TB --- 2012-06-30 03:32:13 - building CNS11XXNAS kernel TB --- 2012-06-30 03:32:13 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 03:32:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 03:32:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 03:32:13 - SRCCONF=/dev/null TB --- 2012-06-30 03:32:13 - TARGET=arm TB --- 2012-06-30 03:32:13 - TARGET_ARCH=arm TB --- 2012-06-30 03:32:13 - TZ=UTC TB --- 2012-06-30 03:32:13 - __MAKE_CONF=/dev/null TB --- 2012-06-30 03:32:13 - cd /src TB --- 2012-06-30 03:32:13 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS Kernel build for CNS11XXNAS started on Sat Jun 30 03:32:13 UTC 2012 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 Kernel build for CNS11XXNAS completed on Sat Jun 30 03:34:41 UTC 2012 TB --- 2012-06-30 03:34:41 - cd /src/sys/arm/conf TB --- 2012-06-30 03:34:41 - /usr/sbin/config -m CRB TB --- 2012-06-30 03:34:41 - skipping CRB kernel TB --- 2012-06-30 03:34:41 - cd /src/sys/arm/conf TB --- 2012-06-30 03:34:41 - /usr/sbin/config -m DB-78XXX TB --- 2012-06-30 03:34:41 - building DB-78XXX kernel TB --- 2012-06-30 03:34:41 - CROSS_BUILD_TESTING=YES TB --- 2012-06-30 03:34:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-30 03:34:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-30 03:34:41 - SRCCONF=/dev/null TB --- 2012-06-30 03:34:41 - TARGET=arm TB --- 2012-06-30 03:34:41 - TARGET_ARCH=arm TB --- 2012-06-30 03:34:41 - TZ=UTC TB --- 2012-06-30 03:34:41 - __MAKE_CONF=/dev/null TB --- 2012-06-30 03:34:41 - cd /src TB --- 2012-06-30 03:34:41 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX Kernel build for DB-78XXX started on Sat Jun 30 03:34:41 UTC 2012 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 Kernel build for DB-78XXX completed on Sat
Re: MPSAFE VFS -- List of upcoming actions
On 06/29/12 16:32, Attilio Rao wrote: As already published several times, according to the following plan: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS in 2 months the code dealing with non-MPSAFE filesystem will be removed and filesystems not yet MPSAFE will be disconnected from the tree. Their code will be however available in our official repository yet for 6 months. This leaves a total time of 8 months to do actions. Current list of unmantained filesystems is: HPFS, NWFS, PortalFS and XFS. Coda and SMBFS have current mantainership but the status of the work has still to be determined. NTFS, is being worked for the Summer of Code program. Finally, ReiserFS was successfully locked during this campaign. I'm familiar with HPFS but not NWFS, PortalFS and SMBFS; don't really know what Coda is. I've been wondering about the status of XFS in (Free or other)BSD, know it's in ports and is usable in Linux. I think you can even run Linux on XFS instead of ext(2,3 or 4)fs, or ReiserFS, or btrfs. I remember Linux having read-only access, later also read-write, to HPFS, and I actually read HPFS partitions from Linux. That was long ago. Sometime during the single-digit days of April 2001, my OS/2 Warp 4 installation came apart when, following a crash where the file system was not cleanly dismounted, CHKDSK ran amok on reboot and trashed the entire hard disk, destroying a Linux installation as well. I was never able to boot any OS/2 again after that (trap 000c or 000d if it got that far), even from installation or other diskettes; there was no such thing as bootable CD back then, at least not for OS/2 Warp 4. Although OS/2 has continued on as eComStation (www.ecomstation.com), 32-bit i386 only, no 64-bit, eComStation has fallen far behind Linux and the BSDs. So one could say HPFS is antiquated, very few Linux or BSD users would have use for HPFS access; my last time was in April 2001. Tom ___ 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: no keyboard after booting r235646 in laptop FS Amilo D 7830
El día Friday, June 29, 2012 a las 04:45:57PM +0200, Hans Petter Selasky escribió: On Friday 29 June 2012 15:34:23 Matthias Apitz wrote: Hello, I have a boot-able USB key with r235646 which works fine in all my laptops so far; today I got as a gift an older FS Amilo D 7830 which has enough resources to use it as new build machine (1 GByte RAM, 80 GByte disk). I booted it with from the USB key and after the system is up it does not echo or react on any key-press; before booting the keys are working, for example in the menu to boot into single user etc. What could be the problem? I will later configure that the USB booted system brings Ethernet and SSH up, maybe I can see something when I can login via SSH... matthias What does dmesg say about USB? attached is the dmesg output matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0 r235646: Sat May 19 15:52:36 CEST 2012 g...@aurora.sisis.de:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2398.35-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Family = f Model = 2 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x4400CNXT-ID,xTPR real memory = 1073741824 (1024 MB) avail memory = 1027141632 (979 MB) Event timer LAPIC quality 400 ACPI APIC Table: A M I OEMAPIC ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 ctl: CAM Target Layer loaded acpi0: A M I OEMRSDT on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 3ff0 (3) failed driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) cpu0: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_ec0: Embedded Controller: GPE 0x1c port 0x62,0x66 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82845G host to AGP bridge on hostb0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xb000-0xb0ff mem 0xd000-0xd7ff,0xffcf-0xffcf irq 16 at device 0.0 on pci1 uhci0: Intel 82801DB (ICH4) USB controller USB-A port 0xdf20-0xdf3f irq 16 at device 29.0 on pci0 uhci0: LegSup = 0x2f00 usbus0 on uhci0 uhci1: Intel 82801DB (ICH4) USB controller USB-B port 0xdf40-0xdf5f irq 19 at device 29.1 on pci0 uhci1: LegSup = 0x2f00 usbus1 on uhci1 uhci2: Intel 82801DB (ICH4) USB controller USB-C port 0xdf80-0xdf9f irq 18 at device 29.2 on pci0 uhci2: LegSup = 0x2f00 usbus2 on uhci2 ehci0: Intel 82801DB/L/M (ICH4) USB 2.0 controller mem 0xffeffc00-0xffef irq 23 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 cbb0: O2Micro OZ6912/6972 PCI-CardBus Bridge at device 3.0 on pci2 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 fwohci0: VIA Fire II (VT6306) port 0xcc00-0xcc7f mem 0xffdff800-0xffdf irq 18 at device 10.0 on pci2 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:03:0d:49:75:50:7a:e8 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 dcons_crom0: dcons configuration ROM on firewire0 dcons_crom0: bus_addr 0x29b8000 fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 02:03:0d:50:7a:e8 fwe0: Ethernet address: 02:03:0d:50:7a:e8 fwip0: IP over FireWire on firewire0 fwip0: Firewire address: 00:03:0d:49:75:50:7a:e8 @ 0xfffe, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x, SelfID Count=1, CYCLEMASTER mode sis0: NatSemi DP8381[56] 10/100BaseTX port 0xc800-0xc8ff mem 0xffdfe000-0xffdfefff irq 17 at device 12.0 on pci2 sis0: Silicon Revision: DP83816A miibus0: MII bus on sis0 nsphyter0: DP83815 10/100
Re: no keyboard after booting r235646 in laptop FS Amilo D 7830
On Saturday 30 June 2012 06:43:16 Matthias Apitz wrote: El día Friday, June 29, 2012 a las 04:45:57PM +0200, Hans Petter Selasky escribió: On Friday 29 June 2012 15:34:23 Matthias Apitz wrote: Hello, I have a boot-able USB key with r235646 which works fine in all my laptops so far; today I got as a gift an older FS Amilo D 7830 which has enough resources to use it as new build machine (1 GByte RAM, 80 GByte disk). I booted it with from the USB key and after the system is up it does not echo or react on any key-press; before booting the keys are working, for example in the menu to boot into single user etc. What could be the problem? I will later configure that the USB booted system brings Ethernet and SSH up, maybe I can see something when I can login via SSH... matthias What does dmesg say about USB? attached is the dmesg output matthias Hi, Can you try to play with USB settings in the BIOS? You can also try to compile a kernel with options USB_DEBUG, and hw.usb.uhub.debug=15. I don't see any errors in the dmesg. Maybe there are some magick bits that needs to be tweaked. Also try to put an external high speed hub in between. --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
