headers
Blair Sadewitz | 1 Apr 2007 20:09
Picon

Re: drm on amd64

This is exactly the same problem I had on amd64; I've since switched
to i386 (for reasons other than drm; linux compatability on amd64 for
EMT64 processors is broken).  Could you file a PR for this, please?

Thanks,

--Blair

--

-- 
Support WFMU-FM: free-form radio for the masses!
<http://www.wfmu.org/>

"The frivolity and boredom which unsettle the established order, the
vague foreboding of something unknown, these are the heralds of
approaching change.  The gradual crumbling that left unaltered the
face of the whole is cut short by a sunburst which, in one flash,
illuminates the features of the new world."  --G.W.F. Hegel,
_Phenomenology of Spirit_ 5:11
Permalink | Reply | 0 comments |
headers
Manuel Bouyer | 1 Apr 2007 22:12

Re: ACPI and invalid devices

On Fri, Mar 30, 2007 at 02:50:08PM -0400, Todd Kover wrote:
> db{0}> trace 
> cpu_Debugger(c097fca3,c0b927b4,c0b927a8,c048c525,e) at netbsd:cpu_Debugger+0x4
> panic(c09555a4,c38c0480,c0b927d8,c0464b1f,c0a9ef82) at netbsd:panic+0x155
> free(c38c0480,c0a4ca00,c0b92858,c051fd1c,c38c0480) at netbsd:free+0x1de
> AcpiOsFree(c38c0480,c0a014a0,2,c3db1f20,c3db1f20) at netbsd:AcpiOsFree+0x1a
> mpacpi_pcibus_cb(c3db1660,2,c3d0f300,0,1000000) at netbsd:mpacpi_pcibus_cb+0xfc
> AcpiNsWalkNamespace(6,c3db1e00,64,1,c051fc20) at netbsd:AcpiNsWalkNamespace+0xde
> 
> AcpiWalkNamespace(6,c3db1e00,64,c051fc20,c3d0f300) at netbsd:AcpiWalkNamespace+0
> x7e
> mpacpi_find_interrupts(c3d0f300,43b8c9,18,c3d0f358,c3d0f300) at netbsd:mpacpi_fi
> nd_interrupts+0x789
> acpi_md_callback(c3d0f300,c076eea0,c3d0f358,c38c0f10,1) at netbsd:acpi_md_callba
> ck+0x67
> acpi_attach(c38a4f80,c3d0f300,c0b92b3c,0,c0b92b3c) at netbsd:acpi_attach+0x176
> config_attach_loc(c38a4f80,c09f5480,0,c0b92b3c,0) at netbsd:config_attach_loc+0x
> 156
> config_found_ia(c38a4f80,c093e296,c0b92b3c,0,c3821f40) at netbsd:config_found_ia
> +0x32
> mainbus_attach(0,c38a4f80,0,c047f6be,c093d799) at netbsd:mainbus_attach+0x1c1
> config_attach_loc(0,c09f3db8,0,0,0) at netbsd:config_attach_loc+0x156
> config_attach(0,c09f3db8,0,0,c0b8f010) at netbsd:config_attach+0x2c
> config_rootfound(c093d799,0,c0b92c28,c0480ebf,c0a020a0) at netbsd:config_rootfou
> nd+0x44    
> cpu_configure(c0a020a0,a,0,0,c0aa44f0) at netbsd:cpu_configure+0x27
> configure(c0aa0d80,1,0,0,ffff) at netbsd:configure+0x2f
> main(fbff,c01002d2,0,0,0) at netbsd:main+0x115

Well, it works fine for me on a pe2950, with both i386 and amd64 GENERIC
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edgar Fuß | 2 Apr 2007 18:54
Picon
Favicon

install problems on RAID

