Re: Unfortunate dynamic linking for everything
On Wed, Nov 19, 2003 at 09:27:55PM -0800, Tim Kientzle wrote: Richard Coleman wrote: It seems /bin/sh is the real sticking point. There is a problem here: Unix systems have historically used /bin/sh for two somewhat contradictory purposes: * the system script interpreter * as a user shell The user shell must be dynamically linked in order to support centralized administration. I personally see no way around that. Given that many users do rely on /bin/sh, it seems that /bin/sh must be dynamically linked. There are good reasons to want the system script interpreter statically linked. Maybe it's time to separate these two functions? I would be content to have a static /sbin/sh that is used as the system script interpreter for rc scripts, etc. And /usr/bin/sh as a user shell? --Stijn -- I'm not under the alkafluence of inkahol that some thinkle peep I am. It's just the drunker I sit here the longer I get. pgp0.pgp Description: PGP signature
Re: another trap 12 while in kernel mode (now with trace)
Hi, On Wed, 19 Nov 2003 22:30:44 + (UTC) [EMAIL PROTECTED] (Bjoern A. Zeeb) said: db trace bzeeb-lists key_cmpspidx_withmask(deadc0de,c9b5c914) at key_cmpspidx_withmask+0x2c bzeeb-lists key_allocsp(0,c9b5c914,2,16000210,c1426f0a) at key_allocsp+0x8b Thank you for your report. I'm working on this. Please wait. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Brian F. Feldman [EMAIL PROTECTED] writes: Jeez, it's been broken a year and it's almost 5.2-RELEASE now. Does anyone have ANY leads on these problems? I know precisely nothing about how my USB hardware is supposed to work, but this OHCI+EHCI stuff definitely doesn't, and it's really not uncommon at all. Is it unbroken in NetBSD currently? *shrug* I have never been able to get my USB printer to work with FreeBSD, and I gave up writing drivers for USB crypto tokens because the USB drivers were too broken (reading any amount of data from the ugen device returns garbage with no error message and no indication of the actual amount of data obtained from the device). Neither could I get anybody with USB clue interested in the problem long enough to actually try to fix it. In conclusion, I simply don't consider FreeBSD's USB support usable for anything more complex than mice and keyboards. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: probing for non-PCI bus
John Baldwin wrote: On 11-Nov-2003 John Hay wrote: Upgrading a Asus P2L97-DS dual Pentium II 266MHz box, I got this panic when booting: I have the exact same motherboard, only I run with dual Pentium II 300MHz. However I run a beta bios (to support ata disks larger than 32GB) that I got from Asus many years ago. I am using this system as my workstation at home, and it does have an AGP slot (with an nvidia card in). ACPI has worked before, and it still does except is fires off about 4 interrupts (on IRQ20). However I'll have to wait until I get home to provide acpidumps and mptables when I get home. Oof, no MADT table. Your BIOS sucks. :-P Don't use ACPI because PCI interrupts aren't going to work otherwise. Does this system have an AGP slot? Also, do you have a dmesg from before? If I remember correctly I do not have a MADT table either, but ACPI did find the CPUs. We/I'll know more when I get home. -- Morten Rodal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installworld failure
Tor 2003-11-20 klockan 02.47 skrev Thomas T. Veldhouse: ... cat /usr/src/bin/csh/../../contrib/tcsh/nls/et/ et_EE.ISO8859-15.msg gencat -new et_EE.ISO8859-15.cat et_EE.ISO8859-15.msg gencat:No such file or directory ... If you don't insist on implement support for Estonian, just touch /usr/src/contrib/tcsh/et_EE.ISO8859-15.msg so gencat will find its msg-file. Aron Håkanson Comitor Konsult http://www.comitor.se/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
In message [EMAIL PROTECTED], Brian F. Feldman
writes:
Jeez, it's been broken a year and it's almost 5.2-RELEASE now. Does anyone
have ANY leads on these problems? I know precisely nothing about how my USB
hardware is supposed to work, but this OHCI+EHCI stuff definitely doesn't,
and it's really not uncommon at all. Is it unbroken in NetBSD currently?
I had some success with this patch:
Index: usb_mem.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/usb_mem.c,v
retrieving revision 1.5
diff -u -r1.5 usb_mem.c
--- usb_mem.c 4 Oct 2003 22:13:21 - 1.5
+++ usb_mem.c 27 Oct 2003 15:39:03 -
@@ -142,7 +142,8 @@
s = splusb();
/* First check the free list. */
for (p = LIST_FIRST(usb_blk_freelist); p; p = LIST_NEXT(p, next)) {
- if (p-tag == tag p-size = size p-align = align) {
+ if (p-tag == tag p-size = size p-size size * 2
+ p-align = align) {
LIST_REMOVE(p, next);
usb_blk_nfree--;
splx(s);
It seems that since the conversion to busdma, the USB code can end
up attempting to use contigmalloc() to allocate multi-page regions
from an interrupt thread(!). The above doesn't fix that; it just
prevents successful large (e.g 64k) contiguous allocations from
being wasted when a much smaller amount of space is needed.
With the above, I was able to use ohci+ehci fairly reliably on a
Soekris box with a large USB2 disk attached via a cardbus USB2
adaptor. I also have a few other local patches that may help too -
some of them are below:
Ian
Index: ohci.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ohci.c,v
retrieving revision 1.132
diff -u -r1.132 ohci.c
--- ohci.c 24 Aug 2003 17:55:54 - 1.132
+++ ohci.c 21 Sep 2003 15:28:27 -
@@ -1405,12 +1405,13 @@
if (std-flags OHCI_ADD_LEN)
xfer-actlen += len;
if (std-flags OHCI_CALL_DONE) {
+ ohci_free_std(sc, std); /* XXX */
xfer-status = USBD_NORMAL_COMPLETION;
s = splusb();
usb_transfer_complete(xfer);
splx(s);
- }
- ohci_free_std(sc, std);
+ } else
+ ohci_free_std(sc, std);
} else {
/*
* Endpoint is halted. First unlink all the TDs
@@ -2246,6 +2247,7 @@
usb_uncallout(xfer-timeout_handle, ohci_timeout, xfer);
usb_transfer_complete(xfer);
splx(s);
+ return;
}
if (xfer-device-bus-intr_context || !curproc)
Index: usbdi.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.82
diff -u -r1.82 usbdi.c
--- usbdi.c 24 Aug 2003 17:55:55 - 1.82
+++ usbdi.c 21 Sep 2003 15:28:29 -
@@ -751,6 +751,7 @@
pipe, xfer, pipe-methods));
/* Make the HC abort it (and invoke the callback). */
pipe-methods-abort(xfer);
+ KASSERT(SIMPLEQ_FIRST(pipe-queue) != xfer, (usbd_ar_pipe));
/* XXX only for non-0 usbd_clear_endpoint_stall(pipe); */
}
pipe-aborting = 0;
@@ -763,8 +764,9 @@
{
usbd_pipe_handle pipe = xfer-pipe;
usb_dma_t *dmap = xfer-dmabuf;
+ usbd_status status;
int repeat = pipe-repeat;
- int polling;
+ int polling, xfer_flags;
SPLUSBCHECK;
@@ -835,30 +837,33 @@
xfer-status = USBD_SHORT_XFER;
}
- if (xfer-callback)
- xfer-callback(xfer, xfer-priv, xfer-status);
-
-#ifdef DIAGNOSTIC
- if (pipe-methods-done != NULL)
+ /* Copy any xfer fields in case the xfer goes away in the callback. */
+ status = xfer-status;
+ xfer_flags = xfer-flags;
+ /*
+* For repeat operations, call the callback first, as the xfer
+* will not go away and the done method may modify it. Otherwise
+* reverse the order in case the callback wants to free or reuse
+* the xfer.
+*/
+ if (repeat) {
+ if (xfer-callback)
+ xfer-callback(xfer, xfer-priv, status);
pipe-methods-done(xfer);
- else
- printf(usb_transfer_complete: pipe-methods-done == NULL\n);
-#else
- pipe-methods-done(xfer);
-#endif
-
- if ((xfer-flags USBD_SYNCHRONOUS) !polling)
- wakeup(xfer);
+ } else {
+ pipe-methods-done(xfer);
+ if (xfer-callback)
+
Re: Unfortunate dynamic linking for everything
On Wed, Nov 19, 2003 at 11:18:47AM -0700, Lyndon Nerenberg wrote: --On Wednesday, November 19, 2003 12:30 AM -0500 Garance A Drosihn [EMAIL PROTECTED] wrote: have a: chflags ldcache /bin/sh Shouldn't that be 'chmod +t /bin/sh' ??? Definitely. Why waste a new bit when there's already a perfectly good one that is (or was) defined for the purpose. As for the implementation, I presume the desired behaviour would be to snapshot the process image (make it copy-on-write) at the point where ld-elf.so invokes main(). You'd probably want LD_BIND_NOW behaviour to minimise the runtime overheads. I don't see any need for this to need massive amounts of RAM - there's no reason why the snapshot couldn't be paged normally. I think this would be a big win compared to what we have now - the full benefits of dynamic linking remain and most of the run-time binding overheads are removed. Of course it's not perfect. The snapshot image permanently occupies virtual space (RAM/swap). And there's still the PIC overhead - especially on register-starved architectures like the i386. I wonder how difficult this would be to implement in userland only? Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Jeez, it's been broken a year and it's almost 5.2-RELEASE now. See for example the page for the FreeBSD eagle driver: http://damien.bergamini.free.fr/ueagle/ end notably the OHCI patches in http://damien.bergamini.free.fr/ueagle/download.html At least for the eagle USB ADSL modem, these patches solve the ohci problems. -- Michel TALON ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Alexander Leidinger [EMAIL PROTECTED] writes: I have no problem using my printer: [...] ulpt0: Hewlett-Packard DeskJet 895C, rev 1.00/1.00, addr 4, iclass 7/1 ulpt0: using uni-directional mode Sure, I can do that: ulpt0: Hewlett-Packard officejet d series, rev 1.10/1.00, addr 3, iclass 7/1 ulpt0: using bi-directional mode but it still won't print. Sometimes it works (albeit very, very slowly) but most of the time the process writing to ulpt0 just hangs. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multifunction USB devices
On Tue, Nov 18, 2003 at 08:12:49PM -0500, Jeff Walters wrote: I have an Epson printer/scanner combo device (CX5200) which works just fine either as a printer or as a scanner (when I add the vendor and product codes to usbdevs and uscanner.c) but not both simultaneously. Currently I compile ulpt and my customized uscanner as modules, and to switch functions I power the device off, unload/load the appropriate kernel module, and power the device back on. I'm assuming a patch to add the CX5200 vendor/device codes to usbdevs and uscanner.c in the way I'm doing wouldn't be accepted into CURRENT since the resulting usage of it is a bit of a hack. Is that right? The right fix would be to convert uscanner into a function level driver for scanner combinations - currently it's a device level driver. ulpt does the right thing. Compare USB_MATCH and USB_ATTACH functions to get an idea about the difference. Adding device identification to uscanner is required anyway, because there is no class definition for scanners. I wouldn't mind doing work over the next few months to create proper simultaneous support for both devices if it can be done with a reasonable level of effort and I can find some sources of information, and I can get some guidance from an experienced committer or architect to help do it right the first time. Where should I go for discussion? I'd like to learn ie. should I work to combine ulpt and uscanner into some kind of single umulti type of device driver, or should a virtual hub device of some kind be created to support both ulpt and uscanner simultaneously as-is (one USB endpoint, multiple interfaces), or should the system simply continue searching after matching a USB device, or will this be OBE with some other USB work going on, etc. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
Jacques A. Vidrine [EMAIL PROTECTED] wrote: Finally, if we could call `dlopen' from statically-linked binaries, this wouldn't be an issue. One of the performance problems that John Dyson mentioned (the sparse dirtying of libc's data section) would still remain, because the whole of libc has to be linked into programs that use NSS. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ THE WASH TO NORTH FORELAND: SOUTHWEST 4 OR 5, PERHAPS 6 FOR A TIME IN EVENING IN THAMES, VEERS NORTH TO NORTHEAST 2 OR 3 FROM NORTH, BACKS NORTHWEST LATER. OCCASIONAL RAIN, CLEARS ERRATICALLY FROM NORTH, EXCEPT FAR SOUTH. MODERATE OR GOOD, LOCALLY POOR IN SOUTH. SLIGHT , LOCALLY MODERATE IN SOUTH. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 20 Nov 2003 10:20, Dag-Erling Smørgrav wrote: Sure, I can do that: ulpt0: Hewlett-Packard officejet d series, rev 1.10/1.00, addr 3, iclass 7/1 ulpt0: using bi-directional mode but it still won't print. Sometimes it works (albeit very, very slowly) but most of the time the process writing to ulpt0 just hangs. When it works, is that when you have been using it in another operating system, and then reboot into FreeBSD and try it? IIRC, some of these multi-function devices require a code sending to them by the printer driver to tell them to behave like printers (instead of being a fax machine or a scanner or whatever). Unfortunately, finding out what that code is and sending it can be tricky. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/vKlcLqgJ90OcaiARAhB9AKCnTINKAW5tZ7t9EVZQlEr7GujSvgCfbx+u e2bNUtyWQgFIKXcMDGFCjZI= =gx+R -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Nate Lawson wrote: On Tue, 18 Nov 2003, Lukas Ertl wrote: I'm gonna try some buildkernelstones with the different settings. If you have some special benchmarks in mind I'd be happy to run them. That's probably ok. It has a lot of IO. Now I've tried running make buildkernel and tarring /usr/src to a different location, with different setting for hw.acpi.cpu.cx_lowest. I couldn't see any real difference - neither in performance nor in heat emission. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Mark Dixon [EMAIL PROTECTED] writes: When it works, is that when you have been using it in another operating system, and then reboot into FreeBSD and try it? I don't think so. BTW, I just reinstalled cups to give the printer another try, and it now seems to work in -CURRENT (knock on wood). It didn't work in -STABLE when I tried a couple of weeks ago, nor did it work in -CURRENT when I tried to use it to print wedding invitations this summer. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
mount problems: file name too long with a 79 character name?
Hi,
---snip---
{71} FreeBSD 5.1-CURRENT [M87:~netchild/FreeBSD/SystemOnCD]
(62) [EMAIL PROTECTED] # realpath work/SystemOnCD-1/usr/ports/distfiles |wc -c
79
{0} FreeBSD 5.1-CURRENT [M87:~netchild/FreeBSD/SystemOnCD]
(63) [EMAIL PROTECTED] # realpath /space/distfiles |wc -c
17
{0} FreeBSD 5.1-CURRENT [M87:~netchild/FreeBSD/SystemOnCD]
(64) [EMAIL PROTECTED] # mount -t unionfs -o -b /space/distfiles
work/SystemOnCD-1/usr/ports/distfiles
unionfs: /space/distfiles: File name too long
{71} FreeBSD 5.1-CURRENT [M87:~netchild/FreeBSD/SystemOnCD]
(65) [EMAIL PROTECTED] # mount -t unionfs -o -b /space/distfiles /mnt
---snip---
The same happens with nullfs, but not with ntfs. I can't find a
documented limitation in the man pages (expect ENAMETOOLONG in mount(2),
but the name is shorter than 255 characters). I also can't find
ENAMETOOLONG in /sys/fs/unionfs/* (as mount_unionfs returns EX_OSERR, so
it isn't the mount_unionfs utility which rejects the mount).
This is with a pre-statfs-changes current. Does this problem still
exists in a recent current? If yes: where does this ENAMETOOLONG come
from?
Bye,
Alexander.
P.S.: I don't complain about the wrong path printed with the error,
looking at the source makes it obvious why this happens and it's easy to
fix this without help.
--
It's not a bug, it's tradition!
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: probing for non-PCI bus
On 20-Nov-2003 Morten Rodal wrote: John Baldwin wrote: On 11-Nov-2003 John Hay wrote: Upgrading a Asus P2L97-DS dual Pentium II 266MHz box, I got this panic when booting: I have the exact same motherboard, only I run with dual Pentium II 300MHz. However I run a beta bios (to support ata disks larger than 32GB) that I got from Asus many years ago. I am using this system as my workstation at home, and it does have an AGP slot (with an nvidia card in). ACPI has worked before, and it still does except is fires off about 4 interrupts (on IRQ20). However I'll have to wait until I get home to provide acpidumps and mptables when I get home. Oof, no MADT table. Your BIOS sucks. :-P Don't use ACPI because PCI interrupts aren't going to work otherwise. Does this system have an AGP slot? Also, do you have a dmesg from before? If I remember correctly I do not have a MADT table either, but ACPI did find the CPUs. We/I'll know more when I get home. acpu_cpu is not the same thing as CPUs listed in the MADT. If there is no MADT, then FreeBSD won't find any APICs and won't be able to trust ACPI PCI interrupt routing. In fact, ACPI will still be trying to route interrupts to the ATPICS, and not to the APICs if the MADT isn't found and used. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic (kernel trap 12 with interrupts disabled) in propagate_priority()
OK; I managed to build yesterday's -CURRENT (I update my local FreeBSD CVS repository mirror from 0347 - 0354 hrs. US/Pacific, daily) on my SMP build machine, and the resulting system appeared fairly normal: it booted to multi-user mode, and I could login via the serial console. (I wasn't expecting the issue with non-recognition of the Realtek 8129 NIC to be resolved yet.) So I ran cvs update against /usr/src, booted to -CURRENT, fired up screen, then script, and started a make buildworld -- then detached the screen and headed in to work. When I reconnected after getting in to work, I saw that the $SUBJECT panic had occurred (cut/paste from serial console): kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xe5 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0545d69 stack pointer = 0x10:0xd9cd4ba0 frame pointer = 0x10:0xd9cd4bc8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 92287 (make) timeout stopping cpus kernel: type 12 trap, code=0 Stopped at propagate_priority+0x219: movzbl 0xe5(%edx),%eax db tr propagate_priority(c4958c80,0,c06fb9a2,1dc,c075dc38) at propagate_priority+0x219 turnstile_wait(c48e9540,c075a300,c585a140,1cc,605) at turnstile_wait+0x33d _mtx_lock_sleep(c075a300,0,c06f66f8,241,605) at _mtx_lock_sleep+0x125 _mtx_lock_flags(c075a300,0,c06f66f8,241,14b) at _mtx_lock_flags+0x98 wait1(c4958c80,d9cd4d10,0,d9cd4d40,c06c10c0) at wait1+0xa5 wait4(c4958c80,d9cd4d10,c071729f,3ee,4) at wait4+0x20 syscall(2f,2f,2f,0,8095500) at syscall+0x300 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (7, FreeBSD ELF32, wait4), eip = 0x8061a38, esp = 0xbfbfda34, ebp = 0xbfbfda50 --- db show pcpu 0 cpuid= 0 curthread= 0xc4958c80: pid 92287 make curpcb = 0xd9cd4da0 fpcurthread = none idlethread = 0xc1d00780: pid 12 idle: cpu0 APIC ID = 0 currentldt = 0x28 spin locks held: db show pcpu 1 cpuid= 1 curthread= 0xc4d8ca00: pid 93010 cc1 curpcb = 0xd9db4da0 fpcurthread = 0xc4d8ca00: pid 93010 cc1 idlethread = 0xc1d00640: pid 11 idle: cpu1 APIC ID = 1 currentldt = 0x28 spin locks held: db I'm not in a super rush to get the machine back up (if it had completed normally, I would have powered it off until tonight), so if I can supply additional information that would help resolve this, please let me know. Serial console is the only access to it while it's running -CURRENT, but I have that access. Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] If you want true virus-protection for your PC, install a non-Microsoft OS on it. Plausible candidates include FreeBSD, Linux, NetBSD, OpenBSD, and Solaris (in alphabetical order). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: probing for non-PCI bus
John Baldwin wrote: acpu_cpu is not the same thing as CPUs listed in the MADT. If there is no MADT, then FreeBSD won't find any APICs and won't be able to trust ACPI PCI interrupt routing. In fact, ACPI will still be trying to route interrupts to the ATPICS, and not to the APICs if the MADT isn't found and used. So I *MUST* run without ACPI? (Not that much of a loss, since I'm not using to anything, other than having to push the powerbutton and having the computer safely shut down) Hopefully there isn't many hardware vendors that have such a bogus ACPI implementation. -- Morten Rodal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
Stijn Hoop wrote: On Wed, Nov 19, 2003 at 09:27:55PM -0800, Tim Kientzle wrote: Maybe it's time to separate these two functions? I would be content to have a static /sbin/sh that is used as the system script interpreter for rc scripts, etc. And /usr/bin/sh as a user shell? I was thinking /bin/sh for the user shell and /sbin/sh for the system script interpreter. There must be a /bin/sh and given that there are many user scripts that rely on it, it seems that it must be a user shell. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Fix for sysinstall (please apply)
Hello, in PR bin/59078 I have submitted a simple fix for sysinstall that allows it to correctly support the Greek locale. In every FreeBSD release so far, one cannot select a greek keymap during the installation and has to be aware of the ways it can be enabled afterwards. This however is not evident to a novice user, who (in my experience) performs most administrative tasks from sysinstall. Since 5.2-RELEASE is just around the corner, I would like to implore some kind soul to review and commit it on time. Regards, -- Panagiotis Astithas Electrical Computer Engineer, PhD Network Management Center National Technical University of Athens, Greece ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
IPFIREWALL_FORWARD kernel config option gone?
Hello all, When trying to bring a box up to date, we noticed that the IPFIREWALL_FORWARD kernel option has been removed somewhere between the 2'nd of this month and now. Has it been obsoleted by other options? I saw nothing in UPDATING rearding this. Here's the info: [EMAIL PROTECTED] src]# make buildkernel KERNCONF=WORKSTATION-5.0-SMP -- Kernel build for WORKSTATION-5.0-SMP started on Thu Nov 20 11:04:18 PST 2003 -- === WORKSTATION-5.0-SMP mkdir -p /usr/obj/usr/src/sys cd /usr/src/sys/i386/conf; PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/ obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/ obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/ i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/ sys/WORKSTATION-5.0-SMP /usr/src/sys/i386/conf/WORKSTATION-5.0-SMP WARNING: unknown option `APIC_IO' removed from /usr/obj/usr/src/sys/ WORKSTATION-5.0-SMP/opt_global.h WARNING: unknown option `IPFIREWALL_FORWARD' removed from /usr/obj/usr/src/ sys/WORKSTATION-5.0-SMP/opt_ipfw.h /usr/src/sys/i386/conf/WORKSTATION-5.0-SMP: unknown option IPFIREWALL_FORWARD *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- Wade Klaver Wavefire Technologies Corporation GPG Public Key at http://archeron.wavefire.com /\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
On Thu, Nov 20, 2003 at 11:20:18AM +0100, Dag-Erling Smørgrav wrote: Alexander Leidinger [EMAIL PROTECTED] writes: I have no problem using my printer: [...] ulpt0: Hewlett-Packard DeskJet 895C, rev 1.00/1.00, addr 4, iclass 7/1 ulpt0: using uni-directional mode Sure, I can do that: ulpt0: Hewlett-Packard officejet d series, rev 1.10/1.00, addr 3, iclass 7/1 ulpt0: using bi-directional mode but it still won't print. Sometimes it works (albeit very, very slowly) but most of the time the process writing to ulpt0 just hangs. My OfficeJet 6110 works great with FreeBSD 5 as of a month ago. I don't print very often. It is prints quickly. My only problem with installation was because apsfilter' setup script didn't know about the 6110 driver parameter for the hpijs driver. Apsfilter seemed to have missed a couple of newer revs of the hpijs drivers. Unfortunately, the box isn't reachable from here or I'd post configs. -- Scott LambertKC5MLE Unix SysAdmin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: probing for non-PCI bus
On 20-Nov-2003 Morten Rodal wrote: John Baldwin wrote: acpu_cpu is not the same thing as CPUs listed in the MADT. If there is no MADT, then FreeBSD won't find any APICs and won't be able to trust ACPI PCI interrupt routing. In fact, ACPI will still be trying to route interrupts to the ATPICS, and not to the APICs if the MADT isn't found and used. So I *MUST* run without ACPI? (Not that much of a loss, since I'm not using to anything, other than having to push the powerbutton and having the computer safely shut down) Hopefully there isn't many hardware vendors that have such a bogus ACPI implementation. Well, for now you must. I intend to fix the priorities of the drivers so that for your case the mptable PCI bridge drivers will be used instead of ACPI, and thus you can still use the rest of ACPI and it will just work out of the box. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: spin lock sched lock held by 0xc25a8640 for 5 seconds
On 20-Nov-2003 Kris Kennaway wrote: I updated bento last night, and it panicked after a few hours with: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 01 fault virtual address = 0xe5 fault code = supervisor read, page not present instruction pointer = 0x8:0xc052e219 stack pointer = 0x10:0xe00d2c3c frame pointer = 0x10:0xe00d2c64 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 40 (irq29: sym0) spin lock sched lock held by 0xc25a8640 for 5 seconds panic: spin lock held too long cpuid = 1; Debugger(panic) Unfortunately it hangs there instead of breaking to DDB. The instruction pointer is in: ... c052e000 t propagate_priority c052e360 T init_turnstiles ... I'm currently rebuilding without WITNESS_SKIPSPIN in case this catches it. Argh, I didn't catch that you trap 12'd before the sched_lock hang. Do you have INVARIANTS on? Also, do you possibly have a kernel.debug around that you could try to figure out what line that IP corresponds to? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: spin lock sched lock held by 0xc25a8640 for 5 seconds
On 20-Nov-2003 Craig Rodrigues wrote: On Thu, Nov 20, 2003 at 11:03:42AM -0800, Kris Kennaway wrote: c052e000 t propagate_priority c052e360 T init_turnstiles Is your crash similar to the one I saw on my system yesterday? No, your real panic was earlier. The pp was a later panic during the buffer sync. Script started on Thu Nov 20 14:50:14 2003 [EMAIL PROTECTED] /opt/crash]% gdb -k /usr/obj/usr/src/sys/MYKERNEL1/kernel.debug vmcore. 0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x6300040 fault code= supervisor read, page not present instruction pointer = 0x8:0xc083611e Can you do a 'l *0xc083611e' on in gdb on your kernel.debug stack pointer = 0x10:0xd3383a24 frame pointer = 0x10:0xd3383a34 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 = 75969 (tcpdump) trap number = 12 panic: page fault cpuid = 0; syncing disks, buffers remaining... panic: sleeping thread (pid 75969) owns a non-sleepable lock This is where pp panic'd. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-CURRENT totally broken on AMD64 in 32-bit mode
On Tue, 18 Nov 2003, Andy Farkas wrote:
The changes that break things were made more than a week ago. I sent this
email last week:
Date: Sun, 9 Nov 2003 09:22:17 +1000 (EST)
From: Andy Farkas [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: kernel halts before booting
My kernels now break into the debugger before booting!
Boot sequence goes like this:
...
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
cpuid = 0; apic id = 00
instruction pointer = 0x0:0xa00
stack pointer = 0x0:0xffe
frame pointer = 0x0:0x0
code segment= base 0x0, limit 0x0, type 0x0
= DPL 0, pres 0, def32 0, gran 0
processor eflags= interrupt enabled, vm86, IOPL = 0
current process = 0 ()
kernel: type 30 trap, code=0
stopped at 0xa00: cli
db
This too has been fixed. Extra cookies for all involved!
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: spin lock sched lock held by 0xc25a8640 for 5 seconds
On Thu, Nov 20, 2003 at 03:17:29PM -0500, John Baldwin wrote:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x6300040
fault code= supervisor read, page not present
instruction pointer = 0x8:0xc083611e
Can you do a 'l *0xc083611e' on in gdb on your kernel.debug
(kgdb) l *0xc083611e
0xc083611e is in _bus_dmamap_unload (/usr/src/sys/i386/i386/busdma_machdep.c:751).
746 void
747 _bus_dmamap_unload(bus_dma_tag_t dmat, bus_dmamap_t map)
748 {
749 struct bounce_page *bpage;
750
751 while ((bpage = STAILQ_FIRST(map-bpages)) != NULL) {
752 STAILQ_REMOVE_HEAD(map-bpages, links);
753 free_bounce_page(dmat, bpage);
754 }
755 }
--
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VMWare build failure
On Thu, 2003-11-20 at 12:38, Ben Paley wrote: Hello all. I think this is a -current issue. When I started using -current I began to get weird behaviour from vmware2: eventually every time I powered on the virtual machine the screen would freeze up so I couldn't get a console, and then the whole machine - the REAL machine, I mean - would reboot. Bit rubbish, huh? [snip] -I. -I@ -I@/../include -I/usr/include -finline-limit=15000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c /usr/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c: In function `cleanup_module': /usr/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c:284: warning: unused variable `retval' /usr/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c:301:35: i386/isa/intr_machdep.h: No such file or directory *** Error code 1 Stop in /usr/ports/emulators/vmware2/work/vmware-distrib/vmmon-only. *** Error code 1 Stop in /usr/ports/emulators/vmware2/work/vmware-distrib/vmmon-only. *** Error code 1 Stop in /usr/ports/emulators/vmware2/work/vmware-distrib. *** Error code 1 Stop in /usr/ports/emulators/vmware2. *** Error code 1 Stop in /usr/ports/emulators/vmware2. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portinstall6065.18 make ** Fix the problem and try again. ** The following packages were not installed or upgraded (*:skipped / !:failed) ! emulators/vmware2 (missing header) First off if you're running -CURRENT you want emulators/vmware3, missing header would conclude you don't have the header installed that it wants. Guessing you're running -CURRENT you have the kernel source installed, so my suggestion is to run vmware3. Unless you have a specific reason to run 2? -- I think we ought to be out there doing what we do best - making large holes in other people's countries. - George Carlin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Current SMP with ACPI dies in a second
John Baldwin writes: Ok, your BIOS is buggy, but I think I can work around it. http://www.FreeBSD.org/~jhb/patches/acpi_irq.patch Thanks, now it's working much better! New dmesg and vmstat-i at http://tomppa.iki.fi/~tomppa/FreeBSD/ Tomppa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Current SMP with ACPI dies in a second
On 20-Nov-2003 Tomi Vainio - Sun Finland wrote: John Baldwin writes: Ok, your BIOS is buggy, but I think I can work around it. http://www.FreeBSD.org/~jhb/patches/acpi_irq.patch Thanks, now it's working much better! New dmesg and vmstat-i at http://tomppa.iki.fi/~tomppa/FreeBSD/ You probably shouldn't be using intpm with acpi by the way. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On 2003-11-20 at 21:51:48 boyd, rounin wrote: think about a dynamically linked init(8) ... % sudo ldd /sbin/init /sbin/init: libutil.so.3 = /lib/libutil.so.3 (0x28074000) libcrypt.so.2 = /lib/libcrypt.so.2 (0x2807f000) libc.so.5 = /lib/libc.so.5 (0x28097000) Yes, working fine here. What should the problem be? pgp0.pgp Description: PGP signature
Re: Unfortunate dynamic linking for everything
From: Dimitry Andric [EMAIL PROTECTED] % sudo ldd /sbin/init /sbin/init: libutil.so.3 = /lib/libutil.so.3 (0x28074000) libcrypt.so.2 = /lib/libcrypt.so.2 (0x2807f000) libc.so.5 = /lib/libc.so.5 (0x28097000) Yes, working fine here. What should the problem be? the day /lib gets smashed. you're building a house of cards. once, if /etc/init and /bin/sh and some other pieces where in place a smashed file-system could be easily fixed. now you have to have 3 shared libs and a viable /lib. do you want systems that work? or houses of cards? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On Fri, Nov 21, 2003 at 12:23:16AM +0100, boyd, rounin wrote: you're building a house of cards. once, if /etc/init and /bin/sh and some other pieces where in place a smashed file-system could be easily fixed. now you have to have 3 shared libs and a viable /lib. do you want systems that work? or houses of cards? Personally, I think init should be static, and can't think of any way it would benefit from shared libraries. I'm not qualified to comment on the various things people have said about /bin/sh. (Possibly irrelevant data point: Solaris 10, if it ever flies, will supposedly have only shared libraries.) Given that you've got a knob if you really care enough to change the default, static init and /rescue should be adequate to get past all the other bickering here, so please stop it already... -- Christopher Vance ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VMWare build failure
Scott Likens wrote: On Thu, 2003-11-20 at 12:38, Ben Paley wrote: Hello all. I think this is a -current issue. When I started using -current I began to get weird behaviour from vmware2: eventually every time I powered on the virtual machine the screen would freeze up so I couldn't get a console, and then the whole machine - the REAL machine, I mean - would reboot. Bit rubbish, huh? [snip] First off if you're running -CURRENT you want emulators/vmware3, missing header would conclude you don't have the header installed that it wants. Guessing you're running -CURRENT you have the kernel source installed, so my suggestion is to run vmware3. Unless you have a specific reason to run 2? Maybe he doesn't run 3 because it also doesn't build: /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/freebsd/driver.c:303:35: i386/isa/intr_machdep.h: No such file or directory /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include/vm_asm.h: In function `Div643264': /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include/vm_asm.h:1033: warning: use of memory input without lvalue in asm operand 4 is deprecated *** Error code 1 Stop in /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only. *** Error code 1 Stop in /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only. *** Error code 1 Stop in /usr/ports/emulators/vmware3/work/vmware-distrib. *** Error code 1 Stop in /usr/ports/emulators/vmware3. *** Error code 1 Stop in /usr/ports/emulators/vmware3. So same thing with vmware3 - note that the file (intr_machdep.h) doesn't exist in that location - but it does in other locations. I tried copying one of the others over to that spot, and rebuilding, but still fails (with new errors as expected).. :( Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
From: Christopher Vance [EMAIL PROTECTED] Personally, I think init should be static, and can't think of any way it would benefit from shared libraries. plan 9 has everything static. the kernel compiles in about 20 seconds or less -- no compression -- and you can boot it off a floppy. if i can sit in /sys/src and type: mk install and have everything re-built (and i could do it for all the supported architectures) in minutes i have eliminated unnecessary complexity. if it's not there, it can't break. btw: say hi to maltby for me. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On Fri, Nov 21, 2003 at 12:23:16AM +0100, boyd, rounin wrote: From: Dimitry Andric [EMAIL PROTECTED] % sudo ldd /sbin/init /sbin/init: libutil.so.3 = /lib/libutil.so.3 (0x28074000) libcrypt.so.2 = /lib/libcrypt.so.2 (0x2807f000) libc.so.5 = /lib/libc.so.5 (0x28097000) Yes, working fine here. What should the problem be? the day /lib gets smashed. This is only marginally different than /sbin/init getting smashed. If the root partition develops problems, you need to restore for tape. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VMWare build failure
Hello! On Thu, Nov 20, 2003 at 04:53:57PM -0600, Eric Anderson wrote: Guessing you're running -CURRENT you have the kernel source installed, so my suggestion is to run vmware3. Unless you have a specific reason to run 2? Maybe he doesn't run 3 because it also doesn't build: /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/freebsd/driver.c:303:35: i386/isa/intr_machdep.h: No such file or directory /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include/vm_asm.h: In function `Div643264': /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include/vm_asm.h:1033: warning: use of memory input without lvalue in asm operand 4 is deprecated *** Error code 1 Stop in /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only. *** Error code 1 Stop in /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only. *** Error code 1 Stop in /usr/ports/emulators/vmware3/work/vmware-distrib. *** Error code 1 Stop in /usr/ports/emulators/vmware3. *** Error code 1 Stop in /usr/ports/emulators/vmware3. So same thing with vmware3 - note that the file (intr_machdep.h) doesn't exist in that location - but it does in other locations. I tried copying one of the others over to that spot, and rebuilding, but still fails (with new errors as expected).. vmware3 port was fixed for non-SMP recently. please update your ports. /fjoe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
From: Steve Kargl [EMAIL PROTECTED] This is only marginally different than /sbin/init getting smashed. If the root partition develops problems, you need to restore for tape. tape? who uses tape? optical, my son. brother, can you spare a TU-16? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
Garance A Drosihn wrote: At 6:26 PM +0100 11/17/03, Julian Stacey wrote: Seconded ! Better commit an improved switch with default = Off. The time for voting was months ago. Actually, the discussion started almost a year ago now. That's when the new PAM/NSS libraries were first being announced, which was a big driving factor for all-dynamic linking. I recall quite a bit of that discussion happening right here on [EMAIL PROTECTED] Many of us here have been hamstrung by systems that didn't provide a static fallback. I've personally been bitten by unrecoverable Linux and Solaris systems due to hosed shared libraries. That's why I volunteered to build /rescue in the first place, so that I'd never be faced with an unrecoverable FreeBSD machine. I'm pretty comfortable with the failsafes that we have in place: * /sbin/init is static * If /bin/sh fails, /rescue/sh can be run * /rescue provides a complete set of statically-linked sysadmin utilities that should be sufficient for recovering a damaged system. There are a few things I'd like to see: * It would be nice if the kernel noticed that /sbin/init failed too quickly and prompted the user for an alternate init. That would open the door to a dynamic or just more ambitious /sbin/init, since you could always fall back to /rescue/init for recovery. * /rescue/vi is currently unusable if /usr is missing because the termcap database is in /usr. One possibility would be to build a couple of default termcap entries into ncurses or into vi. If there are still rough edges on some of this well, that is what -CURRENT is all about, after all. ;-) Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Thu, Nov 20, 2003 at 16:31 , while impersonating an expert on the internet, Tim Kientzle sent this to stdout: Garance A Drosihn wrote: At 6:26 PM +0100 11/17/03, Julian Stacey wrote: Seconded ! Better commit an improved switch with default = Off. The time for voting was months ago. Actually, the discussion started almost a year ago now. That's when the new PAM/NSS libraries were first being announced, which was a big driving factor for all-dynamic linking. I recall quite a bit of that discussion happening right here on [EMAIL PROTECTED] Many of us here have been hamstrung by systems that didn't provide a static fallback. I've personally been bitten by unrecoverable Linux and Solaris systems due to hosed shared libraries. That's why I volunteered to build /rescue in the first place, so that I'd never be faced with an unrecoverable FreeBSD machine. Happened to me in the past too. I'm pretty comfortable with the failsafes that we have in place: * /sbin/init is static * If /bin/sh fails, /rescue/sh can be run * /rescue provides a complete set of statically-linked sysadmin utilities that should be sufficient for recovering a damaged system. There are a few things I'd like to see: * It would be nice if the kernel noticed that /sbin/init failed too quickly and prompted the user for an alternate init. That would open the door to a dynamic or just more ambitious /sbin/init, since you could always fall back to /rescue/init for recovery. * /rescue/vi is currently unusable if /usr is missing because the termcap database is in /usr. One possibility would be to build a couple of default termcap entries into ncurses or into vi. Considering that rescue mode will most often be run from a console login or a serial console, I would thing the default console name termcap [cons25] and something ubuiquitous such as vt102 would do quite well - as you could cover almost all with just those two. That surely beats older systems where all I had in recovery attempts was echo to see what was there, and ed for editing. I like your idea. Bill -- Bill Vermillion - bv @ wjv . com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
From: Tim Kientzle [EMAIL PROTECTED] Many of us here have been hamstrung by systems that didn't provide a static fallback. I've personally been bitten by unrecoverable Linux and Solaris systems due to hosed shared libraries. bingo. a small set of tools will usually save you. vi(1) is out of the question because it is too complex. init, sh, echo, cat, ed, sed, fsck (and 'once upon a time' fsdb) should do it. remove dynamic linking and you remove Yet Another Band-Aid. the kernel should be able to page stuff right which should eliminate the need for this folly. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
Hi Garance cc current, Thanks for your well explained posting. I won't distract from new thread Unfortunate dynamic linking for everything except to note: It is not fair to pretend that this was some kind of back-room, closed-door decision. Sorry, I didn't mean to imply that. I meant: - Current@ readers (that decide things), may have different skill levels preference of balance between risk function, compared with other user groups EG perhaps on hackers@ /or isp@ etc. - Some admins don't read @freebsd.org lists, to comment on the fully dynamic decision, but will later install default systems `out of the box', with later subsequent remote upgrades. - Any extra later danger / limitation to them could affect FreeBSD reputation. If you personally are worried about the new setup, then just use the switch which gives you the previous setup. Did it immediately, Thanks. Julian - Julian Stacey. Munich Unix Net Consultancy available. http://berklix.com Ihr Rauchen = mein allergischer Kopfschmerz ! Schnupftabak probieren. All HTML mail automaticaly deleted unread as Spam. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR kernel trap
I am build freebsd-current w/ cvs snap on 2003.11.11
and have some problem:
1. LOR
lock order reversal
1st 0xc1b05690 rtentry (rtentry) @ /usr/src/sys/net/rtsock.c:388
2nd 0xc15e187c radix node head (radix node head) @ /usr/src/sys/net/route.c:1114
Stack backtrace:
backtrace(c06126bc,c15e187c,c061775a,c061775a,c06177b0) at backtrace+0x17
witness_lock(c15e187c,8,c06177b0,45a,1) at witness_lock+0x672
_mtx_lock_flags(c15e187c,0,c06177b0,45a,c1b05690) at _mtx_lock_flags+0xba
rt_setgate(c1b05600,c1ad6440,c1b05b78,185,0) at rt_setgate+0x3b8
route_output(c0e11500,c16fc550,b0,c0e11500,1f50) at route_output+0x6aa
raw_usend(c16fc550,0,c0e11500,0,0) at raw_usend+0x73
rts_send(c16fc550,0,c0e11500,0,0) at rts_send+0x35
sosend(c16fc550,0,c6a8bc7c,c0e11500,0) at sosend+0x44d
soo_write(c1a01c38,c6a8bc7c,c1b74780,0,c1afd000) at soo_write+0x70
dofilewrite(c1afd000,c1a01c38,8,bfbfe870,b0) at dofilewrite+0xf8
write(c1afd000,c6a8bd10,c062c0e1,3ee,3) at write+0x6e
syscall(2f,2f,2f,8,3) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4), eip = 0x28283c2f, esp = 0xbfbfe65c, ebp = 0xbfbfe688 ---
2. kernel trap
cpuid = 0 acic id = 00
ip 0x8:0xc04955ed
sp 0x10:0xc6a8babc
fp 0x10:0xc6a8bac0
code segment base 0 limit f type 0x1b DPL 0 pres 1 def32 1 gran 1
eflags interrupt enabled IOPL = 0
current process 562 (ppp)
kernel: type 30 trap, code = 0
stopet at critical_exit+0x2d: jmp critical_exit+0x36
gdb -k /.1/obj/usr/src/sys/SLW/kernel.debug
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
(kgdb) l *0xc04955ed
0xc04955ed is in critical_exit (machine/cpufunc.h:358).
353 }
354
355 static __inline void
356 write_eflags(u_int ef)
357 {
358 __asm __volatile(pushl %0; popfl : : r (ef));
359 }
360
361 static __inline void
362 wrmsr(u_int msr, u_int64_t newval)
--
Slawa Olhovchenkov
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
In message: [EMAIL PROTECTED] boyd, rounin [EMAIL PROTECTED] writes: : Yes, working fine here. What should the problem be? : : the day /lib gets smashed. /rescue/sh Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Another panic
FreeBSD bogushost2 5.1-CURRENT FreeBSD 5.1-CURRENT #7: Tue Nov 18 18:36:56 EST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARL5KERNEL i386
Another panic that occured just after loading and attempting to play an audio CD:
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc04c81b4 in boot (howto=0x100) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc04c8558 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc05eaf9c in trap_fatal (frame=0xd87e8c28, eva=0x0) at
/usr/src/sys/i386/i386/trap.c:821
#4 0xc05eac62 in trap_pfault (frame=0xd87e8c28, usermode=0x0, eva=0x1c) at
/usr/src/sys/i386/i386/trap.c:735
#5 0xc05ea7fd in trap (frame=
{tf_fs = 0xc0c30018, tf_es = 0xc44a0010, tf_ds = 0xc44a0010, tf_edi = 0x0,
tf_esi = 0xc44a9d00, tf_ebp = 0xd87e8c80, tf_isp = 0xd87e8c54, tf_ebx = 0xc44985a0,
tf_edx = 0x0, tf_ecx = 0xc0658844, tf_eax = 0x1, tf_trapno = 0xc, tf_err = 0x0, tf_eip
= 0xc04e4b53, tf_cs = 0x8, tf_eflags = 0x10207, tf_esp = 0xd87e8c98, tf_ss =
0xc048f6ae})
at /usr/src/sys/i386/i386/trap.c:420
#6 0xc05dc758 in calltrap () at {standard input}:94
#7 0xc0494058 in g_destroy_provider (pp=0xc44985a0) at
/usr/src/sys/geom/geom_subr.c:426
#8 0xc0491015 in g_orphan_register (pp=0xc44a9d00) at
/usr/src/sys/geom/geom_event.c:143
#9 0xc049113c in one_event () at /usr/src/sys/geom/geom_event.c:169
#10 0xc0491365 in g_run_events () at /usr/src/sys/geom/geom_event.c:202
#11 0xc0492385 in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:134
#12 0xc04b14b0 in fork_exit (callout=0xc0492360 g_event_procbody, arg=0x0, frame=0x0)
at /usr/src/sys/kern/kern_fork.c:793
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
boyd, rounin wrote: From: Dimitry Andric [EMAIL PROTECTED] % sudo ldd /sbin/init /sbin/init: libutil.so.3 = /lib/libutil.so.3 (0x28074000) libcrypt.so.2 = /lib/libcrypt.so.2 (0x2807f000) libc.so.5 = /lib/libc.so.5 (0x28097000) Yes, working fine here. What should the problem be? the day /lib gets smashed. you're building a house of cards. once, if /etc/init and /bin/sh and some other pieces where in place a smashed file-system could be easily fixed. now you have to have 3 shared libs and a viable /lib. do you want systems that work? or houses of cards? I would prefer to solve this problem using a fixit floppy or cdrom anyways. I don't think that creates a house of cards. My systems work just fine. But I've often wondered how frequently a production system has such problems. I've been a sysadmin for many years and can't remember this ever happening. It's much more common to blow a hard drive, or have flaky memory, etc. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
boyd, rounin wrote: From: Christopher Vance [EMAIL PROTECTED] Personally, I think init should be static, and can't think of any way it would benefit from shared libraries. plan 9 has everything static. the kernel compiles in about 20 seconds or less -- no compression -- and you can boot it off a floppy. if i can sit in /sys/src and type: mk install and have everything re-built (and i could do it for all the supported architectures) in minutes i have eliminated unnecessary complexity. if it's not there, it can't break. btw: say hi to maltby for me. plan9 doesn't count. It's so minimalistic, it's useless. It has many beautiful and brilliant ideas. But it's not useful to many people as a production system. It's a shame, really. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
Tim Kientzle wrote: I'm pretty comfortable with the failsafes that we have in place: * /sbin/init is static * If /bin/sh fails, /rescue/sh can be run * /rescue provides a complete set of statically-linked sysadmin utilities that should be sufficient for recovering a damaged system. There are a few things I'd like to see: * It would be nice if the kernel noticed that /sbin/init failed too quickly and prompted the user for an alternate init. That would open the door to a dynamic or just more ambitious /sbin/init, since you could always fall back to /rescue/init for recovery. * /rescue/vi is currently unusable if /usr is missing because the termcap database is in /usr. One possibility would be to build a couple of default termcap entries into ncurses or into vi. Just put a tiny termcap file in /rescue (i.e. termcap.rescue) that contains 5 or 6 of the most common terminal types (cons25, vt102, etc), and have /rescue/vi default to cons25. That is cleaner than hard coding them into /rescue/vi. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
plan9 doesn't count. It's so minimalistic, it's useless. well, try to think about non-minimalism when you're trying to track down a kernel bug in a zillion SLOC ... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On Fri, 21 Nov 2003 03:37:20 +0100, boyd, rounin [EMAIL PROTECTED] said: well, try to think about non-minimalism when you're trying to track down a kernel bug in a zillion SLOC ... How about trying to think about FreeBSD when posting on the FreeBSD mailing-lists. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Thanks for the patches to try! They unfortunately didn't fix the crash I have, but I found out why it's occurring. See ohci.c:1389: if (std-td.td_cbp != 0) len -= le32toh(std-td.td_be) - le32toh(std-td.td_cbp) + 1; In one of my transfers (look in my log for the 2560 byte one) that statement actually adds 8192 to len, which is utterly bogus because you can see it only allocates 2560 -- hence when it tries to finish the transfer it memcpy()'s way too much memory and my kernel segfaults. If I #if 0 this out, I'm left only with umass0: BBB reset failed, STALLED messages... which is a lot better than before! I don't know under what situations that bit of code makes sense, but it definitely needs more reviewing! Please check out my debugging messages and tell me if you see any hints as to why the transfers are getting stalled. I should have looked at the debugging messages long ago, I guess. Thanks! http://green.homeunix.org/~green/ohci-debugging.txt.gz -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Brian F. Feldman [EMAIL PROTECTED] wrote: Thanks for the patches to try! They unfortunately didn't fix the crash I have, but I found out why it's occurring. See ohci.c:1389: if (std-td.td_cbp != 0) len -= le32toh(std-td.td_be) - le32toh(std-td.td_cbp) + 1; In one of my transfers (look in my log for the 2560 byte one) that statement actually adds 8192 to len, which is utterly bogus because you can see it only allocates 2560 -- hence when it tries to finish the transfer it memcpy()'s way too much memory and my kernel segfaults. If I #if 0 this out, I'm left only with umass0: BBB reset failed, STALLED messages... which is a lot better than before! I don't know under what situations that bit of code makes sense, but it definitely needs more reviewing! Please check out my debugging messages and tell me if you see any hints as to why the transfers are getting stalled. I should have looked at the debugging messages long ago, I guess. Thanks! http://green.homeunix.org/~green/ohci-debugging.txt.gz BTW, replying to myself -- it seems to be something missing from the multi-allocation transfers (8KB), because I can do up to 8KB transfers perfectly fine now, but 10KB ones, for example, like mdir(8) does are the ones that give me BBB stalls. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
From: Bruce M Simpson [EMAIL PROTECTED] During my time in an investment bank, installations were usually hosed in this way by human error (systems administrators removing a file by accident, etc) ... yup, it's rare i've seen flakey h/w. but i do remember one sysadmin (when i was a contract sysadmin) who on day 2 chown'd the whole source tree to himself on a development m/c. ugly. there were backups but 'that would be too costly [in time]' to do a clean restore. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
systat drive list
Low priority, but easy to accomplish:
Now that my eisa scsi disk controllers are working again, I'd like to
monitor the 8 drives attached with systat(1), except its broken.
Would someone like to commit this trivial patch? (see pr bin/59220)
cd /usr/src/usr.bin/systat/
ident devs.c
devs.c:
$FreeBSD: src/usr.bin/systat/devs.c,v 1.9 2003/10/20 20:13:50 phk Exp $
diff -u devs.c-orig devs.c
--- devs.c-orig Fri Nov 21 13:23:33 2003
+++ devs.c Fri Nov 21 13:46:14 2003
@@ -280,12 +280,12 @@
;
if (*cp)
*cp++ = '\0';
- if (cp - args == 0)
+ if (cp - tmpstr1 == 0)
break;
for (i = 0; i num_devices; i++) {
asprintf(buffer, %s%d,
dev_select[i].device_name,
dev_select[i].unit_number);
- if (strcmp(buffer, tmpstr1) == 0) {
+ if (strcmp(tmpstr1, buffer) == 0) {
num_devices_specified++;
@@ -303,8 +303,8 @@
free(buffer);
}
if (i = num_devices)
- error(%s: unknown drive, args);
- args = cp;
+ error(%s: unknown drive, tmpstr1);
+ tmpstr1 = cp;
}
free(tmpstr);
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
In message [EMAIL PROTECTED], boyd, rounin write s: From: Bruce M Simpson [EMAIL PROTECTED] During my time in an investment bank, installations were usually hosed in this way by human error (systems administrators removing a file by accident, etc) ... yup, it's rare i've seen flakey h/w. but i do remember one sysadmin (when i was a contract sysadmin) who on day 2 chown'd the whole source tree to himself on a development m/c. ugly. there were backups but 'that would be too costly [in time]' to do a clean restore. I've seen that too. An end user got permission from management to the root account, e.g. management ordered us to give her the root pw on a Tru64 box. She chowned every file on the system to herself. Very ugly indeed. Cheers, -- Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/ BC Government . FreeBSD UNIX [EMAIL PROTECTED] . [EMAIL PROTECTED] http://www.gov.bc.ca/ .http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help request: problems with a 5.1 server and large numbers of ssh users.
On Wed, 19 Nov 2003, Len Sassaman wrote: It is my intuition from this behavior that the sshd master process listening for connections is unable to spawn a new process to complete the authentication step, and thus the connection is being dropped. There is no information of use in dmesg, nor in the system logs. (I've cranked up LogLevel to DEBUG3 in sshd_config). I have a RedHat Linux server running the 2.4.18-3smp kernel on a dual Athlon MP 1800+ and 2048MB RAM that is known to handle 1000 users without issue -- so I have to believe the FreeBSD box, though not as beefy hardware-wise, should be able to do better than a few hundred users. I believe this to be some sort of resource limit issue, but I have addressed everything I could think of. Hmm. Well, it certainly sounds like a resource limit to me, especially if it's a nice round number like 150 or 300. However, I'm also having a bit of trouble seeing, off the top of my head, which limit it might be. It sounds like you've got the ones I would think of. A quick skim of sshd.c suggests that it is pretty careful to document various failure modes in debugging output. There are one or two failures where it does not log, and they include the call to pipe() in the server loop -- if that fails, it bails without an error, which is a little surprising. Could you post server debug output for the first connection to the server that fails? This would let us see how far it got... In particular, whether it did spawn a child process, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help request: problems with a 5.1 server and large numbers of ssh users.
On Thu, Nov 20, 2003 at 10:56:08AM -0500, Robert Watson wrote: Hmm. Well, it certainly sounds like a resource limit to me, especially if it's a nice round number like 150 or 300. One possibility might be running out of pseudo-terminals to support the login sessions. pty's are created as needed I think, and the code that handles it is in sys/kern/tty_pty.c. The limits on it appear to be 256 ptys: /* * This function creates and initializes a pts/ptc pair * * pts == /dev/tty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv] * ptc == /dev/pty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv] * * XXX: define and add mapping of upper minor bits to allow more * than 256 ptys. */ I don't know if simply changing the : static char *names = pqrsPQRS; to something longer is all that would be required or if there are other factors involved. -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help request: problems with a 5.1 server and large numbers of ssh users.
On Thu, 20 Nov 2003, Ken Smith wrote: On Thu, Nov 20, 2003 at 10:56:08AM -0500, Robert Watson wrote: Hmm. Well, it certainly sounds like a resource limit to me, especially if it's a nice round number like 150 or 300. One possibility might be running out of pseudo-terminals to support the login sessions. pty's are created as needed I think, and the code that handles it is in sys/kern/tty_pty.c. The limits on it appear to be 256 ptys: I thought about that, but the submitter indicated that pty's were not being allocated. However, that would be a really good thing to verify, since the numbers come out right... I should really clean up and commit my pty cleanup at some point, as well as support for forkpty()/openpty()/etc that avoid the sort of code found below. Presumably that would be a 5.3 thing. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories /* * This function creates and initializes a pts/ptc pair * * pts == /dev/tty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv] * ptc == /dev/pty[pqrsPQRS][0123456789abcdefghijklmnopqrstuv] * * XXX: define and add mapping of upper minor bits to allow more * than 256 ptys. */ I don't know if simply changing the : static char *names = pqrsPQRS; to something longer is all that would be required or if there are other factors involved. -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help request: problems with a 5.1 server and large numbers of ssh users.
Len Sassaman wrote: The problem is that after about 150 users log in (300ish sshd sessions, since I am using privsep), incoming connections start getting dropped. That number (150) sounds awfully familiar; I feel like I've seen it somewhere recently. H Try an 'fstat' when connections start getting dropped. I wonder if something (PAM module, maybe?) is opening a file on each connection and you're running out of per-process file descriptors. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help request: problems with a 5.1 server and large numbers of ssh users.
Hmm. Well, it certainly sounds like a resource limit to me, especially if it's a nice round number like 150 or 300. However, I'm also having a bit of trouble seeing, off the top of my head, which limit it might be. It sounds like you've got the ones I would think of. A quick skim of sshd.c suggests that it is pretty careful to document various failure modes in debugging output. There are one or two failures where it does not log, and they include the call to pipe() in the server loop -- if that fails, it bails without an error, which is a little surprising. Could you post server debug output for the first connection to the server that fails? This would let us see how far it got... In particular, whether it did spawn a child process, etc. I have never gotten this to fail when sshd is running in debug mode (i.e., sshd -ddd). However, given that it doesn't fork when run with -d, that still doesn't tell us too much. When I set LogLevel DEBUG3, this is as much info as I am given in the auth.log: Nov 20 16:39:19 clyde sshd[63993]: Failed none for rabbi from 127.0.0.1 port 62701 ssh2 And this is the debug output for the connection, as seen from the client: bash-2.05b# ssh -vvv -l rabbi localhost OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug2: ssh_connect: needpriv 0 debug1: Connecting to localhost [::1] port 22. socket: Protocol not supported debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /root/.ssh/identity type -1 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 ssh_exchange_identification: Connection closed by remote host This can't be a system-wide process related resource issue, I don't think, because once a user connects and authenticates, there are no problems of note. I'm leaning toward a socket related limit or user-level limit. However, since sysctl tells me: kern.ipc.maxsockbuf: 262144 kern.ipc.somaxconn: 16384 kern.ipc.numopensockets: 2201 kern.ipc.maxsockets: 49312 I tend to not believe the former, and why the latter would be occurring escapes me as well. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help request: problems with a 5.1 server and large numbers of ssh users.
Tim Kientzle wrote: Try an 'fstat' when connections start getting dropped. I wonder if something (PAM module, maybe?) is opening a file on each connection and you're running out of per-process file descriptors. A similar thing happened here - although it wasn't sshd at fault. Len mentioned using ldap authentication. nss_ldap and/or pam_ldap are use TCP connections to connect to the LDAP server. In my case there was another big consumer of persistent ldap connections that caused slapd to reach its default 1024 descriptor limit (which required a compile-time adjustment). Found this by tracing the master slapd process. -Jamie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4 Clause license?
Erik Trulsson wrote: On Mon, Nov 17, 2003 at 02:48:08PM -0500, Rod Taylor wrote: The PostgreSQL group has recently had a patch submitted with a snippet of code from FreeBSDs src/bin/mkdir/mkdir.c. http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?annotate=1.27 Is this intentionally under the 4 clause license or does the copyright from the website (2 clause) applied to everything that is non-contrib? http://www.freebsd.org/copyright/freebsd-license.html That copyright notice on the website should apply to everything that is not under some other license. Different parts of the system is under different licenses and copyrights depending on who wrote it. The mkdir.c *was* under the 4 clause license. However all material that was part of the original BSDs and thus was copyrighted by The Regents of the University of California has had its license changed such that clause 3 (the advertising clause) no longer apply. People seem to frequently misunderstand what a license is, and more specifically, what the conversion from a 4 clause to a 3 clause license meant, in the case of the UCB License. This change does not apply to derivative works, only to the original code itself. So if you went back and grabbed the mkdir.c code off the BSD 4.4-Lite2 CDROM, and used that, fine. If you grabbed the mkdir.c off the FreeBSD sources, and even one line was modified by someone, then it's a derivative work, and, unless you can also get written permission from the contributor, it stays under the license from which it was derived. The announcement by the University only permits the change, it does not mandate the change, for this very reason: otherwise third party redistributed code would have sudddenly become legally questionable. By the same token, if you dual-license some code under th GPL and another license, and someone gets the GPL'ed version, and makes changes, unless thy specifically permit it, the code contributed back is only licensed under the GPL. This is why SGI licensing the XFS code under the GPL was a stupid move: a contributer contributing code back results in an improved code base that can only be used under the terms of the GPL, and not in SGI's commercial product offerings. I believe that SGI did not actually expect any significant or worthwhile bug fixes or enhancements to come from the GPL'ed code using community. In terms of getting written approval for the license change from other contributors, this is basically the role that the Regents of the University of California and the UCB CSRG were fulfilling: a legal entity to whom such representations could be made by contributors, and who could then legally forward those representations to another. FreeBSD has no such legal entity, at present. The closest you could come is perhaps the FreeBSD Foundation. Had there been a FreeBSD Foundation from day on, to whom rights could have been assigned by contributors (turning it into The FreeBSD Foundation and its Contributors), then the license would be capable of being modified after the fact. Without that, however, you must track down all of the individual contributors to get the license changed. My recommendation is to us the code off the 4.4 BSD-Lite2 CDROM, if you can, live with the 4 clause license if the code contains changes you need, if you can, or contact the contributors, if it is a small enough job. If none of those things will work for you, then start with the 4.4 BSD-Lite2 CDROM code, convert to the 3 clause license, as permitted by the university, and then hack out whatever modifications you ned on top of that for yourself. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
