Re: Reading in real time from a file without pipes
Matthew Hudson wrote: Mon Dec 11 09:08:37 PST 2006 c0re dumped wrote: I wonder if is possible to read data from a certain file without using a pipe. Let me explain: I have a process already writing messages to a logfile. I want to read all written data (without neither stop nor interfere normal log process) from another process in real time. How can I achieve it ? When on the command line, I do this using the program 'socat' (net/socat in ports). I.e. socat FILE:/var/log/messages,ignoreeof - This gives me the same sort of behavior as 'tail -f' except that it reads the entire file in first. I also use this when I'm say scp'ing over a really large tarball of text files and want to start looking at the files as they're coming in: * bigdir.tgz is a big tarball being scp'd over, 3 hours remaining * socat FILE:bigdir.tgz,ignoreeof - | gzip -dc | tar xf - & and just like that I now have bigdir.tgz being expanded in realtime without having to do anything that may have interfered with the scp (such as using ssh to run 'tee' on the remote host and do it that way. Wouldn't "tail -f +1" do the same thing? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/89528: [jail] impossible to kill a jail
* Coleman Kane <[EMAIL PROTECTED]> wrote: > Does this behavior still occur if you set sysctl kern.pts.enable=1 ? Well, I haven't tested that, but it should be fixed as well, because it also calls make_dev_cred(). > Is this at all related to why I have been experiencing zombies left behind > for any process that alloc's its own tty (such as gnome-terminal [actually > gnome-pty-helper])? If I CTRL-D to end a gnome-terminal session, it will > hang all of the gnome-terminals I have open and I typically have to reboot > to clear out the zombies that remain. I can't open any more apps that use > gnome-pty-helper to allocate ttys unless I attempt to kill it and start it > anew (and I am not even completely sure if that works). As far as I know, this is unrelated. The patch in my previous mail only fixes device node creation in jails. -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://g-rave.nl/ pgpxx2lu5Tc9F.pgp Description: PGP signature
Re: Reading in real time from a file without pipes
Mon Dec 11 09:08:37 PST 2006 c0re dumped wrote: > I wonder if is possible to read data from a > certain file without using a pipe. > > Let me explain: > > I have a process already writing messages to > a logfile. I want to read all written data > (without neither stop nor interfere normal > log process) from another process in real > time. > > How can I achieve it ? When on the command line, I do this using the program 'socat' (net/socat in ports). I.e. socat FILE:/var/log/messages,ignoreeof - This gives me the same sort of behavior as 'tail -f' except that it reads the entire file in first. I also use this when I'm say scp'ing over a really large tarball of text files and want to start looking at the files as they're coming in: * bigdir.tgz is a big tarball being scp'd over, 3 hours remaining * socat FILE:bigdir.tgz,ignoreeof - | gzip -dc | tar xf - & and just like that I now have bigdir.tgz being expanded in realtime without having to do anything that may have interfered with the scp (such as using ssh to run 'tee' on the remote host and do it that way. I know this isn't what you were asking since but I wanted to take the quick opportunity to brag about socat since I think it's the most powerful and useful utility that nobody seems to have heard about. More in line to what you're asking, I think the magic you're looking for is hinted to by the name of the option that socat uses, i.e. 'ignoreeof'. I'd surmise that all that socat and 'tail -f' are doing are reading until the end of a file and when they get a EOF, they simply wait a few milliseconds and try again. cheers -- Matthew Hudson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP initialisation changes 6.1-PRERELEASE and 6.1-RELEASE?
Steven Hartland wrote: This now panics in the initial hpt driver init with: panic: blocakble sleep lock ( sleep mutex ) 128 @ vm/uma_core.c: 1845 This looks to me like a seperate issue as the driver is aquiring a spinlock MTX_SPIN instead of MTX_DEF? I'm quite out of my depth at this point so any pointers would be really appreciated. Thanks to John Baldwin's patch for hptmv I'm now back at the stage where the machine hangs as during initialisation of the CPU's. I've got WITNESS, INVARIANTS, KDB and DDB installed but I cant break to the debugger as it seems to be totally wedged. If I break to the debugger earlier and continue it doesnt hang any ideas on how to proceed would be greatfully appreciated. 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 [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /bin/dd fails with big disks containing bad sectors
James Risner wrote: Hello, I filed this PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107443) and it was suggested I bring the issue to this list. If you have a defective disk larger than 2 gb with many bad sectors and attempt to use dd under FreeBSD to duplicate the disk, the operation will fail with sectors being out of alignment. dd bs=512 if=src of=dst conv=noerror,sync Under Linux, this operation performs as expected. There are faster methods of duplicating the disk (tools/recoverdisk is one.) But sometimes you only have /bin/dd and a fixit disk. It isn't intuitive that dd should fail in the way it is failing. The user (in this case me) doesn't expect to have a disk improperly aligned. I once resolved this issue several years ago with a patch to dd that is no long valid with current sources. I recently resolved this issue by writing my own tiny dd program (code is provided for curious people in the pr kern/107443) to properly copy the blocks. From what I can tell there are several requirements for this issue: 1) Disk > 2Gb 2) Disk has more than a few bad sectors. 3) Use dd to copy the disk. It seems despite using "sync", dd is getting confused as to the input and output seek position. They get out of sync with each other and all future output blocks are written earlier on the disk than is required. there is a tool in the tools directory (i forget the name) that is specifically for reading bad disks.. written by phk.. gets this right..along with various tricks to try get back more data. James Risner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/89528: [jail] impossible to kill a jail
On 1/4/07, Ed Schouten <[EMAIL PROTECTED]> wrote:
* Ed Schouten <[EMAIL PROTECTED]> wrote:
> As long as pty's have been allocated that have been created by threads
> in a jail, the prison structure has more references, causing the zombie
> jails to exist.
We could change the make_dev_credv() routine to crcopy() everything
except the prison when we're creating a node in a jail. The following
patch fixes the zombie jail bug on my machine:
--- src/sys/kern/kern_conf.cFri Oct 20 09:59:50 2006
+++ src/sys/kern/kern_conf.cThu Jan 4 21:36:44 2007
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -563,7 +564,15 @@
dev->si_flags |= SI_NAMED;
if (cr != NULL)
- dev->si_cred = crhold(cr);
+ if (cr->cr_prison == NULL) {
+ dev->si_cred = crhold(cr);
+ } else {
+ /* Don't let the node depend on a prison */
+ dev->si_cred = crget();
+ crcopy(dev->si_cred, cr);
+ prison_free(dev->si_cred->cr_prison);
+ dev->si_cred->cr_prison = NULL;
+ }
else
dev->si_cred = NULL;
dev->si_uid = uid;
Could other people experiencing this problem as well give this patch a
try? Thanks a lot!
Yours,
--
Ed Schouten <[EMAIL PROTECTED]>
WWW: http://g-rave.nl/
Does this behavior still occur if you set sysctl kern.pts.enable=1 ?
Is this at all related to why I have been experiencing zombies left behind
for any process that alloc's its own tty (such as gnome-terminal [actually
gnome-pty-helper])? If I CTRL-D to end a gnome-terminal session, it will
hang all of the gnome-terminals I have open and I typically have to reboot
to clear out the zombies that remain. I can't open any more apps that use
gnome-pty-helper to allocate ttys unless I attempt to kill it and start it
anew (and I am not even completely sure if that works).
--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/89528: [jail] impossible to kill a jail
* Ed Schouten <[EMAIL PROTECTED]> wrote:
> As long as pty's have been allocated that have been created by threads
> in a jail, the prison structure has more references, causing the zombie
> jails to exist.
We could change the make_dev_credv() routine to crcopy() everything
except the prison when we're creating a node in a jail. The following
patch fixes the zombie jail bug on my machine:
--- src/sys/kern/kern_conf.cFri Oct 20 09:59:50 2006
+++ src/sys/kern/kern_conf.cThu Jan 4 21:36:44 2007
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -563,7 +564,15 @@
dev->si_flags |= SI_NAMED;
if (cr != NULL)
- dev->si_cred = crhold(cr);
+ if (cr->cr_prison == NULL) {
+ dev->si_cred = crhold(cr);
+ } else {
+ /* Don't let the node depend on a prison */
+ dev->si_cred = crget();
+ crcopy(dev->si_cred, cr);
+ prison_free(dev->si_cred->cr_prison);
+ dev->si_cred->cr_prison = NULL;
+ }
else
dev->si_cred = NULL;
dev->si_uid = uid;
Could other people experiencing this problem as well give this patch a
try? Thanks a lot!
Yours,
--
Ed Schouten <[EMAIL PROTECTED]>
WWW: http://g-rave.nl/
pgpE6qzgtZxq9.pgp
Description: PGP signature
Re: kern/89528: [jail] impossible to kill a jail
Hello everyone, I decided to investigate this bug because I think the bug is quite irritating. After adding some ddb show commands to the source and reading a lot of code, I think I understand the problem: The tty code doesn't leak any ucreds, it's the devfs code that crhold()'s an ucred structure. When a new pty is needed, the tty_pty code allocates a new pty. It also runs make_dev_cred(), to which it passes the thread's ucred. This function calls make_dev_credv(), which finally runs crhold(). As long as pty's have been allocated that have been created by threads in a jail, the prison structure has more references, causing the zombie jails to exist. Yours, -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://g-rave.nl/ pgpswPIdLYTmc.pgp Description: PGP signature
Re: Init.c, making it chroot
John Baldwin wrote:
> Oliver Fromme wrote:
> > I've created (and tested!) a new patch. I've tested on
> > RELENG_6, but I think init(8) isn't very different on
> > HEAD, so it should work there, too.
> >
> > Any comments are welcome. I particularly appreciate
> > if others test this stuff.
>
> Some things I noticed:
>
> - Why do you have the 'ichroot_name' and 'iscript_name' variables? I would
> just pass the string literal to the kenv() function, e.g.
>
> if (kenv(KENV_GET, "init_script", kenv_value, sizeof(kenv_value)) > 0) {
>
> I think that putting the constant right there is easier for someone who
> is reading the code to see what is going on.
In fact that's what I tried first ... Alas:
warning: passing arg 2 of `kenv' discards qualifiers from pointer target type
> - Rather than abusing a global runcom_script variable that you change to
> get side effects when you invoke runcom(), why not change runcom() to
> take a single 'char *script' as an argument and just pass _PATH_RUNCOM
> or kenv_value as appropriate and get rid of the global runcom_script
> variable?
You are right, the global runcom_script variable does not
look very clean. However, the problem is that runcom() is
one of the transition action functions, i.e. it is called
by the transition() function and never gets an argument.
Of course it is possible to write an additional function
run_script(char *script) which contains runcom's current
code, and make the runcom() function a wrapper that just
calls run_script(_PATH_RUNCOM). This isn't a perfectly
clean solution either, but maybe it's at least a little bit
better.
e.g. basically:
state_func_t
runcom (void)
{
return run_script(_PATH_RUNCOM);
}
state_func_t
run_script (char *script)
{
/* all the code formerly in runcom() */
}
Then the init_script code would call run_script(kenv_value)
instead of runcom(), of course.
Would that be acceptable? Or do you have an even better
solution in mind?
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"If Java had true garbage collection, most programs
would delete themselves upon execution."
-- Robert Sewell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Init.c, making it chroot
On Thursday 04 January 2007 13:03, Oliver Fromme wrote:
>
> John Baldwin wrote:
> > Oliver Fromme wrote:
> > > I've created (and tested!) a new patch. I've tested on
> > > RELENG_6, but I think init(8) isn't very different on
> > > HEAD, so it should work there, too.
> > >
> > > Any comments are welcome. I particularly appreciate
> > > if others test this stuff.
> >
> > Some things I noticed:
> >
> > - Why do you have the 'ichroot_name' and 'iscript_name' variables? I
would
> > just pass the string literal to the kenv() function, e.g.
> >
> >if (kenv(KENV_GET, "init_script", kenv_value, sizeof(kenv_value)) > 0) {
> >
> > I think that putting the constant right there is easier for someone who
> > is reading the code to see what is going on.
>
> In fact that's what I tried first ... Alas:
> warning: passing arg 2 of `kenv' discards qualifiers from pointer target
type
It's fixed in HEAD, I'll MFC the prototype fix for kenv() to 6.x.
> > - Rather than abusing a global runcom_script variable that you change to
> > get side effects when you invoke runcom(), why not change runcom() to
> > take a single 'char *script' as an argument and just pass _PATH_RUNCOM
> > or kenv_value as appropriate and get rid of the global runcom_script
> > variable?
>
> You are right, the global runcom_script variable does not
> look very clean. However, the problem is that runcom() is
> one of the transition action functions, i.e. it is called
> by the transition() function and never gets an argument.
>
> Of course it is possible to write an additional function
> run_script(char *script) which contains runcom's current
> code, and make the runcom() function a wrapper that just
> calls run_script(_PATH_RUNCOM). This isn't a perfectly
> clean solution either, but maybe it's at least a little bit
> better.
>
> e.g. basically:
>
> state_func_t
> runcom (void)
> {
> return run_script(_PATH_RUNCOM);
> }
>
> state_func_t
> run_script (char *script)
> {
> /* all the code formerly in runcom() */
> }
>
> Then the init_script code would call run_script(kenv_value)
> instead of runcom(), of course.
>
> Would that be acceptable? Or do you have an even better
> solution in mind?
That sounds great.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hptmv not compatible with WITNESS / INVARIANTS pointers required
This appears to fix the problem, no panic during init of
the adapter or detection of da0.
I say appears as now I'm still stuck with SMP cpu init issue
I was originally looking at :(
Thanks for the fix most appreciated.
Steve
Steven Hartland wrote:
Thanks john, I'll try applying that later tonight should
apply cleanly even though I'm using v1.14 of the driver
I dont think there are any changes in these areas.
N.B. Already contacted Scott Long to get the v1.14
imported as it contains a number of critical fixes.
Steve
John Baldwin wrote:
On Wednesday 03 January 2007 18:58, Steven Hartland wrote:
I'm currently trying to debug an issue with Tyan s2892
based machine but when I enable WITNESS / INVARIANTS
the Highpoint 182x driver panics the kernel with:
panic: blocakble sleep lock ( sleep mutex )
128 @ vm/uma_core.c: 1845
I believe this is due to the fact that you cant hold
a spin mutex while using: bus_dma_tag_create, malloc
bus_dmamem_alloc etc which the driver currently does,
but I have no experience with drivers hence dont know
what it should be doing instead.
If someone's willing to give me some pointers I'd be
willing to give creating a patch and testing it a go.
Here's a snipet of what I think is causing the issue:
/* This uses a mtx_lock_spin */
intrmask_t oldspl = lock_driver();
pAdapter->next = 0;
if(gIal_Adapter == 0) {
gIal_Adapter = pAdapter;
pCurAdapter = gIal_Adapter;
} else {
pCurAdapter->next = pAdapter;
pCurAdapter = pAdapter;
}
pAdapter->outstandingCommands = 0;
pMvSataAdapter = &(pAdapter->mvSataAdapter);
_vbus_p->OsExt = (void *)pAdapter;
pMvSataAdapter->IALData = pAdapter;
/* Errors due to lock_driver holding mtx_lock_spin?? */
if (bus_dma_tag_create(NULL, 1, 0, BUS_SPACE_MAXADDR_32BIT,
BUS_SPACE_MAXADDR, NULL, NULL, BUS_SPACE_MAXSIZE_32BIT,
MV_MAX_SEGMENTS, BUS_SPACE_MAXSIZE_32BIT, 0, NULL, NULL,
&pAdapter->parent_dmat) != 0) {
MV_ERROR("RR182x: Failed to create busdma resources\n");
unlock_driver(oldspl);
return (ENOMEM);
}
I would start off making it use a regular mutex (it doesn't need a
spin mutex anyway). It also doesn't need any locking during the
init_adapter() routine so I've removed that as well. Try this:
Index: entry.c
===
RCS file: /usr/cvs/src/sys/dev/hptmv/entry.c,v
retrieving revision 1.12
diff -u -r1.12 entry.c
--- entry.c 16 May 2006 14:36:25 - 1.12
+++ entry.c 4 Jan 2007 17:44:12 -
@@ -166,12 +166,12 @@
{
intrmask_t spl = 0;
- mtx_lock_spin(&driver_lock);
+ mtx_lock(&driver_lock);
return spl;
}
void unlock_driver(intrmask_t spl)
{
- mtx_unlock_spin(&driver_lock);
+ mtx_unlock(&driver_lock);
}
#else
static int driver_locked = 0;
@@ -1168,7 +1168,7 @@
#if __FreeBSD_version >= 50
static void hpt_init(void *dummy)
{
- mtx_init(&driver_lock, "hptlock", NULL, MTX_SPIN);
+ mtx_init(&driver_lock, "hptlock", NULL, MTX_DEF);
}
SYSINIT(hptinit, SI_SUB_CONFIGURE, SI_ORDER_FIRST, hpt_init, NULL);
#endif
@@ -1183,8 +1183,6 @@
PVDevice pVDev;
- intrmask_t oldspl = lock_driver();
-
pAdapter->next = 0;
if(gIal_Adapter == 0){
@@ -1225,7 +1223,6 @@
if (hptmv_allocate_edma_queues(pAdapter))
{
MV_ERROR("RR182x: Failed to allocate memory for EDMA queues\n");
- unlock_driver(oldspl);
return ENOMEM;
}
@@ -1238,7 +1235,6 @@
{
MV_ERROR("RR182x: Failed to remap memory space\n");
hptmv_free_edma_queues(pAdapter);
- unlock_driver(oldspl);
return ENXIO;
}
else
@@ -1268,7 +1264,6 @@
unregister:
bus_release_resource(pAdapter->hpt_dev, SYS_RES_MEMORY, rid,
pAdapter->mem_res);
hptmv_free_edma_queues(pAdapter);
- unlock_driver(oldspl);
return ENXIO;
}
pAdapter->ver_601 = pMvSataAdapter->pcbVersion;
@@ -1411,7 +1406,6 @@
#endif
mvSataUnmaskAdapterInterrupt(pMvSataAdapter);
- unlock_driver(oldspl);
return 0;
}
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 [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
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 tra
/bin/dd fails with big disks containing bad sectors
Hello, I filed this PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107443) and it was suggested I bring the issue to this list. If you have a defective disk larger than 2 gb with many bad sectors and attempt to use dd under FreeBSD to duplicate the disk, the operation will fail with sectors being out of alignment. dd bs=512 if=src of=dst conv=noerror,sync Under Linux, this operation performs as expected. There are faster methods of duplicating the disk (tools/recoverdisk is one.) But sometimes you only have /bin/dd and a fixit disk. It isn't intuitive that dd should fail in the way it is failing. The user (in this case me) doesn't expect to have a disk improperly aligned. I once resolved this issue several years ago with a patch to dd that is no long valid with current sources. I recently resolved this issue by writing my own tiny dd program (code is provided for curious people in the pr kern/107443) to properly copy the blocks. >From what I can tell there are several requirements for this issue: 1) Disk > 2Gb 2) Disk has more than a few bad sectors. 3) Use dd to copy the disk. It seems despite using "sync", dd is getting confused as to the input and output seek position. They get out of sync with each other and all future output blocks are written earlier on the disk than is required. James Risner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WITNESS & RELENG_6
On Thu, Jan 04, 2007 at 02:12:45PM +0200, Kostik Belousov wrote: > > > > I've tried. Now machine just hangs if I try to switch from X to vty. > > > > It stays in graphics mode locked. > > > Does it crash when exiting glxgears/some video player ? > > It does not crash now when exiting glxgears but glxgears does not > > exit really, this process "hangs" in the "devdrn" state. > As expected. > > mplayer hangs hard the whole system in the moment it switches to > > full-screen. > > > When hangs, does it answer ping/allow ssh connections ? > > Can't check just now, but can establish serial console if you wish. > It would be better to check this in both cases (mplayer and return to vty). I've established ethernet and serial links with this box and checked. In both cases this is X server locked in "devdrn" state. All other processes and the kernel run just fine. > But, most likely, the problem is in nvidia driver that calls destroy_dev() > from d_close(). > > You should ask the vendor for the fix. As a side note, responsible engineer > is aware of the bug. So, I need not bother him ones more? Eugene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel hang on 6.x
On Thursday 04 January 2007 10:27, Brian Dean wrote: > On Wed, Dec 27, 2006 at 11:50:43PM -0500, John Baldwin wrote: > > > The 'traceall' seemed to miss several threads actually (like pid > > 18). Can you get a 'ps'? Also, are you able to get a kernel dump > > when this happens? > > I can't ps that particular session since it is no longer available, > however I can reproduce another one and generate a new set of debug > output. One note, the "swap_pager: indefinite wait buffer: ..." > timeout message may have been a result of a misconfigured secondary > swap file, so that might be a red herring. However, we can still > reliably reproduce the hang with 32 Gig swap, but we don't get any > console messages associated with it. > > The system is set up as a test system so I'm not under any pressure to > get it rebooted and back up when it hangs, so I have the ability to > take some time to debug it. > > I believe that I can generate a kernel dump. We tried this yesterday > but didn't have a dump device configured. I think we've got that set > up now and plan to generate a kernel dump. I'm assuming that since > the process size and swap size is so large, that the dump size is > going to be very large also, on the order of 32 Gig. I beleive I can > host this on a server and make it accessible to you if you are willing > to download it. If this is 6.x, turn on minidumps via the sysctl. The dump size normally is the size of RAM. With minidumps it can be a lot smaller. If you get a dump, let me know and I'll point you at some gdb scripts to generate 'ps' type output, etc. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WITNESS & RELENG_6
On Wednesday 03 January 2007 23:07, Kostik Belousov wrote: > On Wed, Jan 03, 2007 at 04:01:04PM -0500, John Baldwin wrote: > > On Wednesday 03 January 2007 09:18, Eugene Grosbein wrote: > > > Hi! > > > > > > I try to find bugs in 6.2-PRERELEASE by using it (q) :-) > > > The question is: are kernel options WITNESS/WITNESS_KDB expected > > > to be in usable kernel? I don't worry about performance overhead here. > > > > > > The problem is, I've found this is nearly impossible to run > > > my home system with RELENG_6 build from yesterday's sources, > > > X.org 6.9.0, mplayer etc. without panicing and crashdump generation > > > after an hour or so. Just switch from X to vty and logon gave me another > > > LOR and crashdump. One of these you can see here: > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107455 > > > > > > Perhaps, I should not use these options for everyday STABLE use? > > > > > > Eugene > > > > I think you are running into devfs bugs actually. > > I would suggest that the problem may be in the nvidia driver instead. > It seems to be related to dev cloning. > > Anyway, obtaining exact location of fault in devfs_populate_loop (either > with crashdump/kgdb or manually) would be first step. I know of at least one devfs cloning bug the nvidia driver ran into that phk@ verified is a bug in devfs, but I can't understand the patch well enough. I'll forward you the details. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hptmv not compatible with WITNESS / INVARIANTS pointers required
Thanks john, I'll try applying that later tonight should
apply cleanly even though I'm using v1.14 of the driver
I dont think there are any changes in these areas.
N.B. Already contacted Scott Long to get the v1.14
imported as it contains a number of critical fixes.
Steve
John Baldwin wrote:
On Wednesday 03 January 2007 18:58, Steven Hartland wrote:
I'm currently trying to debug an issue with Tyan s2892
based machine but when I enable WITNESS / INVARIANTS
the Highpoint 182x driver panics the kernel with:
panic: blocakble sleep lock ( sleep mutex )
128 @ vm/uma_core.c: 1845
I believe this is due to the fact that you cant hold
a spin mutex while using: bus_dma_tag_create, malloc
bus_dmamem_alloc etc which the driver currently does,
but I have no experience with drivers hence dont know
what it should be doing instead.
If someone's willing to give me some pointers I'd be
willing to give creating a patch and testing it a go.
Here's a snipet of what I think is causing the issue:
/* This uses a mtx_lock_spin */
intrmask_t oldspl = lock_driver();
pAdapter->next = 0;
if(gIal_Adapter == 0) {
gIal_Adapter = pAdapter;
pCurAdapter = gIal_Adapter;
} else {
pCurAdapter->next = pAdapter;
pCurAdapter = pAdapter;
}
pAdapter->outstandingCommands = 0;
pMvSataAdapter = &(pAdapter->mvSataAdapter);
_vbus_p->OsExt = (void *)pAdapter;
pMvSataAdapter->IALData = pAdapter;
/* Errors due to lock_driver holding mtx_lock_spin?? */
if (bus_dma_tag_create(NULL, 1, 0, BUS_SPACE_MAXADDR_32BIT,
BUS_SPACE_MAXADDR, NULL, NULL, BUS_SPACE_MAXSIZE_32BIT,
MV_MAX_SEGMENTS, BUS_SPACE_MAXSIZE_32BIT, 0, NULL, NULL,
&pAdapter->parent_dmat) != 0) {
MV_ERROR("RR182x: Failed to create busdma resources\n");
unlock_driver(oldspl);
return (ENOMEM);
}
I would start off making it use a regular mutex (it doesn't need a
spin mutex anyway). It also doesn't need any locking during the
init_adapter() routine so I've removed that as well. Try this:
Index: entry.c
===
RCS file: /usr/cvs/src/sys/dev/hptmv/entry.c,v
retrieving revision 1.12
diff -u -r1.12 entry.c
--- entry.c 16 May 2006 14:36:25 - 1.12
+++ entry.c 4 Jan 2007 17:44:12 -
@@ -166,12 +166,12 @@
{
intrmask_t spl = 0;
- mtx_lock_spin(&driver_lock);
+ mtx_lock(&driver_lock);
return spl;
}
void unlock_driver(intrmask_t spl)
{
- mtx_unlock_spin(&driver_lock);
+ mtx_unlock(&driver_lock);
}
#else
static int driver_locked = 0;
@@ -1168,7 +1168,7 @@
#if __FreeBSD_version >= 50
static void hpt_init(void *dummy)
{
- mtx_init(&driver_lock, "hptlock", NULL, MTX_SPIN);
+ mtx_init(&driver_lock, "hptlock", NULL, MTX_DEF);
}
SYSINIT(hptinit, SI_SUB_CONFIGURE, SI_ORDER_FIRST, hpt_init, NULL);
#endif
@@ -1183,8 +1183,6 @@
PVDevice pVDev;
- intrmask_t oldspl = lock_driver();
-
pAdapter->next = 0;
if(gIal_Adapter == 0){
@@ -1225,7 +1223,6 @@
if (hptmv_allocate_edma_queues(pAdapter))
{
MV_ERROR("RR182x: Failed to allocate memory for EDMA queues\n");
- unlock_driver(oldspl);
return ENOMEM;
}
@@ -1238,7 +1235,6 @@
{
MV_ERROR("RR182x: Failed to remap memory space\n");
hptmv_free_edma_queues(pAdapter);
- unlock_driver(oldspl);
return ENXIO;
}
else
@@ -1268,7 +1264,6 @@
unregister:
bus_release_resource(pAdapter->hpt_dev, SYS_RES_MEMORY, rid,
pAdapter->mem_res);
hptmv_free_edma_queues(pAdapter);
- unlock_driver(oldspl);
return ENXIO;
}
pAdapter->ver_601 = pMvSataAdapter->pcbVersion;
@@ -1411,7 +1406,6 @@
#endif
mvSataUnmaskAdapterInterrupt(pMvSataAdapter);
- unlock_driver(oldspl);
return 0;
}
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 [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Init.c, making it chroot
Oh and i tested it on 6.1-RELEASE on my own livecd. It works!
Oliver Fromme wrote:
M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Doug Barton <[EMAIL PROTECTED]> writes:
> : Erik Udo wrote:
> : > That's nice. But NetBSDs init.c executes /etc/rc before calling
> : > chroot(), and that's what i'm looking for
> :
> : Sorry if I missed your rationale earlier, but could you perhaps
> : explain a bit more about why you want to do this? I ask because I'm
> : generally interested in boot-time issues, and this sounds like an
> : interesting problem.
>
> This allows one to have a 'simple' /etc/rc that arranges things so
> that a new '/' is ready to 'boot'.
Sorry, I missed that part of the thread because I wasn't
on Cc and didn't look at the list for a while.
I've created (and tested!) a new patch. I've tested on
RELENG_6, but I think init(8) isn't very different on
HEAD, so it should work there, too.
The patched init does the following:
- If the kenv variable "init_script" is set, it is
expected to be the name of a shell script that is
executed before init(8) enters its usual state
machine, and before chrooting (if requested, see
below). If the script terminates with an exit code
other than 0, single user mode is enforced.
- If the kenv variable "init_chroot" is set, init(8)
performs a chroot(2) operation into that directory.
That happens after executing the init_script, if
any, but before entering the usual state machine,
i.e. before going into single or multi user mode.
- A check is performed whether /dev is mounted (inside
the chroot, if any). If not, it is mounted.
- Afterwards, init(8) proceeds normally.
It should be noted that the init_script can create or
modify the "init_chroot" variable using the kenv(1)
tool. So the chroot directory can be specified
dynamically by the init_script; it does not have to
be hardcoded in /boot/loader.conf.
It should also be noted that the init_script requires
a few files and directories to be present _outside_ of
any chroot:
/bin/sh
/dev
/lib/libc.so.6
/lib/libedit.so.5
/lib/libncurses.so.6
/libexec/ld-elf.so.1
Alternatively you can compile a static shell binary,
then you only need /bin/sh and dev (I haven't tested
this, though). Note that the /dev directory must
exist (outside the chroot), because running the
init_script requires certain devices (/dev/console).
It is mounted by the kernel before starting init(8).
As usual, have prepared an ISO image which tests and
demonstrates the patch. It's 17.5 MB compressed:
http://www.secnetix.de/tmp/init_chroot/
The /boot/loader.conf file looks like this:
kernel_options="-C"
init_path="/ochroot/sbin/init"
init_script="/ochroot/etc/rc.init"
init_chroot="/ochroot"
The /ochroot/etc/rc.init just prints a few messages,
so you can see that it actually does something. It
does not have to be inside the chroot (I put it there
because of convenience only).
Any comments are welcome. I particularly appreciate
if others test this stuff.
Best regards
Oliver
PS: Here's the patch, relatve to rev. 1.60.2.2.
I had to move some parts of the original code around,
so the setup of the signal handlers happen before any
script is run, and the mount of /dev happens afterwards.
That's why the diff grew somewhat, even though my actual
code changes aren't that many.
For executing the init_script, I re-used the runcom()
function which required a few minor modifications to it
so it was a bit more flexible. In particular I had to
move the _PATH_RUNCOM constant into a variable.
--- src/sbin/init/init.c.orig Mon Aug 7 15:10:25 2006
+++ src/sbin/init/init.cThu Jan 4 11:53:00 2007
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -121,6 +122,7 @@
state_func_t catatonia(void);
state_func_t death(void);
+const char *runcom_script = _PATH_RUNCOM;
enum { AUTOBOOT, FASTBOOT } runcom_mode = AUTOBOOT;
#define FALSE 0
#define TRUE 1
@@ -187,6 +189,9 @@
int
main(int argc, char *argv[])
{
+ char kenv_value[PATH_MAX];
+ char ichroot_name[] = "init_chroot";
+ char iscript_name[] = "init_script";
int c;
struct sigaction sa;
sigset_t mask;
@@ -275,6 +280,66 @@
if (optind != argc)
warning("ignoring excess arguments");
+ /*
+* We catch or block signals rather than ignore them,
+* so that they get reset on exec.
+*/
+ handle(badsys, SIGSYS, 0);
+ handle(disaster, SIGABRT, SIGFPE, SIGILL, SIGSEGV,
+ SIGBUS, SIGXCPU, SIGXFSZ, 0);
+ handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP,
+ SIGUSR1, SIGUSR2, 0);
+ handle(alrm_handler, SIGALRM, 0);
+ sigfillset(&mask);
+ delset(&mask, SIGABRT, SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGSYS,
+ SIGXCPU, SIGXFSZ, SIGHUP, SIGINT, SIGTERM, SIGTSTP, SIGALRM,
+ SIGUSR1, SIGUSR2, 0);
Re: hptmv not compatible with WITNESS / INVARIANTS pointers required
On Wednesday 03 January 2007 18:58, Steven Hartland wrote:
> I'm currently trying to debug an issue with Tyan s2892
> based machine but when I enable WITNESS / INVARIANTS
> the Highpoint 182x driver panics the kernel with:
> panic: blocakble sleep lock ( sleep mutex )
> 128 @ vm/uma_core.c: 1845
>
> I believe this is due to the fact that you cant hold
> a spin mutex while using: bus_dma_tag_create, malloc
> bus_dmamem_alloc etc which the driver currently does,
> but I have no experience with drivers hence dont know
> what it should be doing instead.
>
> If someone's willing to give me some pointers I'd be
> willing to give creating a patch and testing it a go.
>
> Here's a snipet of what I think is causing the issue:
> /* This uses a mtx_lock_spin */
> intrmask_t oldspl = lock_driver();
>
> pAdapter->next = 0;
>
> if(gIal_Adapter == 0) {
> gIal_Adapter = pAdapter;
> pCurAdapter = gIal_Adapter;
> } else {
> pCurAdapter->next = pAdapter;
> pCurAdapter = pAdapter;
> }
>
> pAdapter->outstandingCommands = 0;
>
> pMvSataAdapter = &(pAdapter->mvSataAdapter);
> _vbus_p->OsExt = (void *)pAdapter;
> pMvSataAdapter->IALData = pAdapter;
>
> /* Errors due to lock_driver holding mtx_lock_spin?? */
> if (bus_dma_tag_create(NULL, 1, 0, BUS_SPACE_MAXADDR_32BIT,
> BUS_SPACE_MAXADDR, NULL, NULL, BUS_SPACE_MAXSIZE_32BIT,
> MV_MAX_SEGMENTS, BUS_SPACE_MAXSIZE_32BIT, 0, NULL, NULL,
> &pAdapter->parent_dmat) != 0) {
> MV_ERROR("RR182x: Failed to create busdma resources\n");
> unlock_driver(oldspl);
> return (ENOMEM);
> }
I would start off making it use a regular mutex (it doesn't need a spin mutex
anyway). It also doesn't need any locking during the init_adapter() routine
so I've removed that as well. Try this:
Index: entry.c
===
RCS file: /usr/cvs/src/sys/dev/hptmv/entry.c,v
retrieving revision 1.12
diff -u -r1.12 entry.c
--- entry.c 16 May 2006 14:36:25 - 1.12
+++ entry.c 4 Jan 2007 17:44:12 -
@@ -166,12 +166,12 @@
{
intrmask_t spl = 0;
- mtx_lock_spin(&driver_lock);
+ mtx_lock(&driver_lock);
return spl;
}
void unlock_driver(intrmask_t spl)
{
- mtx_unlock_spin(&driver_lock);
+ mtx_unlock(&driver_lock);
}
#else
static int driver_locked = 0;
@@ -1168,7 +1168,7 @@
#if __FreeBSD_version >= 50
static void hpt_init(void *dummy)
{
- mtx_init(&driver_lock, "hptlock", NULL, MTX_SPIN);
+ mtx_init(&driver_lock, "hptlock", NULL, MTX_DEF);
}
SYSINIT(hptinit, SI_SUB_CONFIGURE, SI_ORDER_FIRST, hpt_init, NULL);
#endif
@@ -1183,8 +1183,6 @@
PVDevice pVDev;
- intrmask_t oldspl = lock_driver();
-
pAdapter->next = 0;
if(gIal_Adapter == 0){
@@ -1225,7 +1223,6 @@
if (hptmv_allocate_edma_queues(pAdapter))
{
MV_ERROR("RR182x: Failed to allocate memory for EDMA queues\n");
- unlock_driver(oldspl);
return ENOMEM;
}
@@ -1238,7 +1235,6 @@
{
MV_ERROR("RR182x: Failed to remap memory space\n");
hptmv_free_edma_queues(pAdapter);
- unlock_driver(oldspl);
return ENXIO;
}
else
@@ -1268,7 +1264,6 @@
unregister:
bus_release_resource(pAdapter->hpt_dev, SYS_RES_MEMORY, rid,
pAdapter->mem_res);
hptmv_free_edma_queues(pAdapter);
- unlock_driver(oldspl);
return ENXIO;
}
pAdapter->ver_601 = pMvSataAdapter->pcbVersion;
@@ -1411,7 +1406,6 @@
#endif
mvSataUnmaskAdapterInterrupt(pMvSataAdapter);
- unlock_driver(oldspl);
return 0;
}
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Init.c, making it chroot
On Thursday 04 January 2007 09:32, Oliver Fromme wrote:
> M. Warner Losh wrote:
> > In message: <[EMAIL PROTECTED]>
> > Doug Barton <[EMAIL PROTECTED]> writes:
> > : Erik Udo wrote:
> > : > That's nice. But NetBSDs init.c executes /etc/rc before calling
> > : > chroot(), and that's what i'm looking for
> > :
> > : Sorry if I missed your rationale earlier, but could you perhaps
> > : explain a bit more about why you want to do this? I ask because I'm
> > : generally interested in boot-time issues, and this sounds like an
> > : interesting problem.
> >
> > This allows one to have a 'simple' /etc/rc that arranges things so
> > that a new '/' is ready to 'boot'.
>
> I've created (and tested!) a new patch. I've tested on
> RELENG_6, but I think init(8) isn't very different on
> HEAD, so it should work there, too.
>
> Any comments are welcome. I particularly appreciate
> if others test this stuff.
Some things I noticed:
- Why do you have the 'ichroot_name' and 'iscript_name' variables? I would
just pass the string literal to the kenv() function, e.g.
if (kenv(KENV_GET, "init_script", kenv_value, sizeof(kenv_value)) > 0) {
I think that putting the constant right there is easier for someone who
is reading the code to see what is going on.
- Rather than abusing a global runcom_script variable that you change to
get side effects when you invoke runcom(), why not change runcom() to
take a single 'char *script' as an argument and just pass _PATH_RUNCOM
or kenv_value as appropriate and get rid of the global runcom_script
variable?
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Init.c, making it chroot
PERFECT! Just what i needed. Thanks :)
Oliver Fromme wrote:
M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Doug Barton <[EMAIL PROTECTED]> writes:
> : Erik Udo wrote:
> : > That's nice. But NetBSDs init.c executes /etc/rc before calling
> : > chroot(), and that's what i'm looking for
> :
> : Sorry if I missed your rationale earlier, but could you perhaps
> : explain a bit more about why you want to do this? I ask because I'm
> : generally interested in boot-time issues, and this sounds like an
> : interesting problem.
>
> This allows one to have a 'simple' /etc/rc that arranges things so
> that a new '/' is ready to 'boot'.
Sorry, I missed that part of the thread because I wasn't
on Cc and didn't look at the list for a while.
I've created (and tested!) a new patch. I've tested on
RELENG_6, but I think init(8) isn't very different on
HEAD, so it should work there, too.
The patched init does the following:
- If the kenv variable "init_script" is set, it is
expected to be the name of a shell script that is
executed before init(8) enters its usual state
machine, and before chrooting (if requested, see
below). If the script terminates with an exit code
other than 0, single user mode is enforced.
- If the kenv variable "init_chroot" is set, init(8)
performs a chroot(2) operation into that directory.
That happens after executing the init_script, if
any, but before entering the usual state machine,
i.e. before going into single or multi user mode.
- A check is performed whether /dev is mounted (inside
the chroot, if any). If not, it is mounted.
- Afterwards, init(8) proceeds normally.
It should be noted that the init_script can create or
modify the "init_chroot" variable using the kenv(1)
tool. So the chroot directory can be specified
dynamically by the init_script; it does not have to
be hardcoded in /boot/loader.conf.
It should also be noted that the init_script requires
a few files and directories to be present _outside_ of
any chroot:
/bin/sh
/dev
/lib/libc.so.6
/lib/libedit.so.5
/lib/libncurses.so.6
/libexec/ld-elf.so.1
Alternatively you can compile a static shell binary,
then you only need /bin/sh and dev (I haven't tested
this, though). Note that the /dev directory must
exist (outside the chroot), because running the
init_script requires certain devices (/dev/console).
It is mounted by the kernel before starting init(8).
As usual, have prepared an ISO image which tests and
demonstrates the patch. It's 17.5 MB compressed:
http://www.secnetix.de/tmp/init_chroot/
The /boot/loader.conf file looks like this:
kernel_options="-C"
init_path="/ochroot/sbin/init"
init_script="/ochroot/etc/rc.init"
init_chroot="/ochroot"
The /ochroot/etc/rc.init just prints a few messages,
so you can see that it actually does something. It
does not have to be inside the chroot (I put it there
because of convenience only).
Any comments are welcome. I particularly appreciate
if others test this stuff.
Best regards
Oliver
PS: Here's the patch, relatve to rev. 1.60.2.2.
I had to move some parts of the original code around,
so the setup of the signal handlers happen before any
script is run, and the mount of /dev happens afterwards.
That's why the diff grew somewhat, even though my actual
code changes aren't that many.
For executing the init_script, I re-used the runcom()
function which required a few minor modifications to it
so it was a bit more flexible. In particular I had to
move the _PATH_RUNCOM constant into a variable.
--- src/sbin/init/init.c.orig Mon Aug 7 15:10:25 2006
+++ src/sbin/init/init.cThu Jan 4 11:53:00 2007
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -121,6 +122,7 @@
state_func_t catatonia(void);
state_func_t death(void);
+const char *runcom_script = _PATH_RUNCOM;
enum { AUTOBOOT, FASTBOOT } runcom_mode = AUTOBOOT;
#define FALSE 0
#define TRUE 1
@@ -187,6 +189,9 @@
int
main(int argc, char *argv[])
{
+ char kenv_value[PATH_MAX];
+ char ichroot_name[] = "init_chroot";
+ char iscript_name[] = "init_script";
int c;
struct sigaction sa;
sigset_t mask;
@@ -275,6 +280,66 @@
if (optind != argc)
warning("ignoring excess arguments");
+ /*
+* We catch or block signals rather than ignore them,
+* so that they get reset on exec.
+*/
+ handle(badsys, SIGSYS, 0);
+ handle(disaster, SIGABRT, SIGFPE, SIGILL, SIGSEGV,
+ SIGBUS, SIGXCPU, SIGXFSZ, 0);
+ handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP,
+ SIGUSR1, SIGUSR2, 0);
+ handle(alrm_handler, SIGALRM, 0);
+ sigfillset(&mask);
+ delset(&mask, SIGABRT, SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGSYS,
+ SIGXCPU, SIGXFSZ, SIGHUP, SIGINT, SIGTERM, SIGTSTP, SIGALRM,
+ SIGUSR1, SIGUSR2, 0);
+ sigprocmask(SI
Re: Kernel hang on 6.x
On Wed, Dec 27, 2006 at 11:50:43PM -0500, John Baldwin wrote: > The 'traceall' seemed to miss several threads actually (like pid > 18). Can you get a 'ps'? Also, are you able to get a kernel dump > when this happens? I can't ps that particular session since it is no longer available, however I can reproduce another one and generate a new set of debug output. One note, the "swap_pager: indefinite wait buffer: ..." timeout message may have been a result of a misconfigured secondary swap file, so that might be a red herring. However, we can still reliably reproduce the hang with 32 Gig swap, but we don't get any console messages associated with it. The system is set up as a test system so I'm not under any pressure to get it rebooted and back up when it hangs, so I have the ability to take some time to debug it. I believe that I can generate a kernel dump. We tried this yesterday but didn't have a dump device configured. I think we've got that set up now and plan to generate a kernel dump. I'm assuming that since the process size and swap size is so large, that the dump size is going to be very large also, on the order of 32 Gig. I beleive I can host this on a server and make it accessible to you if you are willing to download it. -Brian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Init.c, making it chroot
M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Doug Barton <[EMAIL PROTECTED]> writes:
> : Erik Udo wrote:
> : > That's nice. But NetBSDs init.c executes /etc/rc before calling
> : > chroot(), and that's what i'm looking for
> :
> : Sorry if I missed your rationale earlier, but could you perhaps
> : explain a bit more about why you want to do this? I ask because I'm
> : generally interested in boot-time issues, and this sounds like an
> : interesting problem.
>
> This allows one to have a 'simple' /etc/rc that arranges things so
> that a new '/' is ready to 'boot'.
Sorry, I missed that part of the thread because I wasn't
on Cc and didn't look at the list for a while.
I've created (and tested!) a new patch. I've tested on
RELENG_6, but I think init(8) isn't very different on
HEAD, so it should work there, too.
The patched init does the following:
- If the kenv variable "init_script" is set, it is
expected to be the name of a shell script that is
executed before init(8) enters its usual state
machine, and before chrooting (if requested, see
below). If the script terminates with an exit code
other than 0, single user mode is enforced.
- If the kenv variable "init_chroot" is set, init(8)
performs a chroot(2) operation into that directory.
That happens after executing the init_script, if
any, but before entering the usual state machine,
i.e. before going into single or multi user mode.
- A check is performed whether /dev is mounted (inside
the chroot, if any). If not, it is mounted.
- Afterwards, init(8) proceeds normally.
It should be noted that the init_script can create or
modify the "init_chroot" variable using the kenv(1)
tool. So the chroot directory can be specified
dynamically by the init_script; it does not have to
be hardcoded in /boot/loader.conf.
It should also be noted that the init_script requires
a few files and directories to be present _outside_ of
any chroot:
/bin/sh
/dev
/lib/libc.so.6
/lib/libedit.so.5
/lib/libncurses.so.6
/libexec/ld-elf.so.1
Alternatively you can compile a static shell binary,
then you only need /bin/sh and dev (I haven't tested
this, though). Note that the /dev directory must
exist (outside the chroot), because running the
init_script requires certain devices (/dev/console).
It is mounted by the kernel before starting init(8).
As usual, have prepared an ISO image which tests and
demonstrates the patch. It's 17.5 MB compressed:
http://www.secnetix.de/tmp/init_chroot/
The /boot/loader.conf file looks like this:
kernel_options="-C"
init_path="/ochroot/sbin/init"
init_script="/ochroot/etc/rc.init"
init_chroot="/ochroot"
The /ochroot/etc/rc.init just prints a few messages,
so you can see that it actually does something. It
does not have to be inside the chroot (I put it there
because of convenience only).
Any comments are welcome. I particularly appreciate
if others test this stuff.
Best regards
Oliver
PS: Here's the patch, relatve to rev. 1.60.2.2.
I had to move some parts of the original code around,
so the setup of the signal handlers happen before any
script is run, and the mount of /dev happens afterwards.
That's why the diff grew somewhat, even though my actual
code changes aren't that many.
For executing the init_script, I re-used the runcom()
function which required a few minor modifications to it
so it was a bit more flexible. In particular I had to
move the _PATH_RUNCOM constant into a variable.
--- src/sbin/init/init.c.orig Mon Aug 7 15:10:25 2006
+++ src/sbin/init/init.cThu Jan 4 11:53:00 2007
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -121,6 +122,7 @@
state_func_t catatonia(void);
state_func_t death(void);
+const char *runcom_script = _PATH_RUNCOM;
enum { AUTOBOOT, FASTBOOT } runcom_mode = AUTOBOOT;
#define FALSE 0
#define TRUE 1
@@ -187,6 +189,9 @@
int
main(int argc, char *argv[])
{
+ char kenv_value[PATH_MAX];
+ char ichroot_name[] = "init_chroot";
+ char iscript_name[] = "init_script";
int c;
struct sigaction sa;
sigset_t mask;
@@ -275,6 +280,66 @@
if (optind != argc)
warning("ignoring excess arguments");
+ /*
+* We catch or block signals rather than ignore them,
+* so that they get reset on exec.
+*/
+ handle(badsys, SIGSYS, 0);
+ handle(disaster, SIGABRT, SIGFPE, SIGILL, SIGSEGV,
+ SIGBUS, SIGXCPU, SIGXFSZ, 0);
+ handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP,
+ SIGUSR1, SIGUSR2, 0);
+ handle(alrm_handler, SIGALRM, 0);
+ sigfillset(&mask);
+ delset(&mask, SIGABRT, SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGSYS,
+ SIGXCPU, SIGXFSZ, SIGHUP, SIGINT, SIGTERM, SIGTSTP, SIGALRM,
+ SIGUSR1, SIGUSR2, 0);
+ sigprocmask(SIG_SETMASK, &mask, (sigset_t *) 0);
+
Re: WITNESS & RELENG_6
On Thu, Jan 04, 2007 at 01:02:08PM +0200, Kostik Belousov wrote:
> Hmm, it needs 1.198 as well. Below is aggregated patch against RELENG_6.
>
> Index: kern_conf.c
> ===
> RCS file: /usr/local/arch/ncvs/src/sys/kern/kern_conf.c,v
> retrieving revision 1.186.2.7
> diff -u -r1.186.2.7 kern_conf.c
> --- kern_conf.c 30 Oct 2006 15:43:56 - 1.186.2.7
> +++ kern_conf.c 4 Jan 2007 10:59:33 -
> @@ -676,16 +676,20 @@
> dev->si_flags &= ~SI_CLONELIST;
> }
>
> + dev->si_refcount++; /* Avoid race with dev_rel() */
> csw = dev->si_devsw;
> dev->si_devsw = NULL; /* already NULL for SI_ALIAS */
> while (csw != NULL && csw->d_purge != NULL && dev->si_threadcount) {
> - printf("Purging %lu threads from %s\n",
> - dev->si_threadcount, devtoname(dev));
> csw->d_purge(dev);
> msleep(csw, &devmtx, PRIBIO, "devprg", hz/10);
> + if (dev->si_threadcount)
> + printf("Still %lu threads in %s\n",
> + dev->si_threadcount, devtoname(dev));
> + }
> + while (dev->si_threadcount != 0) {
> + /* Use unique dummy wait ident */
> + msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10);
> }
> - if (csw != NULL && csw->d_purge != NULL)
> - printf("All threads purged from %s\n", devtoname(dev));
>
> dev->si_drv1 = 0;
> dev->si_drv2 = 0;
> @@ -700,6 +704,7 @@
> fini_cdevsw(csw);
> }
> dev->si_flags &= ~SI_ALIAS;
> + dev->si_refcount--; /* Avoid race with dev_rel() */
>
> if (dev->si_refcount > 0) {
> LIST_INSERT_HEAD(&dead_cdevsw.d_devs, dev, si_list);
I've tried. Now machine just hangs if I try to switch from X to vty.
It stays in graphics mode locked.
Eugene
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NVIDIA FreeBSD kernel feature requests
Hi I have got , a geforce 6600gt 256mb/ddr3 can you tell me ? if it will play hd games if ,I BUY a hd ready monitor, [EMAIL PROTECTED] your faithfully , d ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WITNESS & RELENG_6
On Thu, Jan 04, 2007 at 12:37:08PM +0200, Kostik Belousov wrote: > The problem is revealed by INVARIANTS option, not by WITNESS, and is > definitely the use-after-free. > > in src/nvidia_dev.c, nvidia_dev_close(), that is cdevsw.d_close proc, > the destroy_dev() is called. Please, apply rev. 1.199 of sys/kern/kern_conf.c. > I expect that crashes shall stop, but non-killable processes (in the "devdrn") > state would accumulate. > > Please, confirm. I've tried to apply 1.199 to RELENG_6 but failed: one of three chunks has been rejected. Eugene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to make an .so file for Linux binaries
Quoting Garrett Cooper <[EMAIL PROTECTED]> (from Wed, 03 Jan 2007 12:42:38 -0800): Trying to add Flashplayer 9 functionality to FreeBSD (via the Linux binary and www/linux-pluginwrapper) and I was wondering how I should go about determining which symbols need to be used in the .so file, and also how I should go about including the files (#include for the C files, `cat`, etc?). You should see complaints about missing symbols when you start the browser on the console and the output is not redirected to /dev/null (this may be done in a shell wrapper of the browser, you should check). You can also use "nm" to have a look at missing symbols in the .so. Regarding the last part of your question... have a look at what the linux-pluginwrapper does. Note: linux-pluginwrapper will not work on 7-current because of symbol versioning. Bye, Alexander. -- I don't make the rules, Gil, I only play the game. -- Cash McCall http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Partially Unbreak Adobe Reader 7.0.8 for the New Linux Emulator
Quoting Divacky Roman <[EMAIL PROTECTED]> (from Wed, 3 Jan 2007 13:21:34 +0100): On Wed, Jan 03, 2007 at 07:47:28AM +0800, Intron is my alias on the Internet wrote: My patch for /sys/compat/linux/linux_file.c (7.0-CURRENT) can partially unbreak Adobe Reader 7.0.8 for Linux when the sysctl compat.linux.osrelease is set to "2.6.16". You may download the patch at: http://ftp.intron.ac/tmp/linux_file.c.diff this looks good. can you explain why this patch is not needed in 2.4 emulation? I cannot imagine why this differs in 2.6 and 2.4... FC4 (glibc) behaves differently based upon the version of the emulated kernel. Either acroread uses a part of glibc which behaves differently, or acroread checks the version and behaves differently too. Either way: I'm not surprised. ;-) Bye, Alexander. -- It is a wise father that knows his own child. -- William Shakespeare, "The Merchant of Venice" http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Successfully Unbreak Adobe Reader 7.0.8 for the New Linux Emulator
Quoting Intron is my alias on the Internet <[EMAIL PROTECTED]> (from Thu, 04 Jan 2007 06:05:25 +0800): 2. Apply my new patch for /sys/compat/linux/linux_file.c: http://ftp.intron.ac/tmp/linux_file.c.2.diff What about printing a message in the LINUX_O_NOATIME case (maybe only if bootverbose or debug)? Are there other flags which are not handled there? Maybe we should add some code to detect flags which we don't know about (adding the flags we know about to a variable when we see them, comparing this variable to the input and print a message when there's a difference). Bye, Alexander. -- A man is already halfway in love with any woman who listens to him. -- Brendan Francis http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WITNESS & RELENG_6
On Thu, Jan 04, 2007 at 01:48:49PM +0200, Kostik Belousov wrote: > > I've tried. Now machine just hangs if I try to switch from X to vty. > > It stays in graphics mode locked. > > Does it crash when exiting glxgears/some video player ? It does not crash now when exiting glxgears but glxgears does not exit really, this process "hangs" in the "devdrn" state. mplayer hangs hard the whole system in the moment it switches to full-screen. > When hangs, does it answer ping/allow ssh connections ? Can't check just now, but can establish serial console if you wish. Eugene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WITNESS & RELENG_6
On Thu, Jan 04, 2007 at 07:06:03PM +0700, Eugene Grosbein wrote: > On Thu, Jan 04, 2007 at 01:48:49PM +0200, Kostik Belousov wrote: > > > > I've tried. Now machine just hangs if I try to switch from X to vty. > > > It stays in graphics mode locked. > > > > Does it crash when exiting glxgears/some video player ? > > It does not crash now when exiting glxgears but glxgears does not > exit really, this process "hangs" in the "devdrn" state. As expected. > mplayer hangs hard the whole system in the moment it switches to full-screen. > > When hangs, does it answer ping/allow ssh connections ? > Can't check just now, but can establish serial console if you wish. It would be better to check this in both cases (mplayer and return to vty). But, most likely, the problem is in nvidia driver that calls destroy_dev() from d_close(). You should ask the vendor for the fix. As a side note, responsible engineer is aware of the bug. pgphPQFxtRgDP.pgp Description: PGP signature
Re: WITNESS & RELENG_6
On Thu, Jan 04, 2007 at 06:43:27PM +0700, Eugene Grosbein wrote:
> On Thu, Jan 04, 2007 at 01:02:08PM +0200, Kostik Belousov wrote:
>
> > Hmm, it needs 1.198 as well. Below is aggregated patch against RELENG_6.
> >
> > Index: kern_conf.c
> > ===
> > RCS file: /usr/local/arch/ncvs/src/sys/kern/kern_conf.c,v
> > retrieving revision 1.186.2.7
> > diff -u -r1.186.2.7 kern_conf.c
> > --- kern_conf.c 30 Oct 2006 15:43:56 - 1.186.2.7
> > +++ kern_conf.c 4 Jan 2007 10:59:33 -
> > @@ -676,16 +676,20 @@
> > dev->si_flags &= ~SI_CLONELIST;
> > }
> >
> > + dev->si_refcount++; /* Avoid race with dev_rel() */
> > csw = dev->si_devsw;
> > dev->si_devsw = NULL; /* already NULL for SI_ALIAS */
> > while (csw != NULL && csw->d_purge != NULL && dev->si_threadcount) {
> > - printf("Purging %lu threads from %s\n",
> > - dev->si_threadcount, devtoname(dev));
> > csw->d_purge(dev);
> > msleep(csw, &devmtx, PRIBIO, "devprg", hz/10);
> > + if (dev->si_threadcount)
> > + printf("Still %lu threads in %s\n",
> > + dev->si_threadcount, devtoname(dev));
> > + }
> > + while (dev->si_threadcount != 0) {
> > + /* Use unique dummy wait ident */
> > + msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10);
> > }
> > - if (csw != NULL && csw->d_purge != NULL)
> > - printf("All threads purged from %s\n", devtoname(dev));
> >
> > dev->si_drv1 = 0;
> > dev->si_drv2 = 0;
> > @@ -700,6 +704,7 @@
> > fini_cdevsw(csw);
> > }
> > dev->si_flags &= ~SI_ALIAS;
> > + dev->si_refcount--; /* Avoid race with dev_rel() */
> >
> > if (dev->si_refcount > 0) {
> > LIST_INSERT_HEAD(&dead_cdevsw.d_devs, dev, si_list);
>
> I've tried. Now machine just hangs if I try to switch from X to vty.
> It stays in graphics mode locked.
Does it crash when exiting glxgears/some video player ?
When hangs, does it answer ping/allow ssh connections ?
pgpPMuDMl5Kci.pgp
Description: PGP signature
Re: WITNESS & RELENG_6
On Thu, Jan 04, 2007 at 05:52:08PM +0700, Eugene Grosbein wrote:
> On Thu, Jan 04, 2007 at 12:37:08PM +0200, Kostik Belousov wrote:
>
> > The problem is revealed by INVARIANTS option, not by WITNESS, and is
> > definitely the use-after-free.
> >
> > in src/nvidia_dev.c, nvidia_dev_close(), that is cdevsw.d_close proc,
> > the destroy_dev() is called. Please, apply rev. 1.199 of
> > sys/kern/kern_conf.c.
> > I expect that crashes shall stop, but non-killable processes (in the
> > "devdrn")
> > state would accumulate.
> >
> > Please, confirm.
>
> I've tried to apply 1.199 to RELENG_6 but failed:
> one of three chunks has been rejected.
>
Hmm, it needs 1.198 as well. Below is aggregated patch against RELENG_6.
Index: kern_conf.c
===
RCS file: /usr/local/arch/ncvs/src/sys/kern/kern_conf.c,v
retrieving revision 1.186.2.7
diff -u -r1.186.2.7 kern_conf.c
--- kern_conf.c 30 Oct 2006 15:43:56 - 1.186.2.7
+++ kern_conf.c 4 Jan 2007 10:59:33 -
@@ -676,16 +676,20 @@
dev->si_flags &= ~SI_CLONELIST;
}
+ dev->si_refcount++; /* Avoid race with dev_rel() */
csw = dev->si_devsw;
dev->si_devsw = NULL; /* already NULL for SI_ALIAS */
while (csw != NULL && csw->d_purge != NULL && dev->si_threadcount) {
- printf("Purging %lu threads from %s\n",
- dev->si_threadcount, devtoname(dev));
csw->d_purge(dev);
msleep(csw, &devmtx, PRIBIO, "devprg", hz/10);
+ if (dev->si_threadcount)
+ printf("Still %lu threads in %s\n",
+ dev->si_threadcount, devtoname(dev));
+ }
+ while (dev->si_threadcount != 0) {
+ /* Use unique dummy wait ident */
+ msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10);
}
- if (csw != NULL && csw->d_purge != NULL)
- printf("All threads purged from %s\n", devtoname(dev));
dev->si_drv1 = 0;
dev->si_drv2 = 0;
@@ -700,6 +704,7 @@
fini_cdevsw(csw);
}
dev->si_flags &= ~SI_ALIAS;
+ dev->si_refcount--; /* Avoid race with dev_rel() */
if (dev->si_refcount > 0) {
LIST_INSERT_HEAD(&dead_cdevsw.d_devs, dev, si_list);
pgpcRQGmWAiDo.pgp
Description: PGP signature
Re: WITNESS & RELENG_6
On Thu, Jan 04, 2007 at 06:07:27AM +0200, Kostik Belousov wrote: > On Wed, Jan 03, 2007 at 04:01:04PM -0500, John Baldwin wrote: > > On Wednesday 03 January 2007 09:18, Eugene Grosbein wrote: > > > Hi! > > > > > > I try to find bugs in 6.2-PRERELEASE by using it (q) :-) > > > The question is: are kernel options WITNESS/WITNESS_KDB expected > > > to be in usable kernel? I don't worry about performance overhead here. > > > > > > The problem is, I've found this is nearly impossible to run > > > my home system with RELENG_6 build from yesterday's sources, > > > X.org 6.9.0, mplayer etc. without panicing and crashdump generation > > > after an hour or so. Just switch from X to vty and logon gave me another > > > LOR and crashdump. One of these you can see here: > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107455 > > > > > > Perhaps, I should not use these options for everyday STABLE use? > > > > > > Eugene > > > > I think you are running into devfs bugs actually. > > I would suggest that the problem may be in the nvidia driver instead. > It seems to be related to dev cloning. > > Anyway, obtaining exact location of fault in devfs_populate_loop (either > with crashdump/kgdb or manually) would be first step. Ok, thanks to Eugene for sending me requested information in private message. The problem is revealed by INVARIANTS option, not by WITNESS, and is definitely the use-after-free. in src/nvidia_dev.c, nvidia_dev_close(), that is cdevsw.d_close proc, the destroy_dev() is called. Please, apply rev. 1.199 of sys/kern/kern_conf.c. I expect that crashes shall stop, but non-killable processes (in the "devdrn") state would accumulate. Please, confirm. pgphDvlfI6apx.pgp Description: PGP signature
