Re: i386 Go programs crash on amd64

2014-05-29 Thread Peter Jeremy 
On 2014-May-29 04:38:18 +0300, Konstantin Belousov  wrote:
>Hm, I think I know what is going on.  Try this, please.
>At least, your test binary worked for me.

Thank you.  That seems to fix the problem even on non-trivial code.

-- 
Peter Jeremy


pgpr5A3Ze7NEI.pgp
Description: PGP signature

Re: i386 Go programs crash on amd64

2014-05-28 Thread Peter Jeremy 
On 2014-May-26 16:44:57 +0300, Konstantin Belousov  wrote:
>On Mon, May 26, 2014 at 09:36:22PM +1000, Peter Jeremy wrote:
>> On 2014-May-24 10:41:01 +0300, Konstantin Belousov  
>> wrote:
>> >> >Provide the minimal test case.
>> >> 
>> >> The following go program, compiled on i386 and run on amd64 will die
>> >> with a segmentation violation or bus error:
>> >> ---
>> >> package main
>> >> 
>> >> import "fmt"
>> >> 
>> >> func main() {
>> >> fmt.Println("Hello World")
>> >> }
>> >> ---
>> >No, this is not consumable.
>> >
>> >I need a self-contained minimal example written in C/asm.
>> 
>> Actually, I've found that
>> 
>> package main
>> import "syscall"
>> func main() { syscall.Write(1, []byte("Hello World\n")) }
>> 
>> also crashes ~66 syscalls after the first sysarch(2) call.  That
>> reduces the binary to 520K (go reports this is 50K lines of assembler).
>> 
>> >If this is too hard to produce, give the the self-contained
>> >binary, again as small as possible (small by comparing the
>> >number of syscalls before the issue manifests itself).
>> 
>> I've uploaded the source, binary and disassembly to
>> freefall:~peterj/write{.go,,.S} (and verified it crashes).
>> 
>> If I get time, I'll see if I can strip some of the support code out of
>> Go to shrink it further.
>
>What exactly do you mean by 'crashing' ?

I see it dying with either SIGBUS or SIGSEGV.  On freefall, I see:
freefall% ./write 
zsh: segmentation fault (core dumped)  ./write

> I see some spills from (probably) Go runtime.

I've tried further experiments with different hardware and different
loading and get different results: Sometimes I get nothing other than
a coredump and an other times I get part or all of a runtime spill
similar to you.  I suspect there may be multiple issues.

> I am not sure that this is something which should
>be looked at from the kernel side, at least initially.

As I wrote in my initial mail, I am not certain whether this is a problem
with Go or FreeBSD.  And having done some poking at corefiles with gdb
(you need gdb7.6 from ports to grok the Go debug information), I have
found that all my programs are dying at:
    mov    %gs:0xfff8,%ecx
but it seems to be timing related as to when the offending instruction
is executed.  I will do some further investigation into how segment
wraparound is handled.

> E.g., the 32bit
>binaries on amd64 have stack starting near the top of the address space,
>i.e. 4G - some amount. Could this be a problem for the Go ?

That seems unlikely but I guess it's a possibility.

-- 
Peter Jeremy


pgpfkvhsnfJdL.pgp
Description: PGP signature

Re: i386 Go programs crash on amd64

2014-05-26 Thread Peter Jeremy 
On 2014-May-24 10:41:01 +0300, Konstantin Belousov  wrote:
>> >Provide the minimal test case.
>> 
>> The following go program, compiled on i386 and run on amd64 will die
>> with a segmentation violation or bus error:
>> ---
>> package main
>> 
>> import "fmt"
>> 
>> func main() {
>> fmt.Println("Hello World")
>> }
>> ---
>No, this is not consumable.
>
>I need a self-contained minimal example written in C/asm.

Actually, I've found that

package main
import "syscall"
func main() { syscall.Write(1, []byte("Hello World\n")) }

also crashes ~66 syscalls after the first sysarch(2) call.  That
reduces the binary to 520K (go reports this is 50K lines of assembler).

>If this is too hard to produce, give the the self-contained
>binary, again as small as possible (small by comparing the
>number of syscalls before the issue manifests itself).

I've uploaded the source, binary and disassembly to
freefall:~peterj/write{.go,,.S} (and verified it crashes).

