From fedora at leemhuis.info Sun Jul 5 08:02:18 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 05 Jul 2009 10:02:18 +0200 Subject: Time for 2.6.30 in F-11? In-Reply-To: References: <1246704003.2811.43.camel@shrek.rexursive.com> Message-ID: <4A505E0A.4050408@leemhuis.info> CCing #fedora-kernel-list On 04.07.2009 16:12, Kevin Kofler wrote: > Bojan Smojver wrote: >> Now that .1 is out, is there anything in particular stopping F-11 from >> having this kernel? > And why is F10 still stuck on 2.6.27? 2.6.29 has been in updates-testing for > ages now. Good question. Seems the "ship state-of-the-art/nearly latest kernel versions from kernel.org as regular update for Fedora" worked much better in the past. Is that for a specific reason or just a side effect of something (maintainer/responsibly changes maybe?). And yes, I know it's a lot of work to prepare updates from 2.6.x.y to 2.6.(x+1).y. So thx for that work -- it IMHO is definitely worth it as it makes people get drivers for new hardware without forcing them to switch to rawhide. That, btw and afaics, for quite some people was one of the reasons to chose Fedora. I for example use Fedora for testing at work mainly because I got latest kernels on Fedora automatically. Cu knurd From ahmad221284 at yahoo.com Mon Jul 6 15:57:47 2009 From: ahmad221284 at yahoo.com (Ahmad Al-Yaman) Date: Mon, 6 Jul 2009 08:57:47 -0700 (PDT) Subject: Kernel Loading Sequence Message-ID: <910548.16295.qm@web51105.mail.re2.yahoo.com> Hi all, I came across a problem when trying to compile a custom kernel for F11: both the stock kernel and my custom kernel have i915 modesetting enabled by default. In the stock kernel the loading screen starts up immediately when the kernel starts loading, but using the custom kernel, some text is displayed before the loading screen starts up (the kernel finishes loading without problems). I'm trying to figure out the reason for this and if there's a way to fix it so that the user doesn't see this text. Could the reason be the order in which different parts of the kernel are loaded? If yes, how can I control which parts load first? I tried to see the text or find it in one of the logs in order to give a more complete description of the problem but I couldn't, so if anyone has a tip on how or where I can find it (in case it's relevant to the solution) I'd highly appreciate it. Thank you. From jarod at redhat.com Mon Jul 6 19:59:15 2009 From: jarod at redhat.com (Jarod Wilson) Date: Mon, 6 Jul 2009 15:59:15 -0400 Subject: Kernel Loading Sequence In-Reply-To: <910548.16295.qm@web51105.mail.re2.yahoo.com> References: <910548.16295.qm@web51105.mail.re2.yahoo.com> Message-ID: <200907061559.16059.jarod@redhat.com> On Monday 06 July 2009 11:57:47 Ahmad Al-Yaman wrote: > Hi all, > > I came across a problem when trying to compile a custom kernel for F11: both the stock kernel and my custom kernel have i915 modesetting enabled by default. In the stock kernel the loading screen starts up immediately when the kernel starts loading, but using the custom kernel, some text is displayed before the loading screen starts up (the kernel finishes loading without problems). I'm trying to figure out the reason for this and if there's a way to fix it so that the user doesn't see this text. Could the reason be the order in which different parts of the kernel are loaded? If yes, how can I control which parts load first? Is your 'custom kernel' an F11 kernel + your patches, or starting from an upstream tarball + your patches? (In which case, its lacking all the patches Fedora has added, and therein probably lies your answer to why things are behaving differently). -- Jarod Wilson jarod at redhat.com From ahmad221284 at yahoo.com Mon Jul 6 20:39:51 2009 From: ahmad221284 at yahoo.com (Ahmad Al-Yaman) Date: Mon, 6 Jul 2009 13:39:51 -0700 (PDT) Subject: Fw: Kernel Loading Sequence In-Reply-To: <910548.16295.qm@web51105.mail.re2.yahoo.com> References: <910548.16295.qm@web51105.mail.re2.yahoo.com> Message-ID: <578711.24413.qm@web51105.mail.re2.yahoo.com> It's an F11 kernel + my patches. I obtained the SRPM from koji, added a couple of patches, and modified the config file to suit my hardware. ----- Forwarded Message ---- From: Jarod Wilson To: fedora-kernel-list at redhat.com Sent: Monday, July 6, 2009 10:59:15 PM Subject: Re: Kernel Loading Sequence On Monday 06 July 2009 11:57:47 Ahmad Al-Yaman wrote: > Hi all, > > I came across a problem when trying to compile a custom kernel for F11: both the stock kernel and my custom kernel have i915 modesetting enabled by default. In the stock kernel the loading screen starts up immediately when the kernel starts loading, but using the custom kernel, some text is displayed before the loading screen starts up (the kernel finishes loading without problems). I'm trying to figure out the reason for this and if there's a way to fix it so that the user doesn't see this text. Could the reason be the order in which different parts of the kernel are loaded? If yes, how can I control which parts load first? Is your 'custom kernel' an F11 kernel + your patches, or starting from an upstream tarball + your patches? (In which case, its lacking all the patches Fedora has added, and therein probably lies your answer to why things are behaving differently). -- Jarod Wilson jarod at redhat.com _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list From airlied at redhat.com Mon Jul 6 21:17:46 2009 From: airlied at redhat.com (Dave Airlie) Date: Tue, 07 Jul 2009 07:17:46 +1000 Subject: Fw: Kernel Loading Sequence In-Reply-To: <578711.24413.qm@web51105.mail.re2.yahoo.com> References: <910548.16295.qm@web51105.mail.re2.yahoo.com> <578711.24413.qm@web51105.mail.re2.yahoo.com> Message-ID: <1246915066.2843.0.camel@t60prh> On Mon, 2009-07-06 at 13:39 -0700, Ahmad Al-Yaman wrote: > It's an F11 kernel + my patches. I obtained the SRPM from koji, added a couple of patches, and modified the config file to suit my hardware. Either got quiet missing or some of the patches add output that doesn't respect quiet. Dave. > > > > ----- Forwarded Message ---- > From: Jarod Wilson > To: fedora-kernel-list at redhat.com > Sent: Monday, July 6, 2009 10:59:15 PM > Subject: Re: Kernel Loading Sequence > > On Monday 06 July 2009 11:57:47 Ahmad Al-Yaman wrote: > > Hi all, > > > > I came across a problem when trying to compile a custom kernel for F11: both the stock kernel and my custom kernel have i915 modesetting enabled by default. In the stock kernel the loading screen starts up immediately when the kernel starts loading, but using the custom kernel, some text is displayed before the loading screen starts up (the kernel finishes loading without problems). I'm trying to figure out the reason for this and if there's a way to fix it so that the user doesn't see this text. Could the reason be the order in which different parts of the kernel are loaded? If yes, how can I control which parts load first? > > Is your 'custom kernel' an F11 kernel + your patches, or starting from > an upstream tarball + your patches? (In which case, its lacking all the > patches Fedora has added, and therein probably lies your answer to why > things are behaving differently). > > > From ahmad221284 at yahoo.com Mon Jul 6 21:53:23 2009 From: ahmad221284 at yahoo.com (Ahmad Al-Yaman) Date: Mon, 6 Jul 2009 14:53:23 -0700 (PDT) Subject: Fw: Kernel Loading Sequence In-Reply-To: <1246915066.2843.0.camel@t60prh> References: <910548.16295.qm@web51105.mail.re2.yahoo.com> <578711.24413.qm@web51105.mail.re2.yahoo.com> <1246915066.2843.0.camel@t60prh> Message-ID: <179842.17959.qm@web51108.mail.re2.yahoo.com> I just checked and quiet is not missing. As for the patches adding that output, I highly doubt it since none of them has an output and they're quite simple, they adjust a few things in some drivers, nothing major. Besides, the messages are displayed before "Welcome to Fedora init", if the problem was with the patches, shouldn't the messages come up after that? Ahmad ________________________________ From: Dave Airlie To: Ahmad Al-Yaman Cc: fedora-kernel-list at redhat.com Sent: Tuesday, July 7, 2009 12:17:46 AM Subject: Re: Fw: Kernel Loading Sequence On Mon, 2009-07-06 at 13:39 -0700, Ahmad Al-Yaman wrote: > It's an F11 kernel + my patches. I obtained the SRPM from koji, added a couple of patches, and modified the config file to suit my hardware. Either got quiet missing or some of the patches add output that doesn't respect quiet. Dave. > > > > ----- Forwarded Message ---- > From: Jarod Wilson > To: fedora-kernel-list at redhat.com > Sent: Monday, July 6, 2009 10:59:15 PM > Subject: Re: Kernel Loading Sequence > > On Monday 06 July 2009 11:57:47 Ahmad Al-Yaman wrote: > > Hi all, > > > > I came across a problem when trying to compile a custom kernel for F11: both the stock kernel and my custom kernel have i915 modesetting enabled by default. In the stock kernel the loading screen starts up immediately when the kernel starts loading, but using the custom kernel, some text is displayed before the loading screen starts up (the kernel finishes loading without problems). I'm trying to figure out the reason for this and if there's a way to fix it so that the user doesn't see this text. Could the reason be the order in which different parts of the kernel are loaded? If yes, how can I control which parts load first? > > Is your 'custom kernel' an F11 kernel + your patches, or starting from > an upstream tarball + your patches? (In which case, its lacking all the > patches Fedora has added, and therein probably lies your answer to why > things are behaving differently). > > > _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list From SteveD at redhat.com Tue Jul 7 17:41:11 2009 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 07 Jul 2009 13:41:11 -0400 Subject: [PATCH] NFS V4 - Dynamic Pseudo Root Message-ID: <4A5388B7.6060302@RedHat.com> Hey, I would like to apply the following patch to the rawhide kernel that will make exports for NFS v4 mount work just list exports for v3 and v2 mounts. In a nutshell, for NFS v4 mounts to work like v3/2 mounts the '/ *(ro,fsid=0)' entry has to be added to the /etc/exports file. This patch eliminates the need for that entry. The history, reasoning and evolution of this patch can be found at: http://linux-nfs.org/pipermail/nfsv4/2009-June/010724.html Over the weekend, I pounded on this code with 4 clients continuously running the cthon test suite, which tests every part of the protocol including mounting... In the end, this is the first major step toward making NFS v4 the default protocol. steved. Date: Tue Jul 7, 2009 Author: Steve Dickson Kernel support needed to implement dynamic pseudo root support which will allow v3 and v2 exports accessible to NFS v4 clients without any configuration changes. Signed-Off-By: Steve Dickson ---------------------------------------------------- diff -up linux-2.6.30.noarch/fs/nfsd/export.c.save linux-2.6.30.noarch/fs/nfsd/export.c --- linux-2.6.30.noarch/fs/nfsd/export.c.save 2009-07-02 11:34:38.000000000 -0400 +++ linux-2.6.30.noarch/fs/nfsd/export.c 2009-07-02 11:35:44.000000000 -0400 @@ -104,6 +104,7 @@ static int expkey_parse(struct cache_det if (mesg[mlen-1] != '\n') return -EINVAL; mesg[mlen-1] = 0; + dprintk("expkey_parse: '%s'\n", mesg); buf = kmalloc(PAGE_SIZE, GFP_KERNEL); err = -ENOMEM; @@ -181,6 +182,8 @@ static int expkey_parse(struct cache_det if (dom) auth_domain_put(dom); kfree(buf); + if (err) + dprintk("expkey_parse: err %d\n", err); return err; } @@ -351,7 +354,10 @@ static void svc_export_request(struct ca (*bpp)[0] = '\n'; return; } + qword_add(bpp, blen, pth); + dprintk("svc_export_request: pth %s\n", pth); + (*bpp)[-1] = '\n'; } @@ -500,6 +506,7 @@ static int svc_export_parse(struct cache if (mesg[mlen-1] != '\n') return -EINVAL; mesg[mlen-1] = 0; + dprintk("svc_export_parse: '%s'\n", mesg); buf = kmalloc(PAGE_SIZE, GFP_KERNEL); if (!buf) @@ -619,6 +626,8 @@ out1: auth_domain_put(dom); out: kfree(buf); + if (err) + dprintk("svc_export_parse: err %d\n", err); return err; } @@ -1413,6 +1422,7 @@ static struct flags { { NFSEXP_CROSSMOUNT, {"crossmnt", ""}}, { NFSEXP_NOSUBTREECHECK, {"no_subtree_check", ""}}, { NFSEXP_NOAUTHNLM, {"insecure_locks", ""}}, + { NFSEXP_V4ROOT, {"v4root", ""}}, #ifdef MSNFS { NFSEXP_MSNFS, {"msnfs", ""}}, #endif @@ -1493,7 +1503,7 @@ static int e_show(struct seq_file *m, vo struct svc_export *exp = container_of(cp, struct svc_export, h); if (p == SEQ_START_TOKEN) { - seq_puts(m, "# Version 1.1\n"); + seq_puts(m, "# Version 1.2\n"); seq_puts(m, "# Path Client(Flags) # IPs\n"); return 0; } diff -up linux-2.6.30.noarch/fs/nfsd/nfs4xdr.c.save linux-2.6.30.noarch/fs/nfsd/nfs4xdr.c --- linux-2.6.30.noarch/fs/nfsd/nfs4xdr.c.save 2009-07-02 11:34:38.000000000 -0400 +++ linux-2.6.30.noarch/fs/nfsd/nfs4xdr.c 2009-07-02 11:35:31.000000000 -0400 @@ -2176,28 +2176,62 @@ static inline int attributes_need_mount( return 0; } -static __be32 -nfsd4_encode_dirent_fattr(struct nfsd4_readdir *cd, - const char *name, int namlen, __be32 *p, int *buflen) +struct dentry * +nfsd_check_export(struct nfsd4_readdir *cd, const char *name, int namlen) { struct svc_export *exp = cd->rd_fhp->fh_export; struct dentry *dentry; - __be32 nfserr; - int ignore_crossmnt = 0; + int err; dentry = lookup_one_len(name, cd->rd_fhp->fh_dentry, namlen); if (IS_ERR(dentry)) - return nfserrno(PTR_ERR(dentry)); + return dentry; if (!dentry->d_inode) { - /* - * nfsd_buffered_readdir drops the i_mutex between - * readdir and calling this callback, leaving a window - * where this directory entry could have gone away. - */ dput(dentry); - return nfserr_noent; + return ERR_PTR(-ENOENT); + } + + /* + * Check to see if this dentry is part + * of the psuedo root + */ + if ((exp->ex_flags & NFSEXP_V4ROOT) == 0) + return dentry; + + /* + * Only exported directories are visable + * on psuedo exports + */ + if (!S_ISDIR(dentry->d_inode->i_mode)) { + dput(dentry); + return ERR_PTR(-ENOENT); } + /* + * Make the upcall to see if this directory + * is exported. + */ + exp_get(exp); + err = nfsd_export_lookup(cd->rd_rqstp, dentry, exp); + if (err) { + exp_put(exp); + dput(dentry); + return ERR_PTR(err); + } + exp_put(exp); + + return dentry; +} + +static __be32 +nfsd4_encode_dirent_fattr(struct nfsd4_readdir *cd, + struct dentry *dentry, __be32 *p, int *buflen) +{ + struct svc_export *exp = cd->rd_fhp->fh_export; + __be32 nfserr; + int ignore_crossmnt = 0; + int err, v4root = (exp->ex_flags & NFSEXP_V4ROOT); + exp_get(exp); /* * In the case of a mountpoint, the client may be asking for @@ -2208,18 +2242,29 @@ nfsd4_encode_dirent_fattr(struct nfsd4_r */ if (d_mountpoint(dentry) && !attributes_need_mount(cd->rd_bmval)) ignore_crossmnt = 1; - else if (d_mountpoint(dentry)) { - int err; - + else if (d_mountpoint(dentry) || v4root) { + /* + * Make sure the dentry is viewable on the psuedo export + */ + v4root = (dentry->d_inode && v4root); + if (v4root) { + err = nfsd_export_lookup(cd->rd_rqstp, dentry, exp); + if (err) { + nfserr = nfserrno(err); + goto out_put; + } + } /* * Why the heck aren't we just using nfsd_lookup?? * Different "."/".." handling? Something else? * At least, add a comment here to explain.... */ - err = nfsd_cross_mnt(cd->rd_rqstp, &dentry, &exp); - if (err) { - nfserr = nfserrno(err); - goto out_put; + if (d_mountpoint(dentry) || v4root) { + err = nfsd_cross_mnt(cd->rd_rqstp, &dentry, &exp); + if (err) { + nfserr = nfserrno(err); + goto out_put; + } } nfserr = check_nfsd_access(exp, cd->rd_rqstp); if (nfserr) @@ -2258,6 +2303,7 @@ nfsd4_encode_dirent(void *ccdv, const ch struct readdir_cd *ccd = ccdv; struct nfsd4_readdir *cd = container_of(ccd, struct nfsd4_readdir, common); int buflen; + struct dentry *dentry; __be32 *p = cd->buffer; __be32 *cookiep; __be32 nfserr = nfserr_toosmall; @@ -2268,19 +2314,40 @@ nfsd4_encode_dirent(void *ccdv, const ch return 0; } + /* + * Do the lookup and make sure the dentry is + * visible on the exported directory + */ + dentry = nfsd_check_export(cd, name, namlen); + if (IS_ERR(dentry)) { + if (PTR_ERR(dentry) == -ENOENT) { + cd->common.err = nfs_ok; + return 0; + } + cd->common.err = nfserrno(PTR_ERR(dentry)); + return -EINVAL; + } + if (cd->offset) xdr_encode_hyper(cd->offset, (u64) offset); buflen = cd->buflen - 4 - XDR_QUADLEN(namlen); - if (buflen < 0) + if (buflen < 0) { + dput(dentry); goto fail; + } *p++ = xdr_one; /* mark entry present */ cookiep = p; p = xdr_encode_hyper(p, NFS_OFFSET_MAX); /* offset of next entry */ p = xdr_encode_array(p, name, namlen); /* name length & name */ - nfserr = nfsd4_encode_dirent_fattr(cd, name, namlen, p, &buflen); + /* + * Note: the dput() on the dentry is done in + * nfsd4_encode_dirent_fattr() since the dentry can + * change when crossing a mount point. + */ + nfserr = nfsd4_encode_dirent_fattr(cd, dentry, p, &buflen); switch (nfserr) { case nfs_ok: p += buflen; diff -up linux-2.6.30.noarch/fs/nfsd/nfsfh.c.save linux-2.6.30.noarch/fs/nfsd/nfsfh.c --- linux-2.6.30.noarch/fs/nfsd/nfsfh.c.save 2009-07-02 11:34:38.000000000 -0400 +++ linux-2.6.30.noarch/fs/nfsd/nfsfh.c 2009-07-02 11:35:48.000000000 -0400 @@ -109,6 +109,34 @@ static __be32 nfsd_setuser_and_check_por return nfserrno(nfsd_setuser(rqstp, exp)); } +static inline __be32 check_pseudo_root(struct svc_rqst *rqstp, + struct dentry *dentry, struct svc_export *exp) +{ + int error; + + /* + * Only interested in pseudo roots + */ + if (!(exp->ex_flags & NFSEXP_V4ROOT)) + return nfs_ok; + + /* + * Only directories should be on the pseudo root + */ + if (unlikely(!S_ISDIR(dentry->d_inode->i_mode))) + return nfserr_stale; + /* + * Check non-root directories to make sure + * they are truly exported + */ + if (unlikely(dentry->d_name.len > 1)) { + error = nfsd_export_lookup(rqstp, dentry, exp); + return nfserrno(error); + } + + return nfs_ok; +} + /* * Use the given filehandle to look up the corresponding export and * dentry. On success, the results are used to set fh_export and @@ -315,6 +343,14 @@ fh_verify(struct svc_rqst *rqstp, struct error = nfsd_setuser_and_check_port(rqstp, exp); if (error) goto out; + + /* + * Do some spoof checking if we are on the pseudo root + */ + error = check_pseudo_root(rqstp, dentry, exp); + if (error) + goto out; + } error = nfsd_mode_check(rqstp, dentry->d_inode->i_mode, type); diff -up linux-2.6.30.noarch/fs/nfsd/vfs.c.save linux-2.6.30.noarch/fs/nfsd/vfs.c --- linux-2.6.30.noarch/fs/nfsd/vfs.c.save 2009-07-02 11:34:38.000000000 -0400 +++ linux-2.6.30.noarch/fs/nfsd/vfs.c 2009-07-02 11:35:39.000000000 -0400 @@ -89,6 +89,12 @@ struct raparm_hbucket { #define RAPARM_HASH_MASK (RAPARM_HASH_SIZE-1) static struct raparm_hbucket raparm_hash[RAPARM_HASH_SIZE]; +static inline int +nfsd_v4client(struct svc_rqst *rq) +{ + return((rq->rq_prog == NFS_PROGRAM) && (rq->rq_vers == 4)); +} + /* * Called from nfsd_lookup and encode_dirent. Check if we have crossed * a mount point. @@ -115,7 +121,8 @@ nfsd_cross_mnt(struct svc_rqst *rqstp, s path_put(&path); goto out; } - if ((exp->ex_flags & NFSEXP_CROSSMOUNT) || EX_NOHIDE(exp2)) { + if (nfsd_v4client(rqstp) || + (exp->ex_flags & NFSEXP_CROSSMOUNT) || EX_NOHIDE(exp2)) { /* successfully crossed mount point */ /* * This is subtle: path.dentry is *not* on path.mnt @@ -134,6 +141,55 @@ out: return err; } +/* + * Lookup the export the dentry is on. To be + * viewable on an pseudo export, the dentry + * has to be an exported directory. + */ +int +nfsd_export_lookup(struct svc_rqst *rqstp, struct dentry *dentry, + struct svc_export *exp) +{ + struct svc_export *exp2 = NULL; + struct path path; + int err = 0; + + if ((exp->ex_flags & NFSEXP_V4ROOT) == 0) + return 0; + + /* + * Make sure the export is the parent of the dentry + */ + if (dentry->d_parent != exp->ex_path.dentry) + return 0; + + /* + * Only directories are seen on psuedo exports + */ + if (!S_ISDIR(dentry->d_inode->i_mode)) + return -ENOENT; + + /* + * Make the upcall + */ + path.mnt = mntget(exp->ex_path.mnt); + path.dentry = dget(dentry); + while (d_mountpoint(path.dentry) && follow_down(&path)); + + exp2 = rqst_exp_get_by_name(rqstp, &path); + if (IS_ERR(exp2)) + err = PTR_ERR(exp2); + else { + /* + * The export exist so allow the access + */ + exp_put(exp2); + } + + dput(path.dentry); + mntput(path.mnt); + return err; +} __be32 nfsd_lookup_dentry(struct svc_rqst *rqstp, struct svc_fh *fhp, const char *name, unsigned int len, @@ -143,7 +199,7 @@ nfsd_lookup_dentry(struct svc_rqst *rqst struct dentry *dparent; struct dentry *dentry; __be32 err; - int host_err; + int host_err, v4root; dprintk("nfsd: nfsd_lookup(fh %s, %.*s)\n", SVCFH_fmt(fhp), len,name); @@ -155,6 +211,7 @@ nfsd_lookup_dentry(struct svc_rqst *rqst dparent = fhp->fh_dentry; exp = fhp->fh_export; exp_get(exp); + v4root = (exp->ex_flags & NFSEXP_V4ROOT); /* Lookup the name, but don't follow links */ if (isdotent(name, len)) { @@ -199,9 +256,21 @@ nfsd_lookup_dentry(struct svc_rqst *rqst if (IS_ERR(dentry)) goto out_nfserr; /* + * The export is a pseudo one, make sure the + * dentry is accessible + */ + v4root = (dentry->d_inode && v4root); + if (v4root) { + host_err = nfsd_export_lookup(rqstp, dentry, exp); + if (host_err) { + dput(dentry); + goto out_nfserr; + } + } + /* * check if we have crossed a mount point ... */ - if (d_mountpoint(dentry)) { + if (d_mountpoint(dentry) || v4root) { if ((host_err = nfsd_cross_mnt(rqstp, &dentry, &exp))) { dput(dentry); goto out_nfserr; diff -up linux-2.6.30.noarch/include/linux/nfsd/export.h.save linux-2.6.30.noarch/include/linux/nfsd/export.h --- linux-2.6.30.noarch/include/linux/nfsd/export.h.save 2009-07-02 11:34:38.000000000 -0400 +++ linux-2.6.30.noarch/include/linux/nfsd/export.h 2009-07-02 11:35:22.000000000 -0400 @@ -39,7 +39,8 @@ #define NFSEXP_FSID 0x2000 #define NFSEXP_CROSSMOUNT 0x4000 #define NFSEXP_NOACL 0x8000 /* reserved for possible ACL related use */ -#define NFSEXP_ALLFLAGS 0xFE3F +#define NFSEXP_V4ROOT 0x10000 +#define NFSEXP_ALLFLAGS 0x1FE3F /* The flags that may vary depending on security flavor: */ #define NFSEXP_SECINFO_FLAGS (NFSEXP_READONLY | NFSEXP_ROOTSQUASH \ diff -up linux-2.6.30.noarch/include/linux/nfsd/nfsd.h.save linux-2.6.30.noarch/include/linux/nfsd/nfsd.h --- linux-2.6.30.noarch/include/linux/nfsd/nfsd.h.save 2009-07-02 11:34:38.000000000 -0400 +++ linux-2.6.30.noarch/include/linux/nfsd/nfsd.h 2009-07-02 11:35:27.000000000 -0400 @@ -76,6 +76,8 @@ int nfsd_racache_init(int); void nfsd_racache_shutdown(void); int nfsd_cross_mnt(struct svc_rqst *rqstp, struct dentry **dpp, struct svc_export **expp); +int nfsd_export_lookup(struct svc_rqst *rqstp, struct dentry *dpp, + struct svc_export *exp); __be32 nfsd_lookup(struct svc_rqst *, struct svc_fh *, const char *, unsigned int, struct svc_fh *); __be32 nfsd_lookup_dentry(struct svc_rqst *, struct svc_fh *, From kyle at mcmartin.ca Tue Jul 7 18:27:43 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Tue, 7 Jul 2009 14:27:43 -0400 Subject: [PATCH] NFS V4 - Dynamic Pseudo Root In-Reply-To: <4A5388B7.6060302@RedHat.com> References: <4A5388B7.6060302@RedHat.com> Message-ID: <20090707182743.GD3826@bombadil.infradead.org> On Tue, Jul 07, 2009 at 01:41:11PM -0400, Steve Dickson wrote: > I would like to apply the following patch to the rawhide > kernel that will make exports for NFS v4 mount work just > list exports for v3 and v2 mounts. > > In a nutshell, for NFS v4 mounts to work like v3/2 mounts > the '/ *(ro,fsid=0)' entry has to be added to the /etc/exports > file. This patch eliminates the need for that entry. > > The history, reasoning and evolution of this patch can > be found at: > http://linux-nfs.org/pipermail/nfsv4/2009-June/010724.html > This seems fairly sensible to me. Feel free to apply it where appropriate. regards, Kyle From SteveD at redhat.com Tue Jul 7 19:25:24 2009 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 07 Jul 2009 15:25:24 -0400 Subject: [PATCH] NFS V4 - Dynamic Pseudo Root In-Reply-To: <20090707182743.GD3826@bombadil.infradead.org> References: <4A5388B7.6060302@RedHat.com> <20090707182743.GD3826@bombadil.infradead.org> Message-ID: <4A53A124.4070901@RedHat.com> On 07/07/2009 02:27 PM, Kyle McMartin wrote: > On Tue, Jul 07, 2009 at 01:41:11PM -0400, Steve Dickson wrote: >> I would like to apply the following patch to the rawhide >> kernel that will make exports for NFS v4 mount work just >> list exports for v3 and v2 mounts. >> >> In a nutshell, for NFS v4 mounts to work like v3/2 mounts >> the '/ *(ro,fsid=0)' entry has to be added to the /etc/exports >> file. This patch eliminates the need for that entry. >> >> The history, reasoning and evolution of this patch can >> be found at: >> http://linux-nfs.org/pipermail/nfsv4/2009-June/010724.html >> > > This seems fairly sensible to me. Feel free to apply it where > appropriate. cool... will do... The patch by itself does not change any functionality until the updated user level bits (i.e. rpc.mountd) are committed, which will be in a couple of days... steved. From ahmad221284 at yahoo.com Sun Jul 12 08:50:30 2009 From: ahmad221284 at yahoo.com (Ahmad Al-Yaman) Date: Sun, 12 Jul 2009 01:50:30 -0700 (PDT) Subject: Fw: Kernel Loading Sequence Message-ID: <800987.93403.qm@web51101.mail.re2.yahoo.com> I was able to find out the messages that are displayed before plymouth starts, but I still have no idea what's causing them: [ INFO: possible circular locking dependency detected ] 2.6.29.5-191.eeepc.fc11.i686.PAE #1 ------------------------------------------------------- plymouthd/746 is trying to acquire lock: (&fb_info->lock){--..}, at: [] fb_mmap+0x83/0x153 but task is already holding lock: (&mm->mmap_sem){----}, at: [] sys_mmap2+0x44/0x7b which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&mm->mmap_sem){----}: [] __lock_acquire+0x1068/0x137e [] lock_acquire+0x5e/0x7a [] might_fault+0x68/0x88 [] copy_to_user+0x2f/0x106 [] filldir+0x80/0xbb [] sysfs_readdir+0x104/0x138 [] vfs_readdir+0x68/0x94 [] sys_getdents+0x60/0xa4 [] syscall_call+0x7/0xb [] 0xffffffff -> #2 (sysfs_mutex){--..}: [] __lock_acquire+0x1068/0x137e [] lock_acquire+0x5e/0x7a [] mutex_lock_nested+0xe0/0x267 [] sysfs_addrm_start+0x23/0x95 [] create_dir+0x3a/0x76 [] sysfs_create_dir+0x2d/0x3d [] kobject_add_internal+0xaa/0x159 [] kobject_add_varg+0x31/0x3d [] kobject_add+0x43/0x49 [] device_add+0x79/0x3fb [] device_register+0x12/0x15 [] device_create_vargs+0x77/0xa0 [] device_create+0x1b/0x1d [] register_con_driver+0xdd/0x137 [] take_over_console+0x14/0x35 [] fbcon_takeover+0x5f/0x92 [] fbcon_event_notify+0x3b7/0x726 [] notifier_call_chain+0x51/0x78 [] __blocking_notifier_call_chain+0x37/0x4c [] blocking_notifier_call_chain+0xc/0xe [] fb_notifier_call_chain+0x11/0x13 [] register_framebuffer+0x1e2/0x1f3 [] intelfb_probe+0x491/0x4fb [] drm_helper_initial_config+0x148/0x152 [] i915_driver_load+0x8b2/0x912 [] drm_get_dev+0x343/0x405 [] i915_pci_probe+0xd/0xf [] local_pci_probe+0xe/0x10 [] pci_device_probe+0x46/0x69 [] driver_probe_device+0xa2/0x11d [] __driver_attach+0x4c/0x6b [] bus_for_each_dev+0x3b/0x63 [] driver_attach+0x14/0x16 [] bus_add_driver+0x98/0x1ab [] driver_register+0x6f/0xd3 [] __pci_register_driver+0x46/0xa5 [] drm_init+0x5b/0xb3 [] i915_init+0x46/0x48 [] _stext+0x4a/0x111 [] kernel_init+0x17f/0x1d0 [] kernel_thread_helper+0x7/0x10 [] 0xffffffff -> #1 ((fb_notifier_list).rwsem){..--}: [] __lock_acquire+0x1068/0x137e [] lock_acquire+0x5e/0x7a [] down_read+0x2a/0x3e [] __blocking_notifier_call_chain+0x24/0x4c [] blocking_notifier_call_chain+0xc/0xe [] fb_notifier_call_chain+0x11/0x13 [] register_framebuffer+0x1e2/0x1f3 [] intelfb_probe+0x491/0x4fb [] drm_helper_initial_config+0x148/0x152 [] i915_driver_load+0x8b2/0x912 [] drm_get_dev+0x343/0x405 [] i915_pci_probe+0xd/0xf [] local_pci_probe+0xe/0x10 [] pci_device_probe+0x46/0x69 [] driver_probe_device+0xa2/0x11d [] __driver_attach+0x4c/0x6b [] bus_for_each_dev+0x3b/0x63 [] driver_attach+0x14/0x16 [] bus_add_driver+0x98/0x1ab [] driver_register+0x6f/0xd3 [] __pci_register_driver+0x46/0xa5 [] drm_init+0x5b/0xb3 [] i915_init+0x46/0x48 [] _stext+0x4a/0x111 [] kernel_init+0x17f/0x1d0 [] kernel_thread_helper+0x7/0x10 [] 0xffffffff -> #0 (&fb_info->lock){--..}: [] __lock_acquire+0xd47/0x137e [] lock_acquire+0x5e/0x7a [] mutex_lock_nested+0xe0/0x267 [] fb_mmap+0x83/0x153 [] mmap_region+0x21c/0x3ab [] do_mmap_pgoff+0x250/0x2a2 [] sys_mmap2+0x5a/0x7b [] syscall_call+0x7/0xb [] 0xffffffff other info that might help us debug this: 1 lock held by plymouthd/746: #0: (&mm->mmap_sem){----}, at: [] sys_mmap2+0x44/0x7b stack backtrace: Pid: 746, comm: plymouthd Not tainted 2.6.29.5-191.eeepc.fc11.i686.PAE #1 Call Trace: [] ? printk+0xf/0x11 [] print_circular_bug_tail+0xab/0xb6 [] __lock_acquire+0xd47/0x137e [] ? fb_mmap+0x83/0x153 [] lock_acquire+0x5e/0x7a [] ? fb_mmap+0x83/0x153 [] mutex_lock_nested+0xe0/0x267 [] ? fb_mmap+0x83/0x153 [] ? fb_mmap+0x83/0x153 [] fb_mmap+0x83/0x153 [] mmap_region+0x21c/0x3ab [] do_mmap_pgoff+0x250/0x2a2 [] sys_mmap2+0x5a/0x7b [] syscall_call+0x7/0xb Any ideas what could be causing this and how to solve it? Ahmad ________________________________ From: Ahmad Al-Yaman To: Dave Airlie Cc: fedora-kernel-list at redhat.com Sent: Tuesday, July 7, 2009 12:53:23 AM Subject: Re: Fw: Kernel Loading Sequence I just checked and quiet is not missing. As for the patches adding that output, I highly doubt it since none of them has an output and they're quite simple, they adjust a few things in some drivers, nothing major. Besides, the messages are displayed before "Welcome to Fedora init", if the problem was with the patches, shouldn't the messages come up after that? Ahmad ________________________________ From: Dave Airlie To: Ahmad Al-Yaman Cc: fedora-kernel-list at redhat.com Sent: Tuesday, July 7, 2009 12:17:46 AM Subject: Re: Fw: Kernel Loading Sequence On Mon, 2009-07-06 at 13:39 -0700, Ahmad Al-Yaman wrote: > It's an F11 kernel + my patches. I obtained the SRPM from koji, added a couple of patches, and modified the config file to suit my hardware. Either got quiet missing or some of the patches add output that doesn't respect quiet. Dave. > > > > ----- Forwarded Message ---- > From: Jarod Wilson > To: fedora-kernel-list at redhat.com > Sent: Monday, July 6, 2009 10:59:15 PM > Subject: Re: Kernel Loading Sequence > > On Monday 06 July 2009 11:57:47 Ahmad Al-Yaman wrote: > > Hi all, > > > > I came across a problem when trying to compile a custom kernel for F11: both the stock kernel and my custom kernel have i915 modesetting enabled by default. In the stock kernel the loading screen starts up immediately when the kernel starts loading, but using the custom kernel, some text is displayed before the loading screen starts up (the kernel finishes loading without problems). I'm trying to figure out the reason for this and if there's a way to fix it so that the user doesn't see this text. Could the reason be the order in which different parts of the kernel are loaded? If yes, how can I control which parts load first? > > Is your 'custom kernel' an F11 kernel + your patches, or starting from > an upstream tarball + your patches? (In which case, its lacking all the > patches Fedora has added, and therein probably lies your answer to why > things are behaving differently). > > > _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list From drago01 at gmail.com Sun Jul 12 09:35:07 2009 From: drago01 at gmail.com (drago01) Date: Sun, 12 Jul 2009 11:35:07 +0200 Subject: Fw: Kernel Loading Sequence In-Reply-To: <800987.93403.qm@web51101.mail.re2.yahoo.com> References: <800987.93403.qm@web51101.mail.re2.yahoo.com> Message-ID: On Sun, Jul 12, 2009 at 10:50 AM, Ahmad Al-Yaman wrote: > I was able to find out the messages that are displayed before plymouth starts, but I still have no idea what's causing them: > > [ INFO: possible circular locking dependency detected ] > 2.6.29.5-191.eeepc.fc11.i686.PAE #1 > ------------------------------------------------------- > plymouthd/746 is trying to acquire lock: > ?(&fb_info->lock){--..}, at: [] fb_mmap+0x83/0x153 > > but task is already holding lock: > ?(&mm->mmap_sem){----}, at: [] sys_mmap2+0x44/0x7b > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: > > -> #3 (&mm->mmap_sem){----}: > ? ? ? [] __lock_acquire+0x1068/0x137e > ? ? ? [] lock_acquire+0x5e/0x7a > ? ? ? [] might_fault+0x68/0x88 > ? ? ? [] copy_to_user+0x2f/0x106 > ? ? ? [] filldir+0x80/0xbb > ? ? ? [] sysfs_readdir+0x104/0x138 > ? ? ? [] vfs_readdir+0x68/0x94 > ? ? ? [] sys_getdents+0x60/0xa4 > ? ? ? [] syscall_call+0x7/0xb > ? ? ? [] 0xffffffff > > -> #2 (sysfs_mutex){--..}: > ? ? ? [] __lock_acquire+0x1068/0x137e > ? ? ? [] lock_acquire+0x5e/0x7a > ? ? ? [] mutex_lock_nested+0xe0/0x267 > ? ? ? [] sysfs_addrm_start+0x23/0x95 > ? ? ? [] create_dir+0x3a/0x76 > ? ? ? [] sysfs_create_dir+0x2d/0x3d > ? ? ? [] kobject_add_internal+0xaa/0x159 > ? ? ? [] kobject_add_varg+0x31/0x3d > ? ? ? [] kobject_add+0x43/0x49 > ? ? ? [] device_add+0x79/0x3fb > ? ? ? [] device_register+0x12/0x15 > ? ? ? [] device_create_vargs+0x77/0xa0 > ? ? ? [] device_create+0x1b/0x1d > ? ? ? [] register_con_driver+0xdd/0x137 > ? ? ? [] take_over_console+0x14/0x35 > ? ? ? [] fbcon_takeover+0x5f/0x92 > ? ? ? [] fbcon_event_notify+0x3b7/0x726 > ? ? ? [] notifier_call_chain+0x51/0x78 > ? ? ? [] __blocking_notifier_call_chain+0x37/0x4c > ? ? ? [] blocking_notifier_call_chain+0xc/0xe > ? ? ? [] fb_notifier_call_chain+0x11/0x13 > ? ? ? [] register_framebuffer+0x1e2/0x1f3 > ? ? ? [] intelfb_probe+0x491/0x4fb > ? ? ? [] drm_helper_initial_config+0x148/0x152 > ? ? ? [] i915_driver_load+0x8b2/0x912 > ? ? ? [] drm_get_dev+0x343/0x405 > ? ? ? [] i915_pci_probe+0xd/0xf > ? ? ? [] local_pci_probe+0xe/0x10 > ? ? ? [] pci_device_probe+0x46/0x69 > ? ? ? [] driver_probe_device+0xa2/0x11d > ? ? ? [] __driver_attach+0x4c/0x6b > ? ? ? [] bus_for_each_dev+0x3b/0x63 > ? ? ? [] driver_attach+0x14/0x16 > ? ? ? [] bus_add_driver+0x98/0x1ab > ? ? ? [] driver_register+0x6f/0xd3 > ? ? ? [] __pci_register_driver+0x46/0xa5 > ? ? ? [] drm_init+0x5b/0xb3 > ? ? ? [] i915_init+0x46/0x48 > ? ? ? [] _stext+0x4a/0x111 > ? ? ? [] kernel_init+0x17f/0x1d0 > ? ? ? [] kernel_thread_helper+0x7/0x10 > ? ? ? [] 0xffffffff > > -> #1 ((fb_notifier_list).rwsem){..--}: > ? ? ? [] __lock_acquire+0x1068/0x137e > ? ? ? [] lock_acquire+0x5e/0x7a > ? ? ? [] down_read+0x2a/0x3e > ? ? ? [] __blocking_notifier_call_chain+0x24/0x4c > ? ? ? [] blocking_notifier_call_chain+0xc/0xe > ? ? ? [] fb_notifier_call_chain+0x11/0x13 > ? ? ? [] register_framebuffer+0x1e2/0x1f3 > ? ? ? [] intelfb_probe+0x491/0x4fb > ? ? ? [] drm_helper_initial_config+0x148/0x152 > ? ? ? [] i915_driver_load+0x8b2/0x912 > ? ? ? [] drm_get_dev+0x343/0x405 > ? ? ? [] i915_pci_probe+0xd/0xf > ? ? ? [] local_pci_probe+0xe/0x10 > ? ? ? [] pci_device_probe+0x46/0x69 > ? ? ? [] driver_probe_device+0xa2/0x11d > ? ? ? [] __driver_attach+0x4c/0x6b > ? ? ? [] bus_for_each_dev+0x3b/0x63 > ? ? ? [] driver_attach+0x14/0x16 > ? ? ? [] bus_add_driver+0x98/0x1ab > ? ? ? [] driver_register+0x6f/0xd3 > ? ? ? [] __pci_register_driver+0x46/0xa5 > ? ? ? [] drm_init+0x5b/0xb3 > ? ? ? [] i915_init+0x46/0x48 > ? ? ? [] _stext+0x4a/0x111 > ? ? ? [] kernel_init+0x17f/0x1d0 > ? ? ? [] kernel_thread_helper+0x7/0x10 > ? ? ? [] 0xffffffff > > -> #0 (&fb_info->lock){--..}: > ? ? ? [] __lock_acquire+0xd47/0x137e > ? ? ? [] lock_acquire+0x5e/0x7a > ? ? ? [] mutex_lock_nested+0xe0/0x267 > ? ? ? [] fb_mmap+0x83/0x153 > ? ? ? [] mmap_region+0x21c/0x3ab > ? ? ? [] do_mmap_pgoff+0x250/0x2a2 > ? ? ? [] sys_mmap2+0x5a/0x7b > ? ? ? [] syscall_call+0x7/0xb > ? ? ? [] 0xffffffff > > other info that might help us debug this: > > 1 lock held by plymouthd/746: > ?#0: ?(&mm->mmap_sem){----}, at: [] sys_mmap2+0x44/0x7b > > stack backtrace: > Pid: 746, comm: plymouthd Not tainted 2.6.29.5-191.eeepc.fc11.i686.PAE #1 > Call Trace: > ?[] ? printk+0xf/0x11 > ?[] print_circular_bug_tail+0xab/0xb6 > ?[] __lock_acquire+0xd47/0x137e > ?[] ? fb_mmap+0x83/0x153 > ?[] lock_acquire+0x5e/0x7a > ?[] ? fb_mmap+0x83/0x153 > ?[] mutex_lock_nested+0xe0/0x267 > ?[] ? fb_mmap+0x83/0x153 > ?[] ? fb_mmap+0x83/0x153 > ?[] fb_mmap+0x83/0x153 > ?[] mmap_region+0x21c/0x3ab > ?[] do_mmap_pgoff+0x250/0x2a2 > ?[] sys_mmap2+0x5a/0x7b > ?[] syscall_call+0x7/0xb > > Any ideas what could be causing this and how to solve it? > > Ahmad Thats a lockdep warning, please report it. After that you can simply disable the lockdep checker in your kernel config and you wont see them anymore. From ahmad221284 at yahoo.com Sun Jul 12 11:32:48 2009 From: ahmad221284 at yahoo.com (Ahmad Al-Yaman) Date: Sun, 12 Jul 2009 04:32:48 -0700 (PDT) Subject: Fw: Kernel Loading Sequence In-Reply-To: References: <800987.93403.qm@web51101.mail.re2.yahoo.com> Message-ID: <416632.59640.qm@web51104.mail.re2.yahoo.com> Thank you, I adjusted the config file as you recommended and the messages are gone. Where should I report this lockdep? ________________________________ From: drago01 To: Ahmad Al-Yaman Cc: fedora-kernel-list at redhat.com Sent: Sunday, July 12, 2009 12:35:07 PM Subject: Re: Fw: Kernel Loading Sequence On Sun, Jul 12, 2009 at 10:50 AM, Ahmad Al-Yaman wrote: > I was able to find out the messages that are displayed before plymouth starts, but I still have no idea what's causing them: > > [ INFO: possible circular locking dependency detected ] > 2.6.29.5-191.eeepc.fc11.i686.PAE #1 > ------------------------------------------------------- > plymouthd/746 is trying to acquire lock: > (&fb_info->lock){--..}, at: [] fb_mmap+0x83/0x153 > > but task is already holding lock: > (&mm->mmap_sem){----}, at: [] sys_mmap2+0x44/0x7b > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: > > -> #3 (&mm->mmap_sem){----}: > [] __lock_acquire+0x1068/0x137e > [] lock_acquire+0x5e/0x7a > [] might_fault+0x68/0x88 > [] copy_to_user+0x2f/0x106 > [] filldir+0x80/0xbb > [] sysfs_readdir+0x104/0x138 > [] vfs_readdir+0x68/0x94 > [] sys_getdents+0x60/0xa4 > [] syscall_call+0x7/0xb > [] 0xffffffff > > -> #2 (sysfs_mutex){--..}: > [] __lock_acquire+0x1068/0x137e > [] lock_acquire+0x5e/0x7a > [] mutex_lock_nested+0xe0/0x267 > [] sysfs_addrm_start+0x23/0x95 > [] create_dir+0x3a/0x76 > [] sysfs_create_dir+0x2d/0x3d > [] kobject_add_internal+0xaa/0x159 > [] kobject_add_varg+0x31/0x3d > [] kobject_add+0x43/0x49 > [] device_add+0x79/0x3fb > [] device_register+0x12/0x15 > [] device_create_vargs+0x77/0xa0 > [] device_create+0x1b/0x1d > [] register_con_driver+0xdd/0x137 > [] take_over_console+0x14/0x35 > [] fbcon_takeover+0x5f/0x92 > [] fbcon_event_notify+0x3b7/0x726 > [] notifier_call_chain+0x51/0x78 > [] __blocking_notifier_call_chain+0x37/0x4c > [] blocking_notifier_call_chain+0xc/0xe > [] fb_notifier_call_chain+0x11/0x13 > [] register_framebuffer+0x1e2/0x1f3 > [] intelfb_probe+0x491/0x4fb > [] drm_helper_initial_config+0x148/0x152 > [] i915_driver_load+0x8b2/0x912 > [] drm_get_dev+0x343/0x405 > [] i915_pci_probe+0xd/0xf > [] local_pci_probe+0xe/0x10 > [] pci_device_probe+0x46/0x69 > [] driver_probe_device+0xa2/0x11d > [] __driver_attach+0x4c/0x6b > [] bus_for_each_dev+0x3b/0x63 > [] driver_attach+0x14/0x16 > [] bus_add_driver+0x98/0x1ab > [] driver_register+0x6f/0xd3 > [] __pci_register_driver+0x46/0xa5 > [] drm_init+0x5b/0xb3 > [] i915_init+0x46/0x48 > [] _stext+0x4a/0x111 > [] kernel_init+0x17f/0x1d0 > [] kernel_thread_helper+0x7/0x10 > [] 0xffffffff > > -> #1 ((fb_notifier_list).rwsem){..--}: > [] __lock_acquire+0x1068/0x137e > [] lock_acquire+0x5e/0x7a > [] down_read+0x2a/0x3e > [] __blocking_notifier_call_chain+0x24/0x4c > [] blocking_notifier_call_chain+0xc/0xe > [] fb_notifier_call_chain+0x11/0x13 > [] register_framebuffer+0x1e2/0x1f3 > [] intelfb_probe+0x491/0x4fb > [] drm_helper_initial_config+0x148/0x152 > [] i915_driver_load+0x8b2/0x912 > [] drm_get_dev+0x343/0x405 > [] i915_pci_probe+0xd/0xf > [] local_pci_probe+0xe/0x10 > [] pci_device_probe+0x46/0x69 > [] driver_probe_device+0xa2/0x11d > [] __driver_attach+0x4c/0x6b > [] bus_for_each_dev+0x3b/0x63 > [] driver_attach+0x14/0x16 > [] bus_add_driver+0x98/0x1ab > [] driver_register+0x6f/0xd3 > [] __pci_register_driver+0x46/0xa5 > [] drm_init+0x5b/0xb3 > [] i915_init+0x46/0x48 > [] _stext+0x4a/0x111 > [] kernel_init+0x17f/0x1d0 > [] kernel_thread_helper+0x7/0x10 > [] 0xffffffff > > -> #0 (&fb_info->lock){--..}: > [] __lock_acquire+0xd47/0x137e > [] lock_acquire+0x5e/0x7a > [] mutex_lock_nested+0xe0/0x267 > [] fb_mmap+0x83/0x153 > [] mmap_region+0x21c/0x3ab > [] do_mmap_pgoff+0x250/0x2a2 > [] sys_mmap2+0x5a/0x7b > [] syscall_call+0x7/0xb > [] 0xffffffff > > other info that might help us debug this: > > 1 lock held by plymouthd/746: > #0: (&mm->mmap_sem){----}, at: [] sys_mmap2+0x44/0x7b > > stack backtrace: > Pid: 746, comm: plymouthd Not tainted 2.6.29.5-191.eeepc.fc11.i686.PAE #1 > Call Trace: > [] ? printk+0xf/0x11 > [] print_circular_bug_tail+0xab/0xb6 > [] __lock_acquire+0xd47/0x137e > [] ? fb_mmap+0x83/0x153 > [] lock_acquire+0x5e/0x7a > [] ? fb_mmap+0x83/0x153 > [] mutex_lock_nested+0xe0/0x267 > [] ? fb_mmap+0x83/0x153 > [] ? fb_mmap+0x83/0x153 > [] fb_mmap+0x83/0x153 > [] mmap_region+0x21c/0x3ab > [] do_mmap_pgoff+0x250/0x2a2 > [] sys_mmap2+0x5a/0x7b > [] syscall_call+0x7/0xb > > Any ideas what could be causing this and how to solve it? > > Ahmad Thats a lockdep warning, please report it. After that you can simply disable the lockdep checker in your kernel config and you wont see them anymore. From drago01 at gmail.com Sun Jul 12 11:43:36 2009 From: drago01 at gmail.com (drago01) Date: Sun, 12 Jul 2009 13:43:36 +0200 Subject: Fw: Kernel Loading Sequence In-Reply-To: <416632.59640.qm@web51104.mail.re2.yahoo.com> References: <800987.93403.qm@web51101.mail.re2.yahoo.com> <416632.59640.qm@web51104.mail.re2.yahoo.com> Message-ID: On Sun, Jul 12, 2009 at 1:32 PM, Ahmad Al-Yaman wrote: > Thank you, I adjusted the config file as you recommended and the messages > are gone. Where should I report this lockdep? Depends on which kernel / patches do you use. If it is a vanilla tarball then upstream (lkml / bugzilla.kernel.org) if you are using the fedora kernel bugzilla.redhat.com From davej at redhat.com Sun Jul 12 15:28:22 2009 From: davej at redhat.com (Dave Jones) Date: Sun, 12 Jul 2009 11:28:22 -0400 Subject: Fw: Kernel Loading Sequence In-Reply-To: References: <800987.93403.qm@web51101.mail.re2.yahoo.com> <416632.59640.qm@web51104.mail.re2.yahoo.com> Message-ID: <20090712152822.GA2517@redhat.com> On Sun, Jul 12, 2009 at 01:43:36PM +0200, drago01 wrote: > On Sun, Jul 12, 2009 at 1:32 PM, Ahmad Al-Yaman wrote: > > Thank you, I adjusted the config file as you recommended and the messages > > are gone. Where should I report this lockdep? > > Depends on which kernel / patches do you use. > If it is a vanilla tarball then upstream (lkml / bugzilla.kernel.org) > if you are using the fedora kernel bugzilla.redhat.com It's already fixed in 2.6.31rc2 Fedora 11 will pick it up when we rebase, it's not a critical patch. Rawhide is already fixed. Dave From ahmad221284 at yahoo.com Mon Jul 13 07:31:19 2009 From: ahmad221284 at yahoo.com (Ahmad Al-Yaman) Date: Mon, 13 Jul 2009 00:31:19 -0700 (PDT) Subject: Fw: Kernel Loading Sequence In-Reply-To: <20090712152822.GA2517@redhat.com> References: <800987.93403.qm@web51101.mail.re2.yahoo.com> <416632.59640.qm@web51104.mail.re2.yahoo.com> <20090712152822.GA2517@redhat.com> Message-ID: <926148.16365.qm@web51111.mail.re2.yahoo.com> Thank you for the info. I just have one more question. I'm still getting the following messages before plymouth loads: ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f] hub 1-0:1.0: unable to enumerate USB device on port 7 I looked those issues up and I know the first is supposed to be fixed in 2.6.30 and the second is being worked on. My question is: which kernel config setting should I enable/disable so as not to show those messages on startup? Thank you again for the help. Ahmad ________________________________ From: Dave Jones To: drago01 Cc: fedora-kernel-list at redhat.com; Ahmad Al-Yaman Sent: Sunday, July 12, 2009 6:28:22 PM Subject: Re: Fw: Kernel Loading Sequence On Sun, Jul 12, 2009 at 01:43:36PM +0200, drago01 wrote: > On Sun, Jul 12, 2009 at 1:32 PM, Ahmad Al-Yaman wrote: > > Thank you, I adjusted the config file as you recommended and the messages > > are gone. Where should I report this lockdep? > > Depends on which kernel / patches do you use. > If it is a vanilla tarball then upstream (lkml / bugzilla.kernel.org) > if you are using the fedora kernel bugzilla.redhat.com It's already fixed in 2.6.31rc2 Fedora 11 will pick it up when we rebase, it's not a critical patch. Rawhide is already fixed. Dave _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list From realyr at gmail.com Mon Jul 13 03:40:31 2009 From: realyr at gmail.com (real yr) Date: Mon, 13 Jul 2009 11:40:31 +0800 Subject: Two kernels on a SINGLE machine Message-ID: There is a smp-machine, I want to run two kernels on this machine. For example, I want to split the cpus and others resources( if needed) into two collections: Collection A and Collection B. In Collection A, I run a linux kernel, and in Collection B, I load another linux kernel. I don't know if this is right. Thanks in advance. From mjg at redhat.com Thu Jul 16 21:28:57 2009 From: mjg at redhat.com (Matthew Garrett) Date: Thu, 16 Jul 2009 22:28:57 +0100 Subject: ASPM enabled by default - mild potential for breakage Message-ID: <20090716212857.GA23301@srcf.ucam.org> I've just flicked ASPM (Active State Power Management - runtime power saving on PCIe hardware) on by default, and it'll be that way in the next rawhide kernel build. There's the potential for some buggy hardware to be upset by this. If your system no longer boots or some hardware doesn't work, try booting with the pcie_aspm=off argument. If that fixes things please file a bug against the kernel and assign it to me (mjg at redhat.com). Include dmesg and the output of lspci -n. There's some reasonable heuristics in the kernel to detect supported hardware, so I'm hoping that people shouldn't see any adverse affects. -- Matthew Garrett | mjg59 at srcf.ucam.org From notting at redhat.com Fri Jul 17 17:01:54 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 17 Jul 2009 13:01:54 -0400 Subject: [PATCH] build a 'full' package on i686 Message-ID: <20090717170153.GA7170@nostromo.devel.redhat.com> This is needed for the i686-by-default feature. Bill -------------- next part -------------- Index: kernel.spec =================================================================== RCS file: /cvs/extras/rpms/kernel/devel/kernel.spec,v retrieving revision 1.1634 diff -u -r1.1634 kernel.spec --- kernel.spec 17 Jul 2009 02:07:24 -0000 1.1634 +++ kernel.spec 17 Jul 2009 17:01:15 -0000 @@ -195,9 +195,8 @@ %endif %define debuginfodir /usr/lib/debug -# We only build -PAE for 686 as of Fedora 11. +# We only build -PAE on 686. %ifarch i686 -%define with_up 0 %define with_pae 1 %else %define with_pae 0 @@ -249,9 +248,9 @@ %define with_perf 0 %endif -# no need to build headers again for these arches, -# they can just use i586 and ppc64 headers -%ifarch i686 ppc64iseries +# no need to build headers again for this arch, +# they can just use ppc64 headers +%ifarch ppc64iseries %define with_headers 0 %endif From davej at redhat.com Mon Jul 20 03:02:10 2009 From: davej at redhat.com (Dave Jones) Date: Sun, 19 Jul 2009 23:02:10 -0400 Subject: [PATCH] build a 'full' package on i686 In-Reply-To: <20090717170153.GA7170@nostromo.devel.redhat.com> References: <20090717170153.GA7170@nostromo.devel.redhat.com> Message-ID: <20090720030209.GA8870@redhat.com> On Fri, Jul 17, 2009 at 01:01:54PM -0400, Bill Nottingham wrote: > This is needed for the i686-by-default feature. > > Bill > Index: kernel.spec > =================================================================== > RCS file: /cvs/extras/rpms/kernel/devel/kernel.spec,v > retrieving revision 1.1634 > diff -u -r1.1634 kernel.spec > --- kernel.spec 17 Jul 2009 02:07:24 -0000 1.1634 > +++ kernel.spec 17 Jul 2009 17:01:15 -0000 > @@ -195,9 +195,8 @@ > %endif > %define debuginfodir /usr/lib/debug > > -# We only build -PAE for 686 as of Fedora 11. > +# We only build -PAE on 686. > %ifarch i686 > -%define with_up 0 > %define with_pae 1 > %else > %define with_pae 0 The naming of 'with_up' is subtle here. With this change, we'll try building a '686' kernel as well as a '686-PAE'. (which no longer exists, in favour of using the 586 kernel) Dave From notting at redhat.com Mon Jul 20 14:12:06 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 20 Jul 2009 10:12:06 -0400 Subject: [PATCH] build a 'full' package on i686 In-Reply-To: <20090720030209.GA8870@redhat.com> References: <20090717170153.GA7170@nostromo.devel.redhat.com> <20090720030209.GA8870@redhat.com> Message-ID: <20090720141205.GA23407@nostromo.devel.redhat.com> Dave Jones (davej at redhat.com) said: > > +# We only build -PAE on 686. > > %ifarch i686 > > -%define with_up 0 > > %define with_pae 1 > > %else > > %define with_pae 0 > > The naming of 'with_up' is subtle here. With this change, > we'll try building a '686' kernel as well as a '686-PAE'. That was the intent, as the i586 package would be going away. Bill From davej at redhat.com Mon Jul 20 14:16:45 2009 From: davej at redhat.com (Dave Jones) Date: Mon, 20 Jul 2009 10:16:45 -0400 Subject: [PATCH] build a 'full' package on i686 In-Reply-To: <20090720141205.GA23407@nostromo.devel.redhat.com> References: <20090717170153.GA7170@nostromo.devel.redhat.com> <20090720030209.GA8870@redhat.com> <20090720141205.GA23407@nostromo.devel.redhat.com> Message-ID: <20090720141645.GB2534@redhat.com> On Mon, Jul 20, 2009 at 10:12:06AM -0400, Bill Nottingham wrote: > Dave Jones (davej at redhat.com) said: > > > +# We only build -PAE on 686. > > > %ifarch i686 > > > -%define with_up 0 > > > %define with_pae 1 > > > %else > > > %define with_pae 0 > > > > The naming of 'with_up' is subtle here. With this change, > > we'll try building a '686' kernel as well as a '686-PAE'. > > That was the intent, as the i586 package would be going away. Oh, I thought that proposal got shot down. We're really dropping support for all those old systems? I'm ok with it if it's been approved, but want to be sure before I start gutting the kernel of 586isms. Dave From notting at redhat.com Mon Jul 20 14:26:04 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 20 Jul 2009 10:26:04 -0400 Subject: [PATCH] build a 'full' package on i686 In-Reply-To: <20090720141645.GB2534@redhat.com> References: <20090717170153.GA7170@nostromo.devel.redhat.com> <20090720030209.GA8870@redhat.com> <20090720141205.GA23407@nostromo.devel.redhat.com> <20090720141645.GB2534@redhat.com> Message-ID: <20090720142604.GG23407@nostromo.devel.redhat.com> Dave Jones (davej at redhat.com) said: > Oh, I thought that proposal got shot down. The proposal to have the baseline be i686 + SSE2 was shot down; bare i686 was approved. Bill From Quentin at Armitage.org.uk Mon Jul 20 21:27:40 2009 From: Quentin at Armitage.org.uk (Quentin Armitage) Date: Mon, 20 Jul 2009 22:27:40 +0100 Subject: [PATCH] build a 'full' package on i686 Message-ID: <1248125260.2212.11.camel@samson.armitage.org.uk> Bill Nottingham wrote: > The proposal to have the baseline be i686 + SSE2 was shot down; bare > i686 was approved. Does this mean that an i686 kernel without PAE will still be built (my laptop processor does not have PAE so I am rather interested)? I note that the latest build on Koji has not built an i686 without PAE version, and the comments against kernel.spec revision 1.1639 suggests there won't be a non-PAE kernel. On the other hand, revision 1.1640 references Source31: config-i686, although I don't see that file in CVS. Quentin From davej at redhat.com Mon Jul 20 22:48:01 2009 From: davej at redhat.com (Dave Jones) Date: Mon, 20 Jul 2009 18:48:01 -0400 Subject: [PATCH] build a 'full' package on i686 In-Reply-To: <1248125260.2212.11.camel@samson.armitage.org.uk> References: <1248125260.2212.11.camel@samson.armitage.org.uk> Message-ID: <20090720224801.GA2528@redhat.com> On Mon, Jul 20, 2009 at 10:27:40PM +0100, Quentin Armitage wrote: > Bill Nottingham wrote: > > The proposal to have the baseline be i686 + SSE2 was shot down; bare > > i686 was approved. > > Does this mean that an i686 kernel without PAE will still be built (my > laptop processor does not have PAE so I am rather interested)? yes > I note > that the latest build on Koji has not built an i686 without PAE version, > and the comments against kernel.spec revision 1.1639 suggests there > won't be a non-PAE kernel. On the other hand, revision 1.1640 references > Source31: config-i686, although I don't see that file in CVS. screwup on my part. it's unnecessary. the non-PAE build is basically just config-x86-generic. Dave From Quentin at Armitage.org.uk Wed Jul 22 15:56:27 2009 From: Quentin at Armitage.org.uk (Quentin Armitage) Date: Wed, 22 Jul 2009 16:56:27 +0100 Subject: [PATCH] build a 'full' package on i686 In-Reply-To: <20090720224801.GA2528@redhat.com> References: <1248125260.2212.11.camel@samson.armitage.org.uk> <20090720224801.GA2528@redhat.com> Message-ID: <1248278187.18904.13.camel@samson.armitage.org.uk> On Mon, 2009-07-20 at 18:48 -0400, Dave Jones wrote: > On Mon, Jul 20, 2009 at 10:27:40PM +0100, Quentin Armitage wrote: > > Bill Nottingham wrote: > > > The proposal to have the baseline be i686 + SSE2 was shot down; bare > > > i686 was approved. > > > > Does this mean that an i686 kernel without PAE will still be built (my > > laptop processor does not have PAE so I am rather interested)? > > yes > > > I note > > that the latest build on Koji has not built an i686 without PAE version, > > and the comments against kernel.spec revision 1.1639 suggests there > > won't be a non-PAE kernel. On the other hand, revision 1.1640 references > > Source31: config-i686, although I don't see that file in CVS. > > screwup on my part. it's unnecessary. the non-PAE build is basically > just config-x86-generic. > > Dave Now there is an i686 kernel available in Rawhide, should doing a yum update update my i586 kernel to the latest i686 version? yum update shows that it will update kernel-firmware.noarch to 2.6.31-0.81.rc3.git4.fc12 and kernel-headers.i686 to 0:2.6.31-0.81.rc3.git4.fc12, but it does not update the kernel package. Indeed, if I try yum install kernel-2.6.31-0.81.rc3.git4.fc12.i686.rpm, yum reports: kernel-2.6.31-0.81.rc3.git4.fc12.i686.rpm: does not update installed package. Quentin From sgruszka at redhat.com Thu Jul 23 14:35:39 2009 From: sgruszka at redhat.com (Stanislaw Gruszka) Date: Thu, 23 Jul 2009 16:35:39 +0200 Subject: [PATCH 0/3] iwl3945 driver fixes for Fedora 11 (2.6.29) Message-ID: <1248359742-15865-1-git-send-email-sgruszka@redhat.com> Due to backport of patch linux-2.6-iwl3945-report-killswitch-changes-even-if-the-interface-is-down.patch we have bunch of iwl3945 bugs (race conditions) that are not reproducible on vanilla 2.6.29. These patches address them (at least some of them). [PATCH 1/3] iwl3945: release resources before shutting down (F11 backport) Resolves RHBZ 499811 (and partially 501117), backport of upstream commit, 2.6.30 has this fix. [PATCH 2/3] iwl3945: add debugging for wrong command queue (F11 backport) Partially resolves RHBZ 501117. Backport of upstream commit, 2.6.30 has this commit. Bug is still reproducible, but after patch applied system not crash. Further work needed to fully resolve the problem, but I'm not sure is easy way to fix 501117 (DMA related memory corruption) other than rebase driver to that we have in 2.6.31. [PATCH 3/3] iwl3945: fix rfkill SW and HW mishmash Resolves RHBZ 498622. The bug is fixed in mainline from 2.6.31-rc3 due to total rewrite of rfkill framework (commit: 19d337dff95cbf76edd3ad95c0cee2732c3e1ec5 "rfkill: rewrite"). However it is reproducible on 2.6.30 as well. Perhaps I should post this patch against 2.6.30, but I'm not sure is such kind of patches, which are not backports, are acceptable in stable kernel. I tested all patches on my laptop. From sgruszka at redhat.com Thu Jul 23 14:35:40 2009 From: sgruszka at redhat.com (Stanislaw Gruszka) Date: Thu, 23 Jul 2009 16:35:40 +0200 Subject: [PATCH 1/3] iwl3945: release resources before shutting down (F11 backport) In-Reply-To: <1248359742-15865-1-git-send-email-sgruszka@redhat.com> References: <1248359742-15865-1-git-send-email-sgruszka@redhat.com> Message-ID: <1248359742-15865-2-git-send-email-sgruszka@redhat.com> commit d552bfb65241a35d48e44ddb0d27e0454f579ab4 Author: Kolekar, Abhijeet Date: Fri Dec 19 10:37:41 2008 +0800 iwl3945: release resources before shutting down Release resource before shutting down and notify upper stack. Signed-off-by: Abhijeet Kolekar Signed-off-by: Zhu Yi Signed-off-by: John W. Linville --- drivers/net/wireless/iwlwifi/iwl3945-base.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c index 22e7e99..8cb0fa2 100644 --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c @@ -8096,7 +8096,12 @@ static void __devexit iwl3945_pci_remove(struct pci_dev *pdev) set_bit(STATUS_EXIT_PENDING, &priv->status); - iwl3945_down(priv); + if (priv->mac80211_registered) { + ieee80211_unregister_hw(priv->hw); + priv->mac80211_registered = 0; + } else { + iwl3945_down(priv); + } /* make sure we flush any pending irq or * tasklet for the driver @@ -8121,9 +8126,6 @@ static void __devexit iwl3945_pci_remove(struct pci_dev *pdev) iwl3945_unset_hw_setting(priv); iwl3945_clear_stations_table(priv); - if (priv->mac80211_registered) - ieee80211_unregister_hw(priv->hw); - /*netif_stop_queue(dev); */ flush_workqueue(priv->workqueue); -- 1.6.2.5 From sgruszka at redhat.com Thu Jul 23 14:35:41 2009 From: sgruszka at redhat.com (Stanislaw Gruszka) Date: Thu, 23 Jul 2009 16:35:41 +0200 Subject: [PATCH 2/3] iwl3945: add debugging for wrong command queue (F11 backport) In-Reply-To: <1248359742-15865-2-git-send-email-sgruszka@redhat.com> References: <1248359742-15865-1-git-send-email-sgruszka@redhat.com> <1248359742-15865-2-git-send-email-sgruszka@redhat.com> Message-ID: <1248359742-15865-3-git-send-email-sgruszka@redhat.com> commit 638d0eb9197d1e285451f6594184fcfc9c2a5d44 Author: Chatre, Reinette Date: Mon Jan 19 15:30:24 2009 -0800 iwl3945: add debugging for wrong command queue We encountered a problem related to this BUG and need to obtain more debugging information. See bug report at http://marc.info/?l=linux-wireless&m=123147215829854&w=2 Signed-off-by: Reinette Chatre Signed-off-by: John W. Linville --- drivers/net/wireless/iwlwifi/iwl3945-base.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c index 8cb0fa2..5011a79 100644 --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c @@ -3349,7 +3349,14 @@ static void iwl3945_tx_cmd_complete(struct iwl3945_priv *priv, int cmd_index; struct iwl3945_cmd *cmd; - BUG_ON(txq_id != IWL_CMD_QUEUE_NUM); + if (WARN(txq_id != IWL_CMD_QUEUE_NUM, + "wrong command queue %d, sequence 0x%X readp=%d writep=%d\n", + txq_id, sequence, + priv->txq[IWL_CMD_QUEUE_NUM].q.read_ptr, + priv->txq[IWL_CMD_QUEUE_NUM].q.write_ptr)) { + /* Not in F11: iwl_print_hex_dump(priv, IWL_DL_INFO , rxb, 32); */ + return; + } cmd_index = get_cmd_index(&priv->txq[IWL_CMD_QUEUE_NUM].q, index, huge); cmd = &priv->txq[IWL_CMD_QUEUE_NUM].cmd[cmd_index]; -- 1.6.2.5 From sgruszka at redhat.com Thu Jul 23 14:35:42 2009 From: sgruszka at redhat.com (Stanislaw Gruszka) Date: Thu, 23 Jul 2009 16:35:42 +0200 Subject: [PATCH 3/3] iwl3945: fix rfkill SW and HW mishmash In-Reply-To: <1248359742-15865-3-git-send-email-sgruszka@redhat.com> References: <1248359742-15865-1-git-send-email-sgruszka@redhat.com> <1248359742-15865-2-git-send-email-sgruszka@redhat.com> <1248359742-15865-3-git-send-email-sgruszka@redhat.com> Message-ID: <1248359742-15865-4-git-send-email-sgruszka@redhat.com> Disable SW switch regardless of HW switch state (we can only enable radio when both SW and HW rfkill switches are off). Report to rfkill subsystem SW switch state before HW switch state to move rfkill subsystem to SOFT_BLOCK rather than HARD_BLOCK, otherwise in some conditions we would not be able to turn radio back on. --- drivers/net/wireless/iwlwifi/iwl3945-base.c | 17 +++++++---------- 1 files changed, 7 insertions(+), 10 deletions(-) diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c index 5011a79..6065921 100644 --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c @@ -8216,7 +8216,8 @@ static int iwl3945_rfkill_soft_rf_kill(void *data, enum rfkill_state state) case RFKILL_STATE_UNBLOCKED: if (iwl3945_is_rfkill_hw(priv)) { err = -EBUSY; - goto out_unlock; + /* pass error to rfkill core to make it state HARD + * BLOCKED and disable software kill switch */ } iwl3945_radio_kill_sw(priv, 0); break; @@ -8227,9 +8228,8 @@ static int iwl3945_rfkill_soft_rf_kill(void *data, enum rfkill_state state) IWL_WARNING("we received unexpected RFKILL state %d\n", state); break; } -out_unlock: - mutex_unlock(&priv->mutex); + mutex_unlock(&priv->mutex); return err; } @@ -8291,15 +8291,12 @@ void iwl3945_rfkill_set_hw_state(struct iwl3945_priv *priv) if (!priv->rfkill) return; - if (iwl3945_is_rfkill_hw(priv)) { + if (iwl3945_is_rfkill_sw(priv)) + rfkill_force_state(priv->rfkill, RFKILL_STATE_SOFT_BLOCKED); + else if (iwl3945_is_rfkill_hw(priv)) rfkill_force_state(priv->rfkill, RFKILL_STATE_HARD_BLOCKED); - return; - } - - if (!iwl3945_is_rfkill_sw(priv)) - rfkill_force_state(priv->rfkill, RFKILL_STATE_UNBLOCKED); else - rfkill_force_state(priv->rfkill, RFKILL_STATE_SOFT_BLOCKED); + rfkill_force_state(priv->rfkill, RFKILL_STATE_UNBLOCKED); } #endif -- 1.6.2.5 From linville at redhat.com Thu Jul 23 17:31:47 2009 From: linville at redhat.com (John W. Linville) Date: Thu, 23 Jul 2009 13:31:47 -0400 Subject: [PATCH 0/3] iwl3945 driver fixes for Fedora 11 (2.6.29) In-Reply-To: <1248359742-15865-1-git-send-email-sgruszka@redhat.com> References: <1248359742-15865-1-git-send-email-sgruszka@redhat.com> Message-ID: <20090723173147.GA5272@redhat.com> On Thu, Jul 23, 2009 at 04:35:39PM +0200, Stanislaw Gruszka wrote: > Due to backport of patch > > linux-2.6-iwl3945-report-killswitch-changes-even-if-the-interface-is-down.patch > > we have bunch of iwl3945 bugs (race conditions) that are not reproducible > on vanilla 2.6.29. These patches address them (at least some of them). Looks good to me. I think Kyle agreed to merge them into Fedora kernels. Thanks! John -- John W. Linville Linux should be at the core linville at redhat.com of your literate lifestyle. From kyle at mcmartin.ca Thu Jul 23 18:11:20 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Thu, 23 Jul 2009 14:11:20 -0400 Subject: [PATCH 0/3] iwl3945 driver fixes for Fedora 11 (2.6.29) In-Reply-To: <20090723173147.GA5272@redhat.com> References: <1248359742-15865-1-git-send-email-sgruszka@redhat.com> <20090723173147.GA5272@redhat.com> Message-ID: <20090723181120.GL11051@bombadil.infradead.org> On Thu, Jul 23, 2009 at 01:31:47PM -0400, John W. Linville wrote: > On Thu, Jul 23, 2009 at 04:35:39PM +0200, Stanislaw Gruszka wrote: > > Due to backport of patch > > > > linux-2.6-iwl3945-report-killswitch-changes-even-if-the-interface-is-down.patch > > > > we have bunch of iwl3945 bugs (race conditions) that are not reproducible > > on vanilla 2.6.29. These patches address them (at least some of them). > > Looks good to me. I think Kyle agreed to merge them into Fedora kernels. > > Thanks! > Applied. (sorry John, I've got kyle at redhat but not kylem at redhat.) cheers, Kyle From notting at redhat.com Wed Jul 29 14:53:10 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 29 Jul 2009 10:53:10 -0400 Subject: [RFC PATCH] Disable alsa snd-pcsp driver Message-ID: <20090729145309.GA8392@nostromo.devel.redhat.com> Because ... why would you want to use this? Ever? Bill -------------- next part -------------- ? diff ? kern.diff ? linux-2.6.28.tar.bz2 ? patch-2.6.29-rc8-git6.bz2 ? patch-2.6.29-rc8.bz2 Index: config-generic =================================================================== RCS file: /cvs/extras/rpms/kernel/devel/config-generic,v retrieving revision 1.314 diff -u -r1.314 config-generic --- config-generic 28 Jul 2009 13:35:42 -0000 1.314 +++ config-generic 29 Jul 2009 14:52:04 -0000 @@ -2659,7 +2659,7 @@ CONFIG_SND_NM256=m CONFIG_SND_OXYGEN=m CONFIG_SND_RME32=m -CONFIG_SND_PCSP=m +# CONFIG_SND_PCSP is not set CONFIG_SND_PCXHR=m CONFIG_SND_RIPTIDE=m CONFIG_SND_RME96=m From ajax at redhat.com Wed Jul 29 15:33:08 2009 From: ajax at redhat.com (Adam Jackson) Date: Wed, 29 Jul 2009 11:33:08 -0400 Subject: [RFC PATCH] Disable alsa snd-pcsp driver In-Reply-To: <20090729145309.GA8392@nostromo.devel.redhat.com> References: <20090729145309.GA8392@nostromo.devel.redhat.com> Message-ID: <1248881588.5139.313.camel@atropine.boston.devel.redhat.com> On Wed, 2009-07-29 at 10:53 -0400, Bill Nottingham wrote: > Because ... why would you want to use this? Ever? <@mezcalero> people who enable that module in the kernel deserve to suffer Kill it kill it kill it. - ajax From kyle at mcmartin.ca Wed Jul 29 15:42:11 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Wed, 29 Jul 2009 11:42:11 -0400 Subject: [RFC PATCH] Disable alsa snd-pcsp driver In-Reply-To: <1248881588.5139.313.camel@atropine.boston.devel.redhat.com> References: <20090729145309.GA8392@nostromo.devel.redhat.com> <1248881588.5139.313.camel@atropine.boston.devel.redhat.com> Message-ID: <20090729154211.GD26333@bombadil.infradead.org> On Wed, Jul 29, 2009 at 11:33:08AM -0400, Adam Jackson wrote: > On Wed, 2009-07-29 at 10:53 -0400, Bill Nottingham wrote: > > Because ... why would you want to use this? Ever? > > <@mezcalero> people who enable that module in the kernel deserve to > suffer > > Kill it kill it kill it. > Just for that comment, I think we'll make it =y. From jcm at redhat.com Wed Jul 29 21:07:53 2009 From: jcm at redhat.com (Jon Masters) Date: Wed, 29 Jul 2009 17:07:53 -0400 Subject: [RFC PATCH] Disable alsa snd-pcsp driver In-Reply-To: <20090729145309.GA8392@nostromo.devel.redhat.com> References: <20090729145309.GA8392@nostromo.devel.redhat.com> Message-ID: <1248901673.1506.0.camel@localhost.localdomain> On Wed, 2009-07-29 at 10:53 -0400, Bill Nottingham wrote: > Because ... why would you want to use this? Ever? I actually quite like having it - is it breaking something? Jon. From zaitcev at redhat.com Thu Jul 30 00:12:28 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 29 Jul 2009 18:12:28 -0600 Subject: [RFC PATCH] Disable alsa snd-pcsp driver In-Reply-To: <1248901673.1506.0.camel@localhost.localdomain> References: <20090729145309.GA8392@nostromo.devel.redhat.com> <1248901673.1506.0.camel@localhost.localdomain> Message-ID: <20090729181228.3274a5a7@redhat.com> On Wed, 29 Jul 2009 17:07:53 -0400, Jon Masters wrote: > On Wed, 2009-07-29 at 10:53 -0400, Bill Nottingham wrote: > > Because ... why would you want to use this? Ever? > > I actually quite like having it - is it breaking something? I don't understand, how do you use it? It's not the same thing as pcspkr that beeps, it's actually the software 1-bit DAC. -- Pete From jcm at redhat.com Thu Jul 30 20:37:56 2009 From: jcm at redhat.com (Jon Masters) Date: Thu, 30 Jul 2009 16:37:56 -0400 Subject: [RFC PATCH] Disable alsa snd-pcsp driver In-Reply-To: <1248901673.1506.0.camel@localhost.localdomain> References: <20090729145309.GA8392@nostromo.devel.redhat.com> <1248901673.1506.0.camel@localhost.localdomain> Message-ID: <1248986276.10029.64.camel@perihelion.bos.jonmasters.org> On Wed, 2009-07-29 at 17:07 -0400, Jon Masters wrote: > On Wed, 2009-07-29 at 10:53 -0400, Bill Nottingham wrote: > > Because ... why would you want to use this? Ever? > > I actually quite like having it - is it breaking something? I take that back. Obviously, I thought you were killing the PC speaker, not this other module that claims the same device (forgot there's a difference in naming of a couple characters). Kill it ;) Jon.