* Re: [parisc-linux] SMP on kernel version 19 pa 23
From: Arto Jantunen @ 2002-12-10 21:45 UTC (permalink / raw)
To: Grant Grundler
Cc: FARINATI,LEANDRO (HP-Brazil,ex1), Parisc-Linux List (E-mail)
In-Reply-To: <20021210192412.GB16933@dsl2.external.hp.com>
grundler@dsl2.external.hp.com (Grant Grundler) writes:
> On Tue, Dec 10, 2002 at 10:41:00AM -0800, FARINATI,LEANDRO wrote:
>> I would link to know if the SMP is working on kernel 19 pa 23, 32
>> bits?
>
> I assume you mean 2.4.19-pa23.
> IIRC 2.4.19-pa24 booted/worked on a500 (64-bit) and I thought that was
> an SMP kernel but aren't sure now.
The main thing here is that 32- and 64-bit SMP kernels are very
different. On a D390 a 32-bit kernel crashes on a lot of cases (I've
submited info on atleast three of those) and 64-bit kernel also
crashes, but in a very different way (and for very different reasons,
I'm quite sure). Lots of people have managed to run 64-bit SMP
kernels, I haven't heard of any succesful 32-bit SMP yet...
--
Arto Jantunen
^ permalink raw reply
* Re: Fwd: Re: [LARTC] HTB with SFQ in leaf classes. & setup question
From: Nickola Kolev @ 2002-12-10 21:44 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103955587129711@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 977 bytes --]
On Tue, 10 Dec 2002 23:27:39 +0200
lartc@e-apollo.lv wrote:
> Ok, just a second ago i did '/sbin/tc qdisc del dev eth2 root'
> And added the classes again.
>
> me@myplace$ ping 80.81.33.1
> PING 80.81.33.1 (80.81.33.1): 56 octets data
> 64 octets from 80.81.33.1: icmp_seq=0 ttl=252 time=24.6 ms
> 64 octets from 80.81.33.1: icmp_seq=1 ttl=252 time=21.9 ms
>
> --- 80.81.33.1 ping statistics ---
> 2 packets transmitted, 2 packets received, 0% packet loss
> round-trip min/avg/max = 21.9/23.2/24.6 ms
>
> I can reach ISP's gateway very smoothly now!
Hello, I'm running a similar setup with about a thousand clients, separated in several level
hierarchy. The machine is also similar. I had the same problem half a year ago.
Anyway, can you tell us what is the version of htb? It's htb2, isn't it? Try upgrading to htb3, this
will solve your problem. If not, just put a crontab job to restart (i.e. delete and the recreate)
the htb classes every 1/2 hour.
Hth,
Nickola
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [BK-2.4] [PATCH] Small do_mmap_pgoff correction
From: Marcelo Tosatti @ 2002-12-10 18:52 UTC (permalink / raw)
To: David S. Miller; +Cc: raul, linux-kernel
In-Reply-To: <20021210.132207.23687680.davem@redhat.com>
On Tue, 10 Dec 2002, David S. Miller wrote:
> From: DervishD <raul@pleyades.net>
> Date: Tue, 10 Dec 2002 21:59:06 +0100
>
> Because PAGE_ALIGN won't return 0?
>
> What if TASK_SIZE is ~0? Both your checks will pass
> for the case of (SIZE_MAX-PAGE_SIZE + 1) to ~0 cases.
Reverted.
^ permalink raw reply
* Re: Canot get serial card working: It worked ONCE.
From: mvw @ 2002-12-10 21:41 UTC (permalink / raw)
To: Linux-Hams
In-Reply-To: <E18Lpdw-0002aB-00@yagi.h-net.msu.edu>
Hi all,
I give up: your sugestions were all helpful but all checked out. Dead
port I still suspects, so I moved the effort to a difefrent machine.
Recompiled the kernel, install libax25/ax25-tools/ax25-apps, and added
/etc/ax25/axports and rc.ax25 with kissattach and routes: hey presto.
For those of you in the GTA, I will soon have this up as another gateway
for the Toronto area (Oakville, Ontario, near the lake).
One small question: in my logs I see that when I start mheardd, I get a
message as follows:
kernel: mheardd uses obsolete (PF_INET,SOCK_PACKET)
...is that anything to worry about?
Michael
^ permalink raw reply
* Re: how do you successful compile or install 2.5.50?
From: eric lin @ 2002-12-11 5:43 UTC (permalink / raw)
To: Holger Waechtler; +Cc: linux-kernel
In-Reply-To: <3DF5C40B.5060002@convergence.de>
Holger Waechtler wrote:
> eric lin wrote:
>
>> Dear Valdis:
>>
>> I also download from kernel.org 2.5.50, it have error at make
>> modules or make install
>
>
> Where exactly do you get the error? Please send post the last lines of
> your compile log to the appropriate mailing list.
>
> linux-dvb for DVB-related stuff and linux-kernel for the general stuff.
>
> Holger
>
>
>
gcc -Wp,-MD,drivers/char/.mxser.o.d -D__KERNEL__ -Iinclude -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686
-Iarch/i386/mach-generic -Iarch/i386/mach-defaults -nostdinc
-iwithprefix include -DMODULE -DKBUILD_BASENAME=mxser
-DKBUILD_MODNAME=mxser -c -o drivers/char/mxser.o drivers/char/mxser.c
drivers/char/mxser.c:378: redefinition of `__module_name'
drivers/char/mxser.c:332: `__module_name' previously defined here
make[2]: *** [drivers/char/mxser.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2
www:/home/fsshl/linux-2.5.50#
that is 2.5.50 with .50-ac1 patch
/* I do not know now where can get 2.5.50 since I got from kernel.org
the latest is 50 but now is 51 */
sincere Eric
www.linuxspice.com
linux pc for sale
^ permalink raw reply
* Re: Alteon AceNIC Coper Seen as Fibre ? (and incorrect settings)
From: Eric Weigle @ 2002-12-10 21:41 UTC (permalink / raw)
To: Stephan van Hienen; +Cc: sparclinux, linux-kernel
In-Reply-To: <Pine.LNX.4.50.0212102157440.1634-100000@ddx.a2000.nu>
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
> eth2: Alteon AceNIC Gigabit Ethernet at 0x1ff02900000, irq 6,7d0
...
> eth2: 10/100BaseT link UP
> eth2: Optical link DOWN
> eth2: 10/100BaseT link UP
>
> but this card is not an Fibre (Optical) card ?
This is a hold-over from the first revision of the cards, which were all
optical; the driver was written at that point.
(Remember, the hideous copper GigE hack came out after the fiber did).
Unless there's some actual failure, just ignore it.
-Eric
--
------------------------------------------------------------
Eric H. Weigle -- http://public.lanl.gov/ehw/
"They that can give up essential liberty to obtain a little
temporary safety deserve neither" -- Benjamin Franklin
------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: grayscale penguin?
From: James Simmons @ 2002-12-10 22:20 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux Frame Buffer Device Development
In-Reply-To: <Pine.GSO.4.21.0212101455170.13391-100000@vervain.sonytel.be>
> Should we add a penguin logo for greyscale displays as well?
>
> Simon Budig already created one a while ago (cfr.
> http://home.tvd.be/cr26864/Linux/fbdev/logo.html and
> http://www.home.unix-ag.org/simon/kernel-pingu/).
Hm. Do we need it? A few drivers fake greyscale by creating a grey scale
colormap. We should try it with the default image. If it doesn't work then
we can include it.
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* [ANNOUNCE] ltp-20021210 released.
From: Jeff Martin @ 2002-12-10 21:34 UTC (permalink / raw)
To: linux-kernel
The Linux Test Project test suite LTP-20021210.tgz has been released.
Visit our website (http://ltp.sourceforge.net) to download the latest
version of the testsuite, and for information on test results on
pre-releases, release candidates & stable releases of the kernel. There
is also a list of test cases that are expected to fail, please find
the list at (http://ltp.sourceforge.net/expected-errors.php)
The highlights of this release are:
- Many new test from Wipro.
- New SPIE tests ported. Special thanks to Gerrit Huizenga and Narasimha
Sharoff
for getting us the SPIE tests.
We encourage the community to post results, patches, or new tests on our
mailing list, and to use the CVS bug tracking facility to report problems
that you might encounter. More details available at our web-site.
Change Log
----------
- Added 5 new sched_setparam() tests ( Saji Kumar )
- Added new syslog() tests. ( David Barrera )
- Fix compile errors with *_module tests ( Paul Larson )
- Added additional semctl tests, semctl06 and ( David Barrera )
semctl07.
- Added additional msgctl tests. ( David Barrera )
- Added mkdir09. ( David Barrera )
- Added mem02. ( David Barrera )
- Added floating point tests, fptest01, fptest02, ( Jacky Malcles )
fptest03.
- Added inode01 and inode02 ( Robbie Williamson )
- Added vmtests, data_space and stack_space. ( Robbie Williamson )
- Added page tests, page01 and page02. ( Robbie Williamson )
- Added sysconf() test. ( Robbie Williamson )
- Added rename14 ( Robbie Williamson )
- Added nftw() tests. ( Robbie Williamson )
- Added confstr() test. ( Robbie Williamson )
- Added acct() tests. ( Robbie Williamson )
- Added flock03 to try relocking after unlocking. ( Paul Larson )
To reproduce bug #7 in osdl's bugzilla.
- Corrected a typo in ar01. A "=" was used, ( Robbie Williamson )
instead of an "==" found by Airong Zhang.
- Added 3 new sched_getparam tests ( Saji Kumar )
- Added query_module() tests ( T.L.Madhu )
- Added 2 new flock() tests ( Vatsal Avasthi )
- Added munlock() tests ( Nirmala Devi
Dhanasekar )
- Added umount() tests ( Nirmala Devi
Dhanasekar )
- Added mount tests ( Nirmala Devi
Dhanasekar )
- Added 2 new tests for sched_get_priority_min ( Saji Kumar )
- Added 2 new tests for sched_get_priority_max ( Saji Kumar )
- patch for sched_setscheduler01 to add ( Saji Kumar )
a test case for calling sched_setscheduler()
with an invalid priority
- Added mlockall() tests ( Nirmala Devi
Dhanasekar )
- Added delete_module tests ( T.L.Madhu )
- fix to readlink04.c. was creating a ( Robbie Williamson )
testfile called "testfile" in /, instead of the
temp dir created for the test.
- Added getdomainame test ( Saji Kumar )
- warning cleanup patches. removed additional ( Saji Kumar )
warnings created when -Wall option used.
also fixed Makefiles to correctly locate
the libraries and header files necessary for
compilation.
- Added 6 new clone() tests ( Saji Kumar )
- PPC fixes to ar, semctl04, and read02 ( Anton Blanchard )
- MULTIPLE cleanups and fixes ( Ihno Krumreich )
- Increased the default setting for MAXIDS number ( Robbie Williamson )
to 2048 in semget05.
- Test was running to /dev/tty3, which does not ( Robbie Williamson )
exist on some Linux installations. changed it
to /dev/tty for better general use.
- Added create_module tests ( T.L.Madhu )
- patch to cleanup warnings in syscall tests ( Saji Kumar )
- Corrected typo in rusers01 ( Robbie Williamson )
- Replaced sigset() with sigaction() in write04. ( Manoj Iyer )
-Jeff
Jeff Martin (ffej_AT_us.ibm.com)
Linux Test Project
IBM Linux Technology Center
http://ltp.sourceforge.net
^ permalink raw reply
* Fwd: Re: [LARTC] HTB with SFQ in leaf classes. & setup question
From: lartc @ 2002-12-10 21:27 UTC (permalink / raw)
To: lartc
Stef Coene <stef.coene@docum.org>:
> On Tuesday 10 December 2002 19:48, lartc@e-apollo.lv wrote:
> > Hello,
> >
> > I wrote something yesterday.
> > Now the situation is even worse. Communicatin with some clients wont work
> > at all until i restart the traffic shaping box.
> > (It works for some hours, then suddenly dies (meaning the client cant be
> > pinged. Suspected at peak hours)
> > Maybe the computer resources are weak, maybe its setup faulty
> Do you have any errors in dmesg? And how is the memory and cpu usage ?
Right now (night) the traffic shaping box is not loaded at all 10% cpu usage and 200MB ram
used.
Tho at the daytime cpu usage goes up to 70% or so. and ~ 500MB ram.
Yes there are errors.
Dec 10 22:59:28 p1 kernel: NET: 26 messages suppressed.
Dec 10 22:59:28 p1 kernel: HTB: bad diff in events, cl\x10243 diff\x19E26000 nowC4192384
thenB94893568 j\x1101578
...
Like this.
Just before i left work, i left a file d/ling, to test what happens.
Right now i cant reach outside world from that computer (128MB with speed of 128kbit/s have
downloaded and it has halted).
I can reach the computer from the computer where the traffic shaping is being done. But not
from a computer which is a hop from traffic shaping computer
internet - router1 - traffic_shaping - ... - me
80.81.33.1 is the router1 at the ISP providing us 8mbit like.
It cant be reached from the box which was being shaped.
me@myplace$ ping 80.81.33.1
PING 80.81.33.1 (80.81.33.1): 56 octets data
--- 80.81.33.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
Tho it can be reached from box next to me. (my other workstation)
me@myotherpc$ ping 80.81.33.1
PING 80.81.33.1 (80.81.33.1): 56 octets data
64 octets from 80.81.33.1: icmp_seq=0 ttl%2 timeb.6 ms
64 octets from 80.81.33.1: icmp_seq=1 ttl%2 time .8 ms
--- 80.81.33.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 20.8/41.7/62.6 ms
So there is a problem in the traffic shaping box.
Traceroute also stops at the traffic shaping box.
Huge problem.
Ok, just a second ago i did '/sbin/tc qdisc del dev eth2 root'
And added the classes again.
me@myplace$ ping 80.81.33.1
PING 80.81.33.1 (80.81.33.1): 56 octets data
64 octets from 80.81.33.1: icmp_seq=0 ttl%2 time$.6 ms
64 octets from 80.81.33.1: icmp_seq=1 ttl%2 time!.9 ms
--- 80.81.33.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 21.9/23.2/24.6 ms
I can reach ISP's gateway very smoothly now!
Any idee?
P.Krumins
____________________________________________________________
Reìistrç un lieto savu Apollo e-pastu www.e-apollo.lv
www.apollo.lv
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [LARTC] HTB and theory
From: Stef Coene @ 2002-12-10 21:23 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103945416224487@msgid-missing>
On Tuesday 10 December 2002 14:28, Abraham van der Merwe wrote:
> Hi Stef!
>
> > > How does this influence the shaping results and the shaping of other
> > > classes? I've actually asked a similar question before: If you have
> > >
> > > 1:1
> > > / \
> > > / \
> > > 1:2 1:3
> > > /|\ \------
> > > / | \ \ \
> > > 1:4 1:5 1:6 1:7 1:8
> > >
> > > if 1:7 and 1:8 respects the rate/ceil of 1:3 and 1:3 respects the
> > > rate/ceil of 1:1, but 1:4 does not respect the rate/ceil of 1:2 and 1:2
> > > respects the rate/ceil of 1:1, does the shaping of 1:3 work as normal
> > > and only those classes under 1:2 are adversely affected or not? from
> > > your previous answer, it seems that the classes under 1:3 would not be
> > > affected, but I would love to know why. what happens with 1:4 requests
> > > some bandwidth which 1:2 does not have...
> >
> > It's easier if you add some numbers of ceil/rate to understand the
> > question.
> >
> > I'm going to create an extra page on www.docum.org with your questions
> > and my answer to explain how rate and ceil of classes and parent classes
> > are used. Ok?
>
> That would be great, thanks
I wrote some more information about ceil and rate. You can find it on the faq
page on www.docum.org under "Basic rules for traffic shaping with HTB". If
you have more questions, let me know and I will try to answer them.
Remember, htb will work if you don't follow this rule. But it will be less
obviuos to figure out how the bandwidth will be distributed.
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
* hard drive head parking in linux
From: Jerry James Haumberger @ 2002-12-10 21:22 UTC (permalink / raw)
To: linux-newbie
>> is this already an automatic feature of the
>> later hard drives...
>Yes, AFAIK this is an automatic eature of all IDE drives.
Good. If I listen closely to this 486 DX2 system, I can
hear the gentle "plunk" sound as the IDE drive heads move
into or out of position. For example, I suspect that when I
hear this sound shortly after activating the screen (when it
has been blanked by the screen saver under BasicLinux) and do
something on the keyboard, the HD heads that were lifted off
from above the hard drive surface during the quiet period are
moving back closer into their normal active position -- just
scarcely above the hard disk surface.
>It's not a big issue (it will be a very rare bird that
>runs Linux on an old XT HD). If you want to protect the
>HD, just reset to DOS and run the park utility before
>powering down.
These older machines do just fine with DOS and the Internet
without the need for something more complex, like Linux. I
keep pretty close to software/hardware combinations that were
usual for the active period of each of my classic machines. The
Linux console-only installation on this 486 DX2 is altogether
"normal", in my opinion, right along with its dual relationship
alongside PC DOS 7. I don't think it would have been a peculiar
combination back in the early 1990's (this machine has a late
1991 BIOS). Around 1994, let's say, this would have been a
very powerful and expensive machine, but not unattainable for
those who could afford it, nor strange.
All in all, though, I believe that Linux is easier on and kinder
to old hardware; and for serious professional use of classic
machines, folks should consider using Linux to prolong the
productivity of such hardware -- and they should preferably
begin with the most basic of distributions, such as your
BasicLinux, with no less than the minimum hardware requirements
you've mentioned.
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: shared IP
From: pa3gcu @ 2002-12-10 21:21 UTC (permalink / raw)
To: EB3CZS Xavier Crehueras, linux-hams
In-Reply-To: <20021210220622.5b72434c.eb3czs@qsl.net>
On Tuesday 10 December 2002 21:06, EB3CZS Xavier Crehueras wrote:
> I read in the AX25-HOWTO that it is possible to have the same IP address in
> all the radio ports but routing must be carefully configured. I have a
> machine with 4 radio ports sharing an IP address. Has anyone tried
> something like this? Can anyone give me some advice to configure routing?
>
> Thank you
I never have used more than one IP on my machine, all interfaces ececpt one
have my 44.ampr.org address, one nic gets assigned via dhcp.
Examples for routing, that is not a wise thing to do without knowing what you
want, however lets say you have 2 different subnets on 2 different interfaces.
ax0 = 44.111.123.0
ax1 = 44.111.321.0
route add -net 44.111.123.0 netmask 255.255.255.0 ax0
route add -net 44.111.321.0 netmask 255.255.255.0 ax1
Take a look at my web site, there are some example there i am sure could help.
--
Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/
^ permalink raw reply
* Re: bash script problem
From: Chuck Gelm @ 2002-12-10 21:19 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <3DF61C86.51C4AD34@ihug.co.nz>
Check this bash script for me, please.
#/bin/sh
#
# if a floppy can be formatted 1.68 megabytes
# with 0 bad blocks
# else
# format 1.44 megabytes
# fi
# mkfs.msdos /dev/fd0
#
if (superformat /dev/fd0u1680 && badblocks -c 512 -n /dev/fd0u1680);
then
mkfs.msdos /dev/fd0u1680
else superformat /dev/fd0u1440
mkfs.msdos /dev/fd0u1440
fi
mdir
#
I'm thinking that 'badblocks' can find bad blocks and still return
a 'true' condition. If this is true, is there any way to cause
the smaller format?
If 'superformat /dev/fd0u1680' fails, it drops back to '/dev/fd0u1440'.
Regards, Chuck
-
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: [BK-2.4] [PATCH] Small do_mmap_pgoff correction
From: David S. Miller @ 2002-12-10 21:22 UTC (permalink / raw)
To: raul; +Cc: linux-kernel, marcelo
In-Reply-To: <20021210205906.GA82@DervishD>
From: DervishD <raul@pleyades.net>
Date: Tue, 10 Dec 2002 21:59:06 +0100
Because PAGE_ALIGN won't return 0?
What if TASK_SIZE is ~0? Both your checks will pass
for the case of (SIZE_MAX-PAGE_SIZE + 1) to ~0 cases.
^ permalink raw reply
* Re: Linux 2.5.51
From: James Simmons @ 2002-12-10 22:18 UTC (permalink / raw)
To: Petr Vandrovec; +Cc: linux-kernel, allan.d
In-Reply-To: <9EC19CF6B8E@vcnet.vc.cvut.cz>
> Hi James,
> I'm glad to see that fbdev changes finally arrived, so I can look at them
> without using your patches ;-) If you have some changes to matroxfb besides
> ones which are in the tree, please send me them... because of I really
> need matroxfb running on my machine, I'll make it top priority, just below
> my "real" work.
I have no additional patches for the matroxfb driver. I do have the
hardware but never got around to porting the driver.
^ permalink raw reply
* Re: [PATCH] make net/ipv4/route.c compile without CONFIG_PROC_FS
From: Arnaldo Carvalho de Melo @ 2002-12-10 21:21 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linux Kernel
In-Reply-To: <200212102208.31562.arnd@bergmann-dalldorf.de>
Em Tue, Dec 10, 2002 at 10:08:31PM +0100, Arnd Bergmann escreveu:
> The recent cleanup of /proc/net/rt_cache broke compiling
> without procfs, this makes it work again.
>
> ===== net/ipv4/route.c 1.31 vs edited =====
> --- 1.31/net/ipv4/route.c Sun Dec 8 03:45:58 2002
> +++ edited/net/ipv4/route.c Tue Dec 10 22:01:36 2002
> @@ -402,6 +402,11 @@
> {
> remove_proc_entry("rt_cache", proc_net);
> }
> +#else
> +
> +#define rt_cache_stat_get_info (get_info_t*)0
> +static inline int rt_cache_proc_init(void) { return 0; }
> +
> #endif /* CONFIG_PROC_FS */
>
> static __inline__ void rt_free(struct rtable *rt)
uups, sorry, but this will not be needed after I convert the rest
of net/ipv4/route.c to seq_file.
- Arnaldo
^ permalink raw reply
* Re: [LARTC] HTB with SFQ in leaf classes. & setup question
From: lartc @ 2002-12-10 21:09 UTC (permalink / raw)
To: lartc
Stef Coene <stef.coene@docum.org>:
> On Tuesday 10 December 2002 19:48, lartc@e-apollo.lv wrote:
> > Hello,
> >
> > I wrote something yesterday.
> > Now the situation is even worse. Communicatin with some clients wont work
> > at all until i restart the traffic shaping box.
> > (It works for some hours, then suddenly dies (meaning the client cant be
> > pinged. Suspected at peak hours)
> > Maybe the computer resources are weak, maybe its setup faulty
> Do you have any errors in dmesg? And how is the memory and cpu usage ?
Right now (night) the traffic shaping box is not loaded at all 10% cpu usage and 200MB ram
used.
Tho at the daytime cpu usage goes up to 70% or so. and ~ 500MB ram.
Yes there are errors.
Dec 10 22:59:28 p1 kernel: NET: 26 messages suppressed.
Dec 10 22:59:28 p1 kernel: HTB: bad diff in events, cl\x10243 diff\x19E26000 nowC4192384
thenB94893568 j\x1101578
...
Like this.
Just before i left work, i left a file d/ling, to test what happens.
Right now i cant reach outside world from that computer (128MB with speed of 128kbit/s have
downloaded and it has halted).
I can reach the computer from the computer where the traffic shaping is being done. But not
from a computer which is a hop from traffic shaping computer
internet - router1 - traffic_shaping - ... - me
80.81.33.1 is the router1 at the ISP providing us 8mbit like.
It cant be reached from the box which was being shaped.
me@myplace$ ping 80.81.33.1
PING 80.81.33.1 (80.81.33.1): 56 octets data
--- 80.81.33.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
Tho it can be reached from box next to me. (my other workstation)
me@myotherpc$ ping 80.81.33.1
PING 80.81.33.1 (80.81.33.1): 56 octets data
64 octets from 80.81.33.1: icmp_seq=0 ttl%2 timeb.6 ms
64 octets from 80.81.33.1: icmp_seq=1 ttl%2 time .8 ms
--- 80.81.33.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 20.8/41.7/62.6 ms
So there is a problem in the traffic shaping box.
Traceroute also stops at the traffic shaping box.
Huge problem.
Ok, just a second ago i did '/sbin/tc qdisc del dev eth2 root'
And added the classes again.
me@myplace$ ping 80.81.33.1
PING 80.81.33.1 (80.81.33.1): 56 octets data
64 octets from 80.81.33.1: icmp_seq=0 ttl%2 time$.6 ms
64 octets from 80.81.33.1: icmp_seq=1 ttl%2 time!.9 ms
--- 80.81.33.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 21.9/23.2/24.6 ms
I can reach ISP's gateway very smoothly now!
Any idee?
P.Krumins
____________________________________________________________
Reìistrç un lieto savu Apollo e-pastu www.e-apollo.lv
www.apollo.lv
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Is this going to be true ?
From: Serge Kuznetsov @ 2002-12-10 21:16 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.50.0212102157440.1634-100000@ddx.a2000.nu>
I am just curious if someone has an opinion for the
following link?
Research Firm: Microsoft Will Use Linux by 2004:
http://story.news.yahoo.com/news?tmpl=story2&ncid=&e=5&u=/nf/20021210/tc_nf/20210
All the Best!
Serge.
^ permalink raw reply
* Re: Patch for ide-tape driver
From: Alan Stern @ 2002-12-10 21:15 UTC (permalink / raw)
To: Alan Cox, Marcelo Tosatti; +Cc: Linux Kernel Mailing List
In-Reply-To: <1039480634.12046.11.camel@irongate.swansea.linux.org.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1128 bytes --]
On 10 Dec 2002, Alan Cox wrote:
> On Mon, 2002-12-09 at 20:03, Alan Stern wrote:
> > Attached are patch files for both 2.4.20 and 2.5.50. Please apply them
> > when you have a chance.
>
> 2.4.21pre1 has updated IDE core code so it probably wants a bit of a
> resync before it can go in. The 2.5.50 one is matching the 2.4.21pre1
> IDE core so it shouldnt be too bad.
All right. I cloned Marcelo's 2.4 tree from bkbits.net this morning, and
sure enough, there are numerous changes with respect to the distribution
version of 2.4.20. I have updated my patch for the ide-tape driver
accordingly and attached it. Please don't tell me that yet more changes
have been made in the meantime -- it's very difficult to hit a moving
target! :-)
So far as I am aware, there have not been any changes to the 2.5.50
version of the driver, so the patch file I submitted earlier should still
apply.
Alan Stern
P.S.: It is a considerable nuisance having to clone an entire kernel tree
just to get the current version of one file. Can anyone tell me if there
is a quicker, less bandwidth-intensive way of accomplishing the same
thing?
[-- Attachment #2: Patch for 2.4.21 version of ide-tape.c --]
[-- Type: TEXT/PLAIN, Size: 24604 bytes --]
--- linux/drivers/ide/ide-tape.c.orig Tue Dec 10 11:15:30 2002
+++ linux/drivers/ide/ide-tape.c Tue Dec 10 15:37:51 2002
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/ide-tape.c Version 1.17a Jan, 2001
+ * linux/drivers/ide/ide-tape.c Version 1.17b Dec, 2002
*
* Copyright (C) 1995 - 1999 Gadi Oxman <gadio@netvision.net.il>
*
@@ -291,6 +291,28 @@
* Ver 1.17a Apr 2001 Willem Riede osst@riede.org
* - Get drive's actual block size from mode sense block descriptor
* - Limit size of pipeline
+ * Ver 1.17b Dec 2002 Alan Stern <stern@rowland.harvard.edu>
+ * Changed IDETAPE_MIN_PIPELINE_STAGES to 1 and actually used
+ * it in the code!
+ * Actually removed aborted stages in idetape_abort_pipeline
+ * instead of just changing the command code.
+ * Made the transfer byte count for Request Sense equal to the
+ * actual length of the data transfer.
+ * Changed handling of partial data transfers: they do not
+ * cause DMA errors.
+ * Moved initiation of DMA transfers to the correct place.
+ * Removed reference to unallocated memory.
+ * Made __idetape_discard_read_pipeline return the number of
+ * sectors skipped, not the number of stages.
+ * Replaced errant kfree() calls with __idetape_kfree_stage().
+ * Fixed off-by-one error in testing the pipeline length.
+ * Fixed handling of filemarks in the read pipeline.
+ * Small code optimization for MTBSF and MTBSFM ioctls.
+ * Don't try to unlock the door during device close if is
+ * already unlocked!
+ * Cosmetic fixes to miscellaneous debugging output messages.
+ * Set the minimum /proc/ide/hd?/settings values for "pipeline",
+ * "pipeline_min", and "pipeline_max" to 1.
*
* Here are some words from the first releases of hd.c, which are quoted
* in ide.c and apply here as well:
@@ -400,7 +422,7 @@
* sharing a (fast) ATA-2 disk with any (slow) new ATAPI device.
*/
-#define IDETAPE_VERSION "1.17a"
+#define IDETAPE_VERSION "1.17b"
#include <linux/config.h>
#include <linux/module.h>
@@ -576,9 +598,10 @@
* whenever we sense that the pipeline is empty, until we reach
* the optimum value or until we reach MAX.
*
- * Setting the following parameter to 0 will disable the pipelined mode.
+ * Setting the following parameter to 0 is illegal: the pipelined mode
+ * cannot be disabled (calculate_speeds() divides by tape->max_stages.)
*/
-#define IDETAPE_MIN_PIPELINE_STAGES 200
+#define IDETAPE_MIN_PIPELINE_STAGES 1
#define IDETAPE_MAX_PIPELINE_STAGES 400
#define IDETAPE_INCREASE_STAGES_RATE 20
@@ -600,8 +623,8 @@
* is verified to be stable enough. This will make it much more
* esthetic.
*/
-#define IDETAPE_DEBUG_INFO 1
-#define IDETAPE_DEBUG_LOG 1
+#define IDETAPE_DEBUG_INFO 0
+#define IDETAPE_DEBUG_LOG 0
#define IDETAPE_DEBUG_LOG_VERBOSE 0
#define IDETAPE_DEBUG_BUGS 1
@@ -1699,25 +1722,6 @@
}
}
-static void idetape_abort_pipeline (ide_drive_t *drive)
-{
- idetape_tape_t *tape = drive->driver_data;
- idetape_stage_t *stage = tape->next_stage;
-
-#if IDETAPE_DEBUG_LOG
- if (tape->debug_level >= 4)
- printk(KERN_INFO "ide-tape: %s: %s called\n",
- tape->name, __FUNCTION__);
-#endif
- while (stage) {
- if (stage->rq.cmd == IDETAPE_WRITE_RQ)
- stage->rq.cmd = IDETAPE_ABORTED_WRITE_RQ;
- else if (stage->rq.cmd == IDETAPE_READ_RQ)
- stage->rq.cmd = IDETAPE_ABORTED_READ_RQ;
- stage = stage->next;
- }
-}
-
/*
* idetape_active_next_stage will declare the next stage as "active".
*/
@@ -1763,7 +1767,7 @@
printk (KERN_INFO "ide-tape: Reached %s\n", __FUNCTION__);
#endif /* IDETAPE_DEBUG_LOG */
- tape->max_stages += increase;
+ tape->max_stages += IDE_MAX(increase, 1);
tape->max_stages = IDE_MAX(tape->max_stages, tape->min_pipeline);
tape->max_stages = IDE_MIN(tape->max_stages, tape->max_pipeline);
}
@@ -1839,6 +1843,30 @@
}
}
+static void idetape_abort_pipeline (ide_drive_t *drive, idetape_stage_t *last_stage)
+{
+ idetape_tape_t *tape = drive->driver_data;
+ idetape_stage_t *stage = tape->next_stage;
+ idetape_stage_t *nstage;
+
+#if IDETAPE_DEBUG_LOG
+ if (tape->debug_level >= 4)
+ printk(KERN_INFO "ide-tape: %s: %s called\n",
+ tape->name, __FUNCTION__);
+#endif
+ while (stage) {
+ nstage = stage->next;
+ idetape_kfree_stage(tape, stage);
+ --tape->nr_stages;
+ --tape->nr_pending_stages;
+ stage = nstage;
+ }
+ tape->last_stage = last_stage;
+ if (last_stage)
+ last_stage->next = NULL;
+ tape->next_stage = NULL;
+}
+
/*
* idetape_end_request is used to finish servicing a request, and to
* insert a pending pipeline request into the main device queue.
@@ -1850,6 +1878,7 @@
unsigned long flags;
int error;
int remove_stage = 0;
+ idetape_stage_t *active_stage;
#if ONSTREAM_DEBUG
idetape_stage_t *stage;
os_aux_t *aux;
@@ -1873,6 +1902,7 @@
spin_lock_irqsave(&tape->spinlock, flags);
if (tape->active_data_request == rq) {
/* The request was a pipelined data transfer request */
+ active_stage = tape->active_stage;
tape->active_stage = NULL;
tape->active_data_request = NULL;
tape->nr_pending_stages--;
@@ -1892,18 +1922,20 @@
if (tape->first_frame_position == OS_DATA_ENDFRAME1) {
#if ONSTREAM_DEBUG
if (tape->debug_level >= 2)
- printk("ide-tape: %s: skipping over config parition..\n", tape->name);
+ printk("ide-tape: %s: skipping over config partition.\n", tape->name);
#endif
tape->onstream_write_error = OS_PART_ERROR;
- if (tape->waiting)
+ if (tape->waiting) {
+ rq->waiting = NULL;
complete(tape->waiting);
+ }
}
}
remove_stage = 1;
if (error) {
set_bit(IDETAPE_PIPELINE_ERROR, &tape->flags);
if (error == IDETAPE_ERROR_EOD)
- idetape_abort_pipeline(drive);
+ idetape_abort_pipeline(drive, active_stage);
if (tape->onstream && !tape->raw &&
error == IDETAPE_ERROR_GENERAL &&
tape->sense.sense_key == 3) {
@@ -1914,14 +1946,16 @@
tape->nr_pending_stages++;
tape->next_stage = tape->first_stage;
rq->current_nr_sectors = rq->nr_sectors;
- if (tape->waiting)
+ if (tape->waiting) {
+ rq->waiting = NULL;
complete(tape->waiting);
+ }
}
}
} else if (rq->cmd == IDETAPE_READ_RQ) {
if (error == IDETAPE_ERROR_EOD) {
set_bit(IDETAPE_PIPELINE_ERROR, &tape->flags);
- idetape_abort_pipeline(drive);
+ idetape_abort_pipeline(drive, active_stage);
}
}
if (tape->next_stage != NULL && !tape->onstream_write_error) {
@@ -1969,7 +2003,7 @@
idetape_init_pc(pc);
pc->c[0] = IDETAPE_REQUEST_SENSE_CMD;
pc->c[4] = 20;
- pc->request_transfer = 18;
+ pc->request_transfer = 20;
pc->callback = &idetape_request_sense_callback;
}
@@ -2071,7 +2105,7 @@
#ifdef CONFIG_BLK_DEV_IDEDMA
if (test_bit(PC_DMA_IN_PROGRESS, &pc->flags)) {
- if (HWIF(drive)->ide_dma_end(drive)) {
+ if (HWIF(drive)->ide_dma_end(drive) || status.b.check) {
/*
* A DMA error is sometimes expected. For example,
* if the tape is crossing a filemark during a
@@ -2083,8 +2117,18 @@
* actually transferred (we can't receive that
* information from the DMA engine on most chipsets).
*/
+
+ /*
+ * On the contrary, a DMA error is never expected;
+ * it usually indicates a hardware error or abort.
+ * If the tape crosses a filemark during a READ
+ * command, it will issue an irq and position itself
+ * after the filemark (not before). Only a partial
+ * data transfer will occur, but no DMA error.
+ * (AS, 19 Apr 2001)
+ */
set_bit (PC_DMA_ERROR, &pc->flags);
- } else if (!status.b.check) {
+ } else {
pc->actually_transferred = pc->request_transfer;
idetape_update_buffers (pc);
}
@@ -2123,7 +2167,7 @@
/* Error detected */
#if IDETAPE_DEBUG_LOG
if (tape->debug_level >= 1)
- printk(KERN_INFO "ide-tape: %s: I/O error, ",
+ printk(KERN_INFO "ide-tape: %s: I/O error\n",
tape->name);
#endif /* IDETAPE_DEBUG_LOG */
if (pc->c[0] == IDETAPE_REQUEST_SENSE_CMD) {
@@ -2314,6 +2358,11 @@
BUG();
/* Set the interrupt routine */
ide_set_handler(drive, &idetape_pc_intr, IDETAPE_WAIT_CMD, NULL);
+#ifdef CONFIG_BLK_DEV_IDEDMA
+ /* Begin DMA, if necessary */
+ if (test_bit(PC_DMA_IN_PROGRESS, &pc->flags))
+ (void) (HWIF(drive)->ide_dma_begin(drive));
+#endif
/* Send the actual packet */
HWIF(drive)->atapi_output_bytes(drive, pc->c, 12);
return ide_started;
@@ -2343,8 +2392,7 @@
/*
* We will "abort" retrying a packet command in case
* a legitimate error code was received (crossing a
- * filemark, or DMA error in the end of media, for
- * example).
+ * filemark, or end of the media, for example).
*/
if (!test_bit (PC_ABORT, &pc->flags)) {
if (!(pc->c[0] == IDETAPE_TEST_UNIT_READY_CMD &&
@@ -2371,7 +2419,8 @@
}
#if IDETAPE_DEBUG_LOG
if (tape->debug_level >= 2)
- printk(KERN_INFO "ide-tape: Retry number - %d\n", pc->retries);
+ printk(KERN_INFO "ide-tape: Retry number - %d, cmd = %02X\n",
+ pc->retries, pc->c[0]);
#endif /* IDETAPE_DEBUG_LOG */
pc->retries++;
@@ -2404,10 +2453,8 @@
HWIF(drive)->OUTB(bcount.b.low, IDE_BCOUNTL_REG);
HWIF(drive)->OUTB(drive->select.all, IDE_SELECT_REG);
#ifdef CONFIG_BLK_DEV_IDEDMA
- if (feature.b.dma) { /* Begin DMA, if necessary */
+ if (feature.b.dma) /* Will begin DMA later */
set_bit(PC_DMA_IN_PROGRESS, &pc->flags);
- (void) (HWIF(drive)->ide_dma_begin(drive));
- }
#endif /* CONFIG_BLK_DEV_IDEDMA */
if (test_bit(IDETAPE_DRQ_INTERRUPT, &tape->flags)) {
if (HWGROUP(drive)->handler != NULL)
@@ -3238,7 +3285,7 @@
tape->waiting = &wait;
spin_unlock(&tape->spinlock);
wait_for_completion(&wait);
- rq->waiting = NULL;
+ /* The stage and its struct request have been deallocated */
tape->waiting = NULL;
spin_lock_irq(&tape->spinlock);
}
@@ -3510,11 +3557,15 @@
if (tape->chrdev_direction != idetape_direction_read)
return 0;
+ cnt = tape->merge_stage_size / tape->tape_block_size;
+ if (test_and_clear_bit(IDETAPE_FILEMARK, &tape->flags))
+ ++cnt; /* Filemarks count as 1 sector */
tape->merge_stage_size = 0;
if (tape->merge_stage != NULL) {
__idetape_kfree_stage(tape->merge_stage);
tape->merge_stage = NULL;
}
+ clear_bit(IDETAPE_PIPELINE_ERROR, &tape->flags);
tape->chrdev_direction = idetape_direction_none;
if (tape->first_stage == NULL)
@@ -3526,9 +3577,14 @@
idetape_wait_for_request(drive, tape->active_data_request);
spin_unlock_irqrestore(&tape->spinlock, flags);
- cnt = tape->nr_stages - tape->nr_pending_stages;
- while (tape->first_stage != NULL)
+ while (tape->first_stage != NULL) {
+ struct request *rq_ptr = &tape->first_stage->rq;
+
+ cnt += rq_ptr->nr_sectors - rq_ptr->current_nr_sectors;
+ if (rq_ptr->errors == IDETAPE_ERROR_FILEMARK)
+ ++cnt;
idetape_remove_stage_head(drive);
+ }
tape->nr_pending_stages = 0;
tape->max_stages = tape->min_pipeline;
return cnt;
@@ -4151,7 +4207,7 @@
*/
bytes_read = idetape_queue_rw_tail(drive, IDETAPE_READ_RQ, 0, tape->merge_stage->bh);
if (bytes_read < 0) {
- kfree(tape->merge_stage);
+ __idetape_kfree_stage(tape->merge_stage);
tape->merge_stage = NULL;
tape->chrdev_direction = idetape_direction_none;
return bytes_read;
@@ -4164,7 +4220,7 @@
rq.sector = tape->first_frame_position;
rq.nr_sectors = rq.current_nr_sectors = blocks;
if (!test_bit(IDETAPE_PIPELINE_ERROR, &tape->flags) &&
- tape->nr_stages <= max_stages) {
+ tape->nr_stages < max_stages) {
new_stage = idetape_kmalloc_stage(tape);
while (new_stage != NULL) {
new_stage->rq = rq;
@@ -4287,6 +4343,12 @@
#endif /* IDETAPE_DEBUG_LOG */
/*
+ * If we are at a filemark, return a read length of 0
+ */
+ if (test_bit(IDETAPE_FILEMARK, &tape->flags))
+ return 0;
+
+ /*
* Wait for the next logical block to be available at the head
* of the pipeline
*/
@@ -4315,14 +4377,7 @@
}
if (rq_ptr->errors == IDETAPE_ERROR_EOD)
return 0;
- if (rq_ptr->errors == IDETAPE_ERROR_FILEMARK) {
- idetape_switch_buffers (tape, tape->first_stage);
- set_bit(IDETAPE_FILEMARK, &tape->flags);
-#if USE_IOTRACE
- IO_trace(IO_IDETAPE_FIFO, tape->pipeline_head, tape->buffer_head, tape->tape_head, tape->minor);
-#endif
- calculate_speeds(drive);
- } else {
+ else {
idetape_switch_buffers(tape, tape->first_stage);
if (rq_ptr->errors == IDETAPE_ERROR_GENERAL) {
#if ONSTREAM_DEBUG
@@ -4331,7 +4386,8 @@
"bytes_read %d\n", bytes_read);
#endif
}
- clear_bit(IDETAPE_FILEMARK, &tape->flags);
+ if (rq_ptr->errors == IDETAPE_ERROR_FILEMARK)
+ set_bit(IDETAPE_FILEMARK, &tape->flags);
spin_lock_irqsave(&tape->spinlock, flags);
idetape_remove_stage_head (drive);
spin_unlock_irqrestore(&tape->spinlock, flags);
@@ -4714,6 +4770,14 @@
tape->restart_speed_control_req = 1;
return retval;
}
+
+ if (mt_count == 0)
+ return 0;
+ if (MTBSF == mt_op || MTBSFM == mt_op) {
+ if (!tape->capabilities.sprev)
+ return -EIO;
+ mt_count = - mt_count;
+ }
if (tape->chrdev_direction == idetape_direction_read) {
/*
@@ -4721,28 +4785,36 @@
* filemarks.
*/
tape->merge_stage_size = 0;
- clear_bit(IDETAPE_FILEMARK, &tape->flags);
+ if (test_and_clear_bit(IDETAPE_FILEMARK, &tape->flags))
+ ++count;
while (tape->first_stage != NULL) {
- idetape_wait_first_stage(drive);
- if (tape->first_stage->rq.errors == IDETAPE_ERROR_FILEMARK)
- count++;
if (count == mt_count) {
- switch (mt_op) {
- case MTFSF:
- spin_lock_irqsave(&tape->spinlock, flags);
- idetape_remove_stage_head(drive);
- spin_unlock_irqrestore(&tape->spinlock, flags);
- case MTFSFM:
- return (0);
- default:
- break;
- }
+ if (mt_op == MTFSFM)
+ set_bit(IDETAPE_FILEMARK, &tape->flags);
+ return 0;
}
spin_lock_irqsave(&tape->spinlock, flags);
+ if (tape->first_stage == tape->active_stage) {
+ /*
+ * We have reached the active stage in the read pipeline.
+ * There is no point in allowing the drive to continue
+ * reading any farther, so we stop the pipeline.
+ *
+ * This section should be moved to a separate subroutine,
+ * because a similar function is performed in
+ * __idetape_discard_read_pipeline(), for example.
+ */
+ tape->next_stage = NULL;
+ spin_unlock_irqrestore(&tape->spinlock, flags);
+ idetape_wait_first_stage(drive);
+ tape->next_stage = tape->first_stage->next;
+ } else
+ spin_unlock_irqrestore(&tape->spinlock, flags);
+ if (tape->first_stage->rq.errors == IDETAPE_ERROR_FILEMARK)
+ ++count;
idetape_remove_stage_head(drive);
- spin_unlock_irqrestore(&tape->spinlock, flags);
}
- idetape_discard_read_pipeline(drive, 1);
+ idetape_discard_read_pipeline(drive, 0);
}
/*
@@ -4751,25 +4823,17 @@
*/
switch (mt_op) {
case MTFSF:
+ case MTBSF:
idetape_create_space_cmd(&pc,mt_count-count,IDETAPE_SPACE_OVER_FILEMARK);
return (idetape_queue_pc_tail(drive, &pc));
case MTFSFM:
- if (!tape->capabilities.sprev)
- return (-EIO);
- retval = idetape_space_over_filemarks(drive, MTFSF, mt_count-count);
- if (retval) return (retval);
- return (idetape_space_over_filemarks(drive, MTBSF, 1));
- case MTBSF:
- if (!tape->capabilities.sprev)
- return (-EIO);
- idetape_create_space_cmd(&pc,-(mt_count+count),IDETAPE_SPACE_OVER_FILEMARK);
- return (idetape_queue_pc_tail(drive, &pc));
case MTBSFM:
if (!tape->capabilities.sprev)
return (-EIO);
- retval = idetape_space_over_filemarks(drive, MTBSF, mt_count+count);
+ retval = idetape_space_over_filemarks(drive, MTFSF, mt_count-count);
if (retval) return (retval);
- return (idetape_space_over_filemarks(drive, MTFSF, 1));
+ count = (MTBSFM == mt_op ? 1 : -1);
+ return (idetape_space_over_filemarks(drive, MTFSF, count));
default:
printk(KERN_ERR "ide-tape: MTIO operation %d not "
"supported\n", mt_op);
@@ -5117,7 +5181,7 @@
*/
retval = idetape_queue_rw_tail(drive, IDETAPE_WRITE_RQ, 0, tape->merge_stage->bh);
if (retval < 0) {
- kfree(tape->merge_stage);
+ __idetape_kfree_stage(tape->merge_stage);
tape->merge_stage = NULL;
tape->chrdev_direction = idetape_direction_none;
return retval;
@@ -5701,9 +5765,11 @@
MOD_DEC_USE_COUNT;
return -EBUSY;
}
- idetape_read_position(drive);
+ if (tape->onstream)
+ idetape_read_position(drive);
MOD_DEC_USE_COUNT;
- clear_bit(IDETAPE_PIPELINE_ERROR, &tape->flags);
+ if (tape->chrdev_direction != idetape_direction_read)
+ clear_bit(IDETAPE_PIPELINE_ERROR, &tape->flags);
if (tape->chrdev_direction == idetape_direction_none) {
MOD_INC_USE_COUNT;
@@ -5776,10 +5842,11 @@
if (minor < 128)
(void) idetape_rewind_tape(drive);
if (tape->chrdev_direction == idetape_direction_none) {
- if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) {
- if (idetape_create_prevent_cmd(drive, &pc, 0))
+ if (tape->door_locked == DOOR_LOCKED) {
+ if (idetape_create_prevent_cmd(drive, &pc, 0)) {
if (!idetape_queue_pc_tail(drive, &pc))
tape->door_locked = DOOR_UNLOCKED;
+ }
}
MOD_DEC_USE_COUNT;
}
@@ -5813,34 +5880,34 @@
printk(KERN_INFO "ide-tape: Dumping ATAPI Identify Device tape parameters\n");
printk(KERN_INFO "ide-tape: Protocol Type: ");
switch (gcw.protocol) {
- case 0: case 1: printk(KERN_INFO "ATA\n");break;
- case 2: printk(KERN_INFO "ATAPI\n");break;
- case 3: printk(KERN_INFO "Reserved (Unknown to ide-tape)\n");break;
+ case 0: case 1: printk("ATA\n");break;
+ case 2: printk("ATAPI\n");break;
+ case 3: printk("Reserved (Unknown to ide-tape)\n");break;
}
printk(KERN_INFO "ide-tape: Device Type: %x - ",gcw.device_type);
switch (gcw.device_type) {
- case 0: printk(KERN_INFO "Direct-access Device\n");break;
- case 1: printk(KERN_INFO "Streaming Tape Device\n");break;
- case 2: case 3: case 4: printk(KERN_INFO "Reserved\n");break;
- case 5: printk(KERN_INFO "CD-ROM Device\n");break;
- case 6: printk(KERN_INFO "Reserved\n");
- case 7: printk(KERN_INFO "Optical memory Device\n");break;
- case 0x1f: printk(KERN_INFO "Unknown or no Device type\n");break;
- default: printk(KERN_INFO "Reserved\n");
+ case 0: printk("Direct-access Device\n");break;
+ case 1: printk("Streaming Tape Device\n");break;
+ case 2: case 3: case 4: printk("Reserved\n");break;
+ case 5: printk("CD-ROM Device\n");break;
+ case 6: printk("Reserved\n");
+ case 7: printk("Optical memory Device\n");break;
+ case 0x1f: printk("Unknown or no Device type\n");break;
+ default: printk("Reserved\n");
}
printk(KERN_INFO "ide-tape: Removable: %s",gcw.removable ? "Yes\n":"No\n");
printk(KERN_INFO "ide-tape: Command Packet DRQ Type: ");
switch (gcw.drq_type) {
- case 0: printk(KERN_INFO "Microprocessor DRQ\n");break;
- case 1: printk(KERN_INFO "Interrupt DRQ\n");break;
- case 2: printk(KERN_INFO "Accelerated DRQ\n");break;
- case 3: printk(KERN_INFO "Reserved\n");break;
+ case 0: printk("Microprocessor DRQ\n");break;
+ case 1: printk("Interrupt DRQ\n");break;
+ case 2: printk("Accelerated DRQ\n");break;
+ case 3: printk("Reserved\n");break;
}
printk(KERN_INFO "ide-tape: Command Packet Size: ");
switch (gcw.packet_size) {
- case 0: printk(KERN_INFO "12 bytes\n");break;
- case 1: printk(KERN_INFO "16 bytes\n");break;
- default: printk(KERN_INFO "Reserved\n");break;
+ case 0: printk("12 bytes\n");break;
+ case 1: printk("16 bytes\n");break;
+ default: printk("Reserved\n");break;
}
printk(KERN_INFO "ide-tape: Model: %.40s\n",id->model);
printk(KERN_INFO "ide-tape: Firmware Revision: %.8s\n",id->fw_rev);
@@ -5856,44 +5923,44 @@
printk(KERN_INFO "ide-tape: Single Word DMA supported modes: ");
for (i=0,mask=1;i<8;i++,mask=mask << 1) {
if (id->dma_1word & mask)
- printk(KERN_INFO "%d ",i);
+ printk("%d ",i);
if (id->dma_1word & (mask << 8))
- printk(KERN_INFO "(active) ");
+ printk("(active) ");
}
- printk(KERN_INFO "\n");
+ printk("\n");
printk(KERN_INFO "ide-tape: Multi Word DMA supported modes: ");
for (i=0,mask=1;i<8;i++,mask=mask << 1) {
if (id->dma_mword & mask)
- printk(KERN_INFO "%d ",i);
+ printk("%d ",i);
if (id->dma_mword & (mask << 8))
- printk(KERN_INFO "(active) ");
+ printk("(active) ");
}
- printk(KERN_INFO "\n");
+ printk("\n");
if (id->field_valid & 0x0002) {
printk(KERN_INFO "ide-tape: Enhanced PIO Modes: %s\n",id->eide_pio_modes & 1 ? "Mode 3":"None");
printk(KERN_INFO "ide-tape: Minimum Multi-word DMA cycle per word: ");
if (id->eide_dma_min == 0)
- printk(KERN_INFO "Not supported\n");
+ printk("Not supported\n");
else
- printk(KERN_INFO "%d ns\n",id->eide_dma_min);
+ printk("%d ns\n",id->eide_dma_min);
printk(KERN_INFO "ide-tape: Manufacturer\'s Recommended Multi-word cycle: ");
if (id->eide_dma_time == 0)
- printk(KERN_INFO "Not supported\n");
+ printk("Not supported\n");
else
- printk(KERN_INFO "%d ns\n",id->eide_dma_time);
+ printk("%d ns\n",id->eide_dma_time);
printk(KERN_INFO "ide-tape: Minimum PIO cycle without IORDY: ");
if (id->eide_pio == 0)
- printk(KERN_INFO "Not supported\n");
+ printk("Not supported\n");
else
- printk(KERN_INFO "%d ns\n",id->eide_pio);
+ printk("%d ns\n",id->eide_pio);
printk(KERN_INFO "ide-tape: Minimum PIO cycle with IORDY: ");
if (id->eide_pio_iordy == 0)
- printk(KERN_INFO "Not supported\n");
+ printk("Not supported\n");
else
- printk(KERN_INFO "%d ns\n",id->eide_pio_iordy);
+ printk("%d ns\n",id->eide_pio_iordy);
} else
printk(KERN_INFO "ide-tape: According to the device, fields 64-70 are not valid.\n");
@@ -6205,9 +6272,9 @@
* drive setting name read/write ioctl ioctl data type min max mul_factor div_factor data pointer set function
*/
ide_add_setting(drive, "buffer", SETTING_READ, -1, -1, TYPE_SHORT, 0, 0xffff, 1, 2, &tape->capabilities.buffer_size, NULL);
- ide_add_setting(drive, "pipeline_min", SETTING_RW, -1, -1, TYPE_INT, 2, 0xffff, tape->stage_size / 1024, 1, &tape->min_pipeline, NULL);
- ide_add_setting(drive, "pipeline", SETTING_RW, -1, -1, TYPE_INT, 2, 0xffff, tape->stage_size / 1024, 1, &tape->max_stages, NULL);
- ide_add_setting(drive, "pipeline_max", SETTING_RW, -1, -1, TYPE_INT, 2, 0xffff, tape->stage_size / 1024, 1, &tape->max_pipeline, NULL);
+ ide_add_setting(drive, "pipeline_min", SETTING_RW, -1, -1, TYPE_INT, 1, 0xffff, tape->stage_size / 1024, 1, &tape->min_pipeline, NULL);
+ ide_add_setting(drive, "pipeline", SETTING_RW, -1, -1, TYPE_INT, 1, 0xffff, tape->stage_size / 1024, 1, &tape->max_stages, NULL);
+ ide_add_setting(drive, "pipeline_max", SETTING_RW, -1, -1, TYPE_INT, 1, 0xffff, tape->stage_size / 1024, 1, &tape->max_pipeline, NULL);
ide_add_setting(drive, "pipeline_used",SETTING_READ, -1, -1, TYPE_INT, 0, 0xffff, tape->stage_size / 1024, 1, &tape->nr_stages, NULL);
ide_add_setting(drive, "pipeline_pending",SETTING_READ,-1, -1, TYPE_INT, 0, 0xffff, tape->stage_size / 1024, 1, &tape->nr_pending_stages, NULL);
ide_add_setting(drive, "speed", SETTING_READ, -1, -1, TYPE_SHORT, 0, 0xffff, 1, 1, &tape->capabilities.speed, NULL);
@@ -6317,8 +6384,11 @@
si_meminfo(&si);
if (tape->max_stages * tape->stage_size > si.totalram * si.mem_unit / 10)
tape->max_stages = si.totalram * si.mem_unit / (10 * tape->stage_size);
- tape->min_pipeline = tape->max_stages;
- tape->max_pipeline = tape->max_stages * 2;
+ tape->max_stages = IDE_MIN(tape->max_stages, IDETAPE_MAX_PIPELINE_STAGES);
+ tape->min_pipeline = IDE_MIN(tape->max_stages, IDETAPE_MIN_PIPELINE_STAGES);
+ tape->max_pipeline = IDE_MIN(tape->max_stages * 2, IDETAPE_MAX_PIPELINE_STAGES);
+ if (tape->max_stages == 0)
+ tape->max_stages = tape->min_pipeline = tape->max_pipeline = 1;
t1 = (tape->stage_size * HZ) / (speed * 1000);
tmid = (tape->capabilities.buffer_size * 32 * HZ) / (speed * 125);
^ permalink raw reply
* RE: (no subject)
From: vivens @ 2002-12-10 21:05 UTC (permalink / raw)
To: 'James Simmons'; +Cc: linux-fbdev-devel
In-Reply-To: <Pine.LNX.4.33.0212101031010.2617-100000@maxwell.earthlink.net>
Well, I mend it like this:
I'm trying to build a framebuffer for an embedded ARM platform (which
doesn't use any kind of a Lunix distr).
I want to use a framebuffer, because some apps need it. For example the
ZEN browser I want to implement on this platform.
So my question is:
What basic functions does a framebuffer normally have, what is need to
initialize for these functions?
Can I see the framebuffer as the API between the video hardware and any
application what uses the video hardware?
Whit kind regards,
Vincent Ivens
-----Original Message-----
From: linux-fbdev-devel-admin@lists.sourceforge.net
[mailto:linux-fbdev-devel-admin@lists.sourceforge.net] On Behalf Of
James Simmons
Sent: dinsdag 10 december 2002 19:32
To: Vincent Ivens
Cc: linux-fbdev-devel@lists.sourceforge.net
Subject: Re: [Linux-fbdev-devel] (no subject)
> New to the list, is this an appropriate place to ask basic question
about
> framebuffer divices?
>
> for example:
> what are the basic funtions i can expect in a framebuffer?
WHat do you mean? Functionality from a userland perspective or from
inside
the kernel. Which version of the kernel are you looking at?
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* shared IP
From: EB3CZS Xavier Crehueras @ 2002-12-10 21:06 UTC (permalink / raw)
To: linux-hams
I read in the AX25-HOWTO that it is possible to have the same IP address in all the radio ports but routing must be carefully configured. I have a machine with 4 radio ports sharing an IP address. Has anyone tried something like this? Can anyone give me some advice to configure routing?
Thank you
--
73 de Xavi EB3CZS
JN11bl
^ permalink raw reply
* Re: vmalloc
From: Arjan van de Ven @ 2002-12-10 21:12 UTC (permalink / raw)
To: imran.badr; +Cc: Linux-kernel
In-Reply-To: <CNEJKAHIKPFGKOPLKCGDAEJOIEAA.imran.badr@cavium.com>
On Tue, 2002-12-10 at 22:02, Imran Badr wrote:
>
> Hi,
> Is there any limitation on the amount of memory that can be allocated by
> using vmalloc ( like 128KB for kmalloc) ?
>
for x86 you shouldn't count on being to get more than 64Mb of vmalloc
memory (even though most machines go upto 128Mb at least)
^ permalink raw reply
* Re: [ACPI] Re: [2.5.50, ACPI] link error
From: Andrew McGregor @ 2002-12-10 20:50 UTC (permalink / raw)
To: Pavel Machek, Alan Cox
Cc: Grover, Andrew, 'Ducrot Bruno', Ducrot Bruno,
Patrick Mochel, Linux Kernel Mailing List, ACPI mailing list
In-Reply-To: <20021210204031.GF20049@atrey.karlin.mff.cuni.cz>
I strongly suspect that s4bios will work on this machine, but swsusp won't.
Why? It's a Dell Inspiron 8000 with an NVidia Geforce2go, and until NVidia
put pm support in their driver, it's game over for Linux. Except that the
BIOS knows how to suspend it, so some kernel/driver combinations work with
APM. I suspect any Geforce2go Dell is the same.
Andrew
--On Tuesday, December 10, 2002 21:40:31 +0100 Pavel Machek <pavel@suse.cz>
wrote:
> Hi!
>
>> > I concur with your pros and cons. This makes me think that if S4BIOS
>> > support ever gets added, it should get added to 2.4 only.
>
> And S4BIOS will never get added to 2.4 since it needs driver model
> :-(.
>
>> That assumes no box exists where S4bios works an S4 doesnt (eg due to
>> bad tables or "knowing" what other-os does)
>
> We have full control over S4 (== swsusp), so we can fix that in most
> cases.
>
> S4BIOS is still little friendlier to the user -- no need to set up
> swap partition and command line parameter, can't go wrong if you boot
> without resume=, etc.
> Pavel
>
> --
> Casualities in World Trade Center: ~3k dead inside the building,
> cryptography in U.S.A. and free speech in Czech Republic.
> -
> 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
* [PATCH] make net/ipv4/route.c compile without CONFIG_PROC_FS
From: Arnd Bergmann @ 2002-12-10 21:08 UTC (permalink / raw)
To: 'Arnaldo Carvalho de Melo'; +Cc: Linux Kernel
The recent cleanup of /proc/net/rt_cache broke compiling
without procfs, this makes it work again.
===== net/ipv4/route.c 1.31 vs edited =====
--- 1.31/net/ipv4/route.c Sun Dec 8 03:45:58 2002
+++ edited/net/ipv4/route.c Tue Dec 10 22:01:36 2002
@@ -402,6 +402,11 @@
{
remove_proc_entry("rt_cache", proc_net);
}
+#else
+
+#define rt_cache_stat_get_info (get_info_t*)0
+static inline int rt_cache_proc_init(void) { return 0; }
+
#endif /* CONFIG_PROC_FS */
static __inline__ void rt_free(struct rtable *rt)
^ permalink raw reply
* Re: update_mmu_cache bug
From: Brian Murphy @ 2002-12-10 21:00 UTC (permalink / raw)
To: linux-mips; +Cc: Ralf Baechle
In-Reply-To: <20021210191801.GF609@gateway.total-knowledge.com>
ilya@theIlya.com wrote:
>Following small patch is needed to prevent kernel from going into infinite loop
>on page_fault. Probably similar patches are needed for other CPUs as well,
>but since I don;t have any, I'll let those who do take care of that :)
>
> Ilya.
>
>
>
It also seems not to work for the 32 bit kernel. The macro for
pte_offset_map
is very different in pgtable.h in the 32 bit directory than the 64 bit.
(Is there a good reason for this Ralf?)
/Brian
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.