1 Jan 2003 01:00
1 Jan 2003 01:02
Re: [PATCH] generic device DMA (dma_pool update)
Adam J. Richter <adam <at> yggdrasil.com>
2003-01-01 00:02:17 GMT
2003-01-01 00:02:17 GMT
Andrew Morton wrote:
>The existing mempool code can be used to implement this, I believe. The
>pool->alloc callback is passed an opaque void *, and it returns
>a void * which can point at any old composite caller-defined blob.
That field is the same for all allocations (its value
is stored in the struct mempool), so you can't use it.
David's example would work because it happens to store a copy
of the DMA address in the structure being allocated, and the mempool
code currently does not overwrite the contents of any chunks of memory
when it holds a freed chunk to give to out later.
We could generalize David's technique for other data
structures by using a wrapper to store the DMA address and
adopting the convention of having the DMA allocator initially
stuff the DMA address in the beginning of the chunk being
allocated, like so.
/* Set mempool.alloc to this */
void *dma_mempool_alloc_callback(int gfp_mask, void *mempool_data)
{
struct dma_pool *dma_pool = mempool_data;
dma_addr_t dma_addr;
void *result = dma_pool_alloc(mempool_data, gfp_mask, &dma_addr);
if (result)
memcpy(result, dma_addr, sizeof(dma_addr_t));
return result;
}
(Continue reading)
1 Jan 2003 01:04
BUG REPORT: 2.4.20 System freeze at 00:00:00 Jan 1 2003
Stephan von Krawczynski <skraw <at> ithnet.com>
2003-01-01 00:04:50 GMT
2003-01-01 00:04:50 GMT
Hello all, I am really unsure what to think about the system freeze I just experienced on a very low loaded system: Jan 1 00:00:00 core-2 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008 Jan 1 00:00:00 core-2 kernel: printing eip: Jan 1 00:00:00 core-2 kernel: c0136a7b Jan 1 00:00:00 core-2 kernel: *pde = 00000000 Jan 1 00:00:00 core-2 kernel: Oops: 0000 Jan 1 00:00:00 core-2 kernel: CPU: 0 Jan 1 00:00:00 core-2 kernel: EIP: 0010:[fput+27/304] Not tainted Jan 1 00:00:00 core-2 kernel: EIP: 0010:[<c0136a7b>] Not tainted Jan 1 00:00:00 core-2 kernel: EFLAGS: 00010292 Jan 1 00:00:00 core-2 kernel: eax: f675fee0 ebx: f675fee0 ecx: f62333c0 edx: f600bf4c Jan 1 00:00:00 core-2 kernel: esi: 00000000 edi: fffffe00 ebp: 00000000 esp: f600bf7c Jan 1 00:00:00 core-2 kernel: ds: 0018 es: 0018 ss: 0018 Jan 1 00:00:00 core-2 kernel: Process run-crons (pid: 859, stackpage=f600b000) Jan 1 00:00:00 core-2 kernel: Stack: f6233428 00000000 00000000 f675fee0 fffffe00 00000080 c0135be1 f675eee0 Jan 1 00:00:00 core-2 kernel: bffff9e0 00000080 f675ef00 00000000 00000000 f600a000 00000080 bffff9e0 Jan 1 00:00:00 core-2 kernel: bffff9b8 c010741f 00000003 bffff9e0 00000080 00000080 bffff9e0 bffff9b8 Jan 1 00:00:00 core-2 kernel: Call Trace: [sys_read+241/320] [system_call+51/56] Jan 1 00:00:00 core-2 kernel: Call Trace: [<c0135be1>] [<c010741f>] Jan 1 00:00:00 core-2 kernel: Jan 1 00:00:00 core-2 kernel: Code: 8b 7d 08 ff 48 14 0f 94 c0 84 c0 75 18 8b 5c 24 08 8b 74 24 After this the system was just frozen, I did not see any additional info. Just plain dead. This is kernel 2.4.20. FS is reiser. Distro used is SuSE 8.1. It is a do-nothing system (no load, no plan). Stood there for about 2 months, now crashed on new year wrap... -- --(Continue reading)
1 Jan 2003 01:13
Re: BUG REPORT: 2.4.20 System freeze at 00:00:00 Jan 1 2003
James Stevenson <james <at> stev.org>
2003-01-01 00:13:28 GMT
2003-01-01 00:13:28 GMT
> Jan 1 00:00:00 core-2 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008 > Jan 1 00:00:00 core-2 kernel: printing eip: > Jan 1 00:00:00 core-2 kernel: c0136a7b > Jan 1 00:00:00 core-2 kernel: *pde = 00000000 > Jan 1 00:00:00 core-2 kernel: Oops: 0000 > Jan 1 00:00:00 core-2 kernel: CPU: 0 > Jan 1 00:00:00 core-2 kernel: EIP: 0010:[fput+27/304] Not tainted > Jan 1 00:00:00 core-2 kernel: EIP: 0010:[<c0136a7b>] Not tainted > Jan 1 00:00:00 core-2 kernel: EFLAGS: 00010292 > Jan 1 00:00:00 core-2 kernel: eax: f675fee0 ebx: f675fee0 ecx: f62333c0 edx: f600bf4c > Jan 1 00:00:00 core-2 kernel: esi: 00000000 edi: fffffe00 ebp: 00000000 esp: f600bf7c > Jan 1 00:00:00 core-2 kernel: ds: 0018 es: 0018 ss: 0018 > Jan 1 00:00:00 core-2 kernel: Process run-crons (pid: 859, stackpage=f600b000) > Jan 1 00:00:00 core-2 kernel: Stack: f6233428 00000000 00000000 f675fee0 fffffe00 00000080 c0135be1 f675eee0 > Jan 1 00:00:00 core-2 kernel: bffff9e0 00000080 f675ef00 00000000 00000000 f600a000 00000080 bffff9e0 > Jan 1 00:00:00 core-2 kernel: bffff9b8 c010741f 00000003 bffff9e0 00000080 00000080 bffff9e0 bffff9b8 > Jan 1 00:00:00 core-2 kernel: Call Trace: [sys_read+241/320] [system_call+51/56] > Jan 1 00:00:00 core-2 kernel: Call Trace: [<c0135be1>] [<c010741f>] > Jan 1 00:00:00 core-2 kernel: > Jan 1 00:00:00 core-2 kernel: Code: 8b 7d 08 ff 48 14 0f 94 c0 84 c0 75 18 8b 5c 24 08 8b 74 24 > > After this the system was just frozen, I did not see any additional info. Just plain dead. > This is kernel 2.4.20. FS is reiser. Distro used is SuSE 8.1. It is a do-nothing system (no load, no plan). > Stood there for about 2 months, now crashed on new year wrap... are you able to wind the clock back and reproduce this ? James(Continue reading)
1 Jan 2003 01:27
Re: NIC with polling support
Florian Weimer <Weimer <at> CERT.Uni-Stuttgart.DE>
2003-01-01 00:27:24 GMT
2003-01-01 00:27:24 GMT
Jason Lunz <lunz <at> falooley.org> writes: > Weimer <at> CERT.Uni-Stuttgart.DE said: >> Any suggestions which card I should use? The driver has to be open >> source, and the card shouldn't be too expensive (i.e. in the usual >> price range of brand 100BaseTX NICs). > > linux 2.4.20 supports NAPI for tg3 only. I have patches for e1000, > 3c59x, tulip, and eepro100 at: Thanks, the 3c59x patches are interesting, but they contain a few _very_ discouraging comments.I might give the e100 patches a try, or borrow/buy an e1000 card--does a "PRO/1000 MT Desktop Adapter" do it? If I go the e100 route, does it matter much which chip the card is built around? (The CPU Saver feature seems to be available only on 82558/9, and I haven't found those yet.) -- -- Florian Weimer Weimer <at> CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
1 Jan 2003 01:31
Impact of scheduler tunables on interactive response (was Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio)
scott thomason <scott <at> thomasons.org>
2003-01-01 00:31:29 GMT
2003-01-01 00:31:29 GMT
Around mid-December, Con, rml, & akpm had a discussion about whether
or not the scheduler tunables were a good thing for interactive
responsiveness. Andrew was of the opinion that the interactivity
estimator judged poorly too often and introduced noticeable lags to
the interactive experience. To combat this, he fiddled with the
tunable knobs in an attempt to basicly turn off the interactive
estimation.
I wrote a program that emulates a varying but constant set of loads
with a fixed amount of sleep() time in the hopes that it would appear
"interactive" to the estimator. The program measures the time it
takes to process each iteration (minus the time it spends sleeping).
Then I tried seven different configurations of the tunables while the
system was under load. The kernel was 2.5.53-mm2. The load was a
continuously looping kernel make -j4 clean/make -j4 bzImage, and a
continuously looping copy of a 100MB file. My system is a dual AMD
MP2000 with 1GB RAM.
*IF* the test program is valid--something I would like feedback
on!--the results show that you can attack the background load with
aggressive tunable settings to achieve low interactive response
times, contrary to the direction Andrew had suggested taking for
tunable settings.
The seven tunable configurations, a graph of the results, and the raw
data are here:
http://www.thomasons.org/int_res.html
Tab-delimited text and OpenOffice spreadsheets of the data are here:
(Continue reading)
1 Jan 2003 01:34
Re: NIC with polling support
Florian Weimer <Weimer <at> CERT.Uni-Stuttgart.DE>
2003-01-01 00:34:01 GMT
2003-01-01 00:34:01 GMT
Jason Lunz <lunz <at> falooley.org> writes:
[snip]
Sorry for writing this publicly, but maybe Jason can read it this way:
lunz <at> falooley.org
SMTP error from remote mailer after RCPT TO:<lunz <at> falooley.org>:
host temp123.org [128.61.35.118]: 554 <lunz <at> falooley.org>:
Recipient address rejected: Relay access denied
Jason, you might want to fix this...
--
--
Florian Weimer Weimer <at> CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898
1 Jan 2003 01:50
Re: Oops with 2.4.20 when accessing SVCDs
Marc-Christian Petersen <m.c.p <at> wolk-project.de>
2003-01-01 00:50:13 GMT
2003-01-01 00:50:13 GMT
On Tuesday 31 December 2002 16:36, Kurt Huwig wrote: Hi Kurt, > I got the attached oops when copying a file from a SVCD using cdfs-0.5c > I mounted a SVCD using > mount -t cdfs /dev/cdbrenner /cdbrenner > using the cdfs driver from > http://www.elis.rug.ac.be/~ronsse/cdfs/cdfs.html > Any help would be appreciated. Can you reproduce this w/o cdfs? I've heard alot of problems with cdfs is oopsing and crashing with recent kernels so this might be a problem of cdfs, not the kernel itself. > And a happy new year! thanks, dito :) ciao, Marc
1 Jan 2003 02:17
[BK fbdev updates]
James Simmons <jsimmons <at> infradead.org>
2003-01-01 01:17:16 GMT
2003-01-01 01:17:16 GMT
Happy new year!!! To make several people happy I have more fbdev updates. More bug fixes and more drivers ported to the new api. Things are starting to shape you. Just do a bk pull at bk://fbdev.bkbits.net:8080/fbdev-2.5 The diff is at http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
1 Jan 2003 01:31
Re: [BK fbdev updates]
Dimitrie O. Paun <dpaun <at> rogers.com>
2003-01-01 00:31:24 GMT
2003-01-01 00:31:24 GMT
On December 31, 2002 08:17 pm, James Simmons wrote: > Just do a bk pull at > > bk://fbdev.bkbits.net:8080/fbdev-2.5 > > The diff is at http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz James, What about a diffstat? Come on dude, this a problem _every_single_patch_ :) -- -- Dimi. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
RSS Feed