date:20111002

Re: FreeBSD 9: Fn+* keyboard combinations aren't working anymore.

2011-10-02 Thread arrowdodger

On Wed, Sep 28, 2011 at 5:44 PM, arrowdodger 6year...@gmail.com wrote:

 On Wed, Sep 28, 2011 at 5:32 PM, Lars Engels lars.eng...@0x20.net wrote:

 On Wed, Sep 28, 2011 at 05:30:25PM +0400, arrowdodger wrote:
  Hello. I've used FreeBSD 8-STABLE on my Asus K40IN notebook. This
 notebook
  has an key combination (Fn+F6/F7)to change monitor brightness. After
 i've
  updated my system to 9-STABLE, these combinations stopped working. It's
  worth mentioning, that these combinations still work at boot screen.

 Have you tried loading acpi_asus.ko?


 I've tried to do so when i was on 8-STABLE and it didn't work. It's not
 working for me on 9-STABLE too:
 acpi_asus0: Unsupported Asus laptop: K40IN

 All hotkeys, except ones for switching Wi-Fi and adjusting volume, were
 working on 8-STABLE.


If no one knows a fix for this problem, maybe someone can point me to
relevant code? I may try to bisect revisions, or to check commit log.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

alq_open_flags() panics in _mtx_lock_flags()

2011-10-02 Thread Lev Serebryakov

Hello, FreeBSD.

 I'm trying to create logging queue with alq kernel API. I call
 alq_open_flags() like this in my module:

error = alq_open_flags(sc-sc_alq, sc-sc_vnode_name,
curthread-td_ucred, ALQ_DEFAULT_CMODE,
sizeof(struct g_log_entry), ALQ_ORDERED);

 and my system (10-CURRENT) panics with this stack trace (top frames
 are DDB-related, so I omit them):

#5  0xc06101c3 in kdb_trap (type=12, code=0, tf=0xc4e29990)
at /usr/home/lev/FreeBSD-head/sys/kern/subr_kdb.c:620
#6  0xc08290af in trap_fatal (frame=0xc4e29990, eva=136)
at /usr/home/lev/FreeBSD-head/sys/i386/i386/trap.c:958
#7  0xc08292c0 in trap_pfault (frame=0xc4e29990, usermode=0, eva=136)
at /usr/home/lev/FreeBSD-head/sys/i386/i386/trap.c:880
#8  0xc0829f46 in trap (frame=0xc4e29990)
at /usr/home/lev/FreeBSD-head/sys/i386/i386/trap.c:555
#9  0xc0812e7c in calltrap ()
at /usr/home/lev/FreeBSD-head/sys/i386/i386/exception.s:168
#10 0xc05cafc0 in _mtx_lock_flags (m=0x78, opts=0, 
file=0xc088c140 /usr/home/lev/FreeBSD-head/sys/kern/vfs_subr.c, 
line=2169) at /usr/home/lev/FreeBSD-head/sys/kern/kern_mutex.c:194
#11 0xc0672eb2 in vref (vp=0x0)
at /usr/home/lev/FreeBSD-head/sys/kern/vfs_subr.c:2169
#12 0xc066932f in namei (ndp=0xc4e29b74)
at /usr/home/lev/FreeBSD-head/sys/kern/vfs_lookup.c:264
#13 0xc0682900 in vn_open_cred (ndp=0xc4e29b74, flagp=0xc4e29be8, cmode=384, 
vn_open_flags=0, cred=0xc50fee80, fp=0x0)
at /usr/home/lev/FreeBSD-head/sys/kern/vfs_vnops.c:137
#14 0xc5c42609 in alq_open_flags (alqp=0xc550dc08, 
file=0xc5108d40 /usr/ada4.log, cred=0xc50fee80, cmode=384, size=28,
flags=16)
at /usr/home/lev/FreeBSD-head/sys/modules/alq/../../kern/kern_alq.c:451

  It seems, that vref() get NULL instead of valid pointer to struct
 vnode. But I have no idea -- why?! Yes, I have no such file created,
 but man alq(9) says, that it will create file for me. And if I point
 to existed file, it panic anyway.

  What do I do wrong?!

-- 
// Black Lion AKA Lev Serebryakov l...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

code in GEOM thread could not use vnode API (Was: alq_open_flags() panics in _mtx_lock_flags())

2011-10-02 Thread Lev Serebryakov

Hello, Current.
You wrote 2 октября 2011 г., 19:32:23:

  It seems, that error only occurs when I call alq API from geom
threads (from g_events, for example). Module, which is not GEOM
class, could use this API without any problem!

  Is it normal, that GEOM could not use vnode API? Is it normal, that