I'm probably making some absolutely stupid mistake.
I've done this several times before and it worked, but maybe it was either 3.0 or /i386.
I've spent most of the day trying to install (4.0_BETA2) via network onto a RAID1 and the <beep> sysinst
insists on installing an MBR onto the RAID proper. Of course, this makes all the partitions move by 63
sectors and the primary boot not finding the secondary one.
Have there been any recent "improvements" in sysinst to keep people from not installing an MBR? I tried for
two hours tricking sysinst into not writing the MBR, but to no avail. Also, I'm not allowed to delete the
<beep> c partition from the disklabel in sysinst. So, even if I manage to make the partitions start at 0,
after writing the label, newfs on the root fs fails because it can't write block 32.
As I started, I'm probably making some entirely stupid mistake, but I don't know what it is.
Permalink | Reply | 4 comments |
headers
Edgar Fuß | 2 Apr 2007 21:11
Picon
Favicon

Re: install problems on RAID

So I just checked, it seems I've not gone mad.
The installer behaves differently for amd64 and i386.
For i386, it skips the "edit MBR/use entire disk" step and goes straight
to the disklabel step after I've chosen the sets to install.

OK, probably this will fix it (I'm not sure whether the names ar OK,
I just copied from i386):

--- distrib/utils/sysinst/arch/amd64/md.h.orig	2006-02-26 11:25:52.000000000 +0100
+++ distrib/utils/sysinst/arch/amd64/md.h	2007-04-02 20:43:16.000000000 +0200
 <at>  <at>  -73,6 +73,14  <at>  <at> 
 #define SET_KERNEL_GENERIC	SET_KERNEL_1

 /*
+ * Disk names accepted as valid targets for a from-scratch installation.
+ *
+ * On amd64, we allow "wd"  ST-506/IDE disks,  "sd" scsi disks, "ld" logical
+ * disks, "ed" IBM ESDI disks, "raid" raidframe disks
+ */
+#define DISK_NAMES "wd", "sd", "ld", "ed", "raid:no_mbr", "xbd:no_mbr"
+
+/*
  * Machine-specific command to write a new label to a disk.
  * For example, i386  uses "/sbin/disklabel -w -r", just like i386
  * miniroot scripts, though this may leave a bogus incore label.
Permalink | Reply | 3 comments |
headers
Xning Lee | 5 Apr 2007 15:45

Re: drm on amd64 (drmMap failed)

Xning Lee <xning <at> soforge.com> writes:

> "Blair Sadewitz" <blair.sadewitz <at> gmail.com> writes:
>
>> This is exactly the same problem I had on amd64; I've since switched
>> to i386 (for reasons other than drm; linux compatability on amd64 for
>> EMT64 processors is broken).  Could you file a PR for this, please?
>>
>> Thanks,
>>
>
> The issue of 'drmMap failed' on amd64 because the function
> 'udv_attach' of /usr/src/sys/uvm/uvm_device.c can't accept address
> offset value more than 4GB: (the type of 'voff_t' is int64)
               ^^^^^^^^^^^^^
correct: more than 0x7fffffffffffffff

Regards,

--Xning
Permalink | Reply | 0 comments |
headers
Xning Lee | 5 Apr 2007 15:08

Re: drm on amd64 (drmMap failed)

"Blair Sadewitz" <blair.sadewitz <at> gmail.com> writes:

> This is exactly the same problem I had on amd64; I've since switched
> to i386 (for reasons other than drm; linux compatability on amd64 for
> EMT64 processors is broken).  Could you file a PR for this, please?
>
> Thanks,
>

The issue of 'drmMap failed' on amd64 because the function
'udv_attach' of /usr/src/sys/uvm/uvm_device.c can't accept address
offset value more than 4GB: (the type of 'voff_t' is int64)

struct uvm_object *
udv_attach(void *arg, vm_prot_t accessprot,
    voff_t off,	        /* used only for access check */
    vsize_t size	/* used only for access check */)
{
        ...

	if (off < 0)
		return(NULL);
        ...
}

When I changed the type of parameter 'off' from 'voff_t' to
'vsize_t'(u_long), 'drm on amd64' can work now.

Xorg.0.log:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Antti Kantee | 5 Apr 2007 18:36
Picon
Picon

swapcontext: preserve r12 & r13

Hello,

puffs was reported to not work on amd64 if libpuffs was compiled without
optimization flags.  I tracked this down to r12 getting clobbered when
doing a swapcontext() dance and memory accesses based on that register
being a bit off afterwards.  I managed to make it work, but could someone
eye the patch over, as I have zero knowledge of x86.

