http://www.netbsd.org/~ad/pmap.diff Is there anything wrong with this? Have I missed a case where we can avoid an invalidation? Thanks, Andrew
On Tuesday 03 June 2008 15:37:44 Andrew Doran wrote: > http://www.netbsd.org/~ad/pmap.diff > > Is there anything wrong with this? Have I missed a case where we can > avoid an invalidation? In pmap_free_ptp() I don't see where you initialize invaladdr2. To me, this looks like using an uninitialized variable. Christoph
On Tue, Jun 03, 2008 at 04:01:20PM +0200, Christoph Egger wrote: > On Tuesday 03 June 2008 15:37:44 Andrew Doran wrote: > > http://www.netbsd.org/~ad/pmap.diff > > > > Is there anything wrong with this? Have I missed a case where we can > > avoid an invalidation? > > In pmap_free_ptp() I don't see where you initialize invaladdr2. > To me, this looks like using an uninitialized variable. I made that change after testing it; the remove_all bit does work well though. Thanks, Andrew
On Tue, Jun 03, 2008 at 03:01:43PM +0100, Andrew Doran wrote: > On Tue, Jun 03, 2008 at 04:01:20PM +0200, Christoph Egger wrote: > > > On Tuesday 03 June 2008 15:37:44 Andrew Doran wrote: > > > http://www.netbsd.org/~ad/pmap.diff > > > > > > Is there anything wrong with this? Have I missed a case where we can > > > avoid an invalidation? > > > > In pmap_free_ptp() I don't see where you initialize invaladdr2. > > To me, this looks like using an uninitialized variable. > > I made that change after testing it; the remove_all bit does work well > though. It occured to me that remote invalidations can also be deferred. Updated diff: http://www.netbsd.org/~ad/pmap2.diff Andrew
Andrew Doran wrote: > On Tue, Jun 03, 2008 at 03:01:43PM +0100, Andrew Doran wrote: > >> On Tue, Jun 03, 2008 at 04:01:20PM +0200, Christoph Egger wrote: >> >>> On Tuesday 03 June 2008 15:37:44 Andrew Doran wrote: >>>> http://www.netbsd.org/~ad/pmap.diff >>>> >>>> Is there anything wrong with this? Have I missed a case where we can >>>> avoid an invalidation? >>> In pmap_free_ptp() I don't see where you initialize invaladdr2. >>> To me, this looks like using an uninitialized variable. >> I made that change after testing it; the remove_all bit does work well >> though. > > It occured to me that remote invalidations can also be deferred. Updated > diff: > > http://www.netbsd.org/~ad/pmap2.diff From my scant knowledge of x86 pmap it looks ok. In pmap_tlb_shootdown, can the test be moved further up the file? Everything before it looks to only effect local variables. I've one query, which is more due to my lack of knowledge about how -current kernel works, than the change. Is there ever a risk that an lwp might not complete the removal, eg, fast soft interrupts, which borrow the lwp on leaving an interrupt. If one of them starts a pmap_remove_all which then gets blocked (taking a lock in the UVM(Continue reading)
Hi, is anyone using cdrecord on amd64 ? I'm having troubles getting it working with a DVD writer on amd64. The drive reports error like "illegal request", or sometimes it looks like the command doesn't even make it to the drive. While building cdrecord I've seen some warnings about "cast from pointer to integer of different size", so I suspect some LP64 issues here. -- -- Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer <at> lip6.fr NetBSD: 26 ans d'experience feront toujours la difference --
On Thu, 5 Jun 2008 13:04:03 +0200 Manuel Bouyer <bouyer <at> antioche.eu.org> wrote: > Hi, > is anyone using cdrecord on amd64 ? I'm having troubles getting it > working with a DVD writer on amd64. The drive reports error like "illegal > request", or sometimes it looks like the command doesn't even make it > to the drive. While building cdrecord I've seen some warnings about > "cast from pointer to integer of different size", so I suspect some > LP64 issues here. I am using cdrecord for CDRs and growisofs for DVDRs on my ===> lars <at> laphroaig:~ %dmesg | grep cd cd0 at atapibus0 drive 0: <HL-DT-ST DVDRAM GSA-4081B, K2I41CG5459, A100> cdrom removable cd0: 32-bit data port cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33) cd0(jmide1:0:0): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33) (using DMA) running NetBSD/amd64 -current. It usually works fine. I have however been able to lock the machine solidly when writing both CDRWs and DVDR/DVDRWs. I am still trying to understand why (interrupt issue? even mouse pointer stalls in X), but I think it is a separate problem. This behaviour started a couple of weeks ago. Best regards, Lars(Continue reading)
On Thu, 5 Jun 2008, Lars Nordlund wrote: > I have however been able to lock the machine solidly when writing both > CDRWs and DVDR/DVDRWs. I am still trying to understand why (interrupt > issue? even mouse pointer stalls in X), but I think it is a separate > problem. This behaviour started a couple of weeks ago. I've seen the same on my Thinkpad T61 with various media -- it ends up writing media that locks up the machine while trying to read it. I just assumed the drive had failed after one too many plane rides: cd0 at atapibus0 drive 0: <HL-DT-ST DVDRAM GSA-U10N, KZ076SE5954, 1.05> cdrom removable Glad I'm not the only one :) Cheers, Jared
On Thu, Jun 05, 2008 at 01:04:03PM +0200, Manuel Bouyer wrote: > Hi, > is anyone using cdrecord on amd64 ? I'm having troubles getting it > working with a DVD writer on amd64. The drive reports error like "illegal > request", or sometimes it looks like the command doesn't even make it > to the drive. While building cdrecord I've seen some warnings about > "cast from pointer to integer of different size", so I suspect some > LP64 issues here. Hum, I can burn CDs on this box, so it's either an issue with my DVD burner in DVD mode, or a LP64 issue in some DVD-specific code of cdrecord ... -- -- Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer <at> lip6.fr NetBSD: 26 ans d'experience feront toujours la difference --
On Thu, Jun 05, 2008 at 01:04:03PM +0200, Manuel Bouyer wrote: > is anyone using cdrecord on amd64 ? I'm having troubles getting it > working with a DVD writer on amd64. The drive reports error like "illegal > request", or sometimes it looks like the command doesn't even make it > to the drive. While building cdrecord I've seen some warnings about > "cast from pointer to integer of different size", so I suspect some > LP64 issues here. I think it's not amd64 specific. I can't get the cdrtools package to work, but this one works for me: cdrtools-ossdvd-2.01.1.36nb2 Andrew
RSS Feed12 | |
|---|---|
2 | |
1 | |
13 | |
18 | |
10 | |
19 | |
6 | |
11 | |
11 | |
10 | |
25 | |
36 | |
1 | |
22 | |
12 | |
32 | |
28 | |
15 | |
13 | |
6 | |
19 | |
46 | |
12 | |
7 | |
11 | |
10 | |
28 | |
6 | |
7 | |
1 | |
1 | |
19 | |
26 | |
16 | |
33 | |
4 | |
7 | |
16 | |
25 | |
9 | |
20 | |
16 | |
19 | |
20 | |
18 | |
17 | |
34 | |
10 | |
24 | |
92 | |
41 | |
58 | |
133 | |
43 | |
54 | |
27 | |
35 | |
51 | |
74 | |
33 | |
51 | |
50 | |
86 | |
117 | |
76 | |
51 | |
33 | |
61 | |
25 | |
43 | |
24 | |
52 | |
104 | |
57 | |
34 | |
27 | |
20 | |
38 | |
56 | |
115 | |
74 | |
22 | |
43 | |
43 | |
109 | |
80 | |
133 | |
62 | |
52 | |
31 | |
110 | |
61 | |
96 | |
86 | |
29 | |
41 | |
66 | |
67 | |
51 | |
51 | |
39 | |
21 | |
13 | |
10 | |
18 | |
41 | |
21 | |
46 | |
66 | |
42 | |
20 | |
24 | |
51 | |
56 | |
14 | |
2 | |
7 | |
12 | |
1 | |
2 |
