lkml.org 
[lkml]   [1998]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: NEW HyperTerminal Private Edition Release!
    Hallo,

    great! Hyperterminal provate edition works with Linux?

    Bye

    >>>>> "sales" == owner-linux-kernel-digest <owner-linux-kernel-digest@vger.rutgers.edu> writes:


    sales> From: sales@hilgraeve.com Date: Thu, 8 Oct 1998 12:47:6 Subject:
    sales> NEW HyperTerminal Private Edition Release!

    sales> We've just re-released HyperTerminal Private Edition 4.0, and
    sales> you're welcome to download it FREE. (We're notifying you because
    sales> you downloaded a previous version. If you want to remove yourself
    sales> from our mailing list, see the end of this message.)

    sales> You may be thinking, "Re-released! What the heck does that mean?"

    sales> More than 100,000 people downloaded HyperTerminal Private Edition
    sales> 4.0 since its release two months ago. With so many people using
    sales> it, and so many new features, it's not surprising a few bugs
    sales> would turn up. We've responded quickly, and created a new version
    sales> of HyperTerminal Private Edition 4.0 that you can download today!

    sales> HyperTerminal Private Edition 4.0 introduced these new features:

    sales> * Now you can define key macros to send passwords, user IDs or
    sales> often-used host commands with one keystroke * Set terminal screen
    sales> size (rows and columns); now also supports telnet NAWS feature
    sales> for telnet sites with variable screen size * Define the colors
    sales> used by the terminal screen * Full color support when emulating
    sales> VT100 terminals * Pass-through printing lets host systems control
    sales> your printer * Ability to exit the program automatically when you
    sales> log off * Updated entries for BBSs and telnet sites that you can
    sales> call * Adopts Windows new "flat" toolbar style * Use Windows
    sales> sounds (WAV and audio files) instead of beeps * Bug fixes for
    sales> improved use with all versions of Windows

    sales> You can install this new version right over any previous version
    sales> without losing your settings.

    sales> Download HyperTerminal Private Edition 4.0 TODAY from our web
    sales> site:

    sales> http://www.hilgraeve.com

    sales> We hope you enjoy HyperTerminal Private Edition 4.0. Please
    sales> forward this message to three of your friends!

    sales> - --- To remove your email address
    sales> [linux-kernel@vger.rutgers.edu] from this hilgraeve mailing list,
    sales> simply reply to this message. Include this entire message in
    sales> your reply. If you have problems, please forward this message
    sales> with all headers to htpelist@hilgraeve.com. If you wish to
    sales> exchange email with us, send your mail to sales@hilgraeve.com.


    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: greg@wind.enjellic.com (G.W. Wettstein) Date: Thu, 22 Oct
    sales> 1998 00:18:57 -0500 Subject: Re: 2.0.3x -- hanging network
    sales> interfaces

    sales> On Oct 20, 2:25pm, Matt Kemner wrote: } Subject: Re: 2.0.3x --
    sales> hanging network interfaces

    >> On Sat, 17 Oct 1998, Chris Evans wrote:

    chris> We've recently got a tulip based card, and we see network hangs
    chris> (the kind fixable by taking the interface down then up). I have
    chris> two questions.

    >> I saw a similar problem with a tulip card in my proxy server, which
    >> is under a LOT of network load (2 million requests/day) - the card
    >> would simply stop working, but if I ifconffiged it down/up again it
    >> was fine.. The problem turned out to be hardware rather than
    >> software - it was plugged into a rather cheap non-switching hub,
    >> which I replaced with a 16x10Mb+2x10/100Mb switch (by Netgear, and
    >> the tulip is also a Netgear) and I haven't seen the problem since
    >> (plus the card now runs at 100Mb full duplex, VERY fast :))

    >> Hope this helps you solve your problem.

    sales> I find this a somewhat interesting observation. I have been
    sales> reporting problems with the epic based Etherpower II NIC's on our
    sales> production IMAP server running 2.0.35. We have a pair of these
    sales> cards sharing an interrupt line.

    sales> During periods of high load the eth0 card wedges itself. The
    sales> eth1 interface remain active. Downing and upping both interfaces
    sales> clears the problem. We have been blaming SMP/interrupt problems
    sales> but we had 28 days of trouble-free operation. Our first incident
    sales> of wedging occurred when the Bay 450 switch that eth0 was plugged
    sales> into was replaced with a 10Mbit/sec shared media hub.

    sales> I have been running a uniprocessor kernel on the box for 2 days
    sales> and we have not had a wedging problem. This would seem to
    sales> implicate SMP but I find the whole situation after reading the
    sales> above notes somewhat more than coincidental.

    >> - Matt Kemner

    sales> Greg

    sales> }-- End of excerpt from Matt Kemner

    sales> As always, Dr. G.W. Wettstein Enjellic Systems Development -
    sales> Specialists in 4206 N. 19th Ave. intranet based enterprise
    sales> information solutions. Fargo, ND 58102 WWW:
    sales> http://www.enjellic.com Phone: 701-281-1686 EMAIL:
    sales> greg@wind.enjellic.com -
    sales> ------------------------------------------------------------------------------
    sales> "Fools ignore complexity. Pragmatists suffer it. Some can avoid
    sales> it. Geniuses remove it. -- Perliss' Programming Proverb #58
    sales> SIGPLAN National, Sept. 1982

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Andreas Haumer <andreas@xss.co.at> Date: Thu, 22 Oct 1998
    sales> 07:10:34 +0200 Subject: Re: bridging fix? Which (fwd)

    sales> Hi!

    sales> Peter T. Breuer wrote:
    >> [Cc: to linux-kernel, in case some other network guru knows and alan
    >> is busy]
    >>
    >> Hello Alan
    >>
    >> I know you finally found and fixed the bridging code leak somewhere
    >> in the recent 2.0.36pre series or just before. But I haven't been
    >> able to figure out what the fix was, by inspection. I would be
    >> deeply grateful if you could tell me what the line or lines was .. I
    >> think some intrepid soul managed to find the line that did the damage
    >> using the memleak patches.
    >>
    sales> Yeah, I think that was me :-)

    >> I saw the leak first on a server I had at 2.0.33. P100 with 3c905
    >> and buslogic fast and wide. It went down in a week serving NFS. You
    >> steered me to the cause and workaround.
    >>
    sales> Yes, the system where I found that also went down after a few
    sales> days. I have some quite impressive vmstat statistics where you
    sales> can see a almost linear decreasing in available memory...

    sales> [...]
    >> I would love to have just the fix for this as a patch. I know
    >> that's too much to ask, so I'm asking just to be clued in on the
    >> eureka that solved this.
    >>
    sales> I think that's what you are looking for:

    sales> *** linux-2.0.35/net/bridge/br.c Tue Aug 26 20:05:34 1997 - ---
    sales> linux/net/bridge/br.c Sat Oct 17 16:04:22 1998 ***************
    sales> *** 921,930 ****
    skb-> pkt_bridged = IS_BRIDGED; arp = 1; /* do not resolve... */ h.raw =
    skb-> skb->data + ETH_HLEN;
    sales> ! save_flags(flags); ! cli(); ! skb_queue_tail(dev->buffs,
    sales> skb); ! restore_flags(flags); return(0); }

    sales> - --- 921,927 ----
    skb-> pkt_bridged = IS_BRIDGED; arp = 1; /* do not resolve... */ h.raw =
    skb-> skb->data + ETH_HLEN;
    sales> ! dev_queue_xmit(skb, dev, SOPRI_INTERACTIVE); return(0); }

    sales> *************** *** 977,986 ****
    skb-> pkt_bridged = IS_BRIDGED; arp = 1; /* do not resolve... */ h.raw =
    skb-> skb->data + ETH_HLEN;
    sales> ! save_flags(flags); ! cli(); ! skb_queue_tail(dev->buffs,
    sales> skb); ! restore_flags(flags); return(0); }

    sales> - --- 974,981 ----
    skb-> pkt_bridged = IS_BRIDGED; arp = 1; /* do not resolve... */ h.raw =
    skb-> skb->data + ETH_HLEN;
    sales> ! ! dev_queue_xmit(skb, dev, SOPRI_INTERACTIVE); return(0); }

    sales> HTH

    sales> - - andreas

    sales> - -- Andreas Haumer | email: andreas@xss.co.at | PGP key
    sales> available *x Software + Systeme | phone: +43.1.6001508 | on
    sales> request. Buchengasse 67/8 | +43.664.3004449 | A-1100 Vienna,
    sales> Austria | fax: +43.1.6001507 | AH327-RIPE

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: hpa@transmeta.com (H. Peter Anvin) Date: 22 Oct 1998
    sales> 04:37:59 GMT Subject: Re: OFF-Topic glibc behavior

    sales> Followup to:
    sales> <Pine.LNX.3.95.981021131237.241A-100000@chaos.analogic.com> By
    sales> author: "Richard B. Johnson" <root@chaos.analogic.com> In
    sales> newsgroup: linux.dev.kernel
    >> The following code will write "Hello World!" to the screen on the
    >> following platforms:
    >>
    >> MS-DOS with Micro$oft 'C' 6.0 and Micro$oft 7.01 compilers MS-DOS
    >> with Borland Turbo-C 3.0 VAX/VMS VAX-C V3.0
    >>
    >> It just waits in a CPU-eating race on SunOs 5.5.1 With glibc on
    >> Linux, it seg-faults.
    >>
    >> This is not meant to be flame-bait. I know this is not how to write
    >> code. However, the effect of this kind of coding does happen when
    >> structures containing file-pointers are duplicated so it can (does)
    >> happen.
    >>

    sales> No. You can duplicate a file POINTER. You can't duplicate a
    sales> file STRUCTURE. There is no excuse for it either -- your user
    sales> program should never mess with a FILE structure but only have
    sales> pointers to it.

    >> Glibc doesn't check the contents of the FILE structures, just the
    >> addresses and since it "knows" the pointer received was not one it
    >> provided, it generates signal 11 on its own. Is this REALLY what is
    >> supposed to happen? After all, the function call did get a perfectly
    >> valid pointer to the required structure.
    >>

    sales> No it didn't. You duplicated the FILE *structure*, which may
    sales> itself contain pointers to other structures inside libc.

    sales> Your program is totally and utterly broken. SIGSEGV is a
    sales> perfectly acceptable and quite reasonable.

    sales> -hpa

    sales> - -- PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35
    sales> BD 74 See http://www.zytor.com/~hpa/ for web page and full PGP
    sales> public key I am Bahá'í -- ask me about it or see
    sales> http://www.bahai.org/ "To love another person is to see the face
    sales> of God." -- Les Misérables

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Daniel Nash <danash@students.wisc.edu> Date: Wed, 21 Oct
    sales> 1998 23:58:28 -0500 (CDT) Subject: Kernel freeze on boot
    sales> (.123-.125) in IDE init

    sales> I'm currently running 2.1.113, and trying the newest ones.
    sales> However, since 2.1.123, it's been freezing during the IDE
    sales> Partition check. I've tried a minimal config, w/o scsi sound or
    sales> anything extraneous and monolithic. I also have tried
    sales> 2.1.126-pre2 and 2.1.126-pre2ac1, with the same results.

    sales> Machine: 430HX w/Petium 225MMX using Promise Ultra/33 PCI
    sales> controller for ide2/3

    sales> It freezes after displaying 'hda:' in the partition check.

    sales> Here's the pertinent part of dmesg and /proc/pci from under
    sales> 2.1.113

    sales> PIIX3: IDE controller on PCI bus 00 dev 39 PIIX3: not 100% native
    sales> mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS
    sales> settings: hda:pio, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS
    sales> settings: hdc:pio, hdd:pio PDC20246: IDE controller on PCI bus 00
    sales> dev 58 PDC20246: not 100% native mode: will probe irqs later
    sales> ide2: BM-DMA at 0x6500-0x6507, BIOS settings: hde:DMA, hdf:pio
    sales> ide3: BM-DMA at 0x6508-0x650f, BIOS settings: hdg:pio, hdh:DMA
    sales> hda: IBM-DAQA-33240, ATA DISK drive hdb: WDC AC31600H, ATA DISK
    sales> drive hdc: MATSHITA CR-585, ATAPI CDROM drive hde:
    sales> IBM-DHEA-38451, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq
    sales> 14 ide1 at 0x170-0x177,0x376 on irq 15 ide2 at
    sales> 0x6100-0x6107,0x6206 on irq 10 hda: IBM-DAQA-33240, 3098MB w/96kB
    sales> Cache, CHS=787/128/63, DMA hdb: WDC AC31600H, 1549MB w/128kB
    sales> Cache, CHS=787/64/63, DMA hde: IBM-DHEA-38451, 8063MB w/472kB
    sales> Cache, CHS=16383/16/63, UDMA Partition check: hda: hda1 < hda5 >
    sales> hda3 hda4 hdb: hdb1 hdb4 < hdb5 hdb6 > hde: [PTBL] [1027/255/63]
    sales> hde1 hde2 hde3 < hde5 hde6 hde7 >


    sales> % cat /proc/pci PCI devices found: Bus 0, device 0, function 0:
    sales> Host bridge: Intel 82439HX Triton II (rev 3). Medium devsel.
    sales> Master Capable. Latency=32. Bus 0, device 7, function 0: ISA
    sales> bridge: Intel 82371SB PIIX3 ISA (rev 1). Medium devsel. Fast
    sales> back-to-back capable. Master Capable. No bursts. Bus 0, device
    sales> 7, function 1: IDE interface: Intel 82371SB PIIX3 IDE (rev 0).
    sales> Medium devsel. Fast back-to-back capable. Master Capable.
    sales> Latency=32. I/O at 0xf000 [0xf001]. Bus 0, device 11, function
    sales> 0: RAID bus controller: Promise Technology IDE UltraDMA/33 (rev
    sales> 1). Medium devsel. IRQ a. Master Capable. Latency=32. I/O at
    sales> 0x6100 [0x6101]. I/O at 0x6204 [0x6205]. I/O at 0x6300
    sales> [0x6301]. I/O at 0x6404 [0x6405]. I/O at 0x6500 [0x6501]. Bus
    sales> 0, device 13, function 0: Ethernet controller: 3Com 3C905 100bTX
    sales> (rev 0). Medium devsel. IRQ a. Master Capable. Latency=32.
    sales> Min Gnt=3.Max Lat=8. I/O at 0x6600 [0x6601]. Bus 0, device 15,
    sales> function 0: VGA compatible controller: Matrox Millennium (rev 1).
    sales> Medium devsel. Fast back-to-back capable. IRQ b.
    sales> Non-prefetchable 32 bit memory at 0xe0800000 [0xe0800000].
    sales> Prefetchable 32 bit memory at 0xe0000000 [0xe0000008].

    sales> What other information would be useful?

    sales> Thanks, - -- Daniel Nash "Waiter, Waiter, there's an avocado in
    sales> my guacamole." - Me

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Odddmonseter <lund@uq.net.au> Date: Thu, 22 Oct 1998
    sales> 07:11:12 +1000 Subject: Unexplained problem. 2.1.125.

    sales> I've been having trouble with 2.1.125 quite frequently. I'm a
    sales> heavy X user and I use netscape in X quite alot. Been running
    sales> 2.1.125 for a few days now, and everyday so far the kernel has
    sales> locked up (i think). There is no responce from the SysRq key and
    sales> I can't make anything go. All hdds stop and I have to hit the
    sales> reset button. I found this in my syslog after I rebooted from
    sales> the last go. I'm not sure if fsck did this so can someone please
    sales> explain what I have been doing wrong.

    sales> Oct 22 06:39:04 strange tcplogd: auth connection attempt from
    sales> doughnut.cc.uq.edu.au [130.102.128.239]
    sales> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Oct
    sales> 22 06:56:44 strange syslogd 1.3-3#26: restart.


    sales> - -- O. is for Oddd. (and its good enough for me). Odddmonster.

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: "Lee, Hee-Jin" <heejin@secns.sec.samsung.co.kr> Date: Thu,
    sales> 22 Oct 1998 15:06:31 +0900 Subject: command source code

    sales> Hi all, How can I get command source code such as "insmod"? I'm
    sales> looking for who delacares "struct device" for a network module.

    sales> I'm always asking, but I hope I can help you some day. :->

    sales> Thnak you. - -heejin

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Gerhard Mack <gmack@imag.net> Date: Wed, 21 Oct 1998
    sales> 23:36:07 -0700 (PDT) Subject: Re: Dynamic IP hack (PR#294)

    sales> Ummm what happens when 20 or 30 customers of IP MASQed isp
    sales> descide us use say ... efnet ?

    sales> Gerhard



    sales> On Wed, 21 Oct 1998, Riley Williams wrote:

    >> Hi Meelis.
    >>
    >> >> Would your customers be unhappy if you installed a firewall? If >>
    >> not, then it's very simple to get hold of MILLIONS of addresses >>
    >> for static IP purposes, as has been stated at least twice >>
    >> before...
    >>
    >> > IP masq != firewall in a strict sense.
    >>
    >> True, but as the same software's used to control both under Linux 2.0
    >> kernels, there's not a great deal to differentiate them from a
    >> practical point of view...
    >>
    >> > With NAT, your clients can not use many protocols that they could >
    >> use otherwise. Still, for most clients it's ok. ICQ w/incoming >
    >> calls is the only one I've had problems with in such setup ;-)
    >>
    >> There's one other I've come across, namely net2phone. However, whilst
    >> they're not directly supporting masquerading, they have programmed a
    >> work-around to deal with it - net2phone can be set up to use specific
    >> port numbers, rather than the standard "random free port" system now,
    >> since I've notified them of the problem...
    >>
    >> Incidentally, I met it when setting up Linux as an IP Masq firewall
    >> to a network of Win95 and Win98 systems...net2phone is not available
    >> in Linux versions, and they don't currently plan to support Linux
    >> either, unfortunately...
    >>
    >> Best wishes from Riley.
    >>
    >>
    >> - To unsubscribe from this list: send the line "unsubscribe
    >> linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
    >> Please read the FAQ at http://www.tux.org/lkml/
    >>

    sales> - -- Gerhard Mack

    sales> gmack@imag.net InnerFIRE@starchat.net

    sales> As a computer I find your faith in technology amusing.




    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: ketil@ii.uib.no Date: 22 Oct 1998 08:38:37 +0200 Subject:
    sales> 2.1.125: problems

    sales> Hi,

    sales> on a relatively straightforward RH 5.1, P133 system (Digital
    sales> Venturis FX 5133, if you must know), I've been a good citizen and
    sales> installed 2.1.125.

    sales> I get an oops when the sb module is loaded for my SB64AweGold,
    sales> I've been mucking with plug and play and whatnot, so it's
    sales> possibly my own fault. If anybody wants the gritty details, drop
    sales> me a mail.

    sales> Also, when shutting down, umount -a doesn't seem to do it's
    sales> thing, it just hangs indefinitely, and subsequently it fscks on
    sales> restart. I only have one large / partition (yes, yes, I know),
    sales> if that makes a difference.

    sales> I did a quick version check of among other things mount, without
    sales> finding anything outdated, and 2.1.117 worked okay, I think.

    sales> (I've been following the list without seeing anybody else have
    sales> these problems, and I've somehow messed up my kernel a bit. I'll
    sales> get a clean tree before going any further with this (have a thin
    sales> wire, so it'd take a while), but thought I should at least
    sales> mention it, just in case)

    sales> ~kzm - -- If I haven't seen further, it is by standing in the
    sales> footprints of giants

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Simon Kenyon <simon@koala.ie> Date: Thu, 22 Oct 1998
    sales> 08:33:42 +0100 (BST) Subject: Re: Motherboard design specifically
    sales> for Linux

    sales> On 21-Oct-98 Vojtech Pavlik wrote:
    >> The serial (and/or floppy) loading mechanism was intended, in this
    >> thread, to allow fix a badly flashed rom, as a last resort when
    >> nothing else helps.

    sales> in my case "the last resort" would involve taking the machine
    sales> apart and adding a floppy drive *or* connecting another machine
    sales> running some special software which would download the kernel
    sales> with some special protocol.

    sales> that means that the solution is not *self contained* i broken pc
    sales> would not have the h/w and/or s/w to repair a broken rom
    sales> supermicro motherboards (and i'm certainly not advocating them)
    sales> have a system whereby if you hold down some key (i forget which)
    sales> when you turn on the machine and there is a floppy in the drive -
    sales> the boot code will load a new rom image from the
    sales> floppy. absolutely minimal! - -- simon

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Werner Almesberger <almesber@lrc.di.epfl.ch> Date: Thu, 22
    sales> Oct 1998 09:50:56 +0200 (MET DST) Subject: MM with fragmented
    sales> memory

    sales> [ Posted to linux-kernel and linux-7110 ]

    sales> I'd like to get some opinions on what could be a reasonable
    sales> memory mapping for the Psion S5. The problem with this device is
    sales> that its physical RAM is scattered over a 30 bit address space in
    sales> little fragments of 512kB, aligned to multiples of 1MB. Since
    sales> it's impossible to fit any useful kernel into 512kB, some
    sales> creative memory layout is necessary.

    sales> I can see two viable approaches:

    sales> (1) play linker tricks and insert holes in the kernel such that
    sales> it skips over the gaps in memory. Then map all the memory 1:1 and
    sales> let start_mem and end_mem each have one of the 512kB fragments
    sales> for linear allocation. (2) use the MMU to create virtually
    sales> continuous memory and let the kernel manage that in the usual
    sales> way.

    sales> The problems I see with (1) are: - at least part of the memory
    sales> layout needs to be known when linking the kernel - allocations
    sales> from start_mem and end_mem are each limited to a total of 512kB -
    sales> need to re-arrange VMALLOC_END, because on ARM-Linux it's 256 MB
    sales> after PAGE_OFFSET, but VMALLOC_START will already have to be
    sales> about 278 MB after that, due to the "exploded" address
    sales> space. (But that change may be harmless.) The problems I see
    sales> with (2) are: - virt_to_phys and phys_to_virt now need to perform
    sales> lookups (in (1) they're no-ops). With a few tricks, I can get
    sales> each of them done in about 10 clock cycles, clobbering two
    sales> registers (out of 16), and accessing memory once - a little voice
    sales> in the back of my head saying that something in the kernel will
    sales> certainly trip over a virtual:physical mapping that isn't just an
    sales> offset

    sales> While I'm attracted by the simplicity of (1), I'm a little
    sales> worried about the limitation for linear allocations. Also, initrd
    sales> needs a little work to function in such a scenario.

    sales> The disadvantage of (2) is clearly its complexity. Also, I don't
    sales> like what that little voice is saying ...

    sales> Any suggestions ?

    sales> Thanks, - - Werner

    sales> - --
    sales> _________________________________________________________________________
    sales> / Werner Almesberger, DI-ICA,EPFL,CH
    sales> werner.almesberger@lrc.di.epfl.ch /
    sales> /_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Rik van Riel <H.H.vanRiel@phys.uu.nl> Date: Thu, 22 Oct
    sales> 1998 10:10:40 +0200 (CEST) Subject: Re: command source code

    sales> On Thu, 22 Oct 1998, Lee, Hee-Jin wrote:

    >> How can I get command source code such as "insmod"?

    sales> You download it from one of the countless ftp sites where it is
    sales> hosted. You can also get it on CDROM.

    sales> ftp.kernel.org sunsite.unc.edu ftp.funet.fi ftp.tsx-11.edu
    sales> ftp.redhat.com ftp.debian.org ftp.cdrom.com

    >> I'm looking for who delacares "struct device" for a network module.

    sales> /usr/bin/grep is your friend ;)

    sales> Rik.
    sales> +-------------------------------------------------------------------+
    sales> | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | |
    sales> Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
    sales> +-------------------------------------------------------------------+


    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Neil Conway <nconway.list@ukaea.org.uk> Date: Thu, 22 Oct
    sales> 1998 08:40:29 +0000 Subject: wtmp problems (with "last")

    sales> With RH5.1, few if any of the updated RPM's (mea culpa :-),
    sales> 2.1.108, I keep getting entries like these throughout my "last"
    sales> printouts, which if I am correct means corruption in the wtmp
    sales> file (?):

    sales> ing *4*** ?***P****4*****@ Wed Oct 21 18:02 still logged in
    sales> x6*@**** otify ***@ Wed Oct 21 18:02 still logged in

    sales> Any tips ?

    sales> I was concerned about disk corruption for a while, but that seems
    sales> to check out OK, so I now suspect one of the programs that should
    sales> make entries isn't doing a good job.

    sales> I tracked these down to what I *think* is happening: when someone
    sales> logs OUT, whichever program updates the file isn't finding the
    sales> right entry, and makes a bogus one at the end. I didn't get any
    sales> further than that due to lack of time and ability ;-)

    sales> TIA

    sales> Neil

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Vojtech Pavlik <vojtech-lists@twilight.ucw.cz> Date: Thu,
    sales> 22 Oct 1998 11:02:41 +0200 Subject: Re: Motherboard design
    sales> specifically for Linux

    sales> On Thu, Oct 22, 1998 at 08:33:42AM +0100, Simon Kenyon wrote:

    >> > The serial (and/or floppy) loading mechanism was intended, in this
    >> thread, to > allow fix a badly flashed rom, as a last resort when
    >> nothing else helps.
    >>
    >> in my case "the last resort" would involve taking the machine apart
    >> and adding a floppy drive *or* connecting another machine running
    >> some special software which would download the kernel with some
    >> special protocol.
    >>
    >> that means that the solution is not *self contained*

    sales> Now, how would you like to make it be self contained? If the
    sales> machine you build doesn't have a floppy, it doesn't need to have
    sales> an LS120, or a CDROM or whatever anyway, so no more luck than
    sales> with a floppy ... you'd need to take the machine apart again.

    sales> Even NOW, when the kernel is on the harddrive, and you build the
    sales> machine floppy/ CDROM/LS120/ZIP-less, you can't bring it back to
    sales> life if the kernel images on the harddrive are corrupted without
    sales> taking it apart ...

    sales> ......

    sales> And, should you have two boot time selectable kernel images in
    sales> the flash, one for actually being run and the other as a backup
    sales> for when eg. upgrading the kernel, a situation where you would
    sales> need to re-flash the flash fully would happen only very very
    sales> seldom.

    sales> And I think that when this happens, it's worth to have the
    sales> trouble with using a second computer and a serial cable, instead
    sales> of having support for every device you can load the kernel from
    sales> in the boot/kernel loader part of the flash.

    sales> Vojtech

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Philip Trickett <philipt@informatic.ie> Date: Thu, 22 Oct
    sales> 1998 10:03:53 +0100 Subject: Re: NADS for Linux

    sales> Alex Buell wrote:
    >> On Tue, 20 Oct 1998, Mark Spencer wrote:
    >>
    >> > This is the official announcment of the NADS project for Linux.
    >>
    >> Hi. I'm really sorry, but your acronym ("NADS") is making me
    >> laugh. You do know that NADS means your testicles don't you? ;o)
    >> Thanks for making my day.
    sales> Maybe they should rename it Dogs NADS? ;)

    sales> (Because after all, Linux is the Dogs Bollocks! (For those that
    sales> don't know, that is a complimentary term by the way))


    sales> Other than that, I am afraid that I am no routing expert.

    sales> Sorry, Phil - --
    sales> ========================================================================
    sales> Philip Trickett mailto:philipt@informatic.ie Systems Engineer
    sales> Marine Informatics Tel: +353-1-475-2924 64 Harcourt Street Fax:
    sales> +353-1-475-2952 Dublin 2 Republic of Ireland
    sales> http://www.informatic.ie/marine/
    sales> ========================================================================

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Andreas Jaeger <aj@arthur.rhein-neckar.de> Date: 22 Oct
    sales> 1998 11:01:24 +0200 Subject: Re: wtmp problems (with "last")

    >>>>> Neil Conway writes:

    >> With RH5.1, few if any of the updated RPM's (mea culpa :-), 2.1.108,
    >> I keep getting entries like these throughout my "last" printouts,
    >> which if I am correct means corruption in the wtmp file (?):

    >> ing *4*** ?***P****4*****@ Wed Oct 21 18:02 still logged in x6*@****
    >> otify ***@ Wed Oct 21 18:02 still logged in

    sales> glibc2 which is used with RedHat 5.1 uses a different (larger)
    sales> utmp format than libc5. If you've got program that expect the
    sales> libc5 utmp format, you'll notice this corruption. Just upgrade
    sales> those binaries. When upgrading from a libc5 distribution to a
    sales> glibc2 one, you should also `rm wtmp' since the format has
    sales> changed.

    sales> Andreas P.S. This is offtopic to linux-kernel. - -- Andreas
    sales> Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for
    sales> pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Kenneth Albanowski <kjahds@kjahds.com> Date: Thu, 22 Oct
    sales> 1998 04:59:14 -0400 (EDT) Subject: Re: MM with fragmented memory

    sales> On Thu, 22 Oct 1998, Werner Almesberger wrote:

    >> [ Posted to linux-kernel and linux-7110 ]
    >>
    >> I'd like to get some opinions on what could be a reasonable memory
    >> mapping for the Psion S5. The problem with this device is that its
    >> physical RAM is scattered over a 30 bit address space in little
    >> fragments of 512kB, aligned to multiples of 1MB. Since it's
    >> impossible to fit any useful kernel into 512kB, some creative memory
    >> layout is necessary.

    sales> I'm working with uClinux, which fits quite well in less then
    sales> 512kB of ROM, and can certainly run in 512kB of RAM (although
    sales> more is always better). Note that I don't copy the kernel from
    sales> ROM to RAM. Indeed, I go out of my way to leave things in ROM if
    sales> I can.

    >> I can see two viable approaches:
    >>
    >> (1) play linker tricks and insert holes in the kernel such that it
    >> skips over the gaps in memory. Then map all the memory 1:1 and let
    >> start_mem and end_mem each have one of the 512kB fragments for linear
    >> allocation.

    sales> I find this very interesting, from an eclectic viewpoint. If you
    sales> want to run the kernel from RAM, and it's over 512K in length,
    sales> then obviously, you'll need to teach the linker, _and probably
    sales> the assembler_ how to properly place code across the gaps, and
    sales> still let the code run. (And all of this applies equally to user
    sales> applications that try to load over gaps. If you want relocatable
    sales> code, I'd simply refuse to touch that problem.)

    sales> I have a nagging feeling that somebody else had to implement this
    sales> sort of thing, but I can't think who.

    >> (2) use the MMU to create virtually continuous memory and let the
    >> kernel manage that in the usual way.

    sales> Simplest, obviously. If you've got an MMU, take advantage of it.

    >> The problems I see with (1) are: - at least part of the memory layout
    >> needs to be known when linking the kernel

    sales> Very much so.

    >> - allocations from start_mem and end_mem are each limited to a total
    >> of 512kB

    sales> I'm not sure I follow. All allocations of memory with contiguous
    sales> physical addresses would be limited to 512K, yes. That's about
    sales> the only limit I can see. The page system would be a little
    sales> inefficient, but it can easily cope with this sort of missing
    sales> memory.

    >> - need to re-arrange VMALLOC_END, because on ARM-Linux it's 256 MB
    >> after PAGE_OFFSET, but VMALLOC_START will already have to be about
    >> 278 MB after that, due to the "exploded" address space. (But that
    >> change may be harmless.) The problems I see with (2) are: -
    >> virt_to_phys and phys_to_virt now need to perform lookups (in (1)
    >> they're no-ops). With a few tricks, I can get each of them done in
    >> about 10 clock cycles, clobbering two registers (out of 16), and
    >> accessing memory once

    sales> How often are virt_to_phys and phys_to_virt invoked? Offhand, I
    sales> can't see why these (or virt vs. bus) should be invoked very
    sales> often. (I could easily be wrong.)

    >> - a little voice in the back of my head saying that something in the
    >> kernel will certainly trip over a virtual:physical mapping that isn't
    >> just an offset

    sales> Hmm... Offhand, I have to agree. There's a problem here of how
    sales> large the "assumed address range" of a virt_to_phys ptr is. In
    sales> your case, it could range from [0K,+512K] to [-512K,0K],
    sales> depending on the original pointer.

    sales> However, once again I'm not sure I can see any reason why this
    sales> should hurt: there is no reason for the kernel to be using
    sales> physical or bus addresses for block memory accesses, unless the
    sales> ARM is considerably different then the other processors I'm
    sales> familiar with. Those address spaces should only be useful from
    sales> outside the processor, or within the processor's MMU, and no
    sales> where else.

    sales> If there was a memcpy_to_phys/bus, then you'd have to hack it up
    sales> to understand this sort of thing. But there isn't. And normal
    sales> memcpy isn't supposed to work with phys or bus address spaces, in
    sales> any case.

    sales> If it's a matter of the kernel running in a different memory
    sales> mapping mode then user code, well, you do have memcpy_to/from_fs,
    sales> and get/put_user to hide any translation.

    sales> Now will the Linux MMU code die on this sort of system? As long
    sales> as pages never cross these 512K boundries, I can't think why it
    sales> would break.

    >> While I'm attracted by the simplicity of (1), I'm a little worried
    >> about the limitation for linear allocations. Also, initrd needs a
    >> little work to function in such a scenario.

    sales> See if you can ditch initrd: if you can boot off a ROM disk, and
    sales> then mount a RAM disk in /var, you save all the memory of copying
    sales> the initrd image in to RAM. (#1 rule of small systems: if it's
    sales> already in memory somewhere, don't bother copying it somewhere
    sales> else.)

    >> The disadvantage of (2) is clearly its complexity. Also, I don't like
    >> what that little voice is saying ...
    >>
    >> Any suggestions ?

    sales> As they say, "Hope This Helped".

    >> Thanks, - Werner

    sales> Cheers, Ken

    sales> - -- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)



    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Rik van Riel <H.H.vanRiel@phys.uu.nl> Date: Thu, 22 Oct
    sales> 1998 11:19:22 +0200 (CEST) Subject: scheduler bigpatch, version 4

    sales> Hi,

    sales> I've just put out version 4 of the scheduler bigpatch. It is now
    sales> completely bugfree (guaranteed) and does: - - improve the
    sales> responsiveness of the system - - add a new scheduling class
    sales> (SCHED_IDLE) for low-priority background tasks - - the timeslice
    sales> of which you can tune through /proc/sys/kernel/sched_idle - -
    sales> adds Richard Gooches patch for a separate run queue for RT
    sales> processes, decreasing the latency realtime tasks are experiencing
    sales> when there are other tasks in the system

    sales> The patch is available from my home page.

    sales> Rik.
    sales> +-------------------------------------------------------------------+
    sales> | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | |
    sales> Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
    sales> +-------------------------------------------------------------------+


    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz> Date: Thu, 22 Oct
    sales> 1998 11:45:33 +0200 (MET DST) Subject: Re: MM with fragmented
    sales> memory

    >> I can see two viable approaches:
    >>
    >> (1) play linker tricks and insert holes in the kernel such that it
    >> skips over the gaps in memory. Then map all the memory 1:1 and let
    >> start_mem and end_mem each have one of the 512kB fragments for linear
    >> allocation.

    sales> I think if you have just 512kB fragments, it would be a lot of
    sales> trouble with linker, I guess you'd need to touch generic code in
    sales> a couple of places, etc. BTW: Are those frags at fixed locations
    sales> or do their addresses depend on how somebody stuffed SIMMs into
    sales> it? Another question: how large VA space do you have and how
    sales> large PA space the machine has? If e.g. max PA range is 2GB, but
    sales> VA is 4GB, then you could happily use 1:(1+off) mapping (or even
    sales> 1:1), and map the kernel with a virtual mapping to some other VA
    sales> (so that kernel's 2MB (or so) would have two mappings). If that's
    sales> possible, then you won. In fact, that's how things look like on
    sales> sparc64: physical memory may be non-contiguous, may start
    sales> anywhere and consists of chunks at least 4M long. We have an
    sales> automatic mapping VA=PA+PAGE_OFFSET. The kernel is located in
    sales> first physical chunk, which is mapped with a 4M page to 4MB VA.
    sales> The kernel already has PG_Skip stuff which is designed for
    sales> non-contiguous physical memory (ie. your mem_map will point to
    sales> some valid pages and some invalid pages (as no physical pages is
    sales> mapped to them).

    >> (2) use the MMU to create virtually continuous memory and let the
    >> kernel manage that in the usual way.

    sales> If the above is not possible, then this should work just fine,
    sales> although a tiny bit slower. That's what sparc32/sun4m does in
    sales> most cases, so the little voice can stay back in your head, such
    sales> scheme is tested and works.

    sales> Cheers, Jakub
    sales> ___________________________________________________________________
    sales> Jakub Jelinek | jj@sunsite.mff.cuni.cz |
    sales> http://sunsite.mff.cuni.cz Administrator of SunSITE Czech
    sales> Republic, MFF, Charles University
    sales> ___________________________________________________________________
    sales> Ultralinux - first 64bit OS to take full power of the UltraSparc
    sales> Linux version 2.1.125 on a sparc64 machine (498.80 BogoMips).
    sales> ___________________________________________________________________

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Carsten Pluntke <su0289@sx2.HRZ.Uni-Dortmund.DE> Date: Thu,
    sales> 22 Oct 1998 11:45:06 +0200 (MET DST) Subject: Re: wtmp problems
    sales> (with "last")

    sales> On Thu, 22 Oct 1998, Neil Conway wrote:

    >> [wtmp corrupted]
    >>
    >> I tracked these down to what I *think* is happening: when someone
    >> logs OUT, whichever program updates the file isn't finding the right
    >> entry, and makes a bogus one at the end. I didn't get any further
    >> than that due to lack of time and ability ;-)

    sales> Maybe 'last' and other utilities meddling with wtmp compiled
    sales> using different versions of the glibc? AFAIK, from glibc 2 the
    sales> structure of the wtmp entries have changed a bit to have enough
    sales> space for IPv6 addresses.

    sales> Check out the binaries using ldd (especially login, logout and
    sales> last)

    sales> Carsten



    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: "Etienne Lorrain" <lorrain@fb.sony.de> Date: Thu, 22 Oct
    sales> 1998 11:54:39 +0001 Subject: Re: Motherboard design specifically
    sales> for Linux

    sales> Hi,

    sales> I am not sure it is on-topic, but here are my $0.02 on this
    sales> thread (multiple answers):

    >> > > Many flash chips have a separatly write-protectable area used > >
    >> for boot areas. > > I know. Is it large enough?
    >>
    >> AMD 29F040 flash chips (512KB) are divided into 64KB sectors that can
    >> be individually erased.

    sales> Take care that even with write-protectable sectors, most of
    sales> FLASHs cannot erase and program themself by executing code from
    sales> the FLASH been treated. You also do not want to enable memory
    sales> cache in this process. A small independant ROM is sometime better
    sales> (to do basic checks like RAM check) instead of coping code to
    sales> erase/program FLASH in RAM.

    >> [people talking about reprogram FLASH after total panic]

    sales> Surely there should not be complex drivers in the non erasable
    sales> boot software, because it should be bug free. Anyway, when a
    sales> company build a motherboard, it has to test it on the production
    sales> line, without any card on the ISA bus... I have heard they use a
    sales> connection through the keyboard interface, with a very basic
    sales> protocol, use this one at last choice. Note also that
    sales> programming a FLASH *before* soldering is theoretically not
    sales> guaranted to work...

    sales> Etienne.

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: "Henning P. Schmiedehausen" <hps@tanstaafl.de> Date: 22 Oct
    sales> 1998 11:50:11 +0200 Subject: Re: OFF-Topic glibc behavior

    sales> root@chaos.analogic.com (Richard B. Johnson) writes:

    >> On Wed, 21 Oct 1998 grant@torque.net wrote:

    >>> > The following code will write "Hello World!" to the screen on >
    >>> the following platforms:
    >>>
    >>> On the screen or in /tmp/foo ???
    >>>
    >> The problem was originally shown to me, and the text was written by
    >> one who didn't want to be flamed, using 'stdout'. Thinking that
    >> 'stdout' might be special, I opened a file explicitly, finding the
    >> same behavior. I did not change the text.

    sales> Most surely, the 'struct FILE' you see (and get defined in the
    sales> includes) is just half the truth. You often have two structure
    sales> definition, one visible to the world and another one, private
    sales> with maybe much more members than the public one. You get a FILE
    sales> * pointer and can access the 'public known' fields but there are
    sales> more fields hidden beneath.

    sales> I'm not sure whether you must be allowed to copy this but this
    sales> would surely explain the behaviour. Treat FILE * as an opaque
    sales> type with no information about the size of the underlying
    sales> structure.

    sales> Kind regards Henning





    >>> Is this the simplest explanation ? Seems to me that the FILE
    >>> structure could contain (directly or indirectly) a self-referential
    >>> pointer. Moving it would certainly break something ...
    >>>
    >>> But what does this have to do with the kernel ?

    >> Read above.

    >> Cheers, Dick Johnson ***** FILE SYSTEM WAS MODIFIED ***** Penguin :
    >> Linux version 2.1.123 on an i586 machine (66.15 BogoMips). Warning :
    >> It's hard to remain at the trailing edge of technology.


    >> - To unsubscribe from this list: send the line "unsubscribe
    >> linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
    >> Please read the FAQ at http://www.tux.org/lkml/
    sales> - -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen --
    sales> hps@tanstaafl.de TANSTAAFL! Consulting - Unix, Internet, Security

    sales> Hutweide 15 Fon.: 09131 / 50654-0 "There ain't no such D-91054
    sales> Buckenhof Fax.: 09131 / 50654-20 thing as a free Linux"

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Werner Almesberger <almesber@lrc.di.epfl.ch> Date: Thu, 22
    sales> Oct 1998 11:57:38 +0200 (MET DST) Subject: Re: MM with fragmented
    sales> memory

    sales> Jakub Jelinek wrote:
    >> BTW: Are those frags at fixed locations or do their addresses depend
    >> on how somebody stuffed SIMMs into it?

    sales> They seem to be fixed on Psions, although I'd like to keep this
    sales> part generic, because (1) you never know if there isn't some odd
    sales> Psion model with a different layout, and (2) we could then re-use
    sales> things on the Geofox and other 7110-based systems.

    >> Another question: how large VA space do you have and how large PA
    >> space the machine has?

    sales> The CPU has VA = PA = 4 GB, but RAM is confined to the upper 1
    sales> GB.

    >> If e.g. max PA range is 2GB, but VA is 4GB, then you could happily
    >> use 1:(1+off) mapping (or even 1:1), and map the kernel with a
    >> virtual mapping to some other VA (so that kernel's 2MB (or so) would
    >> have two mappings).

    sales> Hmm, that's a very interesting idea ! There's one issue with
    sales> multiple mappings, though: the cache works with virtual
    sales> addresses, so if we access the same page via two different
    sales> addresses, our cache becomes inconsistent. Can such a thing ever
    sales> happen to kernel text, data, bss, and friends ?

    >> If the above is not possible, then this should work just fine,
    >> although a tiny bit slower. That's what sparc32/sun4m does in most
    >> cases, so the little voice can stay back in your head, such scheme is
    >> tested and works.

    sales> Excellent. Things look much brighter now :)

    sales> Thanks a lot !

    sales> - - Werner - --
    sales> _________________________________________________________________________
    sales> / Werner Almesberger, DI-ICA,EPFL,CH
    sales> werner.almesberger@lrc.di.epfl.ch /
    sales> /_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> From: Riley Williams <rhw@bigfoot.com> Date: Thu, 22 Oct 1998
    sales> 11:21:31 +0100 (GMT) Subject: Re: Dynamic IP hack (PR#294)

    sales> Hi there.

    >> Ummm what happens when 20 or 30 customers of IP MASQed isp descide us
    >> use say ... efnet ?

    sales> I notice that one of the 'helpers' for IP Masquerading systems is
    sales> to enable IRC to be used through such a firewall...

    sales> However, the sentiments behind your suggestion are indeed valid,
    sales> and indeed, I think I stated as much in my original message...

    sales> In addition, other problems of which I was not aware have been
    sales> pointed out to me...

    sales> Best wishes from Riley.


    sales> Please read the FAQ at http://www.tux.org/lkml/

    sales> ------------------------------

    sales> End of linux-kernel-digest V1 #2738
    sales> ***********************************

    sales> To subscribe to linux-kernel-digest, send the command:

    sales> subscribe linux-kernel-digest

    sales> in the body of a message to "Majordomo@vger.rutgers.edu". If you
    sales> want to subscribe something other than the account the mail is
    sales> coming from, such as a local redistribution list, then append
    sales> that address to the "subscribe" command; for example, to
    sales> subscribe "local-linux-kernel":

    sales> subscribe linux-kernel-digest
    sales> local-linux-kernel@your.domain.net

    sales> A non-digest (direct mail) version of this list is also
    sales> available; to subscribe to that instead, replace all instances of
    sales> "linux-kernel-digest" in the commands above with "linux-kernel".
    sales> --
    Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

    Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
    --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:45    [W:0.098 / U:30.964 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site