All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: How to extract CONFIG file for a kernel
From: Richard B. Tilley  (Brad) @ 2002-12-10 18:54 UTC (permalink / raw)
  To: SK; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20021210184805.19739.qmail@web14601.mail.yahoo.com>

If you have RH's /usr/src directory installed, you can cd to
/usr/src/linux-2.4/configs and pick from several pre-built config files.
they work nicely. I use them to build kernel.org kernels. It's *much*
easier to make a few config changes to their config file than starting
from scratch. They tend to be highly modular though... some people don't
like this.

Good luck!

On Tue, 2002-12-10 at 13:48, SK wrote:
> 
> Is there any way to extrace the CONFIG file
> used to compile a kernel. I have 2.4.18-14 kernel
> from RedHat and I want to know the config options
> used for compiling that kernel.
> 
> Any ideas..?
> Thanks
> Santhosh
> 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Richard B. Tilley (Brad), System Administrator & Web Developer
Virginia Tech, Office of the University Bursar
Phone: 540.231.6277
Fax: 540.231.3238
Page: 557.0891
Web: http://www.bursar.vt.edu


^ permalink raw reply

* problem about CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID ?
From: Hu, Boris @ 2002-12-10 18:49 UTC (permalink / raw)
  To: Linux Kernel ML (E-mail), NPTL list (E-mail)


When I read create_thread() in NPTL source code, it passes
CLONE_PARENT_SETTID 
| CLONE_CHILD_CLEARTID to sys_clone(). However, in arch/arm/kernel/sys_arm.c

(sys_clone) [kernel 2.5.49]
256         if (clone_flags & (CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID))
257                 return -EINVAL;

 I have searched CLONE_PARENT_SETTID in kernel, it seems only to appear in 
some non-architecture files, such as /include/linux/sched.h and several arch
files,
 but they do little about wrapping.  Why ARM can't support 
(CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID)? 

any comments? thanks a lot. 

  Boris
=========================
To know what I don't know
To learn what I don't know
To contribute what I know
=========================




^ permalink raw reply

* [parisc-linux] SMP on kernel version 19 pa 23
From: FARINATI,LEANDRO (HP-Brazil,ex1) @ 2002-12-10 18:41 UTC (permalink / raw)
  To: Parisc-Linux List (E-mail)

Hi people,

	I would link to know if the SMP is working on kernel 19 pa 23, 32
bits?
	
	I'm make this question because when I enable SMP to compile this
kernel and put it to run, it crashes when the systen try do boot.
	If anyone know something about this, please give me a tip to solve
this.

Thanks in Advance,

-----------------------------------------------------------------------
              Leandro Marcondes Farinati
                    Software Developer

*   leandro.farinati@hp.com

^ permalink raw reply

* How to extract CONFIG file for a kernel
From: SK @ 2002-12-10 18:48 UTC (permalink / raw)
  To: linux-kernel


Is there any way to extrace the CONFIG file
used to compile a kernel. I have 2.4.18-14 kernel
from RedHat and I want to know the config options
used for compiling that kernel.

Any ideas..?
Thanks
Santhosh



__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

^ permalink raw reply

* Re: [BENCHMARK] 2.5.51 with contest
From: Robert Love @ 2002-12-10 18:45 UTC (permalink / raw)
  To: Stan Bubrouski; +Cc: Con Kolivas, linux kernel mailing list
In-Reply-To: <3DF621D0.6040505@ccs.neu.edu>

On Tue, 2002-12-10 at 12:18, Stan Bubrouski wrote:

> I know this has been brought up before, but
> these don't seem to mean much unless you
> include 2.4.20 in the comaprison.

Comparing this to 2.4 achieves nothing because so much changed.

The point of these benchmarks are not marketing, but to find
improvements or regressions from one version to the next and find out
what caused them.

Comparing the kernel to 2.4 has some uses (i.e. finding micro-ops) but
Con's mission is much different (and imo more useful).

	Robert Love


^ permalink raw reply

* 2.5.51 -- Unresolved symbols in /lib/modules/2.5.51/kernel/3c59x.ko -- pci_set_power_state, etc.
From: Miles Lane @ 2002-12-10 18:42 UTC (permalink / raw)
  To: linux-kernel

gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
Gnu make               3.79.1
util-linux             2.11r
mount                  2.11r
modutils               2.4.22
e2fsprogs              1.27
jfsutils               1.0.17
reiserfsprogs          3.6.2
pcmcia-cs              3.1.31
PPP                    2.4.1
isdn4k-utils           3.1pre4
Linux C Library        2.2.93
Dynamic linker (ldd)   2.2.93
Procps                 2.0.7
Net-tools              1.60
Kbd                    1.06
Sh-utils               2.0.12

