machdep.hlt_cpus not safe with ULE?
I'm trying to debug a possibly failing CPU, so I thought it would be easy just disable the cores using machdep.hlt_cpus and see if we see the panic's we've been seeing. The problem is it seems ULE doesnt properly support machdep.hlt_cpus and still schedules processes onto the halted cpus which obviously causes problems. Can anyone confirm this behaviour? Should machdep.hlt_cpus and I assume the logical counterpart never be used with ULE? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: machdep.hlt_cpus not safe with ULE?
On Sat, 19 Feb 2011 12:36:57 - Steven Hartland kill...@multiplay.co.uk wrote: I'm trying to debug a possibly failing CPU, so I thought it would be easy just disable the cores using machdep.hlt_cpus and see if we see the panic's we've been seeing. The problem is it seems ULE doesnt properly support machdep.hlt_cpus and still schedules processes onto the halted cpus which obviously causes problems. Can anyone confirm this behaviour? Should machdep.hlt_cpus and I assume the logical counterpart never be used with ULE? Looking at the kernel source it appears that only sched_4bsd.c makes use of hlt_cpus_mask. -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: machdep.hlt_cpus not safe with ULE?
- Original Message - From: Gary Jennejohn gljennj...@googlemail.com Looking at the kernel source it appears that only sched_4bsd.c makes use of hlt_cpus_mask. Given ULE is default do these need to be either removed totally or at least conditionally based on the scheduler choice as currently they are quite dangerous to a systems health? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] nmount ro, rw and negated option handling
On 2011-01-25, Jaakko Heinonen wrote:
Another related bug is in vfs_domount_update(): if VFS_MOUNT() succeeds
but vfs_export() fails, old mount flags and options are restored. I
think this shouldn't happen when VFS_MOUNT() has been already
successfully completed and this is the final reason why FFS fs_ronly and
the MNT_RDONLY flag get out of sync. Does the patch below look sane?
%%%
Index: sys/kern/vfs_mount.c
===
--- sys/kern/vfs_mount.c (revision 217792)
+++ sys/kern/vfs_mount.c (working copy)
I have committed an updated version as r218852.
Unless there are objections, I plan to commit something like this next:
Recognize ro, rdonly, norw, rw and noro as equal options in
vfs_equalopts(). This allows vfs_sanitizeopts() to filter redundant
occurrences of these options. It was possible that for example both ro
and rw options became active concurrently.
PR: kern/133614
%%%
Index: sys/kern/vfs_mount.c
===
--- sys/kern/vfs_mount.c(revision 218446)
+++ sys/kern/vfs_mount.c(working copy)
@@ -175,6 +175,27 @@ vfs_deleteopt(struct vfsoptlist *opts, c
}
}
+static int
+vfs_isopt_ro(const char *opt)
+{
+
+ if (strcmp(opt, ro) == 0 || strcmp(opt, rdonly) == 0 ||
+ strcmp(opt, norw) == 0)
+ return (1);
+ else
+ return (0);
+}
+
+static int
+vfs_isopt_rw(const char *opt)
+{
+
+ if (strcmp(opt, rw) == 0 || strcmp(opt, noro) == 0)
+ return (1);
+ else
+ return (0);
+}
+
/*
* Check if options are equal (with or without the no prefix).
*/
@@ -203,6 +224,11 @@ vfs_equalopts(const char *opt1, const ch
if (strncmp(opt2, no, 2) == 0 strcmp(opt1, opt2 + 2) == 0)
return (1);
}
+ /* ro / rdonly / norw / rw / noro */
+ if ((vfs_isopt_ro(opt1) || vfs_isopt_rw(opt1))
+ (vfs_isopt_ro(opt2) || vfs_isopt_rw(opt2)))
+ return (1);
+
return (0);
}
%%%
--
Jaakko
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: machdep.hlt_cpus not safe with ULE?
For reference I've found that an alternative is to set the following in loader.conf:- hint.lapic.2.disabled=1 hint.lapic.3.disabled=1 2 and 3 here are the apic numbers displayed by dmesg on boot for the cpu's Obviously this requires a reboot so no perfect for all uses but it does work for what we're testing. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Can vm_mmap()/vm_map_remove() be called with giant held? (linuxolator dvb patches)
On Fri, Feb 18, 2011 at 09:55:42PM +0100, Juergen Lock wrote:
I have finally got back to this and did the style and vm_map_remove()
return value handling fixes, updated the patches in-place:
http://people.freebsd.org/~nox/dvb/linux-dvb.patch
(for head)
http://people.freebsd.org/~nox/dvb/linux-dvb-8.patch
(for 8.)
On Sun, Jan 30, 2011 at 12:54:48AM +0100, Juergen Lock wrote:
On Sat, Jan 29, 2011 at 10:51:05PM +0200, Kostik Belousov wrote:
On Sat, Jan 29, 2011 at 09:10:00PM +0100, Juergen Lock wrote:
Hi!
I was kinda hoping to be able to post a correct patch in public but
getting an answer to ${Subject} seems to be more difficult than I
thought... :) So, does anyone here know? copyout_map() and
You do not need Giant locked for vm_map* functions.
The question was more do I need to drop it first before calling them...
copyout_unmap() are copied from ksyms_map() from sys/dev/ksyms/ksyms.c
- should there maybe be global versions instead of two static copies
each, and what would be good names? And giant is taken by linux_ioctl()
Would you make a patch for this ?
Heh if you want me to... Where should they go and are my name choices ok?
I haven't done this yet so people can keep patching linux.ko in-place
without having to build a new kernel too...
Separate build of linux.ko is not quite supported action. I would greatly
prefer to have the move of these two functions before the rest of the
patch comes in. Together with conversion of other users.
I propose to put it into vm/vm_glue.c.
in the same source file before calling the parts I added. So here
comes the patch, it is to add support for dvb ioctls to the linuxolator
as discussed on -emulation earlier in this thread:
http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-January/011575.html
(patch also at:
http://people.freebsd.org/~nox/dvb/linux-dvb.patch
and a version for 8, which is what I tested with w_scan on dvb-s2
and dvb-t, and Andrew Gallatin also tested it with SageTV:
http://people.freebsd.org/~nox/dvb/linux-dvb-8.patch
)
+ /*
+* Map somewhere after heap in process memory.
+*/
+ PROC_LOCK(td-td_proc);
+ *addr = round_page((vm_offset_t)vms-vm_daddr +
+ lim_max(td-td_proc, RLIMIT_DATA));
+ PROC_UNLOCK(td-td_proc);
Are you sure that this is needed ? Why not leave the address selection
to the VM ?
I don't know, maybe sys/dev/ksyms/ksyms.c has a reason?
How would I leave the address selection to the VM? Just trying
to initialize *addr to (vm_offset_t)NULL there caused the patch to
stop working.
I believe you should do
*addr = 0;
vm_mmap(map, addr);
pgp2xDmVJigQs.pgp
Description: PGP signature
