Re: [PATCH V2] sparse: Allow override of sizeof(bool) warning
On Wed, Feb 26, 2014 at 08:19:57PM -0800, H. Peter Anvin wrote: > On 02/26/2014 08:00 PM, Ben Pfaff wrote: > > > > The commit *relaxed* sparse behavior: because previously sizeof(bool) > > was an error. I'm not in favor of any diagnostic at all for > > sizeof(bool), but my recollection is that a sparse maintainer wanted it > > to yield one. > > Still not clear as to why. The discussion is here: http://comments.gmane.org/gmane.comp.parsers.sparse/2462 Quoting from that discussion, the core of Christopher Li's argument was this: > On Mon, May 9, 2011 at 1:02 PM, Ben Pfaff nicira.com> wrote: > > Thank you for applying my patch. It does work for me, in the sense > > that I get a warning instead of an error now, but I'm not so happy to > > get any diagnostic at all. Is there some reason why sizeof(_Bool) > > warrants a warning when, say, sizeof(long) does not? After all, both > > sizes are implementation defined. > Because sizeof(_Bool) is a little bit special compare to sizeof(long). > In the case of long, all sizeof(long) * 8 bits are use in the actual value. > But for the _Bool, only the 1 bit is used in the 8 bits size. In other words, > the _Bool has a special case of the actual bit size is not a multiple of 8. > Sparse has two hats, it is a C compiler front end, and more often it is > used in the Linux kernel source sanitize checking. Depending on the sizeof > _Bool sounds a little bit suspicious in the kernel. I would love to the heard > your actual usage case of the sizeof(_Bool). Why do you care about this > warning? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] sparse: Allow override of sizeof(bool) warning
On Wed, Feb 26, 2014 at 07:38:46PM -0800, Joe Perches wrote: > (adding Ben Pfaff and Christopher Li) > > On Wed, 2014-02-26 at 19:29 -0800, H. Peter Anvin wrote: > > On 02/26/2014 06:58 PM, Josh Triplett wrote: > > > On Wed, Feb 26, 2014 at 06:53:14PM -0800, Joe Perches wrote: > > >> Allow an override to emit or not the sizeof(bool) warning > > >> Add a description to the manpage. > > >> > > >> Signed-off-by: Joe Perches > > > > > > Reviewed-by: Josh Triplett > > > > > > > I have to admit that this particular warning is a bit odd to me. I'm > > wondering what kind of bugs it was intended to catch. > > > > In particular, things that incorrectly assumes the size of bool to be > > anything in particular would seem unlikely to actually use sizeof(). > > Dunno, the commit log for the commit that added it doesn't quite > match the code and is seemingly unaware that the c99 spec doesn't > specify sizeof(bool). The commit *relaxed* sparse behavior: because previously sizeof(bool) was an error. I'm not in favor of any diagnostic at all for sizeof(bool), but my recollection is that a sparse maintainer wanted it to yield one. I don't care about the particular result for sizeof(bool) as long as it matches the ABI. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] sparse: Allow override of sizeof(bool) warning
On Wed, Feb 26, 2014 at 07:38:46PM -0800, Joe Perches wrote: (adding Ben Pfaff and Christopher Li) On Wed, 2014-02-26 at 19:29 -0800, H. Peter Anvin wrote: On 02/26/2014 06:58 PM, Josh Triplett wrote: On Wed, Feb 26, 2014 at 06:53:14PM -0800, Joe Perches wrote: Allow an override to emit or not the sizeof(bool) warning Add a description to the manpage. Signed-off-by: Joe Perches j...@perches.com Reviewed-by: Josh Triplett j...@joshtriplett.org I have to admit that this particular warning is a bit odd to me. I'm wondering what kind of bugs it was intended to catch. In particular, things that incorrectly assumes the size of bool to be anything in particular would seem unlikely to actually use sizeof(). Dunno, the commit log for the commit that added it doesn't quite match the code and is seemingly unaware that the c99 spec doesn't specify sizeof(bool). The commit *relaxed* sparse behavior: because previously sizeof(bool) was an error. I'm not in favor of any diagnostic at all for sizeof(bool), but my recollection is that a sparse maintainer wanted it to yield one. I don't care about the particular result for sizeof(bool) as long as it matches the ABI. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] sparse: Allow override of sizeof(bool) warning
On Wed, Feb 26, 2014 at 08:19:57PM -0800, H. Peter Anvin wrote: On 02/26/2014 08:00 PM, Ben Pfaff wrote: The commit *relaxed* sparse behavior: because previously sizeof(bool) was an error. I'm not in favor of any diagnostic at all for sizeof(bool), but my recollection is that a sparse maintainer wanted it to yield one. Still not clear as to why. The discussion is here: http://comments.gmane.org/gmane.comp.parsers.sparse/2462 Quoting from that discussion, the core of Christopher Li's argument was this: On Mon, May 9, 2011 at 1:02 PM, Ben Pfaff blp at nicira.com wrote: Thank you for applying my patch. It does work for me, in the sense that I get a warning instead of an error now, but I'm not so happy to get any diagnostic at all. Is there some reason why sizeof(_Bool) warrants a warning when, say, sizeof(long) does not? After all, both sizes are implementation defined. Because sizeof(_Bool) is a little bit special compare to sizeof(long). In the case of long, all sizeof(long) * 8 bits are use in the actual value. But for the _Bool, only the 1 bit is used in the 8 bits size. In other words, the _Bool has a special case of the actual bit size is not a multiple of 8. Sparse has two hats, it is a C compiler front end, and more often it is used in the Linux kernel source sanitize checking. Depending on the sizeof _Bool sounds a little bit suspicious in the kernel. I would love to the heard your actual usage case of the sizeof(_Bool). Why do you care about this warning? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No sysfs directory for openvswitch module when built-in
On Tue, Feb 05, 2013 at 06:49:45PM +0800, Cong Wang wrote: > On Tue, Feb 5, 2013 at 2:08 PM, Ben Pfaff wrote: > > Stephen Hemminger writes: > > > >> On Tue, 29 Jan 2013 22:15:18 +0800 > >> Cong Wang wrote: > >> > >>> Hello, Rusty, Jesse, > >>> > >>> I met an interesting problem when I compile openvswitch module as a > >>> built-in (actually I compile ALL kernel modules as built-in), there is > >>> no /sys/module/openvswitch/ directory created by the kernel in this > >>> case. > >>> > >>> What's worse, the user-space init script thinks openvswitch module is > >>> not loaded by checking the exist of this directory, therefore refuses > >>> to start. > >> > >> Shouldn't the OVS init script be testing for some other API. > > > > I agree that's a bug in the OVS init script. I will fix it. > > Thanks for taking care of it, Ben! I posted a patch to ovs-dev for review: http://openvswitch.org/pipermail/dev/2013-February/025128.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No sysfs directory for openvswitch module when built-in
On Tue, Feb 05, 2013 at 06:49:45PM +0800, Cong Wang wrote: On Tue, Feb 5, 2013 at 2:08 PM, Ben Pfaff b...@cs.stanford.edu wrote: Stephen Hemminger step...@networkplumber.org writes: On Tue, 29 Jan 2013 22:15:18 +0800 Cong Wang xiyou.wangc...@gmail.com wrote: Hello, Rusty, Jesse, I met an interesting problem when I compile openvswitch module as a built-in (actually I compile ALL kernel modules as built-in), there is no /sys/module/openvswitch/ directory created by the kernel in this case. What's worse, the user-space init script thinks openvswitch module is not loaded by checking the exist of this directory, therefore refuses to start. Shouldn't the OVS init script be testing for some other API. I agree that's a bug in the OVS init script. I will fix it. Thanks for taking care of it, Ben! I posted a patch to ovs-dev for review: http://openvswitch.org/pipermail/dev/2013-February/025128.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No sysfs directory for openvswitch module when built-in
Stephen Hemminger writes: > On Tue, 29 Jan 2013 22:15:18 +0800 > Cong Wang wrote: > >> Hello, Rusty, Jesse, >> >> I met an interesting problem when I compile openvswitch module as a >> built-in (actually I compile ALL kernel modules as built-in), there is >> no /sys/module/openvswitch/ directory created by the kernel in this >> case. >> >> What's worse, the user-space init script thinks openvswitch module is >> not loaded by checking the exist of this directory, therefore refuses >> to start. > > Shouldn't the OVS init script be testing for some other API. I agree that's a bug in the OVS init script. I will fix it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No sysfs directory for openvswitch module when built-in
Stephen Hemminger step...@networkplumber.org writes: On Tue, 29 Jan 2013 22:15:18 +0800 Cong Wang xiyou.wangc...@gmail.com wrote: Hello, Rusty, Jesse, I met an interesting problem when I compile openvswitch module as a built-in (actually I compile ALL kernel modules as built-in), there is no /sys/module/openvswitch/ directory created by the kernel in this case. What's worse, the user-space init script thinks openvswitch module is not loaded by checking the exist of this directory, therefore refuses to start. Shouldn't the OVS init script be testing for some other API. I agree that's a bug in the OVS init script. I will fix it. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] net: socket bind to file descriptor introduced
Stanislav Kinsbursky writes: > This system call is especially required for UNIX sockets, which has name > lenght limitation. The worst of the name length limitations can be worked around by opening the directory where the socket is to go as a file descriptor, then using /proc/self/fd// as the name of the socket. This technique also works with "connect" and in other contexts where a struct sockaddr is needed. At first glance, it looks like your patches only help with "bind". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] net: socket bind to file descriptor introduced
Stanislav Kinsbursky skinsbur...@parallels.com writes: This system call is especially required for UNIX sockets, which has name lenght limitation. The worst of the name length limitations can be worked around by opening the directory where the socket is to go as a file descriptor, then using /proc/self/fd/fd/basename as the name of the socket. This technique also works with connect and in other contexts where a struct sockaddr is needed. At first glance, it looks like your patches only help with bind. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New Address Family: Inter Process Networking (IPN)
"Chris Friesen" <[EMAIL PROTECTED]> writes: > David Miller wrote: >> From: "Chris Friesen" <[EMAIL PROTECTED]> >>> One problem we ran into was that there are only 32 multicast groups >>> per netlink protocol family. >> I'm pretty sure we've removed this limitation. > As of 2.6.23 nl_groups is a 32-bit bitmask with one bit per > group. Use setsockopt(fd, SOL_NETLINK, NETLINK_ADD_MEMBERSHIP, ...) to join an arbitrary Netlink multicast group. -- "A computer is a state machine. Threads are for people who cant [sic] program state machines." --Alan Cox -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New Address Family: Inter Process Networking (IPN)
Chris Friesen [EMAIL PROTECTED] writes: David Miller wrote: From: Chris Friesen [EMAIL PROTECTED] One problem we ran into was that there are only 32 multicast groups per netlink protocol family. I'm pretty sure we've removed this limitation. As of 2.6.23 nl_groups is a 32-bit bitmask with one bit per group. Use setsockopt(fd, SOL_NETLINK, NETLINK_ADD_MEMBERSHIP, ...) to join an arbitrary Netlink multicast group. -- A computer is a state machine. Threads are for people who cant [sic] program state machines. --Alan Cox -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Request for Linux Kernel Mailing List archives
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > For example, if a message had: > > Message-ID: <[EMAIL PROTECTED]> > > ... and I could just generate a URL: > > http://linux-kernel.example.com/msgid/[EMAIL PROTECTED] gmane can do that: http://mid.gmane.org/[EMAIL PROTECTED] > (Extra points if all the vger lists are available, not just LKML.) gmane has thousands of free software mailing lists. I don't know whether it has all of the vger lists. -- Ben Pfaff http://benpfaff.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Request for Linux Kernel Mailing List archives
H. Peter Anvin [EMAIL PROTECTED] writes: For example, if a message had: Message-ID: [EMAIL PROTECTED] ... and I could just generate a URL: http://linux-kernel.example.com/msgid/[EMAIL PROTECTED] gmane can do that: http://mid.gmane.org/[EMAIL PROTECTED] (Extra points if all the vger lists are available, not just LKML.) gmane has thousands of free software mailing lists. I don't know whether it has all of the vger lists. -- Ben Pfaff http://benpfaff.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 1/4] SoC base drivers: SoC helper API
Paul Sokolovsky <[EMAIL PROTECTED]> writes: > soc-core: Helper API for SoC base drivers to register/unregister > subdevices. It would be nice if the code said at some point what SoC stands for. It makes me think of Silicon on Conductor, but I don't think that's right. -- Ben Pfaff http://benpfaff.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 1/4] SoC base drivers: SoC helper API
Paul Sokolovsky [EMAIL PROTECTED] writes: soc-core: Helper API for SoC base drivers to register/unregister subdevices. It would be nice if the code said at some point what SoC stands for. It makes me think of Silicon on Conductor, but I don't think that's right. -- Ben Pfaff http://benpfaff.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slow module build--what am I doing wrong?
Ben Pfaff <[EMAIL PROTECTED]> writes: > When I modify a source file or two that belong to a particular > module, and then rebuild just that module with "make > dir1/dir/module.ko" (e.g.), the build system spends a couple of > minutes grinding away on "MODPOST" operations. Am I doing > something wrong? Is there a way to avoid this? It slows down my > build-and-test cycle quite a bit. I was privately emailed a suggestion to use "make M=dir1/dir" instead of "make dir1/dir/module.ko". It helps a great deal. -- Ben Pfaff [EMAIL PROTECTED] http://benpfaff.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
slow module build--what am I doing wrong?
When I modify a source file or two that belong to a particular module, and then rebuild just that module with "make dir1/dir/module.ko" (e.g.), the build system spends a couple of minutes grinding away on "MODPOST" operations. Am I doing something wrong? Is there a way to avoid this? It slows down my build-and-test cycle quite a bit. Thanks! -- Ben Pfaff [EMAIL PROTECTED] http://benpfaff.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
slow module build--what am I doing wrong?
When I modify a source file or two that belong to a particular module, and then rebuild just that module with make dir1/dir/module.ko (e.g.), the build system spends a couple of minutes grinding away on MODPOST operations. Am I doing something wrong? Is there a way to avoid this? It slows down my build-and-test cycle quite a bit. Thanks! -- Ben Pfaff [EMAIL PROTECTED] http://benpfaff.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slow module build--what am I doing wrong?
Ben Pfaff [EMAIL PROTECTED] writes: When I modify a source file or two that belong to a particular module, and then rebuild just that module with make dir1/dir/module.ko (e.g.), the build system spends a couple of minutes grinding away on MODPOST operations. Am I doing something wrong? Is there a way to avoid this? It slows down my build-and-test cycle quite a bit. I was privately emailed a suggestion to use make M=dir1/dir instead of make dir1/dir/module.ko. It helps a great deal. -- Ben Pfaff [EMAIL PROTECTED] http://benpfaff.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Entropy Pool Contents
[EMAIL PROTECTED] (David Wagner) writes: > Well, if you want to talk about really high-value keys like the scenarios > you mention, you probably shouldn't be using /dev/random, either; you > should be using a hardware security module with a built-in FIPS certified > hardware random number source. Is there such a thing? "Annex C: Approved Random Number Generators for FIPS PUB 140-2, Security Requirements for Cryptographic Modules", or at least the version of it I was able to find with Google in a few seconds, simply states: There are no FIPS Approved nondeterministic random number generators. -- "Welcome to the Slippery Slope. Here is your handbasket. Say, can you work 70 hours this week?" --Ron Mansolino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Entropy Pool Contents
[EMAIL PROTECTED] (David Wagner) writes: Well, if you want to talk about really high-value keys like the scenarios you mention, you probably shouldn't be using /dev/random, either; you should be using a hardware security module with a built-in FIPS certified hardware random number source. Is there such a thing? Annex C: Approved Random Number Generators for FIPS PUB 140-2, Security Requirements for Cryptographic Modules, or at least the version of it I was able to find with Google in a few seconds, simply states: There are no FIPS Approved nondeterministic random number generators. -- Welcome to the Slippery Slope. Here is your handbasket. Say, can you work 70 hours this week? --Ron Mansolino - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] writes not always synchronous on JFS with O_SYNC?
Dave Kleikamp <[EMAIL PROTECTED]> writes: > This patch to jfs_fsck fixes the problem. It wasn't really an issue > with O_SYNC at all, although I believe there are O_SYNC issues that need > to be resolved. The data itself should be sync'd correctly, as > generic_file_write checks for the O_SYNC flag. The missing piece in jfs > is that metadata changes to the inode may not always be making it to the > disk when they should. Wow, that's an amazingly fast fix. Thanks! If I have time today, I'll re-run the checker after applying your patch. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] writes not always synchronous on JFS with O_SYNC?
Dave Kleikamp [EMAIL PROTECTED] writes: This patch to jfs_fsck fixes the problem. It wasn't really an issue with O_SYNC at all, although I believe there are O_SYNC issues that need to be resolved. The data itself should be sync'd correctly, as generic_file_write checks for the O_SYNC flag. The missing piece in jfs is that metadata changes to the inode may not always be making it to the disk when they should. Wow, that's an amazingly fast fix. Thanks! If I have time today, I'll re-run the checker after applying your patch. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[CHECKER] writes not always synchronous on JFS with O_SYNC?
Hi. We've been running some tests on JFS and other file systems
and believe we've found an issue whereby O_SYNC does not always
cause data to be committed synchronously. On Linux 2.6.11, we
found that the program appended below causes
/mnt/sbd0/0006/0010/0029/0033 to contain all zeros, despite the
use of O_SYNC on the write calls and the fsyncs on the
directories. It seems to be pretty sensitive to the existence of
the rmdir calls: if I omit one of them, the data does get
written.
Note that /dev/sbd0 is essentially a ramdisk that we've developed
for testing this kind of thing: it allows a snapshot of a disk's
momentary contents to be copied out, so that we don't have to do
a reboot.
Can you confirm this?
Thanks,
Ben.
--
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define CHECK(ret) if(ret < 0) {perror(0); assert(0);}
#define MAX_SIG_WRITE (20)
typedef unsigned int signature_t;
typedef struct write_s {
off_t off;
size_t len;
char buf[MAX_SIG_WRITE * sizeof(signature_t)];
off_t size; // file size;
signature_t sig; // file sig;
} write_t;
write_t writes[] = {
{0, 4,{-23, -69, 101, -119, }, 4, 228307655},
{1023, 8,{63, -3, -104, -45, 4, -110, -59, 88, }, 1031, 4168021214},
{4093, 12,{98, 11, -106, 98, 79, -107, -88, 102, 1, 100, -6, 85, },
4105, 2386671457},
{32755, 20,{-83, 49, -128, -96, 90, -7, 13, 69, 62, 127, -99, 125, 7,
53, -70, 62, -113, 63, 72, -104, }, 32775, 2170096179},
{1073741793, 40,{-69, -57, -42, 80, -70, 54, 127, 17, -113, 34, 72, 31,
27, 5, -28, -18, -73, -79, -1, -52, -106, 8, 86, 100, 72, 28, 98, -27, -52,
-104, -65, 3, 56, 51, 68, -66, 65, -87, 62, 51, }, 1073741833, 255668987},
};
int systemf(const char *fmt, ...)
{
static char cmd[1024];
va_list ap;
va_start(ap, fmt);
vsprintf(cmd, fmt, ap);
va_end(ap);
fprintf(stderr, "running cmd \"%s\"\n", cmd);
return system(cmd);
}
int test_write(const char *pathname, unsigned i)
{
int fd = open(pathname, O_WRONLY | O_SYNC);
CHECK(fd);
int ret = pwrite(fd, writes[i].buf,
writes[i].len, writes[i].off);
CHECK(ret);
ret = close(fd);
CHECK(ret);
return ret;
}
void test_fsync(const char* pathname)
{
int fd, ret;
fd = open(pathname, 0);
CHECK(fd);
ret = fsync(fd);
CHECK(ret);
ret = close(fd);
CHECK(ret);
}
void test_creat(const char* pathname, mode_t m)
{
int fd, ret;
fd = creat(pathname, m);
CHECK(fd);
ret = close(fd);
CHECK(ret);
}
int main(int argc, char *argv[])
{
int ret, fd;
systemf("umount /dev/sbd0");
systemf("sbin/mkfs.jfs -q /dev/sbd0 4096");
systemf("sbin/fsck.jfs -a -p /dev/sbd0");
systemf("mount -t jfs /dev/sbd0 /mnt/sbd0 ");
systemf("umount /dev/sbd0");
systemf("mount -t jfs /dev/sbd0 /mnt/sbd0 ");
ret = mkdir("/mnt/sbd0/0006", 511);
CHECK(ret);
ret = mkdir("/mnt/sbd0/0006/0010", 511);
CHECK(ret);
ret = mkdir("/mnt/sbd0/0014", 511);
CHECK(ret);
ret = mkdir("/mnt/sbd0/0015", 511);
CHECK(ret);
ret = mkdir("/mnt/sbd0/0015/0016", 511);
CHECK(ret);
ret = mkdir("/mnt/sbd0/0006/0010/0017", 511);
CHECK(ret);
ret = rmdir("/mnt/sbd0/0015/0016");
CHECK(ret);
ret = mkdir("/mnt/sbd0/0006/0010/0017/0021", 511);
CHECK(ret);
ret = rmdir("/mnt/sbd0/0014");
CHECK(ret);
ret = rmdir("/mnt/sbd0/0015");
CHECK(ret);
ret = test_creat("/mnt/sbd0/0006/0028", 511);
CHECK(ret);
ret = test_write("/mnt/sbd0/0006/0028", 0);
CHECK(ret);
ret = mkdir("/mnt/sbd0/0006/0010/0029", 511);
CHECK(ret);
ret = test_creat("/mnt/sbd0/0006/0010/0029/0033", 511);
CHECK(ret);
ret = test_write("/mnt/sbd0/0006/0010/0029/0033", 0);
CHECK(ret);
ret = test_fsync("/mnt/sbd0/0006/0010/0029");
CHECK(ret);
ret = test_fsync("/mnt/sbd0/0006/0010");
CHECK(ret);
ret = test_fsync("/mnt/sbd0/0006");
CHECK(ret);
ret = test_fsync("/mnt/sbd0");
CHECK(ret);
#if 0
{
#include "../sbd/sbd.h"
int sbd_fd = open("/dev/sbd0", O_RDONLY);
ret = ioctl(sbd_fd, SBD_COPY_DISK, 1);
CHECK(ret);
close(sbd_fd);
[CHECKER] writes not always synchronous on JFS with O_SYNC?
Hi. We've been running some tests on JFS and other file systems
and believe we've found an issue whereby O_SYNC does not always
cause data to be committed synchronously. On Linux 2.6.11, we
found that the program appended below causes
/mnt/sbd0/0006/0010/0029/0033 to contain all zeros, despite the
use of O_SYNC on the write calls and the fsyncs on the
directories. It seems to be pretty sensitive to the existence of
the rmdir calls: if I omit one of them, the data does get
written.
Note that /dev/sbd0 is essentially a ramdisk that we've developed
for testing this kind of thing: it allows a snapshot of a disk's
momentary contents to be copied out, so that we don't have to do
a reboot.
Can you confirm this?
Thanks,
Ben.
--
#define _GNU_SOURCE
#include sys/types.h
#include sys/ioctl.h
#include sys/stat.h
#include fcntl.h
#include stdio.h
#include stdlib.h
#include stdarg.h
#include assert.h
#include unistd.h
#define CHECK(ret) if(ret 0) {perror(0); assert(0);}
#define MAX_SIG_WRITE (20)
typedef unsigned int signature_t;
typedef struct write_s {
off_t off;
size_t len;
char buf[MAX_SIG_WRITE * sizeof(signature_t)];
off_t size; // file size;
signature_t sig; // file sig;
} write_t;
write_t writes[] = {
{0, 4,{-23, -69, 101, -119, }, 4, 228307655},
{1023, 8,{63, -3, -104, -45, 4, -110, -59, 88, }, 1031, 4168021214},
{4093, 12,{98, 11, -106, 98, 79, -107, -88, 102, 1, 100, -6, 85, },
4105, 2386671457},
{32755, 20,{-83, 49, -128, -96, 90, -7, 13, 69, 62, 127, -99, 125, 7,
53, -70, 62, -113, 63, 72, -104, }, 32775, 2170096179},
{1073741793, 40,{-69, -57, -42, 80, -70, 54, 127, 17, -113, 34, 72, 31,
27, 5, -28, -18, -73, -79, -1, -52, -106, 8, 86, 100, 72, 28, 98, -27, -52,
-104, -65, 3, 56, 51, 68, -66, 65, -87, 62, 51, }, 1073741833, 255668987},
};
int systemf(const char *fmt, ...)
{
static char cmd[1024];
va_list ap;
va_start(ap, fmt);
vsprintf(cmd, fmt, ap);
va_end(ap);
fprintf(stderr, running cmd \%s\\n, cmd);
return system(cmd);
}
int test_write(const char *pathname, unsigned i)
{
int fd = open(pathname, O_WRONLY | O_SYNC);
CHECK(fd);
int ret = pwrite(fd, writes[i].buf,
writes[i].len, writes[i].off);
CHECK(ret);
ret = close(fd);
CHECK(ret);
return ret;
}
void test_fsync(const char* pathname)
{
int fd, ret;
fd = open(pathname, 0);
CHECK(fd);
ret = fsync(fd);
CHECK(ret);
ret = close(fd);
CHECK(ret);
}
void test_creat(const char* pathname, mode_t m)
{
int fd, ret;
fd = creat(pathname, m);
CHECK(fd);
ret = close(fd);
CHECK(ret);
}
int main(int argc, char *argv[])
{
int ret, fd;
systemf(umount /dev/sbd0);
systemf(sbin/mkfs.jfs -q /dev/sbd0 4096);
systemf(sbin/fsck.jfs -a -p /dev/sbd0);
systemf(mount -t jfs /dev/sbd0 /mnt/sbd0 );
systemf(umount /dev/sbd0);
systemf(mount -t jfs /dev/sbd0 /mnt/sbd0 );
ret = mkdir(/mnt/sbd0/0006, 511);
CHECK(ret);
ret = mkdir(/mnt/sbd0/0006/0010, 511);
CHECK(ret);
ret = mkdir(/mnt/sbd0/0014, 511);
CHECK(ret);
ret = mkdir(/mnt/sbd0/0015, 511);
CHECK(ret);
ret = mkdir(/mnt/sbd0/0015/0016, 511);
CHECK(ret);
ret = mkdir(/mnt/sbd0/0006/0010/0017, 511);
CHECK(ret);
ret = rmdir(/mnt/sbd0/0015/0016);
CHECK(ret);
ret = mkdir(/mnt/sbd0/0006/0010/0017/0021, 511);
CHECK(ret);
ret = rmdir(/mnt/sbd0/0014);
CHECK(ret);
ret = rmdir(/mnt/sbd0/0015);
CHECK(ret);
ret = test_creat(/mnt/sbd0/0006/0028, 511);
CHECK(ret);
ret = test_write(/mnt/sbd0/0006/0028, 0);
CHECK(ret);
ret = mkdir(/mnt/sbd0/0006/0010/0029, 511);
CHECK(ret);
ret = test_creat(/mnt/sbd0/0006/0010/0029/0033, 511);
CHECK(ret);
ret = test_write(/mnt/sbd0/0006/0010/0029/0033, 0);
CHECK(ret);
ret = test_fsync(/mnt/sbd0/0006/0010/0029);
CHECK(ret);
ret = test_fsync(/mnt/sbd0/0006/0010);
CHECK(ret);
ret = test_fsync(/mnt/sbd0/0006);
CHECK(ret);
ret = test_fsync(/mnt/sbd0);
CHECK(ret);
#if 0
{
#include ../sbd/sbd.h
int sbd_fd = open(/dev/sbd0, O_RDONLY);
ret = ioctl(sbd_fd, SBD_COPY_DISK, 1);
CHECK(ret);
close(sbd_fd);
}
#else
systemf(reboot -f -n);
#endif
return 0;
}
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
[CHECKER] ext3 bug in ftruncate() with O_SYNC?
Hi. We're doing some checking on Linux file systems and found
what appears to be a bug in the Linux 2.6.11 implementation of
ext3: when ftruncate shrinks a file, using a file descriptor
opened with O_SYNC, the file size is not updated synchronously.
I've appended a test program that illustrates the problem. After
this program runs, the file system shows a file with length 1031,
not 4 as would be expected if the ftruncate completed
synchronously. (If I insert an fsync before closing the file,
the file length is correct.)
Does this look like a bug to you guys?
Thanks,
Ben.
--
#include
#include
#include
#include
#include
#include
#include
#define CHECK(ret) if(ret < 0) {perror(0); assert(0);}
int systemf(const char *fmt, ...)
{
static char cmd[1024];
va_list ap;
va_start(ap, fmt);
vsprintf(cmd, fmt, ap);
va_end(ap);
fprintf(stderr, "running cmd \"%s\"\n", cmd);
return system(cmd);
}
main(int argc, char *argv[])
{
int ret, fd;
systemf("umount /dev/sbd0");
systemf("sbin/mkfs.ext3 -F -j -b 1024 /dev/sbd0 2048");
systemf("sbin/e2fsck.shared -y /dev/sbd0");
systemf("mount -t ext3 /dev/sbd0 /mnt/sbd0 -o commit=65535");
systemf("umount /dev/sbd0");
systemf("mount -t ext3 /dev/sbd0 /mnt/sbd0 -o commit=65535");
fd = open("/mnt/sbd0/0001", O_CREAT | O_RDWR | O_SYNC, 0700);
CHECK(fd);
ret = write(fd, "foobar", 6);
CHECK(ret);
ret = ftruncate(fd, 1031);
CHECK(ret);
ret = pwrite(fd, "bazzle", 6, 1031 - 6);
CHECK(ret);
ret = ftruncate(fd, 4);
CHECK(ret);
ret = close(fd);
CHECK(ret);
#if 0
{
#include "../sbd/sbd.h"
int sbd_fd = open("/dev/sbd0", O_RDONLY);
ret = ioctl(sbd_fd, SBD_COPY_DISK, 1);
CHECK(ret);
close(sbd_fd);
}
#else
systemf("reboot -f -n");
#endif
return 0;
}
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[CHECKER] ext3 bug in ftruncate() with O_SYNC?
Hi. We're doing some checking on Linux file systems and found
what appears to be a bug in the Linux 2.6.11 implementation of
ext3: when ftruncate shrinks a file, using a file descriptor
opened with O_SYNC, the file size is not updated synchronously.
I've appended a test program that illustrates the problem. After
this program runs, the file system shows a file with length 1031,
not 4 as would be expected if the ftruncate completed
synchronously. (If I insert an fsync before closing the file,
the file length is correct.)
Does this look like a bug to you guys?
Thanks,
Ben.
--
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include stdio.h
#include stdlib.h
#include stdarg.h
#include assert.h
#define CHECK(ret) if(ret 0) {perror(0); assert(0);}
int systemf(const char *fmt, ...)
{
static char cmd[1024];
va_list ap;
va_start(ap, fmt);
vsprintf(cmd, fmt, ap);
va_end(ap);
fprintf(stderr, running cmd \%s\\n, cmd);
return system(cmd);
}
main(int argc, char *argv[])
{
int ret, fd;
systemf(umount /dev/sbd0);
systemf(sbin/mkfs.ext3 -F -j -b 1024 /dev/sbd0 2048);
systemf(sbin/e2fsck.shared -y /dev/sbd0);
systemf(mount -t ext3 /dev/sbd0 /mnt/sbd0 -o commit=65535);
systemf(umount /dev/sbd0);
systemf(mount -t ext3 /dev/sbd0 /mnt/sbd0 -o commit=65535);
fd = open(/mnt/sbd0/0001, O_CREAT | O_RDWR | O_SYNC, 0700);
CHECK(fd);
ret = write(fd, foobar, 6);
CHECK(ret);
ret = ftruncate(fd, 1031);
CHECK(ret);
ret = pwrite(fd, bazzle, 6, 1031 - 6);
CHECK(ret);
ret = ftruncate(fd, 4);
CHECK(ret);
ret = close(fd);
CHECK(ret);
#if 0
{
#include ../sbd/sbd.h
int sbd_fd = open(/dev/sbd0, O_RDONLY);
ret = ioctl(sbd_fd, SBD_COPY_DISK, 1);
CHECK(ret);
close(sbd_fd);
}
#else
systemf(reboot -f -n);
#endif
return 0;
}
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
Dan Kegel <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > > > On an unrelated note: > > > > I noticed the quote below in your message. Is this a true quote or just a > > joke going around? I have tried believing it is just a joke but I am > > scared it is not. > > > > >-- > > > "A Computer is a state machine. > > > Threads are for people who can't program state machines." > > > - Alan Cox > > Alan, did you really say that, or are people taking your name in vain? Actually he left out the apostrophe and didn't capitalize `computer'. See, e.g., http://www.google.com/search?q=cache:myb1i-ixJ0k:web.gnu.walfield.org/mail-archive/linux-kernel/2000-January/3533.html -- "...dans ce pays-ci il est bon de tuer de temps en temps un amiral pour encourager les autres." --Voltaire, _Candide_ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
Dan Kegel [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: On an unrelated note: I noticed the quote below in your message. Is this a true quote or just a joke going around? I have tried believing it is just a joke but I am scared it is not. -- A Computer is a state machine. Threads are for people who can't program state machines. - Alan Cox Alan, did you really say that, or are people taking your name in vain? Actually he left out the apostrophe and didn't capitalize `computer'. See, e.g., http://www.google.com/search?q=cache:myb1i-ixJ0k:web.gnu.walfield.org/mail-archive/linux-kernel/2000-January/3533.html -- ...dans ce pays-ci il est bon de tuer de temps en temps un amiral pour encourager les autres. --Voltaire, _Candide_ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ess maestro, support for hardware volume control
Alan Cox <[EMAIL PROTECTED]> writes: > > this patch applies to (at least) 2.4.3 up to and including 2.4.6-pre2. > > It enables the hardware volume control feature of the maestro. > > it doesnt apply to the current version of the maestro driver (2.4.5-ac) > however. I think it is clashing with the docking station support Yeah, it does--I included support for the hwv control in the docking patch. I used a different technique though because I couldn't get the technique used by Lukas's patch to work properly for me. I now have a patch that will output the hwv buttons pressed (up, down, mute) to a new dynamically allocated misc device as letters u, d, m, instead of directly modifying the mixer. Anyone want that? It's more flexible than either the patch that's currently in -ac or Lukas's patch, but you need a little userspace daemon for it to do anything useful. BTW, what is the officially approved way to open a device on a dynamic misc minor? Reading /proc/misc for the minor number, then mknod'ing a device and opening it seems to me to have a nasty race condition, am I missing something here? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ess maestro, support for hardware volume control
Alan Cox [EMAIL PROTECTED] writes: this patch applies to (at least) 2.4.3 up to and including 2.4.6-pre2. It enables the hardware volume control feature of the maestro. it doesnt apply to the current version of the maestro driver (2.4.5-ac) however. I think it is clashing with the docking station support Yeah, it does--I included support for the hwv control in the docking patch. I used a different technique though because I couldn't get the technique used by Lukas's patch to work properly for me. I now have a patch that will output the hwv buttons pressed (up, down, mute) to a new dynamically allocated misc device as letters u, d, m, instead of directly modifying the mixer. Anyone want that? It's more flexible than either the patch that's currently in -ac or Lukas's patch, but you need a little userspace daemon for it to do anything useful. BTW, what is the officially approved way to open a device on a dynamic misc minor? Reading /proc/misc for the minor number, then mknod'ing a device and opening it seems to me to have a nasty race condition, am I missing something here? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] Bug-fix for Maestro dock/hardware volume control patch
This patch, to be applied on top of the patch sent to linux-kernel last week, fixes a bug which caused the driver to crash on insertion if a hardware volume button had been pushed. --- linux-2.4.4-ac12.vanilla/drivers/sound/maestro.cMon May 21 19:18:49 2001 +++ linux-2.4.5pre1/drivers/sound/maestro.c Mon May 21 18:27:39 2001 @@ -3226,7 +3359,7 @@ outw(w, iobase+0x18); w=inw(iobase+0x18); - w|=1<<6;/* Hardware volume control interrupt on. */ + w&=~(1<<6); /* Hardware volume control interrupt off... for now. */ outw(w, iobase+0x18); w=inw(iobase+0x18); @@ -3549,6 +3680,15 @@ kfree(card); return 0; } + + /* Turn on hardware volume control interrupt. + This has to come after we grab the IRQ above, + or a crash will result on installation if a button has been pressed, + because in that case we'll get an immediate interrupt. */ + n = inw(iobase+0x18); + n|=(1<<6); + outw(n, iobase+0x18); + /* now go to sleep 'till something interesting happens */ maestro_power(card,ACPI_D2); -- Ben Pfaff <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> MSU Student - Debian GNU/Linux Maintainer - GNU Developer Personal webpage: http://www.msu.edu/user/pfaffben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] Bug-fix for Maestro dock/hardware volume control patch
This patch, to be applied on top of the patch sent to linux-kernel last week, fixes a bug which caused the driver to crash on insertion if a hardware volume button had been pushed. --- linux-2.4.4-ac12.vanilla/drivers/sound/maestro.cMon May 21 19:18:49 2001 +++ linux-2.4.5pre1/drivers/sound/maestro.c Mon May 21 18:27:39 2001 @@ -3226,7 +3359,7 @@ outw(w, iobase+0x18); w=inw(iobase+0x18); - w|=16;/* Hardware volume control interrupt on. */ + w=~(16); /* Hardware volume control interrupt off... for now. */ outw(w, iobase+0x18); w=inw(iobase+0x18); @@ -3549,6 +3680,15 @@ kfree(card); return 0; } + + /* Turn on hardware volume control interrupt. + This has to come after we grab the IRQ above, + or a crash will result on installation if a button has been pressed, + because in that case we'll get an immediate interrupt. */ + n = inw(iobase+0x18); + n|=(16); + outw(n, iobase+0x18); + /* now go to sleep 'till something interesting happens */ maestro_power(card,ACPI_D2); -- Ben Pfaff [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] MSU Student - Debian GNU/Linux Maintainer - GNU Developer Personal webpage: http://www.msu.edu/user/pfaffben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] ES978 docking support for Maestro 2E - advice requested
Hi. I have an Compaq Armada M700 laptop and an ArmadaStation II
laptop. The laptop has a Maestro 2E sound chipset in it, and the
docking station has the matching ES978 chip which controls
speakers and handles volume up/down/mute buttons on the side of
the docking station. The maestro.c driver in 2.4.4 doesn't have
support for these, so I wrote some code to do it. The following
patch adds support. It does the following:
* Turns on the docking station speakers and sets the
playback volume on them to the max. (Their volume is
still scaled based on the Maestro's master volume.)
* Adds basic support for the hardware volume control
buttons: the up button increases volume by 10%, the
down button decreases volume by 10%, the mute button
toggles the master volume on and off.
It doesn't do any of the following:
* Add the docking station volumes to the mixer--it just
hard-wires them to the max values. Should I do this?
* Make the buttons from the hardware volume control
available to software. Should I do this (I assume that
hard-wiring +/- 10% isn't really acceptable)? What's
the best way to do it--create a /dev/es978buttons and a
daemon, or what?
* Add any support for the recording features of the
docking station--just playback.
All comments appreciated.
--- /root/linux-2.4.4.clean/drivers/sound/maestro.c Fri Mar 2 14:12:11 2001
+++ linux-2.4.5pre1/drivers/sound/maestro.c Sun May 13 17:14:07 2001
@@ -115,6 +115,8 @@
* themselves, but we'll see.
*
* History
+ * (still kind of v0.14) May 13 2001 - Ben Pfaff <[EMAIL PROTECTED]>
+ * Add support for 978 docking and basic hardware volume control
* (still kind of v0.14) Nov 23 - Alan Cox <[EMAIL PROTECTED]>
* Add clocking= for people with seriously warped hardware
* (still v0.14) Nov 10 2000 - Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
@@ -189,7 +191,7 @@
* fix bob frequency
* endianness
* do smart things with ac97 2.0 bits.
- * docking and dual codecs and 978?
+ * dual codecs
* leave 54->61 open
*
* it also would be fun to have a mode that would not use pci dma at all
@@ -483,8 +485,12 @@
int bob_freq;
char dsps_open;
+
+ int dock_mute_vol;
};
+static void set_mixer(struct ess_card *card,unsigned int mixer, unsigned int val );
+
static unsigned
ld2(unsigned int x)
{
@@ -983,6 +989,17 @@
outw(inw(ioaddr+0x68) | 0x600, ioaddr + 0x68);
outw(0x0209, ioaddr + 0x60);
}
+
+ /* Turn on the 978 docking chip.
+ First frob the "master output enable" bit,
+ then set most of the playback volume control registers to max. */
+ outb(inb(ioaddr+0xc0)|(1<<5), ioaddr+0xc0);
+ outb(0xff, ioaddr+0xc3);
+ outb(0xff, ioaddr+0xc4);
+ outb(0xff, ioaddr+0xc6);
+ outb(0xff, ioaddr+0xc8);
+ outb(0x3f, ioaddr+0xcf);
+ outb(0x3f, ioaddr+0xd0);
}
/*
* Indirect register access. Not all registers are readable so we
@@ -1895,19 +1912,52 @@
outw(inw(c->iobase+4)&1, c->iobase+4);
/* M_printk("maestro int: %x\n",event);*/
-
if(event&(1<<6))
{
- /* XXX if we have a hw volume control int enable
- all the ints? doesn't make sense.. */
- event = inw(c->iobase+0x18);
- outb(0xFF, c->iobase+0x1A);
- }
- else
- {
- /* else ack 'em all, i imagine */
- outb(0xFF, c->iobase+0x1A);
+ int x;
+ enum {UP_EVT, DOWN_EVT, MUTE_EVT} vol_evt;
+ int volume;
+
+ /* Figure out which volume control button was pushed,
+ based on differences from the default register
+ values. */
+ x = inb(c->iobase+0x1c);
+ if (x&1) vol_evt = MUTE_EVT;
+ else if (((x>>1)&7) > 4) vol_evt = UP_EVT;
+ else vol_evt = DOWN_EVT;
+
+ /* Reset the volume control registers. */
+ outb(0x88, c->iobase+0x1c);
+ outb(0x88, c->iobase+0x1d);
+ outb(0x88, c->iobase+0x1e);
+ outb(0x88, c->iobase+0x1f);
+
+ /* Deal with the button press in a hammer-handed
+ manner by adjusting the master mixer volume. */
+ volume = c->mix.mixer_state[0] & 0xff;
+ if (vol_evt == UP_EVT) {
+ volume += 10;
+ if (volume > 100)
+ volume = 100;
+ }
+ else if (vol_evt == DOWN_EVT) {
+ volume -= 10;
+ if (volume &l
[patch] ES978 docking support for Maestro 2E - advice requested
Hi. I have an Compaq Armada M700 laptop and an ArmadaStation II
laptop. The laptop has a Maestro 2E sound chipset in it, and the
docking station has the matching ES978 chip which controls
speakers and handles volume up/down/mute buttons on the side of
the docking station. The maestro.c driver in 2.4.4 doesn't have
support for these, so I wrote some code to do it. The following
patch adds support. It does the following:
* Turns on the docking station speakers and sets the
playback volume on them to the max. (Their volume is
still scaled based on the Maestro's master volume.)
* Adds basic support for the hardware volume control
buttons: the up button increases volume by 10%, the
down button decreases volume by 10%, the mute button
toggles the master volume on and off.
It doesn't do any of the following:
* Add the docking station volumes to the mixer--it just
hard-wires them to the max values. Should I do this?
* Make the buttons from the hardware volume control
available to software. Should I do this (I assume that
hard-wiring +/- 10% isn't really acceptable)? What's
the best way to do it--create a /dev/es978buttons and a
daemon, or what?
* Add any support for the recording features of the
docking station--just playback.
All comments appreciated.
--- /root/linux-2.4.4.clean/drivers/sound/maestro.c Fri Mar 2 14:12:11 2001
+++ linux-2.4.5pre1/drivers/sound/maestro.c Sun May 13 17:14:07 2001
@@ -115,6 +115,8 @@
* themselves, but we'll see.
*
* History
+ * (still kind of v0.14) May 13 2001 - Ben Pfaff [EMAIL PROTECTED]
+ * Add support for 978 docking and basic hardware volume control
* (still kind of v0.14) Nov 23 - Alan Cox [EMAIL PROTECTED]
* Add clocking= for people with seriously warped hardware
* (still v0.14) Nov 10 2000 - Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
@@ -189,7 +191,7 @@
* fix bob frequency
* endianness
* do smart things with ac97 2.0 bits.
- * docking and dual codecs and 978?
+ * dual codecs
* leave 54-61 open
*
* it also would be fun to have a mode that would not use pci dma at all
@@ -483,8 +485,12 @@
int bob_freq;
char dsps_open;
+
+ int dock_mute_vol;
};
+static void set_mixer(struct ess_card *card,unsigned int mixer, unsigned int val );
+
static unsigned
ld2(unsigned int x)
{
@@ -983,6 +989,17 @@
outw(inw(ioaddr+0x68) | 0x600, ioaddr + 0x68);
outw(0x0209, ioaddr + 0x60);
}
+
+ /* Turn on the 978 docking chip.
+ First frob the master output enable bit,
+ then set most of the playback volume control registers to max. */
+ outb(inb(ioaddr+0xc0)|(15), ioaddr+0xc0);
+ outb(0xff, ioaddr+0xc3);
+ outb(0xff, ioaddr+0xc4);
+ outb(0xff, ioaddr+0xc6);
+ outb(0xff, ioaddr+0xc8);
+ outb(0x3f, ioaddr+0xcf);
+ outb(0x3f, ioaddr+0xd0);
}
/*
* Indirect register access. Not all registers are readable so we
@@ -1895,19 +1912,52 @@
outw(inw(c-iobase+4)1, c-iobase+4);
/* M_printk(maestro int: %x\n,event);*/
-
if(event(16))
{
- /* XXX if we have a hw volume control int enable
- all the ints? doesn't make sense.. */
- event = inw(c-iobase+0x18);
- outb(0xFF, c-iobase+0x1A);
- }
- else
- {
- /* else ack 'em all, i imagine */
- outb(0xFF, c-iobase+0x1A);
+ int x;
+ enum {UP_EVT, DOWN_EVT, MUTE_EVT} vol_evt;
+ int volume;
+
+ /* Figure out which volume control button was pushed,
+ based on differences from the default register
+ values. */
+ x = inb(c-iobase+0x1c);
+ if (x1) vol_evt = MUTE_EVT;
+ else if (((x1)7) 4) vol_evt = UP_EVT;
+ else vol_evt = DOWN_EVT;
+
+ /* Reset the volume control registers. */
+ outb(0x88, c-iobase+0x1c);
+ outb(0x88, c-iobase+0x1d);
+ outb(0x88, c-iobase+0x1e);
+ outb(0x88, c-iobase+0x1f);
+
+ /* Deal with the button press in a hammer-handed
+ manner by adjusting the master mixer volume. */
+ volume = c-mix.mixer_state[0] 0xff;
+ if (vol_evt == UP_EVT) {
+ volume += 10;
+ if (volume 100)
+ volume = 100;
+ }
+ else if (vol_evt == DOWN_EVT) {
+ volume -= 10;
+ if (volume 0)
+ volume = 0;
+ } else {
+ /* vol_evt == MUTE_EVT */
+ if (volume == 0
Re: Rage Mobility P/M
Jani Monoses <[EMAIL PROTECTED]> writes: > does the atyfb or aty128fb support this chip? > Device id of 4c4d. > Using 2.4.3-ac7. I have a Rage Mobility with the same device ID on my laptop (Compaq Armada M700) but haven't been able to get it working with framebuffer. At any rate, atyfb is the proper one to use. Let me know if you get it working, I'd like to use it too. -- "How could this be a problem in a country where we have Intel and Microsoft?" --Al Gore on Y2K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Rage Mobility P/M
Jani Monoses [EMAIL PROTECTED] writes: does the atyfb or aty128fb support this chip? Device id of 4c4d. Using 2.4.3-ac7. I have a Rage Mobility with the same device ID on my laptop (Compaq Armada M700) but haven't been able to get it working with framebuffer. At any rate, atyfb is the proper one to use. Let me know if you get it working, I'd like to use it too. -- "How could this be a problem in a country where we have Intel and Microsoft?" --Al Gore on Y2K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 3 kmalloc underallocation bugs
Dawson Engler <[EMAIL PROTECTED]> writes:
> enclosed are three bugs found in the 2.4.1 kernel by an extension
> that checks that kmalloc calls allocate enough memory. It examines all
> callsites of the form:
> p = [kv]malloc(nbytes);
> and issues an error if
> sizeof *p < nbytes
[...]
> struct midi_hdr *midihdr;
>
> Error --->
> if ((midihdr = (struct midi_hdr *) kmalloc(sizeof(struct midi_hdr *), GF
> P_KERNEL)) == NULL) {
This sort of thing is why the comp.lang.c approved way to call
malloc() is
foo *x = malloc (sizeof *x);
No cast is required and the sizeof usage resembles the
declaration. The following is what I say on comp.lang.c when
someone does it another way. AFAICS the recommendations apply
equally to [kv]malloc().
--
When calling malloc(), I recommend using the sizeof operator on the
object you are allocating, not on the type. For instance, *don't*
write this:
int *x = malloc (sizeof (int) * 128); /* Don't do this! */
Instead, write it this way:
int *x = malloc (sizeof *x * 128);
There's a few reasons to do it this way:
* If you ever change the type that `x' points to, it's not
necessary to change the malloc() call as well.
This is more of a problem in a large program, but it's still
convenient in a small one.
* Taking the size of an object makes your sizeof call more
similar to your declaration, which makes writing the
statement less error-prone.
For instance, above, the declaration syntax is `*x' and the
sizeof operation is also written `*x'. This provides a
visual clue that the malloc() call is correct.
I don't recommend casting the return value of malloc():
* The cast is not required in ANSI C.
* Casting its return value can mask a failure to #include
, which leads to undefined behavior.
* If you cast to the wrong type by accident, odd failures can
result.
----------
--
Ben Pfaff <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
MSU Student - Debian GNU/Linux Maintainer - GNU Developer
Personal webpage: http://www.msu.edu/user/pfaffben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 3 kmalloc underallocation bugs
Dawson Engler [EMAIL PROTECTED] writes:
enclosed are three bugs found in the 2.4.1 kernel by an extension
that checks that kmalloc calls allocate enough memory. It examines all
callsites of the form:
p = [kv]malloc(nbytes);
and issues an error if
sizeof *p nbytes
[...]
struct midi_hdr *midihdr;
Error ---
if ((midihdr = (struct midi_hdr *) kmalloc(sizeof(struct midi_hdr *), GF
P_KERNEL)) == NULL) {
This sort of thing is why the comp.lang.c approved way to call
malloc() is
foo *x = malloc (sizeof *x);
No cast is required and the sizeof usage resembles the
declaration. The following is what I say on comp.lang.c when
someone does it another way. AFAICS the recommendations apply
equally to [kv]malloc().
--
When calling malloc(), I recommend using the sizeof operator on the
object you are allocating, not on the type. For instance, *don't*
write this:
int *x = malloc (sizeof (int) * 128); /* Don't do this! */
Instead, write it this way:
int *x = malloc (sizeof *x * 128);
There's a few reasons to do it this way:
* If you ever change the type that `x' points to, it's not
necessary to change the malloc() call as well.
This is more of a problem in a large program, but it's still
convenient in a small one.
* Taking the size of an object makes your sizeof call more
similar to your declaration, which makes writing the
statement less error-prone.
For instance, above, the declaration syntax is `*x' and the
sizeof operation is also written `*x'. This provides a
visual clue that the malloc() call is correct.
I don't recommend casting the return value of malloc():
* The cast is not required in ANSI C.
* Casting its return value can mask a failure to #include
stdlib.h, which leads to undefined behavior.
* If you cast to the wrong type by accident, odd failures can
result.
--
--
Ben Pfaff [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
MSU Student - Debian GNU/Linux Maintainer - GNU Developer
Personal webpage: http://www.msu.edu/user/pfaffben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
Matti Aarnio <[EMAIL PROTECTED]> writes: > On Mon, Oct 16, 2000 at 04:55:08PM -0400, Ben Pfaff wrote: > > Yes. In practice the usual question is whether the compiler will > > evaluate the operands from left to right or from right to left, > > but the compiler is within its rights to evaluate the operands in > > any order it wants. > > That depends mainly on question: Does your stack grow up or down ? No it doesn't. It depends mainly on whether the ABI for the machine says that arguments are pushed onto the stack in left-to-right or right-to-left order. You could do either on x86, for instance, and it has nothing to do with whether the x86 stack grows up or down. > > > Does this imply that even the evaluation of a function pointer > > > is itself undefined in terms of ordering? > > > > Yes. > >For things like lone pointer referral with pre/post inc/dec: > *p++ >it is well defined, but for things like: > *p++ + *p >it is not. (Will the second *p be evaluated before or after *p++ >post-increment ?) Non sequitur: I see no function pointers being evaluated here. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
Jonathan George <[EMAIL PROTECTED]> writes: > > $ The order of evaluation of the function designator, the > > $ arguments, and subexpressions within the arguments is > > $ unspecified, ... > >-- > > I sit surprised and corrected. With every version of every C compiler on > every OS I have ever used (over 100 combinations from AmigaDOS 1.1 using > Manx C to E1 using Kai C++) the behavior has been the same for parameter > lists as for the comma operator in this respect. Yes. In practice the usual question is whether the compiler will evaluate the operands from left to right or from right to left, but the compiler is within its rights to evaluate the operands in any order it wants. > Does this imply that even the evaluation of a function pointer > is itself undefined in terms of ordering? Yes. > >"Premature optimization is the root of all evil." > >--D. E. Knuth, "Structured Programming with go to Statements" > > Absolutely true. Good sigmonster, have $TREAT. > I would be really interested to see how well the kernel compiler does at > optimizing out all of these new tmp variables in terms of the resulting > register utilization and performance. At least an assembler code size > comparison is in order for each of these individual cases. I agree with you and Al Viro that the proposed fixes were less than desirable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
Jonathan George <[EMAIL PROTECTED]> writes: > This patch has many bogus corrections where new variables were created, but > the order of evaluation is already unambiguous. > > For example each comma separated clause in an expression is guaranteed to be > completely evaluated before the next comma separated clause Including > Assignments. No, that is not true in general. When the comma in question is the comma operator, it is true. But when the comma separates arguments to a function, it is not: the order of evaluation of function arguments is implementation dependent. See C89 section 6.3.2.2 "Function calls": $ The order of evaluation of the function designator, the $ arguments, and subexpressions within the arguments is $ unspecified, ... -- "Premature optimization is the root of all evil." --D. E. Knuth, "Structured Programming with go to Statements" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
Jonathan George [EMAIL PROTECTED] writes: This patch has many bogus corrections where new variables were created, but the order of evaluation is already unambiguous. For example each comma separated clause in an expression is guaranteed to be completely evaluated before the next comma separated clause Including Assignments. No, that is not true in general. When the comma in question is the comma operator, it is true. But when the comma separates arguments to a function, it is not: the order of evaluation of function arguments is implementation dependent. See C89 section 6.3.2.2 "Function calls": $ The order of evaluation of the function designator, the $ arguments, and subexpressions within the arguments is $ unspecified, ... -- "Premature optimization is the root of all evil." --D. E. Knuth, "Structured Programming with go to Statements" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
Jonathan George [EMAIL PROTECTED] writes: $ The order of evaluation of the function designator, the $ arguments, and subexpressions within the arguments is $ unspecified, ... -- I sit surprised and corrected. With every version of every C compiler on every OS I have ever used (over 100 combinations from AmigaDOS 1.1 using Manx C to E1 using Kai C++) the behavior has been the same for parameter lists as for the comma operator in this respect. Yes. In practice the usual question is whether the compiler will evaluate the operands from left to right or from right to left, but the compiler is within its rights to evaluate the operands in any order it wants. Does this imply that even the evaluation of a function pointer is itself undefined in terms of ordering? Yes. "Premature optimization is the root of all evil." --D. E. Knuth, "Structured Programming with go to Statements" Absolutely true. Good sigmonster, have $TREAT. I would be really interested to see how well the kernel compiler does at optimizing out all of these new tmp variables in terms of the resulting register utilization and performance. At least an assembler code size comparison is in order for each of these individual cases. I agree with you and Al Viro that the proposed fixes were less than desirable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
Matti Aarnio [EMAIL PROTECTED] writes: On Mon, Oct 16, 2000 at 04:55:08PM -0400, Ben Pfaff wrote: Yes. In practice the usual question is whether the compiler will evaluate the operands from left to right or from right to left, but the compiler is within its rights to evaluate the operands in any order it wants. That depends mainly on question: Does your stack grow up or down ? No it doesn't. It depends mainly on whether the ABI for the machine says that arguments are pushed onto the stack in left-to-right or right-to-left order. You could do either on x86, for instance, and it has nothing to do with whether the x86 stack grows up or down. Does this imply that even the evaluation of a function pointer is itself undefined in terms of ordering? Yes. For things like lone pointer referral with pre/post inc/dec: *p++ it is well defined, but for things like: *p++ + *p it is not. (Will the second *p be evaluated before or after *p++ post-increment ?) Non sequitur: I see no function pointers being evaluated here. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
