Re: Like OpenBSD? Like to see new stuff happening? You really need to order a CD today :)
On Mon, Apr 18, 2011 at 9:39 PM, Bob Beck b...@obtuse.com wrote: So - yes we like donations, but we also like CD sales.. now is the time to help out. Order done on openbsdeurope.com. Sorry for being late. cheers! david
Re: fenv.h support for libm
On 4/18/11, Matthew Dempsky matt...@dempsky.org wrote: On Sun, Apr 17, 2011 at 5:29 PM, Philip Guenther guent...@gmail.com wrote: I haven't worked through all the bit-twiddling and asm, but what I have looks good and the abundance of regress tests that keep showing up in cvs up -d inspires confidence. With that x87--__x87 nit, ok guenther@ ok matthew@ as well; the regress tests run fine on my system, and I was able to use it to build my WIP CGAL and OpenSCAD ports. However, since this is only support for amd64, it can't be linked into the build for all platforms just yet. Can at least the .c and .h files be committed now so they're not lost and are easier to continue testing until fenv.h support can be turned on everywhere? I think so; let's commit fenv.c for each arch till it's complete. I'll commit the amd64 bits this evening if noone objects. I can't finish this unless someone provides me with access to other archs. If someone can provide remote access to develop and test fp things, please contact me offlist.
Re: wol for xl(4)
On Tue, Apr 19, 2011 at 02:03:54AM +0200, Tobias Ulmer wrote: On Mon, Apr 18, 2011 at 10:17:33AM +0200, Stefan Sperling wrote: On Mon, Apr 18, 2011 at 04:18:01AM +0200, Tobias Ulmer wrote: On Sun, Apr 17, 2011 at 11:05:38AM +0200, Stefan Sperling wrote: On Thu, Mar 31, 2011 at 06:54:44PM +0200, Stefan Sperling wrote: This is an attempt to add wol support to xl(4). Unfortunately, while I have an xl(4) card to test with none of the motherboards I have will do WOL with it since they all lack an on-board WOL connector :( So test reports are needed. Please also check whether WOL is disabled by default. I haven't received any test reports yet. The (commited) diff has no effect on my onboard xl(4). The hardware supports this (BIOS setting checked): http://support.dell.com/support/edocs/systems/dvol/en/vol_mt/SETUP.HTM#Wakeup %20On%20LAN Please elaborate on no effect. Does WOL work at all? Or does it not work at all? I've done tests with the integrated NIC and one in a PCI slot connected to the WOL connector. WOL does not work in any configuration I've tried. Can it be enabled from the BIOS but not, independently, from ifconfig? The BIOS has 3 WOL settings: Off, Integrated NIC, WOL Connector. I've configured this according to which card was tested. WOL still did not work. Can it be disabled via ifconfig even if enabled in the BIOS? I've tried enabling WOL using ifconfig for the PCI NIC and set the BIOS to WOL mainboard connector. WOL did not work. shutdowns were always done with halt -p No idea what else I could do... Thanks. I'll have to take another look at the FreeBSD driver so. Can you check whether WOL works with FreeBSD?
Re: Like OpenBSD? Like to see new stuff happening? You really need to order a CD today :)
On Tue, 19 Apr 2011 09:32:50 +0200, David Coppa dco...@gmail.com wrote: On Mon, Apr 18, 2011 at 9:39 PM, Bob Beck b...@obtuse.com wrote: So - yes we like donations, but we also like CD sales.. now is the time to help out. Order done on openbsdeurope.com. Sorry for being late. cheers! david Hi for Europeans, you can order here too http://openbsd.otasc.org/ :-) Enjoy ! Guillaume.
automatically set the default console?
When I'm installing over a serial line, I would expect to use that as my
console in the future. This diff sets the default console to the one we
are currently using, so it's just another [enter]. (The style is based
on the xdm case immediately above)
OK?
Index: distrib/miniroot/install.sub
===
RCS file: /cvs/openbsd/src/distrib/miniroot/install.sub,v
retrieving revision 1.636
diff -u -p -r1.636 install.sub
--- distrib/miniroot/install.sub22 Mar 2011 19:20:15 - 1.636
+++ distrib/miniroot/install.sub5 Apr 2011 10:42:10 -
@@ -1895,9 +1895,11 @@ questions() {
xdm=$resp
fi
+ defcons=no
+ [[ -n $CONSOLE ]] defcons=yes
if [[ -n $CDEV ]]; then
_d=${CPROM:-$CDEV}
- ask_yn Change the default console to $_d?
+ ask_yn Change the default console to $_d? $defcons
defcons=$resp
if [[ $resp == y ]]; then
ask_which speed should $_d use \
--
You've been leading a dog's life. Stay off the furniture.
Re: automatically set the default console?
On Tue, Apr 19, 2011 at 12:21:57PM +0200, Peter Hessler wrote:
When I'm installing over a serial line, I would expect to use that as my
console in the future. This diff sets the default console to the one we
are currently using, so it's just another [enter]. (The style is based
on the xdm case immediately above)
OK?
I seem to recall proposing this when we added the auto speed
detection. I was shot down for reasons I no longer recall in detail.
Something to do with people building boxes en masse on a bench with
serial but wanting to deploy to racks with KVM. Or something.
Personally I still like the idea. :-)
Ken
Index: distrib/miniroot/install.sub
===
RCS file: /cvs/openbsd/src/distrib/miniroot/install.sub,v
retrieving revision 1.636
diff -u -p -r1.636 install.sub
--- distrib/miniroot/install.sub 22 Mar 2011 19:20:15 - 1.636
+++ distrib/miniroot/install.sub 5 Apr 2011 10:42:10 -
@@ -1895,9 +1895,11 @@ questions() {
xdm=$resp
fi
+ defcons=no
+ [[ -n $CONSOLE ]] defcons=yes
if [[ -n $CDEV ]]; then
_d=${CPROM:-$CDEV}
- ask_yn Change the default console to $_d?
+ ask_yn Change the default console to $_d? $defcons
defcons=$resp
if [[ $resp == y ]]; then
ask_which speed should $_d use \
--
You've been leading a dog's life. Stay off the furniture.
Re: km_alloc for stack and exec
On Mon, Apr 18, 2011 at 03:47:27PM -0600, Artur Grabowski wrote:
A repeat of an earlier diff.
Change stack and exec arguments allocation from old allocators to km_alloc(9).
//art
Index: kern/kern_exec.c
===
RCS file: /cvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.117
diff -u -r1.117 kern_exec.c
--- kern/kern_exec.c 4 Apr 2011 13:00:13 - 1.117
+++ kern/kern_exec.c 18 Apr 2011 19:37:08 -
@@ -227,6 +227,11 @@
return (error);
}
+struct kmem_va_mode kv_exec = {
+ .kv_map = exec_map,
+ .kv_wait = 1
+};
+
/*
* exec system call
*/
@@ -312,7 +317,7 @@
/* XXX -- THE FOLLOWING SECTION NEEDS MAJOR CLEANUP */
/* allocate an argument buffer */
- argp = (char *) uvm_km_valloc_wait(exec_map, NCARGS);
+ argp = km_alloc(NCARGS, kv_exec, kp_pageable, kd_waitok);
#ifdef DIAGNOSTIC
if (argp == NULL)
panic(execve: argp == NULL);
@@ -592,7 +597,7 @@
splx(s);
}
- uvm_km_free_wakeup(exec_map, (vaddr_t) argp, NCARGS);
+ km_free(argp, NCARGS, kv_exec, kp_pageable);
pool_put(namei_pool, nid.ni_cnd.cn_pnbuf);
vn_close(pack.ep_vp, FREAD, cred, p);
@@ -689,7 +694,7 @@
/* close and put the exec'd file */
vn_close(pack.ep_vp, FREAD, cred, p);
pool_put(namei_pool, nid.ni_cnd.cn_pnbuf);
- uvm_km_free_wakeup(exec_map, (vaddr_t) argp, NCARGS);
+ km_free(argp, NCARGS, kv_exec, kp_pageable);
freehdr:
free(pack.ep_hdr, M_EXEC);
@@ -717,7 +722,7 @@
free(pack.ep_emul_arg, M_TEMP);
pool_put(namei_pool, nid.ni_cnd.cn_pnbuf);
vn_close(pack.ep_vp, FREAD, cred, p);
- uvm_km_free_wakeup(exec_map, (vaddr_t) argp, NCARGS);
+ km_free(argp, NCARGS, kv_exec, kp_pageable);
free_pack_abort:
free(pack.ep_hdr, M_EXEC);
Index: kern/kern_fork.c
===
RCS file: /cvs/src/sys/kern/kern_fork.c,v
retrieving revision 1.125
diff -u -r1.125 kern_fork.c
--- kern/kern_fork.c 3 Apr 2011 14:56:28 - 1.125
+++ kern/kern_fork.c 18 Apr 2011 19:37:08 -
@@ -195,6 +195,11 @@
/* print the 'table full' message once per 10 seconds */
struct timeval fork_tfmrate = { 10, 0 };
+struct kmem_va_mode kv_fork = {
+ .kv_map = kernel_map,
+ .kv_align = USPACE_ALIGN
+};
+
int
fork1(struct proc *p1, int exitsig, int flags, void *stack, size_t stacksize,
void (*func)(void *), void *arg, register_t *retval,
@@ -204,7 +209,7 @@
uid_t uid;
struct vmspace *vm;
int count;
- vaddr_t uaddr;
+ struct user *uaddr;
int s;
extern void endtsleep(void *);
extern void realitexpire(void *);
@@ -251,10 +256,7 @@
return (EAGAIN);
}
- uaddr = uvm_km_kmemalloc_pla(kernel_map, uvm.kernel_object, USPACE,
- USPACE_ALIGN, UVM_KMF_ZERO,
- dma_constraint.ucr_low, dma_constraint.ucr_high,
- 0, 0, USPACE/PAGE_SIZE);
+ uaddr = km_alloc(USPACE, kv_fork, kp_dma_zero, kd_waitok);
if (uaddr == 0) {
As ariane said, this should be checking null (km_alloc returns void * and
uaddr is pointer)
chgproccnt(uid, -1);
nprocs--;
Index: kern/sys_pipe.c
===
RCS file: /cvs/src/sys/kern/sys_pipe.c,v
retrieving revision 1.58
diff -u -r1.58 sys_pipe.c
--- kern/sys_pipe.c 14 Jan 2010 23:12:11 - 1.58
+++ kern/sys_pipe.c 18 Apr 2011 19:37:08 -
@@ -168,9 +168,9 @@
int
pipespace(struct pipe *cpipe, u_int size)
{
- caddr_t buffer;
+ void *buffer;
- buffer = (caddr_t)uvm_km_valloc(kernel_map, size);
+ buffer = km_alloc(size, kv_any, kp_pageable, kd_waitok);
if (buffer == NULL) {
return (ENOMEM);
}
@@ -714,8 +714,8 @@
if (cpipe-pipe_buffer.size PIPE_SIZE)
--nbigpipe;
amountpipekva -= cpipe-pipe_buffer.size;
- uvm_km_free(kernel_map, (vaddr_t)cpipe-pipe_buffer.buffer,
- cpipe-pipe_buffer.size);
+ km_free(cpipe-pipe_buffer.buffer, cpipe-pipe_buffer.size,
+ kv_any, kp_pageable);
cpipe-pipe_buffer.buffer = NULL;
}
}
Index: uvm/uvm_glue.c
===
RCS file: /cvs/src/sys/uvm/uvm_glue.c,v
retrieving revision 1.58
diff -u -r1.58 uvm_glue.c
--- uvm/uvm_glue.c15 Apr 2011 21:47:24 - 1.58
+++ uvm/uvm_glue.c18 Apr 2011 19:37:09 -
@@ -361,9 +361,11 @@
void
uvm_exit(struct proc *p)
{
+ extern struct kmem_va_mode kv_fork;
+
uvmspace_free(p-p_vmspace);
p-p_vmspace = NULL;
- uvm_km_free(kernel_map, (vaddr_t)p-p_addr, USPACE);
+ km_free(p-p_addr, USPACE, kv_fork,
Re: Remove useless sti in x86 interrupt return path
Hi, On Mon, Apr 18, 2011 at 10:00:02PM -0700, Philip Guenther wrote: The sti was introduced in revision 1.97 of locore.s in March 2006 by mickey@. Commit message: | prevent the faults on iret to run w/ disabled intrs and cause | deadlocks; niklas toby tom ok Maybe mickey or one of the people giving oks back then want to comment? That predates my involvement with OpenBSD, but I think get the gist. iret can fault if, for example, the user corrupts certain members of the sigcontext passed to a signal handler. If that happens the the CPU generates an exception on the iret and you end up in trap() where it peeks at the instruction that triggered the trap and, seeing it was iret, arranges to 'return' to the resume_iret label to generate what looks like a normal fault against the process. The goal of that sti is to keep that 'normal' fault from being processed with interrupts blocked. Point taken, I missed the sigreturn path. However, note that iret can only fault if the values of the segment registers stored on the kernel stack are bogus. In particular iret will not fault on the new EIP address. (The address can page fault but the fault will be on the instruction pointed to by the new CS:EIP and not in iret). With that in mind, the question is: Is it really a problem if the trap handler runs with interrupts disabled? See below. So, possibility one: sti's effect is delayed to the end of next instruction. This is true, the effect of sti is delayed by one instruction. This is documented in the intel manual. What happens if you put it immediately before an iret that faults? If the flags pushed on the stack by the fault have interrupts unblocked, then simply moving the sti down a line to between the addl and the iret would be enough. If you can reproduce this situation easily than I would ask that you try that. This solves the stack overflow that I see, but it results in inconsistent code. See below. Possibility two would be to try to handle this from, uh, inside resume_iret I guess. I'm not 100% sure whether it can be unilateral there though. This would be my preferred solution. In particular, I see two possibilities: * Maybe it is not even a problem is irqs are sometimes disabled during trap. * It is a problem if trap runs with irqs disabled. In this case, userland can easily trigger this by trapping on one of the pop instructions for ds, es, fs or gs. Those instructions in the interrupt return path run with irqs disabled. Thus moving the sti in the interupt return path down one instruction immediately before the iret does not really help. The proper solution would probably be to add explicit calls to sti in all of the resume paths (or even explicitly before calling trap). regardsChristian
Re: diff: get rid the out of static map entries problem
On Tue, Apr 19, 2011 at 11:26:16AM +0600, Anton Maksimenkov wrote: 2011/4/19 Ariane van der Steldt ari...@stack.nl: Your diff is reducable to: ?static struct vm_map_entry kentries[REALLY_BIG_NUMBER]; And then managing that memory using vmmap. Yes, more or less... But your example eats VA memory and physical pages immediately and forever, while my diff tried to eat it on demand (it even may be constructed in a way to free physical pages when there will be many free kentries, in some cases of course)... Allocating a map eats VA. A submap is simply a local instance of the vmmap allocator, complete with address space that is managed and taken away from the global kernel. And what's worse, it's a contig range, so it will worsen the fragmentation burden (the same amount of fragmentation will live in a smaller area now). pmap_kenter_pa will actually do the physical page management, in a better way (since you know what the memory is used for, you can make more intelligent decisions). Kinda what uvm_km_getpage_pla() does. Your diff will generate problems with recursive locking: 1) I need an entry for the kernel_map ? lock: kernel_map. 2) Therefor I need one from kentry_map, but I only have one left ? lock: kentry_map. ^ why? where you get it? 3) I re-enter kentry_map to allocate a new entry ? lock: kentry_map again! ^ that's must be first and right lock. it occures in uvm_map(kentry_map,...) when it called from uvm_km_kmemalloc(kentry_map,...). You're right. You avoid the recursion. I'm sorry. potentially changed by step 3. Furthermore, simple_lock is a noop and queued for destruction (use mutex instead). Yes. That's why I introduced mutex, as an example (but, my mistake, I missed it in uvm_mapent_free). the malloc groups? Analyze the problem, why does it happen? Can you narrow the behaviour down to a specific pattern? Once it freezes, break into ddb and see what's running. What is the machine doing during the freeze? Submit a bug report. :) Yes, yes... But usually it freezes to death, console not responding, so no ddb, no reports... My box freezes. This is the dmesg. This is what I do with it. I can't enter ddb because my machine doesn't respond to my method of entering ddb. I tried this and this and this other thing with these results. Please help. Something along those lines? We want complete bug reports. That also means that, if we ask for something you can't provide, you tell us that (and why, because it's another symptom). Please consider that you are submitting a diff, solving a problem, that we currently don't see as a problem. The whole kernel is filled with panics that never happen. And this isn't a panic, it's a warning. Look at the code. The warning message is printed, but a new entry was allocated succesfully. If it wasn't, you'd have paniced instead. You're not panicing, these are not the droids you're looking for. You are the only person I know of that has machines freezing because of kentry pressure, assuming it is indeed related... Yes, again. I'm not 100% sure that it is because of kentries pressure, but it was a signal. So put that in the bug report. Of course. But it is completely predictable, not fatal (if we talk about kernel stability). Predictable != non-fatal. So what? Predictable states are much easier to repeat, trace and debug than random states. Running out of map entries is always fatal. We need to have them to be able to create them. Oh... This is exactly what I try to avoid. If 1 kentry remain - allocate more. If can't - return it back, may be next try will success. And we are talking about kernel memory allocations, yes? It's all related to maps with VM_MAP_INTRSAFE flag. For every magic value, users will prove its the wrong value. Are you about sysctl or VM_MAP_INTRSAFE flag? Size of the map. Whichever size you choose, it'll be wrong. BTW, there are many sysctl values, in misc@ we can see that users play with them in a very strange ways. Making their system unusable. So what? Remove that? Proving that knobification is generally a bad thing. I disagree with the idea itself. Where I mean the kentry map. I disagree with the kentry map. As far as I can tell, that is the main idea behind your diff. The real problem is an architectural one. Ok, I got it. I hear same again and again, but did not hear that someone discussed the design new architecture, so the ideas gets The architecture in this case being kernel memory defaulting to pageable, non-intr-safe memory, that we can't allocate memory in the allocator. :) Looks like you mean to say to leave it, and try to be happy with amd64. Sad... You can always switch to sparc64. ;) You're not fixing the issue, you're moving it somewhere else. When kentry map runs out of space, things die (whereas currently, they only complain loudly). Your diff limits the
Caterer's Warehouse Daily Special
If you are having trouble viewing this e-mail, Visit www.catererswarehouse.com Caterer's Warehouse Weekly Specials Caterer's Warehouse Special Offers Home | Catering Supplies | Restaurant Equipment | Tabletop Specialties Bakery Supplies | Bar Supplies | Kitchen Supplies | Commercial Furniture | Hot Deals Valid 4/19/2011 Caterer's Warehouse Hot Deal Items This offer cannot be combined with any other promotional offers, flyers, discounted prices, coupons, or specials. Live Chat Find Us On FacebookFind Us On Facebook Follow Us On TwitterFollow Us On Twitter Share With FriendsShare With Friends [IMAGE] Contact Us 1-800-858-4255 If you would like to discontinue receiving our e-mails, click here www.catererswarehouse.com * 1030A Stafford St, Box 400 * Rochdale, MA 01542 [IMAGE]
Re: Add MDNS lookup for libc.
Keeping this up.
On 19 March 2011 22:35, Christiano F. Haesbaert haesba...@haesbaert.org
wrote:
Whoops, I made some last time changes which broke big-endian systems,
spotted by
Mattew.
Index: net/getaddrinfo.c
===
RCS file: /cvs/src/lib/libc/net/getaddrinfo.c,v
retrieving revision 1.71
diff -d -u -p -w -r1.71 getaddrinfo.c
--- net/getaddrinfo.c 18 Nov 2009 07:43:22 - 1.71
+++ net/getaddrinfo.c 20 Mar 2011 01:32:16 -
@@ -235,6 +235,8 @@ static int res_searchN(const char *, str
static int res_querydomainN(const char *, const char *, struct res_target
*);
static struct addrinfo *_dns_getaddrinfo(const char *, const struct
addrinfo *,
const struct __res_state *);
+static struct addrinfo *_mcast_getaddrinfo(const char *,
+const struct addrinfo *, const struct __res_state *);
/* XXX macros that make external reference is BAD. */
@@ -523,6 +525,9 @@ explore_fqdn(const struct addrinfo *pai,
case 'f':
result = _files_getaddrinfo(hostname, pai);
break;
+ case 'm':
+ result = _mcast_getaddrinfo(hostname, pai, _resp);
+ break;
}
}
_THREAD_PRIVATE_MUTEX_UNLOCK(_explore_mutex);
@@ -1209,6 +1214,99 @@ _dns_getaddrinfo(const char *name, const
free(buf);
free(buf2);
return NULL;
+ }
+ ai = getanswer(buf, q.n, q.name, q.qtype, pai);
+ if (ai) {
+ cur-ai_next = ai;
+ while (cur cur-ai_next)
+ cur = cur-ai_next;
+ }
+ if (q.next) {
+ ai = getanswer(buf2, q2.n, q2.name, q2.qtype, pai);
+ if (ai)
+ cur-ai_next = ai;
+ }
+ free(buf);
+ free(buf2);
+ return sentinel.ai_next;
+}
+
+static struct addrinfo *
+_mcast_getaddrinfo(const char *name, const struct addrinfo *pai,
+const struct __res_state *_resp)
+{
+ struct addrinfo *ai;
+ querybuf *buf, *buf2;
+ struct addrinfo sentinel, *cur;
+ struct res_target q, q2;
+
+ memset(q, 0, sizeof(q));
+ memset(q2, 0, sizeof(q2));
+ memset(sentinel, 0, sizeof(sentinel));
+ cur = sentinel;
+
+ buf = malloc(sizeof(*buf));
+ if (buf == NULL) {
+ h_errno = NETDB_INTERNAL;
+ return NULL;
+ }
+ buf2 = malloc(sizeof(*buf2));
+ if (buf2 == NULL) {
+ free(buf);
+ h_errno = NETDB_INTERNAL;
+ return NULL;
+ }
+
+ switch (pai-ai_family) {
+ case AF_UNSPEC:
+ /* respect user supplied order */
+ q.qclass = C_IN;
+ q.qtype = (_resp-family[0] == AF_INET6) ? T_ : T_A;
+ q.answer = buf-buf;
+ q.anslen = sizeof(buf-buf);
+ q.next = q2;
+
+ if (_resp-family[1] == -1) {
+ /* stop here if only one family was given */
+ q.next = NULL;
+ break;
+ }
+
+ q2.qclass = C_IN;
+ q2.qtype = (_resp-family[1] == AF_INET6) ? T_ : T_A;
+ q2.answer = buf2-buf;
+ q2.anslen = sizeof(buf2-buf);
+ break;
+ case AF_INET:
+ q.qclass = C_IN;
+ q.qtype = T_A;
+ q.answer = buf-buf;
+ q.anslen = sizeof(buf-buf);
+ break;
+ case AF_INET6:
+ q.qclass = C_IN;
+ q.qtype = T_;
+ q.answer = buf-buf;
+ q.anslen = sizeof(buf-buf);
+ break;
+ default:
+ free(buf);
+ free(buf2);
+ return NULL;
+ }
+ if ((q.n = res_search_mcast(name,
+ q.qclass, q.qtype, q.answer, q.anslen)) 0) {
+ free(buf);
+ free(buf2);
+ return (NULL);
+ }
+ if (q.next != NULL) {
+ if ((q2.n = res_search_mcast(name,
+ q2.qclass, q2.qtype, q2.answer, q2.anslen)) 0) {
+ free(buf);
+ free(buf2);
+ return (NULL);
+ }
}
ai = getanswer(buf, q.n, q.name, q.qtype, pai);
if (ai) {
Index: net/gethostnamadr.c
===
RCS file: /cvs/src/lib/libc/net/gethostnamadr.c,v
retrieving revision 1.73
diff -d -u -p -w -r1.73 gethostnamadr.c
--- net/gethostnamadr.c 18 Nov 2009 07:43:22 - 1.73
+++ net/gethostnamadr.c 20 Mar 2011 01:32:16 -
@@ -606,6 +606,7 @@ gethostbyname2(const char *name, int af)
hp = (struct hostent
eliminate gdt(4) raw_scsi mode
gdt(4) man page says 'transparent raw SCSI mode' is unsupported.
The code just returns errors to any attempts to submit i/o. I'm
pretty sure nobody is going to add support so eliminate the framework
for it.
Shrinks the iopool diff.
Any dissenting voices?
Ken
Index: share/man/man4/gdt.4
===
RCS file: /cvs/src/share/man/man4/gdt.4,v
retrieving revision 1.30
diff -u -p -r1.30 gdt.4
--- share/man/man4/gdt.41 Apr 2011 19:13:58 - 1.30
+++ share/man/man4/gdt.419 Apr 2011 13:50:43 -
@@ -145,7 +145,7 @@ inspired by the Linux driver by
.Sh BUGS
An ISA EISA front-end is needed.
.Pp
-The driver does not yet support transparent raw SCSI mode.
+The driver does not support transparent raw SCSI mode.
.Pp
It would be nice to configure the RAID units after boot
but the information on how to do that is not public.
Index: sys/dev/ic/gdt_common.c
===
RCS file: /cvs/src/sys/dev/ic/gdt_common.c,v
retrieving revision 1.55
diff -u -p -r1.55 gdt_common.c
--- sys/dev/ic/gdt_common.c 12 Oct 2010 00:53:32 - 1.55
+++ sys/dev/ic/gdt_common.c 19 Apr 2011 13:50:44 -
@@ -82,7 +82,6 @@ int gdt_ioctl_disk(struct gdt_softc *, s
intgdt_ioctl_alarm(struct gdt_softc *, struct bioc_alarm *);
intgdt_ioctl_setstate(struct gdt_softc *, struct bioc_setstate *);
#endif /* NBIO 0 */
-void gdt_raw_scsi_cmd(struct scsi_xfer *);
void gdt_scsi_cmd(struct scsi_xfer *);
void gdt_start_ccbs(struct gdt_softc *);
intgdt_sync_event(struct gdt_softc *, int, u_int8_t,
@@ -99,10 +98,6 @@ struct scsi_adapter gdt_switch = {
gdt_scsi_cmd, gdtminphys, 0, 0,
};
-struct scsi_adapter gdt_raw_switch = {
- gdt_raw_scsi_cmd, gdtminphys, 0, 0,
-};
-
int gdt_cnt = 0;
u_int8_t gdt_polling;
u_int8_t gdt_from_wait;
@@ -484,26 +479,6 @@ gdt_attach(struct gdt_softc *sc)
config_found(sc-sc_dev, saa, scsiprint);
- sc-sc_raw_link = malloc(sc-sc_bus_cnt * sizeof (struct scsi_link),
- M_DEVBUF, M_NOWAIT | M_ZERO);
- if (sc-sc_raw_link == NULL)
- panic(gdt_attach);
-
- for (i = 0; i sc-sc_bus_cnt; i++) {
- /* Fill in the prototype scsi_link. */
- sc-sc_raw_link[i].adapter_softc = sc;
- sc-sc_raw_link[i].adapter = gdt_raw_switch;
- sc-sc_raw_link[i].adapter_target = 7;
- sc-sc_raw_link[i].openings = 4;/* XXX a guess */
- sc-sc_raw_link[i].adapter_buswidth =
- (sc-sc_class GDT_FC) ? GDT_MAXID : 16; /* XXX */
-
- bzero(saa, sizeof(saa));
- saa.saa_sc_link = sc-sc_raw_link[i];
-
- config_found(sc-sc_dev, saa, scsiprint);
- }
-
gdt_polling = 0;
return (0);
}
@@ -987,43 +962,6 @@ gdt_internal_cache_cmd(struct scsi_xfer
}
xs-error = XS_NOERROR;
-}
-
-/* Start a raw SCSI operation */
-void
-gdt_raw_scsi_cmd(struct scsi_xfer *xs)
-{
- struct scsi_link *link = xs-sc_link;
- struct gdt_softc *sc = link-adapter_softc;
- struct gdt_ccb *ccb;
- int s;
-
- GDT_DPRINTF(GDT_D_CMD, (gdt_raw_scsi_cmd ));
-
- if (xs-cmdlen 12 /* XXX create #define */) {
- GDT_DPRINTF(GDT_D_CMD, (CDB too big %p , xs));
- bzero(xs-sense, sizeof(xs-sense));
- xs-sense.error_code = SSD_ERRCODE_VALID | SSD_ERRCODE_CURRENT;
- xs-sense.flags = SKEY_ILLEGAL_REQUEST;
- xs-sense.add_sense_code = 0x20; /* illcmd, 0x24 illfield */
- xs-error = XS_SENSE;
- scsi_done(xs);
- return;
- }
-
- if ((ccb = gdt_get_ccb(sc, xs-flags)) == NULL) {
- GDT_DPRINTF(GDT_D_CMD, (no ccb available for %p , xs));
- xs-error = XS_DRIVER_STUFFUP;
- scsi_done(xs);
- return;
- }
-
- xs-error = XS_DRIVER_STUFFUP;
- s = splbio();
- scsi_done(xs);
- gdt_free_ccb(sc, ccb);
-
- splx(s);
}
void
Index: sys/dev/ic/gdtvar.h
===
RCS file: /cvs/src/sys/dev/ic/gdtvar.h,v
retrieving revision 1.17
diff -u -p -r1.17 gdtvar.h
--- sys/dev/ic/gdtvar.h 12 Aug 2009 17:51:33 - 1.17
+++ sys/dev/ic/gdtvar.h 19 Apr 2011 13:50:44 -
@@ -268,7 +268,6 @@ struct gdt_softc {
struct device sc_dev;
void *sc_ih;
struct scsi_link sc_link; /* Virtual SCSI bus for cache devs */
- struct scsi_link *sc_raw_link; /* Raw SCSI busses */
int sc_class; /* Controller class */
#define GDT_ISA0x01
I am an idiot in km_alloc
Free the correct memory when we failed to allocate va.
//art
Index: uvm/uvm_km.c
===
RCS file: /cvs/src/sys/uvm/uvm_km.c,v
retrieving revision 1.97
diff -u -r1.97 uvm_km.c
--- uvm/uvm_km.c18 Apr 2011 19:23:46 - 1.97
+++ uvm/uvm_km.c19 Apr 2011 15:46:45 -
@@ -928,7 +928,8 @@
while (uvm_km_pages.free == 0) {
if (kd-kd_waitok == 0) {
mtx_leave(uvm_km_pages.mtx);
- uvm_pagefree(pg);
+ if (!TAILQ_EMPTY(pgl))
+ uvm_pglistfree(pgl);
return NULL;
}
msleep(uvm_km_pages.free, uvm_km_pages.mtx, PVM,
@@ -961,6 +962,8 @@
tsleep(map, PVM, km_allocva, 0);
goto try_map;
}
+ if (!TAILQ_EMPTY(pgl))
+ uvm_pglistfree(pgl);
return (NULL);
}
}
Re: I am an idiot in km_alloc
On Tue, Apr 19, 2011 at 09:49:43AM -0600, Artur Grabowski wrote:
Free the correct memory when we failed to allocate va.
ok ariane@
Index: uvm/uvm_km.c
===
RCS file: /cvs/src/sys/uvm/uvm_km.c,v
retrieving revision 1.97
diff -u -r1.97 uvm_km.c
--- uvm/uvm_km.c 18 Apr 2011 19:23:46 - 1.97
+++ uvm/uvm_km.c 19 Apr 2011 15:46:45 -
@@ -928,7 +928,8 @@
while (uvm_km_pages.free == 0) {
if (kd-kd_waitok == 0) {
mtx_leave(uvm_km_pages.mtx);
- uvm_pagefree(pg);
+ if (!TAILQ_EMPTY(pgl))
+ uvm_pglistfree(pgl);
return NULL;
}
msleep(uvm_km_pages.free, uvm_km_pages.mtx, PVM,
@@ -961,6 +962,8 @@
tsleep(map, PVM, km_allocva, 0);
goto try_map;
}
+ if (!TAILQ_EMPTY(pgl))
+ uvm_pglistfree(pgl);
return (NULL);
}
}
--
Ariane
Re: diff: get rid the out of static map entries problem
2011/4/19 Ariane van der Steldt ari...@stack.nl: You now have feedback. People don't like your diff, told you why. You now have options: You didn't get negative feedback on the reserved entry. It works for your map, maybe it'll also work for the kernel_map? Most comments here are against the kentry map. We don't like how it isn't dynamic. Look at the rejection arguments and distill where you need to improve your idea. I got it, I see the weak parts. Thanks for your encouragement. And tedu@ for the discussion. I'll try to see from the other side. -- antonvm
Re: I am an idiot in km_alloc
works for me.
On 2011/04/19 09:49, Artur Grabowski wrote:
Free the correct memory when we failed to allocate va.
//art
Index: uvm/uvm_km.c
===
RCS file: /cvs/src/sys/uvm/uvm_km.c,v
retrieving revision 1.97
diff -u -r1.97 uvm_km.c
--- uvm/uvm_km.c 18 Apr 2011 19:23:46 - 1.97
+++ uvm/uvm_km.c 19 Apr 2011 15:46:45 -
@@ -928,7 +928,8 @@
while (uvm_km_pages.free == 0) {
if (kd-kd_waitok == 0) {
mtx_leave(uvm_km_pages.mtx);
- uvm_pagefree(pg);
+ if (!TAILQ_EMPTY(pgl))
+ uvm_pglistfree(pgl);
return NULL;
}
msleep(uvm_km_pages.free, uvm_km_pages.mtx, PVM,
@@ -961,6 +962,8 @@
tsleep(map, PVM, km_allocva, 0);
goto try_map;
}
+ if (!TAILQ_EMPTY(pgl))
+ uvm_pglistfree(pgl);
return (NULL);
}
}
tcp support for aucat and midicat
This diffs enables aucat and midicat to work over TCP, which allows a
sound card to be shared between machines, doing strange things with
ssh port forwarding and so on.
Roughly, the first client generates a 128-bit random number (aka the
session cookie), saves it in $HOME/.aucat_cookie and sends it to the
server. Successive clients load the cookie from $HOME/.aucat_cookie
and send it to the server but the server accepts only clients whose
cookie matches the session cookie. When all clients are gone, the
session is over, and another cookie could start a new session, and so
on. Nothing new so far, aucat always used to work this way, except
that it used uids returned by getpeereid() as cookies.
This gives a simple workaround for the _mpd problem, when the user
has two uids that used not to be allowed to share the audio
session. Now the user could simply copy the cookie to all of his uids.
Hostnames are specified with a new optional component in the device
name, and TCP is enabled in the server with the new -L option; see
sndio(7) and aucat(1) for hints.
Example of network setup:
On foo.domain.com do:
aucat -L0.0.0.0
On bar.domain.com do:
export AUDIODEVICE=aucat:foo.domain.com/0
mpg321 /music/myfile.mp3
Example for mpd-style setup: start mpd as _mpd from /etc/rc or
whatever and then steal its cookie:
cp ~_mpd/.aucat_cookie ~/
chown joe:joe .aucat_cookie
mplayer /whatever.avi
-- Alexandre
Index: lib/libsndio/aucat.c
===
RCS file: /cvs/src/lib/libsndio/aucat.c,v
retrieving revision 1.45
diff -u -p -r1.45 aucat.c
--- lib/libsndio/aucat.c18 Apr 2011 23:57:35 - 1.45
+++ lib/libsndio/aucat.c19 Apr 2011 17:27:31 -
@@ -17,10 +17,15 @@
#include sys/types.h
#include sys/socket.h
+#include sys/stat.h
#include sys/un.h
+#include netinet/in.h
+#include netdb.h
+
#include errno.h
#include fcntl.h
+#include limits.h
#include poll.h
#include stdio.h
#include stdlib.h
@@ -30,6 +35,10 @@
#include aucat.h
#include debug.h
+#ifndef DEV_RANDOM
+#define DEV_RANDOM /dev/arandom
+#endif
+
/*
* read a message, return 0 if not completed
*/
@@ -192,6 +201,149 @@ aucat_wdata(struct aucat *hdl, const voi
}
int
+aucat_gencookie(unsigned char *cookie)
+{
+ int fd;
+ ssize_t n, len;
+
+ fd = open(DEV_RANDOM, O_RDONLY);
+ if (fd 0) {
+ DPERROR(DEV_RANDOM);
+ return 0;
+ }
+ len = AMSG_COOKIELEN;
+ while (len 0) {
+ n = read(fd, cookie, AMSG_COOKIELEN);
+ if (n 0) {
+ DPERROR(DEV_RANDOM);
+ close(fd);
+ return 0;
+ }
+ if (n == 0) {
+ close(fd);
+ return 0;
+ }
+ cookie += n;
+ len -= n;
+ }
+ close(fd);
+ return 1;
+}
+
+void
+aucat_savecookie(char *path, unsigned char *cookie)
+{
+ int fd;
+
+ fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, 0600);
+ if (fd 0) {
+ DPERROR(path);
+ return;
+ }
+ if (write(fd, cookie, AMSG_COOKIELEN) 0) {
+ DPERROR(path);
+ return;
+ }
+ close(fd);
+}
+
+int
+aucat_loadcookie(unsigned char *cookie)
+{
+ struct stat sb;
+ char buf[PATH_MAX], *path;
+ int fd, len, res;
+
+ path = issetugid() ? NULL : getenv(AUCAT_COOKIE);
+ if (path == NULL) {
+ path = issetugid() ? NULL : getenv(HOME);
+ if (path == NULL)
+ goto bad_gen;
+ snprintf(buf, PATH_MAX, %s/.aucat_cookie, path);
+ path = buf;
+ }
+ fd = open(path, O_RDONLY);
+ if (fd 0) {
+ if (errno != ENOENT)
+ DPERROR(path);
+ goto bad_gen;
+ }
+ if (fstat(fd, sb) 0) {
+ DPERROR(path);
+ goto bad_close;
+ }
+ if (sb.st_mode 0077) {
+ DPRINTF(%s has wrong permissions\n, path);
+ goto bad_close;
+ }
+ len = read(fd, cookie, AMSG_COOKIELEN);
+ if (len 0) {
+ DPERROR(path);
+ goto bad_close;
+ }
+ if (len != AMSG_COOKIELEN) {
+ DPRINTF(%s: short read\n, path);
+ goto bad_close;
+ }
+ close(fd);
+ return 1;
+bad_close:
+ close(fd);
+bad_gen:
+ res = aucat_gencookie(cookie);
+ if (path != NULL)
+ aucat_savecookie(path, cookie);
+ return res;
+}
+
+int
+aucat_connect_tcp(struct aucat *hdl, char *host, char *unit, int isaudio)
+{
+ int s, error;
+ struct addrinfo *ailist, *ai, aihints;
+ unsigned port;
+ char serv[NI_MAXSERV];
pmap_update() in km_alloc()
pmap(9) says pmap_update() 'must' be called after pmap_kenter_pa()... ok? Index: uvm_km.c === RCS file: /cvs/src/sys/uvm/uvm_km.c,v retrieving revision 1.97 diff -u -p uvm_km.c --- uvm_km.c18 Apr 2011 19:23:46 - 1.97 +++ uvm_km.c19 Apr 2011 17:57:18 - @@ -973,6 +973,7 @@ try_map: pmap_kenter_pa(va, VM_PAGE_TO_PHYS(pg), prot); va += PAGE_SIZE; } + pmap_update(pmap_kernel()); return ((void *)sva); }
Sanex Exprees İle Kargolar Bir Günde Rusya'da
Sanex Express SANEX CARGO D0le Paketler Ertesi GCn RUSYA 'da Rusya ya Gidecek Zarf ve Paketler Saat 18.00'e Kadar Sanex Expressbe VerildiD inde Teslimat Ertesi GCn YapD1lD1yor. Sanex Express ZamanD1nda TeslimatD1 Garanti Ediyor. RUSYA kaynaklD1 Sanex Express, Rusya'da 3 Merkez Ofis,16 acentasD1yla, hizmet veriyor. Sanex Express gC6nderiyle Rusya'nD1n her yerine en kD1sa zamanda ulaE D1yor. GC6nderilerin tCm gCmrCkleme iE lemlerini de sanex Express yapD1yor. CrneD in D0stanbul'dan saat 18.00'de Sanex Express kuryesine mCE terinin adresinden teslim edilen gC6nderiler Russia,Ukrayna ,Beyaz Rusya, Moldova, Azerbaycan, Turkmenistan, Kazakistan, KD1rgD1zD1stan, GCrcistan, Ermenistan, Bulgaristan ve Romanya gibi Clkelerin genelinde alD1cD1lara bir iE gCnCnde, adresinde imza karE D1lD1D D1 teslim ediliyor. Takip sistemi ile mCE teri gC6nderinin saat kaC'ta kime teslim edildiD i bilgisini MCE teri hizmetlerinbden (0090 212 474 65 65) Nolu Telefon'dan C6D renebiliyor. Sanex Express'de her gCn dCzenli Avrupa uC'uE larD1nD1n yanD1sD1ra Rusya-Azerbaycan-Ukrayna,OrtadoD u,TCrk Cumhuriyetleri ve D0srail'e yaptD1D D1mD1z direkt uC'uE larla dCnya Czerinde 200'C aE kD1n noktaya gC6nderilerinizi tam bir gCven ve kalite ile belirttiD iniz adrese zamanD1nda teslim ediyoruz Sanex Express geleceD in dCnyasD1nda yerinizi almanD1z iC'in hizmet veriyor. TCm DCnya'ya taE D1nan numune ve dC6kCmanlara ek olarak, D0THALAT ve D0HRACAT amaC'lD1 gC6nderilerinize FORWARDER olarak hizmet vermektedir. Bu hizmeti 5 kD1tada 227 Clkeye ve KD1brD1s'a ulaE tD1rmaktadD1r. Hizmet NoktalarD1 : Offices: D0ngiltere, Almanya, Cin, Vietnam, Endonazya, Avustralya, Japonya, Tayvan, Tayland, Hong Kong, GCney Kore, BirleE ik Arap Emirlikleri, Irak, BangladeE , D0ran, Nepal Sri Lanka, Hindistan, Pakistan, Azerbaycan, Bulgaristan, Rusya, Ukranya, GCrcistan, Beyaz Rusya, Kazakistan, KD1rgD1zistan, Moldova, Tataristan, Yugoslavya, Cek Cumhuriyeti ,Bosna Hersek, Romanya, TCrkmenistan, SD1rbistan, Ermenistan, Polanya, Macaristan AMERD0KA_ AFRD0KA_ AVRUPA_ ASYA_ORTADOD U_UZAKDOD U SANEX EXPRESS LTD (TURKEY) Yenibosna Karayolu No:53 Yenibosna / D0stanbul Call Center: +90 212 474 65 65 Pbx +90 212 655 54 37 Gsm: (+90 507) 354 53 53
Re: pmap_update() in km_alloc()
On Tue, Apr 19, 2011 at 11:01:54AM -0700, Matthew Dempsky wrote: pmap(9) says pmap_update() 'must' be called after pmap_kenter_pa()... ok? Ok ariane@ Index: uvm_km.c === RCS file: /cvs/src/sys/uvm/uvm_km.c,v retrieving revision 1.97 diff -u -p uvm_km.c --- uvm_km.c 18 Apr 2011 19:23:46 - 1.97 +++ uvm_km.c 19 Apr 2011 17:57:18 - @@ -973,6 +973,7 @@ try_map: pmap_kenter_pa(va, VM_PAGE_TO_PHYS(pg), prot); va += PAGE_SIZE; } + pmap_update(pmap_kernel()); return ((void *)sva); } -- Ariane
significant speedups
In the last two weeks we have commited a few things which significantly speed up disk and network io. i will mention two things. some of you can start cranking the kern.bufcachepercent sysctl to 90. try it out. be impressed, but don't report deadlocks or lockups; however real crashes are worth knowing about. the lockup situations are largely understood and will be slowly worked out, which is why this is not close to being the default. the other change is that interrupt servicing times have gone down substantially. there are some broken drivers we will need to find and fix, so please watch your vmstat -i numbers carefully, and for this circumstance, if you get machine lockups at boot please report those very carefully in a PR (with an old working dmesg). thanks.
Re: eliminate gdt(4) raw_scsi mode
ok
On 20/04/2011, at 12:54 AM, Kenneth R Westerback wrote:
gdt(4) man page says 'transparent raw SCSI mode' is unsupported.
The code just returns errors to any attempts to submit i/o. I'm
pretty sure nobody is going to add support so eliminate the framework
for it.
Shrinks the iopool diff.
Any dissenting voices?
Ken
Index: share/man/man4/gdt.4
===
RCS file: /cvs/src/share/man/man4/gdt.4,v
retrieving revision 1.30
diff -u -p -r1.30 gdt.4
--- share/man/man4/gdt.4 1 Apr 2011 19:13:58 - 1.30
+++ share/man/man4/gdt.4 19 Apr 2011 13:50:43 -
@@ -145,7 +145,7 @@ inspired by the Linux driver by
.Sh BUGS
An ISA EISA front-end is needed.
.Pp
-The driver does not yet support transparent raw SCSI mode.
+The driver does not support transparent raw SCSI mode.
.Pp
It would be nice to configure the RAID units after boot
but the information on how to do that is not public.
Index: sys/dev/ic/gdt_common.c
===
RCS file: /cvs/src/sys/dev/ic/gdt_common.c,v
retrieving revision 1.55
diff -u -p -r1.55 gdt_common.c
--- sys/dev/ic/gdt_common.c 12 Oct 2010 00:53:32 - 1.55
+++ sys/dev/ic/gdt_common.c 19 Apr 2011 13:50:44 -
@@ -82,7 +82,6 @@ int gdt_ioctl_disk(struct gdt_softc *, s
int gdt_ioctl_alarm(struct gdt_softc *, struct bioc_alarm *);
int gdt_ioctl_setstate(struct gdt_softc *, struct bioc_setstate *);
#endif /* NBIO 0 */
-void gdt_raw_scsi_cmd(struct scsi_xfer *);
void gdt_scsi_cmd(struct scsi_xfer *);
void gdt_start_ccbs(struct gdt_softc *);
int gdt_sync_event(struct gdt_softc *, int, u_int8_t,
@@ -99,10 +98,6 @@ struct scsi_adapter gdt_switch = {
gdt_scsi_cmd, gdtminphys, 0, 0,
};
-struct scsi_adapter gdt_raw_switch = {
- gdt_raw_scsi_cmd, gdtminphys, 0, 0,
-};
-
int gdt_cnt = 0;
u_int8_t gdt_polling;
u_int8_t gdt_from_wait;
@@ -484,26 +479,6 @@ gdt_attach(struct gdt_softc *sc)
config_found(sc-sc_dev, saa, scsiprint);
- sc-sc_raw_link = malloc(sc-sc_bus_cnt * sizeof (struct scsi_link),
- M_DEVBUF, M_NOWAIT | M_ZERO);
- if (sc-sc_raw_link == NULL)
- panic(gdt_attach);
-
- for (i = 0; i sc-sc_bus_cnt; i++) {
- /* Fill in the prototype scsi_link. */
- sc-sc_raw_link[i].adapter_softc = sc;
- sc-sc_raw_link[i].adapter = gdt_raw_switch;
- sc-sc_raw_link[i].adapter_target = 7;
- sc-sc_raw_link[i].openings = 4;/* XXX a guess */
- sc-sc_raw_link[i].adapter_buswidth =
- (sc-sc_class GDT_FC) ? GDT_MAXID : 16; /* XXX */
-
- bzero(saa, sizeof(saa));
- saa.saa_sc_link = sc-sc_raw_link[i];
-
- config_found(sc-sc_dev, saa, scsiprint);
- }
-
gdt_polling = 0;
return (0);
}
@@ -987,43 +962,6 @@ gdt_internal_cache_cmd(struct scsi_xfer
}
xs-error = XS_NOERROR;
-}
-
-/* Start a raw SCSI operation */
-void
-gdt_raw_scsi_cmd(struct scsi_xfer *xs)
-{
- struct scsi_link *link = xs-sc_link;
- struct gdt_softc *sc = link-adapter_softc;
- struct gdt_ccb *ccb;
- int s;
-
- GDT_DPRINTF(GDT_D_CMD, (gdt_raw_scsi_cmd ));
-
- if (xs-cmdlen 12 /* XXX create #define */) {
- GDT_DPRINTF(GDT_D_CMD, (CDB too big %p , xs));
- bzero(xs-sense, sizeof(xs-sense));
- xs-sense.error_code = SSD_ERRCODE_VALID | SSD_ERRCODE_CURRENT;
- xs-sense.flags = SKEY_ILLEGAL_REQUEST;
- xs-sense.add_sense_code = 0x20; /* illcmd, 0x24 illfield */
- xs-error = XS_SENSE;
- scsi_done(xs);
- return;
- }
-
- if ((ccb = gdt_get_ccb(sc, xs-flags)) == NULL) {
- GDT_DPRINTF(GDT_D_CMD, (no ccb available for %p , xs));
- xs-error = XS_DRIVER_STUFFUP;
- scsi_done(xs);
- return;
- }
-
- xs-error = XS_DRIVER_STUFFUP;
- s = splbio();
- scsi_done(xs);
- gdt_free_ccb(sc, ccb);
-
- splx(s);
}
void
Index: sys/dev/ic/gdtvar.h
===
RCS file: /cvs/src/sys/dev/ic/gdtvar.h,v
retrieving revision 1.17
diff -u -p -r1.17 gdtvar.h
--- sys/dev/ic/gdtvar.h 12 Aug 2009 17:51:33 - 1.17
+++ sys/dev/ic/gdtvar.h 19 Apr 2011 13:50:44 -
@@ -268,7 +268,6 @@ struct gdt_softc {
struct device sc_dev;
void *sc_ih;
struct scsi_link sc_link; /* Virtual SCSI bus for cache devs */
- struct scsi_link *sc_raw_link; /* Raw SCSI busses */
int sc_class; /* Controller class */
#define GDT_ISA 0x01
isfdtype(3) man page bug
In the STANDARDS section, groff -Tascii -mandoc isfdtype.3 renders: The isfdtype() function is expected to conform to POSIX 1003.1g. whereas mandoc renders: The isfdtype() function is expected to conform to 1003.1g. The issue is isfdtype.3 uses a .Px macro that mandoc doesn't support. We could switch to using .St, but there's currently no 1003.1g .St entry, only 1003.1g-2000. But to my knowledge, isfdtype() isn't actually in 1003.1g-2000, and maybe not even in 1003.1g. (The little bit of history I've found is it was expected for inclusion in some spec, but then omitted.) Anyone want to suggest what the proper fix here is?
Re: automatically set the default console?
On Tue, Apr 19, 2011 at 12:21:57PM +0200, Peter Hessler wrote:
When I'm installing over a serial line, I would expect to use that as my
console in the future. This diff sets the default console to the one we
are currently using, so it's just another [enter]. (The style is based
on the xdm case immediately above)
OK?
I seem to recall proposing this when we added the auto speed
detection. I was shot down for reasons I no longer recall in detail.
Something to do with people building boxes en masse on a bench with
serial but wanting to deploy to racks with KVM. Or something.
Personally I still like the idea. :-)
The concern was over architectures which have more kinds of consoles.
sparc64, if I recall. It would need to be re-verified. I do not
remember the details, but have a vague memoru that this is what
stopped us before.
Don't fall into the everything is a PC trap.
Index: distrib/miniroot/install.sub
===
RCS file: /cvs/openbsd/src/distrib/miniroot/install.sub,v
retrieving revision 1.636
diff -u -p -r1.636 install.sub
--- distrib/miniroot/install.sub22 Mar 2011 19:20:15 - 1.636
+++ distrib/miniroot/install.sub5 Apr 2011 10:42:10 -
@@ -1895,9 +1895,11 @@ questions() {
xdm=$resp
fi
+ defcons=no
+ [[ -n $CONSOLE ]] defcons=yes
if [[ -n $CDEV ]]; then
_d=${CPROM:-$CDEV}
- ask_yn Change the default console to $_d?
+ ask_yn Change the default console to $_d? $defcons
defcons=$resp
if [[ $resp == y ]]; then
ask_which speed should $_d use \
--
You've been leading a dog's life. Stay off the furniture.
Re: significant speedups
On Tuesday, 19 April 2011, Theo de Raadt dera...@cvs.openbsd.org wrote: In the last two weeks we have commited a few things which significantly speed up disk and network io. B i will mention two things. some of you can start cranking the kern.bufcachepercent sysctl to 90. try it out. B be impressed, but don't report deadlocks or lockups; however real crashes are worth knowing about. B the lockup situations are largely understood and will be slowly worked out, which is why this is not close to being the default. the other change is that interrupt servicing times have gone down substantially. B there are some broken drivers we will need to find and fix, so please watch your vmstat -i numbers carefully, and for this circumstance, if you get machine lockups at boot please report those very carefully in a PR (with an old working dmesg). thanks. I've been cranking kern.bufcache to 90 since bob becks talk about hacking vfs a while back (video on YouTube) not experienced any issues, I've recently sent my thinkpad back for repair work where they replaced the CPU fan, on return I installed a new snapshot last week was surprised how fast the machine goes from booting to xdm. I had put this down to fan not working correctly previously but Im glad to hear it's changes in the os. Well done :) Sevan
Re: significant speedups
I've been cranking kern.bufcache to 90 since bob becks talk about hacking vfs a while back (video on YouTube) not experienced any issues, I've recently sent my thinkpad back for repair work where they replaced the CPU fan, on return I installed a new snapshot last week was surprised how fast the machine goes from booting to xdm. I had put this down to fan not working correctly previously but Im glad to hear it's changes in the os. No, we fixed your fan too. We have people everywhere.
Last minute Aprile a Chianciano
B AUGURI DI UNA FELICE E SERENA PASQUA Un regalo da Hermitage LAST MINUTE Nello splendido scenario delle Colline Senesi 3 GIORNI 2 NOTTI EURO 79.00 SERVIZI INCLUSI: Camera doppia o matrimoniale con servizi privati, tv color, telefono diretto . 1 Sola notte Euro 49.00 Camera doppia o matrimoniale con servizi privati, tv color, telefono diretto APRILE DAL 18 AL 21 O DAL 25 AL 28 ( http://www.hermitagehotel.it/ ) ( http://www.hermitagehotel.it/ ) Escursioni in partenza da Chianciano Terme: Montepulciano, Pienza, Monticchiello, Cortona, Val DbOrcia, San Quirico DbOrcia, Montalcino, Bagni Vignoni, San Casciano dei Bagni, Abbadia di Monte Oliveto Maggiore, Siena, San Gimignano, Arezzo, Firenze, Roma, CittC della Pieve, Orvieto, Perugia, Assisi, Lago Trasimeno. Trattamenti termali-benessere per: b San Casciano dei Bagni, Bagni Vignoni, San Filippo, Montepulciano e Chianciano Termeb B Direzione Hermitage Hotel Info Booking: Hermitage Hotel Via P. Ingegnoli, 39 - 53042 Chianciano Terme (SI) Tel/Fax : 0578/62606 E-mail [demime 1.01d removed an attachment of type application/octet-stream which had a name of Week-end 2011.pdf]
CARP Compatibility
Hello, We have two openBSD installation a 4.6 and 4.8 we setup CARP between the two machines, but things are not working properly. On the internal side of the network we have this (ifconfig -A): Router 1 carp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:00:5e:00:01:01 priority: 0 carp: MASTER carpdev em1 vhid 1 advbase 1 advskew 100 groups: carp Router 2 carp0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 lladdr 00:00:5e:00:01:01 priority: 0 carp: INIT carpdev em1 vhid 1 advbase 1 advskew 0 groups: carp while on the external side we have : Router 1 carp1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:00:5e:00:01:02 priority: 0 carp: MASTER carpdev em0 vhid 2 advbase 1 advskew 100 groups: carp Router 2 carp1: flags=8803UP,BROADCAST,SIMPLEX,MULTICAST mtu 1500 lladdr 00:00:00:00:00:00 priority: 0 carp: INIT carpdev none vhid 2 advbase 1 advskew 0 groups: carp We turned off carp0. As you can see things are messed up. Does that have something to do with different openBSD versions?? Does anyone had the same issues, as the interface that is meant to be BACKUP is the MASTER. Thanks. -- Abbass MAROUNI Internet Memory Foundation internetmemory.org
namespace.h
hi, where is a listing of all functions implemented in openbsd's libc? Is src/lib/libc/include/namespace.h consist of functions not implemented or its a relic? i was looking for the equivalent of FreeBSD's file of the same name and location but in OpenBSD. thanks, amit
