ata/ahci problems in 9.0-BETA3
Hi! I have the following problem on 2 different machines with the same version of FreeBSD on it (csup'd yesterday) Whenever I compile some stuff or transfer bigger amounts of data there is a chance that I'l get the following error: ahcich0: AHCI reset: device not ready after 31000ms (tfd = 0080) ahcich0: Timeout on slot 28 port 0 achich0: is cs 1000 ss rs 1000 tfd 80 serr cmd fc17 (this error is from machine 2) It never recovers after that problem and the only solution is to turn off the power (reset is not sufficient - it looks like the sata controller is completely dead after such an occurence) I had the same problem in earlier versions of head (9-current) on machine 1 without the SSD but was able to work around them by not using ahci - that workaround no longer works - only difference is that it says ataX: instead of ahcichX: in the above error. Machine 2 started with the problems when I put the SSD into it. I even tried the NO_NCQ 'switch' which I found somewhere on the net for a similar problem. Both BIOS' are up to date and Windows runs stable on machine 2 (which means I do not expect it to be a hardware problem) What can I do to trace and get rid of that problem? (a bt in the system debugger didn't really show me much useful information - at least not useful to me...) Cheers, Armin machine 1: ahci0: JMicron JMB363 AHCI SATA controller mem 0xfbcfe000-0xfbcf irq 16 at device 0.0 on pci4 ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich1: AHCI channel at channel 1 on ahci0 ahci1: Intel ICH10 AHCI SATA controller port 0x9c00-0x9c07,0x9880-0x9883,0x9800-0x9807,0x9480-0x9483,0x9400-0x941f mem 0xf7ffc000-0xf7ffc7ff irq 20 at device 31.2 on pci0 ahci1: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported ahcich2: AHCI channel at channel 0 on ahci1 ahcich3: AHCI channel at channel 1 on ahci1 ahcich4: AHCI channel at channel 2 on ahci1 ahcich5: AHCI channel at channel 3 on ahci1 ahcich6: AHCI channel at channel 4 on ahci1 ahcich7: AHCI channel at channel 5 on ahci1 ada0 at ahcich2 bus 0 scbus4 target 0 lun 0 ada0: Corsair Force 3 SSD 1.3 ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad10 ada1 at ahcich3 bus 0 scbus5 target 0 lun 0 ada1: SAMSUNG HD154UI 1AG01118 ATA-7 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad12 ada2 at ahcich4 bus 0 scbus6 target 0 lun 0 ada2: SAMSUNG HD154UI 1AG01118 ATA-7 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad14 machine 2: ahci0: Intel 5 Series/3400 Series AHCI SATA controller port 0x5058-0x505f,0x5084-0x5087,0x5050-0x5057,0x5080-0x5083,0x5020-0x503f mem 0xb7806000-0xb78067ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported ahcich0: AHCI channel at channel 0 on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: Corsair Force 3 SSD 1.3 ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ___ 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
9.0-BETA 3 lock order reversal
Hello ! After upgrading my system from 8.2 to 9.0-BETA3 I now see this error message during boot : lock order reversal: 1st 0xc536e8d8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2134 2nd 0xde0077b4 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:260 3rd 0xc7b088d8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2134 KDB: stack backtrace: db_trace_self_wrapper(c0a19f6c,632e7262,3331323a,6f000a34,632e7370,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0757c8b,c0a1d8e8,c45452a0,c4548f28,de2ea3f4,...) at kdb_backtrace+0x2a _witness_debugger(c0a1d8e8,c7b088d8,c0a0cac0,c4548f28,c0a25674,...) at _witness_debugger+0x25 witness_checkorder(c7b088d8,9,c0a25674,856,0,...) at witness_checkorder+0x839 __lockmgr_args(c7b088d8,80100,c7b088f8,0,0,...) at __lockmgr_args+0x824 ffs_lock(de2ea51c,c0768ecb,c0a2495e,80100,c7b08880,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0ab18c0,de2ea51c,c4e36c30,c0ac00e0,c7b08880,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c7b08880,80100,c0a25674,856,4,...) at _vn_lock+0x5e vget(c7b08880,80100,c4e36b80,50,0,...) at vget+0xb9 vfs_hash_get(c494c798,62d401,8,c4e36b80,de2ea660,...) at vfs_hash_get+0xe6 ffs_vgetf(c494c798,62d401,8,de2ea660,1,...) at ffs_vgetf+0x49 softdep_sync_buf(c536e880,de007754,1,106,0,...) at softdep_sync_buf+0x4a3 ffs_syncvnode(c536e880,1,c0afe61c,4,c0a1456b,...) at ffs_syncvnode+0x24c ffs_truncate(c536e880,200,0,880,c49f6500,...) at ffs_truncate+0x7a3 ufs_direnter(c536e880,c7b08880,de2ea9f4,de2eab84,ddfeb7c0,...) at ufs_direnter+0x921 ufs_mkdir(de2eac14,de2eac28,0,0,de2eabac,...) at ufs_mkdir+0x8ef VOP_MKDIR_APV(c0ab18c0,de2eac14,de2eab84,de2eabac,0,...) at VOP_MKDIR_APV+0xa5 kern_mkdirat(c4e36b80,ff9c,bfbfea6d,0,1ff,...) at kern_mkdirat+0x2a1 kern_mkdir(c4e36b80,bfbfea6d,0,1ff,de2ead1c,...) at kern_mkdir+0x2e sys_mkdir(c4e36b80,de2eacec,c0a568d6,c0a1e526,202,...) at sys_mkdir+0x29 syscall(de2ead28) at syscall+0x284 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (136, FreeBSD ELF32, sys_mkdir), eip = 0x28174303, esp = 0xbfbfe7dc, ebp = 0xbfbfe8a8 --- Regards Roar Pettersen Bergen - Norway ___ 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: aliasing (or renaming) kern.geom.debugflags
In message CACqU3MVgVUxe+Mtaf9wq6oz5=PZAq=sx-ihyqh1gyjd3pxm...@mail.gmail.com , Arnaud Lacombe writes: If you expose a setting, you cannot rely on a user not to use it even if you told him not to. As long as this is exposed and usable, it will be used, even more when it was documented. This is clearly marked as a debug tool, the only bug here, is that people tell users to abuse it in the documentation. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: aliasing (or renaming) kern.geom.debugflags
In message alpine.bsf.2.00.1110071734140.4...@wonkity.com, Warren Block write s: Since we're talking about this, could you review the usage in the gmirror section of the Handbook GEOM chapter: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-mirror.html Seems like that is a valid non-debugging use, to allow the last block to be written. gmirror and this procedure has several problems: 1. It steals the last sector on the disk. If that sector contained data you lost them, with no notice. Most often it will not, particularly on a freshly installed system, but it is still a bad thing. 2. The paritioning is not fixed up to record the stealing of this sector. I wouldn't be surprised if this could cause confusion down the road. 3. In this case, writing only happens to a single sector, which we assume is not going to be written by anybody else, so apart from #1 and #2 debugflags=16 does not cause any additional damage. This is the kind of usage that makes me sad I ever added that option. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: RFC: Project geom-events
Hello, Daniel. You wrote 8 октября 2011 г., 0:13:54: GPT (and MBR) metadata placement is dictated from outside world, where is no GEOM and geom_label. They INTENDED to be used on DISKS. BIOSes should be able to find it :) Certainly GPT and MBR must place an instance of the partition table where the BIOS expects it, but there's no immediately obvious reason why they must regard that instance as their GEOM metadata. GPT puts a second copy in the provider's last block, and AFAICT it could just as well use _that_ instance -- or even a differently-formatted block that included the same data -- as the primary. MBR could do likewise. I have deja-vu, that I answered this. Please, read standard. GPT _must_ be placed twice -- at first and last sectors (really, more than one sectors). By standard. Secondary copy must be at end of disk. Period. Then, by standard GPT cannot coexist with GLABEL. Such setup should be disallowed, or at least big nasty message that you have just shoot yourself in the leg should be output. (period) Ok, maybe adding check to geom_part, that it is used on rank-1 provider (whole disk) is not so bad idea. But it then raise question how to install FreeBSD on software mirror, what is useful. But could bite you sometimes... Hm... -- // Black Lion AKA Lev Serebryakov l...@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: RFC: Project geom-events
Hello, Lev. You wrote 8 октября 2011 г., 13:52:21: GPT must have backup copy in last sector by standard ... In that case, shouldn't it refuse to install on any provider that is not in fact a disk, so as not to create configurations that cannot work properly? Installation of FreeBSD on software mirror?.. MBR doesn;t have any additional metadata. How adding one will help it? It would add robustness, for cases like the one that started this thread. If MBR put a GEOM metadata block at the end of its provider, it would fix the tasting race when an MBR is installed on a glabelled (or gmirrored) drive. And how it should work with MBR created by non-FreeBSD tools? -- // Black Lion AKA Lev Serebryakov l...@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: RFC: Project geom-events
Hello, Ivan. You wrote 8 октября 2011 г., 0:23:14: If you think this should be explicitely handled, please file a PR which requests the modification of gpart so that it detects that a GPT is being created in anything other than a raw drive, and warns the user. It should be mentioned in documentation, at least. But how people will create bootable gmirror installation in such case? Make (many) mirrors from parts? I don't like this idea... -- // Black Lion AKA Lev Serebryakov l...@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: zfsloader 9.0 BETA3 r225759 - i/o error - all block copies unavailable
On 10/06/2011 16:20, Andriy Gapon wrote: on 06/10/2011 17:00 Henri Hennebert said the following: On 10/06/2011 15:36, Andriy Gapon wrote: on 06/10/2011 15:30 Henri Hennebert said the following: The pool is a mirror: [root@morzine ~]# zpool status rpool pool: rpool state: ONLINE scan: scrub repaired 0 in 1h0m with 0 errors on Wed Aug 24 15:04:36 2011 config: NAMESTATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gptid/e915c6a0-fc72-11de-aa21-00e081706b68 ONLINE 0 0 0 gptid/eac8497d-fc72-11de-aa21-00e081706b68 ONLINE 0 0 0 errors: No known data errors and rpool/root is not compressed: [root@morzine ~]# zfs get compression rpool/root NAMEPROPERTY VALUE SOURCE rpool/root compression off inherited from rpool pool is v28 and filesystems are v5 No particular recipes for this environment, just a general suggestion. If you run into a situation like this again, please try to use tools/tools/zfsboottest to diagnose where exactly an error originates. I try [ please note _M_enu.rc ]: [root@morzine ~]# /usr/obj/usr/src/tools/tools/zfsboottest/zfsboottest /boot/Menu.rc /dev/da0p2 /dev/da1p2 ZFS: SPA version 28 pool: rpool config: NAME STATE rpool ONLINE mirror ONLINE gptid/e915c6a0-fc72-11de-aa21-00e081706b68 ONLINE gptid/eac8497d-fc72-11de-aa21-00e081706b68 ONLINE \ Menu.rc \ $FreeBSD: head/sys/boot/forth/menu.rc 222417 2011-05-28 08:50:38Z julian $ \ \ Load required Forth modules include /boot/version.4th include /boot/brand.4th include /boot/menu.4th include /boot/menu-commands.4th include /boot/shortcuts.4th \ Screen prep clear \ clear the screen (see `screen.4th') print_version \ print version string (bottom-right; see `version.4th') draw-beastie \ draw freebsd mascot (on right; see `beastie.4th') draw-brand\ draw the FreeBSD title (top-left; see `brand.4th') menu-init \ initialize the menu area (see `menu.4th') \ Initialize main menu constructs (see `menu.4th') \ NOTE: To use the `ansi' variants, add `loader_color=1' to loader.conf(5) clip set menu_timeout_command=boot \ Display the main menu (see `menu.4th') menu-display [root@morzine ~] The line `ZFS: SPA version 28' come from my local patch: Index: sys/boot/zfs/zfsimpl.c === --- sys/boot/zfs/zfsimpl.c(revision 225759) +++ sys/boot/zfs/zfsimpl.c(working copy) @@ -63,6 +63,8 @@ STAILQ_INIT(zfs_vdevs); STAILQ_INIT(zfs_pools); +printf(ZFS: SPA version %u\n, (unsigned) SPA_VERSION); + zfs_temp_buf = malloc(TEMP_SIZE); zfs_temp_end = zfs_temp_buf + TEMP_SIZE; zfs_temp_ptr = zfs_temp_buf; Is it what you sugest ? Yes. And this report indicates that the boot code (built from your source tree) should be able to read that file. I do: mv /boot/Menu.rc /boot/menu.rc and reboot. The /boot/menu.rc can be read by zfsloader so I conclude that it was the directory entry of /boot/menu.rc thas has a problem in the first place. Next time it happen I will directly use zfsboottest before any update to the pool. Thank for your time! Henri ___ 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
9.0-BETA3 (r225759) without ACPI raise a page fault
Hello, On my configuration, If I boot 9.0-BETA3 (r225759) without ACPI, the kernel encounter a page fault before the end of the boot. A photo of the screen can be found at: http://verbier.restart.be/xfer/dsc00042.jpg Henri ___ 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: aliasing (or renaming) kern.geom.debugflags
Hello, Poul-Henning. You wrote 8 октября 2011 г., 12:18:54: gmirror and this procedure has several problems: 1. It steals the last sector on the disk. If that sector contained data you lost them, with no notice. Most often it will not, particularly on a freshly installed system, but it is still a bad thing. 2. The paritioning is not fixed up to record the stealing of this sector. I wouldn't be surprised if this could cause confusion down the road. Yes, see discussion about GPT and MBR problems in thread, which is named (and should be re-named already, really) RFC: Project geom-events This is the kind of usage that makes me sad I ever added that option. Storing metadata of GEOM in last (or first) sector plays bad with MBR and, especially, GPT :( And I cannot see good solution for this. It seems, that GPT will be incompatible with any pure-software mirror or mirror-like RAID. -- // Black Lion AKA Lev Serebryakov l...@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: aliasing (or renaming) kern.geom.debugflags
In message 338510238.20111008140...@serebryakov.spb.ru, Lev Serebryakov write s: It seems, that GPT will be incompatible with any pure-software mirror or mirror-like RAID. Unless you do what other implementations have done: Play nice with GPT and store your metadata in a GPT partition. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: aliasing (or renaming) kern.geom.debugflags
Hello, Poul-Henning. You wrote 8 октября 2011 г., 14:07:29: It seems, that GPT will be incompatible with any pure-software mirror or mirror-like RAID. Unless you do what other implementations have done: Play nice with GPT and store your metadata in a GPT partition. So, every other GEOM class should have special knowledge about GPT? It doesn't look like topology-agnostic GEOM way :) Now it is possible to make gmirror inside GPT partition by hands, of course. but if here is multiple partitions it will lead to multiple instances of gmirror, and, in case of synchronization, it will thrash disk, as all instances will try to read and write from different areas of disks (partiitons) in same time... I don't see good universal solution for this, unfortunately :( -- // Black Lion AKA Lev Serebryakov l...@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
9.0-BETA 3 lock order reversal
Hello ! Just did a new build of world kernel, and the error message have changed a bit : lock order reversal: 1st 0xddf0c4cc bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 2nd 0xc4996200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper(c0a19f6c,7366752f,7366752f,7269645f,68736168,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0757c8b,c0a1d8cf,c45452a0,c4548f90,de2bf898,...) at kdb_backtrace+0x2a _witness_debugger(c0a1d8cf,c4996200,c0a42e72,c4548f90,c0a42af7,...) at _witness_debugger+0x25 witness_checkorder(c4996200,9,c0a42af7,11c,0,...) at witness_checkorder+0x839 _sx_xlock(c4996200,0,c0a42af7,11c,c4ccfd24,...) at _sx_xlock+0x85 ufsdirhash_acquire(ddf0c46c,c4ccfd24,de2bf9f4,deb3ca54,de2bf968,...) at ufsdirhash_acquire+0x35 ufsdirhash_add(c4ccfd24,de2bf9f4,a54,de2bf954,de2bf958,...) at ufsdirhash_add+0x13 ufs_direnter(c4cd8cc0,c4cd8bb0,de2bf9f4,de2bfb84,ddf0c868,...) at ufs_direnter+0x739 ufs_mkdir(de2bfc14,de2bfc28,0,0,de2bfbac,...) at ufs_mkdir+0x8ef VOP_MKDIR_APV(c0ab18c0,de2bfc14,de2bfb84,de2bfbac,0,...) at VOP_MKDIR_APV+0xa5 kern_mkdirat(c4cb38a0,ff9c,28404020,0,1c0,...) at kern_mkdirat+0x2a1 kern_mkdir(c4cb38a0,28404020,0,1c0,de2bfd1c,...) at kern_mkdir+0x2e sys_mkdir(c4cb38a0,de2bfcec,c0a568d6,c0a1e49e,202,...) at sys_mkdir+0x29 syscall(de2bfd28) at syscall+0x284 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (136, FreeBSD ELF32, sys_mkdir), eip = 0x28174303, esp = 0xbfbfe8cc, ebp = 0xbfbfed78 --- FreeBSD 9.0-BETA3 #1: Sat Oct 8 12:19:13 CEST 2011 i386 Regards Roar Pettersen Bergen - Norway ___ 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: A patch for a bug in the dtrace command...
George Neville-Neil g...@freebsd.org wrote:
I have found that the dtrace command on FreeBSD, in both STABLE and HEAD,
does not print out
aggregations properly, likely due to the difference in how Solaris and
FreeBSD signals work.
For example, this one liner will give no output:
sudo dtrace -n 'syscall:::entry { @[execname] = quantize(arg0); }'
Acutally it works when not using sudo or when killing dtrace by
sending a SIGTERM instead of using the keyboard. Of course it's still
a bug.
While is should print this:
dtrace -n 'syscall:::entry { @[execname] = quantize(arg0); }'
dtrace: description 'syscall:::entry ' matched 1028 probes
^C
nrpe2
value - Distribution - count
2 | 0
4 | 12
8 | 0
sshd
value - Distribution - count
0 | 0
1 |@@ 5
2 |@@ 7
4 | 0
8 | 8
16 | 0
etc.
I have made the following patch, but I'd be interested in people testing and
commenting on it.
I do not know whether dtrace or sudo is responsible for the problem,
but I can confirm that the patch works for me. Thanks a lot.
Fabian
signature.asc
Description: PGP signature
Re: aliasing (or renaming) kern.geom.debugflags
Hi, On Sat, Oct 8, 2011 at 4:11 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message CACqU3MVgVUxe+Mtaf9wq6oz5=PZAq=sx-ihyqh1gyjd3pxm...@mail.gmail.com , Arnaud Lacombe writes: If you expose a setting, you cannot rely on a user not to use it even if you told him not to. As long as this is exposed and usable, it will be used, even more when it was documented. This is clearly marked as a debug tool, the only bug here, is that people tell users to abuse it in the documentation. User do not care to understand the meaning of an option, you leave a hole somewhere, it will be used. I'm not even speaking about security issue here... This should never have been present in a release kernel. - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2011-10-08 14:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-08 14:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-08 14:30:00 - cleaning the object tree TB --- 2011-10-08 14:30:55 - cvsupping the source tree TB --- 2011-10-08 14:30:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-08 14:31:08 - building world TB --- 2011-10-08 14:31:08 - CROSS_BUILD_TESTING=YES TB --- 2011-10-08 14:31:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-08 14:31:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-08 14:31:08 - SRCCONF=/dev/null TB --- 2011-10-08 14:31:08 - TARGET=i386 TB --- 2011-10-08 14:31:08 - TARGET_ARCH=i386 TB --- 2011-10-08 14:31:08 - TZ=UTC TB --- 2011-10-08 14:31:08 - __MAKE_CONF=/dev/null TB --- 2011-10-08 14:31:08 - cd /src TB --- 2011-10-08 14:31:08 - /usr/bin/make -B buildworld World build started on Sat Oct 8 14:31:08 UTC 2011 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 Oct 8 16:33:36 UTC 2011 TB --- 2011-10-08 16:33:36 - generating LINT kernel config TB --- 2011-10-08 16:33:36 - cd /src/sys/i386/conf TB --- 2011-10-08 16:33:36 - /usr/bin/make -B LINT TB --- 2011-10-08 16:33:36 - cd /src/sys/i386/conf TB --- 2011-10-08 16:33:36 - /usr/sbin/config -m LINT-NOINET TB --- 2011-10-08 16:33:36 - building LINT-NOINET kernel TB --- 2011-10-08 16:33:36 - CROSS_BUILD_TESTING=YES TB --- 2011-10-08 16:33:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-08 16:33:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-08 16:33:36 - SRCCONF=/dev/null TB --- 2011-10-08 16:33:36 - TARGET=i386 TB --- 2011-10-08 16:33:36 - TARGET_ARCH=i386 TB --- 2011-10-08 16:33:36 - TZ=UTC TB --- 2011-10-08 16:33:36 - __MAKE_CONF=/dev/null TB --- 2011-10-08 16:33:36 - cd /src TB --- 2011-10-08 16:33:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Sat Oct 8 16:33:37 UTC 2011 stage 1: configuring the kernel [...] WARNING: kernel contains GPL contaminated maestro3 headers WARNING: kernel contains GPL contaminated ReiserFS filesystem WARNING: kernel contains GPL contaminated xfs filesystem WARNING: COMPAT_SVR4 is broken and should be avoided config: Error: device exphy is unknown config: Error: device inphy is unknown config: Error: device ruephy is unknown config: 3 errors *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-08 16:33:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-08 16:33:38 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-10-08 16:33:38 - 5924.49 user 1041.20 system 7417.25 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
In message cacqu3muqq6xqtfxhve1jtu4aey3kcdktcprd7ojq3ourdc8...@mail.gmail.com , Arnaud Lacombe writes: User do not care to understand the meaning of an option, you leave a hole somewhere, it will be used. I'm not even speaking about security issue here... There is a big difference between having an emergency hatch that gives you a chance to escape certain death by running across a shooting range, and on posting a sign telling people to use it as a short-cut. debugflags16 has legitimate uses if you know exactly what kind of shitty situation you are in, and it should absolutely be in the release kernel for that reason. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on amd64/amd64
TB --- 2011-10-08 14:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-08 14:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-08 14:30:00 - cleaning the object tree TB --- 2011-10-08 14:30:55 - cvsupping the source tree TB --- 2011-10-08 14:30:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-08 14:31:07 - building world TB --- 2011-10-08 14:31:07 - CROSS_BUILD_TESTING=YES TB --- 2011-10-08 14:31:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-08 14:31:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-08 14:31:07 - SRCCONF=/dev/null TB --- 2011-10-08 14:31:07 - TARGET=amd64 TB --- 2011-10-08 14:31:07 - TARGET_ARCH=amd64 TB --- 2011-10-08 14:31:07 - TZ=UTC TB --- 2011-10-08 14:31:07 - __MAKE_CONF=/dev/null TB --- 2011-10-08 14:31:07 - cd /src TB --- 2011-10-08 14:31:07 - /usr/bin/make -B buildworld World build started on Sat Oct 8 14:31:08 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Sat Oct 8 17:05:03 UTC 2011 TB --- 2011-10-08 17:05:03 - generating LINT kernel config TB --- 2011-10-08 17:05:03 - cd /src/sys/amd64/conf TB --- 2011-10-08 17:05:03 - /usr/bin/make -B LINT TB --- 2011-10-08 17:05:03 - cd /src/sys/amd64/conf TB --- 2011-10-08 17:05:03 - /usr/sbin/config -m LINT-NOINET TB --- 2011-10-08 17:05:03 - building LINT-NOINET kernel TB --- 2011-10-08 17:05:03 - CROSS_BUILD_TESTING=YES TB --- 2011-10-08 17:05:03 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-08 17:05:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-08 17:05:03 - SRCCONF=/dev/null TB --- 2011-10-08 17:05:03 - TARGET=amd64 TB --- 2011-10-08 17:05:03 - TARGET_ARCH=amd64 TB --- 2011-10-08 17:05:03 - TZ=UTC TB --- 2011-10-08 17:05:03 - __MAKE_CONF=/dev/null TB --- 2011-10-08 17:05:03 - cd /src TB --- 2011-10-08 17:05:03 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Sat Oct 8 17:05:03 UTC 2011 stage 1: configuring the kernel [...] WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated maestro3 headers WARNING: kernel contains GPL contaminated ReiserFS filesystem WARNING: kernel contains GPL contaminated xfs filesystem config: Error: device exphy is unknown config: Error: device inphy is unknown config: Error: device ruephy is unknown config: 3 errors *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-08 17:05:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-08 17:05:03 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-10-08 17:05:03 - 7268.92 user 1431.29 system 9302.89 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports on 10.0-CURRENT: r226027 is incorrect fix
On 8 Oct 2011 00:45, Stanislav Sedov s...@freebsd.org wrote:
On Sat, 8 Oct 2011 02:03:37 +0300
Mykola Dzham i...@levsha.me mentioned:
Hi!
r226027 fix ( ... s/freebsd1\*)/SHOULDNOTMATCHANYTHING1)/ ...) is
incorrect: this commit breaks metaports building:
# cd /usr/ports/print/teTeX sudo make clean all
=== Cleaning for teTeX-3.0_5
=== License check disabled, port has not defined LICENSE
=== Found saved configuration for teTeX-3.0_2
=== Extracting for teTeX-3.0_5
=== Patching for teTeX-3.0_5
=== Configuring for teTeX-3.0_5
find /tmp/ports/usr/ports/print/teTeX/work/teTeX-3.0 -type f \( -name
config.libpath -o -name config.rpath -o -name configure -o -name libtool.m4
\) -exec sed -i '' -e 's/freebsd1\*)/SHOULDNOTMATCHANYTHING1)/' -e
's/freebsd\[123\]\*)/SHOULDNOTMATCHANYTHING2)/' {} +
find: /tmp/ports/usr/ports/print/teTeX/work/teTeX-3.0: No such file or
directory
*** Error code 1
Stop in /usr/ports/print/teTeX.
*** Error code 1
Stop in /usr/ports/print/teTeX.
I think this commit should be reverted. Using UNAME_r is less
destructive work around
Hi!
I just committed the fix that checks if the ${WRKSRC} directory exists
firts.
Last I heard, portmgr explicitly disapproved of this fix-- have I missed
something??? Erwin specifically said not to do it.
Since when can anyone just commit stuff to bsd.port.mk, regardless of its
location?
This is a bad solution, please revert it or I will when I get back. We're
going to end up being asked to support it on ports@ otherwise.
Chris
___
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: ports on 10.0-CURRENT: r226027 is incorrect fix
On 8 Oct 2011 00:45, Stanislav Sedov s...@freebsd.org wrote:
On Sat, 8 Oct 2011 02:03:37 +0300
Mykola Dzham i...@levsha.me mentioned:
Hi!
r226027 fix ( ... s/freebsd1\*)/SHOULDNOTMATCHANYTHING1)/ ...) is
incorrect: this commit breaks metaports building:
# cd /usr/ports/print/teTeX sudo make clean all
=== Cleaning for teTeX-3.0_5
=== License check disabled, port has not defined LICENSE
=== Found saved configuration for teTeX-3.0_2
=== Extracting for teTeX-3.0_5
=== Patching for teTeX-3.0_5
=== Configuring for teTeX-3.0_5
find /tmp/ports/usr/ports/print/teTeX/work/teTeX-3.0 -type f \( -name
config.libpath -o -name config.rpath -o -name configure -o -name libtool.m4
\) -exec sed -i '' -e 's/freebsd1\*)/SHOULDNOTMATCHANYTHING1)/' -e
's/freebsd\[123\]\*)/SHOULDNOTMATCHANYTHING2)/' {} +
find: /tmp/ports/usr/ports/print/teTeX/work/teTeX-3.0: No such file or
directory
*** Error code 1
Stop in /usr/ports/print/teTeX.
*** Error code 1
Stop in /usr/ports/print/teTeX.
I think this commit should be reverted. Using UNAME_r is less
destructive work around
Hi!
I just committed the fix that checks if the ${WRKSRC} directory exists
firts.
Last I heard, portmgr explicitly disapproved of this fix-- have I missed
something??? Erwin specifically said not to do it.
Since when can anyone just commit stuff to bsd.port.mk, regardless of its
location?
This is a bad solution, please revert it or I will when I get back. We're
going to end up being asked to support it on ports@ otherwise.
Chris
___
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: aliasing (or renaming) kern.geom.debugflags
Hi, On Sat, Oct 8, 2011 at 12:52 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message cacqu3muqq6xqtfxhve1jtu4aey3kcdktcprd7ojq3ourdc8...@mail.gmail.com , Arnaud Lacombe writes: User do not care to understand the meaning of an option, you leave a hole somewhere, it will be used. I'm not even speaking about security issue here... There is a big difference between having an emergency hatch that gives you a chance to escape certain death by running across a shooting range, and on posting a sign telling people to use it as a short-cut. I will certainly never ask you to draw blueprints for a shooting range. There is NO legitimacy whatsoever for an emergency hatch to pass though the firing line. - Arnaud ___ 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: aliasing (or renaming) kern.geom.debugflags
On Sat, Oct 8, 2011 at 11:08 AM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Sat, Oct 8, 2011 at 12:52 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message cacqu3muqq6xqtfxhve1jtu4aey3kcdktcprd7ojq3ourdc8...@mail.gmail.com , Arnaud Lacombe writes: User do not care to understand the meaning of an option, you leave a hole somewhere, it will be used. I'm not even speaking about security issue here... There is a big difference between having an emergency hatch that gives you a chance to escape certain death by running across a shooting range, and on posting a sign telling people to use it as a short-cut. I will certainly never ask you to draw blueprints for a shooting range. There is NO legitimacy whatsoever for an emergency hatch to pass though the firing line. Certain groups do use this emergency hatch in production to get past safeguards and purposely zero out disks. Granted, it's an ill-advised procedure for most end-users. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Memstick image differences between 8.x and 9.x
Hello, a while ago I downloaded a then current FreeBSD 9 current memstick image and wrote it to an USB pen drive. It didn't boot, but also showed no error. It just did not appear in the list of devices to boot from, after pressing F12 after POST on this box. I thought maybe the pen drive was bad or unbootable or something, and forgot about it. This was for playing around with ZFS, so I went with FreeBSD 8.1 back then. No problems. With FreeBSD 9.0-BETA3 I tried again on another pen drive (known to work ok), same result. It just does not appear in the list of devices to boot from when pressing F12 after POST. Are there any general structural differences between FreeBSD 8 and 9 memstick images which could be at fault here? I didn't really investigate this issue any further than described, just being curious. Regards, Thomas ___ 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: Memstick image differences between 8.x and 9.x
On Sat, Oct 8, 2011 at 8:52 AM, Thomas K. f...@gothschlampen.com wrote: Hello, a while ago I downloaded a then current FreeBSD 9 current memstick image and wrote it to an USB pen drive. It didn't boot, but also showed no error. It just did not appear in the list of devices to boot from, after pressing F12 after POST on this box. I thought maybe the pen drive was bad or unbootable or something, and forgot about it. This was for playing around with ZFS, so I went with FreeBSD 8.1 back then. No problems. With FreeBSD 9.0-BETA3 I tried again on another pen drive (known to work ok), same result. It just does not appear in the list of devices to boot from when pressing F12 after POST. Are there any general structural differences between FreeBSD 8 and 9 memstick images which could be at fault here? I didn't really investigate this issue any further than described, just being curious. The new memstick image uses GPT instead of MBR partitioning. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: aliasing (or renaming) kern.geom.debugflags
Hi, On Sat, Oct 8, 2011 at 2:11 PM, Garrett Cooper yaneg...@gmail.com wrote: On Sat, Oct 8, 2011 at 11:08 AM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Sat, Oct 8, 2011 at 12:52 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message cacqu3muqq6xqtfxhve1jtu4aey3kcdktcprd7ojq3ourdc8...@mail.gmail.com , Arnaud Lacombe writes: User do not care to understand the meaning of an option, you leave a hole somewhere, it will be used. I'm not even speaking about security issue here... There is a big difference between having an emergency hatch that gives you a chance to escape certain death by running across a shooting range, and on posting a sign telling people to use it as a short-cut. I will certainly never ask you to draw blueprints for a shooting range. There is NO legitimacy whatsoever for an emergency hatch to pass though the firing line. Certain groups do use this emergency hatch in production to get past safeguards and purposely zero out disks. Granted, it's an ill-advised procedure for most end-users. Then it is not an emergency hatch. Using an emergency hatch in non emergency, or emergency-drill, situation is in most case strictly forbidden. It would rather be a service hatch. In which case, that part of geom is just badly designed. - Arnaud ___ 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: aliasing (or renaming) kern.geom.debugflags
In message CACqU3MUT36PVxP2hMuizTxYLcuTkBQ_fOfrELit=7ueq-hv...@mail.gmail.com , Arnaud Lacombe writes: Arnaud, Are we done here ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: cvs commit: ports/security/cyrus-sasl2 Makefile ports/security/cyrus-sasl2/files patch-plugins::gssapi.c
On 10/07/11 19:48, Doug Barton wrote: In case anyone wants to take this on, this port fails to install on 10.0 because it uses its own version of libtool. I took a quick look but there wasn't a solution obvious enough for me. :) This appears to have been fixed by the (reversion of a) change to bsd.port.mk in SVN r226162 - I still used the UNAME_r kludge, however, 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: cvs commit: ports/security/cyrus-sasl2 Makefile ports/security/cyrus-sasl2/files patch-plugins::gssapi.c
On 8 Oct 2011 20:34, Michael Butler i...@protected-networks.net wrote: On 10/07/11 19:48, Doug Barton wrote: In case anyone wants to take this on, this port fails to install on 10.0 because it uses its own version of libtool. I took a quick look but there wasn't a solution obvious enough for me. :) This appears to have been fixed by the (reversion of a) change to bsd.port.mk in SVN r226162 - I still used the UNAME_r kludge, however, r226162 has been reverted for now, so your fix is still relevant. Chris ___ 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: aliasing (or renaming) kern.geom.debugflags
Hi, On Sat, Oct 8, 2011 at 3:10 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message CACqU3MUT36PVxP2hMuizTxYLcuTkBQ_fOfrELit=7ueq-hv...@mail.gmail.com , Arnaud Lacombe writes: Arnaud, Are we done here ? 'your call. A. ___ 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: RFC: Project geom-events
On Oct 8, 2011, at 12:05 , Lev Serebryakov wrote: Hello, Ivan. You wrote 8 октября 2011 г., 0:23:14: If you think this should be explicitely handled, please file a PR which requests the modification of gpart so that it detects that a GPT is being created in anything other than a raw drive, and warns the user. It should be mentioned in documentation, at least. But how people will create bootable gmirror installation in such case? Make (many) mirrors from parts? I don't like this idea... Good example of what I would call laziness -- other would call it hacking I guess. Either way, the solution we have now is permitting some exotic setups, but is fragile and is not consistent. Most of the useful features are actually side effects of the hack. If it should remain this way, a warning in the documentation and at runtime is very helpful. Daniel___ 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
Panics after AHCI timeouts
Hello list!
In the view of upcoming RELEASE-9.0 I should have reported it earlier,
but it is better later than never... Every time I wanted to report
this, the system was ~one month old and I tried to upgrade it
to see, if the problem was still there, waiting for the next panic...
and when it finally paniced it was one month old again.
For some time (around half a year actually :) under some heavy disk load
my desktop panics. The panics are not 100% reproducible, two situations
which could lead to a panic are:
- svn up in /usr/src
- last stage of openoffice building (I think, during the packaging stage)
Updating the sources is less probable to panic the system (I would give
~30% of probability), but building OOO is close to 100% to cause the panic.
The root cause seems to be the Samsung hard drive in use -
it times out on some NCQ slots under heavy load.
Same problem is reported, for example here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/157397
Earlier this year (I would say March - May), AHCI handled these timeouts,
at least to the point when the disk (and, possibly, the controlled too)
were completely wedged (only power cycling had brought them back again,
reset was not sufficient). From ~June, however, the system paniced
right after the first timeout. So it is this panic immediately after ahci
timeout which could be hopefully fixed.
Some info about the system:
~ uname -a
FreeBSD lexx.ifp.tuwien.ac.at 9.0-BETA2 FreeBSD 9.0-BETA2 #0 r225311: Thu Sep
1 17:17:57 CEST 2011
r...@lexx.ifp.tuwien.ac.at:/usr/obj/usr/src/sys/GENERIC amd64
From dmesg.boot:
[snip]
ahci0: ATI IXP700 AHCI SATA controller port
0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem
0xfe5ffc00-0xfe5f irq 19 at device 17.0 on pci0
ahci0: AHCI v1.20 with 6 6Gbps ports, Port Multiplier supported
ahcich0: AHCI channel at channel 0 on ahci0
ahcich1: AHCI channel at channel 1 on ahci0
ahcich2: AHCI channel at channel 2 on ahci0
ahcich3: AHCI channel at channel 3 on ahci0
ahcich4: AHCI channel at channel 4 on ahci0
ahcich5: AHCI channel at channel 5 on ahci0
[snip]
ada0 at ahcich0 bus 0 scbus1 target 0 lun 0
ada0: SAMSUNG HD204UI 1AQ10001 ATA-8 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad4
[snip]
~ cat /etc/rc.local
#!/bin/sh
ddb script kdb.enter.panic=capture on; show pcpu; trace; ps; show locks;
alltrace; show alllocks; show lockedvnods; call doadump; reset
sysctl debug.debugger_on_panic=0
I have two cores:
~ ll /var/crash/
total 2628524
-rw-r--r-- 1 root wheel 2 Oct 7 15:12 bounds
-rw-r- 1 root wheel 224897 Aug 5 18:07 core.txt.3
-rw-r- 1 root wheel 151478 Oct 7 15:13 core.txt.5
-rw-r- 1 root wheel 475 Aug 5 18:06 info.3
-rw-r- 1 root wheel 478 Oct 7 15:12 info.5
-rw-r--r-- 1 root wheel 5 Jan 26 2011 minfree
-rw-r- 1 root wheel 1390616576 Aug 5 18:07 vmcore.3
-rw-r- 1 root wheel 1371832320 Oct 7 15:13 vmcore.5
However, I do not have the old kernel for the core N 3 anymore
(but the current kernel is the one which produced core N 5).
From core.txt.3:
[snip]
Unread portion of the kernel message buffer:
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x8092988e
stack pointer = 0x28:0xff8000256a80
frame pointer = 0x28:0xff8000256aa0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi4: clock)
trap number = 9
panic: general protection fault
cpuid = 0
VNASSERT failed
Uptime: 0xfe0073591780: 3dtag ufs, type VDIR
7h59musecount 1, writecount 0, refcount 4 mountedhere 0
45s
flags ()
v_object 0xfe00888501b0 ref 0 pages 1
lock type ufs: UNLOCKED
ino 2709060, on dev ada0p6
VNASSERT failed
0xfe0073591780: tag ufs, type VDIR
usecount 1, writecount 0, refcount 4 mountedhere 0
flags ()
v_object 0xfe00888501b0 ref 0 pages 1
lock type ufs: UNLOCKED
ino 2709060, on dev ada0p6
Dumping 1326 out of 7914 MB:..2%..11%..21%..31%..42%..51%..61%..72%..81%..91%
[snip]
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:252
252 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:252
#1 0x8081f3ca in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:430
#2 0x8081ee61 in panic (fmt=Variable fmt is not available.
)
at /usr/src/sys/kern/kern_shutdown.c:595
#3 0x80b04b70 in trap_fatal (frame=0x9, eva=Variable eva is not
available.
)
at /usr/src/sys/amd64/amd64/trap.c:805
#4 0x80b05145 in
Re: Memstick image differences between 8.x and 9.x
On 10/8/11 2:21 PM, Garrett Cooper wrote: Are there any general structural differences between FreeBSD 8 and 9 memstick images which could be at fault here? The new memstick image uses GPT instead of MBR partitioning. GPT should have no impact on booting from the memory stick, as far as I am aware. Thomas, can you please zero out the beginning of the 1024 bytes of your memory stick, as follows (please take care to note the actual device for your memory stick, and change '/dev/da0' below, as appropriate): dd if=/dev/zero of=/dev/da0 bs=1024 count=1 Then re-write the memory stick per the instructions in the Handbook. Newly added to this section of the Handbook was a note to ensure the device is _not_ mounted (either manually, or automatically). http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-pre.html#INSTALL-BOOT-MEDIA Please let us know if this helps. -- Glen Barber | g...@freebsd.org FreeBSD Documentation Project ___ 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: Experiences with FreeBSD 9.0-BETA2
* Greg Miller greglmil...@gmail.com, 20111008 22:47: I've never gotten around to reporting this until this thread came up, but I've found that GNU Emacs has tons of problems with text disappearing on the console. Just moving the cursor to the start of a long line and holding down the right-arrow key is enough to cause many of the characters to disappear. Can you try applying the patch I mentioned previously? If it doesn't fix this issue, please let me know, so I can get it fixed in 9.0. Thanks! -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgp25SMDbLIhI.pgp Description: PGP signature
[head tinderbox] failure on i386/i386
TB --- 2011-10-08 19:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-08 19:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-08 19:10:00 - cleaning the object tree TB --- 2011-10-08 19:10:16 - cvsupping the source tree TB --- 2011-10-08 19:10:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-08 19:10:54 - building world TB --- 2011-10-08 19:10:54 - CROSS_BUILD_TESTING=YES TB --- 2011-10-08 19:10:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-08 19:10:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-08 19:10:54 - SRCCONF=/dev/null TB --- 2011-10-08 19:10:54 - TARGET=i386 TB --- 2011-10-08 19:10:54 - TARGET_ARCH=i386 TB --- 2011-10-08 19:10:54 - TZ=UTC TB --- 2011-10-08 19:10:54 - __MAKE_CONF=/dev/null TB --- 2011-10-08 19:10:54 - cd /src TB --- 2011-10-08 19:10:54 - /usr/bin/make -B buildworld World build started on Sat Oct 8 19:10:55 UTC 2011 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 Oct 8 21:13:57 UTC 2011 TB --- 2011-10-08 21:13:58 - generating LINT kernel config TB --- 2011-10-08 21:13:58 - cd /src/sys/i386/conf TB --- 2011-10-08 21:13:58 - /usr/bin/make -B LINT TB --- 2011-10-08 21:13:58 - cd /src/sys/i386/conf TB --- 2011-10-08 21:13:58 - /usr/sbin/config -m LINT-NOINET TB --- 2011-10-08 21:13:58 - building LINT-NOINET kernel TB --- 2011-10-08 21:13:58 - CROSS_BUILD_TESTING=YES TB --- 2011-10-08 21:13:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-08 21:13:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-08 21:13:58 - SRCCONF=/dev/null TB --- 2011-10-08 21:13:58 - TARGET=i386 TB --- 2011-10-08 21:13:58 - TARGET_ARCH=i386 TB --- 2011-10-08 21:13:58 - TZ=UTC TB --- 2011-10-08 21:13:58 - __MAKE_CONF=/dev/null TB --- 2011-10-08 21:13:58 - cd /src TB --- 2011-10-08 21:13:58 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Sat Oct 8 21:13:58 UTC 2011 stage 1: configuring the kernel [...] WARNING: kernel contains GPL contaminated maestro3 headers WARNING: kernel contains GPL contaminated ReiserFS filesystem WARNING: kernel contains GPL contaminated xfs filesystem WARNING: COMPAT_SVR4 is broken and should be avoided config: Error: device exphy is unknown config: Error: device inphy is unknown config: Error: device ruephy is unknown config: 3 errors *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-08 21:13:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-08 21:13:58 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-10-08 21:13:58 - 5964.92 user 1038.24 system 7437.83 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Experiences with FreeBSD 9.0-BETA2
On 10/7/11, Ed Schouten e...@80386.nl wrote: Well, apart from small bugs here and there, it should be pretty conformant already, especially when compared to various graphical terminal emulators (e.g. GNOME terminal). For example, it passes quite a large number of tests from vttest. I've never gotten around to reporting this until this thread came up, but I've found that GNU Emacs has tons of problems with text disappearing on the console. Just moving the cursor to the start of a long line and holding down the right-arrow key is enough to cause many of the characters to disappear. ___ 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: flash for 9-beta3
On 10/8/11, Nenhum_de_Nos math...@eternamente.info wrote: as recently had issues in this regard, to install it can I just use http://www.freebsd.org/doc/handbook/desktop-browsers.html or there is another guide ? I've just noticed that I never actually added the symbolic link, but I've otherwise followed the 8.x instructions you linked to in the handbook, and my Flash is working nicely on 9.0B3. ___ 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: flash for 9-beta3
On Sat, Oct 8, 2011 at 2:21 PM, Greg Miller greglmil...@gmail.com wrote: On 10/8/11, Nenhum_de_Nos math...@eternamente.info wrote: as recently had issues in this regard, to install it can I just use http://www.freebsd.org/doc/handbook/desktop-browsers.html or there is another guide ? I've just noticed that I never actually added the symbolic link, but I've otherwise followed the 8.x instructions you linked to in the handbook, and my Flash is working nicely on 9.0B3. Every time you update the port, you must re-run nspluginwrapper. Seems like the port itself is sort of broken by not doing this by default with the post-install script. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Memstick image differences between 8.x and 9.x
On Sat, 8 Oct 2011, Glen Barber wrote: On 10/8/11 2:21 PM, Garrett Cooper wrote: Are there any general structural differences between FreeBSD 8 and 9 memstick images which could be at fault here? The new memstick image uses GPT instead of MBR partitioning. GPT should have no impact on booting from the memory stick, as far as I am aware. Memory stick should not be a problem, but some of the Lenovo notebooks hate GPT, even with a PMBR: http://forums.freebsd.org/showthread.php?t=26304 http://forums.freebsd.org/showthread.php?t=26759 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on amd64/amd64
TB --- 2011-10-08 19:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-08 19:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-08 19:10:00 - cleaning the object tree TB --- 2011-10-08 19:10:22 - cvsupping the source tree TB --- 2011-10-08 19:10:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-08 19:10:54 - building world TB --- 2011-10-08 19:10:54 - CROSS_BUILD_TESTING=YES TB --- 2011-10-08 19:10:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-08 19:10:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-08 19:10:54 - SRCCONF=/dev/null TB --- 2011-10-08 19:10:54 - TARGET=amd64 TB --- 2011-10-08 19:10:54 - TARGET_ARCH=amd64 TB --- 2011-10-08 19:10:54 - TZ=UTC TB --- 2011-10-08 19:10:54 - __MAKE_CONF=/dev/null TB --- 2011-10-08 19:10:54 - cd /src TB --- 2011-10-08 19:10:54 - /usr/bin/make -B buildworld World build started on Sat Oct 8 19:10:55 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Sat Oct 8 21:45:38 UTC 2011 TB --- 2011-10-08 21:45:38 - generating LINT kernel config TB --- 2011-10-08 21:45:38 - cd /src/sys/amd64/conf TB --- 2011-10-08 21:45:38 - /usr/bin/make -B LINT TB --- 2011-10-08 21:45:38 - cd /src/sys/amd64/conf TB --- 2011-10-08 21:45:38 - /usr/sbin/config -m LINT-NOINET TB --- 2011-10-08 21:45:38 - building LINT-NOINET kernel TB --- 2011-10-08 21:45:38 - CROSS_BUILD_TESTING=YES TB --- 2011-10-08 21:45:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-08 21:45:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-08 21:45:38 - SRCCONF=/dev/null TB --- 2011-10-08 21:45:38 - TARGET=amd64 TB --- 2011-10-08 21:45:38 - TARGET_ARCH=amd64 TB --- 2011-10-08 21:45:38 - TZ=UTC TB --- 2011-10-08 21:45:38 - __MAKE_CONF=/dev/null TB --- 2011-10-08 21:45:38 - cd /src TB --- 2011-10-08 21:45:38 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Sat Oct 8 21:45:38 UTC 2011 stage 1: configuring the kernel [...] WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated maestro3 headers WARNING: kernel contains GPL contaminated ReiserFS filesystem WARNING: kernel contains GPL contaminated xfs filesystem config: Error: device exphy is unknown config: Error: device inphy is unknown config: Error: device ruephy is unknown config: 3 errors *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-08 21:45:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-08 21:45:39 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-10-08 21:45:39 - 7328.45 user 1421.82 system 9338.19 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: flash for 9-beta3
On Sat, 8 Oct 2011, Garrett Cooper wrote: On Sat, Oct 8, 2011 at 2:21 PM, Greg Miller greglmil...@gmail.com wrote: On 10/8/11, Nenhum_de_Nos math...@eternamente.info wrote: as recently had issues in this regard, to install it can I just use http://www.freebsd.org/doc/handbook/desktop-browsers.html or there is another guide ? I've just noticed that I never actually added the symbolic link, but I've otherwise followed the 8.x instructions you linked to in the handbook, and my Flash is working nicely on 9.0B3. Every time you update the port, you must re-run nspluginwrapper. Seems like the port itself is sort of broken by not doing this by default with the post-install script. nspluginwrapper needs to be run as the end user. The port post-install could loop through all users looking for links to update, but that seems questionably secure. A script that makes it easier but doesn't run automatically, like perl-after-upgrade, maybe. ___ 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: Memstick image differences between 8.x and 9.x
On 10/8/11 5:40 PM, Warren Block wrote: On Sat, 8 Oct 2011, Glen Barber wrote: On 10/8/11 2:21 PM, Garrett Cooper wrote: Are there any general structural differences between FreeBSD 8 and 9 memstick images which could be at fault here? The new memstick image uses GPT instead of MBR partitioning. GPT should have no impact on booting from the memory stick, as far as I am aware. Memory stick should not be a problem, but some of the Lenovo notebooks hate GPT, even with a PMBR: http://forums.freebsd.org/showthread.php?t=26304 http://forums.freebsd.org/showthread.php?t=26759 Ugh, that's annoying. I'm half-tempted to note this in the new installer chapter, but I don't like the idea of such edge cases as these to effectively turn that page into a pseudo-HCL. Maybe this should be noted somewhere in the wiki... -- Glen Barber | g...@freebsd.org FreeBSD Documentation Project signature.asc Description: OpenPGP digital signature
Re: Memstick image differences between 8.x and 9.x
On Sat, 8 Oct 2011, Glen Barber wrote: On 10/8/11 5:40 PM, Warren Block wrote: On Sat, 8 Oct 2011, Glen Barber wrote: On 10/8/11 2:21 PM, Garrett Cooper wrote: Are there any general structural differences between FreeBSD 8 and 9 memstick images which could be at fault here? The new memstick image uses GPT instead of MBR partitioning. GPT should have no impact on booting from the memory stick, as far as I am aware. Memory stick should not be a problem, but some of the Lenovo notebooks hate GPT, even with a PMBR: http://forums.freebsd.org/showthread.php?t=26304 http://forums.freebsd.org/showthread.php?t=26759 Ugh, that's annoying. I'm half-tempted to note this in the new installer chapter, but I don't like the idea of such edge cases as these to effectively turn that page into a pseudo-HCL. There are already a couple of notes about having to use MBR with XP and other older operating systems. But instead of updating them, I'd rather see somebody with one of the affected systems contact somebody with influence at Lenovo and say hey, the FreeBSD guys are talking about making your broken GPT support famous followed quickly by a BIOS update. ___ 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: flash for 9-beta3
On 10/08/2011 14:53, Warren Block wrote: nspluginwrapper needs to be run as the end user. The pkg-message tells them to do that. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: Memstick image differences between 8.x and 9.x
On Oct 9, 2011 8:52 AM, Warren Block wbl...@wonkity.com wrote: On Sat, 8 Oct 2011, Glen Barber wrote: On 10/8/11 5:40 PM, Warren Block wrote: On Sat, 8 Oct 2011, Glen Barber wrote: On 10/8/11 2:21 PM, Garrett Cooper wrote: Are there any general structural differences between FreeBSD 8 and 9 memstick images which could be at fault here? The new memstick image uses GPT instead of MBR partitioning. GPT should have no impact on booting from the memory stick, as far as I am aware. Memory stick should not be a problem, but some of the Lenovo notebooks hate GPT, even with a PMBR: http://forums.freebsd.org/showthread.php?t=26304 http://forums.freebsd.org/showthread.php?t=26759 Ugh, that's annoying. I'm half-tempted to note this in the new installer chapter, but I don't like the idea of such edge cases as these to effectively turn that page into a pseudo-HCL. There are already a couple of notes about having to use MBR with XP and other older operating systems. But instead of updating them, I'd rather see somebody with one of the affected systems contact somebody with influence at Lenovo and say hey, the FreeBSD guys are talking about making your broken GPT support famous followed quickly by a BIOS update. I believe this is actually a case of the memstick image being an improperly formatted GPT as there is no backup partition table at the end of the volume. The only sensible answer is to not use GPT for the memstick image. I not said this,loud enough yet but this is a show stopper for 9.0-RELEASE and must be fixed. We can't have a major release that modern systems cannot install with one of now most popular install methods. As a first step, Andriy Gapon has provided a quick patch for makefs(8) so it can create filesystems with UFS labels (as bsdinstall relys on labels). If you want to fix your memstick, create a copy of the partition table at the end of the volume and it should boot. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-BETA 3 lock order reversal
On Sat, 8 Oct 2011, Roar Pettersen wrote: Hello ! Just did a new build of world kernel, and the error message have changed a bit : lock order reversal: 1st 0xddf0c4cc bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 2nd 0xc4996200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 Hi Roar, Both of these look to be well-known (i.e. trivially reproduced) LORs. No one seems to have been willing to step up to disable the warnings for them or otherwise eliminate them, though, so they still pop up and surprise people. Thanks for taking the time to report them, and sorry that they've been sitting untouched for so long. -Ben Kaduk [0] http://ipv4.sources.zabbadoz.net/freebsd/lor.html ___ 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: Memstick image differences between 8.x and 9.x
On 10/08/11 19:25, Matt Thyer wrote: On Oct 9, 2011 8:52 AM, Warren Blockwbl...@wonkity.com wrote: On Sat, 8 Oct 2011, Glen Barber wrote: On 10/8/11 5:40 PM, Warren Block wrote: On Sat, 8 Oct 2011, Glen Barber wrote: On 10/8/11 2:21 PM, Garrett Cooper wrote: Are there any general structural differences between FreeBSD 8 and 9 memstick images which could be at fault here? The new memstick image uses GPT instead of MBR partitioning. GPT should have no impact on booting from the memory stick, as far as I am aware. Memory stick should not be a problem, but some of the Lenovo notebooks hate GPT, even with a PMBR: http://forums.freebsd.org/showthread.php?t=26304 http://forums.freebsd.org/showthread.php?t=26759 Ugh, that's annoying. I'm half-tempted to note this in the new installer chapter, but I don't like the idea of such edge cases as these to effectively turn that page into a pseudo-HCL. There are already a couple of notes about having to use MBR with XP and other older operating systems. But instead of updating them, I'd rather see somebody with one of the affected systems contact somebody with influence at Lenovo and say hey, the FreeBSD guys are talking about making your broken GPT support famous followed quickly by a BIOS update. I believe this is actually a case of the memstick image being an improperly formatted GPT as there is no backup partition table at the end of the volume. The only sensible answer is to not use GPT for the memstick image. I not said this,loud enough yet but this is a show stopper for 9.0-RELEASE and must be fixed. We can't have a major release that modern systems cannot install with one of now most popular install methods. As a first step, Andriy Gapon has provided a quick patch for makefs(8) so it can create filesystems with UFS labels (as bsdinstall relys on labels). If you want to fix your memstick, create a copy of the partition table at the end of the volume and it should boot. It is being fixed, pending Andriy's change getting into the tree, which should be soon, and will end up being used for the next build (which I believe is RC1). There is also the interesting question of actually installing to GPT on the hard disk, which is the default in 9.0. Does this not work on some systems? If so, do we want to blacklist them and use a different default partition scheme? Can we identify systems that violate regular PC boot standards and reject GPT? Any data on any of these points would be appreciated. -Nathan ___ 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: Memstick image differences between 8.x and 9.x
On Oct 9, 2011 11:04 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 10/08/11 19:25, Matt Thyer wrote: I believe this is actually a case of the memstick image being an improperly formatted GPT as there is no backup partition table at the end of the volume. The only sensible answer is to not use GPT for the memstick image. I've not said this loud enough yet but this is a show stopper for 9.0-RELEASE and must be fixed. We can't have a major release that modern systems cannot install with one of the now most popular install methods. As a first step, Andriy Gapon has provided a quick patch for makefs(8) so it can create filesystems with UFS labels (as bsdinstall relys on labels). If you want to fix your memstick, create a copy of the partition table at the end of the volume and it should boot. It is being fixed, pending Andriy's change getting into the tree, which should be soon, and will end up being used for the next build (which I believe is RC1). There is also the interesting question of actually installing to GPT on the hard disk, which is the default in 9.0. Does this not work on some systems? If so, do we want to blacklist them and use a different default partition scheme? Can we identify systems that violate regular PC boot standards and reject GPT? Any data on any of these points would be appreciated. -Nathan I don't think there have been any reports of failure to boot properly formatted GPT yet. ___ 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: Memstick image differences between 8.x and 9.x
On Sun, 9 Oct 2011, Matt Thyer wrote: On Oct 9, 2011 11:04 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 10/08/11 19:25, Matt Thyer wrote: There is also the interesting question of actually installing to GPT on the hard disk, which is the default in 9.0. Does this not work on some systems? If so, do we want to blacklist them and use a different default partition scheme? Can we identify systems that violate regular PC boot standards and reject GPT? Any data on any of these points would be appreciated. I don't think there have been any reports of failure to boot properly formatted GPT yet. Lenovo T420S and T520, from the links above. Install GPT on the hard drive, try to boot. http://forums.freebsd.org/showthread.php?t=26304 http://forums.freebsd.org/showthread.php?t=26759 http://forum.thinkpads.com/viewtopic.php?f=9t=98078 ___ 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: Memstick image differences between 8.x and 9.x
On 9 October 2011 04:38, Glen Barber g...@freebsd.org wrote: GPT should have no impact on booting from the memory stick, as far as I am aware. I've already emailed -current with an example where GPT+memstick == fail. Some theories include that GPT/EFT on USB is what the BIOS expects when doing BIOS reflashing, and gets confused when something else is there. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Memstick image differences between 8.x and 9.x
On 10/8/11 10:00 PM, Adrian Chadd wrote: On 9 October 2011 04:38, Glen Barber g...@freebsd.org wrote: GPT should have no impact on booting from the memory stick, as far as I am aware. I've already emailed -current with an example where GPT+memstick == fail. Some theories include that GPT/EFT on USB is what the BIOS expects when doing BIOS reflashing, and gets confused when something else is there. Yep, and I also recall you bringing this up in IRC. Though, at that time (well, up until a few hours ago), I wasn't aware of the Lenovo issue Warren mentioned. So, that said, I happily stand corrected. I am now aware of a few GPT memstick issues. :) -- Glen Barber | g...@freebsd.org FreeBSD Documentation Project signature.asc Description: OpenPGP digital signature
Re: Memstick image differences between 8.x and 9.x
On 9 October 2011 10:15, Glen Barber g...@freebsd.org wrote: Yep, and I also recall you bringing this up in IRC. Though, at that time (well, up until a few hours ago), I wasn't aware of the Lenovo issue Warren mentioned. So, that said, I happily stand corrected. I am now aware of a few GPT memstick issues. :) Can we please flip off GPT partitions for memstick images?: ) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Memstick image differences between 8.x and 9.x
On Sat, Oct 08, 2011 at 04:38:09PM -0400, Glen Barber wrote: Thomas, can you please zero out the beginning of the 1024 bytes of your memory stick, as follows (please take care to note the actual device for your memory stick, and change '/dev/da0' below, as appropriate): dd if=/dev/zero of=/dev/da0 bs=1024 count=1 Then re-write the memory stick per the instructions in the Handbook. Newly added to this section of the Handbook was a note to ensure the device is _not_ mounted (either manually, or automatically). So you want me to clear the first 1K bytes, and then write the whole image back to the pen drive, did I get this right? If so, I don't understand what we're trying to archive here, maybe you could explain? Anyway, I read it wrong the first time and did the following: I just cleared the first 1K of the stick as it was (with BETA3 image on it), and then put it in when rebooting the box and pressing F12 to get to the boot device list. Without the GPT it showed up in the list, but of course was unbootable when choosen. I then wrote back the 1K with dd if=FreeBSD-9... of=/dev/sde bs=1024 count=1 and verified the stick to be ok with a cmp(1) of the device file vs. the image file, so the pendrive is in the fresh state it should be. When plugging it in under Linux I get the following: [232309.636200] usb 1-1.1: new high speed USB device number 5 using ehci_hcd [232309.730109] scsi9 : usb-storage 1-1.1:1.0 [232310.729101] scsi 9:0:0:0: Direct-Access Ut165USB2FlashStorage 0.00 PQ: 0 ANSI: 2 [232310.904549] sd 9:0:0:0: Attached scsi generic sg5 type 0 [232310.905449] sd 9:0:0:0: [sde] 3948544 512-byte logical blocks: (2.02 GB/1.88 GiB) [232310.906657] sd 9:0:0:0: [sde] Write Protect is off [232310.906663] sd 9:0:0:0: [sde] Mode Sense: 00 00 00 00 [232310.907303] sd 9:0:0:0: [sde] Asking for cache data failed [232310.907308] sd 9:0:0:0: [sde] Assuming drive cache: write through [232310.909803] sd 9:0:0:0: [sde] Asking for cache data failed [232310.909808] sd 9:0:0:0: [sde] Assuming drive cache: write through [232311.031811] GPT:Primary header thinks Alt. header is not at the end of the disk. [232311.031825] GPT:1339319 != 3948543 [232311.031827] GPT:Alternate GPT header not at the end of the disk. [232311.031829] GPT:1339319 != 3948543 [232311.031830] GPT: Use GNU Parted to correct GPT errors. [232311.031845] sde: sde1 sde2 [232311.034154] sd 9:0:0:0: [sde] Asking for cache data failed [232311.034160] sd 9:0:0:0: [sde] Assuming drive cache: write through [232311.034165] sd 9:0:0:0: [sde] Attached SCSI removable disk [232312.081344] ufs was compiled with read-only support, can't be mounted as read-write Notice the GPT stuff. Of course that's because there can't possibly be an alternative GPT header at the end of the disk unless it's size is the same as the image size. As suggested I fixed it with parted and tried to boot from it again. No joy. I'm starting to believe this box just doesn't know GPT and the BIOS can't handle it at all. This is an Acer AX3960 Core i7 from maybe 6 months ago. Does anyone if the other BSDs have images using GPT, so I might verify? Regards, Thomas ___ 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: Memstick image differences between 8.x and 9.x
On Sat, Oct 08, 2011 at 07:28:55PM -0600, Warren Block wrote: On Sun, 9 Oct 2011, Matt Thyer wrote: On Oct 9, 2011 11:04 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 10/08/11 19:25, Matt Thyer wrote: There is also the interesting question of actually installing to GPT on the hard disk, which is the default in 9.0. Does this not work on some systems? If so, do we want to blacklist them and use a different default partition scheme? Can we identify systems that violate regular PC boot standards and reject GPT? Any data on any of these points would be appreciated. I don't think there have been any reports of failure to boot properly formatted GPT yet. Lenovo T420S and T520, from the links above. Install GPT on the hard drive, try to boot. http://forums.freebsd.org/showthread.php?t=26304 http://forums.freebsd.org/showthread.php?t=26759 http://forum.thinkpads.com/viewtopic.php?f=9t=98078 As I used parted from Linux to fix the alternate GPT, i.e. put it not at the end of the image data but on the end of the disk, and it still did not appear in the boot device list, the Acer AX3960 should probably be on the list as well. Being a Core i7 2600k system maybe 6 months old, it's rather recent hardware, but doesn't boot from the memstick image. Regards, Thomas ___ 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: Memstick image differences between 8.x and 9.x
On Sat, Oct 8, 2011 at 7:50 PM, Thomas K. f...@gothschlampen.com wrote: On Sat, Oct 08, 2011 at 07:28:55PM -0600, Warren Block wrote: On Sun, 9 Oct 2011, Matt Thyer wrote: On Oct 9, 2011 11:04 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 10/08/11 19:25, Matt Thyer wrote: There is also the interesting question of actually installing to GPT on the hard disk, which is the default in 9.0. Does this not work on some systems? If so, do we want to blacklist them and use a different default partition scheme? Can we identify systems that violate regular PC boot standards and reject GPT? Any data on any of these points would be appreciated. I don't think there have been any reports of failure to boot properly formatted GPT yet. Lenovo T420S and T520, from the links above. Install GPT on the hard drive, try to boot. http://forums.freebsd.org/showthread.php?t=26304 http://forums.freebsd.org/showthread.php?t=26759 http://forum.thinkpads.com/viewtopic.php?f=9t=98078 As I used parted from Linux to fix the alternate GPT, i.e. put it not at the end of the image data but on the end of the disk, and it still did not appear in the boot device list, the Acer AX3960 should probably be on the list as well. Being a Core i7 2600k system maybe 6 months old, it's rather recent hardware, but doesn't boot from the memstick image. MBR format would be a better idea considering that there are a number of catches to using GPT (as noted on the list), and we're probably not anywhere near producing 2TB+ images (yet :)..), and to quote Monty Python MBR: I'm not dead yet!. If it comes to that day and age, we could provide a script or standalone command that would do the gpart foo to write out the partition table and just copy the image to the first partition, correct? Seems like more OSes should run into this issue producing GPT partitioned media than just us.. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Memstick image differences between 8.x and 9.x
On 10/8/11 10:41 PM, Thomas K. wrote: On Sat, Oct 08, 2011 at 04:38:09PM -0400, Glen Barber wrote: Thomas, can you please zero out the beginning of the 1024 bytes of your memory stick, as follows (please take care to note the actual device for your memory stick, and change '/dev/da0' below, as appropriate): dd if=/dev/zero of=/dev/da0 bs=1024 count=1 Then re-write the memory stick per the instructions in the Handbook. Newly added to this section of the Handbook was a note to ensure the device is _not_ mounted (either manually, or automatically). So you want me to clear the first 1K bytes, and then write the whole image back to the pen drive, did I get this right? If so, I don't understand what we're trying to archive here, maybe you could explain? Mostly what I was getting at here was ensuring the first blocks of the memory stick did not contain actual data. Though, I fear other forces may be at play here with GPT... -- Glen Barber | g...@freebsd.org FreeBSD Documentation Project ___ 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
