Re: Compiler error XFree86-Server
Yes. But our 5.0-RELEASE is will non-polished; so I think having the
compiler in the same shape is OK if it means we can get bugs fixed and
our needs taken care of.
But it's still a relase. :-)
Many IA-64, and AMD x86-64 bug fixes and improvements aren't merged back
to the 3.{1,2} branch.
Then we we should go for 3.3. You're right. But why don't we import gcc 3.2
in the meantime to fix the currently broken system gcc?
Marc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Job control pipes
Hi, Job control still does not work correctly on -CURRENT built on Aug 11 13:52:57 EST 2002 (~4 hours ago): $ su Password: cinq# suspend Suspended (signal) $ fg su cinq# suspend Suspended (signal) $ fg su cinq# Stopped (tty output) (I get disconnected) The problems with chpass getting suspended are still there, too. There also seems to be something wrong with pipes: yes | more will fail once in a while. 'more' dies like this: (has just written the first screenful of y's to the screen) 15142 more RET write 78/0x4e 15142 more CALL read(0x4,0xbfbffbe3,0x1) 15142 more RET read -1 errno 5 Input/output error 15142 more CALL write(0x1,0x8061180,0x17) 15142 more GIO fd 1 wrote 23 bytes \^[[24;1H\0\0\0\0\^[[K\0\0\^[[?1l\^[ 15142 more RET write 23/0x17 15142 more CALL fsync(0x2) 15142 more RET fsync 0 15142 more CALL ioctl(0x2,TIOCSETAW,0xbfbffb60) 15142 more RET ioctl -1 errno 5 Input/output error 15142 more CALL exit(0x1) 'yes' dies like this: (has just written a big block of y's) 14288 yes RET write 16384/0x4000 14288 yes CALL write(0x1,0x804b000,0x4000) 14288 yes RET write -1 errno 32 Broken pipe 14288 yes PSIG SIGPIPE SIG_DFL more is trying to read a character from the user's tty, but getting EIO instead. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is anyone else having trouble with dump(8) on -current?
On Sun, 11 Aug 2002 02:03:40 +1000 (EST) Bruce Evans [EMAIL PROTECTED] wrote: I don't know how open() of a disk device can be interrupted by a signal in practice. Most disk operations don't check for signals. How close is our open() to the standards? Does any of them specify EINTR as a possible errno and if yes, shouldn't we write programs which respect the standards (where applicable) instead of just adapting them to our kernel? Bye, Alexander. -- Secret hacker rule #11: hackers read manuals. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
booting SMP kernel on single CPU system
Hi, I have a 5.0-CURRENT system (build date 25th of May) with SMP kernel. Because my SMP mainboard is under repair I placed the disk in a temporary uniprocessor machine. When I try to boot, the following panic occurs: panic: pmap_bootstrap: no local apic! (non-SMP hardware?) cpuid = 0; lapic.id = I understand this problem, but is there some workaround? I don't have a non-SMP kernel on that machine (the kernel.GENERIC is a leftover from FreeBSD 4) and I guess there is no possibily to rebuild the kernel without booting first.. Mark Lastdrager -- Pine Internet BV :: tel. +31-70-3111010 :: fax. +31-70-3111011 PGP 0xFF0EA728 fpr 57D2 CD16 5908 A8F0 9F33 AAA3 AFA0 24EF FF0E A728 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sendfile(2) is broken (Was: ftpd problem: Input/output error)
Hello,
On 14:43+0100, Aug 10, 2002, Gavin Atkinson wrote:
Hi,
For a few months now I have been seeing the following problems with the
ftpd in current. When transferring a large file, ftpd seems to
consistantly fail after almost all of the file hass been transferred. The
example transcript below shows all but 4096 bytes of a file being
transferred before stopping. This also happens across networks, with
4-stable ftp clients - i am confident that it is the ftp server in
current.
gavin@epsilon:/home/gavin grep ^ftp /etc/inetd.conf
ftp stream tcp nowait root/usr/libexec/ftpd ftpd -ll
gavin@epsilon:/home/gavin ls -l foo
-rw--- 1 gavin users 31969280 Aug 4 18:19 foo
gavin@epsilon:/home/gavin ftp localhost
Trying ::1...
ftp: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
220 epsilon.ury.york.ac.uk FTP server (Version 6.00LS) ready.
Name (localhost:gavin):
331 Password required for gavin.
Password:
230 User gavin logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp lcd test
Local directory now /usr/home/gavin/test
ftp get foo
local: foo remote: foo
229 Entering Extended Passive Mode (|||49152|)
150 Opening BINARY mode data connection for 'foo' (31969280 bytes).
99% | | 31216 KB3.25 MB/s00:09
426 Data connection: Input/output error.
31965184 bytes received in 00:09 (3.25 MB/s)
ftp
gavin@epsilon:/home/gavin ls -l test/foo
-rw-r--r-- 1 gavin users 31965184 Aug 4 18:19 test/foo
epsilon# tail -3
/var/log/ftp.log
Aug 10 14:28:28 epsilon ftpd[345]: connection from localhost (127.0.0.1)
Aug 10 14:29:03 epsilon ftpd[345]: FTP LOGIN FROM localhost as gavin
Aug 10 14:29:36 epsilon ftpd[345]: get /usr/home/gavin/foo = 31965184 bytes
As can be seen, the file is 31969280 bytes in size, but ftpd only sends
31963184 bytes. The log file reads the smaller size.
World and kernel are from source supped midnight GMT 10th August. I can
help debug this or provide an account for someone else to look at this
problem.
This is sendfile(2) mis-behaviour arised after rev.1.109
sys/kern/uipc_syscalls.c but I think the real problem in vn_rdwr(),
sys/kern/vfs_vnops.c. Here is my patch but I really need somebody with
vfs clue. I CC'ed Robert Watson as an author of sendfile(2)
modification and our vfs expert.
Index: sys/kern/vfs_vnops.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_vnops.c,v
retrieving revision 1.159
diff -u -r1.159 vfs_vnops.c
--- sys/kern/vfs_vnops.c8 Aug 2002 12:45:30 - 1.159
+++ sys/kern/vfs_vnops.c11 Aug 2002 10:19:47 -
@@ -401,7 +401,7 @@
if (aresid)
*aresid = auio.uio_resid;
else
- if (auio.uio_resid error == 0)
+ if (auio.uio_resid error != 0)
error = EIO;
if ((ioflg IO_NODELOCKED) == 0) {
if (rw == UIO_WRITE)
%%%
With this patch sendfile(2) and ftpd(8) work as expected but I cannot
believe vn_rdwr() has been broken since 1994.
As a temporal solution you can revert rev. 1.109 uipc_syscalls.c,
recompile and reinstall your kernel.
--
Maxim Konovalov, [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Is anyone else having trouble with dump(8) on -current?
In message [EMAIL PROTECTED], Bruce Evans writes:
I don't know how open() of a disk device can be interrupted by a signal
in practice. Most disk operations don't check for signals.
Does the PCATCH tsleep in diskopen() that I mentioned seem a likely
candidate? Anyway, below is a simple program that reproduces the
EINTR error fairly reliably for me when run on disk devices.
Ian
#include sys/types.h
#include err.h
#include fcntl.h
#include signal.h
#include unistd.h
void
handler(int sig) {
}
int
main(int argc, char **argv)
{
int fd, i;
if (argc 2)
errx(1, Usage: %s device, argv[0]);
fork();
fork();
fork();
fork();
signal(SIGUSR1, handler);
sleep(1);
for (i = 0; i 200; i++) {
killpg(0, SIGUSR1);
if ((fd = open(argv[1], O_RDONLY)) 0)
err(1, %s, argv[1]);
close(fd);
}
return 0;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Interrupt vs. polling on -current
On Sat, 10 Aug 2002, Terry Lambert wrote:
Bruce Evans wrote:
No, but the 3Com driver apparently is. The sio driver wants to have
fast interrupts. It can't have them with the irq is shared, so its
worst-case interrupt latency for a single serial port is increased
from about 50 usec to many msec, depending other interrupt activity
in the system (not limited to that for the shared irq except in some
configurations). Silo overflows occur at 115200 bps when the latency
is more than about 1.5 msec.
Anyway to get the code to complain about the sharing of serial
interrupts?
It already complains: from sio.c:
% ret = BUS_SETUP_INTR(device_get_parent(dev), dev, com-irqres,
%INTR_TYPE_TTY | INTR_FAST,
%siointr, com, com-cookie);
% if (ret) {
% ret = BUS_SETUP_INTR(device_get_parent(dev), dev,
%com-irqres, INTR_TYPE_TTY,
%siointr, com, com-cookie);
% if (ret == 0)
% device_printf(dev, unable to activate interrupt in
fast mode - using normal mode\n);
Also, if there is a PCI interrupt for the serial (serial handled
by Northbridge... I'd like to see this, actually), shouldn't it
be capable of sharing *only* fast interrupts somehow? It's an
Yes, this should work. It mainly needs a multiplexer like the old one
for ordinary shared irqs (but even simpler since it doesn't need or
want to change the ipl (soft or hard)) and lots of configuation cruft.
obvious pessimization to mix other interrupts with fast interrupts,
but less obvious what would happen with fast + fast...
It's more than a pessimization; it is impossible by definition, since
sharing fast interrupts (at the same time) makes them non-fast. Another
thing that bus_setup_intr() doesn't do is transparently enough is changing
the setup as devices with different requirements come and go.
FreeBSD on a 486/33 can handle about 4 serial interrupts per second
to do one character of i/o per interrupt). Pessimizations in -current
have only degraded this by a small factor (2?), provided the driver
uses fast interrupts. Lose another small factor (2?) for normal interrupts
(using normal interrupts only loses a large factor for latency).
Any way to fix this, short of don't run -current??
There's also use a fast CPU (almost any new one). Some of the overheads
are related to I/O, so you won't noticed 2x or 4x pessimizations of software
overheads once the I/O overheads are very dominant.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Is anyone else having trouble with dump(8) on -current?
On Sun, 11 Aug 2002, Alexander Leidinger wrote: On Sun, 11 Aug 2002 02:03:40 +1000 (EST) Bruce Evans [EMAIL PROTECTED] wrote: I don't know how open() of a disk device can be interrupted by a signal in practice. Most disk operations don't check for signals. How close is our open() to the standards? Does any of them specify EINTR as a possible errno and if yes, shouldn't we write programs which respect the standards (where applicable) instead of just adapting them to our kernel? open() returning EINTR is normal for some types of devices, so it is standard. General standards like POSIX.1 shouldn't go into details enough to specify different EINTR behaviour for disks (or even specify disks) since this would limit them too much. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sendfile(2) is broken (Was: ftpd problem: Input/output error)
On Sun, 11 Aug 2002, Maxim Konovalov wrote:
This is sendfile(2) mis-behaviour arised after rev.1.109
sys/kern/uipc_syscalls.c but I think the real problem in vn_rdwr(),
sys/kern/vfs_vnops.c. Here is my patch but I really need somebody with
vfs clue. I CC'ed Robert Watson as an author of sendfile(2)
modification and our vfs expert.
Index: sys/kern/vfs_vnops.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_vnops.c,v
retrieving revision 1.159
diff -u -r1.159 vfs_vnops.c
--- sys/kern/vfs_vnops.c 8 Aug 2002 12:45:30 - 1.159
+++ sys/kern/vfs_vnops.c 11 Aug 2002 10:19:47 -
@@ -401,7 +401,7 @@
if (aresid)
*aresid = auio.uio_resid;
else
- if (auio.uio_resid error == 0)
+ if (auio.uio_resid error != 0)
error = EIO;
if ((ioflg IO_NODELOCKED) == 0) {
if (rw == UIO_WRITE)
%%%
With this patch sendfile(2) and ftpd(8) work as expected but I cannot
believe vn_rdwr() has been broken since 1994.
I think the caller (do_sendfile() here?) is at fault for not passing
a non-NULL aresid. The EIO case is basically a kludge to handle short
i/o's. Since the caller hasn't passed a place to return the (residual)
i/o count, it can't even tell if a short i/o occurred, so we pretend
that short i/o's are i/o errors.
There are a lot of sloppy callers that pass a null aresid. But these are
less broken than link_aout_load_file() and link_elf_load_file which pass
a non-null one and then never check it.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sendfile(2) is broken (Was: ftpd problem: Input/output error)
On Sun, 11 Aug 2002, Maxim Konovalov wrote: This is sendfile(2) mis-behaviour arised after rev.1.109 sys/kern/uipc_syscalls.c but I think the real problem in vn_rdwr(), sys/kern/vfs_vnops.c. Here is my patch but I really need somebody with vfs clue. I CC'ed Robert Watson as an author of sendfile(2) modification and our vfs expert. Semen Ustimenko [EMAIL PROTECTED] ran into a similar problem, but his fix was to teach sendfile() to pass in a non-NULL resid and handle the failure mode better. I suspect this fix is more correct since it will both handle the failure mode and the data delivered, and probably is required for other consumers of vn_rdwr(). He was going to run the patch past dg, and then commit it assuming dg approved it, so hopefully it will go into the tree in the next day or so. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
2 Attract Females now.o3r8r8
Below is the result of your feedback form. It was submitted by ([EMAIL PROTECTED]) on Sunday, August 11, 2002 at 11:33:07 --- : It's not a secret anymore... There is a NEW product available in the United States :and it is the strongest formula ever sold! Pheromones! Make your partner HOT!Click :the link below to get PRIMAL! Click here: :http:[EMAIL PROTECTED]/index9987.php Click to remove :http://www.spambites.com/cgi-bin/enter.cgi?spambytes_id=21574 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Interrupt vs. polling on -current
On Fri, 9 Aug 2002, Maksim Yevmenkin wrote: OS: FreeBSD-current DP1 (dmesg attached) Laptop: Toshiba Tecra 8100 (docked) Hardware: 3Com Bluetooth USB dongle, 3Com Bluetooth PC-CARD Xircom CBT PC-CARD (with 16550A UART) First of all, irq 11 gets shared between PC-CARD controller, USB controller, NIC in docking station (see dmesg). Everything This configuration should be expected to work poorly at best. hmmm... i have a couple of latops here at home, one made by Toshiba and another by IBM and they both have similar configuration. may be such configuration is normal for laptops? Both laptop/cards seems to work fine in W2K. I do not know much about PC-CARD controllers, but somehow each PC-CARD i plug into slot gets a different interrupt line. [ ... ] The Xircom card just does not work :( I' getting a lot of silo overflow messages no matter what i try. I checked list archives and source - not much look. Is sio driver totally hopeless? No, but the 3Com driver apparently is. The sio driver wants to have fast interrupts. It can't have them with the irq is shared, so its worst-case interrupt latency for a single serial port is increased from about 50 usec to many msec, depending other interrupt activity in the system (not limited to that for the shared irq except in some configurations). Silo overflows occur at 115200 bps when the latency is more than about 1.5 msec. perhaps, i said it wrong. I only plug *one* PC-CARD at a time, so it only 3com *or* Xircom. So irq11 gets shared between USB, NIC in docking station, PC-CARD controller and Xircom card. BTW, i see silo overflow messages when i run ppp via null-modem cable. in this configuration i'm using serial port 0 which is on board and hase irq 4 with fast interrupts. This morning i change 3Com driver to use polling, and, to my extreme surprise it work much, much better now. Also the interrupt load (according to top) has reduced to at least half. I have not noticed any system slow down. So what is up this that? Does that mean that for slow devices like serial ports etc. polling is better? This points to bug(s) in the 3Com driver. Perhaps its interrupt handler just runs for too long to determine that irq11's for the serial device are not for it. Running in polled mode decreases yes, and that is what i was thinking too. but now i think it is not only 3com driver's fault. The driver just reads one port and check one bit, if it not set then interrupt is not for it. the number of interrupts that it looks at (if there are a lot of serial interrupts), and prevents the 3Com interrupt handling from interfering with serial interrupt handling (because timeouts have lower priority than all other interrupts). just like i said, there is *only one* card in the PC-CARD slot and 3Com *USB* dongle. [ ... ] I just can't believe that FreeBSD on my Pentium-III/600 can't handle lousy 500-700 interrupts a second from PC-CARD. Can anyone point me into right direction, because i'm obviously doing something wrong here. FreeBSD on a 486/33 can handle about 4 serial interrupts per second to do one character of i/o per interrupt). Pessimizations in -current have only degraded this by a small factor (2?), provided the driver uses fast interrupts. Lose another small factor (2?) for normal interrupts (using normal interrupts only loses a large factor for latency). if my calculations are correct -current should handle about 10,000 interrupt/sec from sio, right? i'm sorry, but it is not what i see here. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Aug 11 09:37:52 PDT 2002 -- Kernel build for GENERIC completed on Sun Aug 11 10:19:40 PDT 2002 -- Kernel build for LINT started on Sun Aug 11 10:19:40 PDT 2002 -- === xe /local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:480: warning: no previous prototype for `AcpiDbDecodeNode' /local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:131: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbexec.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbhistry.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbinput.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbstats.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbxface.c:127: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/hwgpe.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfname.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfobj.c:126: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/rsdump.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utclib.c:129: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utdebug.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:489: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:527: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:604: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:607: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:274: warning: `acpi_pwr_deregister_consumer' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:212: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /local0/scratch/des/src/sys/dev/ata/atapi-cam.c: In function `cam_rescan': /local0/scratch/des/src/sys/dev/ata/atapi-cam.c:615: warning: passing arg 1 of `xpt_print_path' makes pointer from integer without a cast *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/LINT. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Weirdness trying -STABLE - -CURRENT
I've been tracking each of -STABLE -CURRENT for a while now, so
it's been almost a year since I tried the -STABLE - -CURRENT upgrade
path. Still, I was a bit skeptical when someone on the #FreeBSD
channel at irc.sage-members.org indicated that the make installworld
was failing for him, typically with /bin/sh dying in some strange way.
In an effort to get a better idea of what any issues might be,
therefore, after I built today's -STABLE (on slice 1) and today's
-CURRENT (on slice 4), I did the following on my SMP (2x866MHz PIII)
build machine:
* cloned slice 1 to slice 3 (dump|restore ad0s1a - ad0s3a ad0s1e -
ad0s3e, followed by tweaking etc/fstab on ad0s3a changing the
obj symlink on ad0s3e to point to /common/S3/obj instead of
/common/S1/obj).
* reboot from slice 3 (multi-user mode); verify that I was running 4.6-S
as of this morning.
* rm -fr /usr/obj/usr/src
* rm -fr /usr/src/*
* cd /usr cvs -d /cvs/freebsd checkout src [/cvs/freebsd is the
FreeBSD portion of my local CVS repository; my ~/.cvsrc has -P as an
automatic command-line flag for the checkout command.]
* cd src/i386/conf ln -s /common/local/src/kernels/current/FREEBEAST .
* whoami mount cd /usr/src uname -a date make -j8
buildworld date make kernel KERNCONF=FREEBEAST date
[This proceeded OK up to the make kernel, at which point I was
reminded that I should only go so far as make buildkernel before
copying /sys/i386/conf/GENERIC.hints to /boot/device.hints.]
* (per above) cp sys/i386/conf/GENERIC.hints /boot/device.hints
date make kernel KERNCONF=FREEBEAST date
* reboot (single-user mode)
Now, at this step, I see something a bit odd:
Console: serial port
BIOS drive A: is disk0
BIOS drive C: is disk1
BIOS 639kB/523200kB available memory
FreeBSD/i386 bootstrap loader, Revision 1.1
([EMAIL PROTECTED], Sun Aug 11 09:29:25 PDT 2002)
Loading /boot/defaults/loader.conf
Warning: syntax error on file /boot/device.hints
machine i386
^
Warning: syntax error on file /boot/loader.conf
$
^
/boot/kernel/kernel text=0x237e0c data=0x35db4+0x6f72c syms=[0x4+0x36820+0x4+0x421d1]
* fsck -p
* mount -u /
* mount -a
* cd /usr/src
* adjkerntz -i
* mergemaster -p
* make installworld
... and this step appears to fail to terminate in a useful manner: I
get as far as:
=== usr.bin/biff
install -s -o root -g wheel -m 555 biff /usr/bin
install -o root -g wheel -m 444 biff.1.gz /usr/share/man/man1
=== usr.bin/brandelf
install -s -o root -g wheel -m 555 brandelf /usr/bin
install -o root -g wheel -m 444 brandelf.1.gz /usr/share/man/man1
=== usr.bin/bzip2
install -s -o root -g wheel -m 555 bzip2 /usr/bin
install -o root -g wheel -m 444 bzip2.1.gz /usr/share/man/man1
/usr/share/man/man1/bunzip2.1.gz - /usr/share/man/man1/bzip2.1.gz
/usr/share/man/man1/bzcat.1.gz - /usr/share/man/man1/bzip2.1.gz
=== usr.bin/bzip2/doc
install-info --quiet --defsection=Programming development tools. --defentry=
bzip2.info /usr/share/info/dir
install -o root -g wheel -m 444 bzip2.info.gz /usr/share/info
/usr/bin/bunzip2 - /usr/bin/bzip2
/usr/bin/bzcat - /usr/bin/bzip2
=== usr.bin/c89
install -s -o root -g wheel -m 555 c89 /usr/bin
install -o root -g wheel -m 444 c89.1.gz /usr/share/man/man1
=== usr.bin/calendar
insptall -o root -g iwheel -m 444 /ud
~z*M~3~W~IK~~k~n%C19K~=c~~1+=K#rB*J~iS~jj~M+IC){I)v~V[{){11~IKv }s!c
}~H(k!I~W%UyI{19U+19~!I#W%U19jBVV{MIK~WYxj
and the machine appears at this point to be non-responsive. I had
cut/pasted the above from the serial console; seeing no way to get
the machine to wake up, I'll hit the reset button... and I find
that after boot -s I see:
Type '?' for a list of commands, 'help' for more detailed help.
OK boot -s
/boot/kernel/acpi.ko text=0x2e29c data=0x1804+0x6e0 syms=[0x4+0x50b0+0x4+0x6913]
-
where things just sit. (I.e., the spinner doesn't spin.)
OK; I hit the magic reset button, then hit space soon enough to
intercept the attempt to load /boot/loader from slice 3, and told it
to load the one from slice 1, boot single-user, and I'm doing a fsck -p
as I type.
OK; I brought it back up under today's -STABLE, and looking at the typescript
file, I see that it ends thusly:
=== usr.bin/cap_mkdb
install -s -o root -g wheel -m 555 cap_mkdb /usr/bin
install -o root -g wheel -m 444 cap_mkdb.1.gz /usr/share/man/man1
=== usr.bin/catman
install -s -o root -g wheel -m 555 catman /usr/bin
install -o root -g wheel -m 444 catman.1.gz /usr/share/man/man1
=== usr.bin/chat
install -s -o root -g wheel -m 555 chat /usr/bin
install -o root -g wheel -m 444 chat.8.gz /usr/share/man/man8
=== usr.bin/checknr
install -s -o root -g wheel -m 555 checknr /usr/bin
install -o root -g wheel -m 444 checknr.1.gz /usr/share/man/man1
=== usr.bin/chflags
install -s -o root -g wheel -m 555 chflags /bin
install -o root -g wheel -m 444 chflags.1.gz /usr/share/man/man1
=== usr.bin/chpass
[ ! -e /usr/bin/chpass ] || chflags noschg /usr/bin/chpass || true
***
pkg-comment
Since pkg-comment contains only a single line, wouldn't it be more subtile to put it in a COMMENT field as does NetBSD, instead of using a file? I think it would speed up updates. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pkg-comment
Since pkg-comment contains only a single line, wouldn't it be more subtile to put it in a COMMENT field as does NetBSD, instead of using a file? I think it would speed up updates. http://people.FreeBSD.org/~eric/ports-comment.diff Will Andrews said that portmgr would be going over this sometime soon, hopefully they will commit it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Pthread library using KSE?
Hi, I'm intrigued by KSE and would like to write some program to test it. Is there a PThread library using KSE for scheduling? Thanks, ed __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Weirdness trying -STABLE - -CURRENT
Hello David, First off, sorry for the lot of snippage but this mail was really long... On Sun, Aug 11, 2002 at 11:37:06AM -0700, David Wolfskill wrote: ... OK; I brought it back up under today's -STABLE, and looking at the typescript file, I see that it ends thusly: ... === usr.bin/checknr install -s -o root -g wheel -m 555 checknr /usr/bin install -o root -g wheel -m 444 checknr.1.gz /usr/share/man/man1 === usr.bin/chflags install -s -o root -g wheel -m 555 chflags /bin install -o root -g wheel -m 444 chflags.1.gz /usr/share/man/man1 === usr.bin/chpass [ ! -e /usr/bin/chpass ] || chflags noschg /usr/bin/chpass || true *** Signal 12 ... So I get the impression that folks who are complaining about the shell getting a SIGSYS probably aren't hallucinating (about that, anyway), and to the extent that there's a (non-recovered) mistake in the procedure I followed, perhaps the effected folks are doing something similar. This is known problem, straight updates by simply make world do not work from -STABLE. Therefore, one has to very carefully follow the procedure described in the UPDATING file even though normally not so many steps would be needed. To get of this situatio, the person(s) affected should do a make -k installworld now and then a make installworld again anf this way get all the new userland installed. Also, one should not use the -j when upgrading (as stated in UPDATING) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Weirdness trying -STABLE - -CURRENT
It's me again... On Sun, Aug 11, 2002 at 11:37:06AM -0700, David Wolfskill wrote: * reboot (single-user mode) Now, at this step, I see something a bit odd: Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/523200kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Sun Aug 11 09:29:25 PDT 2002) Loading /boot/defaults/loader.conf Warning: syntax error on file /boot/device.hints machine i386 ^ Warning: syntax error on file /boot/loader.conf $ ^ /boot/kernel/kernel text=0x237e0c data=0x35db4+0x6f72c syms=[0x4+0x36820+0x4+0x421d1] As for this part: Are you *really* sure that the files were what you believed them to be? The first appears to me to be a kernel config file instead of the device.hints. I have no idea about the second, it could be any file with a $FreeBSD$ tag in it, which was not commented properly or something. BTW: I looked over the suggested order of steps in UPDATING just now, you did things pretty much according to that (with the exception of the -j for the buildworld but that one cannot be that dramatic, I assume you did not use the -j for the installworld. So, I still have no real explanation for your hanging of the machine. Perhaps someone else. The first failure is memory corruption in any event but the reason is not known to me. I have not seen it reported here yet. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sendfile(2) is broken (Was: ftpd problem: Input/output error)
Hi! On Sun, 11 Aug 2002, Robert Watson wrote: On Sun, 11 Aug 2002, Maxim Konovalov wrote: This is sendfile(2) mis-behaviour arised after rev.1.109 sys/kern/uipc_syscalls.c but I think the real problem in vn_rdwr(), sys/kern/vfs_vnops.c. Here is my patch but I really need somebody with vfs clue. I CC'ed Robert Watson as an author of sendfile(2) modification and our vfs expert. Semen Ustimenko [EMAIL PROTECTED] ran into a similar problem, but his fix was to teach sendfile() to pass in a non-NULL resid and handle the failure mode better. I suspect this fix is more correct since it will both handle the failure mode and the data delivered, and probably is required for other consumers of vn_rdwr(). He was going to run the patch past dg, and then commit it assuming dg approved it, so hopefully it will go into the tree in the next day or so. David reviewed the patch and I have committed it few minutes ago. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interrupt vs. polling on -current
[[ I've read the rest of this thread ]] In message: [EMAIL PROTECTED] Maksim Yevmenkin [EMAIL PROTECTED] writes: : My tests are very simple. I plug USB dongle and one PC-CARD : and try to pump data between them as fast as possible. The : data blocks sizes are between 63 and 1500 bytes. I think that the issue here may be that the USB stack may be interacting badly with the interrupt system. Since the pccard is effectively forced into sharing the interrupt with the USB stack with NEWCARD, that's going to interact very badly, I think. Worse even than if you were multiplexing the xl0 driver and the sio0 driver. The sio driver is extremely sensitive to the interrupt latency, since the underlying hardware has only a few characters to react before the fifo overflows. At 115200 baud, each character takes 1/11520 seconds (or 86us), and the fifo is set to have only 8 bytes left when the device interrupts. This means that the sio driver can only tolerate about 700us of latency before there are issues. With 500 interrupts per second, that's an interrupt every 2000us, which is about the same order as the maximum latency tolerance. If these interrupts are shared and are taking a while to allow the serial driver to run, then you are almost certain to cause problems. For cardbus cards, we're forced to use the pci interrupt and share it. For r2 cards (aka 16-bit cards), we could use an unused ISA interrupt on most (but not all) cardbus bridges, but currently there's no support for that in NEWCARD. I'm also surprised you were able to make it work at all. I've had lots of bad luck when trying to make modems work in recent -current kernels. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Pthread library using KSE?
Ed Yu wrote: Hi, I'm intrigued by KSE and would like to write some program to test it. Is there a PThread library using KSE for scheduling? the Kernel support for KSE treads is only partially implemented. Ihe user library is only in initial stages of design.. Any recent talk about KSE support in the -current kernel refers to the basic support that has been added. There is enough in the kernel now to allow the test program in tools/KSE/ksetest to run multipe threads at once, but that program does everyting itself without a library and doesn't handle any of the complicated things such as signals. There is a paper that is currently not anywhere on the web. It's a LITTLE out of date but the big problem is that I don't know enough about TeX to be able to revise it properly. If you can cope with TeX etc the source for the paper is at: http://www.freebsd.org/~julian/freebsd_kse.tgz I really haven't been successful in getting going all the 2034 tools needed to produce the web-page and other forms. Also... look up KSE in the archives of the arch mailing list via the web for more than you ever wanted to know about the evolution of FreeBSD's kernel support for threads. Thanks, ed __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is anyone else having trouble with dump(8) on -current?
On Fri, 2002-08-09 at 18:07, Ian Dowse wrote: [replying to an old message] In message [EMAIL PROTECTED], Alexander Leidi nger writes: On 7 Mai, Benjamin Lewis wrote: | DUMP: slave couldn't reopen disk: Interrupted system call Try the attached patch. [...] I was just looking at PR bin/18319 when I remembered this message. Many of the changes in your patch are not necessary I believe, as read(2) will restart after a signal by default. How about just fixing the open call that actually triggers the reported error? I suspect that many of the other cases are either impossible or extremely unlikely in practice. Could someone who can reproduce the couldn't reopen disk error try the following? [...] My apologies for not keeping up on this. Since buying a house, time for computer-related hobbies has evaporated! Nearly three months later, some less essential parts of the old home network still remain in boxes. In any case, I have been using Alex Leidinger's first patch since he sent it to me. At various times I have tried an unpatched dump and the results have varied from fairly good (only 1 out of 6 filesystems failing each night) to miserable (thousands of errors while reading the disk) depending on the general state of -current. As of today's build, things were behaving on the fairly good side. I have rebuilt dump with Ian Dowse's patch and things look good so far. Sometimes it takes several full backup runs by Amanda before a problem surfaces, so I will report back later in the week. I wish I knew why I seem to be the only one seeing this on -current! -Ben To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
I am forwarding this to -current as I think it needs more neurons on it..
I am presently unable to spend any due to work commitments, and due to a sort-of
personal confusion about tis stuff anyhow..
David Xu wrote:
does anyone believe that su behaviours correctly?
we are talking that kernel has bug to handle job control
but I found that the issue may not related to signal handling
problem, but related to su or csh's job control.
I see this piece of code in su.c:
switch (child_pid) {
default:
while ((ret_pid = waitpid(child_pid, statusp, WUNTRACED)) != eca-1)
{
if (WIFSTOPPED(statusp)) {
child_pgrp = tcgetpgrp(1);
kill(getpid(), SIGSTOP);
tcsetpgrp(1, child_pgrp);
kill(child_pid, SIGCONT);
statusp = 1;
continue;
}
break;
}
I have traced down su. In my test, the su process forked a
child process, child process pid is 873 while parent pid is 872.
these code are in question, I found that tcgetpgrp(1) really
returns parent su pid, it is 872, parent su process
then suspends itself until login shell unsuspends it,
when it resumes, I have inserted another tcgetpgrp(1) after it resumes,
and found that it was 873, it was child su process pid! not 872,
because parent su was not in foreground group, when it called tcsetpgrp(1, 872),
it got a SIGTTOU and suspended there, the SIGCONT was not sent out.
so the code's behaviour is not what the author's want, and all job
control gets weird. I suguest this job control assumption should be removed,
strange thing is why su calls fork()? why doesn't call directly execvl()?
I don't see su calls fork() in OpenBSD.
--- Andrey A. Chernov [EMAIL PROTECTED] wrote:
On Sat, Aug 10, 2002 at 13:36:32 +0400, Andrey A. Chernov wrote:
On Fri, Aug 09, 2002 at 18:23:05 -0700, Julian Elischer wrote:
Andrey.. we need you to also ktrace the child as well..
(together with the su) use ktrace -d -i {YOURSHELL}
to capture everything...
Here it is (starting from the moment, when su exec'ed)
I notice that no 'su' section here, it because that su have s-bit and not
traced. I try to do the same thing from root and get very strange
behaviour, summarized in the following table:
-
root login csh su
suspend
fg
(got bug)
-
root login csh ktrace -d -i /bin/csh
su
suspend
fg
(NO BUG)
-
user login csh su
suspend
fg
(got bug)
-
user login csh ktrace -d -i /bin/csh
su
suspend
fg
(got bug)
It means I can't ktrace _both_ csh and su in the same time, since bug
dissapearse just for that variant.
--
Andrey A. Chernov
http://ache.pp.ru/
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +--x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
David Xu wrote: want, and all job control gets weird. I suguest this job control assumption should be removed, strange thing is why su calls fork()? why doesn't call directly execvl()? I don't see su calls fork() in OpenBSD. This has to do with PAM, AFAIK. Someone has to call PAM session cleanup hooks, that's why another process for the command is forked. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
--- Andrey A. Chernov [EMAIL PROTECTED] wrote:
On Sun, Aug 11, 2002 at 17:41:20 +0400, Andrey A. Chernov wrote:
On Sun, Aug 11, 2002 at 06:28:54 -0700, David Xu wrote:
does anyone believe that su behaviours correctly?
I not believe in that first, so why I remove tcsetpgrg() in my initial
commit. It fix suspend/fg, but break stop $$/fg those times. I not test,
is it break stop $$/fg now too (I'll do it a bit later and send result).
fork/wait seems to be needed here just for PAM_END.
Yes, still there. If tcsetpgrp() removed, suspend/fg fixed, but stop
$$/fg kills login shell. It means that neither variant is correct, unless
there is a kernel bug. To be 100% sure, we need to test su with old
-current kernel without KSE. Anybody have that thing? I can cvsup early
kernel sources and build from them, but I don't know exact KSE changes
data. Other way is to build su statically and test on -stable. I don't
have any -stable machines around.
--
Andrey A. Chernov
http://ache.pp.ru/
Sorry, Andrey, current su's job control mode does not work under STABLE too,
I have tested, it has same result as under CURRENT. the following piece of
code does not work under STABLE, it mimics what su is doing in CURRENT
source tree.
#include err.h
#include errno.h
#include signal.h
#include stdio.h
#include sys/wait.h
#include unistd.h
int main()
{
pid_t ret_pid, statusp, child_pid, child_pgrp;
struct sigaction sa, sa_int, sa_quit, sa_tstp;
char buf[64];
char* sargv[3];
sa.sa_flags = SA_RESTART;
sa.__sigaction_u.__sa_handler = SIG_IGN;
sigemptyset(sa.sa_mask);
sigaction(SIGINT, sa, sa_int);
sigaction(SIGQUIT, sa, sa_quit);
sigaction(SIGTSTP, sa, sa_tstp);
child_pid = fork();
switch (child_pid) {
default:
while ((ret_pid = waitpid(child_pid, statusp, WUNTRACED)) != -1) {
if (WIFSTOPPED(statusp)) {
child_pgrp = tcgetpgrp(1);
kill(getpid(), SIGSTOP);
tcsetpgrp(1, child_pgrp);
kill(child_pid, SIGCONT);
statusp = 1;
continue;
}
break;
}
if (ret_pid == -1)
err(1, waitpid);
exit(statusp);
case -1:
err(1, fork);
exit(1);
case 0:
sigaction(SIGINT, sa_int, NULL);
sigaction(SIGQUIT, sa_quit, NULL);
sigaction(SIGTSTP, sa_tstp, NULL);
sargv[0] = csh;
sargv[1] = NULL;
execv(/bin/csh, sargv);
printf(hi, there!\n);
break;
}
return 0;
}
David
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Kernel Panic and reboots - smtpd process ?
Hi Folks, I got this kernel panic yesterday and this has happened twice in the last two days. -- /usr/src/sys/vm/uma_core.c:1332: could sleep with inp locked from /usr/src/sys/netinet/tcp_usrreq.c:1013 Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc3128634 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02a356b stack pointer = 0x10:0xd2e61aa8 frame pointer = 0x10:0xd2e61ab0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 99039 (smtpd) trap number = 12 panic: page fault syncing disks... panic: bremfree: bp 0xc772704c not locked Uptime: 9h14m0s Terminate ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... -- Something already reported ? Thanks Regards Sid -- God gives us relatives; thank goodness we can chose our friends. Sid Carter FreeBSD oder Debian GNU/Linux. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel Panic and reboots - smtpd process ?
An Mon, Aug 12, 2002 at 09:35:34AM +0530, Sid Carter schreib : I got this kernel panic yesterday and this has happened twice in the last two days. -- /usr/src/sys/vm/uma_core.c:1332: could sleep with inp locked from /usr/src/sys/netinet/tcp_usrreq.c:1013 Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc3128634 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02a356b stack pointer = 0x10:0xd2e61aa8 frame pointer = 0x10:0xd2e61ab0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 99039 (smtpd) trap number = 12 panic: page fault syncing disks... panic: bremfree: bp 0xc772704c not locked Uptime: 9h14m0s Terminate ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... -- Sorry. I forgot this info. uname -a FreeBSD calvin 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Aug 10 17:58:11 IST 2002 root@calvin:/usr/obj/usr/src/sys/GENERIC i386 dmesg - FreeBSD 5.0-CURRENT #0: Sat Aug 10 17:58:11 IST 2002 root@calvin:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc061a000. Preloaded elf module /boot/kernel/splash_pcx.ko at 0xc061a0a8. Preloaded elf module /boot/kernel/snd_ich.ko at 0xc061a158. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc061a204. Preloaded elf module /boot/kernel/acpi.ko at 0xc061a2b0. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 996771495 Hz CPU: Pentium III/Pentium III Xeon/Celeron (996.77-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE TIA Regards Sid -- God gives us relatives; thank goodness we can chose our friends. Sid Carter FreeBSD oder Debian GNU/Linux. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Aug 11 22:22:13 PDT 2002 -- === ibcs2 /local0/scratch/des/src/sys/i386/ibcs2/ibcs2_misc.c:57:21: opt_mac.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /local0/scratch/des/src/sys/modules/ibcs2. *** Error code 1 Stop in /local0/scratch/des/src/sys/modules. *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
--- David Xu [EMAIL PROTECTED] wrote:
--- Andrey A. Chernov [EMAIL PROTECTED] wrote:
On Sun, Aug 11, 2002 at 17:41:20 +0400, Andrey A. Chernov wrote:
On Sun, Aug 11, 2002 at 06:28:54 -0700, David Xu wrote:
does anyone believe that su behaviours correctly?
I not believe in that first, so why I remove tcsetpgrg() in my initial
commit. It fix suspend/fg, but break stop $$/fg those times. I not test,
is it break stop $$/fg now too (I'll do it a bit later and send result).
fork/wait seems to be needed here just for PAM_END.
Yes, still there. If tcsetpgrp() removed, suspend/fg fixed, but stop
$$/fg kills login shell. It means that neither variant is correct, unless
there is a kernel bug. To be 100% sure, we need to test su with old
-current kernel without KSE. Anybody have that thing? I can cvsup early
kernel sources and build from them, but I don't know exact KSE changes
data. Other way is to build su statically and test on -stable. I don't
have any -stable machines around.
--
Andrey A. Chernov
http://ache.pp.ru/
Sorry, Andrey, current su's job control mode does not work under STABLE too,
I have tested, it has same result as under CURRENT. the following piece of
code does not work under STABLE, it mimics what su is doing in CURRENT
source tree.
#include err.h
#include errno.h
#include signal.h
#include stdio.h
#include sys/wait.h
#include unistd.h
int main()
{
pid_t ret_pid, statusp, child_pid, child_pgrp;
struct sigaction sa, sa_int, sa_quit, sa_tstp;
char buf[64];
char* sargv[3];
sa.sa_flags = SA_RESTART;
sa.__sigaction_u.__sa_handler = SIG_IGN;
sigemptyset(sa.sa_mask);
sigaction(SIGINT, sa, sa_int);
sigaction(SIGQUIT, sa, sa_quit);
sigaction(SIGTSTP, sa, sa_tstp);
child_pid = fork();
switch (child_pid) {
default:
while ((ret_pid = waitpid(child_pid, statusp, WUNTRACED)) != -1) {
if (WIFSTOPPED(statusp)) {
child_pgrp = tcgetpgrp(1);
kill(getpid(), SIGSTOP);
tcsetpgrp(1, child_pgrp);
kill(child_pid, SIGCONT);
statusp = 1;
continue;
}
break;
}
if (ret_pid == -1)
err(1, waitpid);
exit(statusp);
case -1:
err(1, fork);
exit(1);
case 0:
sigaction(SIGINT, sa_int, NULL);
sigaction(SIGQUIT, sa_quit, NULL);
sigaction(SIGTSTP, sa_tstp, NULL);
sargv[0] = csh;
sargv[1] = NULL;
execv(/bin/csh, sargv);
printf(hi, there!\n);
break;
}
return 0;
}
following is patch for su, I can type suspend and stop $$ without the
problem you described, I have tested it under tcsh and bash, all works
for me.
--- su.cMon Aug 12 13:08:01 2002
+++ su.c.newMon Aug 12 13:16:14 2002
@@ -329,10 +329,13 @@
default:
while ((ret_pid = waitpid(child_pid, statusp, WUNTRACED)) != -1) {
if (WIFSTOPPED(statusp)) {
- child_pgrp = tcgetpgrp(1);
kill(getpid(), SIGSTOP);
- tcsetpgrp(1, child_pgrp);
- kill(child_pid, SIGCONT);
+ child_pgrp = getpgid(child_pid);
+ if (tcgetpgrp(1) == getpgrp())
+ {
+ tcsetpgrp(1, child_pgrp);
+ kill(child_pid, SIGCONT);
+ }
statusp = 1;
continue;
}
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
David Xu wrote: following is patch for su, I can type suspend and stop $$ without the problem you described, I have tested it under tcsh and bash, all works for me. [ ... ] Looks like a patch to a user space program to deal with POSIX non-compliance of the host OS. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
