9.0-BETA1 installer glithcies (i386)
Hello, Freebsd-current. Maybe, everything is reported already, but I think, that better I'll be second, that no-one notice this: Manual partitioning chosen (1) Installer offer me bunch of Partition schemes, but only MBR and BSD have sense. Why i386 installer offer me PC98 or PowerPC-based Apple partition schemes?! Why it offer GPT when system doesn't have UFI BIOS? I could be wrong about GPT, but APT and PC98-based variants should be disabled even in Manual mode, IMHO. (2) MBR Slice creation. Status line suggest freebsd-ufs and freebsd-swap as examples for Type field (which contains freebsd by default, but freebsd-ufs leads to Error: Invalid argument :) (3) Auto creates one big / partition + SWAP. It looks very not-BSD way (disk is only 8Gb, it is virtual machine). (4) Partition types again: IMHO, drop-down of filesystem types will be much better. It is not clear, is it possible to type zfs here, for example. (5) Partition creation dialog has button Options, but modify dialog doesn't. (6) Partition editor main panel: (a) Inconsistent sizes display. ada0 has size 8.0 GB but ada0s1 has size 8 GB. (b) No information about free size on device/slice. (7) Partition editor doesn't seen existing filesystems and doesn't warn about parititoning disks with existing filesystems. I have two (virtual) disks common for all my VMs -- with sources (one common disk per version) and with some scratch space (common for every my VM), FSes are created without any partitions or slices, directly on device nodes (ada1 and ada2). PArtition Editor doesn't have any sign or warning, that ada1 and ada2 contains valid FreeBSD filesystems. (8) After Exit from Partition Editor I expected some filesystem options selection (as here is no visible options on partition creation). NOPE. Also, it is impossible to set mount points for exisitng filesystems (see above about ada1 and ada2) (9) Lot of LORs on slice/partition creation and newfs. (10) Mistype password for Root for second type -- no message about it, simple New password: prompt. It is not obvious, what happens. (11) No way to mount NFS file systems :) -- // 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
Fwd: Re: Can *you* UFS snapshot a filesystem with 9.0-BETA1?
Le Thu, 18 Aug 2011 10:22:31 +0100, Hugo Silva h...@barafranca.com a écrit : Hello, I'm wondering. On a virtual machine (amd64 HVM+PV), it's crashing every time. Not sure if this is SNAFU, as I had never used ufs snapshots on freebsd before. After running mksnap_ffs, ssh stops working (a telnet session doesn't show the sshd banner). The ssh session where the command was run from stops responding, the webserver dies and xm console'ing from the dom0 works, but the VM is unresponsive (ie no login prompt on ENTER). Anyone else seeing the same? I've tried in a FreeBSD guest (9.0-beta1/i386) into VirtualBox and I see a LOR (or looks like a LOR), then the system is freezed. This is 100% reproductible. Unfortunatly, I'm not able to dump a panic or to break into the debugger, so a screenshot : http://user.lamaiziere.net/patrick/public/lormksnap.png You should ask on freebsd-current@ Regards. ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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
VirtualBox causes kernel panic
VirtualBox Version: 4.0.12_OSE r72916 uname -a: FreeBSD shuttle0.lan 9.0-BETA1 FreeBSD 9.0-BETA1 #1: Wed Aug 17 01:21:47 WEST 2011 net...@shuttle0.lan:/usr/obj/usr/src/sys/GALILEO amd64 The kernel panic is occurred when I start a virtual machine with boot from CD/DVD burner/reader device. With or without passthrough. Kernel panic http://pastie.org/private/0nxanttdmtc9zvtllg0rw atapicam is loaded and hald is working. -- netSys-- http://www.byteandbit.info ___ 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: dtrace walltimestamp
Ashley Williams ashley@gmail.com wrote:
walltimestamp and timestamp don't appear to be right in BETA-1:
# dtrace -qn 'syscall::exec*:return { printf(%Y
%s\n,walltimestamp,curpsinfo-pr_psargs); }'
1970 Jan 1 10:00:00 date
1970 Jan 1 10:00:00 ping
1970 Jan 1 10:00:00 ls
I can reproduce this on amd64 with a recent HEAD, walltimestamp
is always 0, which together with the dmesg warnings seems to indicate
that it's not supported (yet).
# dtrace -qn 'syscall::exec*:return { printf(%Y
%s\n,timestamp,curpsinfo-pr_psargs); }'
1970 Jan 6 12:02:27 ping
1970 Jan 6 12:02:29 ls
1970 Jan 6 12:02:31 dtrace
Note that the timestamp value is relative to the time
the system is booted (I think), and not to midnight,
January 1, 1970.
Assuming your system has been running for a few days
and the offsets are right as well, the output seems fine.
At least on my system, timestamp offsets can only can be relied
on with either kern.timecounter.hardware=TSC or with C3
states disabled, though.
Measuring the elapsed time (in ms) between events that happen
in roughly 1 second intervals with kern.timecounter.hardware=HPET
and dev.cpu.0.cx_lowest=C2:
elapsed
value - Distribution - count
990 | 0
1000 |@@@ 57
1010 | 0
1020 | 0
1030 |@1
1040 | 0
elapsed avg1007
And doing the same with dev.cpu.0.cx_lowest=C3:
elapsed
value - Distribution - count
40 | 0
50 |@@@ 28
60 |@@@ 10
70 |@@@ 5
80 |@1
90 | 0
100 |@2
110 |@2
120 |@2
130 | 0
140 |@1
150 |@1
160 |@1
170 |@1
180 | 0
190 | 0
200 | 0
210 | 0
220 |@1
230 |@1
240 | 0
250 | 0
260 | 0
270 | 0
280 | 0
290 |@1
300 |@1
310 | 0
320 |@1
330 | 0
elapsed avg 90
Fabian
signature.asc
Description: PGP signature
Re: gptzfsboot error using HP Smart Array P410i Controller
On 2011-08-18 18:30, Christoph Hoffmann wrote:
...
Changing the order of execution in zfsboot.c main() function to
[…]
int
main(void)
{
[…]
bios_getmem();
if (high_heap_size 0) {
[…]
bootinfo.bi_version = BOOTINFO_VERSION;
bootinfo.bi_size = sizeof(bootinfo);
bootinfo.bi_basemem = bios_basemem / 1024;
bootinfo.bi_extmem = bios_extmem / 1024;
bootinfo.bi_memsizes_valid++;
/* bootinfo.bi_bios_dev = dsk-drive; */
bootinfo.bi_bios_dev = *(uint8_t *)PTOV(ARGS);
dsk = malloc(sizeof(struct dsk));
dsk-drive = *(uint8_t *)PTOV(ARGS);
dsk-type = dsk-drive DRV_HARD ? TYPE_AD : TYPE_FD;
dsk-unit = dsk-drive DRV_MASK;
dsk-slice = *(uint8_t *)PTOV(ARGS + 1) + 1;
dsk-part = 0;
dsk-start = 0;
dsk-init = 0;
bootdev = MAKEBOOTDEV(dev_maj[dsk-type],
dsk-slice, dsk-unit, dsk-part),
[…]
fixes the problem.
Can you please use -save-temps to save the intermediate zfsboot.s files,
both before and after you change this order, then post them here? It's
easiest to just do:
DEBUG_FLAGS=-save-temps make -C /usr/src/sys/boot/i386/gptzfsboot clean all
then save /usr/obj/usr/src/sys/boot/i386/gptzfsboot/zfsboot.s somewhere.
___
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: fsid change of ZFS?
Hiroki Sato wrote: Rick Macklem rmack...@uoguelph.ca wrote in 1565511281.69213.1313764157732.javamail.r...@erie.cs.uoguelph.ca: rm Hiroki Sato wrote: rm fsid_guid = dmu_objset_fsid_guid(zfsvfs-z_os); rm ASSERT((fsid_guid ~((1ULL56)-1)) == 0); rm vfsp-vfs_fsid.val[0] = fsid_guid; rm vfsp-vfs_fsid.val[1] = ((fsid_guid32) 8) | rm vfsp-mnt_vfc-vfc_typenum 0xFF; rm rm Since the vfc_typenum variable is incremented every time a new vfs is rm installed, loading order of modules that call vfs_register() affects rm ZFS's fsid. rm rm Anyway, possibility of fsid change is troublesome especially for an rm NFS server with a lot of clients running. Can zeroing or setting a rm fixed value to the lowest 8-bit of vfs_fsid.val[1] be harmful? rm rm -- Hiroki rm Well, the problem is that the fsid needs to be unique among all mounts. rm The vfs_typenum field is used to try and ensure that it does not end up rm the same value as a non-ZFS file system. rm rm (A) I think making that field a fixed constant should be ok, if the function rm checks for a conflict by calling vfs_getvfs() to check for one. rm See vfs_getnewfsid() for how this is done. (There is a mutex lock that rm needs to be held while doing it.) Alternately, if ZFS can call vfs_getnewfsid() rm instead of doing its own, that might be nicer? rm rm (B) Another way to fix this would be to modify vfs_register() to look up rm file systems in a table (by vfc_name) and used a fixed, assigned value rm from the table for vfc_typenum for entries found in the table. Only do rm the maxvfsconf++ when there isn't an entry for the fstype in the table. rm (VFS_GENERIC can be set to the size of the table. That's what happened rm in the bad old days when vfsconf was a table built at kernel config time.) rm rm If you guys think (B) is preferred, I could come up with a patch. I don't rm know enough about ZFS to do (A). rm Oh, and I think other fs types will suffer the same fate, except that rm they usually avoid it, because they are compiled into the kernel and rm the assignment of vfs_typenum happens in the same order--same value. Yes, using vfs_getnewfsid() does not solve the issue. I noticed that Solaris looked up a fixed array vfssw[] exactly for the purpose. I think a table like it is a good solution for fixing fsid for each file system. -- Hiroki If anyone thinks using a fixed table to assign vfc_typenum for known file system types is a bad idea, please let us know. Otherwise I will make up a patch, rick ___ 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: fsid change of ZFS?
Hiroki Sato wrote:
Rick Macklem rmack...@uoguelph.ca wrote
in 1565511281.69213.1313764157732.javamail.r...@erie.cs.uoguelph.ca:
rm Hiroki Sato wrote:
rm fsid_guid = dmu_objset_fsid_guid(zfsvfs-z_os);
rm ASSERT((fsid_guid ~((1ULL56)-1)) == 0);
rm vfsp-vfs_fsid.val[0] = fsid_guid;
rm vfsp-vfs_fsid.val[1] = ((fsid_guid32) 8) |
rm vfsp-mnt_vfc-vfc_typenum 0xFF;
rm
rm Since the vfc_typenum variable is incremented every time a new
vfs is
rm installed, loading order of modules that call vfs_register()
affects
rm ZFS's fsid.
rm
rm Anyway, possibility of fsid change is troublesome especially for
an
rm NFS server with a lot of clients running. Can zeroing or setting
a
rm fixed value to the lowest 8-bit of vfs_fsid.val[1] be harmful?
rm
rm -- Hiroki
rm Well, the problem is that the fsid needs to be unique among all
mounts.
rm The vfs_typenum field is used to try and ensure that it does not
end up
rm the same value as a non-ZFS file system.
rm
rm (A) I think making that field a fixed constant should be ok, if
the function
rm checks for a conflict by calling vfs_getvfs() to check for one.
rm See vfs_getnewfsid() for how this is done. (There is a mutex lock
that
rm needs to be held while doing it.) Alternately, if ZFS can call
vfs_getnewfsid()
rm instead of doing its own, that might be nicer?
rm
rm (B) Another way to fix this would be to modify vfs_register() to
look up
rm file systems in a table (by vfc_name) and used a fixed, assigned
value
rm from the table for vfc_typenum for entries found in the table.
Only do
rm the maxvfsconf++ when there isn't an entry for the fstype in the
table.
rm (VFS_GENERIC can be set to the size of the table. That's what
happened
rm in the bad old days when vfsconf was a table built at kernel
config time.)
rm
rm If you guys think (B) is preferred, I could come up with a patch.
I don't
rm know enough about ZFS to do (A).
rm Oh, and I think other fs types will suffer the same fate, except
that
rm they usually avoid it, because they are compiled into the kernel
and
rm the assignment of vfs_typenum happens in the same order--same
value.
Yes, using vfs_getnewfsid() does not solve the issue.
I noticed that Solaris looked up a fixed array vfssw[] exactly for
the purpose. I think a table like it is a good solution for fixing
fsid for each file system.
-- Hiroki
Hiroki, could you please test the attached patch.
One problem with this patch is that I don't know how to create a fixed
table that matches what systems would already have been getting.
(I got the first 6 entries by booting a GENERIC i386 kernel with a
printf in vfs_init(), so I suspect those don't change much, although
I'm not sure if ZFS will usually end up before or after them?)
Do you guys know what ZFS gets assigned typically? (I realize that
changes w.r.t. when it gets loaded, so the question also becomes
do you know how it typically gets loaded so the table can have
that vfc_typenum value assigned to it?)
Maybe you could boot a system with a printf like:
printf(%s, %d\n, vfc-vfc_name, vfc-vfc_typenum);
just after vfc-vfc_typenum = maxvfsconf++; in vfs_init() and
then look in dmesg after booting, to see what your tables look like?
(Without the attached patch installed.)
Thanks, rick
ps: The patch is also at
http://people.freebsd.org/~rmacklem/fsid.patch for anyone on
the list interested (if the attachment doesn't make it through.
rick--- kern/vfs_init.c.sav 2011-06-11 18:58:33.0 -0400
+++ kern/vfs_init.c 2011-08-20 20:01:31.0 -0400
@@ -54,9 +54,38 @@ static int vfs_unregister(struct vfsconf
MALLOC_DEFINE(M_VNODE, vnodes, Dynamically allocated vnodes);
/*
+ * This table assigns static vfc_typenum values for file systems that
+ * are well known to the system. This avoids the problem of a file system's
+ * fsid and, therefore, its NFS file handle, from changing based on
+ * when the file system is loaded into the kernel.
+ * File system types not in this list will be assigned values based
+ * on maxvfsconf.
+ */
+static struct vfstypenums {
+ char *typename;
+ int typenum;
+} vfstypenums[] = {
+ { cd9660, 1 },
+ { ufs, 2 },
+ { procfs, 3 },
+ { devfs, 4 },
+ { msdosfs, 5 },
+ { nfs, 6 },
+ { zfs, 7 },
+ { reiserfs, 8 },
+ { tmpfs, 9 },
+ { hpfs, 10 },
+ { ntfs, 11 },
+ { ext2fs, 12 },
+ { udf, 13 },
+ { xfs, 14 },
+ { , 0 } /* Must be last. */
+};
+
+/*
* The highest defined VFS number.
*/
-int maxvfsconf = VFS_GENERIC + 1;
+int maxvfsconf = sizeof(vfstypenums) / sizeof(struct vfstypenums);
/*
* Single-linked list of configured VFSes.
@@ -138,6 +167,7 @@ vfs_register(struct vfsconf *vfc)
struct sysctl_oid *oidp;
struct vfsops *vfsops;
static int once;
+ int i;
if (!once) {
vattr_null(va_null);
@@ -152,7 +182,18 @@ vfs_register(struct vfsconf *vfc)
if (vfs_byname(vfc-vfc_name) != NULL)
return EEXIST;
- vfc-vfc_typenum = maxvfsconf++;
+ /* First, search for a match in
Re: fsid change of ZFS?
On Sat, 20 Aug 2011, Rick Macklem wrote: Yes, using vfs_getnewfsid() does not solve the issue. I noticed that Solaris looked up a fixed array vfssw[] exactly for the purpose. I think a table like it is a good solution for fixing fsid for each file system. -- Hiroki If anyone thinks using a fixed table to assign vfc_typenum for known file system types is a bad idea, please let us know. Fixed table sounds like a good plan. Is there a reason for/against using a hash table for types that are not in the fixed table? The advantage would be that out-of-tree filesystems get a consistent typenum (modulo hash collisions), but there would be more overhead in maintaining the table. -Ben Kaduk ___ 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
nfs lock failure/hang when using alias address for server from linux
Hi, I have an nfs server running 9-current. Everything works as far as nfs i/o operations are concerned. From another FreeBSD box, nfs locking works great to the server when addressed by both it's real ip address and it's aliased ip address. From a Linux system: Linux bb05d6403.unx.sas.com 2.6.32-131.0.15.el6.x86_64 #1 SMP Tue May 10 15:42:40 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux nfs locking works fine if the mount goes to the real ip address of the server. If, however, the server is mounted by using it's aliased ip address, while nfs i/o operations work fine, file locking hangs. On the server, the processes: root 5995 0.0 0.0 14272 1920 ?? Ss3:48PM0:05.33 /usr/sbin/rpcbind -h 10.24.6.38 -h 172.1.1.2 -h 10.24.6.33 -h 10.24.6.34 root 6021 0.0 0.0 12316 2364 ?? Ss3:48PM0:00.65 /usr/sbin/mountd -r -l -h 10.24.6.38 -h 172.1.1.2 -h 10.24.6.33 -h 10.24.6.34 root 6048 0.0 0.0 10060 1864 ?? Ss3:48PM0:00.10 nfsd: master (nfsd) root 6049 0.0 0.0 10060 1368 ?? S 3:48PM0:00.20 nfsd: server (nfsd) root 6074 0.0 0.0 274432 2084 ?? Is3:48PM0:00.03 /usr/sbin/rpc.statd -d -h 10.24.6.38 -h 172.1.1.2 -h 10.24.6.33 -h 10.24.6.34 root 6099 0.0 0.0 14400 1780 ?? Ss3:48PM0:00.03 /usr/sbin/rpc.lockd -d 9 -h 10.24.6.38 -h 172.1.1.2 -h 10.24.6.33 -h 10.24.6.34 The server is accessed by udp in addition to tcp thus the -h options for each address. Nfsv4 is not enabled at this time. I have the debug output of statd lockd running to /var/log via syslog but nothing useful shows up. The interface configuration: bce0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether 84:2b:2b:fd:a1:fc inet 10.24.6.38 netmask 0x broadcast 10.24.255.255 inet6 fe80::862b:2bff:fefd:a1fc%bce0 prefixlen 64 scopeid 0x1 inet 10.24.6.33 netmask 0x broadcast 10.24.255.255 inet 10.24.6.34 netmask 0x broadcast 10.24.255.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active Above, a mount to 10.24.6.38 works. A mount to either 10.24.6.33 or 10.24.6.34 works for nfs i/o operations, but hangs for lock requests. I'd like this to work so I can transistion some volumes around to different servers. Does anyone have any thoughts on the best way to debug this? I've looked at what I believe are the obvious areas. I'll probably start looking more closely at tcpdump next. Thanks, John ___ 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
