Re: hdd problem
- Original Message - From: "Chirag Kantharia" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 19, 2000 6:58 AM Subject: hdd problem Hi! Sounds to me like your harddisk is broken or faulty... I've had the same problem with a 1.6GB harddisk of mine. When you put a lot of strain on it, it would suddenly disappear (even the BIOS wouldn't find it). After 15 minutes or so, it'd come back... this might also be caused by heat, though. --Rink Hello! I've been using 4.1.1-RELEASE on my machine. Lately, my hard disk starts whirring noisily for a period ranging from 3 to 15 secs during which the hdd led shines very bright and the machine *almost* stops responding. A few secs later, everything comes back to normal and the following appears in /var/log/messages: Oct 19 10:23:10 mercury /kernel: ad0: WRITE command timeout - resetting Oct 19 10:23:10 mercury /kernel: ata0: resetting devices .. device dissapeared! 1 ata0-master: timeout waiting to give command=c6 s=80 e=00 Oct 19 10:23:10 mercury /kernel: done Any ideas, as to what is happening? Or just a coupla loose connections? chyrag. -- Chirag Kantharia chyrag-at-slashetc-dot-net http://slashetc.net/chyrag/ GCS/IT/B/E/MU/TW d-! s-:- a--? C@ UBLS P(+++) L++ E-(---) W++ N--@ w--- M- PS+ PE++ PGP++ R* b++ DI+ D+ G+++ e++ h++ r-- y To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: hdd problem
On Tue, Sep 19, 2000 at 09:08:51AM +0200, Rink Springer wrote: | Sounds to me like your harddisk is broken or faulty... I've had the same | problem with a 1.6GB harddisk of mine. When you put a lot of strain on it, | it would suddenly disappear (even the BIOS wouldn't find it). After 15 | minutes or so, it'd come back... this might also be caused by heat, though. Hi! Thanx for the ideas. Heat doesn't seem to the problem here. The other suggestion might hold. I'll check it. Thanx again. chyrag. -- Chirag Kantharia chyrag-at-slashetc-dot-net http://slashetc.net/chyrag/ GCS/IT/B/E/MU/TW d-! s-:- a--? C@ UBLS P(+++) L++ E-(---) W++ N--@ w--- M- PS+ PE++ PGP++ R* b++ DI+ D+ G+++ e++ h++ r-- y To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dumb usb question
We do not have support for that serial device yet. And it is not straightforward to write support for it. Nick On Tue, 17 Oct 2000, Andrew Gallatin wrote: A friend of mine just bought a D-Link USB-S25 USB to Serial Port converter cable. Given that he cannot make it work under linux and that I've been trying to sell him on FreeBSD, I'd like to give it a whirl under FreeBSD. What is the appropriate driver? umodem looks like it just deals with generic serial devices and might do the job. Is that correct? Thanks, Drew -- Andrew Gallatin, Sr Systems Programmerhttp://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer SciencePhone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How to sense DCD on serial port?
Hello, I just assembled a mini IR receiver for the serial Port. This device shows the IR-code by pulling DCD up or down. As there is no software for FreeBSD supporting IR I would like to have a try and code it myself. Unfortunately those Pulses sent by the IR device sometimes only last a few milliseconds. Now my question: How can I sense the state of the DCD line that quick? I can meassure the overal time with gettimeofday() but how can I sense DCD? Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to sense DCD on serial port?
On Thu, 19 Oct 2000, Alexander Maret wrote: How can I sense the state of the DCD line that quick? I I'm not sure how quick it is but have you tried ioctl with an argument of TIOCMGET? See tty(4) for more details. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDMA ICRC WRITE ERROR
On Tue, Oct 17, 2000 at 08:18:45PM -0700, Greg Lehey wrote: On Sunday, 15 October 2000 at 13:58:15 +0200, Frank Nobis wrote: Hi, I have a IDE drive spitting out this messages: ad3: UDMA ICRC WRITE ERROR blk# 48562489 retrying ad3: UDMA ICRC READ ERROR blk# 24576329 retrying ad3: UDMA ICRC WRITE ERROR blk# 69108025 retrying ad3: UDMA ICRC WRITE ERROR blk# 73728313 retrying It seems the problem is solved for now. I replaced the cables with real UDMA66 parts (the ones with 80 wires) even if the ata controller is only UDMA33. Currently the drives are running without spitting out any more errors. Now the drives really operate at the physical maximum transfer rates up to 16 MB/s measured with iostat. Regards, Frank -- ~/.signature not found: wellknown error 42 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: How to sense DCD on serial port?
-Original Message- From: [EMAIL PROTECTED] To: Alexander Maret Cc: '[EMAIL PROTECTED]' Sent: 19.10.00 15:30 Subject: Re: How to sense DCD on serial port? How can I sense the state of the DCD line that quick? I I'm not sure how quick it is but have you tried ioctl with an argument of TIOCMGET? See tty(4) for more details. Thanks for your answer. I meanwhile tried TIOCMGET and I can sense the state of dcd. Unfortunately I can't continously check DCD because this takes ernormous cpu time. Is there a possibility to get a signal,intr or whatever, whenever the state of DCD changes? If not, what could you think of I have to do to implement such a feature? Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dumb usb question
We do not have support for that serial device yet. And it is not straightforward to write support for it. Doug Ambrisko has support for a number of devices that aren't supported in the current FreeBSD code. You may want to contact him: [EMAIL PROTECTED] Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mfsroot over nfs and optional install.cfg ??
On Mon, 16 Oct 2000, Danny Howard wrote: I'm working on doing a FreeBSD jumpstat process based on http://people.freebsd.org/~alfred/pxe/ If you're at BSDCon please to my talk on it tomorrow. :-) My primary limitation is configurability - I need to be able to run sysinstall with a different install.cfg per install. So the first answer to that is "configure each client with a different PXE root and go from there." I'm curious what differences you need. If it's radical or can't be handled in post-install then you would be better off writing your own installer. Then I get the irritation that I must diddle with an mfsroot image to change the install.cfg. I've been poring over what loader documentation I can find, but still haven't even figured out how the "let's go to mfsroot which will take us to sysinstall in the next stage" thing works ... there's nothing in mfsroot's /etc, for example ... It isn't needed for the most part -- sysinstall runs as init in the install environment so there's no /etc/rc* to run. From loader.rc: load -t mfs_root /mfsroot [...] set vfs.root.mountfrom="ufs:/dev/md0c" boot How is boot different from autoboot? Autoboot is a variable; 'boot' does a countdown from 'autoboot' seconds. Can I get around having to load the mfs_root image and just dump it in the pxe boot directory? I'm getting a hunch that maybe I can do an NFS partition and set vfs.root.mountfrom to use NFS ... You're shooting for an NFS-mounted root I bet, and I believe we have it going on the lab machines here at the con. I'll have to pick them apart and see what they do. Then, the other question is, how the heck does sysinstall get launched? If I can get at a script that launches sysinstall, I could set an install.cfg for sysinstall to run instead of having to point at differnt install.cfg's via dhcpd.conf ... You're in the 'hack sysinstall' arena. You can recompile it to use a different path for the install.cfg. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Routing issue with cable modem
I guess no one knew the answer to my original question about getting RCN cable modem (with analog upstream line dialup) to work. So here's a somewhat simplified question. I narrowed the problem down to routing. Cable modem does dial out when I try to ping something on it's subnet (10.17.56.###), however it does not respond to any broadcast ARP queries about location of DNS server. Goal -- to add cable modem as the default gateway to internet. Symptom -- "add net default: gateway 10.17.56.XXX: Network is unreachable" Problem -- I think modem gateway cannot be added because it's on a different subnet then my NICs. Attempted -- aliasing ed0 to modem subnet all 10.17.56 IPs seem to be occupied. Any ideas would be greatly appreciated. It's been 2 weeks now that I'm stuck to using windows box :( Marko P.S. If someone on the freebsd-hackers mailing list knows the answer, please reply to my address because I'm not subscribed to freebsd-hackers (yet). P.S.S. On a side note: it would be very interesting to know how MSWin98 does it's network setup, that it has no trouble using the modem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IPFW bug/incoming TCP connections being let in.
I had blocked incoming TCP connections coming into my network using
IPFW, and I noticed that my brother was able to establish a Napster
connection, even though I had blocked it earlier.
I thought, no worries, I'll just block it at the port level.
I read a couple of articles, and noted that connections from to the
server should be blocked.
Easy enough, I'll just block my clients from establishing connections to
port .
Unfortunately, that doesn't work. Looking at tcpdump output, the
'server' appears to initiates a TCP connection from - some random
port. My firewall rules do *NOT* allow incoming TCP connections to be
made to internal machines, since they only allow 'setup' packets to go
out.
So, how can Napster work? What happened to the 3-way handshake? I
could see an issue if the OS's were hacked to get around this and not
require a 3-way handshake, but the client in this case in a Win98 box.
I'm *really* confused, and more than a little concerned, since it
appears that somehow Napster is getting around the 3-way handshake.
Does Napster create 'raw' sockets that emulate TCP traffic?
In an attempt to attempt to debug what was going on, I stuck the
following rules in place;
00016 allow log tcp from ${client} to any out xmit ep0 setup
00017 allow log tcp from any to ${client} in recv ep0 setup
00018 allow log tcp from ${client} to any out xmit ep0 established
00019 allow log tcp from any to ${client} in recv ep0 established
00020 allow log tcp from ${client} to any out xmit ep0
00021 allow log tcp from any to ${client} in recv ep0
Then, I started up Napster and logged what showed up.
It was suprising (to me at least).
One would think that rules 16 or 17 *must* be hit first, because the
connection has to be initially established. However, it doesn't work
that way.
ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER: out via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER: out via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER: out via ep0
ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER: out via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
No 'setup' packets are sent at all.
Confused and concerned
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters? (WildWire DSL card driver)
Terry Lambert wrote: Back in July I was asking about the capability to set parameters (variables) when loading my DSL driver module. There was a small flurry of activity about some initial ideas on how to do it, but I never heard any more about it. Did you (Mike, Warner, or anybody) have time to work on it? Did this capability get put into release 4.1, by any chance? :) A common trick "in the old days" was to load a parameter module that the driver module depended up, and give it a hook that it could call to get data from the parameter module, by reference to a statis structure. You would send the data down to the parameter module before you load the driver module; thus: 1) Load paramter module 2) Open parameter module psuedo device 3) Ioctl parameters up/down via the pseudo device 4) Load the deriver module 5) Driver module attach routine call parameter_fetch() routine out of parameter module 6) Parameter module returns static parameter structure, by reference 7) Driver dereferences parameters out of static struct 8) Driver completes attach I'm implementing this suggested method, but I have one problem. I don't know what "device" to access to allow me to do ioctl's to it. That is, I've created a parameter module (which loads and is accessible by my driver) - but I don't think that (alone) has created a "device", has it? If so, what is it named? Realize that at step 3, my real device doesn't exist yet, so I can't reference that... Do I need to somehow "create" a (pseudo-)device in my parameter module - and if so how do I do that? Thanks, Gary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPFW bug/incoming TCP connections being let in.
On Thu, 19 Oct 2000, Nate Williams wrote: I had blocked incoming TCP connections coming into my network using IPFW, and I noticed that my brother was able to establish a Napster connection, even though I had blocked it earlier. I thought, no worries, I'll just block it at the port level. I read a couple of articles, and noted that connections from to the server should be blocked. Easy enough, I'll just block my clients from establishing connections to port . Unfortunately, that doesn't work. Looking at tcpdump output, the 'server' appears to initiates a TCP connection from - some random port. My firewall rules do *NOT* allow incoming TCP connections to be made to internal machines, since they only allow 'setup' packets to go out. So, how can Napster work? What happened to the 3-way handshake? I could see an issue if the OS's were hacked to get around this and not require a 3-way handshake, but the client in this case in a Win98 box. The remote napster client sends a message through the central Napster server, which relays the message to your Napster client to tell your machine to make a connection to the remote machine. This is so that, as long as one of the two Napster clients are not behind a firewall, the two clients can communicate directly. The client behind the firewall makes the connection to the client that isn't behind a firewall, since most firewalls are configured to allow internal machines to make connections to any outside machine. The regular 3-way handshake is occurring. It's just not initiated by the machine you would expect. You'd have to block outgoing SYNs to any outside host at port (but anyone who knows anything about ports could change their port number and get around your block). Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Dept. of Computer Science --- [EMAIL PROTECTED] http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPFW bug/incoming TCP connections being let in.
I had blocked incoming TCP connections coming into my network using IPFW, and I noticed that my brother was able to establish a Napster connection, even though I had blocked it earlier. I thought, no worries, I'll just block it at the port level. I read a couple of articles, and noted that connections from to the server should be blocked. Easy enough, I'll just block my clients from establishing connections to port . Unfortunately, that doesn't work. Looking at tcpdump output, the 'server' appears to initiates a TCP connection from - some random port. My firewall rules do *NOT* allow incoming TCP connections to be made to internal machines, since they only allow 'setup' packets to go out. So, how can Napster work? What happened to the 3-way handshake? I could see an issue if the OS's were hacked to get around this and not require a 3-way handshake, but the client in this case in a Win98 box. The remote napster client sends a message through the central Napster server, which relays the message to your Napster client to tell your machine to make a connection to the remote machine. This much I undertand. However, I'm not making any downloads, so my client isn't (yet) connecting to another client. I'm trying to block connections to the server. How is the client connecting to the server? I don't see *any* TCP setup packets being sent out by my client, so how is the client communicating with the server via TCP? (I *AM* seeing TCP packets being sent out, but they are being sent as 'established' connections, before a setup packet is being sent.) The regular 3-way handshake is occurring. It's just not initiated by the machine you would expect. The only way my client can work is if it initiates the connection, but I don't see it initiating a connection to port . So, how then is the Napster server at port communicating with my client? You'd have to block outgoing SYNs to any outside host at port (but anyone who knows anything about ports could change their port number and get around your block). That was what I did, but the rule is never being hit. However, there appears to be a connecting from my client to port on the server. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Problems with pthread
Hi
First please CC to me as I am not on the hackers mail list.
I am trying to get the ORBacus working for FreeBSD. I know you already have
a port of ORBacus, but that is version 3, and their latest release is version
4. In order to get ORBacus working to it I first need to get their JTC
library working (JTC is a thin wrapper to pthread).
Now that the user threads have re-written I was hoping to get the JTC
library to compile and work under the 4.1 kernel. I have managed to
get it to compile, but it core dumps very early in the start up code of
my application.
I have written a little simple program (attached with its Makefile) that also
exhibits the same problem. When I run the program I see the following
error reported from gdb:
(gdb) run
Starting program: nod
Program received signal SIGSEGV, Segmentation fault.
0x280747b8 in pth_cancel_point () from /usr/local/lib/libpthread.so.13
(gdb)
Can anyone offer any advice.
Steve
--
Steve Dobson [EMAIL PROTECTED]
People don't usually make the same mistake twice -- they make it three
times, four time, five times...
#include stream.h
#include pthread.h
int
main(int argc, char **argv)
{
pthread_mutex_t lock;
cerr "About to initialise the lock" endl;
if (pthread_mutex_init(lock, 0))
{
cerr "Failed to init the lock" cout;
return 1;
}
cerr "About to grab the lock" endl;
if (pthread_mutex_lock(lock))
{
cerr "Failed to grab the lock" cout;
return 1;
}
cerr "About to release the lock" endl;
if (pthread_mutex_unlock(lock))
{
cerr "Failed to release the lock" cout;
return 1;
}
cerr "All done" endl;
}
SRC.cpp = nod.cpp
CPPFLAGS = -I/usr/local/include -D_THREAD_SAFE
CXXFLAGS = -g
LDFLAGS = -L/usr/local/lib -pthread -g
LDLIBS = -lpthread
OBJS = ${SRC.cpp:%.cpp=%.o}
nod: ${OBJS}
${CXX} ${LDFLAGS} -o nod ${OBJS} ${LDLIBS}
clean:
rm -f nod ${OBJS}
Re: Problems with pthread
On Thursday, October 19, 2000, Steve Dobson wrote: I have written a little simple program (attached with its Makefile) that also exhibits the same problem. When I run the program I see the following error reported from gdb: (gdb) run Starting program: nod Program received signal SIGSEGV, Segmentation fault. 0x280747b8 in pth_cancel_point () from /usr/local/lib/libpthread.so.13 (gdb) This is GNU Pth, not FreeBSD pthreads. Use the ``-pthread'' cc(1) switch to link to the FreeBSD threads library. -- |Chris Costello [EMAIL PROTECTED] |Design simplicity: It was developed on a shoe-string budget. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Troube with remote kernel debugging using --- gdb ptrace( PT_GETDBREGS )
Hello, I am haveing a slight problem with remote kernel debugging using gdb. ( host target both fbsd 4.1.1 + gdb that came along - 4.18 ) I am able to attach and an debug the target But I keep getting the following warning : ptrace( PT_GETDBREGS ) failed: no such process Otherwise things seem to be working. Soumen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
smbfs-1.3.0 released
Hello, At first, I'm want to say 'thank you' for everybody who provided me with feedback on my work. So, here is a records from the HISTORY file for last two releases: 20.10.2000 1.3.0 - Network IO engine significantly reworked. Now it uses kernel threads to implement 'smbiod' process which handles network traffic for each VC. Previous model were incapable to serve large number of mount points and didn't work well with intensive IO operations performed on a different files on the same mount point. Special care was taken on better usage of MP systems. Unfortunately, kernel threads aren't supported by FreeBSD 3.X and for now it is excluded from the list of supported systems. - Reduce overhead caused by using single hash table for each mount point. 26.09.2000 1.2.8 (never released) - More SMP related bugs are fixed. - Make smbfs compatible with the Linux emulator. - smbfs now known to work with IBM LanManager (special thanks to Eugen Averin) - Fix problem with files bigger than 2GB (reported by Lee McKenna) - Please note that smbfs may not work properly with FreeBSD 3.X. New version can be downloaded from: ftp://ftp.butya.kz/pub/smbfs/smbfs.tar.gz -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: How to sense DCD on serial port?
On Thu, 19 Oct 2000, Alexander Maret wrote: DCD because this takes ernormous cpu time. Is there a possibility to get a signal,intr or whatever, whenever the state of DCD changes? UmmI'm not sure but wouldn't you get SIGHUP if DCD was dropped? It would look like the "dialed in user" had closed the connection. Not to sure though. I don't think you get anything when it goes high again although a blocked open will return so you might be able to hack up something there...but there must be a better way :-) If not, what could you think of I have to do to implement such a feature? You could look at the source for various serial port related stuff such as cu and tip. You may even get some hints from looking at getty etc that handles serial logins. Perhaps the sio source might help as well. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