Running:
sh arch/i386/boot/install.sh 2.5.51 arch/i386/boot/bzImage System.map ""
(which calls "depmod -ae -F /boot/System.map-2.5.51 2.5.51"),
I get:

depmod: *** Unresolved symbols in /lib/modules/2.5.51/kernel/3c59x.ko
depmod:         pci_set_power_state
depmod:         EISA_bus
depmod:         __netdev_watchdog_up
depmod:         preempt_schedule
depmod:         _mmx_memcpy
depmod:         enable_irq
depmod:         eth_type_trans
depmod:         __kfree_skb
depmod:         alloc_skb
depmod:         pci_register_driver
depmod:         pci_bus_write_config_byte
depmod:         __release_region
depmod:         pci_free_consistent
depmod:         pci_enable_device
depmod:         alloc_etherdev
depmod:         cpu_raise_softirq
depmod:         pci_restore_state
depmod:         free_irq
depmod:         unregister_netdev
depmod:         copy_to_user
depmod:         pci_alloc_consistent
depmod:         __ioremap
depmod:         zone_table
depmod:         del_timer
depmod:         register_netdev
depmod:         linkwatch_fire_event
depmod:         mod_timer
depmod:         kfree
depmod:         disable_irq
depmod:         request_irq
depmod:         netif_rx
depmod:         pci_unregister_driver
depmod:         skb_over_panic
depmod:         pci_set_master
depmod:         pci_enable_wake
depmod:         sprintf
depmod:         copy_from_user
depmod:         jiffies
depmod:         softnet_data
depmod:         __request_region
depmod:         printk
depmod:         add_timer
depmod:         irq_stat
depmod:         pci_save_state
depmod:         __const_udelay
depmod:         ioport_resource
depmod:         do_softirq
depmod:         pci_bus_read_config_byte

  mkdir -p /lib/modules/2.5.51/kernel && cp drivers/usb/media/dsbr100.ko 
drivers
/usb/media/ibmcam.ko drivers/usb/media/usbvideo.ko 
drivers/usb/media/ultracam.ko
 drivers/usb/media/konicawc.ko drivers/usb/media/usbvideo.ko 
drivers/usb/media/o
v511.ko drivers/usb/media/pwc.ko drivers/usb/media/se401.ko 
drivers/usb/media/st
v680.ko drivers/usb/media/vicam.ko drivers/usb/media/usbvideo.ko 
/lib/modules/2.
5.51/kernel/
cp: warning: source file `drivers/usb/media/usbvideo.ko' specified more 
than once
cp: warning: source file `drivers/usb/media/usbvideo.ko' specified more 
than once

  mkdir -p /lib/modules/2.5.51/kernel && cp 