If I get time, I'll see if I can strip some of the support code out of
Go to shrink it further.

-- 
Peter Jeremy


pgp4BZhTk0VMY.pgp
Description: PGP signature

Re: i386 Go programs crash on amd64

2014-05-23 Thread Peter Jeremy 
On 2014-May-24 02:34:44 +0300, Konstantin Belousov  wrote:
>On Fri, May 23, 2014 at 04:28:34PM -0700, Peter Wemm wrote:
>> On 5/23/14, 4:22 PM, Peter Wemm wrote:
>> > On 5/23/14, 3:53 PM, Peter Jeremy wrote:
>> >> I've been playing with Go (lang/go) and found that i386 Go binaries
>> >> segfault when run on amd64 (9.x, 10.x or HEAD).  I've narrowed it down
>> >> to the LDT handling but am not sure whether it's on the FreeBSD or Go
>> >> side.
>> >>
>> >> As far as I can see, the i386 binary is correctly calling i386_set_ldt()
>> >> and the i386_set_ldt() emulation in the amd64 kernel matches the i386
>> >> kernel - but the net result doesn't work.
>> >>
>> >> Can anyone offer any suggestions as to how to resolve this?
>Provide the minimal test case.

The following go program, compiled on i386 and run on amd64 will die
with a segmentation violation or bus error:
---
package main

import "fmt"

func main() {
fmt.Println("Hello World")
}
---

>> >>
>> > We don't emulate i386_set_ldt().
>> >
>> > The 32 bit version of libc on amd64 has a different implementation 
>> > that calls sysarch(I386_SET_FSBASE, ..) and friends.  Normally this is 
>> > handled transparently by static linking, but obviously that's an issue 
>> > for Go.
>> 
>> Actually, that's an even more interesting question. WHY are they using 
>> i386_set_ldt()?  Where is it coming from? As near as I can tell, libc, 
>> libthr etc call I386_SET_GSBASE for tls.

As installed, the code is in /usr/local/go/src/pkg/runtime/sys_freebsd_386.s
"runtime·setldt", which calls "runtime·i386_set_ldt" which uses "int 128".

>We do support ldt for 32bit binaries on amd64.

I thought it was supported.

-- 
Peter Jeremy


pgphxCH3P7xDq.pgp
Description: PGP signature

i386 Go programs crash on amd64

2014-05-23 Thread Peter Jeremy 
I've been playing with Go (lang/go) and found that i386 Go binaries
segfault when run on amd64 (9.x, 10.x or HEAD).  I've narrowed it down
to the LDT handling but am not sure whether it's on the FreeBSD or Go
side.

As far as I can see, the i386 binary is correctly calling i386_set_ldt()
and the i386_set_ldt() emulation in the amd64 kernel matches the i386
kernel - but the net result doesn't work.

Can anyone offer any suggestions as to how to resolve this?

-- 
Peter Jeremy


pgpd4HbpQ_ZOU.pgp
Description: PGP signature

Re: amd64/171250: ldd32 cannot find some i386 libraries

2012-09-04 Thread Peter Jeremy 
The following reply was made to PR amd64/171250; it has been noted by GNATS.

From: Peter Jeremy 
To: Konstantin Belousov 
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/171250: ldd32 cannot find some i386 libraries
Date: Tue, 4 Sep 2012 21:40:56 +1000

 --45Z9DzgjV8m4Oswq
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On 2012-Sep-03 12:30:19 +, Konstantin Belousov  wr=
 ote:
 > I have a symphathy to the idea that ld-elf32.so.1 should translate well-k=
 nown
 > pathes from DT_RPATH into their 32bit compat synonims. That is, /lib and
 > /usr/lib probably should be interpreted as /lib32 and /usr/lib32.
 
 That sounds like a good idea to me as well.
 
 > On the other hand, I do not know what to do with non-default pathes,
 > that is /usr/local/lib in your case. Please note that some library can
 > be find there for many reasons, and I cannot imagine a sane way to
 > translate to 32bit compat path without involving some additional config.
 
 My suggestion is that we define /usr/local/lib32 as a standard
 directory (and wire it into ld-elf32.so.1 in the same wap as /lib &
 /usr/lib) and extend /etc/libmap32.conf to define directory name
 mappings as well as dynamic object mappings to handle cases where
 LOCALBASE is not /usr/local and non-standard library directories.
 
 > This is closely related to non-existent multiarch support in ports, which
 > cannot even start happens without working cc -m32.
 
 I would disagree on this point.  There's no reason why we need a working
 "cc -m32" in order to pkg_add an i386 package on an amd64 system.  I
 notice there was some discussion regarding multi-arch ports on -current
 in late March.
 
 > I think your PR shall be postponed instead of being closed.
 
 Agreed.
 
 --=20
 Peter Jeremy
 
 --45Z9DzgjV8m4Oswq
 Content-Type: application/pgp-signature
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.19 (FreeBSD)
 
 iEYEARECAAYFAlBF6MgACgkQ/opHv/APuId21ACgpl5kkWT6T5Lu7qSOJX8m+ZlU
 KvYAn2S1P4xrvZlZJBrxXwfJE6NUBQEl
 =+9H6
 -END PGP SIGNATURE-
 
 --45Z9DzgjV8m4Oswq--
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"

