5.3 lyrics
hi tech@. despite of 5.3 lyrics being released recently, 53.html says opposite. is it normal? cheers, alexey
Re: /usr.bin/colldef and collation tables
On Sat, Mar 23, 2013 at 04:09:12PM +0100, Stefan Sperling wrote: On Sat, Mar 23, 2013 at 09:27:50AM -0500, Vladimir Támara Patiño wrote: Please change this to look like in other parse.y files in the OpenBSD src tree (e.g. look at bgpd). Could you change? No, sorry. I don't have time for doing that. My time is also limited. Please cross-check the parse.y files yourself and make sure the new parse.y file follows conventions used in the existing parse.y files. We want our source tree to be consistent. I think it is somehow similar to lex.l and yacc.y of usr.bin/mklocale But, however I would like to know what conventions of other parse.y files are desirable (even for mklocale)? * Using log.c ? * Not using lex, but implementing the lexer in parse.y? I see you're still tempted to copy code from FreeBSD without making it perfect for OpenBSD. I'm not going to allow you to be that lazy ;-) I made small changes, like improving documentation, using strlcpy and strlcat, adding debugging of lexer when the option -d is used. Comparing mklocale current implementations with NetBSD's, I see improving documentation and renamings. What other conventions are important? Possible to show example with mklocale's lexer and parser? Why do you compile colldef with COLLAGE_DEBUG by default? To have the option -d that gives debuggin information (mklocale also has it). Don't expect me to hunt for additional opinions and OKs before I've gotten around to review the libc changes you sent as well, and before I'm perfectly happy with both diffs. Ok. Better then sending both parts as one patch? I'm certainly not going to commit any of this without asking others for review as well, so please don't be worried if it takes some time to get this in. Ok. collate.h has this: This should be named something like COLLATE_MAX_STR_LEN. Ok. Also, the collate.h file has: +__BEGIN_DECLS +#ifdef COLLATE_DEBUG +void __collate_print_tables(void); This is bogus. colldef.c declares and defines a collate_print_tables() function. The __collate_print_tables() function is used in the libc diff you sent, so it doesn't belong in the colldef diff. Ok. Should I sent now, only one diff (with changes for colldef, collation tables and changes to libc ?) -- Dios, gracias por tu amor infinito. -- Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/ http://www.pasosdejesus.org/dominio_publico_colombia.html
Re: Adds product ATI RADEON_HD5570
On Sun, 24 Mar 2013, Ted Unangst wrote:
On Sun, Mar 24, 2013 at 16:59, Abel Abraham Camarillo Ojeda wrote:
When I used nail it _always_ segfaults when trying to open
my gmail inbox via IMAP, maybe it has something to do
with my 30,000 mails in inbox...
smtp and imap are separate and unrelated protocols. your mail client
doesn't need to read your imap inbox to send mails using smtp.
I hope alpine doesn't mangle this.
Index: dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1670
diff -u -p -r1.1670 pcidevs
--- dev/pci/pcidevs 14 Mar 2013 14:47:00 - 1.1670
+++ dev/pci/pcidevs 18 Mar 2013 22:09:57 -
@@ -1273,6 +1273,7 @@ product ATI RADEON_HD6670 0x6758 Radeon
product ATI RADEON_HD5800 0x6899 Radeon HD 5800
product ATI RADEON_HD5700 0x68b8 Radeon HD 5700
product ATI RADEON_HD5670 0x68d8 Radeon HD 5670
+product ATI RADEON_HD5570 0x68d9 Radeon HD 5570
product ATI MOBILITY_HD54700x68e0 Radeon Mobility HD 5470
product ATI MOBILITY_HD54300x68e1 Radeon Mobility HD 5430
product ATI RADEON_HD5450 0x68f9 Radeon HD 5450
Index: dev/pci/pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1666
diff -u -p -r1.1666 pcidevs.h
--- dev/pci/pcidevs.h 14 Mar 2013 14:47:28 - 1.1666
+++ dev/pci/pcidevs.h 18 Mar 2013 22:10:30 -
@@ -1278,6 +1278,7 @@
#definePCI_PRODUCT_ATI_RADEON_HD5800 0x6899 /* Radeon HD
5800 */
#definePCI_PRODUCT_ATI_RADEON_HD5700 0x68b8 /* Radeon HD
5700 */
#definePCI_PRODUCT_ATI_RADEON_HD5670 0x68d8 /* Radeon HD
5670 */
+#definePCI_PRODUCT_ATI_RADEON_HD5570 0x68d9 /* Radeon HD
5570 */
#definePCI_PRODUCT_ATI_MOBILITY_HD5470 0x68e0 /* Radeon
Mobility HD 5470 */
#definePCI_PRODUCT_ATI_MOBILITY_HD5430 0x68e1 /* Radeon
Mobility HD 5430 */
#definePCI_PRODUCT_ATI_RADEON_HD5450 0x68f9 /* Radeon HD
5450 */
Index: dev/pci/pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1661
diff -u -p -r1.1661 pcidevs_data.h
--- dev/pci/pcidevs_data.h 14 Mar 2013 14:47:28 - 1.1661
+++ dev/pci/pcidevs_data.h 18 Mar 2013 22:10:30 -
@@ -3408,6 +3408,10 @@ static const struct pci_known_product pc
Radeon HD 5670,
},
{
+ PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD5570,
+ Radeon HD 5570,
+ },
+ {
PCI_VENDOR_ATI, PCI_PRODUCT_ATI_MOBILITY_HD5470,
Radeon Mobility HD 5470,
},
Fix iteration of softdep hash tables
Hi,
The code in clear_remove() and clear_inodedeps() does not iterate over
the pagedep and inodedep hash tables correctly. The last entry in the
table is skipped -- this is due to the fact that 'pagedep_hash' and
'inodedep_hash' hold the size of the hash tables - 1.
-p.
Index: ufs/ffs/ffs_softdep.c
===
RCS file: /cvs/src/sys/ufs/ffs/ffs_softdep.c,v
retrieving revision 1.116
diff -u -p -r1.116 ffs_softdep.c
--- ufs/ffs/ffs_softdep.c 17 Feb 2013 17:39:29 - 1.116
+++ ufs/ffs/ffs_softdep.c 25 Mar 2013 10:36:26 -
@@ -5320,9 +5320,9 @@ clear_remove(struct proc *p)
ino_t ino;
ACQUIRE_LOCK(lk);
- for (cnt = 0; cnt pagedep_hash; cnt++) {
+ for (cnt = 0; cnt = pagedep_hash; cnt++) {
pagedephd = pagedep_hashtbl[next++];
- if (next = pagedep_hash)
+ if (next pagedep_hash)
next = 0;
LIST_FOREACH(pagedep, pagedephd, pd_hash) {
if (LIST_FIRST(pagedep-pd_dirremhd) == NULL)
@@ -5376,9 +5376,9 @@ clear_inodedeps(struct proc *p)
* We will then gather up all the inodes in its block
* that have dependencies and flush them out.
*/
- for (cnt = 0; cnt inodedep_hash; cnt++) {
+ for (cnt = 0; cnt = inodedep_hash; cnt++) {
inodedephd = inodedep_hashtbl[next++];
- if (next = inodedep_hash)
+ if (next inodedep_hash)
next = 0;
if ((inodedep = LIST_FIRST(inodedephd)) != NULL)
break;
Re: More direct use of IFQ_MAXLEN
On Tue, Mar 19, 2013 at 11:50 +0100, Martin Pieuchot wrote: Diff below removes 4 global read-only variables ifqmaxlen, ipqmaxlen, ip6qmaxlen and mplsqmaxlen that are all set to IFQ_MAXLEN and never modified afterward. ok? OK to reduce bogosity.
ddb while running X
Now that we have KMS, it becomes possible to switch to the console
before entering ddb. Of course this will only work on devices
supported by inteldrm for now.
ok?
Index: arch/i386/i386/db_interface.c
===
RCS file: /cvs/src/sys/arch/i386/i386/db_interface.c,v
retrieving revision 1.27
diff -u -p -r1.27 db_interface.c
--- arch/i386/i386/db_interface.c 4 Apr 2011 22:37:30 - 1.27
+++ arch/i386/i386/db_interface.c 26 Mar 2013 00:28:23 -
@@ -57,6 +57,11 @@
#include dev/acpi/acpidebug.h
#endif /* NACPI 0 */
+#include wsdisplay.h
+#if NWSDISPLAY 0
+#include dev/wscons/wsdisplayvar.h
+#endif
+
extern label_t *db_recover;
extern char *trap_type[];
extern int trap_types;
@@ -100,6 +105,10 @@ int
kdb_trap(int type, int code, db_regs_t *regs)
{
int s;
+
+#if NWSDISPLAY 0
+ wsdisplay_switchtoconsole();
+#endif
switch (type) {
case T_BPTFLT: /* breakpoint */
Index: arch/amd64/amd64/db_interface.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/db_interface.c,v
retrieving revision 1.16
diff -u -p -r1.16 db_interface.c
--- arch/amd64/amd64/db_interface.c 1 Apr 2010 19:47:59 - 1.16
+++ arch/amd64/amd64/db_interface.c 26 Mar 2013 00:28:23 -
@@ -62,6 +62,11 @@
#include dev/acpi/acpidebug.h
#endif /* NACPI 0 */
+#include wsdisplay.h
+#if NWSDISPLAY 0
+#include dev/wscons/wsdisplayvar.h
+#endif
+
extern label_t *db_recover;
extern char *trap_type[];
extern int trap_types;
@@ -106,6 +111,10 @@ int
kdb_trap(int type, int code, db_regs_t *regs)
{
int s;
+
+#if NWSDISPLAY 0
+ wsdisplay_switchtoconsole();
+#endif
switch (type) {
case T_BPTFLT: /* breakpoint */
Index: dev/pci/drm/i915/i915_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
retrieving revision 1.7
diff -u -p -r1.7 i915_drv.c
--- dev/pci/drm/i915/i915_drv.c 25 Mar 2013 19:50:56 - 1.7
+++ dev/pci/drm/i915/i915_drv.c 26 Mar 2013 00:28:24 -
@@ -699,6 +699,10 @@ inteldrm_show_screen(void *v, void *cook
void (*cb)(void *, int, int), void *cbarg)
{
struct inteldrm_softc *dev_priv = v;
+ struct rasops_info *ri = dev_priv-ro;
+
+ if (cookie == ri-ri_active)
+ return (0);
dev_priv-switchcb = cb;
dev_priv-switchcbarg = cbarg;
Re: uthum(4): Microdia's USB TEMPer variant
Sasano, recently I bought a pair of pcsensor devices from amazon. Wasn't sure if uthum supported it yet. Your diff works for me: dmesg: uhidev3 at uhub3 port 1 configuration 1 interface 0 RDing TEMPerV1.2 rev 2.00/0.01 addr 2 uhidev3: iclass 3/1, 1 report id uthum0 at uhidev3 reportid 1 uhidev4 at uhub3 port 1 configuration 1 interface 1 RDing TEMPerV1.2 rev 2.00/0.01 addr 2 uhidev4: iclass 3/1 uthum1 at uhidev4 uthum1: type ds75/12bit (temperature) sysctl hw: hw.sensors.uthum1.temp0=29.12 degC (inner) usbdevs -vd: Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x8086), rev 1.00 uhub3 port 1 addr 2: low speed, power 100 mA, config 1, TEMPerV1.2(0x7401), RDing(0x0c45), rev 0.01 uhidev3 uhidev4 port 2 powered Im running -current + uthum-wip.diff OpenBSD 5.3-current (GENERIC.MP) #1: Mon Mar 25 16:26:44 CST 2013 r...@host.mynetwork.dev:/usr/src/sys/arch/amd64/compile/GENERIC.MP -luis On Sat, Mar 16, 2013 at 9:24 AM, SASANO Takayoshi u...@mx5.nisiq.net wrote: Hi, I bought a PC Sensor's gold TEMPer (http://www.pcsensor.com/index.php?_a=productproduct_id=41), but this is completely different from TEMPer series which handled by uthum(4) driver. This is also USB HID device (one keyboard and one mouse) but temperature data comes from interrupt pipe, not control pipe. Details are described in TEMPered's wiki page [1]. And I hope my lsusb log [2] and USB analyzer log (attached to Windows) [3] helps. I wrote a patch (work-in-progress, and for OpenBSD 5.2) for uthum(4) to test my device [4]. But I have a question, which is better to expand uthum(4) driver or write a new one? [1] https://github.com/edorfaus/TEMPered/wiki/0C45%3A7401 [2] http://www2192ue.sakura.ne.jp/~uaa/gomitext/2013/20130224/temp.txt [3] http://www2192ue.sakura.ne.jp/~uaa/gomitext/2013/20130307/temper.txt [4] http://www2192ue.sakura.ne.jp/~uaa/gomitext/2013/20130315/uthum-wip.diff Thanks, SASANO Takayoshi u...@mx5.nisiq.net
