Re: how to destroy zfs parent filesystem without destroying children - corrupted file causing kernel panick
On Fri, Dec 28, 2012 at 2:46 PM, Greg Bonett wrote: > Many months ago, I believe some *very bad hardware* caused corruption of a > file on one of my zfs file systems. I've isolated the corrupted file and > can reliably induce a kernel panic with "touch bad.file", "rm bad.file", or > "ls -l" in the bad.file's directory (ls in bad.file's dir doesn't cause > panic, but "ls bad.file" does). > Does: cat /dev/null > bad.file Cause a kernel panic? -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RC3: xorg-input-mouse, xfce4-panel
On 28 December 2012 04:02, Kimmo Paasiala wrote: > It doesn't look like the FreeBSD ports SVN repository is used to its > full potential. SVN allows branching and creation of experimental > versions of the tree very easily and cheaply, yet all the experimental > repositories references so far are stored in some external > repositories, github or elsewhere. > > What gives? Because then people who wish to create experimental branches of a rather large ports SVN tree would end up populating the core SVN repo, which is reproduced on mirrors (both ours and whoever else wishes to mirror the SVN repository.) So the current method in src/ is to work out hacks in local mirrors of the repository (eg via svn -> git gateways) and then when it's time to start some public work - create a branch, do the hacking, merge it into HEAD when it's ready. That way it can also be worked on by non-FreeBSD contributors. Just like what people do for Linux, who don't have kernel.org accounts. I won't speak for the ports people but just keep that in mind. There's sometimes larger scale issues abound. :-) And before you say "but but but but but but git!" please keep in mind that there's no such thing as a central GIT repository that _everyone_ dumps their work in, like what would happen if one created an SVN branch for projects (in src, ports, doc, etc.) Everyone has their own git repository forks and they push patches to "more authoritative" trees over time. Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1 minimal ram requirements
> It has happened in the past that even as the release bits were propogating, > One Last Big Bug was found and those bits had to be pulled and re-done. It > would have looked like you had FreeBSD Release X.Y but you wouldn't have had > the final bits that everyone else did. I'm aware of this. I simply did not have alternative. > I understand your frustration that this process takes days, and in general > the frustration with this particular release -- more than you could possibly > believe. However, until we figure out the process that would exist in an > ideal world, this is what we have, and so if you need something that will be > in 9.1, your options at this moment are: build an install from 9-STABLE; find > one of the snapshots (and no, I am not the one to ask, sorry); or wait. I'm not fond of one-size fits all principle. If an image is correct, I'll stick with it, till next treshold. At the moment, I fill relaxed, since both systems work as the best machines I had in my life. As I stated before, I could stand bugs and do not expect "perfect" system anytime. Freebsd suits me. If I have a problem, I wait or go around, or forget the issue. My bad was that release problem sinchronized with my power surge issue. At any other time, I'd be patient and you'd never hear of me. > Sorry, but that's the best I can offer right now. Wrong. You made psychological thing and I could be not worried about state of OS. If this image differs from the final one, I do not care, if they are the same in parts that matter to me. I will upgrade at the next . Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: how to destroy zfs parent filesystem without destroying children - corrupted file causing kernel panick
ahh, unfortunately the filesystem I want to destroy is the top-most file system for the pool. Does this mean I'll need to set up another pool with enough free space to move everything over? Any ideas for a way to remove the corrupted file without destroying the file system? thanks! On Sat, Dec 29, 2012 at 3:35 AM, Artem Belevich wrote: > > On Fri, Dec 28, 2012 at 12:46 PM, Greg Bonett wrote: > >> However, I can't figure out how to destroy the /tank filesystem without >> destroying /tank/tempfs (and the other /tank children). Is it possible to >> destroy a parent without destroying the children? Or, create a new parent >> zfs file system on the same zpool and move the /tank children there before >> destroying /tank? >> > > It is possible in case parent is not the top-most zfs filesystem (i.e > tomp-most filesystem for the pool). > > I.e. if your zfs filesystem layout looked like zfs-pool/tank/tempfs, then > you could simply do "zfs rename zfs-pool/tank/tempfs zfs-pool/tempfs" and > then would be free to remove zfs-pool/tank. Alas this rename semantics > breaks down when you can no longer rename sub-filesystem upward. I don't > think ZFS would allow you to promote inner filesystem to a pool which is > what you seem to want. > > --Artem > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: how to destroy zfs parent filesystem without destroying children - corrupted file causing kernel panick
On Fri, Dec 28, 2012 at 12:46 PM, Greg Bonett wrote: > However, I can't figure out how to destroy the /tank filesystem without > destroying /tank/tempfs (and the other /tank children). Is it possible to > destroy a parent without destroying the children? Or, create a new parent > zfs file system on the same zpool and move the /tank children there before > destroying /tank? > It is possible in case parent is not the top-most zfs filesystem (i.e tomp-most filesystem for the pool). I.e. if your zfs filesystem layout looked like zfs-pool/tank/tempfs, then you could simply do "zfs rename zfs-pool/tank/tempfs zfs-pool/tempfs" and then would be free to remove zfs-pool/tank. Alas this rename semantics breaks down when you can no longer rename sub-filesystem upward. I don't think ZFS would allow you to promote inner filesystem to a pool which is what you seem to want. --Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup
Konstantin Belousov wrote:
>
> Please try the following patch. It is against HEAD, might need some
> adjustments for 8. I do the resume and write accounting atomically,
> not allowing other suspension to intervent between.
>
> diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c
> index 3f65b05..cf49ecb 100644
> --- a/sys/kern/vfs_vnops.c
> +++ b/sys/kern/vfs_vnops.c
> @@ -1434,6 +1434,40 @@ vn_closefile(fp, td)
> * proceed. If a suspend request is in progress, we wait until the
> * suspension is over, and then proceed.
> */
> +static int
> +vn_start_write_locked(struct mount *mp, int flags)
> +{
> + int error;
> +
> + mtx_assert(MNT_MTX(mp), MA_OWNED);
> + error = 0;
> +
> + /*
> + * Check on status of suspension.
> + */
> + if ((curthread->td_pflags & TDP_IGNSUSP) == 0 ||
> + mp->mnt_susp_owner != curthread) {
> + while ((mp->mnt_kern_flag & MNTK_SUSPEND) != 0) {
> + if (flags & V_NOWAIT) {
> + error = EWOULDBLOCK;
> + goto unlock;
> + }
> + error = msleep(&mp->mnt_flag, MNT_MTX(mp),
> + (PUSER - 1) | (flags & PCATCH), "suspfs", 0);
> + if (error)
> + goto unlock;
> + }
> + }
> + if (flags & V_XSLEEP)
> + goto unlock;
> + mp->mnt_writeopcount++;
> +unlock:
> + if (error != 0 || (flags & V_XSLEEP) != 0)
> + MNT_REL(mp);
> + MNT_IUNLOCK(mp);
> + return (error);
> +}
> +
> int
> vn_start_write(vp, mpp, flags)
> struct vnode *vp;
> @@ -1470,30 +1504,7 @@ vn_start_write(vp, mpp, flags)
> if (vp == NULL)
> MNT_REF(mp);
>
> - /*
> - * Check on status of suspension.
> - */
> - if ((curthread->td_pflags & TDP_IGNSUSP) == 0 ||
> - mp->mnt_susp_owner != curthread) {
> - while ((mp->mnt_kern_flag & MNTK_SUSPEND) != 0) {
> - if (flags & V_NOWAIT) {
> - error = EWOULDBLOCK;
> - goto unlock;
> - }
> - error = msleep(&mp->mnt_flag, MNT_MTX(mp),
> - (PUSER - 1) | (flags & PCATCH), "suspfs", 0);
> - if (error)
> - goto unlock;
> - }
> - }
> - if (flags & V_XSLEEP)
> - goto unlock;
> - mp->mnt_writeopcount++;
> -unlock:
> - if (error != 0 || (flags & V_XSLEEP) != 0)
> - MNT_REL(mp);
> - MNT_IUNLOCK(mp);
> - return (error);
> + return (vn_start_write_locked(mp, flags));
> }
>
> /*
> @@ -1639,8 +1650,7 @@ vfs_write_suspend(mp)
> * Request a filesystem to resume write operations.
> */
> void
> -vfs_write_resume(mp)
> - struct mount *mp;
> +vfs_write_resume_flags(struct mount *mp, int flags)
> {
>
> MNT_ILOCK(mp);
> @@ -1652,10 +1662,25 @@ vfs_write_resume(mp)
> wakeup(&mp->mnt_writeopcount);
> wakeup(&mp->mnt_flag);
> curthread->td_pflags &= ~TDP_IGNSUSP;
> + if ((flags & VR_START_WRITE) != 0) {
> + MNT_REF(mp);
> + mp->mnt_writeopcount++;
> + }
> MNT_IUNLOCK(mp);
> VFS_SUSP_CLEAN(mp);
> - } else
> + } else if ((flags & VR_START_WRITE) != 0) {
> + MNT_REF(mp);
> + vn_start_write_locked(mp, 0);
> + } else {
> MNT_IUNLOCK(mp);
> + }
> +}
> +
> +void
> +vfs_write_resume(struct mount *mp)
> +{
> +
> + vfs_write_resume_flags(mp, 0);
> }
>
> /*
> diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h
> index 42f9e5f..4371b40 100644
> --- a/sys/sys/vnode.h
> +++ b/sys/sys/vnode.h
> @@ -392,6 +392,8 @@ extern intvttoif_tab[];
> #define V_NOWAIT0x0002 /* vn_start_write: don't sleep for
> suspend */
> #define V_XSLEEP0x0004 /* vn_start_write: just return after
> sleep */
>
> +#define VR_START_WRITE 0x0001 /* vfs_write_resume: start write
> atomically */
> +
> #define VREF(vp)vref(vp)
>
> #ifdef DIAGNOSTIC
> @@ -701,6 +703,7 @@ int vn_io_fault_uiomove(char *data, int xfersize,
> struct uio *uio);
> int vfs_cache_lookup(struct vop_lookup_args *ap);
> void vfs_timestamp(struct timespec *);
> void vfs_write_resume(struct mount *mp);
> +void vfs_write_resume_flags(struct mount *mp, int flags);
> int vfs_write_suspend(struct mount *mp);
> int vop_stdbmap(struct vop_bmap_args *);
> int vop_stdfsync(struct vop_fsync_args *);
> diff --git a/sys/ufs/ffs/ffs_snapshot.c b/sys/ufs/ffs/ffs_snapshot.c
> index e528509..25ad79c 100644
> --- a/sys/ufs/ffs/ffs_snapshot.c
> +++ b/sys/ufs/ffs/ffs_snapshot.c
> @@ -687,8 +687,7 @@ out1:
> /*
>* Resume operation on filesystem.
>*/
> - vfs_write_resume(vp->v_mount);
> -
how to destroy zfs parent filesystem without destroying children - corrupted file causing kernel panick
Many months ago, I believe some *very bad hardware* caused corruption of a file on one of my zfs file systems. I've isolated the corrupted file and can reliably induce a kernel panic with "touch bad.file", "rm bad.file", or "ls -l" in the bad.file's directory (ls in bad.file's dir doesn't cause panic, but "ls bad.file" does). This is a raidz zpool, but zpool scrub doesn't fix it - it eventually creates a kernel panic. My next plan is to attempt to get rid of this file by zfs destroy(ing) the entire filesystem. The corrupted file is on /tank, and I've copied all of the good data onto a new zfs file system, /tank/tempfs/. However, I can't figure out how to destroy the /tank filesystem without destroying /tank/tempfs (and the other /tank children). Is it possible to destroy a parent without destroying the children? Or, create a new parent zfs file system on the same zpool and move the /tank children there before destroying /tank? /tank and it's children are about 4.2 TB and I don't have the disk space readily available to copy the whole thing (but I can get the space if it's the only way to do this). Thanks in advance for the help. --Greg system info: FreeBSD 9.1-PRERELEASE #1 r243694 amd64 16GB ram 'zpool upgrade' gives: This system supports ZFS pool feature flags. All pools are formatted using feature flags. Every feature flags pool has all supported features enabled. 'zfs upgrade' gives: This system is currently running ZFS filesystem version 5. All filesystems are formatted with the current version. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Anothe pkgng question: signing a repository
On Fri, Dec 28, 2012 at 9:28 AM, Matthew Seaman wrote: > On 27/12/2012 21:01, Garrett Wollman wrote: >>> I'm creating my own repository and have created a key for it. >> [...] >>> >What does pkg expect to be in this file? > >> A public key. It does not use X.509 (nor is there any reason why it >> should, although I suppose it could be made to at the cost of >> significant added complexity and a bootstrapping problem). > > pkgng has a quite minimal signing setup -- it uses naked RSA > public/private keys without committing to either of the two popular > models for providing assurance on the validity of public keys (viz: PGP > web of trust or X509 style certificate chains to some trusted root > certificate). It's not clear at the moment if one or other or neither > of those styles would be preferred in the future. > > Or it may well be the case that RFC6698 (DANE -- DNS-Based > Authentication of Named Entities) via DNSSEC signed zone data[*] is > preferred over either of the two means frequently used at the moment. > Remember that there's really only one cryptographic signature needed for > each architecture/OS version specific repository catalogue. So not a > huge maintenance burden keeping the DNS up to date and signed even if a > new repository catalogue is published each day. > > Cheers, > > Matthew > > [*] FreeBSD.org is not currently DNSSEC signed, so use of DANE will have > to remain no more than a pipe-dream for the time being. So why not? BIND 9.9 makes signing pretty easy and many registrars support it, though not all do. I think Tucows does, though I don't use them, so I might be wrong. With all of the concern over security after the intrusion, this seems like a good time to get started with signing. (Yes, I know everyone is really tied up with auditing things, but if it keeps getting delayed, ti will not happen.) And, yes, DANE is clearly preferable to either PGP (#2 choice, IMHO) or X.509 (too broken to be worth considering). -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1 minimal ram requirements
In an ideal world, the bits that will almost certainly become FreeBSD 9.1 would not appear on the masters, or any of the mirrors, until the same instant that the release announcement is set to freebsd-annou...@freebsd.org. In practice this doesn't happen. If there is some clever way for that to happen, we haven't found it yet. It has happened in the past that even as the release bits were propogating, One Last Big Bug was found and those bits had to be pulled and re-done. It would have looked like you had FreeBSD Release X.Y but you wouldn't have had the final bits that everyone else did. I understand your frustration that this process takes days, and in general the frustration with this particular release -- more than you could possibly believe. However, until we figure out the process that would exist in an ideal world, this is what we have, and so if you need something that will be in 9.1, your options at this moment are: build an install from 9-STABLE; find one of the snapshots (and no, I am not the one to ask, sorry); or wait. Sorry, but that's the best I can offer right now. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Anothe pkgng question: signing a repository
On 27/12/2012 21:01, Garrett Wollman wrote: >> I'm creating my own repository and have created a key for it. > [...] >> >What does pkg expect to be in this file? > A public key. It does not use X.509 (nor is there any reason why it > should, although I suppose it could be made to at the cost of > significant added complexity and a bootstrapping problem). pkgng has a quite minimal signing setup -- it uses naked RSA public/private keys without committing to either of the two popular models for providing assurance on the validity of public keys (viz: PGP web of trust or X509 style certificate chains to some trusted root certificate). It's not clear at the moment if one or other or neither of those styles would be preferred in the future. Or it may well be the case that RFC6698 (DANE -- DNS-Based Authentication of Named Entities) via DNSSEC signed zone data[*] is preferred over either of the two means frequently used at the moment. Remember that there's really only one cryptographic signature needed for each architecture/OS version specific repository catalogue. So not a huge maintenance burden keeping the DNS up to date and signed even if a new repository catalogue is published each day. Cheers, Matthew [*] FreeBSD.org is not currently DNSSEC signed, so use of DANE will have to remain no more than a pipe-dream for the time being. -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: 9.1 minimal ram requirements
> What you are seeing is behind-the-scenes preparation. > The release is official when, and only when, a security-signed email is > sent to freebsd-annou...@freebsd.org from the Release Engineering team. Yeah, Mark. You're right. Further, I'm right too. What should I install on blank node? Beta? No beta on the site. RC1-3? No RC on the site. 9.0? I need kms at least on laptop. My simple question is: what is the file on the server? Please, no only-when, no wait-for-... I'm might be ignorant in many ways, but I expect freebsd site to content what it reads as a file name. So, do I have installed 9.1 on my desktop and laptop or some alien OS? Do I have to wait more and reinstall from the beginning, when official announcement comes? To be clear: freebsd is my only OS on computer for many years and I do not argue in any way. I just want to say that silence is not a good kind of communication. Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Anothe pkgng question: signing a repository
Am Thu, 27 Dec 2012 16:01:43 -0500 (EST) schrieb Garrett Wollman : > In article <20121227162311$6...@grapevine.csail.mit.edu>, > rai...@ultra-secure.de writes: > > >I'm creating my own repository and have created a key for it. > [...] > >What does pkg expect to be in this file? > > A public key. It does not use X.509 (nor is there any reason why it > should, although I suppose it could be made to at the cost of > significant added complexity and a bootstrapping problem). Ah, OK. When I hear "key", I sort of assume there must be a certificate and a CA involved. It works now ;-) Best Regards, Rainer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RC3: xorg-input-mouse, xfce4-panel
http://wiki.freebsd.org/Git -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-RC3-xorg-input-mouse-xfce4-panel-tp5772549p5772798.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RC3: xorg-input-mouse, xfce4-panel
xorg trunk repo predates SVN for ports. -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-RC3-xorg-input-mouse-xfce4-panel-tp5772549p5772797.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RC3: xorg-input-mouse, xfce4-panel
On Fri, Dec 28, 2012 at 2:08 PM, CeDeROM wrote: > On Fri, Dec 28, 2012 at 1:02 PM, Kimmo Paasiala wrote: >> It doesn't look like the FreeBSD ports SVN repository is used to its >> full potential. (...) > > Yea, btw why FreeBSD does not use GIT? I have been using it for some > time and I have not seen better source code revision utility. GIT is > really amazing, SVN/CVS seems to be a file revision control, while GIT > is the source code revision control, this tool surprises me all the > time with its great features :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info I would personally use GIT but I'm ok with SVN too. I absolutely hate CVS :P My point is really that why not centralise all the development that happens around the ports tree. The infrastructure is there already. -Kimmo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RC3: xorg-input-mouse, xfce4-panel
On Fri, Dec 28, 2012 at 1:02 PM, Kimmo Paasiala wrote: > It doesn't look like the FreeBSD ports SVN repository is used to its > full potential. (...) Yea, btw why FreeBSD does not use GIT? I have been using it for some time and I have not seen better source code revision utility. GIT is really amazing, SVN/CVS seems to be a file revision control, while GIT is the source code revision control, this tool surprises me all the time with its great features :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RC3: xorg-input-mouse, xfce4-panel
On Fri, Dec 28, 2012 at 1:51 PM, CeDeROM wrote: > On Fri, Dec 28, 2012 at 12:42 PM, Kimmo Paasiala wrote: >> You're misunderstanding a few things. There are no "release packages" >> for any release of FreeBSD. What you have on the install discs are >> just "snapshot" packages built from the ports tree as it happened (...) > > I know, I hoped 1.7.2 driver or 1.8.1 can get into a port tree before > packages for 9.1 are built and released. When I applied a patch (some > structure fields initialization) from 1.7.2 on current 1.7.1 driver > problem of detection and strange mouse behavior was gone. If 1.7.1 > gets into the packages lots of people will report this issue... thats > all. > > Best regards :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info Related to this, It doesn't look like the FreeBSD ports SVN repository is used to its full potential. SVN allows branching and creation of experimental versions of the tree very easily and cheaply, yet all the experimental repositories references so far are stored in some external repositories, github or elsewhere. What gives? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: usb port issue in 9.1-Prerelease (Possibly Cam related)
On 9/10/2012 2:05 AM, Kenneth D. Merry wrote:
On Mon, Sep 10, 2012 at 23:09:04 +0930, Benjamin Close wrote:
Hi Folks,
I've facing an intermittent hang with a USB port which seems cam
related:
Event's that happen are:
o USB modem (HUAWEI E220) plugged into PC
ugen3.2: at usbus3
u3g0: <3G Modem> on usbus3
u3g0: Found 3 ports.
umass0: on usbus3
umass0: SCSI over Bulk-Only; quirks = 0x
umass0:6:0:-1: Attached to scbus6
umass1: on usbus3
umass1: SCSI over Bulk-Only; quirks = 0x
umass1:7:1:-1: Attached to scbus7
cd1 at umass-sim0 bus 0 scbus6 target 0 lun 0
cd1: Removable CD-ROM SCSI-2 device
cd1: 1.000MB/s transfers
cd1: Attempt to query device size failed: NOT READY, Medium not present
da0 at umass-sim1 bus 1 scbus7 target 0 lun 0
da0: Removable Direct Access SCSI-2 device
da0: 1.000MB/s transfers
da0: Attempt to query device size failed: NOT READY, Medium not present
o Time Elapsesmany packets passed, no da0 or cd1 used.
o USB Modem drops off the bus
(It does this occasionally as it resets itself)
o Causes USB bus to lose devices
ugen3.2: at usbus3 (disconnected)
u3g0: at uhub3, port 1, addr 2 (disconnected)
(cd1:umass-sim0:0:0:0): lost device, 1 refs
(cd1:umass-sim0:0:0:0): removing device entry
(pass4:umass-sim0:0:0:0): passdevgonecb: devfs entry is gone
(da0:umass-sim1:1:0:0): lost device - 0 outstanding, 1 refs
(da0:umass-sim1:1:0:0): removing device entry
(pass5:umass-sim1:1:0:0): passdevgonecb: devfs entry is gone
umass0: at uhub3, port 1, addr 2 (disconnected)
At this point that particular USB port is effectively useless. Plugging
anything into the ports shows no device showing up.
Running usbconfig hangs with:
PIDTID COMM TDNAME KSTACK
48562 101874 usbconfig-mi_switch+0x186
sleepq_wait+0x42 _sx_xlock_hard+0x426 usbd_enum_lock+0xac
usb_ref_device+0x21c usb_open+0xc7 devfs_open+0x197 vn_open_cred+0x2ff
kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7
Controller is:
uhci0@pci0:0:26:0: class=0x0c0300 card=0x02091028 chip=0x28348086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB UHCI Controller'
class = serial bus
subclass = USB
uhci1@pci0:0:26:1: class=0x0c0300 card=0x02091028 chip=0x28358086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB UHCI Controller'
class = serial bus
subclass = USB
ehci0@pci0:0:26:7: class=0x0c0320 card=0x02091028 chip=0x283a8086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB2 EHCI Controller'
class = serial bus
subclass = USB
It does however seem related to cam as looking at the various threads
for the usb hub I find:
(kgdb) bt
#0 sched_switch (td=0xfe000265, newtd=0xfe000227f000,
flags=Variable "flags" is not available.
) at /usr/src/sys/kern/sched_ule.c:1927
#1 0x808f34c6 in mi_switch (flags=260, newtd=0x0) at
/usr/src/sys/kern/kern_synch.c:485
#2 0x8092bfd2 in sleepq_wait (wchan=0xfe001ec2a900, pri=92)
at /usr/src/sys/kern/subr_sleepqueue.c:623
#3 0x808f3c69 in _sleep (ident=0xfe001ec2a900,
lock=0xfe00371e9210, priority=Variable "priority" is not available.
) at /usr/src/sys/kern/kern_synch.c:250
#4 0x802bea02 in cam_sim_free (sim=0xfe001ec2a900,
free_devq=1) at /usr/src/sys/cam/cam_sim.c:112
#5 0x8074f8ba in umass_detach (dev=Variable "dev" is not available.
) at /usr/src/sys/dev/usb/storage/umass.c:2183
#6 0x8091a054 in device_detach (dev=0xfe001ec2e900) at
device_if.h:214
#7 0x8075c458 in usb_detach_device (udev=0xfe0007ce8800,
iface_index=32 ' ', flag=Variable "flag" is not available.
) at /usr/src/sys/dev/usb/usb_device.c:1065
#8 0x8075c5f4 in usb_unconfigure (udev=0xfe0007ce8800,
flag=Variable "flag" is not available.
) at /usr/src/sys/dev/usb/usb_device.c:455
#9 0x8075c88e in usb_free_device (udev=0xfe0007ce8800,
flag=Variable "flag" is not available.
) at /usr/src/sys/dev/usb/usb_device.c:2093
#10 0x80764e5e in uhub_explore (udev=0xfe0007353800) at
/usr/src/sys/dev/usb/usb_hub.c:358
#11 0x8074f536 in usb_bus_explore (pm=Variable "pm" is not
available.
) at /usr/src/sys/dev/usb/controller/usb_controller.c:359
#12 0x80769173 in usb_process (arg=Variable "arg" is not available.
) at /usr/src/sys/dev/usb/usb_process.c:170
#13 0x808bc2df in fork_exit (callout=0x807690a0
, arg=0xff80007c0e88, frame=0xff804743cc40) at
/usr/src/sys/kern/kern_fork.c:992
#14 0x80bc216e in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:602
From: cam_sim_free(struct cam_sim *sim, int free_devq)
(kgdb) l
107 {
108 int error;
109
110 sim->refcount--;
111 if (sim->refcount > 0) {
112 error = msleep(s
Re: 9.1-RC3: xorg-input-mouse, xfce4-panel
On Fri, Dec 28, 2012 at 12:42 PM, Kimmo Paasiala wrote: > You're misunderstanding a few things. There are no "release packages" > for any release of FreeBSD. What you have on the install discs are > just "snapshot" packages built from the ports tree as it happened (...) I know, I hoped 1.7.2 driver or 1.8.1 can get into a port tree before packages for 9.1 are built and released. When I applied a patch (some structure fields initialization) from 1.7.2 on current 1.7.1 driver problem of detection and strange mouse behavior was gone. If 1.7.1 gets into the packages lots of people will report this issue... thats all. Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RC3: xorg-input-mouse, xfce4-panel
On Fri, Dec 28, 2012 at 1:33 PM, CeDeROM wrote: > On Thu, Dec 27, 2012 at 6:07 PM, Jakub Lach wrote: >> xf86-input-mouse-1.8.1 is in dev trunk xorg tree. (see -x11). > > This is the only sensible solution to use new driver. HAL and > AllowEmptyInput are EXCLUSIVE and cause very strange behavior - I have > just noticed that again on another desktop - screen is refreshed AFTER > mouse is moved heh... > > Still I cannot see the new 1.8.1 driver after updating the port > tree... cannot wait to see that one, still I think this is a must for > a "release package" :-) > > Best regards :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info You're misunderstanding a few things. There are no "release packages" for any release of FreeBSD. What you have on the install discs are just "snapshot" packages built from the ports tree as it happened to be at the time of the release was made. If you want to see the newer mouse driver in ports help the xorg developers by testing their experimental tree. There's nothing to be done about the 9.1-RELEASE, the packages on the install discs will not have any experimental content. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RC3: xorg-input-mouse, xfce4-panel
1.8.1 is in staging area (dev trunk). It will be not in packages distributed with 9.1. They were just apps which happened to be in ports tree at packages building for release time. There is only one branch of ports. hal is less and less used/supported and it was never meant to be used with AllowEmptyInput... http://wiki.freebsd.org/Xorg -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-RC3-xorg-input-mouse-xfce4-panel-tp5772549p5772781.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RC3: xorg-input-mouse, xfce4-panel
On Thu, Dec 27, 2012 at 6:07 PM, Jakub Lach wrote: > xf86-input-mouse-1.8.1 is in dev trunk xorg tree. (see -x11). This is the only sensible solution to use new driver. HAL and AllowEmptyInput are EXCLUSIVE and cause very strange behavior - I have just noticed that again on another desktop - screen is refreshed AFTER mouse is moved heh... Still I cannot see the new 1.8.1 driver after updating the port tree... cannot wait to see that one, still I think this is a must for a "release package" :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup
On Fri, Dec 28, 2012 at 10:19:31AM +0100, Andreas Longwitz wrote:
> Konstantin Belousov wrote:
> >>> On Thu, Dec 27, 2012 at 12:28:54PM +0100, Andreas Longwitz wrote:
> >> db> alltrace (pid 18 and 7126)
> >>
> >> Tracing command g_journal switcher pid 18 tid 100076 td 0xff0002bd5000
> >> sched_switch() at sched_switch+0xde
> >> mi_switch() at mi_switch+0x186
> >> sleepq_wait() at sleepq_wait+0x42
> >> __lockmgr_args() at __lockmgr_args+0x49b
> >> ffs_copyonwrite() at ffs_copyonwrite+0x19a
> >> ffs_geom_strategy() at ffs_geom_strategy+0x1b5
> >> bufwrite() at bufwrite+0xe9
> >> ffs_sbupdate() at ffs_sbupdate+0x12a
> >> g_journal_ufs_clean() at g_journal_ufs_clean+0x3e
> >> g_journal_switcher() at g_journal_switcher+0xe5e
> >> fork_exit() at fork_exit+0x11f
> >> fork_trampoline() at fork_trampoline+0xe
> >> --- trap 0, rip = 0, rsp = 0xff8242ca8cf0, rbp = 0 ---
> >>
> >> Tracing command mksnap_ffs pid 7126 tid 100157 td 0xff000807a470
> >> sched_switch() at sched_switch+0xde
> >> mi_switch() at mi_switch+0x186
> >> sleepq_wait() at sleepq_wait+0x42
> >> _sleep() at _sleep+0x373
> >> vn_start_write() at vn_start_write+0xdf
> >> ffs_snapshot() at ffs_snapshot+0xe2b
> > Can you look up the line number for the ffs_snapshot+0xe2b ?
>
> (kgdb) list *ffs_snapshot+0xe2b
> 0x8056287b is in ffs_snapshot
> (/usr/src/sys/ufs/ffs/ffs_snapshot.c:676).
> 671/*
> 672 * Resume operation on filesystem.
> 673 */
> 674vfs_write_resume(vp->v_mount);
> 675vn_start_write(NULL, &wrtmp, V_WAIT);
> 676if (collectsnapstats && starttime.tv_sec > 0) {
> 677 nanotime(&endtime);
> 678 timespecsub(&endtime, &starttime);
> 679 printf("%s: suspended %ld.%03ld sec, redo %ld of %d\n",
> 680vp->v_mount->mnt_stat.f_mntonname, (long)endtime.tv_sec,
>
> > I think the bug is that vn_start_write() is called while the snaplock
> > is owned, after the out1 label in ffs_snapshot() (I am looking at the
> > HEAD code).
>
> You are right, the vn_start_write() is just after the out1 label.
Please try the following patch. It is against HEAD, might need some
adjustments for 8. I do the resume and write accounting atomically,
not allowing other suspension to intervent between.
diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c
index 3f65b05..cf49ecb 100644
--- a/sys/kern/vfs_vnops.c
+++ b/sys/kern/vfs_vnops.c
@@ -1434,6 +1434,40 @@ vn_closefile(fp, td)
* proceed. If a suspend request is in progress, we wait until the
* suspension is over, and then proceed.
*/
+static int
+vn_start_write_locked(struct mount *mp, int flags)
+{
+ int error;
+
+ mtx_assert(MNT_MTX(mp), MA_OWNED);
+ error = 0;
+
+ /*
+* Check on status of suspension.
+*/
+ if ((curthread->td_pflags & TDP_IGNSUSP) == 0 ||
+ mp->mnt_susp_owner != curthread) {
+ while ((mp->mnt_kern_flag & MNTK_SUSPEND) != 0) {
+ if (flags & V_NOWAIT) {
+ error = EWOULDBLOCK;
+ goto unlock;
+ }
+ error = msleep(&mp->mnt_flag, MNT_MTX(mp),
+ (PUSER - 1) | (flags & PCATCH), "suspfs", 0);
+ if (error)
+ goto unlock;
+ }
+ }
+ if (flags & V_XSLEEP)
+ goto unlock;
+ mp->mnt_writeopcount++;
+unlock:
+ if (error != 0 || (flags & V_XSLEEP) != 0)
+ MNT_REL(mp);
+ MNT_IUNLOCK(mp);
+ return (error);
+}
+
int
vn_start_write(vp, mpp, flags)
struct vnode *vp;
@@ -1470,30 +1504,7 @@ vn_start_write(vp, mpp, flags)
if (vp == NULL)
MNT_REF(mp);
- /*
-* Check on status of suspension.
-*/
- if ((curthread->td_pflags & TDP_IGNSUSP) == 0 ||
- mp->mnt_susp_owner != curthread) {
- while ((mp->mnt_kern_flag & MNTK_SUSPEND) != 0) {
- if (flags & V_NOWAIT) {
- error = EWOULDBLOCK;
- goto unlock;
- }
- error = msleep(&mp->mnt_flag, MNT_MTX(mp),
- (PUSER - 1) | (flags & PCATCH), "suspfs", 0);
- if (error)
- goto unlock;
- }
- }
- if (flags & V_XSLEEP)
- goto unlock;
- mp->mnt_writeopcount++;
-unlock:
- if (error != 0 || (flags & V_XSLEEP) != 0)
- MNT_REL(mp);
- MNT_IUNLOCK(mp);
- return (error);
+ return (vn_start_write_locked(mp, flags));
}
/*
@@ -1639,8 +1650,7 @@ vfs_write_suspend(mp)
* Request a filesystem to resume write operations.
*/
void
-vfs_write_resume(mp)
- struct mount *mp;
+vfs_write_resume_flags(struct mount *mp, int flags)
{
MNT_ILOCK(mp);
@@ -1652,10 +1662,25 @@ vfs_write_resume(mp)
Re: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup
Konstantin Belousov wrote:
>>> On Thu, Dec 27, 2012 at 12:28:54PM +0100, Andreas Longwitz wrote:
>> db> alltrace (pid 18 and 7126)
>>
>> Tracing command g_journal switcher pid 18 tid 100076 td 0xff0002bd5000
>> sched_switch() at sched_switch+0xde
>> mi_switch() at mi_switch+0x186
>> sleepq_wait() at sleepq_wait+0x42
>> __lockmgr_args() at __lockmgr_args+0x49b
>> ffs_copyonwrite() at ffs_copyonwrite+0x19a
>> ffs_geom_strategy() at ffs_geom_strategy+0x1b5
>> bufwrite() at bufwrite+0xe9
>> ffs_sbupdate() at ffs_sbupdate+0x12a
>> g_journal_ufs_clean() at g_journal_ufs_clean+0x3e
>> g_journal_switcher() at g_journal_switcher+0xe5e
>> fork_exit() at fork_exit+0x11f
>> fork_trampoline() at fork_trampoline+0xe
>> --- trap 0, rip = 0, rsp = 0xff8242ca8cf0, rbp = 0 ---
>>
>> Tracing command mksnap_ffs pid 7126 tid 100157 td 0xff000807a470
>> sched_switch() at sched_switch+0xde
>> mi_switch() at mi_switch+0x186
>> sleepq_wait() at sleepq_wait+0x42
>> _sleep() at _sleep+0x373
>> vn_start_write() at vn_start_write+0xdf
>> ffs_snapshot() at ffs_snapshot+0xe2b
> Can you look up the line number for the ffs_snapshot+0xe2b ?
(kgdb) list *ffs_snapshot+0xe2b
0x8056287b is in ffs_snapshot
(/usr/src/sys/ufs/ffs/ffs_snapshot.c:676).
671/*
672 * Resume operation on filesystem.
673 */
674vfs_write_resume(vp->v_mount);
675vn_start_write(NULL, &wrtmp, V_WAIT);
676if (collectsnapstats && starttime.tv_sec > 0) {
677 nanotime(&endtime);
678 timespecsub(&endtime, &starttime);
679 printf("%s: suspended %ld.%03ld sec, redo %ld of %d\n",
680vp->v_mount->mnt_stat.f_mntonname, (long)endtime.tv_sec,
> I think the bug is that vn_start_write() is called while the snaplock
> is owned, after the out1 label in ffs_snapshot() (I am looking at the
> HEAD code).
You are right, the vn_start_write() is just after the out1 label.
>> ffs_mount() at ffs_mount+0x65a
>> vfs_donmount() at vfs_donmount+0xdc5
>> nmount() at nmount+0x63
>> amd64_syscall() at amd64_syscall+0x1f4
>> Xfast_syscall() at Xfast_syscall+0xfc
>> --- syscall (378, FreeBSD ELF64, nmount), rip = 0x18069e35c, rsp =
>> 0x7fffe358, rbp = 0x7fffedc7 ---
--
Andreas Longwitz
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
