System Hang During tar Backup
I am encountering a problem when using tar to backup the files on my system. I am uncertain of when this problem began, but this worked a month ago. The backup seems to run for at least ten minutes, but the system seems to hang after a period of time. Keyboard input appears on the screen, but control-C has no effect. Control-Alt-Delete has no effect either, and my only option is to press the reset button or power down the machine. No services are active when the system is in this state (i.e., I cannot make a remote connection to the machine). I am running 4.3-STABLE that was built after a cvsup of RELENG_4 as of yesterday. I am using the following syntax: tar --create --totals --absolute-paths --file /dev/rsa0 / My hardware is a Seagate Scorpion STD2401LW. This is a DDS4 DAT drive. Is anyone else experiencing a similar problem? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: RELENG_4 crashes under SMP
Since my machine is co-located and over an hour away, I would love to know whether this is solved. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Unable to run linux unace
Quoting Mikko Tyolajarvi <[EMAIL PROTECTED]>:
> In local.freebsd.stable you write:
>
> >Quoting Roman Shterenzon <[EMAIL PROTECTED]>:
>
> >> Hello,
> >> I wanted to use linux unace from www.winace.com
> >> (http://praf.nirvanet.net/winace/linunace203.tgz),
> >> but unfortunately it doesn't work.
> >> When I used truss on it, I've seen this:
>
> [...]
>
> >> linux_mremap(0x28109000,0x61000,0x81000,0x1) ERR#12 'Cannot
> allocate
> >> memory'
>
> [...]
>
> >This is what I get when I run it on remote linux system:
>
> >mremap(0x4000, 135168, 266240, MREMAP_MAYMOVE) = 0x4000
>
> [...]
>
> >It doesn't give me any hints :(
>
> From a Linux mremap() man page:
>
> void *mremap(void *old_address, size_t old_size, size_t new_size,
> unsigned long flags);
>
> And from linux_mremap() in the linuxulator (linux_misc.c):
>
> if (args->new_len > args->old_len) {
> p->p_retval[0] = 0;
> return ENOMEM;
> }
>
> To me it looks like extending a mmapped region with mremap() isn't
> supported.
>
> $.02,
> /Mikko
> --
> Mikko
> Työläjä[EMAIL PROTECTED]
> RSA Security
>
Hmm.. Is it possible to completely unmap and then remap this region?
And if it is, how? The fd is not known to the mremap handler. :(
--Roman Shterenzon, UNIX System Administrator and Consultant
[ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: Unable to run linux unace
Quoting Valentin Nechayev <[EMAIL PROTECTED]>:
> Fri, Jun 29, 2001 at 02:47:41, roman (Roman Shterenzon) wrote about
> "Re: Unable to run linux unace":
>
> > > -- UNKNOWN SYSCALL 221
> > > (null)() ERR#78 'Function
> not
> > > implemente
> > > d'
>
> Let's believe in correctness of these syscall numbers (see below
> why)...
> 221 is sys_fcntl64 in 2.4.1 and does not exist in 2.2.16.
>
> > > -- UNKNOWN SYSCALL 201
>
> 201 is sys_geteuid in 2.4.1 and does not exist in 2.2.16.
> 2.2.16 has sys_geteuid as syscall 49. 2.4.1 declares it as
> sys_geteuid16.
>
> > This is what I get when I run it on remote linux system:
>
> Version of kernel of this linux system may be essential to diagnose.
>
> But I'm surprised that linux trace mentions shmat() and semop()
> (which are implemented in linux in generic sys_ipc() multiplexer,
> syscall number 117), but your FreeBSD trace says quite another
> numbers.
> Possibly these syscall numbers are not target to believe.
>
> > execve("./unace", ["./unace"], [/* 27 vars */]) = 0
> > shmat(0, 0, 0x1)= -1 ENOSYS (Function not
> implemented)
> > fcntl(0, F_GETFD) = 0
> > fcntl(1, F_GETFD) = 0
> > fcntl(2, F_GETFD) = 0
> > uname({sys="Linux", node="..com", ...}) = 0
> > semop(131601, 0, 38)= -1 ENOSYS (Function not
> implemented)
>
>
> /netch
>
The linux system I tried running unace on is 2.2.17.
The FreeBSD sysctl emulates linux version of 2.2.12.
Do you think that these syscalls are essential? Because they fail on both
FreeBSD and Linux, perhaps they're not the main reason for the failure?
Any ideas? Where is the linuxulator guy? :)
--Roman Shterenzon, UNIX System Administrator and Consultant
[ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