Please cc replies, as I'm not on the list.

Index: swapcontext.S
===================================================================
RCS file: /cvsroot/src/lib/libc/arch/x86_64/gen/swapcontext.S,v
retrieving revision 1.3
diff -u -r1.3 swapcontext.S
--- swapcontext.S       1 Dec 2004 01:08:18 -0000       1.3
+++ swapcontext.S       5 Apr 2007 16:25:05 -0000
 <at>  <at>  -48,28 +48,26  <at>  <at> 
  */

 ENTRY(swapcontext)
-       pushq   %r12
-       pushq   %r13
-       movq    %rdi,%r12               /* preserve oucp */
-       movq    %rsi,%r13               /* preserve ucp */
+       pushq   %rdi                    /* preserve oucp */
+       pushq   %rsi                    /* preserve ucp */
 #ifdef PIC
        call    PIC_PLT(_C_LABEL(_getcontext))
 #else
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Thomas | 6 Apr 2007 04:59

Re: drm on amd64 (drmMap failed)

Xning Lee wrote:
> "Blair Sadewitz" <blair.sadewitz <at> gmail.com> writes:
> 
>> This is exactly the same problem I had on amd64; I've since switched
>> to i386 (for reasons other than drm; linux compatability on amd64 for
>> EMT64 processors is broken).  Could you file a PR for this, please?
>>
>> Thanks,
>>
> 
> The issue of 'drmMap failed' on amd64 because the function
> 'udv_attach' of /usr/src/sys/uvm/uvm_device.c can't accept address
> offset value more than 4GB: (the type of 'voff_t' is int64)

This is going to be, ultimately, a sign extension problem.  I'm guessing
that line 176 in drm_ioctl.c would show that the address being passed in
has already been sign-extended.

if ((voff_t)(vaddr_t)request.offset < 0)
   printf("drm_getmap: invalid offset %"PRIx64"\n",
    (voff_t)(vaddr_t)request.offset);

So the question is where it happened.  Have fun finding it. :)
Permalink | Reply | 0 comments |
headers
Xning Lee | 6 Apr 2007 08:17

Re: drm on amd64 (drmMap failed)

Matt Thomas <matt <at> 3am-software.com> writes:

> Xning Lee wrote:
>> "Blair Sadewitz" <blair.sadewitz <at> gmail.com> writes:
>>
>>> This is exactly the same problem I had on amd64; I've since switched
>>> to i386 (for reasons other than drm; linux compatability on amd64 for
>>> EMT64 processors is broken).  Could you file a PR for this, please?
>>>
>>> Thanks,
>>>
>>
>> The issue of 'drmMap failed' on amd64 because the function
>> 'udv_attach' of /usr/src/sys/uvm/uvm_device.c can't accept address
>> offset value more than 0x7fffffffffffffff: (the type of 'voff_t' is int64)
>
> This is going to be, ultimately, a sign extension problem.  I'm guessing
> that line 176 in drm_ioctl.c would show that the address being passed in
> has already been sign-extended.
>

that because at line 190 in drm_bufs.c, the address
value('map->handle') that retured by 'malloc' has been more than
0x7fffffffffffffff, then at line 197 in drm_bufs.c:

		map->offset = (unsigned long)map->handle;
Permalink | Reply | 0 comments |
headers
Juan RP | 6 Apr 2007 17:33

Re: puffs/refuse on amd64 ?

On Thu, 5 Apr 2007 15:42:11 +0300
Antti Kantee <pooka <at> netbsd.org> wrote:

> Hi,
> 
> Seems like a function argument register is not correctly restored after
> swapcontext().  Before I figure out what's the cause, you can compile
> libpuffs with -O0, which uses the stack and does not suffer from this
> register mutation problem.

Ok... I tried your patch and seems to work fine (I tried psshfs).

Thank you!

--

-- 
http://plog.xtrarom.org/
Juan RP's blog - NetBSD/pkgsrc news in Spanish
Permalink | Reply | 0 comments |

Gmane