this leads to panic, and not some diagnostic messages, even with
WITNESS and other diagnostic options turned on?

 I'm looping fs@ and geom@, as it seems to be related to them.

  I'm trying to create logging queue with alq kernel API. I call
  alq_open_flags() like this in my module:

 error = alq_open_flags(sc-sc_alq, sc-sc_vnode_name,
 curthread-td_ucred, ALQ_DEFAULT_CMODE,
 sizeof(struct g_log_entry), ALQ_ORDERED);

  and my system (10-CURRENT) panics with this stack trace (top frames
  are DDB-related, so I omit them):

 #5  0xc06101c3 in kdb_trap (type=12, code=0, tf=0xc4e29990)
 at /usr/home/lev/FreeBSD-head/sys/kern/subr_kdb.c:620
 #6  0xc08290af in trap_fatal (frame=0xc4e29990, eva=136)
 at /usr/home/lev/FreeBSD-head/sys/i386/i386/trap.c:958
 #7  0xc08292c0 in trap_pfault (frame=0xc4e29990, usermode=0, eva=136)
 at /usr/home/lev/FreeBSD-head/sys/i386/i386/trap.c:880
 #8  0xc0829f46 in trap (frame=0xc4e29990)
 at /usr/home/lev/FreeBSD-head/sys/i386/i386/trap.c:555
 #9  0xc0812e7c in calltrap ()
 at /usr/home/lev/FreeBSD-head/sys/i386/i386/exception.s:168
 #10 0xc05cafc0 in _mtx_lock_flags (m=0x78, opts=0, 
 file=0xc088c140 /usr/home/lev/FreeBSD-head/sys/kern/vfs_subr.c, 
 line=2169) at /usr/home/lev/FreeBSD-head/sys/kern/kern_mutex.c:194
 #11 0xc0672eb2 in vref (vp=0x0)
 at /usr/home/lev/FreeBSD-head/sys/kern/vfs_subr.c:2169
 #12 0xc066932f in namei (ndp=0xc4e29b74)
 at /usr/home/lev/FreeBSD-head/sys/kern/vfs_lookup.c:264
 #13 0xc0682900 in vn_open_cred (ndp=0xc4e29b74, flagp=0xc4e29be8, cmode=384,
 vn_open_flags=0, cred=0xc50fee80, fp=0x0)
 at /usr/home/lev/FreeBSD-head/sys/kern/vfs_vnops.c:137
 #14 0xc5c42609 in alq_open_flags (alqp=0xc550dc08, 
 file=0xc5108d40 /usr/ada4.log, cred=0xc50fee80, cmode=384, size=28,
 flags=16)
 at
 /usr/home/lev/FreeBSD-head/sys/modules/alq/../../kern/kern_alq.c:451

   It seems, that vref() get NULL instead of valid pointer to struct
  vnode. But I have no idea -- why?! Yes, I have no such file created,
  but man alq(9) says, that it will create file for me. And if I point
  to existed file, it panic anyway.

   What do I do wrong?!

-- 
// Black Lion AKA Lev Serebryakov l...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

st_dev and st_ino for pipes

2011-10-02 Thread Kostik Belousov

Our implementation of pipes does not provide useful values for st_dev
and st_ino when stat(2) is done on an anonymous pipe. It was noted by the
people outside the project, e.g. Perl contains a workaround in one
of its modules, submitted by Debian/kFreeBSD developers, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537555
and the commit 16f708c9bc0dc48713b200 in the Perl git.

I think this is a non-conformance, since SUSv4 explicitely states
in the description of stat(2)
For all other file types defined in this volume of POSIX.1-2008, the
structure members st_mode, st_ino, st_dev, st_uid, st_gid, st_atim,
st_ctim, and st_mtim shall have meaningful values 

Patch below implements the requirement, by the cost of the small overhead
at the pipe creation time, and slightly bigger cost at the destruction.

Any comments ?

diff --git a/sys/fs/devfs/devfs_devs.c b/sys/fs/devfs/devfs_devs.c
index a2d3222..a111527 100644
--- a/sys/fs/devfs/devfs_devs.c
+++ b/sys/fs/devfs/devfs_devs.c
@@ -171,8 +171,7 @@ devfs_free(struct cdev *cdev)
cdp = cdev2priv(cdev);
if (cdev-si_cred != NULL)
crfree(cdev-si_cred);
-   if (cdp-cdp_inode  0)
-   free_unr(devfs_inos, cdp-cdp_inode);
+   devfs_free_cdp_inode(cdp-cdp_inode);
if (cdp-cdp_maxdirent  0) 
free(cdp-cdp_dirents, M_DEVFS2);
free(cdp, M_CDEVP);
@@ -394,7 +393,7 @@ devfs_delete(struct devfs_mount *dm, struct devfs_dirent 
*de, int flags)
mac_devfs_destroy(de);
 #endif
