Re: Recent 6.0_BETA crash
On Thu, Mar 8, 2012 at 2:31 PM, Manuel Bouyer bou...@antioche.eu.org wrote: On Thu, Mar 08, 2012 at 02:04:49PM +0300, Aleksey Cheusov wrote: On my system this crash is reproducible. At least it repeated three times with xdm login. Does it make sense to send PR? Does it always fail in the same way, or does the panic happen at random places ? Crash happens always in the same place. I tried it three times and the only difference is in addresses.
Re: Recent 6.0_BETA crash
On Sun, Mar 11, 2012 at 12:19:45PM +0300, Aleksey Cheusov wrote: On Thu, Mar 8, 2012 at 2:31 PM, Manuel Bouyer bou...@antioche.eu.org wrote: On Thu, Mar 08, 2012 at 02:04:49PM +0300, Aleksey Cheusov wrote: On my system this crash is reproducible. At least it repeated three times with xdm login. Does it make sense to send PR? Does it always fail in the same way, or does the panic happen at random places ? Crash happens always in the same place. I tried it three times and the only difference is in addresses. Could you see if a recent netbsd-6 kernel (with the last pullups to kern_exec.c) still has the problem ? If so, please open a PR. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Adding SMBus block transfers to iic(4)
There are apparently some devices out there that really need to have i2c block-mode transfers, and it appears that none of our current drivers (at least, none of the mainstream pci drivers) supports this. At first glance, it might appear that we could simply check the transfer requested byte-count, and automatically operate in block mode if the count is greater than 2; the implication is that we could fall back to byte or word transfers for smaller byte counts. But it looks like at least one device out there [1] doesn't support this. So I propose adding a new flag bit that can be passed to iic_exec() to request block-transfer protocols. In src/sys/dev/i2c/i2c_io.h #define I2C_F_BLOCK 0x20 Comments? Suggestions? Alternatives? [1] http://eeepc-linux.googlecode.com/files/9LPR426A.pdf - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: Adding SMBus block transfers to iic(4)
[...] i2c block-mode transfers [...] #define I2C_F_BLOCK 0x20 Comments? Suggestions? Alternatives? BLOCK has a second, quite different, meaning (as in, blocking I/O). It may not apply here, but defining a bit in the interface that can be misunderstood as indicating it does could, at the very least, be confusing. Might I suggest BLKMODE instead of BLOCK? At least to my eye, that's a lot less ambiguous. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Adding SMBus block transfers to iic(4)
Good point. On Sun, 11 Mar 2012, Mouse wrote: [...] i2c block-mode transfers [...] #define I2C_F_BLOCK 0x20 Comments? Suggestions? Alternatives? BLOCK has a second, quite different, meaning (as in, blocking I/O). It may not apply here, but defining a bit in the interface that can be misunderstood as indicating it does could, at the very least, be confusing. Might I suggest BLKMODE instead of BLOCK? At least to my eye, that's a lot less ambiguous. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B !DSPAM:4f5d315b1981260811860! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
config syntax for modules
As has been previously suggested, I am planning to add module syntax to config(1); namely module options FOO and module dev* at bus? and so forth, to indicate that the element so named should be built as a module. At first this will have no effect in config vs. not listing the element at all, but it will allow writing the off-the-shelf kernel configs in a clearer way. That is, if something is going to be built as a module, adding module to its config line will prevent it from being compiled in, while making it clear what the situation is. In the longer run I expect this syntax should be linked to (1) only allowing autoload of an element from a module if it was configured as a module, and probably also (2) selecting what modules should be built at all. (I'm aware the latter point has been contentious. I fail to see why people with slow machines should be obliged to compile bazillions of modules they know they'll never use.) Also probably it should be possible to wire down a particular attachment but still build the driver as a module. The question at hand (using options DDB as an example kernel element because it's short) is whether no module options DDB should be legal syntax and what it should mean. Alternative 1: options DDB means ddb should be compiled into the kernel module options DDB means ddb should be available as a module no options DDB means ddb should not be available In this alternative, each of these reflects one of three possible states; the directives may appear in any order and the last one to appear selects the configured behavior. Alternative 2: options DDB means ddb should be compiled into the kernel no options DDB means ddb should not be compiled into the kernel module options DDB means ddb should be available as a module no module options DDB means ddb should not be available as a module In this alternative, no cancels a previous statement of the same kind without no. Canceling a statement that has not been made is an error; and since having options DDB and module options DDB in effect at once is meaningless, one must be cancelled before the other can be applied. Alternative 3: Same as alternative 2, except that if module options DDB and options DDB are both in effect at once, ddb is compiled in. (Others?) My thoughts so far are that while alternatives 2 and 3 are a more obvious generalization of the existing config logic, alternative 1 may ultimately make more sense. -- David A. Holland dholl...@netbsd.org