Re: The intel "X520-4 154d 82599EB 10-Gigabit SFP+" ethernet controllerdoesn't work

2012-08-27 Thread Peter Jeremy 
Hi Guozhong,

Can you please provide the PCI ID for the card.  This is reported via
"pciconf -lv"

-- 
Peter Jeremy


pgpGbAJT1hFet.pgp
Description: PGP signature

Re: amd64/167543: Install FreeBSD can show error message with config 256G DIMM.

2012-05-23 Thread Peter Jeremy 
The following reply was made to PR amd64/167543; it has been noted by GNATS.

From: Peter Jeremy 
To: kunlin_ch...@wistron.com
Cc: gordon_ys_c...@wistron.com, janus_y...@wistron.com,
freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/167543: Install FreeBSD can show error message with config
 256G DIMM.
Date: Wed, 23 May 2012 19:29:57 +1000

 --XsQoSWH+UP9D9v3l
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 Hi Kunlin,
 
 On 2012-May-23 09:36:32 +0800, kunlin_ch...@wistron.com wrote:
 >Is there any progress?
 
 Sorry, I got sidetracked.  Unfortunately, you haven't provided any
 information that would allow me to investigate the problem further.
 
 Can you please provide more details of your hardware configuration.
 
 What motherboard & chipset is this?  Please provide a verbose boot log
 and indicate which device(s) you were installing from and to.
 
 You indicate that you can install FreeBSD 9.0 with 240GB RAM.  Can
 you please do so and then do a verbose boot and post the boot log
 (/var/run/dmesg.boot once you get to multi-user) and the output
 =66rom "kenv".
 
 --=20
 Peter Jeremy
 
 --XsQoSWH+UP9D9v3l
 Content-Type: application/pgp-signature
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.19 (FreeBSD)
 
 iEYEARECAAYFAk+8rhUACgkQ/opHv/APuIeMKACfZtuLvFKram07kNY7gH0oC9oU
 ENsAoLvW4qbFSJTQ87+9ZooM4zhk6pOH
 =qox1
 -END PGP SIGNATURE-
 
 --XsQoSWH+UP9D9v3l--
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"

Re: amd64/167543: Install FreeBSD can show error message with config 256G DIMM.

2012-05-03 Thread Peter Jeremy 
The following reply was made to PR amd64/167543; it has been noted by GNATS.

From: Peter Jeremy 
To: Kunlin Cheng 
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/167543: Install FreeBSD can show error message with config
 256G DIMM.
Date: Fri, 4 May 2012 07:08:48 +1000

 --0F1p//8PRICkK4MW
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On 2012-May-03 02:12:20 +, Kunlin Cheng  wrot=
 e:
 >>Environment:
 >CPU:Intel chip 2.4GHz *2
 >DIMM:Hynix 16G 1333MHz *16
 
 Can you please provide more details of your hardware configuration.
 What motherboard & chipset is this?  Are you able to provide a verbose
 boot log and indicate which device(s) you were installing from and to.
 
 --=20
 Peter Jeremy
 
 --0F1p//8PRICkK4MW
 Content-Type: application/pgp-signature
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.19 (FreeBSD)
 
 iEYEARECAAYFAk+i8+AACgkQ/opHv/APuIeSpQCgwnBORoOj3aBkKm8h02aw4tGv
 ef0AoJdpm8PdpVsOSUzfb/12W2pnrQLF
 =oIEi
 -END PGP SIGNATURE-
 
 --0F1p//8PRICkK4MW--
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"

