PR bin/25110 - pthreads signal handling problem
I'm wondering if anyone has the time or inclination to take a look at a fix for PR bin/25110. We're having problems using a freshly-built 4.2-stable box (technically 4.3 rc at this point), and the bug is still present. I'm not sure how many people would see this problem (we see it because we have to compile Apache 1.x with the -pthread switch due to add-on modules that are threaded). Under 4.1-stable, everything was fine. At some point between 4.1-stable and 4.2-release, something changed, but my hunt through the CVS repository hasn't revealed anything obvious. In any case, it's a repeatable bug (the PR includes a code sample) and unless looked at, it will be a bug in 4.3-release. If there's any clarification needed, please let me know. TIA. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
* Chris Dillon ([EMAIL PROTECTED]) [001113 08:22]: Since you can select the LUN and not the ID, maybe they've mapped SCSI ID0:LUN0 to ID0:LUN0 (duh), ID1:LUN0 to ID0:LUN1, ID2:LUN0 to ID0:LUN2, and so on, which would explain why we only see a device at ID0:LUN0 if we aren't looking at the remaining LUNs (are we?). This would mean that you can't use multi-LUN devices with the USB-SCSI converter, but that is much more acceptable than only being able to use ID0 with it. I think this is what they do, as my test with a multi-LUN CD changer which works find as a SCSI device only shows up as one CD-ROM under both Windows and BSD. Time to hit up Microtech support to see if they'll at least admit that this is what their driver does. The question then is if we are to implement this kind of ID-to-LUN mapping in the umass driver, what do we predicate that behaviour on ? -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
* Chris Dillon ([EMAIL PROTECTED]) [001113 08:22]: On Sun, 12 Nov 2000, Nick Hibma wrote: I don't know. The only thing I know is that the protocol on the USB wire does not let you select the SCSI id, just the LUN. Since you can select the LUN and not the ID, maybe they've mapped SCSI ID0:LUN0 to ID0:LUN0 (duh), ID1:LUN0 to ID0:LUN1, ID2:LUN0 to ID0:LUN2, and so on, which would explain why we only see a device at ID0:LUN0 if we aren't looking at the remaining LUNs (are we?). This would mean that you can't use multi-LUN devices with the USB-SCSI converter, but that is much more acceptable than only being able to use ID0 with it. I've got a Nakamichi mj-4.8s (4 disc scsi jukebox) at home that I can put in an external case to test this premise. It comes up as the chosen ID and LUNS 0-3. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
* Nick Hibma ([EMAIL PROTECTED]) [001112 06:01]: I don't know. The only thing I know is that the protocol on the USB wire does not let you select the SCSI id, just the LUN. I've confirmed that under Windows this cable works with any SCSI ID, but only if you install the Microtech driver. Otherwise, it doesn't show up (i.e. identical to FBSD). Presuming that their driver is actually just a ID mapping layer, would the same thing be feasible under BSD? I'll fire off a note to their support people and see if they can at least confirm my line of thinking here. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
* Nick Hibma ([EMAIL PROTECTED]) [001109 17:31]: Hm, I missed the zip story. You seem to have all the bits that are necessary in your kernel. Could you compile your kernel/module with UMASS_DEBUG defined and send me the output after an attach? As it turns out, I got it working, but only when the device is on SCSI ID 0. Any other SCSI id and the device is not found when I run 'camcontrol rescan 0' The output is rather large, so I put it on a web server: http://people.targetnet.com/~james/dmesg.plugin http://people.targetnet.com/~james/dmesg.rescan (plugin is the dmesg output when I plugged it into the USB port, and rescan is the additional output when I ran camcontrol rescan 0). Thanks. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
USB-to-SCSI converter
I have a Microtech USB to SCSI converter (see http://www.microtechint.com/qs-usbscsi.html for details). Under Windows (having installed the driver that comes with), everything works without issue. Under BSD, I get this on boot: umass0: Microtech International, Inc. USB-SCSI-HD50, rev 1.00/1.00, addr 3 umass0: Get Max Lun not supported (STALLED) Are there any known workarounds for this problem ? In my particular application I won't be using multi-lun devices, but I don't think that making a "maxlun=0" assumption is a good thing to do. Are there any known workarounds for this problem ? Thanks. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
* Nick Hibma ([EMAIL PROTECTED]) [001109 14:52]: This is not a problem as the thing works although it displays the message. Because it does not support the call it gives an indication that multi LUN devices are not supported. I have one of these cables and managed to newfs a 4Gb SCSI drive. Was anything connected to the cable when you connected it? Yes, I've tried with a Yahama external CDR and a Syquest Syjet drive. In neither case did the device show up on the probe. I do have "SCSI over USB" working on the box, since I regularly use a USB zip drive on the same machine and it comes up as device da0 right after the 'umass-sim0' probe. Can you share your kernel config and/or dmesg for that 4gb drive you mention ? Thanks. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Repeatable STL core with -pthread
We're having a problem with threaded programs that use the STL. Given the
following program:
--START--
#include string
#include pthread.h
typedef mapint, int mymap_t;
#ifdef GLOBLOCK
pthread_mutex_t glob_mut;
#endif
void *run(void *) {
while (1) {
string f("");
#ifdef GLOBLOCK
pthread_mutex_lock(glob_mut);
#endif
f += "adsasd";
f += "adsasd";
f += "adsasd";
#ifdef GLOBLOCK
pthread_mutex_unlock(glob_mut);
#endif
}
}
int main () {
#define FOO 50
pthread_t thread[FOO];
for(int x =0;xFOO;x++) {
pthread_create(thread[x], NULL, run, NULL);
}
for(int x =0;xFOO;x++) {
pthread_join(thread[x], NULL);
}
exit(0);
}
---END---
When compiled like so:
c++ -g -pthread -o stl_core.cc stl_core.cc
The program will core after about 10 seconds, every time. When compiled
with -DGLOBLOCK, it runs without fail. I have tried this using gcc 2.95.1,
2.95.2, egcs-20001002 and 20001106 without success. I have also tried using
the linuxthreads port, and with Matt Dillon's lowmem patch (can't remember
the URL offhand) and with Daniel Eischen's libc_r patches against -stable.
Under RedHat Linux 7.0 (kernel 2.2.16) using gcc 2.96 (development version),
the program works fine.
It would appear that there is an issue with some low-level allocator in the
STL as shipped in 4.x. Because everything in the STL is build around said
allocator, this fails for almost anything that uses STL (the original test
program I used allocated a map rather than a string).
I'd appreciate any ideas this brings forth in people.
Thanks.
--
j.
James FitzGibbon [EMAIL PROTECTED]
Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Determining multi or single user ?
Greetings... Is there an standard programmatic method for determining if a FreeBSD system is running in single or multi-user ? Sysctl doesn't seem to have a specific entry, but I suspect that the value of other less-well defined sysctl values might allow me to infer what I need. Any thoughts ? -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Panics when using Mylex RAID with SMP under RELENG_4
* Drew Eckhardt ([EMAIL PROTECTED]) [000502 13:24]: In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: I am trying to run a Mylex Acceleraid 1100 in a Dell Poweredge 2450. What is a Dell Poweredge 2450, in terms of chipset and processors? Dual 600 PIII, 256k cache. 512mb PC133 RAM. Serverworks RCC LE chipset. Adaptec 7899 Ultra160 SCSI controller. To add another datapoint: I just swapped the 350MHz PII in my Super Micro P6DGS (your generic 440GX dual slot-1 board) for a pair of PIII600Es. Since then, I have been getting panics under both 4.0 and 5.0 current from trap 29 that seem correlated to IDE disk I/O load. The first crash dump I grabbed showed that the faulting address was idle_loop + 64, which is at the cli instruction. Trap 29 could come from processor fault 19 (SIMD), an APIC, or PIC. Since cli isn't a SIMD instruction, I suspect the APICs or PICs but have yet to instrument and test this hypothesis. tf_eip = -1071757093, tf_cs = 8, tf_eflags = 582, tf_esp = 0, tf_ss = -8359936}) at ../../i386/i386/trap.c:586 (kgdb) What do you get when you feed kgdb frame 3 info line * (void *)frame-tf_eip (kgdb) info line * (void *)frame-tf_eip No line number information available for address 0xc01e48db idle_loop+64 (kgdb) Well, at least that matches it to your problem. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Panics when using Mylex RAID with SMP under RELENG_4
I am trying to run a Mylex Acceleraid 1100 in a Dell Poweredge 2450. When
running rawio against the mylex partition, the system panics within 2
minutes, always with a trap #29. I have kernel dumps for four panics, but
kgdb doesn't show any similarities between the panics (other than that they
are all #29).
This is using RELENG_4 cvsupped recently, and the APIC patch is in. I've
tried using a kernel both with and without Matt Dillon's experimental SMP
patch, but both cause problems.
If I boot this machine with kernel.GENERIC (no SMP), then rawio completes
successfully. If I run the test on a single SCSI drive not attached to the
Mylex, it completes without error regardless of whether I am using
kernel.GENERIC or my SMP-enabled kernel.
I'm wondering if anyone can help debug this problem. I can make the box
accessible on the net and give an account to anyone with sufficient
knowledge to help; I can also send the kernel dumps to anyone who is
interested.
I've looked over the CVS repository to see if there have been changes to the
driver in -CURRENT, and there do appear to be changes, but I'm not sure if
they might fix this problem. If they might, I'll install the latest current
snapshot and give it a shot, but if that avenue won't do any good I'd rather
not bother. Any info along those lines is also appreciated.
The traps almost always look like this in kgdb:
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc014b574 in poweroff_wait (junk=0xc0216039, howto=0)
at ../../kern/kern_shutdown.c:554
#2 0xc01e587e in trap_fatal (frame=0xff806fbc, eva=0)
at ../../i386/i386/trap.c:926
#3 0xc01e5242 in trap (frame={tf_fs = 24, tf_es = -1071448048, tf_ds = 16,
tf_edi = -1, tf_esi = 0, tf_ebp = 0, tf_isp = -8359960, tf_ebx = 0,
tf_edx = 160165, tf_ecx = 1, tf_eax = 0, tf_trapno = 29, tf_err = 0,
tf_eip = -1071757093, tf_cs = 8, tf_eflags = 582, tf_esp = 0,
tf_ss = -8359936}) at ../../i386/i386/trap.c:586
(kgdb)
Any help appreciated. Those with sufficient skill and contract hopes are
invited to contact me directly.
TIA.
--
j.
James FitzGibbon [EMAIL PROTECTED]
Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: bind and the limit of serial number ???
* Leif Neland ([EMAIL PROTECTED]) [000423 13:17]: I once put in an extra digit in the serial number. This made a secondary use a serial number, which was larger than mine, and could probably be the modulus 2^32. I had to call the hostmaster there (A "3.rd secondary" hosted at our uplink) to get the zonefile removed, so the right one would be reloaded. Just FYI: if you make the serial number of a zone '0', secondary servers (bind at least) will *always* grab the zone from the master. It's intended to fix just the situation you had; set the serial to 0, leave it that way until all the slaves have picked up the new zone, then start using the proper numbering scheme again. It wastes bandwidth for a while if you have a large number of secondaries and/or a low refresh time, but it lets you fix a type without human intervention. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: T/TCP friendly inetd change?
* David Malone ([EMAIL PROTECTED]) [000316 16:51]: I've tried this over my slip link and it does seem to reduce the number of packets sent by 2 for telnetting to the daytime port. I also had a look at fetch (the only thing in the tree which uses MSG_EOF at the moment), which has an option for turning off the MSG_EOF stuff 'cos some buggy http servers don't like half closed connections. I don't think this applies in this case 'cos we're on the server side - not the client side, and the client expects an EOF anyway. Would this be an acceptable patch to inetd? It would be nice to encourage the use of T/TCP within FreeBSD, as we seem to be the only people who have it ;-) A couple of points of feedback: - by default, T/TCP is off in the kernel (see src/sys/netinet/tcp_subr.c; around line 85 in my 3.x box). It's also off by default in /etc/defaults/rc.conf - all the "internal" services that inetd provides (including daytime) are turned off by default in /etc/inetd.conf - security conscious people who have read through LINT may turn on the "TCP_DROP_SYNFIN" kernel opt, which breaks T/TCP. I think that this option should be made a sysctl knob just like support for T/TCP before a change like this goes through. That way, any program that wants to support T/TCP can query the value of the knob before deciding if it will support the extensions or not. I like T/TCP (I use it on some of my networked apps for the same reasons you describe), but I don't think that it should be added to a program like inetd which has two default settings that would need to be changed before the T/TCP extensions would ever provide any benefit. More education on T/TCP for both client and server authors is the key here I think; if major web browsers alone would support the extensions, then the massive overhead of HTTP (and the issues that arise from getting around it with HTTP/1.1 KeepAlive and such) would be significantly reduced. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pthread blocking I/O
* stefan parvu ([EMAIL PROTECTED]) [000306 09:19]: I have not so much experience using POSIX threads, but we had in university a project and for I/O to use threads is not so good method. You slow down the process. Some comments? Isn't so? In my experience, threads are the perfect way to speed up an I/O bound application. While one thread is blocked in iowait, others can be performing operations that do not contend for the same resource (calculation, I/O on some other resource like a socket, etc.) This is of course implementation dependant; if you are using a user-land thread package like MIT pthreads, the kernel sees the entire process as one schedulable entity, so if one thread blocks on IO, all threads block. If you are using a kernel-thread or hybrid implementation, the system scheduler allows the other threads to run as described above. FreeBSD's threading implementation in libc_r is (AFAIK) a hybrid model, and from personal experience I have found threaded applications under FreeBSD to be much easier to code for performance than their single-threaded counterparts. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
