All of lore.kernel.org
 help / color / mirror / Atom feed
* dell i8100 touchstick, 2.5 input -- further info
From: James H. Cloos Jr. @ 2002-12-18 21:58 UTC (permalink / raw)
  To: linux-kernel, linux-fbdev-devel

I've been researching the touchstick breakage in 2.5 on the i8100.

The board appears to use a SMC lpc47n252 superIO chip for keyboard and
ps/2 support.  Details on the chip are at:

http://www.smsc.com/main/datasheets/47n252.pdf
http://www.smsc.com/main/datasheets/47n252add.pdf

It has four ps/2 ports, matrix kb support and an i8051 compatible
µcore.  The i8051 code, then, is responsible for muxing the four ps/2
ports to the host's 0x60/0x64 ioports.

Dell's bios upgrade tool flashes the 47n252.  

I added some printk()s to i8042.c and confirmed that (unless something
else is accessing the kbc during the mux activation test) the synaptics,
et al mux protocol is not supported.  

Something the 2.5 input system is doing is resetting the kbc to a
state where it no longer muxes its ps2 ports.

Obviously, a dump of the i8051 or bios code would provide all the answers.

Does anyone have any ideas on where to go from here?

Having to use the touchpad is bloody irritating. :(

-JimC

^ permalink raw reply

* Re: [PATCH]: c-r4k.c, new gcc's don't like empty labels
From: Ralf Baechle @ 2002-12-18 21:57 UTC (permalink / raw)
  To: Juan Quintela; +Cc: linux mips mailing list
In-Reply-To: <m2bs3kqez8.fsf@demo.mitica>

On Wed, Dec 18, 2002 at 02:43:07AM +0100, Juan Quintela wrote:

>         patch is trivial to eliminate warnings from the compiler

And yet I didn't like it.  The new syntax requirement isn't only ugly code,
it's harder to read than a replacing the gotos with a simple return ...

  Ralf

^ permalink raw reply

* Re: 2.5.51 ide module problem
From: Alan Cox @ 2002-12-18 22:43 UTC (permalink / raw)
  To: Jeff Chua
  Cc: Adam J. Richter, Andre Hedrick, axboe, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.42.0212190347300.10474-100000@silk.corp.fedex.com>

On Wed, 2002-12-18 at 19:50, Jeff Chua wrote:
> 
> On 18 Dec 2002, Alan Cox wrote:
> 
> > I'll get back to 2.5 IDE things next year. For the moment I'm only
> > concerned in getting the modular stuff sorted out completely in 2.4.
> > Hopefully that will be mostly valid for 2.5 as well.
> 
> I can't even boot 2.4.21-pre1 with IDE as modules. Works fine under 2.4.20
> 
> Looks like the IDE patch for 2.4.21-pre1 broke up the modules very similar
> to 2.5.51

Yes it did, and I plan to fix it there first


^ permalink raw reply

* Re: IDE-CD and VT8235 issue!!!
From: AnonimoVeneziano @ 2002-12-18 22:06 UTC (permalink / raw)
  To: John Reiser; +Cc: linux-kernel, Vojtech Pavlik, black666
In-Reply-To: <3E00EE72.1020506@BitWagon.com>

John Reiser wrote:

> Vojtech Pavlik wrote:
>
>> One more here, if you can try it (and remove the two previous ones
>> first).
>
>
> The earlier vt8235-dvd patch worked for me, but the later vt8235-min 
> did not.
>
> Mitsumi FX4830T ATAPI CD-ROM, MSI KT3 Ultra2 (KT333) mainboard, vt8235.
> -----
> kernel: hdc: status error: status=0x58 { DriveReady SeekComplete 
> DataRequest }
> kernel: hdc: drive not ready for command
> kernel: hdc: status timeout: status=0xd1 { Busy }
> kernel: hdc: DMA disabled
> kernel: hdc: drive not ready for command
> kernel: hdc: ATAPI reset complete
> kernel: hdc: status timeout: status=0xd1 { Busy }
> kernel: hdc: drive not ready for command
> -----

Hunks error? during the patching?

byez

Marcello



^ permalink raw reply

* 2.5.52 vesafb -- no display
From: Pavel Machek @ 2002-12-18 22:01 UTC (permalink / raw)
  To: kernel list

Hi!

vesafb still shows nothing on HP OmniBook. It worked in 2.5.49, IIRC,
and works on Toshiba.
								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

^ permalink raw reply

* RE: A7M266-D problems with integrate sound device and USB 2.0 PCI card
From: Alan Cox @ 2002-12-18 22:42 UTC (permalink / raw)
  To: Steve Lee; +Cc: mush, Linux Kernel Mailing List
In-Reply-To: <000301c2a6d5$bc9bfee0$0201a8c0@pluto>

On Wed, 2002-12-18 at 20:40, Steve Lee wrote:
> One of my systems uses the A7M266-D and I've never had any issues with
> the onboard sound or the usb 2.0 pci card.  I'm wondering if something
> else in your system could be causing the conflict?

BIOS version, exact plug in card combination can matter too.



^ permalink raw reply

* Re: [LARTC] WonderShaper on LAN link kills to-host speed
From: Jose Luis Domingo Lopez @ 2002-12-18 21:53 UTC (permalink / raw)
  To: lartc
In-Reply-To: <marc-lartc-104016341620263@msgid-missing>

On Tuesday, 17 December 2002, at 14:15:39 -0800,
Kenneth Porter wrote:

> What about the ingress policer would do that?
> 
As far as I know, inbound traffic (ingress) can only police packets,
that is, discard traffic on excess hoping the other end will notice it
and slow down a bit. If you want to classify incoming traffic, create
classes, attach queuing disciplines, and those nice things available in
the outgoing traffic, you must:
a) Patch your kernel with IMQ, redirect incoming traffic to it, and
treat this device as you would any "outgoing" traffic, or...
b) ...manage bandwidth in the outgoing direction on the other network
card attached to the router (if this is a router).