Re: amd64/162708: FreeBSD 9.0-RC2 amd64 fails to boot on Dell Optiplex GX620

2011-11-22 Thread Peter Jeremy 
The following reply was made to PR amd64/162708; it has been noted by GNATS.

From: Peter Jeremy 
To: "David J. Weller-Fahy" ,
John Baldwin 
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/162708: FreeBSD 9.0-RC2 amd64 fails to boot on Dell
 Optiplex GX620
Date: Wed, 23 Nov 2011 14:41:50 +1100

 --/NkBOFFp2J2Af1nK
 Content-Type: multipart/mixed; boundary="qMm9M+Fa2AknHoGS"
 Content-Disposition: inline
 
 
 --qMm9M+Fa2AknHoGS
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On 2011-Nov-20 23:57:40 +, "David J. Weller-Fahy"  wrote:
 >When trying to boot from the FreeBSD ISO at ftp://ftp.freebsd.org/pub/Free=
 BSD/releases/amd64/amd64/ISO-IMAGES/9.0/FreeBSD-9.0-RC2-amd64-dvd1.iso I am=
  unable to boot with ACPI enabled or disabled.
 
 I've tried a source upgrade of a GX620 te RELENG_9_0 without problems
 so this would appear to be associated with the DVD boot.  If I get the
 opportunity, I'll download a DVD and try booting it.
 
 >#v+
 >..
 >pcib0: matched entry for 0.29.INTA
 >pcib0: slot 29 INTA hardwired to IRQ 21
 >pcib0: allocated type 3 (0xdf70-0xdf7003ff) for rid 10 of pci0:0:29:7
 >unknown: Lazy allocation of 0x400 bytes rid 0x10 type 3 at 0xdf70
 >#v-
 
 This is different to what I see at this point and a bit more context
 would be useful.
 
 Note that pci0:0:29:7 is:
 ehci0@pci0:0:29:7:  class=3D0x0c0320 card=3D0x01ad1028 chip=3D0x27cc808=
 6 rev=3D0x01 hdr=3D0x00
 vendor =3D 'Intel Corporation'
 device =3D 'N10/ICH 7 Family USB2 EHCI Controller'
 class  =3D serial bus
 subclass   =3D USB
 
 In my boot, it should be followed by pci0:0:30:0:
 pcib4@pci0:0:30:0:  class=3D0x060401 card=3D0x chip=3D0x244e808=
 6 rev=3D0xe1 hdr=3D0x01
 vendor =3D 'Intel Corporation'
 device =3D '82801 PCI Bridge'
 class  =3D bridge
 subclass   =3D PCI-PCI
 
 A verbose dmesg is attached.
 
 --=20
 Peter Jeremy
 
 --qMm9M+Fa2AknHoGS
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="dmesg.boot"
 Content-Transfer-Encoding: quoted-printable
 
 Table 'FACP' at 0xfd34f
 Table 'SSDT' at 0xfffd8815
 Table 'APIC' at 0xfd443
 APIC: Found table at 0xfd443
 APIC: Using the MADT enumerator.
 MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
 SMP: Added CPU 0 (AP)
 MADT: Found CPU APIC ID 1 ACPI ID 2: enabled
 SMP: Added CPU 1 (AP)
 MADT: Found CPU APIC ID 6 ACPI ID 3: disabled
 MADT: Found CPU APIC ID 7 ACPI ID 4: disabled
 Copyright (c) 1992-2011 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
 FreeBSD 9.0-RC2 #0: Wed Nov 23 08:56:39 EST 2011
 r...@c2b0004103.au.alcatel-lucent.com:/var/obj/mnt/usr/src/sys/GENERIC =
 amd64
 Table 'FACP' at 0xfd34f
 Table 'SSDT' at 0xfffd8815
 Table 'APIC' at 0xfd443
 Table 'BOOT' at 0xfd4b5
 Table 'ASF!' at 0xfd4dd
 Table 'MCFG' at 0xfd544
 Table 'HPET' at 0xfd582
 Table 'SSDT' at 0x7fe86c40
 Table 'SSDT' at 0x7fe87049
 Table 'SSDT' at 0x7fe87452
 ACPI: No SRAT table found
 Preloaded elf kernel "/boot/kernel/kernel" at 0x813d8000.
 Preloaded elf obj module "/boot/kernel/vkbd.ko" at 0x813d81f8.
 Calibrating TSC clock ... TSC clock: 319215 Hz
 CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3192.15-MHz K8-class CPU)
   Origin =3D "GenuineIntel"  Id =3D 0xf43  Family =3D f  Model =3D 4  Stepp=
 ing =3D 3
   Features=3D0xbfebfbff
   Features2=3D0x649d
   AMD Features=3D0x20100800
   TSC: P-state invariant
 real memory  =3D 2147483648 (2048 MB)
 Physical memory chunk(s):
 0x1000 - 0x0009bfff, 634880 bytes (155 pages)
 0x0010 - 0x001f, 1048576 bytes (256 pages)
 0x01407000 - 0x7c220fff, 2061606912 bytes (503322 pages)
 avail memory =3D 2043473920 (1948 MB)
 Event timer "LAPIC" quality 400
 ACPI APIC Table: 
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP/HT): APIC ID:  1
 APIC: CPU 0 has ACPI ID 1
 APIC: CPU 1 has ACPI ID 2
 x86bios:  IVT 0x00-0x0004ff at 0xfe00
 x86bios: SSEG 0x001000-0x001fff at 0xff800020d000
 x86bios: EBDA 0x09f000-0x09 at 0xfe09f000
 x86bios:  ROM 0x0a-0x0fefff at 0xfe0a
 ULE: setup cpu 0
 ULE: setup cpu 1
 ACPI: RSDP 0xfeb00 00024 (v02 DELL  )
 ACPI: XSDT 0xfd257 00074 (v01 DELLGX620   0007 ASL  0061)
 ACPI: FACP 0xfd34f 000F4 (v03 DELLGX620   0007 ASL  0061)
 ACPI: DSDT 0xfffd4952

