Subject: Linux-Development Digest #581 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Sun, 27 Mar 94 00:13:06 EST Linux-Development Digest #581, Volume #1 Sun, 27 Mar 94 00:13:06 EST Contents: Re: How to use VARARGS under Linux ? (Patrick Schaaf) Re: TCP/IP-Bug in 1.0 Kernel? (Charles Hedrick) [moddev README omission] Important (John Epstein) TCP-Problem: solved (Martin H. Ludwig) Re: Linux <--> DOS PLIP??? (James F Small Jr) Re: TCP/IP-Bug in 1.0 Kernel? (Rene COUGNENC) Re: How to use VARARGS under Linux ? (Rene COUGNENC) Re: Is "gas" ( GNU assembler ) available for Linux? (Byron Thomas Faber) Re: TCP/IP-Bug in 1.0 Kernel? (Rob Janssen) Re: TCP/IP-Bug in 1.0 Kernel? (Rob Janssen) Re: I want real scrollback. (Andries Brouwer) Re: TCP/IP-Bug in 1.0 Kernel? (Andries Brouwer) Re: How to use VARARGS under Linux ? (John Edward Tillema,&91M+soAj) Re: Slackware as a tar.gz file? (David Fox) Crazy "question" cga lib possible? (Elizabeth M. Phillips) Re: TTY overruns cost money. (Rubber Duck) Re: Amiga FileSystem, Anyone? (Christopher Key) Kernel crash under load (Frank Lofaro) Problem trying to directt IP address back to loopback interface (Frank Lofaro) ---------------------------------------------------------------------------- Crossposted-To: comp.os.linux.help From: bof@wg.saar.de (Patrick Schaaf) Subject: Re: How to use VARARGS under Linux ? Date: Sat, 26 Mar 1994 17:46:44 GMT zenon@resonex.com (Zenon Fortuna) writes: >Fine. But I could not find any header file with the va_list or va_dcl >declaration. Look for it under /usr/lib/gcc-lib/*/*/include/; the method of argument passing is compiler specific, and GnuC consequently puts the relevant header files into its own directory. That include directory is searched before /usr/include and other include directories. Patrick (c.o.l.development is for discussion of kernel development, only. Followup is set.) ------------------------------ From: hedrick@farside.rutgers.edu (Charles Hedrick) Subject: Re: TCP/IP-Bug in 1.0 Kernel? Date: 26 Mar 94 17:49:37 GMT zxmgv07@studserv.zdv.uni-tuebingen.de (Michael Will) writes: >I have noticed that SLIP does work with 1.0 but has problems running >ftp and the like with anything beyond that. I tried 1.0p2 and 1.0p4 but >had to go back to 1.0 to work with SLIP. This note doesn't have enough information to diagnose the problem. Network changes in the patches after 1.0 have been fairly minimal. I use SLIP without any trouble. I just FTP'ed the kernel both directions using 1.0.4, and it was fine. Retrieving it was quite smooth. Sending it involved some retries. However the terminal server I'm using is incrementing its overrun count, so this seems to be the fault of the terminal server. At least Linux retries are working properly. Unfortunately this message doesn't contain enough information to do any diagnosis. I will say that systems like this are complex enough that it's easy to draw incorrect conclusions. I thought Linux had broken TCP in going from pre-1 to 1.0. However further investigation made it clear that for some reason my terminal server had started dropping characters more often. That seemed to be a one-time thing: further experience with 1.0 and 1.0.x has been pretty much the same as late 0.99pl15. I do think there's a possible problem in dealing with some PC TCP implementations. However so far no one has sent me any packet traces, so there's nothing I can do about it. ------------------------------ From: jepstei@afterlife.ncsc.mil (John Epstein) Subject: [moddev README omission] Important Date: Sat, 26 Mar 1994 19:47:16 GMT There is an important omission in moddev-0.1 README file. The lines to add to rc.local should be /sbin/insmod /sbin/moddev.o modload & The README file omitted the "&" --- booting will not finish!!! It did say modload runs in the background, which subtley implies that the "&" is needed. That is why one should ALWAYS have a fall back method of rescuing one's system. John ------------------------------ From: malu@dialslip-17.rz.ruhr-uni-bochum.de (Martin H. Ludwig) Subject: TCP-Problem: solved Reply-To: Martin.Ludwig@ruba.rz.ruhr-uni-bochum.de Date: Sat, 26 Mar 1994 19:33:04 GMT Hello Linux-World! I have to apologize for my postings about TCP-problems with the 1.0-kernel. Sorry! The evil-doer was the syslogd-daemon from the net-std package. Without these daemon running all works fine. Just for interest: does somebody use this daemon without problems? By Martin -- Martin H. Ludwig Martin.Ludwig@ruba.rz.ruhr-uni-bochum.de ================> Why don't you use the right OS? ================> Try Linux and see how good a better OS can be! ------------------------------ From: cavenewt@netcom.com (James F Small Jr) Subject: Re: Linux <--> DOS PLIP??? Date: Sat, 26 Mar 1994 19:24:31 GMT In article <2mvn9k$jeb@rio70.bln.sni.de>, Wolfgang Kalthoff wrote: >>Thanks in advance, > >The first byte is transferred, followed by the multiple error : >"remote end become unready while sending\n". >Maybe we can find the asm-source for plip.com or Russ can hear us! Maybe you'd use archie to look for the packet driver distribution then you'd already have the source to plip.com (plip.asm) [been there done that] ------------------------------ From: rene@renux.frmug.fr.net (Rene COUGNENC) Subject: Re: TCP/IP-Bug in 1.0 Kernel? Date: 26 Mar 1994 11:43:59 GMT Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC) Ce brave Carl Schott ecrit: > Rene COUGNENC (rene@renux.frmug.fr.net) wrote: > : Ce brave Michael Will ecrit: > : > I have noticed that SLIP does work with 1.0 but has problems running > : > ftp and the like with anything beyond that. I tried 1.0p2 and 1.0p4 but > : > had to go back to 1.0 to work with SLIP. > : Same for me, SLIP and PPP. > Hmm... SLIP (CSLIP actually) has been rock solid for me at 1.0.4 > passing 8-10 MB of news and ftp per day. I had a few problems with > general protection warnings at pre-1.0 and 1.0.2, but never had any ftp > breakdowns. What version of ftp are you running, and what are your > configurations? Maybe you should try a fresh compile of Alan Cox's new > "ftp". The problem is not only whith ftp, but whith any program. The network works proprely whith 1.0.4 between 2 linux boxes on Ethernet, but as soon as I connect an Annex terminal server whith SLIP or PPP, these connexions work randomly; I can telnet or rlogin or ftp or anything whith no problem, but receiving data blocks. A "cat" of a text file may show the first lines, then stop for a few minutes, then restart or hang definitively... The /proc stats may show errors on the sl0 interface, or may not. :( Whith plain 1.0 (or the last patches before 1.0) it use to work really well. I don't know which 1.0 patch broke it, since I have been running 1.0 for 10 days, trying 1.0.? whith no problems on my second machine, which does not SLIP... I realized the problem when, after 10 days, I had to reboot the other machine because of a stupid hardware problem, and decided to upgrade it to 1.0.4 in the same time. It seems that Carl Schott has the same problems starting whith 1.0.2... I thought about a serial problem, but anything else using the modem works as well as before. So I'm back to 1.0 whith this machine :-( -- linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux ------------------------------ From: rene@renux.frmug.fr.net (Rene COUGNENC) Subject: Re: How to use VARARGS under Linux ? Date: 26 Mar 1994 12:02:28 GMT Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC) Ce brave Zenon Fortuna ecrit: > Fine. But I could not find any header file with the va_list or va_dcl > declaration. Under HP-UX the declarations are in varargs.h, somebody suggested > that under Linux there exists stdargs.h ... but I did not find it in > SLACKWARE 1.1.2 . Maybe simply I have to copy more header files from other (?) > distributions ? stdarg.h is (should be...) here: /usr/lib/gcc-lib/i486-linux/2.5.8/include/stdarg.h If the compiler is proprely installed, just #include should work; GCC knows about his local includes. Using varargs is obsolete and you really should use stdarg if you write new code. Anyway, your original code using varargs compiles and works under Linux as well; I have just tried it. (Gcc 2.5.8 and libs 4.5.21) If it does not for you, I suggest you get the original development packages built by H.J.Lu, on your favourite mirror site... (Generally found in ...../packages/GCC ) -- linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux ------------------------------ From: bf11620@ehsn3.cen.uiuc.edu (Byron Thomas Faber) Subject: Re: Is "gas" ( GNU assembler ) available for Linux? Date: 26 Mar 1994 21:40:51 GMT jdv@ee.ualberta.ca (John Voth) writes: >Greetings Linux Developers! >I have noticed that GNU has a assembly language compiler called "gas". >I've used it for compiling MC68000 assembly language programs intended to >be used on my university's motorola 68000 labs. Is this GNU product >available for linux? >Any leads would be greatly appreciated! >john >-- >------------------------------------------------------------------------------- >jdv@bode.ee.ualberta.ca Computer Engineering University of Alberta >------------------------------------------------------------------------------- Look around in tsx-11.mit.edu /pub/linux/packages/GCC It should be there. gas, as.. something like 2.2l Byron -- PGP 2.3 key available (in plan file) at: Support public code: b-faber@uiuc.edu Use GNU software and others. other accts at: btf57346@sumter.cso.uiuc.edu & bf11620@coewl.cen.uiuc.edu ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: TCP/IP-Bug in 1.0 Kernel? Date: Sat, 26 Mar 1994 13:10:44 GMT Reply-To: pe1chl@rabo.nl In <2mvha1$ot5@renux.frmug.fr.net> rene@renux.frmug.fr.net (Rene COUGNENC) writes: >Ce brave Michael Will ecrit: >> I have noticed that SLIP does work with 1.0 but has problems running >> ftp and the like with anything beyond that. I tried 1.0p2 and 1.0p4 but >> had to go back to 1.0 to work with SLIP. >Same for me, SLIP and PPP. I think there is a problem with ifconfig somehow. I use a very old ifconfig and it works fine (1.0.4 kernel). Newer version retrieved this week does not work. Weird... Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: TCP/IP-Bug in 1.0 Kernel? Date: Sat, 26 Mar 1994 13:11:45 GMT Reply-To: pe1chl@rabo.nl In cgschott@psu.edu (Carl Schott) writes: >Rene COUGNENC (rene@renux.frmug.fr.net) wrote: >: Ce brave Michael Will ecrit: >: > I have noticed that SLIP does work with 1.0 but has problems running >: > ftp and the like with anything beyond that. I tried 1.0p2 and 1.0p4 but >: > had to go back to 1.0 to work with SLIP. >: Same for me, SLIP and PPP. >Hmm... SLIP (CSLIP actually) has been rock solid for me at 1.0.4 >passing 8-10 MB of news and ftp per day. I had a few problems with >general protection warnings at pre-1.0 and 1.0.2, but never had any ftp >breakdowns. What version of ftp are you running, and what are your >configurations? Maybe you should try a fresh compile of Alan Cox's new >"ftp". Getting Alan's new binaries (ifconfig etc) broke it for me. It worked fine before... Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: aeb@cwi.nl (Andries Brouwer) Subject: Re: I want real scrollback. Date: Sat, 26 Mar 1994 22:02:13 GMT ftlofaro@unlv.edu (Frank Lofaro) writes: :In article nelson@crynwr.crynwr.com (Russell Nelson) writes: ::I want real scrollback for Linux. And of course, it should NOT be done : ^^^^^^^^^^^^^^^^^^^^^ ::in the kernel. So the sensible way to do it is via /proc. :Why not put it in the kernel? It seems like a logical place for it. It seems :like a lot of work have to coordinate the kernel with a user process, and :could slow down the console driver due to context switching overhead, etc. :The vt100 emulation is in the kernel already, this wouldn't be much different. Answer 1: Because we want to avoid kernel bloat. Answer 2: Because a user process could give an arbitrary amount of scrollback, possibly using buffering on disk, while it would not be exactly easy (or clean) to make the keyboard interrupt routine access a disk file or swap space. Moreover, as soon as you have arbitrary scrollback, you'll want to search for a string, dump parts of the screen to a file, etc. ------------------------------ From: aeb@cwi.nl (Andries Brouwer) Subject: Re: TCP/IP-Bug in 1.0 Kernel? Date: Sat, 26 Mar 1994 22:08:27 GMT rene@renux.frmug.fr.net (Rene COUGNENC) schrijft: >Ce brave Michael Will ecrit: >> I have noticed that SLIP does work with 1.0 but has problems running >> ftp and the like with anything beyond that. I tried 1.0p2 and 1.0p4 but >> had to go back to 1.0 to work with SLIP. >Same for me, SLIP and PPP. Interesting. I have not noticed any difference between 1.0, 1.0p2 and 1.0p3. My SLIP runs as usual and ftp works. ------------------------------ From: tillemaj@news.doit.wisc.edu.UUCP (John Edward Tillema,&91M+soAj) Subject: Re: How to use VARARGS under Linux ? Date: 26 Mar 1994 23:13:20 GMT From article <1994Mar25.230730.13766@resonex.com>, by zenon@resonex.com (Zenon Fortuna): > In article <2mvjr5$nah@news.doit.wisc.edu> tillemaj@news.doit.wisc.edu.UUCP (John Edward Tillema,&91M+soAj) writes: >>From article <1994Mar25.031012.3079@resonex.com>, by zenon@resonex.com (Zenon Fortuna): > [...] [...] > > Fine. But I could not find any header file with the va_list or va_dcl > declaration. Under HP-UX the declarations are in varargs.h, somebody suggested > that under Linux there exists stdargs.h ... but I did not find it in > SLACKWARE 1.1.2 . Maybe simply I have to copy more header files from other (?) > distributions ? Well, as one guy pointed out you should use stdarg not vararg (stdarg is what my example came from. For Linux/Suns and HP-UX just include (Not sure which HP-UX version this is, but want to think something like 9 but its running on a hp9000s700 - hprisc machine) and you should be set. I was able to find va_list and va_dcl in varargs.h (which is what stdarg.h includes on HP-UX). Includeing stdarg.h should solve the problem on both systems. > > BTW, where to find more complete set of header files for Linux (and, maybe, > related man-pages ?) ? Don't know about a more complete set of header files, as Slackware should have all the standard header files that come with libc. As for man pages, don't know which manual page set slackware is giving, but I think in the doc directory on sunsite.unc.edu there is a manpage file that contains a whole slew of them (can't remember the exact location right now though). Good Luck John -- John Tillema tillemaj@cae.wisc.edu // \\// + 'nix Q: How many IBM cpu's does it take to do a logical right shift? A: 33. 1 to hold the bits and 32 to push the register. ------------------------------ From: fox@graphics.cs.nyu.edu (David Fox) Subject: Re: Slackware as a tar.gz file? Date: 26 Mar 1994 17:45:46 GMT In article kwh@cs.brown.edu (Kwun Han) writes: ] Even better, do a "get slackware.tar.gz or slackware.tar.z" ] That compresses it and then send it. :) As others have pointed out, almost every file in the slackware distribution is already compressed, so it is counterproductive to compress them again. ------------------------------ From: ad302@freenet.buffalo.edu (Elizabeth M. Phillips) Subject: Crazy "question" cga lib possible? Reply-To: ad302@freenet.buffalo.edu Date: Sun, 27 Mar 1994 00:22:24 GMT Is thier by any chance a CGA lib for Linux? If not is this possible? I have a CGA card that's capable of 640x200x16 and would like to be able to at least SOME graphics under Linux. -- ------------------------------ From: mike@dormrat.sosi.com (Rubber Duck) Subject: Re: TTY overruns cost money. Date: 26 Mar 1994 13:53:01 -0700 In article <2m3jb8$ma8@harbinger.cc.monash.edu.au>, Kevin Lentin wrote: >On Tue, 15 Mar 1994 02:56:03 GMT, Nemosoft Unv. wrote: > >Actually, they're not suddenly broken down. A decision was made to report >the input overrun errors. They were happening before. You just weren't >being told about it! But are these numbers accurate? 28.8kbps CSLIP, 115,200 DTE on internal Zoom (local) 57,600 DTE on external Hayes (remote) sl0 Link encap Serial Line IP inet addr 166.93.11.2 P-t-P 166.93.8.254 Mask 255.255.0.0 UP POINTOPOINT RUNNING MTU 1006 Metric 1 RX packets 178847 errors 0 dropped 0 overrun 165082 TX packets 192912 errors 0 dropped 43010 overrun 176361 Mike P.S. Is this normal? >[ kevinl@bruce.cs.monash.edu.au |___/~\/~\_____/~\______/~\/~\__| ] -- AMN Michael S. Aos Preferred->mike@dormrat.sosi.com This egf-bbs.uucp PSC Box 70989 .forward ->aos@rainbow.sosi.com message Sun 2/120 Peterson AFB ALSO->msaos@nyx.cs.du.edu delayed (719) 573-5761 CO, 80914-5630 OR->mike@egf-bbs.sosi.com 24 hrs Login as 'guest' ------------------------------ From: skip@metronet.com (Christopher Key) Subject: Re: Amiga FileSystem, Anyone? Date: Sat, 26 Mar 1994 23:35:42 GMT In article , Kevin Brown wrote: > >However, DOS supports *no* variability at all in filenames. It *insists* on >the 8+3 rule, period. > Well, I normally don't get into these OS-religious flames, but you obviously haven't thought this through very much. The problem isn't so much that the operating system forces 8.3 but that non 8.3 filenames break the existing _applications_. I use both dos and linux, and writing a device driver for DOS that would hook the various dos services interrupts and provide bigger filenames would probably only be a long weekend hack. But too many applications would break for it to be useful. DOS isn't perfect (far from it), but it is fairly extendable. Skip ------------------------------ From: ftlofaro@unlv.edu (Frank Lofaro) Subject: Kernel crash under load Date: Sat, 26 Mar 94 23:04:46 GMT While running my systtem under extreme load I got this kernel crash when switching VC's. EIP: 16ae45 EFLAGS: 10206 .... Here is the kernel code that crashed: (I compiled the kernel with -g and used gdb /usr/src/linux/tools/zSystem /proc/kcore) gdb> list *0x16ae45 0x16ae45 is in kbd_bh (keyboard.c:867). 862 last_console = fg_console; 863 change_console(want_console); 864 } 865 want_console = -1; 866 } 867 if (tty && tty->ldisc.read_flush) 868 (tty->ldisc.read_flush)(tty); 869 do_keyboard_interrupt(); 870 cli(); 871 if ((inb_p(0x64) & kbd_read_mask) == 0x01) gdb> x/i 0x16ae45 0x16ae45 : cmpl $0x0,0xb4(%edx) 0xb4 is the offset of the ldisc.read_flush in the tty_struct: gdb> print &((struct tty_struct *) 0)->ldisc.read_flush $12 = (void (**)()) 0xb4 Looks like tty is valid while it is being checked, and when it is used, it has become invalid. After the kernel fault, the user process running at the time (ironically, gdb) was killed, but the kernel stopped working. There were some complains about gfp called non-atomically from an interrupt, twice, at the following addresses: gdb> list *0x11a8d3 0x11a8d3 is in swap_in (swap.c:257). 252 } 253 if (SWP_TYPE(entry) == SHM_SWP_TYPE) { 254 shm_no_page ((unsigned long *) table_ptr); 255 retur 256 } 257 if (!(page = get_free_page(GFP_KERNEL))) { 258 oom(current); 259 page = BAD_PAGE; 260 } else 261 read_swap_page(entry, (char *) page); gdb> list *0x120ab6 0x120ab6 is in grow_buffers (buffer.c:871). 866 867 if ((size & 511) || (size > PAGE_SIZE)) { 868 printk("VFS: grow_buffers: size = %d\n",size); 869 return 0; 870 } 871 if(!(page = __get_free_page(pri))) 872 return 0; 873 bh = create_buffers(page, size); 874 if (!bh) { 875 free_page(page); (Yeah, I know the 2 things above are not interrupts! Tell Linux that! :) I think a bug in the fault handling code confused the rest of the kernel, which resulted in it crashing (read on...) VC switching was totally ignored, ctrl/shift/altgr-printscreen stuff still worked. (these symptoms were just like what happened with the tcpspray problem). altgr-printscreen showed it always with EIP 0023:00000000 and EFLAGS: 282. It was constantly staying at 23:0 (i.e. in user space at location 0), never entering kernel mode except to print the printscreen info. In addition to the bug causing the fault, it appears there is a bug in the fault handling code. If a process is killed due to a fault in an interrupt, or in other "bad" places, it kills Linux. I have not been able to replicate the problem. It looks like some sort of race condition. It took a lot to get it to happen in the first place. Really high load average, a lot of thrashing, and a lot of I/O. It seems like it could occur under any load (less likely though, usually race conditions show more under high load). I still think it should be looked at, no amount of load should cause a crash. I hope the information here helps. Setup: 486/DX33 running 1.0.4 with the modules patch (no longer needs ksysms.lst), various local patches (none in any of the bottom half handlers though!), and Ted Tso' new tty code (I patched it into 0.99.15h and kept patching the kernel up to 1.0.4, sometimes having to manually patch.) ------------------------------ From: ftlofaro@unlv.edu (Frank Lofaro) Subject: Problem trying to directt IP address back to loopback interface Date: Sun, 27 Mar 94 00:24:18 GMT I want to be able to direct an IP address back to the loopback, but it does not work. If I have my IP adress as not 127.0.0.1 and my externel interface is down, sending to it gives a "Netowrk unreachable" (as expected). If I try to route that IP adress to the loopback, all packets to it are dropped. E.g. If my IP address is 125.5.5.5 and my externel link is currently down, I would want to not have to change my hosts file to point to 127.0.0.1, but still point to 125.5.5.5. If the link is up, (e.g a SLIP link with my IP address as 125.5.5.5 and the server at 125.1.1.1), using 125.5.5.5 will act like loopback. If the link is down and I do this: route add -host 125.5.5.5 dev lo Packets set to 125.5.5.5 are dropped! This is BAD, since apps like talk to a local user will fail if it uses the 125.5.5.5 IP address. Here is some debug info: 127.0.0.1 works 125.0.0.1 fails inet_debug = 3: (dev.c) whitney:/# ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes ETH: header(127.0.0.1, 127.0.0.1, 0x800) ETH: No header for loopback dev_queue_xmit(skb=689410, dev=17F2D0, pri = 1) ETH: header(127.0.0.1, 127.0.0.1, 0x800) ETH: No header for loopback dev_queue_xmit(skb=762210, dev=17F2D0, pri = 1) 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=8.6 ms --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 8.6/8.6/8.6 ms whitney:/# ping -c 1 125.5.5.5 PING 125.5.5.5 (125.5.5.5): 56 data bytes ETH: header(127.0.0.1, 125.5.5.5, 0x800) ETH: No header for loopback dev_queue_xmit(skb=689808, dev=17F2D0, pri = 1) --- 125.5.5.5 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss inet_debug = 10: (loopback.c) whitney:/# ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes loopback_xmit(dev=17F2D0, skb=689410) loopback_xmit(dev=17F2D0, skb=575210) 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=5.2 ms --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 5.2/5.2/5.2 ms whitney:/# ping -c 1 125.5.5.5 PING 125.5.5.5 (125.5.5.5): 56 data bytes loopback_xmit(dev=17F2D0, skb=689410) --- 125.5.5.5 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss It looks as if the loopback interface is working on the way out, but the packets are dropped before coming back (through loopback_xmit, etc). Where exactly is that happening? How it I fix it? Where do I look? I tried looking in loopback.c but no luck there. P.S. There should be a way to have the kernel log ALL dropping of packets. Not know when or why the kernel is dropping a packet is very bad, it makes debugging really difficult. ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************