I'm sure somebody in this list can explain himslef much better, and
provide links to information and example code, but hope it helps.

-- 
Jose Luis Domingo Lopez
Linux Registered User #189436     Debian Linux Woody (Linux 2.4.20-xfs)
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply

* RE: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Nakajima, Jun @ 2002-12-18 22:00 UTC (permalink / raw)
  To: Linus Torvalds, Dave Jones
  Cc: Horst von Brand, linux-kernel, Alan Cox, Andrew Morton,
	Saxena, Sunil, Mallick, Asit K

BTW, in terms of validation, I think we might want to compare the results from LTP (http://ltp.sourceforge.net/), for example, by having it run on the two setups (sysenter/sysexit and int/iret). 

Jun

> -----Original Message-----
> From: Linus Torvalds [mailto:torvalds@transmeta.com]
> Sent: Wednesday, December 18, 2002 8:50 AM
> To: Dave Jones
> Cc: Horst von Brand; linux-kernel@vger.kernel.org; Alan Cox; Andrew Morton
> Subject: Freezing.. (was Re: Intel P6 vs P7 system call performance)
> 
> 
> 
> On Wed, 18 Dec 2002, Dave Jones wrote:
> > On Wed, Dec 18, 2002 at 10:40:24AM -0300, Horst von Brand wrote:
> >  > [Extremely interesting new syscall mechanism tread elided]
> >  >
> >  > What happened to "feature freeze"?
> >
> > *bites lip* it's fairly low impact *duck*.
> 
> However, it's a fair question.
> 
> I've been wondering how to formalize patch acceptance at code freeze, but
> it might be a good idea to start talking about some way to maybe put
> brakes on patches earlier, ie some kind of "required approval process".
> 
> I think the system call thing is very localized and thus not a big issue,
> but in general we do need to have something in place.
> 
> I just don't know what that "something" should be. Any ideas? I thought
> about the code freeze require buy-in from three of four people (me, Alan,
> Dave and Andrew come to mind) for a patch to go in, but that's probably
> too draconian for now. Or is it (maybe start with "needs approval by two"
> and switch it to three when going into code freeze)?
> 
> 			Linus
> 
> -
> 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/

^ permalink raw reply

* dosemu-1.1.4
From: Bart Oldeman @ 2002-12-18 21:52 UTC (permalink / raw)
  To: linux-msdos; +Cc: dosemu-devel

Hi,

dosemu-1.1.4 is now available; see www.dosemu.org/bleeding

This features
* much improved DPMI support
* much improved sound (SBPro, midi) support
* new: joystick emulation
* many PIC related cleanups
* misc fixes to IPX and network code
* misc fixes to the MFS ("lredir'ed file system")
* make install works again, configuration is a little simplified
* the new keyboard code is now enabled by default
and other bug fixes that are too important too mention...

NOTES:
* this is a development release -- some of the new code may have glitches
at certain points; if dosemu-1.0.2.1 works fine for you, and you're not
feeling adventurous then there is no good reason to use 1.1.4.
* even though the 'dosemu' wrapper script now allows a suid-root
dosemu.bin, this is not recommended: do not allow the execution of
suid-root DOSEMU by untrusted users; if DPMI is enabled, (local
"get-root") exploits are possible, and there might be other exploits that
we don't know about.
* setup-dosemu is disabled; I haven't got around to repair it yet; for
now, just edit the configuration files, compiletime-settings,
compiletime-settings.devel, dosemu.conf and ~/.dosemurc, by hand. The
defaults should "just work".

Bart


^ permalink raw reply

* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133  Promise ctrlr, or...
From: Alan Cox @ 2002-12-18 22:38 UTC (permalink / raw)
  To: D.A.M. Revok; +Cc: Andre Hedrick, Manish Lachwani, Linux Kernel Mailing List
In-Reply-To: <200212181635.58164.marvin@synapse.net>

On Wed, 2002-12-18 at 21:35, D.A.M. Revok wrote:
> So.  I /think/ that somehow the Promise controller isn't being 
> initialized properly by the Linux kernel, UNLESS the mobo's BIOS inits 
> it first?

In some situations yes. The BIOS does stuff including fixups we mere
mortals arent permitted to know about.


^ permalink raw reply

* Re: 405LP RTC reset
From: Hollis Blanchard @ 2002-12-18 21:49 UTC (permalink / raw)
  To: David Gibson; +Cc: embedded list
In-Reply-To: <20021218211556.GA8947@zax.zax>


On Wed, 2002-12-18 at 15:15, David Gibson wrote:
> On Wed, Dec 18, 2002 at 09:38:53AM -0600, Hollis Blanchard wrote:
> >
> > The only issue I can think of here is the firmware setting it
> > incorrectly or not at all. In that case, a few seconds will be expanded
> > or compressed, but that's better than time running too fast or slow
> > forever, right?
>
> That's true.  Still, I think it might be worth testing what the rate
> is set to when we come in, and printing a warning if it's not what we
> expect before we adjust it.  If it just silently corrects it I could
> imagine it being pretty nasty to track down why the device is
> losing/gaining time each boot.

Sounds like a very good idea. I'll add it to my list unless someone
beats me to it. :)