Re: amd64/155135: Does Not Boot On a Very Standard Hardware

2011-03-02 Thread Peter Jeremy 
The following reply was made to PR amd64/155135; it has been noted by GNATS.

From: Peter Jeremy 
To: John 
Cc: bug-follo...@freebsd.org
Subject: Re: amd64/155135: Does Not Boot On a Very Standard Hardware
Date: Thu, 3 Mar 2011 07:44:08 +1100

 --gBBFr7Ir9EOA20Yy
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On 2011-Feb-28 22:49:13 +, John  wrote:
 >I have pretty much standard computer hardware. Nothing exotic. Just C2D
 >with Intel chipset (ICH8) and NV 8400M GT.
 
 Can you please describe the hardware and BIOS you are using:  What
 brand/model of motherboard, what BIOS?  I presume you are booting
 off a physical DVD - in which case, where is the drive attached?
 
 > I attach "lshw" in html for easier reading.
 
 I'm not sure why you think that embedding 70kB of HTML into an
 otherwise plaintext report makes anything easier.  And note that it
 contains virtually no useful information for these purposes.
 
 >Description: After a bunch of code, and loading something from DVD, I am p=
 resented for 3s with some options, i.e. the "bootloader choice". Shouldn't =
 it be the other way? First show me what I want to load, and then I chose wh=
 at to load, and after my choice the system loads? Why is it the other way r=
 ound? Every Linux distro does this.
 >
 >Should be:
 >
 >1.Load the options
 >2.Chose the option from install/live/this kernel/that kernel/this desktop =
 environment/ that desktop environment etc.
 >3.Then load what I have chosen.
 >4.Load the system
 
 Feel free to discuss the philosophy of loading and booting Unix
 kernels on an appropriate mailing list.  See=20
 http://www.freebsd.org/cgi/man.cgi?query=3Dboot&sektion=3D8 and
 http://www.freebsd.org/cgi/man.cgi?query=3Dloader&sektion=3D8 for a
 description of what actually happens.
 
 >Is:
 >1.Something loads, arrow is spinning...
 >2still loading...
 >3."bootloader choice" appears for 3s
 >4.I hit enter (I chose 1st option if I am that fast to catch that 3s gap)
 >5.The system restarts the computer
 
 It's not clear what you mean by "bootloader choice" - this name does
 not appear in the boot code and your description of the load sequence
 doesn't make it clear which point in the load sequence you are
 referring to.  Can you please advise exactly what is displayed and
 what the 1st choice actually is.  Are you able to setup a serial
 console to capture the actual output?  If not, are you able to post a
 photo?
 
 >>How-To-Repeat:
 >study the lshw output.
 
 Contains no relevant information.
 
 > Something is not right with the BSD kernel.
 
 If my interpretation of your description is correct, the kernel hasn't
 even been loaded so this seems unlikely.
 
 --=20
 Peter Jeremy
 
 --gBBFr7Ir9EOA20Yy
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.15 (FreeBSD)
 
 iEYEARECAAYFAk1urBgACgkQ/opHv/APuId6fwCfRU1tGkQNnYwM39Qftv7SEG+b
 Lh0AnAz+11X/qlHAErOG7DyCz5T4PuaZ
 =66P0
 -END PGP SIGNATURE-
 
 --gBBFr7Ir9EOA20Yy--
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"