if (de-de_inode  DEVFS_ROOTINO) {
-   free_unr(devfs_inos, de-de_inode);
+   devfs_free_cdp_inode(de-de_inode);
de-de_inode = 0;
}
if (DEVFS_DE_DROP(de))
@@ -685,6 +684,21 @@ devfs_destroy(struct cdev *dev)
devfs_generation++;
 }
 
+ino_t
+devfs_alloc_cdp_inode(void)
+{
+
+   return (alloc_unr(devfs_inos));
+}
+
+void
+devfs_free_cdp_inode(ino_t ino)
+{
+
+   if (ino  0)
+   free_unr(devfs_inos, ino);
+}
+
 static void
 devfs_devs_init(void *junk __unused)
 {
diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c
index b7ae521..2edecf2 100644
--- a/sys/kern/sys_pipe.c
+++ b/sys/kern/sys_pipe.c
@@ -93,6 +93,7 @@ __FBSDID($FreeBSD$);
 
 #include sys/param.h
 #include sys/systm.h
+#include sys/conf.h
 #include sys/fcntl.h
 #include sys/file.h
 #include sys/filedesc.h
@@ -224,6 +225,8 @@ static int  pipe_zone_init(void *mem, int size, int flags);
 static voidpipe_zone_fini(void *mem, int size);
 
 static uma_zone_t pipe_zone;
+static struct unrhdr *pipeino_unr;
+static ino_t pipedev_ino;
 
 SYSINIT(vfs, SI_SUB_VFS, SI_ORDER_ANY, pipeinit, NULL);
 
@@ -235,6 +238,10 @@ pipeinit(void *dummy __unused)
pipe_zone_ctor, NULL, pipe_zone_init, pipe_zone_fini,
UMA_ALIGN_PTR, 0);
KASSERT(pipe_zone != NULL, (pipe_zone not initialized));
+   pipeino_unr = new_unrhdr(1, INT32_MAX, NULL);
+   KASSERT(pipeino_unr != NULL, (pipe fake inodes not initialized));
+   pipedev_ino = devfs_alloc_cdp_inode();
+   KASSERT(pipedev_ino  0, (pipe dev inode not initialized));
 }
 
 static int
@@ -562,6 +569,12 @@ pipe_create(pipe, backing)
/* If we're not backing this pipe, no need to do anything. */
error = 0;
}
+   if (error == 0) {
+   pipe-pipe_ino = alloc_unr(pipeino_unr);
+   if (pipe-pipe_ino == -1)
+   /* pipeclose will clear allocated kva */
+   error = ENOMEM;
+   }
return (error);
 }
 
@@ -1408,9 +1421,10 @@ pipe_stat(fp, ub, active_cred, td)
ub-st_ctim = pipe-pipe_ctime;
ub-st_uid = fp-f_cred-cr_uid;
ub-st_gid = fp-f_cred-cr_gid;
+   ub-st_dev = pipedev_ino;
+   ub-st_ino = pipe-pipe_ino;
/*
-* Left as 0: st_dev, st_ino, st_nlink, st_rdev, st_flags, st_gen.
-* XXX (st_dev, st_ino) should be unique.
+* Left as 0: st_nlink, st_rdev, st_flags, st_gen.
 */
return (0);
 }
@@ -1463,6 +1477,7 @@ pipeclose(cpipe)
 {
struct pipepair *pp;
struct pipe *ppipe;
+   ino_t ino;
 
KASSERT(cpipe != NULL, (pipeclose: cpipe == NULL));
 
@@ -1521,6 +1536,12 @@ pipeclose(cpipe)
knlist_destroy(cpipe-pipe_sel.si_note);
 
/*
+* Postpone the destroy of the fake inode number allocated for
+* our end, until pipe mtx is unlocked.
+*/
+   ino = cpipe-pipe_ino;
+
+   /*
 * If both endpoints are now closed, release the memory for the
 * pipe pair.  If not, unlock.
 */
@@ -1532,6 +1553,9 @@ pipeclose(cpipe)
uma_zfree(pipe_zone, cpipe-pipe_pair);
} else
PIPE_UNLOCK(cpipe);
+
+   if (ino  0)
+   free_unr(pipeino_unr, cpipe-pipe_ino);
 }
 
 /*ARGSUSED*/
diff --git a/sys/sys/conf.h b/sys/sys/conf.h
index 08e1582..7acd2e0 100644
--- a/sys/sys/conf.h
+++ b/sys/sys/conf.h
@@

Re: FreeBSD 9: Fn+* keyboard combinations aren't working anymore.

alq_open_flags() panics in _mtx_lock_flags()

code in GEOM thread could not use vnode API (Was: alq_open_flags() panics in _mtx_lock_flags())

st_dev and st_ino for pipes

4 matches

Site Navigation

Mail list logo

Footer information