-Hollis
--
PowerPC Linux
IBM Linux Technology Center

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply

* Re: [LARTC] HTB steals bandwidth
From: Stef Coene @ 2002-12-18 21:47 UTC (permalink / raw)
  To: lartc
In-Reply-To: <marc-lartc-104005823313721@msgid-missing>

On Monday 16 December 2002 18:02, Robert Brueckmann wrote:
> Hi!
>
> I just tested my HTB setup. But I have a problem. Let's assume I run the
> following script (even if it might do nothing useful, just for
> demonstrating my problem):
>
> #!/bin/bash
> /usr/sbin/tc qdisc add dev ppp0 root handle 1: htb default 12
> /usr/sbin/tc class add dev ppp0 parent 1: classid 1:1 htb rate 125kbit ceil
> 125kbit
> /usr/sbin/tc class add dev ppp0 parent 1:1 classid 1:14 htb rate 125kbit
> ceil 125kbit prio 0
> iptables -A POSTROUTING -t mangle -o ppp0 -p tcp --dport ftp-data -j
> MARK --set-mark 14
> tc filter add dev ppp0 parent 1:0 prio 0 protocol ip handle 14 fw flowid
> 1:14
>
> I have an adsl-connection (768kbit down/128kbit up), Linux kernel 2.4.20.
> The script should do nothing to an outgoing ftp-upload, since I grant all
> the available bandwith to it. No other traffic is happending during all
> that, only one ftp-upload from a computer inside the LAN. I start the
> upload without the rules above, and the upload is at a constant maximum of
> 128kbit/sec. After running the script above and waiting for say 5 seconds,
> the upload speed drops down to app. 80 kbit/s! After removing the rules
> above, the speed climbs up again to top speed.
Have you tried with other rates and ceil values?
And you defined a default class 12, but there is no such class.
Ftp-data can use dynamic ports.  So can you check that the iptables line with 
"--dport ftp-data"  is really catching the ftp packets??


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: [LARTC] PRIO type qdisc
From: Stef Coene @ 2002-12-18 21:45 UTC (permalink / raw)
  To: lartc
In-Reply-To: <marc-lartc-104010520627418@msgid-missing>

On Tuesday 17 December 2002 07:05, Paul C. Diem wrote:
> I'm looking for a PRIO type qdisc which will prioritize packets (either
> based on DS or filters). Unlike PRIO, I need all the classes to flow into
> a single qdisc (HTB). For example:
>
>          PRIO
>
>   +--------+--------+
>
> Band0    Band1    Band2
>
>   +--------+--------+
>
>           HTB
>
> Does such a qdisc exist or is there a way to get all the PRIO classes to
> flow into a single qdisc?
There is no such qdisc.  And I don't think there is such way.

But why do you want to do this?  

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: [LARTC] WonderShaper on LAN link kills to-host speed
From: Stef Coene @ 2002-12-18 21:43 UTC (permalink / raw)
  To: lartc
In-Reply-To: <marc-lartc-104016341620263@msgid-missing>

On Tuesday 17 December 2002 23:15, Kenneth Porter wrote:
> I tried installing the WonderShaper on my internal link, mostly to get the
> SFQ installed. I set uplink and downlink to 100000 to match the link speed
> and changed the bandwidth on the cbq line to 100mbit. This killed transfer
> speed *to* the box, knocking it from 30-40 Mbps down to about 800 kbps.
> Commenting out just the ingress control restored the speed.
>
> What about the ingress policer would do that?
I'm not sure, but the policer can calculate the rate in the class in 2 ways.  
And maybe your CPU can't handle the calculations.  What CPU do you have and 
what's the load on the sstem?