Re: firefox constantly loads one CPU core to 100%

2010-11-26 Thread Peter Jeremy 
On 2010-Nov-26 08:46:53 +0200, Zeus V Panchenko  wrote:
>i'm trying to understand, why firefox loads one core constantly up to
>100% and even more ...

Possibly https://bugzilla.mozilla.org/show_bug.cgi?id=595823

Unfortunately, there's no fix shown.  I had a similar problem in
conjunction with the NoScript plugin but turning off NoScript ->
Options -> ABE -> "WAN IP (???) ε LOCAL" fixed the problem.

-- 
Peter Jeremy


pgpO8SCz7VZMk.pgp
Description: PGP signature

Re: why does UATA/133 == UATA/100 on amd64?

2010-06-04 Thread Peter Jeremy 
On 2010-Jun-04 16:36:08 -0700, fbsdm...@dnswatch.com wrote:
> After _finally_ making the correct decisions to install amd64 on an
>AMD64 system. I was able to make/build/install world && kernel, I see
>a difference in drive recognition.

Can you please do a verbose boot and post the resultant dmesg somewhere
(preferably with your USB DVD drive connected).

>kernel: ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire
>kernel: ad6: 476940MB  at ata3-master SATA300

>kernel: ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire
>kernel: ad6: setting UDMA100
>kernel: ad6: 476940MB  at ata3-master UDMA100
>SATA 3Gb/s

The 'UDMA' numbers are meaningless for SATA controllers/drives.

-- 
Peter Jeremy


pgpGLveheDDu9.pgp
Description: PGP signature

Re: When will the amd64 be supported?

2010-06-04 Thread Peter Jeremy 
On 2010-Jun-04 10:04:11 +0100, Pete French  wrote:
>> That seems to be overcomplicating things a bit, but yes.. the general
>> strategy would be something along those lines.
>
>Am curious that you think it's overcomplicating matters - can you think
>of a way of doing it with only one drive ? That the simplest procedure
>I amnaged to come up with when migrating machine from 32 to 64. As
>I;ve got a few which still need ding then any simpler method is of
>great interest (especially one which doesnt require a 2nd drive!)

In theory, you should be able to just steal a disk partition - swap
being the most obvious:  Disable swap, newfs it and mount it as /mnt,
install kernel and world into it and configure it as root.  Reboot
onto /mnt (manually specify the 'b' partition to boot1) and do an
installkernel/world onto your original partitions then reboot back
into them.

It might be slightly quicker and easier to dump/restore your existing
i386 root (and minimal parts of /usr) into /mnt, boot into it and the
just do a single installkernel/world onto your original partitions.
I'm not sure of the exact parts of /usr that will be necessary.

Keep in mind that you'll need to rebuild all your ports as soon as
you rebuild any.  And anything that gets too chummy with the kernel
innards won't work until it's rebuilt.

Some time ago, I did manage to do an in-place amd64 to i386 conversion
(and revert using a ZFS snapshot).

-- 
Peter Jeremy


pgp5w172cield.pgp
Description: PGP signature