John Bradford | 1 Jan 01:00 2003

(unknown)

Happy new year!

Do you think will we be working on 2.7 by this time next year?

John.
Adam J. Richter | 1 Jan 01:02 2003

Re: [PATCH] generic device DMA (dma_pool update)

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)

Stephan von Krawczynski | 1 Jan 01:04 2003

BUG REPORT: 2.4.20 System freeze at 00:00:00 Jan 1 2003

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)

James Stevenson | 1 Jan 01:13 2003

Re: BUG REPORT: 2.4.20 System freeze at 00:00:00 Jan 1 2003

> 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)

Florian Weimer | 1 Jan 01:27 2003
Picon

Re: NIC with polling support

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
scott thomason | 1 Jan 01:31 2003

Impact of scheduler tunables on interactive response (was Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio)

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)

Florian Weimer | 1 Jan 01:34 2003
Picon

Re: NIC with polling support

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
Marc-Christian Petersen | 1 Jan 01:50 2003
Picon

Re: Oops with 2.4.20 when accessing SVCDs

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
James Simmons | 1 Jan 02:17 2003

[BK fbdev updates]


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

Dimitrie O. Paun | 1 Jan 01:31 2003

Re: [BK fbdev updates]

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

Gmane