> Here's the effective line after shell expansions:
>
> tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip src \
> 0.0.0.0/0 police rate 100000kbit burst 10k drop flowid :1

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

* 2.5.52 a/arch/i386/mm/init.c
From: Pavel Machek @ 2002-12-18 21:50 UTC (permalink / raw)
  To: kernel list

Hi!

In 2.5.52:

Looks suspect to me... Is it okay to do one_md_table_init, then just
discard the result? Why this change?
							Pavel

--- a/arch/i386/mm/init.c       Sun Dec 15 18:08:30 2002
+++ b/arch/i386/mm/init.c       Sun Dec 15 18:08:30 2002
@@ -134,8 +134,10 @@
        pgd = pgd_base + pgd_ofs;
        pfn = 0;

-       for (; pgd_ofs < PTRS_PER_PGD && pfn < max_low_pfn; pgd++,
pgd_ofs++) {
+       for (; pgd_ofs < PTRS_PER_PGD; pgd++, pgd_ofs++) {
                pmd = one_md_table_init(pgd);
+               if (pfn >= max_low_pfn)
+                       continue;
                for (pmd_ofs = 0; pmd_ofs < PTRS_PER_PMD && pfn <
max_low_pfn; pmd++, pmd_ofs++) {
                        /* Map with big pages if possible, otherwise
create normal page tables. */
                        if (cpu_has_pse) {

-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

^ permalink raw reply

* Re: How do I see all my partitions?
From: axel @ 2002-12-18 21:43 UTC (permalink / raw)
  To: Ray Olszewski; +Cc: linux-newbie
In-Reply-To: <5.1.0.14.1.20021218091629.02111760@celine>

Hi Ray!

On Wed, 18 Dec 2002, Ray Olszewski wrote:

> >To call fdisk for your primary IDE slave call "fdisk /dev/hda" and you
> >will get something like this:
> 
> /dev/hda is the IDE primary *master*, not the IDE primary *slave* (which is 
> /dev/hdb).

Ooops. Sorry. Was unintentionally! :)

Axel
-
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: [PATCH] An O1, nonrecursive ID allocator for Posix timers
From: george anzinger @ 2002-12-18 21:50 UTC (permalink / raw)
  To: Joe Korty; +Cc: akpm, torvalds, jim.houston, linux-kernel
In-Reply-To: <200212181553.PAA04992@rudolph.ccur.com>

Joe Korty wrote:
> 
> Hi George, Andrew, Linus, Jim, Everyone,
> 
> This is a drop-in replacement for the ID allocator that Jim Houston
> wrote to support posix timers.  The inspiration for this came from
> Andrew Morton's desire for a recursion-free allocator; in addition I
> have made it O(1) while preserving the no-upper-limits-except-memory
> attribute of the original.
> 
> I (actually Jim) spot-tested this with Jim's posix timers patch as
> the base.  It passed a run of George's timers test suite
> (http://sourceforge.net/projects/high-res-timers) and the timer
> portion of the posix test suite (http://posixtest.sourceforge.net/).
> 
> To play with, apply Jim's posix timer patch to 2.5.51 and then delete
> 
>     kernel/id2ptr.c
>     include/linux/id2ptr.h
> 
> then apply this patch.
> 
> This procedure might also work against George's timers patch, as he is
> using the same ID allocator as Jim.
> 
> Jim's timer patch may be found at:
>     http://marc.theaimsgroup.com/?l=linux-kernel&m=104006731324824&q=raw
> 
> George's timer patch may be found at:
>     http://sourceforge.net/projects/high-res-timers
> 
A few comments:

I have found that the locking needs on lookup require that
the object be locked before the id-look-up is unlocked. 
With out this it is possible to find an object and have it
"removed" by another prior to getting it locked.  This is
why, in my version, the lock is exported.  I am considering
removing the locking from the id code entirely.  The
radix-tree code does it this way.  Another issue with
locking is the irq required or not thing.  Irq locking is
VERY expensive and getting more so as cpu speeds go up and
I/O speeds stay the same.  If it is not needed, it is best
not to use it.  Again, exporting the locking to the caller
seems the best answer.

I would much prefer to return memory on release.  In my code
I currently only return the leaf nodes, but I consider this
something to be fixed rather than a feature.

While the code is order 1 it does do a divide which, as I
understand it, is rather expensive (risc machines do them
with subroutines).  It is rather easy to eliminate the
recursion in an radix-tree AND avoid the div at the same
time.

I would consider moving the "ctr" member to the root of the
tree and using the same one for all allocations.  I may be
wrong here, but I think it gives a better cycle time for the
bits used.
-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

^ permalink raw reply

* Re: [LARTC] Traffic is exceeding limits
From: Stef Coene @ 2002-12-18 21:40 UTC (permalink / raw)
  To: lartc
In-Reply-To: <marc-lartc-104021428723515@msgid-missing>

On Wednesday 18 December 2002 13:23, Mindaugas Riauba wrote:
>   I'm trying to setup traffic shaping for a customer.
> Machine is RedHat 7.3 with kernel-smp-2.4.18-18.7.x.
> HZ=512.
>
>   But when I try to load link (using netcat and discard /
> chargen services) bytes count (tc -s qdisc show, sfq qdisc)
> goes quite well over 512kbit (~560kbit). With UDP I can
> even go over 1mbit.
I did the same.  I used ttcp and recorded the bandwidth I could use. But my 
results where nearly perfetc (I recorder the bandwidth on a very log period).  
Recently I tried it with upd data but I had some strange results.  1 UDP data 
stream was shaped perfectly, but 2 UPD data streams can use the full link 
bandwidth.  I still have to test ir further.

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: [LARTC] VoIP and CBQ
From: Stef Coene @ 2002-12-18 21:37 UTC (permalink / raw)
  To: lartc
In-Reply-To: <marc-lartc-104024474627145@msgid-missing>

On Wednesday 18 December 2002 21:51, James Ma wrote:
> Hi, All,
>
> I did some work on QoS with CBQ. Basically, I wanted to separate VoIP
> traffic from other traffics and give it guarantied bandwidth. I used the
> following scripts to do the work,
>
> #!/bin/sh
>
>
> OPTION="allot 1514 maxburst 20 avpkt 1000"
>
>
> tc qdisc del dev eth0 root
>
>
> tc qdisc add dev eth0 root handle 10: cbq bandwidth 10mbit avpkt 1000
>
> tc class add dev eth0 parent 10: classid 10:2 cbq bandwidth 10mbit rate
> 34kbit $OPTION prio 3 bounded
>
> tc class add dev eth0 parent 10:2 classid 10:10 cbq bandwidth 10mbit rate
> 30kbit $OPTION prio 3
>
> tc class add dev eth0 parent 10:2 classid 10:20 cbq bandwidth 10mbit rate
> 4kbit $OPTION prio3
>
> tc filter add dev eth0 parent 10: protocol ip prio 3 u32 match ip tos 0x20
> 0xf0 flowid 10:2
>
> tc filter add dev eth0 parent 10: protocol ip prio 3 u32 match ip dst 0/0
> flowid 10:2
>
> tc filter add dev eth0 parent 10:2 protocol ip prio 3 u32 match ip tos 0x20
> 0xf0 flowid 10:10
>
> tc filter add dev eth0 parent 10:2 protocol ip prio 3 u32 match ip dst 0/0
> flowid 10:20
>
>
>
>
> It seemed working -- when there was no VoIP traffic, a ftp link was using
> all 34kbit rate. When there was VoIP traffic, the ftp rate dropped to
> 17kbit (which was correct because the voice traffic was using 17kbit).
> Unfortunately, the voice quality was not good. Even if without ftp traffic,
> there were packets loss for voice traffic (if you count from 1 to 20 with
> one handset, you miss certain figures on the other end, they are 4, 5, 8,
> 9, 12, 13 etc). Any one had the same problem before? Any one can explain
> it? Any parameter I should adjust to better suit this application? 
What if you add a small prio qdisc to class 10:10 and 10:20 ??
tc qdisc add dev eth0 parent 10:10 pfifo limit 10
This is a short pfifo that can hold 10 packets.  

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: [PATCH]:
From: Juan Quintela @ 2002-12-18 21:41 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: linux mips mailing list
In-Reply-To: <20021218202931.B20144@linux-mips.org>

>>>>> "ralf" == Ralf Baechle <ralf@linux-mips.org> writes:

ralf> On Wed, Dec 18, 2002 at 02:42:25AM +0100, Juan Quintela wrote:
>> PD. Someone can explain me what mean:
>> __attribute__ ((__mode__ (__SI__)));
>> 
>> The SI part don't appear in the gcc info pages :(

ralf> Single Integer, a 32-bit integer.

Changing the code to u32 & friends will be acepted?

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

^ permalink raw reply

* Re: [LARTC] Am I correct?
From: Stef Coene @ 2002-12-18 21:32 UTC (permalink / raw)
  To: lartc
In-Reply-To: <marc-lartc-104024602828802@msgid-missing>

On Wednesday 18 December 2002 22:12, LARTC@VLMINTERNATIONAL.COM wrote:
> I've got some customers that have lots of bandwidth that are uploading and
> downloading files to our https:// help desk and are using up all of my T-1
> at times. This leaves other customers sucking wind. I've taken a look at
> the '15.10. Example of a full nat solution with QoS' section. Would it work
> for me if I change the section that says eth0 to my internet adapter
> Serial0? If I can do that, will that allow fair sharing between all my
> customers of the https:// help desk?
>
> My setup:
>
> //////////   /////////////////   ///////
> https:// |-- |eth0 * Serial0 |-- |INET |
> //////////   /////////////////   ///////
>
> My proposed script:
>
> CEIL=1020 # actual is 1024Kbit
> IFACE=Serial0
>
> tc qdisc add dev $IFACE root handle 1: htb default 15
> tc class add dev $IFACE parent 1: classid 1:1 htb rate ${CEIL}kbit ceil
> ${CEIL}kbit
> tc class add dev $IFACE parent 1:1 classid 1:10 htb rate 170kbit ceil
> 170kbit prio 0
> tc class add dev $IFACE parent 1:1 classid 1:11 htb rate 170kbit ceil
> ${CEIL}kbit prio 1
> tc class add dev $IFACE parent 1:1 classid 1:12 htb rate 170kbit ceil
> ${CEIL}kbit prio 2
> tc class add dev $IFACE parent 1:1 classid 1:13 htb rate 170kbit ceil
> ${CEIL}kbit prio 2
> tc class add dev $IFACE parent 1:1 classid 1:14 htb rate 170kbit ceil
> ${CEIL}kbit prio 3
> tc class add dev $IFACE parent 1:1 classid 1:15 htb rate 170kbit ceil
> ${CEIL}kbit prio 3
>
> tc qdisc add dev $IFACE parent 1:12 handle 120: sfq perturb 10
> tc qdisc add dev $IFACE parent 1:13 handle 130: sfq perturb 10
> tc qdisc add dev $IFACE parent 1:14 handle 140: sfq perturb 10
> tc qdisc add dev $IFACE parent 1:15 handle 150: sfq perturb 10
>
> tc filter add dev $IFACE parent 1:0 protocol ip prio 1 handle 1 fw classid
> 1:10
> tc filter add dev $IFACE parent 1:0 protocol ip prio 2 handle 2 fw classid
> 1:11
> tc filter add dev $IFACE parent 1:0 protocol ip prio 3 handle 3 fw classid
> 1:12
> tc filter add dev $IFACE parent 1:0 protocol ip prio 4 handle 4 fw classid
> 1:13
> tc filter add dev $IFACE parent 1:0 protocol ip prio 5 handle 5 fw classid
> 1:14
> tc filter add dev $IFACE parent 1:0 protocol ip prio 6 handle 6 fw classid
> 1:15
>
> iptables -t mangle -I PREROUTING -p icmp -j MARK --set-mark 0x1
> iptables -t mangle -I PREROUTING -p icmp -j RETURN
> iptables -t mangle -I PREROUTING -p tcp -m tcp --sport ssh -j
> MARK --set-mark 0x1
> iptables -t mangle -I PREROUTING -p tcp -m tcp --sport ssh -j RETURN
> iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK
> SYN -j MARK --set-mark 0x1
> iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK
> SYN -j RETURN
> iptables -t mangle -I PREROUTING -p tcp -m tcp --sport https -j
> MARK --set-mark 0x3
> iptables -t mangle -I PREROUTING -p tcp -m tcp --sport https -j RETURN
>
> iptables -t mangle -I PREROUTING -m tos --tos Minimize-Delay -j
> MARK --set-mark 0x1
> iptables -t mangle -I PREROUTING -m tos --tos Minimize-Delay -j RETURN
> iptables -t mangle -I PREROUTING -m tos --tos Minimize-Cost -j
> MARK --set-mark 0x5
> iptables -t mangle -I PREROUTING -m tos --tos Minimize-Cost -j RETURN
> iptables -t mangle -I PREROUTING -m tos --tos Maximize-Throughput -j
> MARK --set-mark 0x6
> iptables -t mangle -I PREROUTING -m tos --tos Maximize-Throughput -j RETURN
>
> Thanks in advance for any suggestions
I think this is a good script.  
But different prio's for filters are not usefull.  They only determine the 
order the filters are matched. And in your case, there is no specific order.  
In fact, if you add 1 fw filter with no handle parameter, the mark will be 
used as filter key.  So packets marked with 16 will end up in class 1:16.  I 
think this will save more CPU cycles.

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: MIPS64 kernel cross-compiling
From: Julian Scheel @ 2002-12-18 21:31 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20021218011159.B1532@linux-mips.org>

As you read, we changed to stock 2.4.20 after the first error.
Any ideas how to fix the second problem?

Am Mittwoch, 18. Dezember 2002 01:11 schrieb Ralf Baechle:
> 2.5.  Don't dream about using it current.  Use the linux_2_4 branch.
>
>   Ralf

-- 
Grüße,
Julian

^ permalink raw reply

* [LARTC] Deleting a filter with tc makes traffic bypass all classes and the
From: Daniel Egger @ 2002-12-18 21:30 UTC (permalink / raw)
  To: lartc

Hija,

I've sort of an annoying problem:
I'm shaping traffic with HTB and have several leafs with a low
bandwitdh which are added and removed on demand (together with
the associated classes but even without it won't work).
Now "tc -s class show dev eth1" shows traffic through the whole
tree including the root; when adding another class and an filter
all the traffic gets shaped correctly. As soon as I delete the
filter (also tried the fh trick but that shouldn't matter anyways)
all traffic is completely unshaped and bypasses all classes and
the root qdisc; the statistics in 
"tc -s class show dev eth1" doesn't show any new packets and
the rates ramp up to the network interface maximum effectively
ignoring the default handle. As soon as some leaf and a filter is
readded the whole filter system behaves normal again.

I'm using iproute_20010824-9_i386.deb and kernel 2.4.20 FWIW and
would be *really* grateful for any help.

-- 
Daniel Egger <egger@spotnic.de>
WirelessCreation

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

^ permalink raw reply

* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133  Promise ctrlr, or...
From: D.A.M. Revok @ 2002-12-18 21:35 UTC (permalink / raw)
  To: Andre Hedrick; +Cc: Manish Lachwani, linux-kernel
In-Reply-To: <Pine.LNX.4.10.10212180241580.8350-100000@master.linux-ide.org>

Amendment to this email:
=====================
I figured out what it is, more...
hdparm -X12 ( to set PIO instead of UDMA ) /does not/ fix it, so I dug 
into BIOS and re-enabled the bios for that controller...

I'd disabled it because I've a SCSI burner that I use for backup
( DAR Disk ARchiver @ http://dar.linux.free.fr/  -- excellent program ),
as well as for installing distros, and I could not boot from the CD drive 
if the mobo was waiting for an OS to magically appear on whatever ATA 
device I had on the Promise-controller.  The BIOS is written to prevent 
one from choosing SCSI-boot and not Promise-boot while the Promise-BIOS 
is enabled, so I'd disabled it.
... when I re-enabled the Promise-BIOS, the problem disappeared.

So.  I /think/ that somehow the Promise controller isn't being 
initialized properly by the Linux kernel, UNLESS the mobo's BIOS inits 
it first?

============================
============================

Ah,
"What you are doing is not out of spec, just how
  you are are doing it is."
eh??

my typing in
hdparm -l /dev/hde ( upper-case Capital i ), or
smartctl -a, or
cat /proc/ide/hde/identify
are doing things wrong?
or do you mean that
 the method-used-by-these-commands is wrong somehow?

IF it'll get this fixed for everyone, then I'll sign an NDA ( probably: 
I'm reading it first, and discussing the NDA itself, too ), but I don't 
understand how NDA and GPL driver can mix?

I /want/ this fixed, because it's a problem, if for me, then for others 
too...

Does my having the "bios" for that controller turned off create the 
problem? ( I don't boot from those drives, so didn't see any reason to 
have it...  )
... hmmm I'll try changing that before contacting you again

One other weird thing is that when I've got my Quantum LM15 on the 
Promise, I've /got/ to have it on a 40-wire ribbon, or it doesn't work 
right ( can't remember if it fails to boot, or if the drive isn't 
accessable, or what )...
electronically the drive identifies as UDMA 4 or 5 or something, but if I 
put a UDMA cable on it it don't work ( solution? have a 40-wire cable on 
it, unless I've got it on the Via chipset port, in which case UDMA's 
fine... )

If you come-up-with, or have, a diagnostic that'd black-box 
reverse-engineer the bug, tell me, and I'll run it.

( note that now I'm using DAR
http://dar.linux.free.fr/
for backup, so I'm a /lot/ less worried than I used to be about hosing my 
system: the "backup your system" advice parroted always doesn't come 
with a good utility for doing so, but with DAR it's only 16 CD-Rs for 
the crucial stuff   : )   - just figured it's so good you'd benefit from 
knowing about it...   )


On Wed 18 December, 2002 5:44, Andre Hedrick wrote:
>Guess you two need to head over to promise and get those blood letting
>NDA's signed.  To figure out what is wrong with your deployment.
>I have never seen this issue and I know every combination of command
> calls to avoid.  What you are doing is not out of spec, just how you
> are are doing it is.
>
>Cheers,
>
>Andre Hedrick
>LAD Storage Consulting Group
>
>On Wed, 18 Dec 2002, D.A.M. Revok wrote:
>> Ahem.
>>
>> You /may/ want to remind me, next time, that umounting all
>> filesystems except root, remounting root read-only, AND raid-stop'ing
>> all arrays would be a good idea before doing this ( I forgot the last
>> one )
>>
>> Also, it seems that all drives de-allocate a sector every time I do
>> this, and this is costing my system integrity...
>>
>>
>> Yes, it happens on all drives on the controller, and I've 2:
>> IBM 60GXP, 40GB == /dev/hde
>> Quantum LM15, 15GB == /dev/hdg
>>
>> booting into multiuser command-line mode, no X, login as root, umount
>> everything, "smartctl -a /dev/hde" ( or hdg ) gets 2 information
>> lines, the second being the model# of the drive, and it never reaches
>> the third line ( the newline doesn't appear ), and the drive-light
>> comes on, and it's permanently hanged.
>>
>> I'd thought this would be implicit in the
>> * "cat /proc/ide/hde/identify" gets the same results *
>> comment I'd made previously, but did it out of curiosity...
>>
>>
>> When I did it on the Quantum, the Quantum's drive-light came on (
>> it's in a "mobile-rack" ), so it seems that the drive-light actually
>> is still connected to the drive at that point, though nothing useful
>> goes on after...
>>
>>
>> By the way, I seem to have hit this with the earlier 2.4.x kernels, (
>> IIRC ), but had /so/ much problems with flaky config and flaky
>> distros at the time, that I didn't get that info out then ( by the
>> time I got a stable system, I'd forgot, sorry... )
>>
>>
>> * Tell me which kernels you want me to try ( except ext3-broken ones
>> ), and I'll do it, so you can scope where-the-break-is better, TIA *
>>
>>      -me
>>
>> On Tue 17 December, 2002 7:09, you wrote:
>> >Is it happening with all the drives on the controller? Is it
>> > possible to immediaately gather the SMART data from the drive after
>> > bootup using smartctl?
>> >
>> >Thanks
>> >Manish
>> >
>> >-----Original Message-----
>>
>> From: D.A.M. Revok
>>
>> >To: linux-kernel@vger.kernel.org
>> >Sent: 12/15/02 12:49 PM
>> >Subject: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus
>> > A7V133 Promise ctrlr, or...
>> >
>> >( that's a capital-aye in the hdparm line )
>> >
>> >not even the Magic SysReq key will work.
>> >
>> >also, don't
>> >
>> >"cd /proc/ide/hde ; cat identify"
>> >
>> >... same thing
>> >drive-light comes on, but have to use the power-switch to get the
>> >machine
>> >back, ( lost stuff again, fuck )
>> >
>> >
>> >proc says it's pdc202xx
>> >
>> >Promise Ultra series driver Ver 1.20.0.7 2002-05-23
>> >Adapter: Ultra100 on M/B
>>
>> --
>> http://www.drawright.com/
>>  - "The New Drawing on the Right Side of the Brain" ( Betty Edwards,
>> check "Theory", "Gallery", and "Exercises" )
>> http://www.ldonline.org/ld_indepth/iep/seven_habits.html
>>  - "The 7 Habits of Highly Effective People" ( this site is same
>> principles as Covey's book )
>> http://www.eiconsortium.org/research/ei_theory_performance.htm
>>  - "Working With Emotional Intelligence" ( Goleman: this link is
>> /revised/ theory, "Working. . . " is practical )
>> http://www.leadershipnow.com/leadershop/1978-5.html
>>  - Corps Business: The 30 /Management Principles/ of the U.S. Marines
>> ( David Freedman )
>> -
>> 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/

-- 
http://www.drawright.com/
 - "The New Drawing on the Right Side of the Brain" ( Betty Edwards, 
check "Theory", "Gallery", and "Exercises" )
http://www.ldonline.org/ld_indepth/iep/seven_habits.html
 - "The 7 Habits of Highly Effective People" ( this site is same 
principles as Covey's book )
http://www.eiconsortium.org/research/ei_theory_performance.htm
 - "Working With Emotional Intelligence" ( Goleman: this link is 
/revised/ theory, "Working. . . " is practical )
http://www.leadershipnow.com/leadershop/1978-5.html
 - Corps Business: The 30 /Management Principles/ of the U.S. Marines ( 
David Freedman )



^ permalink raw reply

* RE: Invalid PBLK length
From: Grover, Andrew @ 2002-12-18 21:28 UTC (permalink / raw)
  To: 'Matthew Wilcox', Adachi, Kenichi
  Cc: haug-X6ztD3ggwzuBAmxm6OvjtTjhTm2NLCe8,
	acpi-devel-pyega4qmqnRoyOMFzWx49A

> From: Matthew Wilcox [mailto:willy-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org] 
> you're right.  Andy, could we add something like this?
> +#define ACPI_ADR_SPACE_FIXED_HARDWARE  (ACPI_ADR_SPACE_TYPE) 127

Yes, thanks.

Regards -- Andy

PS about the iasl glibc thing - you do know you can compile your own from
the acpica-unix source release, right?


-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart Putty.
T H I N K G E E K . C O M       http://www.thinkgeek.com/sf/

^ 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.