drivers/usb/serial/usbserial.ko driv
ers/usb/serial/visor.ko drivers/usb/serial/ipaq.ko 
drivers/usb/serial/whiteheat.
ko drivers/usb/serial/ftdi_sio.ko drivers/usb/serial/keyspan_pda.ko 
drivers/usb/
serial/keyspan_pda.ko drivers/usb/serial/omninet.ko 
drivers/usb/serial/digi_acce
leport.ko drivers/usb/serial/belkin_sa.ko drivers/usb/serial/empeg.ko 
drivers/us
b/serial/mct_u232.ko drivers/usb/serial/io_edgeport.ko 
drivers/usb/serial/io_ti.
ko drivers/usb/serial/pl2303.ko drivers/usb/serial/cyberjack.ko 
drivers/usb/seri
al/ir-usb.ko drivers/usb/serial/kl5kusb105.ko 
drivers/usb/serial/safe_serial.ko
/lib/modules/2.5.51/kernel/
cp: warning: source file `drivers/usb/serial/keyspan_pda.ko' specified 
more than once




^ permalink raw reply

* 2.4.20 AGP for I845 wrong ?
From: Margit Schubert-While @ 2002-12-10 18:42 UTC (permalink / raw)
  To: linux-kernel

 From drivers/char/agp/agpgart_be.c
4554,4559
     { PCI_DEVICE_ID_INTEL_845_G_0,
                  PCI_VENDOR_ID_INTEL,
                  INTEL_I845_G,
                  "Intel",
                  "i845G",
                  intel_830mp_setup },

Surely this is wrong or ?
Should be "intel_845_setup", I think.

Which might explain funny messages in th X/DRI/DRM log.

For info, the Intel M/B D845PESV(L) reports as a "G" -
00:00.0 Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host 
Bridge (rev 02)
00:01.0 PCI bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset AGP Bridge 
(rev 02)

Also in drivers/char/drm/drm_agpsupport.h, the switch statement at 262 is 
missing the
cases for INTEL_I830_M, INTEL_I845_G.

Margit


^ permalink raw reply

* Re: ECN target bug report
From: Andrea Rossato @ 2002-12-10 18:30 UTC (permalink / raw)
  To: netfilter-devel
In-Reply-To: <3DF62FAF.9050908@trash.net>

Patrick McHardy wrote:
> I thought calculating checksum for x and htons(x) should give me same 
> result, obiously that is wrong (which i learned after trying it out).
> For the first patch: *tcpflags are bitfields (position declared 
> dependant of endianess), so no htons here.
> For the second patch, it's working with or without, although i think the 
> correct way is with the patch:
> 
> u_int16_t diffs[2];
> diffs[0] = htons(iph->tos) ^ 0xFFFF;
> ...
> diffs[1] = htons(iph->tos);
> ...
> 
> iph->tos is of type u_int8_t. so no htons is necessary.


I know netiquette suggest not to send messages just to thank...but i 
spet the whole afternoon trying to understand when exactly host-to-net 
byte order translation was needed without results!
Now I've got it!!
Thanks,
andrea

^ permalink raw reply

* [parisc-linux] (no subject)
From: KING,RICHARD (HP-Boise,ex1) @ 2002-12-10 18:25 UTC (permalink / raw)
  To: 'parisc-linux@lists.parisc-linux.org'

confirm 133734

^ permalink raw reply

* new driver to replace LMC
From: david linux @ 2002-12-10 18:33 UTC (permalink / raw)
  To: linux-kernel

To whom it may concern,

I work with linux drivers for wan cards (etc.), and
there is a driver currently in the kernel (for some of
the devices I work with) which is way old. 
I'd be happy to submit the new driver (at least the
replacement for the stale stuff being passed around)
to be wrapped in new kernel versions ... but I don't
know who would be best to write re this subject.

I would appreciate help in being pointed to the right
direction for this.

The "old" driver that I'm talking about is the Lan
Meadia, Corp driver.  LMC was bought-out awhile ago,
and since then many bug fixes have been made, etc.


Thanks in advance,
David



__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

^ permalink raw reply

* Re: longrun not working
From: Joshua N Pritikin @ 2002-12-10 18:32 UTC (permalink / raw)
  To: linux-kernel; +Cc: robm
In-Reply-To: <20021208160349.GA712@always.joy.eth.net>

On Sun, Dec 08, 2002 at 09:33:49PM +0530, Joshua N Pritikin wrote:
> i have a Fujitsu P-Series laptop (TM5800 CPU @ 800MHz) running Linux
> 2.4.20 (debian) with devfs, CONFIG_MCRUSOE, CONFIG_X86_MSR, and
> CONFIG_X86_CPUID.
> 
> emit:/usr/src/pseries/longrun# ls -l /dev/cpu/0/
> total 0
> crw-rw----    1 root     root     203,   0 Dec  8  2002 cpuid
> crw-rw----    1 root     root     202,   0 Dec  8  2002 msr
> 
> When i try longrun 0.9, i get a failure at the first call to
> read_cpuid() in check_cpu(), line 186.
> 
> (Actually longrun was working on my laptop about a month ago
> then it mysterious started failing, as described.  i don't
> know what changed.)
> 
> Who is maintaining longrun?  What more information can i provide
> to help in debugging?

This problem was due to some problem in the debian unstable
version of libc6.  i am filing a bug report with debian.

-- 
Victory to the Divine Mother!!         after all,
  http://sahajayoga.org                  http://why-compete.org

^ permalink raw reply

* Re: [PATCH 2.4] IP: disable ECN support by default - Config option
From: Krzysztof Halasa @ 2002-12-10  2:53 UTC (permalink / raw)
  To: linux-kernel
In-Reply-To: <200212100316.59910.m.c.p@wolk-project.de>

Marc-Christian Petersen <m.c.p@wolk-project.de> writes:

> attached super trivial patch gives us a config option to choose whether we 
> want ECN disabled per default if selected or not.

Why do we need that if we can enable/disable ECN at runtime?
-- 
Krzysztof Halasa
Network Administrator

^ permalink raw reply

* Re: [BUG]: agpgart for i810 chipsets broken in 2.5.51
From: Antonino Daplas @ 2002-12-10 21:23 UTC (permalink / raw)
  To: Dave Jones; +Cc: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <20021210182120.GD577@codemonkey.org.uk>

On Tue, 2002-12-10 at 23:21, Dave Jones wrote:
> On Wed, Dec 11, 2002 at 02:00:47AM +0500, Antonino Daplas wrote:
> I did something similar in my pending tree, but I just made it
> unconditional instead of littering lots of ifdefs.

That's great.  Thanks. 

Tony



^ permalink raw reply

* Re: Strange connections
From: Michail Bachmann @ 2002-12-10 18:19 UTC (permalink / raw)
  To: linux-diald@vger.kernel.org
In-Reply-To: <3DF56F7C.9070307@branjardiere.com>

On Tuesday 10 December 2002 05:37, Rene Starneauld wrote:
> Michail Bachmann wrote:
> > On Monday 09 December 2002 19:30, Rene Starneauld wrote:
> >>OK, route -n does not bring up the link, then I must set up reverse DNS
> >>lookup, thats fine but how do I do that.
> >
> > Add all your internal hostnames and their ip addresses to /etc/hosts

> That, I did already

Every ip which you can see with route -n?
You even need the ip of the tun|tap|sl interface, both the remote and the local part.


CU Micha

^ permalink raw reply

* RE: Port Forwarding only works outside?
From: Todd Hartman @ 2002-12-10 18:18 UTC (permalink / raw)
  To: 'Andrea Rossato', netfilter

This seemed to do the trick! Thanks. (Though I'm not sure why it's working
now when my box at home doesn't have this and IT works okay. Very strange
indeed. Oh well.)

-T


-----Original Message-----
From: Andrea Rossato [mailto:mailing_list@istitutocolli.org] 
Sent: Tuesday, December 10, 2002 11:53 AM
To: netfilter@lists.netfilter.org
Subject: Re: Port Forwarding only works outside?


iptables -A POSTROUTING -o eth1 -j MASQERADE
you need to change source address of the forwarded traffic, so that it 
can go back for the same way it came in from.

andrea
 >

Todd Hartman wrote:
> I tried the suggestion and I'm sorry to say that it didn't work 
> either. I realize I didn't give very exacting details on what we had 
> already. I'll do that now. Here's the /etc/sysconfig/iptables file I'm 
> currently working with. This was generated through the webmin 
> interface.
> 
>   # Generated by iptables-save v1.2.5 on Tue Dec 10 10:52:38 2002
>   *nat
>   :OUTPUT ACCEPT [0:0]
>   :PREROUTING ACCEPT [0:0]
>   :POSTROUTING ACCEPT [0:0]
>   -A POSTROUTING -o eth0 -j MASQUERADE
>   -A PREROUTING -p tcp -m tcp -i eth0 --dport 25 -j DNAT 
> --to-destination 192.168.1.29:25
>   COMMIT
>   # Completed on Tue Dec 10 10:52:38 2002
>   # Generated by iptables-save v1.2.5 on Tue Dec 10 10:52:38 2002
>   *mangle
>   :PREROUTING ACCEPT [272:72783]
>   :INPUT ACCEPT [6571:1221017]
>   :FORWARD ACCEPT [2516:1428106]
>   :OUTPUT ACCEPT [296:174336]
>   :POSTROUTING ACCEPT [7989:3971198]
>   COMMIT
>   # Completed on Tue Dec 10 10:52:38 2002
>   # Generated by iptables-save v1.2.5 on Tue Dec 10 10:52:38 2002
>   *filter
>   :INPUT ACCEPT [273:72823]
>   :FORWARD ACCEPT [0:0]
>   :OUTPUT ACCEPT [296:174336]
>   COMMIT
>   # Completed on Tue Dec 10 10:52:38 2002
> 
> I have another server at home that's doing pretty much the same thing 
> with different ports (for games on a machine behind the firewall) and 
> that's working fine. If I change that 192.168.1.29:25 to my home 
> server's IP, it forwards just fine. Also, on this firwall, I can 
> telnet to 192.168.1.29 25 but I can't seem to forward to it.
> 
> -T
> 
> -----Original Message-----
> From: Sander Sneekes [mailto:sander@dmdsecure.com]
> Sent: Tuesday, December 10, 2002 10:29 AM
> To: Todd Hartman
> Cc: 'netfilter@lists.netfilter.org'
> Subject: Re: Port Forwarding only works outside?
> 
> 
> try
> 
> iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE 
> iptables -A FORWARD -p tcp --dport 25 -d 192.168.1.29 -j ACCEPT 
> iptables -A PREROUTING -t nat -p tcp --dport 25 -d x.x.x.x -j DNAT 
> --to 192.168.1.29
> 
> x.x.x.x = eth0 external ip
> 
> On Tue, 2002-12-10 at 16:31, Todd Hartman wrote:
> 
>>I've come across an issue I just don't know how to solve. I'm not even 
>>certain it's an issue with iptables itself, but I thought that someone 
>>here might have run across this before and have some advice.
>> 
>>I've got a RH7.3 box set up with two NICs. Eth0 is external and eth1 
>>is internal. Internal network is 192.168.1.* with netmask 
>>255.255.255.128. I need to forward traffic on eth0, port 25 to 
>>192.168.1.29. The firewall is 192.168.1.1 - both in the same subnet as 
>>I understand it.
>> 
>>When I forward SMTP traffic to 192.168.1.29 and try to telnet to port 
>>25 to test SMTP, it just sits there, unresponsive. BUT, if I forward 
>>eth0 port 25 traffic to a machine out on the internet, it works just 
>>fine.
>> 
>>I suspect a networking problem, but I don't know well enough to pin it 
>>down myself.
>> 
>>-T
>> 
> 
> 



^ permalink raw reply

* Re: ECN target bug report
From: Patrick McHardy @ 2002-12-10 18:17 UTC (permalink / raw)
  To: Andrea Rossato; +Cc: netfilter-devel
In-Reply-To: <3DF6241A.9040404@istitutocolli.org>

Hi,

Andrea Rossato wrote:

> Patrick McHardy wrote:
>
>> the first attached patch fixes the issue you reported (verified), 
>> altough i'm not entirely sure why ;).
>> the second one is untested but probably couldn't hurt neither.
>
>
> great patrick! faster then light!
>
> BTW, your second patch seems to imply that byte order is just a matter 
> of taste ;)
>
> iph and tcph should give little endian int on i386 arch, so tons 
> should be needed when writing to the sk_buff. but in computer 
> programming there are misteries a lawyar will never be able to grasp...

I thought calculating checksum for x and htons(x) should give me same 
result, obiously that is wrong (which i learned after trying it out).
For the first patch: *tcpflags are bitfields (position declared 
dependant of endianess), so no htons here.
For the second patch, it's working with or without, although i think the 
correct way is with the patch:

u_int16_t diffs[2];
diffs[0] = htons(iph->tos) ^ 0xFFFF;
...
diffs[1] = htons(iph->tos);
...

iph->tos is of type u_int8_t. so no htons is necessary.

Bye,
Patrick

^ permalink raw reply

* Re: [PATCH] cs46xx Phase reversal fixes and some AC3 pass through progress
From: Takashi Iwai @ 2002-12-10 18:15 UTC (permalink / raw)
  To: Benny Sjostrand; +Cc: alsa-devel
In-Reply-To: <3DF505CD.5050807@cucumelo.org>

At Mon, 09 Dec 2002 22:06:21 +0100,
Benny Sjostrand wrote:
> 
> >
> >
> >the spdif output on my terratec x-fire seems working fine now, at
> >least for the normal playback.  however, if i stop the playback in the
> >  
> >
> >middle, it results in a constant beep.  does happen on another card?
> >
> 
> It has not happen for me (yet)
> 
> Sounds like there some garbage left in some sample buffer.
> Did you use the IEC958 PCM device (aplay -Dhw:0,2)  or just turn on the
> SPDIF output switch in mixer ???

i've used -Dhw:0,2.  well, it seems fixed on the latest version.

thanks!


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

^ permalink raw reply

* Re: [BUG]: agpgart for i810 chipsets broken in 2.5.51
From: Dave Jones @ 2002-12-10 18:21 UTC (permalink / raw)
  To: Antonino Daplas; +Cc: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <1039553986.1054.7.camel@localhost.localdomain>

On Wed, Dec 11, 2002 at 02:00:47AM +0500, Antonino Daplas wrote:
 > 
 > Oops, Alan beat me into it. It's basically the same as what I've got
 > except I had an i810fb specific macro.  I guess the one without the
 > macro is cleaner.

I did something similar in my pending tree, but I just made it
unconditional instead of littering lots of ifdefs.

        Dave


^ permalink raw reply

* hard drive head parking in linux
From: Jerry James Haumberger @ 2002-12-10 18:12 UTC (permalink / raw)
  To: linux-newbie


Hello, Steven --

>> I understand that early PC hard drives had to have 
>> their heads parked when shut down, 

>A blast from the past.  Yes, indeed, pre-IDE drives 
>(two data cables) needed parking.  Over the years I've 
>had several of these monsters.  I even installed a small
>Linux on one (it had to be small 'cause the HD was only
>20mb :-).  Did you know that the latest Slackware (8.1) 
>still provides a stock kernel (xt.i) for such drives?
>Imagine that: a 2.4.18 kernel on an old Seagate MFM.   

But do you know whether or not Linux lifts the HD heads after a
period of inactivity, or is this already an automatic feature
of the later hard drives... say, my (approx.) 700MB HD on
this machine?  I'm guessing Linux (including your BL 1.7)
parks hard drive heads (if not done by the HD mechanism itself)
upon shutdown... but I'm not certain about what happens to
the hard drive heads during up time...

Or are you implying that the "stock kernel (xt.i)" *does*
support this hard drive head parking/"resting" feature... for
XTs and later hard drives?

>You gotta give credit to Jerry.  He doesn't just talk the
>talk, he walks the walk.  A close reading of his message
>header reveals that he is indeed using a minimalist mailer
>for this list.

Oh?  I thought that "mail" was the Standard Procedure for "Mr.
BasicLinux" himself... ;-)

This 486 DX2 is one of my more *powerful* machines... actually,
it was "newly" constructed (with some used parts, but new case and
monitor) only about five years ago.  This was done at my expense
through Computer Renaissance in the USA.  I've intended it to be
a showcase demonstration of the capabilities of a DOS-only computer
system comprised largely of freeware and/or abandoned software
(and some inexpensive shareware from my past purchases); it contains
PC DOS 7 in its boot-up partition (thrown away -- still in the
unbroken plastic-wrapped box).  Now, however, it also demonsrates
the dual capabilities of DOS/Linux -- thanks to your wonderful
distribution of BasicLinux 1.7.  I've wished for several years to
have a console-only installation of Linux (without that enormous
quantity of "X" material) from which I could have full textual
style Internet services.  Your BasicLinux is installed in the
larger area of this machine's hard drive (PC DOS has about 160 MBs,
and BasicLinux 1.7 has two partitions in the remainder of the
688 MB HD, minus around 16 MBs for its swap partition).  Originally,
the Linux partition was RH 5.0, but I couldn't figure out how to
install that without X, until your excellent distribution became
available -- which only occupies (according to du) about 9.2 MBs of
its ext2 partition (this includes several other add-ons from the
Slackware 3.5 distribution site; your basic BL installation is only
about half that size, I believe).

And I have other classic systems -- a venerable old IBM AT and XT,
among others... all in splendid shape and Internet-ready...

Anyway, back to topic... ?!

Jerry... on a 486 DX2-50MHz with 8MB RAM in BasicLinux 1.7
and Midnight Commander at the lab of Classic Systems, Ltd.


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

^ permalink raw reply

* Re: [LARTC] TBF algorithm/usage
From: Radu-Mihail Obada @ 2002-12-10 18:12 UTC (permalink / raw)
  To: lartc
In-Reply-To: <marc-lartc-103953705603989@msgid-missing>

Ok, I guess I got the point. And I think this is not exactly what I want to
do. Thanks for your help.
> Tbf limits all bandwidth that leaves the NIC.  What you want to do, limit each 
> connection to a certain bandwidth, is not so easy to implement.  If you want 
> to do it per ip-address, or port, you can create a cbq or htb setup.  So you 
> can put each connection in a different class and limit the speed it can get.  
> The filtering can be done on ports and/or ip-addresses.  But if you want a 
> class for each connection, you will need a lot of classes.
> 
> Stef
> 
> -- 
> 
> stef.coene@docum.org
>  "Using Linux as bandwidth manager"
>      http://www.docum.org/
>      #lartc @ irc.oftc.net
> 

-- 
Radu-Mihail Obada
System administrator & web programmer,
Faculty of Mathematics and Computer Science,
University of Bucharest
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply

* Re: hidden interface (ARP) 2.4.20
From: Roberto Nibali @ 2002-12-10 18:15 UTC (permalink / raw)
  To: Bill Davidsen; +Cc: 'linux-kernel@vger.kernel.org', linux-net
In-Reply-To: <Pine.LNX.3.96.1021210093408.12210B-100000@gatekeeper.tmr.com>

>>Yes, source address selection based on different rules and routing 
>>tables. What does it have to do with the hidden patch?
>  
>   I see it as an alternative solution to the problem the hidden patch is
> addressing. Perhaps a more general one, although the method of causing
> such routing might not be source routing in the "ip" sense.

Ohh, now I see where you're coming from. You mean the additional 
blackhole routes you need to add on every box that need to mimic the 
'non-arp parlance' or the 'do not choose this address for reply', right?

>>??? Depends how you use those multiple default routes. If you do nexthop 
>>routing you do sort of RR balancing on preferred routes. If you do 
>>source address selection routing based on rules you have fixed default 
>>routes which will not match because of the fewest hops but because of 
>>the rule. I am a bit confused as to what you're trying to tell me.
>  
> I have in mid multiple ISPs for redundancy, perhaps a pair of OC12s or
> similar. Sites would be reachable from either, but fewer hops to one or
> the other. When the client connects, it avoids asymmetric routing to reply
> on the same router.

I understand everything but the last sentence. You have a couple of 
redundant ISP links which can all act as a router to the Internet, the 
only difference is that if you go over some of them you need less hops. 
Now in order to avoid asymmetric routing you need the hidden patch? I 
apologise for being so narrow minded but I still don't get it.

>>>Source routing takes too much overhead for lots of connections, and as I
>>
>>Either we have a different view of source routing or I have to ask you 
>>why you think there is too much overhead with source routing.
>  
> More rules, more overhead, having to set up a rule per IP (which can be
> dynamic) takes overhead.

Only if you change your rules once every 1000 packets maybe but other 
than that I doubt there is a significant overhead to the hidden patch. I 
would denote the overhead as being something in the range of O(log N), 
with N being the amount of routes. The way I understand the source 
address selection algorithm efficiency for routing decision is that you 
look up the fast routing cache and if there is no hit you try to find 
the preferred route by walking the tree-like structure of rules and 
their according routes. Of course you have a worst case bounce table 
walking if every rule matches but no route in the according table can be 
selected (this would be a pretty stupid setup to begin with). This would 
mean a complete walk through all routing tables until you have a 
preferred match. In this case it is 0(N) but after that it is in the 
routing cache and therefore O(1) again :).

Please anyone correct me if I'm wrong.

>>>recall is limited to 256 rules. I'm not sure the hidden interface patch
>>>really does this, although I just looked quickly.
>>
>>The hidden patch doesn't do source routing and the limit of available 
>>source routes is 254 but not because of the rules (you can have 2**16 
>>rule entries) but because of the amount of routing tables which is 256 
>>[0..255] minus local table minus main table which equals to 254 tables.
>  
> I actually meant that the patch didn't do this in another way, but you
> have noted that the number of routing tables is limited. That may or may
> not be a limitation depending on complexity. In any case a single
> use-configured-interface patch avoids having tables.

That is something I certainly agree with you.

>>>the networking area. I don't expect them to be adopted in the main kernel,
>>>but as long as they're easier than making multiple configs, particularly
>>>at runtime, they will be around.
>>
>>Yes, definitely. And I think noone has said anything against that.
>  
> I thought this thread had a "please don't post patches like that we don't
> want it in the kernel" early on in the thread, but I've expired the
> message and lack time to dig archives.

You're right. After rereading my email I think I owe the original poster 
my apology for those rather harsh words. He even cc'd Julian who is the 
author and maintainer of those patches.

Best regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc


^ permalink raw reply

* ALSA-drivers-writing howto updated
From: Takashi Iwai @ 2002-12-10 18:11 UTC (permalink / raw)
  To: alsa-devel

Hi,

i've updated my alsa-drivers-writing howto document, including
corrections, more complete example codes in sub-sections, and more
detailed explanation in some unclear parts (thanks to Phil Kerr).

regarding to conversion to other formats:  Kevin Conder already
proposed to convert to DocBook, but he'll have no time until the next
weekend.

the document is found at the same place,

	http://www.alsa-project.org/~iwai/alsa-drivers-writing.txt

please give your comments, criticism and/or corrections.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

^ permalink raw reply

* Re: [LARTC] TBF algorithm/usage
From: Stef Coene @ 2002-12-10 18:08 UTC (permalink / raw)
  To: lartc
In-Reply-To: <marc-lartc-103953705603989@msgid-missing>

On Tuesday 10 December 2002 15:51, Radu-Mihail Obada wrote:
> Hello everyone,
> I have a (mini) Linux router, which goes "out" through eth0; eth0 is
> capable of almost 2Mbit of bandwith (well, actually it's like 10Mbit,
> but you wouldn't care less). Now, say I want to limit _everything_, like
> in every connection. So naturally, after carefully reading the man pages
> and that excellent HOWTO, I resort to TBF. I fiddle a lit with this, but
> after a couple of hours of intense experimentation, I find that it
> doesn't do what I really want it to.
> Specifically, I want _every_ connection to use _at most_ (say) 16kbps,
> never more, even if there is some bandwidth to borrow from. But TBF doesn't
> seem to do just that (or I don't understand its inner working, which I
> kinda don't). And what does burst mean/do? tc-tbf(8) says that I would
> never need to modify this, but tc qdisc add ... root tbf always requires
> it.
> Thanks in advance.
Tbf limits all bandwidth that leaves the NIC.  What you want to do, limit each 
connection to a certain bandwidth, is not so easy to implement.  If you want 
to do it per ip-address, or port, you can create a cbq or htb setup.  So you 
can put each connection in a different class and limit the speed it can get.  
The filtering can be done on ports and/or ip-addresses.  But if you want a 
class for each connection, you will need a lot of classes.

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply

* Re: hidden interface (ARP) 2.4.20 / network performance
From: Roberto Nibali @ 2002-12-10 18:11 UTC (permalink / raw)
  To: Stephan von Krawczynski; +Cc: willy, linux-kernel, linux-net, jamal
In-Reply-To: <20021210140912.7a9092b6.skraw@ithnet.com>

>>Could you please be more specific on what exactly you're trying to 
>>achieve? Do you want to load balance an application whose average 
>>package size is 80 bytes? How many sustained connections per seconds do 
>>you have?
>  
> Well, what I am trying to say is this: my experience is that under load with
> small sized packets even standard routing/packet forwarding becomes lossy. If I

That's a known fact, however I experienced Linux to perform the best in 
such worst case situations among several other Unices I tested, and NAPI 
certainly has brought some improvements in this area.

> put NAT and other nice netfilter features on top of such a situation things get
> a lot worse (obviously) - no comparison to building the "application" (e.g.
> cluster) with routing and hidden-patch (mainly because of its pure simplicity I
> guess).

I'm afraid but I don't understand what you mean with the second part of 
your statement.

> Don't get me wrong: I am pretty content with the hidden-patch and my setup
> without NAT. But I wanted to point to the direction of possible further routing
> performance improvement in 2.4.X tree. Is it correct that I can expect higher

Huh? Routing performance improvements? Routing is almost possible at 
wire speed. Some 60us delay per packet maybe (in case of load balancing 
decisions) but what do you want to improve?

I agree with you that netfilter NAT performance should and possibly can 
be impoved. And people are working on proof-of-concept improvements of 
NAPT in the Linux kernel including the netfilter team. But again, for me 
the hidden patch (http://www.ssi.bg/~ja/hidden-2.4.20pre10-1.diff) as it 
can be found does nothing to improve your situation.

> data-rates (concerning small packets) if using higher HZ ?

I doubt this would help much but I haven't tested it and I do not see 
all consequences on the routing, the routing cache and the FIB policy of 
modifying HZ. I couldn't comment on that.

> Someone selling E3 cards told me he cannot manage loads like these (small
> packet stuff) with a stock kernel, and that you _at least_ have to increase HZ
> to get acceptable throughput results.

Now that certainly is interesting, does he have any nice numbers to back 
this up? I'd be very interested. Also I've cc'd Jamal (I hope he will 
forgive me for that) who's working in this field since a couple of years 
now. Maybe he can comment on the HZ changes.

Best regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc


^ permalink raw reply

* Re: HPT372 RAID controller
From: Spacecake @ 2002-12-10 18:09 UTC (permalink / raw)
  To: Alan Cox; +Cc: sflory, linux-kernel
In-Reply-To: <1039480307.12051.8.camel@irongate.swansea.linux.org.uk>

Hi,

> Check the notes on -ac kernels when doing this. I try and note when
> stuff is stable or not

Because of a recent crash (the first ever using linux on this hardware,
using 2.4.18 through 2.4.20), i went in search of these release notes. I
feel really stupid here, but i can't find them, not on
linux.org.uk/thefreeworld.net, google, kernel.org... umm?

The crash in question was while copying between hard disks (both on the
RAID controller) a directory tree of MP3s, about 95megs. I was in X at
the time so i couldn't see any errors if there was some, and the machine
totally locked up, tried pinging it etc, didn't work.
Can't find any errors in logfiles or anything.

The .config for the kernel was identical to my 2.4.20 config that has
never crashed, except it has IDE Taskfile IO enabled, because from the
help this seemed like a good thing.

Do you want me to provide debugging info on this? It's okay if not, i'll
just wait until stuff works in the main stable kernel :)

Thanks,
 - Daniel

P.S. please CC any replies to me, i'm no longer subscribed to LKML.

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.