* Timeout in do_write_oneword()
From: Marius Groeger @ 2002-12-12 13:36 UTC (permalink / raw)
To: linux-mtd
Hello,
we ran into a problem with the current CVS version of
drivers/mtd/chips/cfi_cmdset_0002.c::do_write_oneword(), line 514. We
think the following is broken on most platform, where HZ is 100 and
results in a 10ms jiffy resolution:
timeo = jiffies + (HZ/1000); /* setting timeout to 1ms for now */
Wouldn't this be better:
/* setting timeout to 1ms for now, but wait a least one system tick */
timeo = jiffies + (HZ/1000) ? (HZ/1000) : 1;
Regards,
Marius
-----------------------------------------------------------------------------
Marius Groeger SYSGO Real-Time Solutions AG mgroeger@sysgo.de
Software Engineering Embedded and Real-Time Software www.sysgo.de
Voice: +49-6136-9948-0 Am Pfaffenstein 14 www.osek.de
FAX: +49-6136-9948-10 55270 Klein-Winternheim, Germany www.elinos.com
^ permalink raw reply
* Re: Inserting rules is extremly slow :((
From: Paulo Andre @ 2002-12-12 13:03 UTC (permalink / raw)
To: nedco; +Cc: netfilter
In-Reply-To: <3df87716.1a99.0@unacs.bg>
On Thu, 2002-12-12 at 13:46, nedco@unacs.bg wrote:
>
>
>
> Hi,
> How to insert fast about 20000 rules in iptables.
> If some document will be help , please let me know :)
>
> Thanks a lot
> Nedco
>
I would write a firewall script and run it...
Put the script in /etc/rc.local and then if you ever reboot, viola
Paulo
^ permalink raw reply
* [PATCH] usb-storage : support for sony DSC-U10, kernel 2.4.20 & 2.5.51
From: Thomas Poindessous @ 2002-12-12 13:09 UTC (permalink / raw)
To: linux-kernel, usb-storage
[-- Attachment #1: Type: text/plain, Size: 222 bytes --]
Hi
here are two patch to support sony DSC-U10 digital camera.
I found them on google.
It works very well with 2.4.20 kernel. I didn't test it on a 2.5.x kernel.
Can someone apply them ?
thanks.
--
Thomas Poindessous
[-- Attachment #2: kernel-source-2.4.20_patch --]
[-- Type: text/x-diff, Size: 573 bytes --]
--- kernel-source-2.4.20/drivers/usb/storage/unusual_devs.h.orig 2002-12-11 20:42:21.000000000 +0100
+++ kernel-source-2.4.20/drivers/usb/storage/unusual_devs.h 2002-12-11 21:41:25.000000000 +0100
@@ -213,6 +213,12 @@
US_SC_SCSI, US_PR_CB, NULL,
US_FL_SINGLE_LUN | US_FL_START_STOP | US_FL_MODE_XLATE ),
+UNUSUAL_DEV( 0x054c, 0x0010, 0x0106, 0x0430,
+ "Sony",
+ "DSC-U10",
+ US_SC_SCSI, US_PR_CB, NULL,
+ US_FL_SINGLE_LUN | US_FL_START_STOP | US_FL_MODE_XLATE ),
+
/* Reported by wim@geeks.nl */
UNUSUAL_DEV( 0x054c, 0x0025, 0x0100, 0x0100,
"Sony",
[-- Attachment #3: linux-2.5.51_patch --]
[-- Type: text/x-diff, Size: 555 bytes --]
--- linux-2.5.51/drivers/usb/storage/unusual_devs.h.orig 2002-12-11 22:48:33.000000000 +0100
+++ linux-2.5.51/drivers/usb/storage/unusual_devs.h 2002-12-11 22:48:36.000000000 +0100
@@ -220,6 +220,12 @@
US_SC_SCSI, US_PR_CB, NULL,
US_FL_SINGLE_LUN | US_FL_START_STOP | US_FL_MODE_XLATE ),
+UNUSUAL_DEV( 0x054c, 0x0010, 0x0106, 0x0430,
+ "Sony",
+ "DSC-U10",
+ US_SC_SCSI, US_PR_CB, NULL,
+ US_FL_SINGLE_LUN | US_FL_START_STOP | US_FL_MODE_XLATE ),
+
/* Reported by wim@geeks.nl */
UNUSUAL_DEV( 0x054c, 0x0025, 0x0100, 0x0100,
"Sony",
^ permalink raw reply
* Is the preemptive kernel patch unsafe for 8xx/PPC?
From: Joakim Tjernlund @ 2002-12-12 12:56 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <3DF84AD5.9090500@intracom.gr>
Hi all
I am testing the latest(2.4.20-1) preemtive kernel patch from Robert Love and
I wonder if anybody know if it's unsafe/not working for 8xx or PPC in general?
So far it boots and runs fine but that's no proof.
Jocke
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH 2.5] SGI O2 framebuffer driver
From: Dominic Sweetman @ 2002-12-12 12:52 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Alan Cox, Vivien Chappelier, linux-mips, Ilya Volynets
In-Reply-To: <20021212132022.A5060@linux-mips.org>
Ralf Baechle (ralf@linux-mips.org) writes:
> Flushes are very expensive operations, on the order of 16 cycles per
> cacheline plus memory delay.
Hmm. Not on most MIPS CPUs; the internal cost of running the
writeback cache-op instructions is typically around 3 clocks per
cache-line. But this is misleading anyway... too CPU-centric.
The associated memory operations are the slowest thing about cacheops,
always. Memory accesses (120ns is good) are much, much slower than an
instruction time on a modern CPU (1-5ns).
So for your framebuffer, it's the write which does for you. If you
use uncached mode and write 32-bit words that's 120ns/word. You can
get a cacheline-sized burst of 8 words in and out in roughly the same
amount of time.
In most cases this means that cacheing the framebuffer and then
pushing it out will save a whole lot of time.
It's not absolutely certain: in most MIPS CPUs (write allocate as well
as writeback) you also pay to read in the framebuffer data. And it
tends to displace all sorts of other useful data from the cache, and
then you have to pay to bring it back again.
But in general the memory operations associated with write-backs and
invalidates are much more costly than the cacheops themselves.
--
Dominic Sweetman,
MIPS Technologies (UK)
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706205 / fax: +44 1223 706250 / swbrd: +44 1223 706200
http://www.algor.co.uk
^ permalink raw reply
* Re: Question on set_page_dirty()
From: Stephen C. Tweedie @ 2002-12-12 12:42 UTC (permalink / raw)
To: Ingo Oeser; +Cc: Jan Hudec, Martin Maletinsky, linux-mm, kernelnewbies
In-Reply-To: <20021212102930.C15158@nightmaster.csn.tu-chemnitz.de>
Hi,
On Thu, 2002-12-12 at 09:29, Ingo Oeser wrote:
> set_page_dirty() can be used in all cases, IMHO, since it:
> - will not sleep
...
Unfortunately, it can take both the inode_lock and pagecache_lock
spinlocks, so if you use it in the wrong place, with other locks already
held, you can cause a deadlock. So you _do_ need to be a bit careful,
and you can't just use it with abandon.
Cheers,
Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* bbram access problems
From: Geoffroy Stevenne @ 2002-12-12 13:05 UTC (permalink / raw)
To: linux-mtd; +Cc: jch
Hi,
We're trying to use BBRAM on a VersaLogic VSBC-6 m-b. We use the slram
driver and the 2.4.18 kernel. The problem is that we can't acces the
entire memory of the BBRAM, just the first 64k page.
Other problem: we added to our lilo.conf:
append="slram=BBRAM,0xE0000,+0x10000"
We can write to the BBRAM but we noticed data corruption (not write
operation was done) in this address range. Is there a way to lock this
memory area? Is this the right thing to do?
What we need is to mount a filesystem on the entire BBRAM, not just the
first 64k. I can (and wish to) provide more information, test changes,
report bugs, etc. I can read and understand C code but I don't feel
competent in writing drivers on my own.
Thanks for your help,
--
Geoffroy Stévenne
Hellea SPRL
^ permalink raw reply
* Re: a question about ip_conntrack_max
From: Harald Welte @ 2002-12-12 12:32 UTC (permalink / raw)
To: jump lee; +Cc: netfilter-devel
In-Reply-To: <F78gEj4v5iJarnJ3kEP000004e7@hotmail.com>
[-- Attachment #1: Type: text/plain, Size: 819 bytes --]
On Thu, Dec 12, 2002 at 02:35:56PM +0800, jump lee wrote:
>
> i am hacking ip_conntrack.
> in function ip_conntrack_init (ip_conntrack_core.c), i can not understand
> this statement:
>
> ip_conntrack_max=8*ip_conntrack_htable_size;
>
> what's the reason of multiplying ip_conntrack_htable_size by 8?
please read the mailinglist archive. There have been discussions about
this subject going on all the time. You can greatly improve performance
by using different values (higher prime numbers, ...) here.
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: [PATCH 2.5] SGI O2 framebuffer driver
From: Ralf Baechle @ 2002-12-12 12:20 UTC (permalink / raw)
To: Alan Cox; +Cc: Vivien Chappelier, linux-mips, Ilya Volynets
In-Reply-To: <1039697045.21231.13.camel@irongate.swansea.linux.org.uk>
On Thu, Dec 12, 2002 at 12:44:05PM +0000, Alan Cox wrote:
> > The O2 is non-cache coherent. So with the fairly large write-back second
> > level caches enabled frame buffer write could potencially be delayed
> > indefinately but in any case quite long. Frame buffers are usually only
>
> You can flush the frame buffer pages that were touched at the end of an
> operation though
Flushes are very expensive operations, on the order of 16 cycles per
cacheline plus memory delay. So why using them when just using the right
cache mode does the right thing already.
Ralf
^ permalink raw reply
* Re: Inserting rules is extremly slow :((
From: Filip Sneppe @ 2002-12-12 12:25 UTC (permalink / raw)
To: nedco; +Cc: netfilter
In-Reply-To: <3df87716.1a99.0@unacs.bg>
On Thu, 2002-12-12 at 12:46, nedco@unacs.bg wrote:
>
> Hi,
> How to insert fast about 20000 rules in iptables.
> If some document will be help , please let me know :)
>
Hi,
man iptables-save
man iptables-restore
That's the only solution to your performance problem at this moment...
Regards,
Filip
^ permalink raw reply
* Re: Linux 2.4.21-pre1 IDE
From: Alan Cox @ 2002-12-12 13:10 UTC (permalink / raw)
To: andersen; +Cc: Marcelo Tosatti, lkml
In-Reply-To: <20021212013546.GA30408@codepoet.org>
On Thu, 2002-12-12 at 01:35, Erik Andersen wrote:
> hda: DMA disabled
> ^^^^^^^^^^^^^^^^^
>
> What's up with this? For each drive in my system it claims it
> has disabled DMA. But hdparm later reports that DMA is in fact
> enabled. In fact, later on the kernel ever reports the drive
> as being in UDMA 100 mode... I think these "DMA disabled"
> messages are bogus.
Cosmetic and known. It in fact turns DMA back on - quietly
> ide2 at 0x1800-0x1807,0xac02 on irq 11
> hda: host protected area => 1
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> hda: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=10011/255/63, UDMA(100)
>
> Now we see the funky "host protected area => 1" message. As
> discussed earlier with Andre, this message should be removed from
> the kernel. The message as written implies that the driv
Before 2.4.21 agreed
^ permalink raw reply
* anyone working on radeonfb?
From: Aleksandr Koltsoff @ 2002-12-12 12:23 UTC (permalink / raw)
To: linux-fbdev-devel
hello
is anyone actively maintaining the radeon fb driver in the 2.4 series?
I've started reviving and older hacked version (based on mplayer radeonfb)
of the driver. The version I have has proper panning and accel console
(almost, 32bit mode is causing some minor head-aches still).
I'd like to eventually sync my version with the kernel one (and yes, I
know that the mplayer version is way off Linus coding style, and yes, it's
based somewhat on xfree86, but I'm willing to work that out eventually).
currently I have only some radeon boards left, but no DVI anymore, so I'll
need someone with DVI displays as well. Also I have no access to PPCs, so
would need someone to test the newer driver there as well if possible.
thanks :-)
ak.
-------------------------------------------------------
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
* [BENCHMARK] TIO bench mm2 patch better than mm1 patch
From: Aniruddha M Marathe @ 2002-12-12 12:29 UTC (permalink / raw)
To: linux-kernel
Hi,
Here are the results of comparison of Kernel 2.5.51 with mm2 patch and 2.5.51 with mm1 patch.
Please see the mail in full size window to avoid text wrap problem.
Key findings of the comparison:
1. Great reduction in maximum latency.
2. better throughput of CPU mainly because less usage for same work.
3. mega-bytes transfered per second have also improved.
many optimizations done in the pathces. they must perform :)
*******************************************************************************
TIO BENCH PERFORMANCE RESULT
LINUX KERNEL 2.5.51 with mm2
Date: December 12TH 2002
*******************************************************************************
No size specified, using 252 MB
Unit information
================
File size = megabytes
Blk Size = bytes
Rate = megabytes per second
CPU% = percentage of CPU used during the test
Latency = milliseconds
Lat% = percent of requests that took longer than X seconds
CPU Eff = Rate divided by CPU% - throughput per cpu load
Sequential Reads
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.5.51 252 4096 10 8.81 5.345% 12.244 1894.78 0.00000 0.00000 165
Random Reads
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.5.51 252 4096 10 0.51 0.750% 206.139 1306.27 0.00000 0.00000 68
Sequential Writes
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.5.51 252 4096 10 17.56 32.68% 3.841 28833.24 0.05625 0.00156 54
Random Writes
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.5.51 252 4096 10 0.72 1.013% 3.694 4066.20 0.07500 0.00000 71
*******************************************************************************
TIO BENCH PERFORMANCE RESULT
LINUX KERNEL 2.5.51 with mm1
Date: December 11TH 2002
*******************************************************************************
Unit information
================
File size = megabytes
Blk Size = bytes
Rate = megabytes per second
CPU% = percentage of CPU used during the test
Latency = milliseconds
Lat% = percent of requests that took longer than X seconds
CPU Eff = Rate divided by CPU% - throughput per cpu load
Sequential Reads
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.5.51 252 4096 10 8.57 5.375% 12.720 1712.91 0.00000 0.00000 159
Random Reads
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.5.51 252 4096 10 0.50 1.073% 205.984 1278.60 0.00000 0.00000 47
Sequential Writes
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.5.51 252 4096 10 17.86 33.77% 3.850 21603.95 0.06406 0.00000 53
Random Writes
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.5.51 252 4096 10 0.77 1.091% 0.736 1551.03 0.00000 0.00000 70
========================================================================================================================
Regards,
---------------------------------------------------------------
Aniruddha Marathe
Systems Engineer,
4th floor, WIPRO technologies,
53/1, Hosur road,
Madivala,
Bangalore - 560068
Karnataka, India
Phone: +91-80-5502001 extension 5092
E-mail: aniruddha.marathe@wipro.com
---------------------------------------------------------------
^ permalink raw reply
* Re: hostname forwarding
From: bernard @ 2002-12-12 12:20 UTC (permalink / raw)
To: netfilter
In-Reply-To: <Pine.LNX.4.33.0212111606240.17876-100000@www.csbenter.at>
Thank again for your valuable help.
So apache can take http requests to do that but what's about the
other protocols ?
It seems that squid can do a transparent proxy for some of them.
Do I need to use a specific solutions for each different protocol I
want to set and what solution to use for the most common (telnet,
pop, imap, ftp, ...) ?
Bernard
>this is not possible using ipotables
>
>Apache however can very well handle this ..
>
>
>On Wed, 11 Dec 2002, bernard wrote:
>
>> I'm using iptables to redirect external requests depending on their
>> port/protocol like this :
>>
>> hostname A:80 -> public ip -> iptables -> 192.168.1.1:80
>> hostname B:80 -> public ip -> iptables -> 192.168.1.1:80
>>
>> It works pretty well, thanks to iptables :-)
>>
>> Now I want to redirect on a hostname basis on different private ip's
>> like this :
>>
>> hostname A:80 -> public ip -> iptables -> 192.168.1.1:80
>> hostname B:80 -> public ip -> iptables -> 192.168.1.2:80
>>
>> Does anyone know a solution ?
>>
>> Thanks for your help.
>>
>> Bernard
>>
>
>--
>---
>Kind Regards
>Patrick Maartense (using Pine on a Text Console)
^ permalink raw reply
* [PATCH] Add helper routines for fixing up page alignment on xdr_buf
From: Trond Myklebust @ 2002-12-12 12:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: NFS maillist
In order to speed up NFS reads, we attempt to copy directly from
skbuffs into the pagecache pages. As we cannot do XDR decoding in the
soft interrupts, we attempt to estimate the size of the RPC header (+
attributes,...) that will precede the actual data that goes in the
pagecache. If we get the estimate wrong, the XDR decode routines
perform a realignment of the data into the pagecache.
In the existing code, we do a multi-page kmap() from the xdr_buf into
an iovec array, in order to do the shift.
The following patch adds tools for doing the realigment without going
through the iovec array (and without having to do the deadlock-prone
multi-page kmap()).
It also adds the 2 helper routines xdr_read_pages()/xdr_write_pages()
which will be needed for NFSv4 reads/writes in order to add pre/post
operation GETATTR calls.
Cheers,
Trond
diff -u --recursive --new-file linux-2.5.51-02-nfsv4_xdr2/include/linux/sunrpc/xdr.h linux-2.5.51-03-xdr_shift/include/linux/sunrpc/xdr.h
--- linux-2.5.51-02-nfsv4_xdr2/include/linux/sunrpc/xdr.h 2002-11-22 01:51:31.000000000 +0100
+++ linux-2.5.51-03-xdr_shift/include/linux/sunrpc/xdr.h 2002-12-10 11:04:42.000000000 +0100
@@ -211,6 +211,10 @@
return p;
}
+extern void xdr_write_pages(struct xdr_stream *xdr, struct page **pages,
+ unsigned int base, unsigned int len);
+extern void xdr_read_pages(struct xdr_stream *xdr, unsigned int len);
+
/*
* Initialize an xdr_stream for decoding data.
*/
diff -u --recursive --new-file linux-2.5.51-02-nfsv4_xdr2/net/sunrpc/sunrpc_syms.c linux-2.5.51-03-xdr_shift/net/sunrpc/sunrpc_syms.c
--- linux-2.5.51-02-nfsv4_xdr2/net/sunrpc/sunrpc_syms.c 2002-11-09 02:51:52.000000000 +0100
+++ linux-2.5.51-03-xdr_shift/net/sunrpc/sunrpc_syms.c 2002-12-10 11:04:42.000000000 +0100
@@ -120,6 +120,8 @@
EXPORT_SYMBOL(xdr_encode_pages);
EXPORT_SYMBOL(xdr_inline_pages);
EXPORT_SYMBOL(xdr_shift_buf);
+EXPORT_SYMBOL(xdr_write_pages);
+EXPORT_SYMBOL(xdr_read_pages);
/* Debugging symbols */
#ifdef RPC_DEBUG
diff -u --recursive --new-file linux-2.5.51-02-nfsv4_xdr2/net/sunrpc/xdr.c linux-2.5.51-03-xdr_shift/net/sunrpc/xdr.c
--- linux-2.5.51-02-nfsv4_xdr2/net/sunrpc/xdr.c 2002-11-01 22:50:09.000000000 +0100
+++ linux-2.5.51-03-xdr_shift/net/sunrpc/xdr.c 2002-12-10 15:17:14.000000000 +0100
@@ -141,7 +141,6 @@
xdr->len += len;
}
-
/*
* Realign the iovec if the server missed out some reply elements
* (such as post-op attributes,...)
@@ -318,13 +317,308 @@
copy_actor(desc, (char *)xdr->tail[0].iov_base + base, len);
}
+
+/*
+ * Helper routines for doing 'memmove' like operations on a struct xdr_buf
+ *
+ * _shift_data_right_pages
+ * @pages: vector of pages containing both the source and dest memory area.
+ * @pgto_base: page vector address of destination
+ * @pgfrom_base: page vector address of source
+ * @len: number of bytes to copy
+ *
+ * Note: the addresses pgto_base and pgfrom_base are both calculated in
+ * the same way:
+ * if a memory area starts at byte 'base' in page 'pages[i]',
+ * then its address is given as (i << PAGE_CACHE_SHIFT) + base
+ * Also note: pgfrom_base must be < pgto_base, but the memory areas
+ * they point to may overlap.
+ */
+static void
+_shift_data_right_pages(struct page **pages, size_t pgto_base,
+ size_t pgfrom_base, size_t len)
+{
+ struct page **pgfrom, **pgto;
+ char *vfrom, *vto;
+ size_t copy;
+
+ BUG_ON(pgto_base <= pgfrom_base);
+
+ pgto_base += len;
+ pgfrom_base += len;
+
+ pgto = pages + (pgto_base >> PAGE_CACHE_SHIFT);
+ pgfrom = pages + (pgfrom_base >> PAGE_CACHE_SHIFT);
+
+ pgto_base &= ~PAGE_CACHE_MASK;
+ pgfrom_base &= ~PAGE_CACHE_MASK;
+
+ do {
+ /* Are any pointers crossing a page boundary? */
+ if (pgto_base == 0) {
+ pgto_base = PAGE_CACHE_SIZE;
+ pgto--;
+ }
+ if (pgfrom_base == 0) {
+ pgfrom_base = PAGE_CACHE_SIZE;
+ pgfrom--;
+ }
+
+ copy = len;
+ if (copy > pgto_base)
+ copy = pgto_base;
+ if (copy > pgfrom_base)
+ copy = pgfrom_base;
+ pgto_base -= copy;
+ pgfrom_base -= copy;
+
+ vto = kmap_atomic(*pgto, KM_USER0);
+ vfrom = kmap_atomic(*pgfrom, KM_USER1);
+ memmove(vto + pgto_base, vfrom + pgfrom_base, copy);
+ kunmap_atomic(vfrom, KM_USER1);
+ kunmap_atomic(vto, KM_USER0);
+
+ } while ((len -= copy) != 0);
+}
+
+/*
+ * _copy_to_pages
+ * @pages: array of pages
+ * @pgbase: page vector address of destination
+ * @p: pointer to source data
+ * @len: length
+ *
+ * Copies data from an arbitrary memory location into an array of pages
+ * The copy is assumed to be non-overlapping.
+ */
+static void
+_copy_to_pages(struct page **pages, size_t pgbase, const char *p, size_t len)
+{
+ struct page **pgto;
+ char *vto;
+ size_t copy;
+
+ pgto = pages + (pgbase >> PAGE_CACHE_SHIFT);
+ pgbase &= ~PAGE_CACHE_MASK;
+
+ do {
+ copy = PAGE_CACHE_SIZE - pgbase;
+ if (copy > len)
+ copy = len;
+
+ vto = kmap_atomic(*pgto, KM_USER0);
+ memcpy(vto + pgbase, p, copy);
+ kunmap_atomic(vto, KM_USER0);
+
+ pgbase += copy;
+ if (pgbase == PAGE_CACHE_SIZE) {
+ pgbase = 0;
+ pgto++;
+ }
+ p += copy;
+
+ } while ((len -= copy) != 0);
+}
+
+/*
+ * _copy_from_pages
+ * @p: pointer to destination
+ * @pages: array of pages
+ * @pgbase: offset of source data
+ * @len: length
+ *
+ * Copies data into an arbitrary memory location from an array of pages
+ * The copy is assumed to be non-overlapping.
+ */
+static void
+_copy_from_pages(char *p, struct page **pages, size_t pgbase, size_t len)
+{
+ struct page **pgfrom;
+ char *vfrom;
+ size_t copy;
+
+ pgfrom = pages + (pgbase >> PAGE_CACHE_SHIFT);
+ pgbase &= ~PAGE_CACHE_MASK;
+
+ do {
+ copy = PAGE_CACHE_SIZE - pgbase;
+ if (copy > len)
+ copy = len;
+
+ vfrom = kmap_atomic(*pgfrom, KM_USER0);
+ memcpy(p, vfrom + pgbase, copy);
+ kunmap_atomic(vfrom, KM_USER0);
+
+ pgbase += copy;
+ if (pgbase == PAGE_CACHE_SIZE) {
+ pgbase = 0;
+ pgfrom++;
+ }
+ p += copy;
+
+ } while ((len -= copy) != 0);
+}
+
+/*
+ * xdr_shrink_bufhead
+ * @buf: xdr_buf
+ * @len: bytes to remove from buf->head[0]
+ *
+ * Shrinks XDR buffer's header iovec buf->head[0] by
+ * 'len' bytes. The extra data is not lost, but is instead
+ * moved into the inlined pages and/or the tail.
+ */
void
-xdr_shift_buf(struct xdr_buf *xdr, size_t len)
+xdr_shrink_bufhead(struct xdr_buf *buf, size_t len)
{
- struct iovec iov[MAX_IOVEC];
- unsigned int nr;
+ struct iovec *head, *tail;
+ size_t copy, offs;
+ unsigned int pglen = buf->page_len;
+
+ tail = buf->tail;
+ head = buf->head;
+ BUG_ON (len > head->iov_len);
+
+ /* Shift the tail first */
+ if (tail->iov_len != 0) {
+ if (tail->iov_len > len) {
+ copy = tail->iov_len - len;
+ memmove((char *)tail->iov_base + len,
+ tail->iov_base, copy);
+ }
+ /* Copy from the inlined pages into the tail */
+ copy = len;
+ if (copy > pglen)
+ copy = pglen;
+ offs = len - copy;
+ if (offs >= tail->iov_len)
+ copy = 0;
+ else if (copy > tail->iov_len - offs)
+ copy = tail->iov_len - offs;
+ if (copy != 0)
+ _copy_from_pages((char *)tail->iov_base + offs,
+ buf->pages,
+ buf->page_base + pglen + offs - len,
+ copy);
+ /* Do we also need to copy data from the head into the tail ? */
+ if (len > pglen) {
+ offs = copy = len - pglen;
+ if (copy > tail->iov_len)
+ copy = tail->iov_len;
+ memcpy(tail->iov_base,
+ (char *)head->iov_base +
+ head->iov_len - offs,
+ copy);
+ }
+ }
+ /* Now handle pages */
+ if (pglen != 0) {
+ if (pglen > len)
+ _shift_data_right_pages(buf->pages,
+ buf->page_base + len,
+ buf->page_base,
+ pglen - len);
+ copy = len;
+ if (len > pglen)
+ copy = pglen;
+ _copy_to_pages(buf->pages, buf->page_base,
+ (char *)head->iov_base + head->iov_len - len,
+ copy);
+ }
+ head->iov_len -= len;
+ buf->len -= len;
+}
- nr = xdr_kmap(iov, xdr, 0);
- xdr_shift_iovec(iov, nr, len);
- xdr_kunmap(xdr, 0);
+/*
+ * xdr_shrink_pagelen
+ * @buf: xdr_buf
+ * @len: bytes to remove from buf->pages
+ *
+ * Shrinks XDR buffer's page array buf->pages by
+ * 'len' bytes. The extra data is not lost, but is instead
+ * moved into the tail.
+ */
+void
+xdr_shrink_pagelen(struct xdr_buf *buf, size_t len)
+{
+ struct iovec *tail;
+ size_t copy;
+ char *p;
+ unsigned int pglen = buf->page_len;
+
+ tail = buf->tail;
+ BUG_ON (len > pglen);
+
+ /* Shift the tail first */
+ if (tail->iov_len != 0) {
+ p = (char *)tail->iov_base + len;
+ if (tail->iov_len > len) {
+ copy = tail->iov_len - len;
+ memmove(p, tail->iov_base, copy);
+ } else
+ buf->len -= len;
+ /* Copy from the inlined pages into the tail */
+ copy = len;
+ if (copy > tail->iov_len)
+ copy = tail->iov_len;
+ _copy_from_pages((char *)tail->iov_base,
+ buf->pages, buf->page_base + pglen - len,
+ copy);
+ }
+ buf->page_len -= len;
+ buf->len -= len;
+}
+
+void
+xdr_shift_buf(struct xdr_buf *buf, size_t len)
+{
+ xdr_shrink_bufhead(buf, len);
+}
+
+void
+xdr_write_pages(struct xdr_stream *xdr, struct page **pages, unsigned int base,
+ unsigned int len)
+{
+ struct xdr_buf *buf = xdr->buf;
+ struct iovec *iov = buf->tail;
+ buf->pages = pages;
+ buf->page_base = base;
+ buf->page_len = len;
+
+ iov->iov_base = (char *)xdr->p;
+ iov->iov_len = 0;
+ xdr->iov = iov;
+
+ if (len & 3) {
+ unsigned int pad = 4 - (len & 3);
+
+ BUG_ON(xdr->p >= xdr->end);
+ iov->iov_base = (char *)xdr->p + (len & 3);
+ iov->iov_len += pad;
+ len += pad;
+ *xdr->p++ = 0;
+ }
+ buf->len += len;
+}
+
+void
+xdr_read_pages(struct xdr_stream *xdr, unsigned int len)
+{
+ struct xdr_buf *buf = xdr->buf;
+ struct iovec *iov;
+ ssize_t shift;
+
+ /* Realign pages to current pointer position */
+ iov = buf->head;
+ shift = iov->iov_len + (char *)iov->iov_base - (char *)xdr->p;
+ if (shift > 0)
+ xdr_shrink_bufhead(buf, shift);
+
+ /* Truncate page data and move it into the tail */
+ len = XDR_QUADLEN(len) << 2;
+ if (buf->page_len > len)
+ xdr_shrink_pagelen(buf, buf->page_len - len);
+ xdr->iov = iov = buf->tail;
+ xdr->p = (uint32_t *)iov->iov_base;
+ xdr->end = (uint32_t *)((char *)iov->iov_base + iov->iov_len);
}
-------------------------------------------------------
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/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [parisc-linux] ["CSA Test Drive" <TestDrive@compaq.com>] FW: Some issues
From: Matthew Wilcox @ 2002-12-12 12:15 UTC (permalink / raw)
To: Randolph Chung
Cc: John David Anglin, Carlos O'Donell, bdale, parisc-linux
In-Reply-To: <20021212065059.GQ21187@tausq.org>
On Wed, Dec 11, 2002 at 10:50:59PM -0800, Randolph Chung wrote:
> (oh, as an aside, looks like there's a small objdump bug :-)
> 00010428 <ull2dbl>:
> 10428: 0f d9 12 81 stw r25,-10(sr0,sp)
> 1042c: 0f da 12 89 stw r26,-c(sr0,sp)
> 10430: 2f c1 10 16 fldd -10(sr0,sp),fr22
> 10434: e8 40 d0 00 bve (rp)
> 10438: 32 c2 aa 04 fcnv Disassembler botch.
>
> (should be fcnv,udw,dbl %fr22,%fr4)
well, there's another one:
stw r25,-10(sr0,sp)
printing `sr0,' is misleading -- were not using sr0, we're using `short
addressing mode', it should be just:
stw r25,-10(sp)
i remember jsm pointing this out a couple of years ago. basically for insns
which have a 2-bit s field, print nothing if it's zero. sr0 should still be
pinted for insns with a 3-bit s field.
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
^ permalink raw reply
* Re: PATCH: Four function buttons on DELL Latitude X200
From: Vojtech Pavlik @ 2002-12-12 12:20 UTC (permalink / raw)
To: James H. Cloos Jr.
Cc: Vojtech Pavlik, Pavel Machek, H. Peter Anvin, linux-kernel
In-Reply-To: <m3znrb4ejx.fsf@lugabout.jhcloos.org>
On Thu, Dec 12, 2002 at 07:17:22AM -0500, James H. Cloos Jr. wrote:
> >>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
>
> Vojtech> Do they by any chance produce a kernel warning when pressed?
>
> Yes, the two keys that do not generate an event in X syslog these errors:
>
> atkbd.c: Unknown key (set 2, scancode 0x176, on isa0060/serio0) pressed.
> atkbd.c: Unknown key (set 2, scancode 0x176, on isa0060/serio0) released.
> atkbd.c: Unknown key (set 2, scancode 0x11e, on isa0060/serio0) pressed.
> atkbd.c: Unknown key (set 2, scancode 0x11e, on isa0060/serio0) released.
>
> where 0x176 is the PLAY key and 0x11e is the PREV key.
You can edit atkbd.c, and at the beginning there is a big table, add
some reasonable keycodes (KEY_PLAY, KEY_PREV), to entries 0x11e and
0x176 in the table.
> Incidently, the FORWARD key is giving the same keycode as the main
> kb's Pause key.
Should be possible to fix at the same place.
(You can try to use 'setkeycode' for the same purpose in 2.5, but it
might and might not work.)
--
Vojtech Pavlik
SuSE Labs
^ permalink raw reply
* changing packets with libipq
From: Peter Hoare @ 2002-12-12 12:12 UTC (permalink / raw)
To: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
We are having problems in trying to use the userspace libipq to change
incoming packets to the kernel. We are picking up UDP packets off the
pre-routing queue, changing the packet header and checksums and then
accepting the new packet back through the ipq_set_verdict() call with
NF_ACCEPT.
This new packet is being delivered quite happily to an end-user
application on the local machine but if the packet is to be forwarded
through this host to another machine it appears to be dropped by the
kernel. Is there a limit to what we are allowed to change in the packet
through libipq? (There are some hints in the documentation to do with
caching fields in the skb that may be the cause of our problem). Our
guess is that because we are significantly changing the header that the
new packet is no longer being recognised as related to the old one?
Is what we are doing not possible using libipq? If not do we have to
write a kernel module to do it or is there any other way to do it in
userspace?
Thank you
Peter Hoare
[-- Attachment #2: Card for Peter Hoare --]
[-- Type: text/x-vcard, Size: 928 bytes --]
begin:vcard
n:Hoare;Peter
tel;fax:+44 1684 894389
tel;work:+44 1684 896438
x-mozilla-html:TRUE
url:www.qinetiq.com
org:QinetiQ;Sensors and Information Processing
version:2.1
email;internet:peteh@signal.qinetiq.com
title:Principal Scientist
adr;quoted-printable:version:2.1;;E204 =0D=0AQinetiQ=0D=0ASt Andrews Road;Malvern;Worcs;WR14 3PS;UK
note;quoted-printable:The Information contained in this e-mail and any subsequent =0D=0Acorrespondence is private and is intended solely for the =0D=0Aintended recipient(s). For those other than the intended recipient =0D=0Aany disclosure, copying, distribution, or any action taken or =0D=0Aomitted to be taken in reliance on such information is prohibited =0D=0Aand may be unlawful.=0D=0A=0D=0AThe views expressed above are entirely those of the writer and =0D=0Ado not represent the views, policy or understanding of any other =0D=0Aperson or official body.
fn:Pete Hoare
end:vcard
^ permalink raw reply
* Re: PATCH: Four function buttons on DELL Latitude X200
From: James H. Cloos Jr. @ 2002-12-12 12:17 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Pavel Machek, H. Peter Anvin, linux-kernel
In-Reply-To: <20021212125114.A10134@ucw.cz>
>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
Vojtech> Do they by any chance produce a kernel warning when pressed?
Yes, the two keys that do not generate an event in X syslog these errors:
atkbd.c: Unknown key (set 2, scancode 0x176, on isa0060/serio0) pressed.
atkbd.c: Unknown key (set 2, scancode 0x176, on isa0060/serio0) released.
atkbd.c: Unknown key (set 2, scancode 0x11e, on isa0060/serio0) pressed.
atkbd.c: Unknown key (set 2, scancode 0x11e, on isa0060/serio0) released.
where 0x176 is the PLAY key and 0x11e is the PREV key.
Incidently, the FORWARD key is giving the same keycode as the main
kb's Pause key.
-JimC
^ permalink raw reply
* sg3_utils-1.02 and sg_utils-1.02 betas
From: Douglas Gilbert @ 2002-12-12 12:10 UTC (permalink / raw)
To: linux-scsi
There are tarballs of these 2 packages linked at the top
of my http://www.torque.net/sg page.
As noted earlier the addition of some of sg's ioctls in
the block level (from about lk 2.5.48) brings both
advantages and dangers.
The main danger is that utilities (e.g. most of those
in sg_utils) that assume that any device responding to
one of sg's ioctls is an sg device and hence it is safe
to use sg's older write()/read() interface. **
The advantage is that the variant that assumed the version
3 sg driver (i.e. sg3_utils-1.02) can send SG_IO ioctls
straight through to block devices. For example:
sg_inq /dev/sdb
sg_logs -p=d /dev/sda # this is the temperature page
The SG_IO ioctl in the block level still has some rough
edges. Hence utilities like sg_dd still treat block devices
like normal files (although there is an extra option to
send SG_IO ioctls through to block devices).
See the CHANGELOG file for more details.
** I have some practical experience of what happens (with
sginfo). The first 48 bytes (or so) of a disk get overwritten.
This damages the boot loader (grub in my case) so you can no
longer boot with that disk. The good news is that all
partitions and the partition table are still intact.
Luckily the first 48 bytes on a boot disk of redhat's last
few versions (since they defaulted to grub) are invariant.
Doug Gilbert
^ permalink raw reply
* Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).
From: Antonino Daplas @ 2002-12-12 15:00 UTC (permalink / raw)
To: Miles Lane; +Cc: James Simmons, Linux Fbdev development list
In-Reply-To: <3DF6894E.3090802@attbi.com>
[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]
On Wed, 2002-12-11 at 05:39, Miles Lane wrote:
> Hi,
>
> I have tried getting rivafb to work in 2.5.51. It is much better
> than before (thanks!). It compiles and sorta works.
>
Can you test the attached patch (rivafb1.diff)? It fixes some things:
1. double ioremap/request_mem_region of the framebuffer memory. Might
cause some initialization weirdness :-)
2. riva_hw.c is outdated (no support for NV_ARCH_20) which will crash
the GeForce3's (I think I read one report of that in the kernel mailing
list).
3. Matched the initialization ordering of rivafb in linux-2.4, except
that RivaGetConfig is executed at rivafb_open().
3. Not sure if the color problem will be fixed. Miles, are you by
offchance using bpp > 8? Because setting the DAC at 8 bpp should be a
very simple matter compared with directcolor which requires some
juggling acts
Also, you mentioned that everything is okay except the characters are
mirrored in the vertical axis, is this correct? Meaning colors are fine
etc. If this is the case, try this patch also:
diff -Naur linux-2.5.51/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.51/drivers/video/riva/fbdev.c 2002-12-12 13:59:07.000000000 +0000
+++ linux/drivers/video/riva/fbdev.c 2002-12-12 13:59:30.000000000 +0000
@@ -917,9 +917,11 @@
size = width * h;
dat = cdat;
- for (i = 0; i < size; i++) {
- *dat = byte_rev[*dat];
- dat++;
+ if (par->riva.Architecture == NV_ARCH_03) {
+ for (i = 0; i < size; i++) {
+ *dat = byte_rev[*dat];
+ dat++;
+ }
}
switch (info->var.bits_per_pixel) {
Tony
[-- Attachment #2: rivafb1.diff --]
[-- Type: text/x-patch, Size: 9901 bytes --]
diff -Naur linux-2.5.51/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.51/drivers/video/riva/fbdev.c 2002-12-12 13:57:09.000000000 +0000
+++ linux/drivers/video/riva/fbdev.c 2002-12-12 13:58:05.000000000 +0000
@@ -916,6 +916,7 @@
size = width * h;
dat = cdat;
+
for (i = 0; i < size; i++) {
*dat = byte_rev[*dat];
dat++;
@@ -923,17 +924,11 @@
switch (info->var.bits_per_pixel) {
case 8:
- fgx = image->fg_color | ~((1 << 8) - 1);
- bgx = image->bg_color | ~((1 << 8) - 1);
+ fgx = image->fg_color;
+ bgx = image->bg_color;
break;
case 16:
- /* set alpha bit */
- if (info->var.green.length == 5) {
- fgx = 1 << 15;
- bgx = fgx;
- }
- /* Fall through... */
case 32:
fgx |= par->riva_palette[image->fg_color];
bgx |= par->riva_palette[image->bg_color];
@@ -1169,6 +1164,9 @@
save_vga(&par->state);
RivaGetConfig(&par->riva);
+ CRTCout(par, 0x11, 0xFF); /* vgaHWunlock() + riva unlock (0x7F) */
+ par->riva.LockUnlock(&par->riva, 0);
+
riva_save_state(par, &par->initial_state);
}
@@ -1554,13 +1552,14 @@
info->display_fg = NULL;
info->pseudo_palette = pseudo_palette;
- cmap_len = riva_get_cmap_len(&info->var);
- fb_alloc_cmap(&info->cmap, cmap_len, 0);
#ifndef MODULE
if (mode_option)
fb_find_mode(&info->var, info, mode_option,
NULL, 0, NULL, 8);
#endif
+ cmap_len = riva_get_cmap_len(&info->var);
+ fb_alloc_cmap(&info->cmap, cmap_len, 0);
+
return 0;
}
@@ -1713,13 +1712,6 @@
goto err_out_free_base1;
}
- info->screen_base = ioremap(rivafb_fix.smem_start,
- rivafb_fix.smem_len);
- if (!info->screen_base) {
- printk(KERN_ERR PFX "cannot ioremap FB base\n");
- goto err_out_iounmap_ctrl;
- }
-
default_par->riva.EnableIRQ = 0;
default_par->riva.PRAMDAC = (unsigned *)(default_par->ctrl_base +
0x00680000);
@@ -1744,6 +1736,25 @@
default_par->riva.IO = (MISCin(default_par) & 0x01) ? 0x3D0 : 0x3B0;
+ if (default_par->riva.Architecture == NV_ARCH_03) {
+ /*
+ * We have to map the full BASE_1 aperture for Riva128's
+ * because they use the PRAMIN set in "framebuffer" space
+ */
+ if (!request_mem_region(rivafb_fix.smem_start,
+ rivafb_fix.smem_len, "rivafb")) {
+ printk(KERN_ERR PFX "cannot reserve FB region\n");
+ goto err_out_free_base0;
+ }
+
+ info->screen_base = ioremap(rivafb_fix.smem_start,
+ rivafb_fix.smem_len);
+ if (!info->screen_base) {
+ printk(KERN_ERR PFX "cannot ioremap FB base\n");
+ goto err_out_iounmap_ctrl;
+ }
+ }
+
switch (default_par->riva.Architecture) {
case NV_ARCH_03:
default_par->riva.PRAMIN = (unsigned *)(info->screen_base +
@@ -1767,17 +1778,23 @@
info->par = default_par;
- if (!request_mem_region(rivafb_fix.smem_start,
- rivafb_fix.smem_len, "rivafb")) {
- printk(KERN_ERR PFX "cannot reserve FB region\n");
- goto err_out_free_base0;
- }
+ if (default_par->riva.Architecture != NV_ARCH_03) {
+ /*
+ * Now the _normal_ chipsets can just map the amount of
+ * real physical ram instead of the whole aperture
+ */
+ if (!request_mem_region(rivafb_fix.smem_start,
+ rivafb_fix.smem_len, "rivafb")) {
+ printk(KERN_ERR PFX "cannot reserve FB region\n");
+ goto err_out_free_base0;
+ }
- info->screen_base = ioremap(rivafb_fix.smem_start,
- rivafb_fix.smem_len);
- if (!info->screen_base) {
- printk(KERN_ERR PFX "cannot ioremap FB base\n");
- goto err_out_iounmap_ctrl;
+ info->screen_base = ioremap(rivafb_fix.smem_start,
+ rivafb_fix.smem_len);
+ if (!info->screen_base) {
+ printk(KERN_ERR PFX "cannot ioremap FB base\n");
+ goto err_out_iounmap_ctrl;
+ }
}
#ifdef CONFIG_MTRR
diff -Naur linux-2.5.51/drivers/video/riva/riva_hw.c linux/drivers/video/riva/riva_hw.c
--- linux-2.5.51/drivers/video/riva/riva_hw.c 2002-12-12 13:57:09.000000000 +0000
+++ linux/drivers/video/riva/riva_hw.c 2002-12-12 13:17:40.000000000 +0000
@@ -41,7 +41,7 @@
* GPL licensing note -- nVidia is allowing a liberal interpretation of
* the documentation restriction above, to merely say that this nVidia's
* copyright and disclaimer should be included with all code derived
- * from this source. -- Jeff Garzik <jgarzik@pobox.com>, 01/Nov/99
+ * from this source. -- Jeff Garzik <jgarzik@mandrakesoft.com>, 01/Nov/99
*/
/* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/nv/riva_hw.c,v 1.8 2000/02/08 17:19:11 dawes Exp $ */
@@ -1220,6 +1220,7 @@
state->repaint1 = hDisplaySize < 1280 ? 0x04 : 0x00;
break;
case NV_ARCH_10:
+ case NV_ARCH_20:
nv10UpdateArbitrationSettings(VClk,
pixelDepth * 8,
&(state->arbitration0),
@@ -1285,6 +1286,7 @@
chip->Tri05 = (RivaTexturedTriangle05 *)&(chip->FIFO[0x0000E000/4]);
break;
case NV_ARCH_10:
+ case NV_ARCH_20:
/*
* Initialize state for the RivaTriangle3D05 routines.
*/
@@ -1393,6 +1395,7 @@
chip->PGRAPH[0x0000067C/4] = state->pitch3;
break;
case NV_ARCH_10:
+ case NV_ARCH_20:
LOAD_FIXED_STATE(nv10,PFIFO);
LOAD_FIXED_STATE(nv10,PRAMIN);
LOAD_FIXED_STATE(nv10,PGRAPH);
@@ -1421,15 +1424,31 @@
chip->Tri03 = 0L;
break;
}
- chip->PGRAPH[0x00000640/4] = state->offset0;
- chip->PGRAPH[0x00000644/4] = state->offset1;
- chip->PGRAPH[0x00000648/4] = state->offset2;
- chip->PGRAPH[0x0000064C/4] = state->offset3;
- chip->PGRAPH[0x00000670/4] = state->pitch0;
- chip->PGRAPH[0x00000674/4] = state->pitch1;
- chip->PGRAPH[0x00000678/4] = state->pitch2;
- chip->PGRAPH[0x0000067C/4] = state->pitch3;
- chip->PGRAPH[0x00000680/4] = state->pitch3;
+
+ if (chip->Architecture == NV_ARCH_10) {
+ chip->PGRAPH[0x00000640/4] = state->offset0;
+ chip->PGRAPH[0x00000644/4] = state->offset1;
+ chip->PGRAPH[0x00000648/4] = state->offset2;
+ chip->PGRAPH[0x0000064C/4] = state->offset3;
+ chip->PGRAPH[0x00000670/4] = state->pitch0;
+ chip->PGRAPH[0x00000674/4] = state->pitch1;
+ chip->PGRAPH[0x00000678/4] = state->pitch2;
+ chip->PGRAPH[0x0000067C/4] = state->pitch3;
+ chip->PGRAPH[0x00000680/4] = state->pitch3;
+ } else {
+ chip->PGRAPH[0x00000820/4] = state->offset0;
+ chip->PGRAPH[0x00000824/4] = state->offset1;
+ chip->PGRAPH[0x00000828/4] = state->offset2;
+ chip->PGRAPH[0x0000082C/4] = state->offset3;
+ chip->PGRAPH[0x00000850/4] = state->pitch0;
+ chip->PGRAPH[0x00000854/4] = state->pitch1;
+ chip->PGRAPH[0x00000858/4] = state->pitch2;
+ chip->PGRAPH[0x0000085C/4] = state->pitch3;
+ chip->PGRAPH[0x00000860/4] = state->pitch3;
+ chip->PGRAPH[0x00000864/4] = state->pitch3;
+ chip->PGRAPH[0x000009A4/4] = chip->PFB[0x00000200/4];
+ chip->PGRAPH[0x000009A8/4] = chip->PFB[0x00000204/4];
+ }
chip->PGRAPH[0x00000B00/4] = chip->PFB[0x00000240/4];
chip->PGRAPH[0x00000B04/4] = chip->PFB[0x00000244/4];
chip->PGRAPH[0x00000B08/4] = chip->PFB[0x00000248/4];
@@ -1607,6 +1626,7 @@
state->pitch3 = chip->PGRAPH[0x0000067C/4];
break;
case NV_ARCH_10:
+ case NV_ARCH_20:
state->offset0 = chip->PGRAPH[0x00000640/4];
state->offset1 = chip->PGRAPH[0x00000644/4];
state->offset2 = chip->PGRAPH[0x00000648/4];
@@ -1970,6 +1990,7 @@
nv4GetConfig(chip);
break;
case NV_ARCH_10:
+ case NV_ARCH_20:
nv10GetConfig(chip);
break;
default:
diff -Naur linux-2.5.51/drivers/video/riva/riva_hw.h linux/drivers/video/riva/riva_hw.h
--- linux-2.5.51/drivers/video/riva/riva_hw.h 2002-12-12 13:57:09.000000000 +0000
+++ linux/drivers/video/riva/riva_hw.h 2002-12-12 13:17:42.000000000 +0000
@@ -41,7 +41,7 @@
* GPL licensing note -- nVidia is allowing a liberal interpretation of
* the documentation restriction above, to merely say that this nVidia's
* copyright and disclaimer should be included with all code derived
- * from this source. -- Jeff Garzik <jgarzik@pobox.com>, 01/Nov/99
+ * from this source. -- Jeff Garzik <jgarzik@mandrakesoft.com>, 01/Nov/99
*/
/* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/nv/riva_hw.h,v 1.6 2000/02/08 17:19:12 dawes Exp $ */
@@ -75,6 +75,7 @@
#define NV_ARCH_04 0x04
#define NV_ARCH_10 0x10
#define NV_ARCH_20 0x20
+
/***************************************************************************\
* *
* FIFO registers. *
diff -Naur linux-2.5.51/drivers/video/riva/riva_tbl.h linux/drivers/video/riva/riva_tbl.h
--- linux-2.5.51/drivers/video/riva/riva_tbl.h 2002-12-12 13:57:09.000000000 +0000
+++ linux/drivers/video/riva/riva_tbl.h 2002-12-12 13:17:42.000000000 +0000
@@ -41,7 +41,7 @@
* GPL licensing note -- nVidia is allowing a liberal interpretation of
* the documentation restriction above, to merely say that this nVidia's
* copyright and disclaimer should be included with all code derived
- * from this source. -- Jeff Garzik <jgarzik@pobox.com>, 01/Nov/99
+ * from this source. -- Jeff Garzik <jgarzik@mandrakesoft.com>, 01/Nov/99
*/
/* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/nv/riva_tbl.h,v 1.5 2000/02/08 17:19:12 dawes Exp $ */
^ permalink raw reply
* Re: [PATCH 2.5] SGI O2 framebuffer driver
From: Alan Cox @ 2002-12-12 12:44 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Vivien Chappelier, linux-mips, Ilya Volynets
In-Reply-To: <20021212033307.C22987@linux-mips.org>
On Thu, 2002-12-12 at 02:33, Ralf Baechle wrote:
> The O2 is non-cache coherent. So with the fairly large write-back second
> level caches enabled frame buffer write could potencially be delayed
> indefinately but in any case quite long. Frame buffers are usually only
You can flush the frame buffer pages that were touched at the end of an
operation though
^ permalink raw reply
* ps and free disagree on swap usage
From: James H. Cloos Jr. @ 2002-12-12 11:23 UTC (permalink / raw)
To: linux-kernel
Using procps from cvs at sources.redhat.com, up to date as of
wednesday night.
free(1) says:
total used free shared buffers cached
Mem: 514664 456576 58088 0 31988 173088
-/+ buffers/cache: 251500 263164
Swap: 538136 23016 515120
which looks correct compared to /proc/meminfo.
OTOH, ps(1) (and qps for that matter) show much higher aggregate swap
usage. A couple of intersting lines from ps avxww --forest:
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
1402 ? S 2:29 784 1336 100875 22308 4.3 \_ /usr/X11R6/bin/X :0 vt07 -auth /var/lib/xdm/authdir/authfiles/A:0-PNAkTo
1717 ? S 0:05 2692 454 100353 18608 3.6 \_ kppp
1718 ? S 0:00 34 454 14329 3752 0.7 | \_ kppp
3985 ? S 0:39 13864 785 57238 37040 7.1 \_ /opt/mozilla/mozilla-bin
4718 ? S 0:01 747 204 10219 6348 1.2 \_ xterm -u8
4720 pts/1 S 0:00 392 414 2393 1704 0.3 | \_ bash
plus another 8 or so xterms all with similar DRS vs RSS numbers. Qps
shows results similar to ps.
ps avxww|awk '{print $6 + $7 - $8}'|awk '{i += $1} END {print i}'
returned 470418 just now, when meminfo is claiming:
SwapTotal: 538136 kB
SwapFree: 515120 kB
Is this just a bug in /proc/meminfo?
-JimC
^ permalink raw reply
* Re: [BK PATCH] Dynamic MP_BUSSES and IRQ_SOURCES for 2.4.21-pre1
From: Alan Cox @ 2002-12-12 12:48 UTC (permalink / raw)
To: Greg KH; +Cc: Marcelo Tosatti, Linux Kernel Mailing List
In-Reply-To: <20021212015326.GI16615@kroah.com>
On Thu, 2002-12-12 at 01:53, Greg KH wrote:
> If the machine needs more busses or interrupts, they will be dynamically
> allocated at boot time. If not, the existing MAX_MP_BUSSES and
> MAX_IRW_SOURCES value will be used. Once nice side effect of this patch
> is when running a SMP kernel on a UP machine without a MP table, less
> kernel memory is used than without the patch.
>
> This patch was originally written by James Cleverdon, and has been in
> the -ac tree for quite some time. I also think Red Hat includes it in
> their main kernel, but am not sure.
Its certainly been in some of our trees.
Marcelo this patch hasn't caused any problem reports in -ac for a long
time. I'm all for including it.
^ permalink raw reply
* Re: i4l dtmf errors
From: Matti Aarnio @ 2002-12-12 12:10 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk, Kernel mailing list
In-Reply-To: <200212121145.26108.roy@karlsbakk.net>
This is possibly more of linux-isdn@vger.kernel.org list thing,
than linux-kernel per se.
On Thu, Dec 12, 2002 at 11:45:26AM +0100, Roy Sigurd Karlsbakk wrote:
> hi
>
> it seems isdn4linux detects DTMF tones from normal speach. This is rather
> annoying when using i4l for voice with Asterisk.org. This is tested on all
> recent kernels
>
> see thread "[MGCP] Asterisk/D-Link phones generates ugly DTMF tones!!!" at
> http://www.marko.net/asterisk/archives/ for more info.
Quick reading of drivers/isdn/isdn_audio.c(*) shows that it does use
fixed-point Görtzel (Goertzel in english) algorithm for detecting
tones, but it does _not_ do comparison of received overall signal
power vs. detected DTMF tone powers.
When there is signal power outside the DTMF channels, signal should
not be detected. Also, DTMF tone powers should be roughly equal,
and exactly two tones should be present for valid detection.
http://www.numerix-dsp.com/goertzel.html
Adding those power tests should be fairly trivial, but I leave it
to Somebody Else...
(*) kernel version I looked upon was 2.4.16-0.11custom -- some RH kernel
> roy
> --
> Roy Sigurd Karlsbakk, Datavaktmester
> ProntoTV AS - http://www.pronto.tv/
> Tel: +47 9801 3356
/Matti Aarnio
^ 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.