5 Jul 2011 00:38
18 Jul 2011 01:21
Apple USB Ethernet A1277
Mark Benson <markbenson <at> mac.com>
2011-07-17 23:21:52 GMT
2011-07-17 23:21:52 GMT
Hi, I am using 5.1-current and need to know if it's possible to use a Apple A1277 USB ethernet dongle. It's not recognised by the OS, but is supposed to be supported by the Axe USB ethernet driver. Is the 5.1-current axe drive out of date, if so is there a way of using a newer version without re-installing? -- -- Mark Benson My Blog: <http://markbenson.org/blog> Follow me on Twitter: http://twitter.com/mdbenson "Never send a human to do a machine's job..."
18 Jul 2011 01:33
Re: Apple USB Ethernet A1277
Bernd Ernesti <netbsd <at> lists.veego.de>
2011-07-17 23:33:31 GMT
2011-07-17 23:33:31 GMT
Hi, On Mon, Jul 18, 2011 at 12:21:52AM +0100, Mark Benson wrote: > Hi, > > I am using 5.1-current and need to know if it's possible to use a Apple A1277 USB ethernet dongle. It's not recognised by the OS, but is supposed to be supported by the Axe USB ethernet driver. Is the 5.1-current axe drive out of date, if so is there a way of using a newer version without re-installing? [long line not wrapped] It may be that you just need to add the vendor and product id in the driver and compile a new kernel but without knowing the numbers it is hard to tell if that would work. Bernd
18 Jul 2011 08:20
Re: Apple USB Ethernet A1277
Mark Benson <md.benson <at> gmail.com>
2011-07-18 06:20:30 GMT
2011-07-18 06:20:30 GMT
On 18 Jul 2011, at 00:33, Bernd Ernesti wrote: > Hi, > > It may be that you just need to add the vendor and product id in the driver > and compile a new kernel but without knowing the numbers it is hard to tell > if that would work. ugen0 at uhub4 port 1 ugen0: vendor 0x05ac product 0x1402, rev 2.00/0.01, addr 3 That's what I get from dmesg. Is that any help? -- -- Mark Benson My Blog: <http://markbenson.org/blog> Follow me on Twitter: http://twitter.com/mdbenson "Never send a human to do a machine's job..."
19 Jul 2011 07:33
Re: Apple USB Ethernet A1277
Bernd Ernesti <netbsd <at> lists.veego.de>
2011-07-19 05:33:19 GMT
2011-07-19 05:33:19 GMT
On Mon, Jul 18, 2011 at 07:20:30AM +0100, Mark Benson wrote: > > On 18 Jul 2011, at 00:33, Bernd Ernesti wrote: > > > Hi, > > > > It may be that you just need to add the vendor and product id in the driver > > and compile a new kernel but without knowing the numbers it is hard to tell > > if that would work. > > ugen0 at uhub4 port 1 > ugen0: vendor 0x05ac product 0x1402, rev 2.00/0.01, addr 3 > > That's what I get from dmesg. Is that any help? Yes. I can send you a patch if I get the time later this week. It is just a matter of adding these numbers (actually the values from usbdevs.h, USB_PRODUCT_APPLE_ETHERNET and USB_VENDOR_APPLE) into the driver source. I need to check the status of the support for axe on the netbsd-5 branch because I do not know if everything is on that branch. Bernd
19 Jul 2011 08:21
Re: Apple USB Ethernet A1277
Mark Benson <md.benson <at> gmail.com>
2011-07-19 06:21:58 GMT
2011-07-19 06:21:58 GMT
On 19 Jul 2011, at 06:33, Bernd Ernesti wrote: > Yes. I can send you a patch if I get the time later this week. > It is just a matter of adding these numbers (actually the values from usbdevs.h, > USB_PRODUCT_APPLE_ETHERNET and USB_VENDOR_APPLE) into the driver source. > I need to check the status of the support for axe on the netbsd-5 branch because > I do not know if everything is on that branch. Thank you, that would be most helpful :) I took a look at the kernel sources last night and axe is configured by default in the GENERIC kernel config, so I guess like you say it needs patching to include the Apple device. -- -- Mark Benson My Blog: <http://markbenson.org/blog> Follow me on Twitter: http://twitter.com/mdbenson "Never send a human to do a machine's job..."
20 Jul 2011 03:43
Re: sometimes resumeable freeze
Jonathan A. Kollasch <jakllsch <at> kollasch.net>
2011-07-20 01:43:12 GMT
2011-07-20 01:43:12 GMT
Following up, It turns out that this issue is caused by the 8259 PICs not being masked in IOAPIC mode, causing spurious interrupts in conjunction with real ones. I should get a PR filed soon. On Tue, Apr 12, 2011 at 01:17:32AM +0000, Jonathan A. Kollasch wrote: > Hi, > > My quad core AMD box has an issue where it will lock up under load. > > Often, when the machine is otherwise unresponsive, I'll press > Num Lock on the pckbd(4) and it will awaken at the point in time > it went comatose. Eventually, pressing num lock doesn't bring it > back and I have to force a reboot. > > If I `cpuctl offline` ¾ of the CPUs the machine is acceptably stable. > The machine is also acceptably stable under Linux with all cores > enabled and performing a similar workload (build.sh release). > > acpicpu(4) is present in the kernel and I have verified that C1E > is not enabled. The machine was significantly less stable when > C1E was enabled. > > I've tried to wire in a Conventional PCI SERR# trigger, but > the chipset doesn't propagate that into an NMI and I lack > details on the chipset required to enable that if possible. > > Can anyone think of ways to debug this issue? >(Continue reading)
21 Jul 2011 02:40
i387 rounding mode and long double support
Joerg Sonnenberger <joerg <at> britannica.bec.de>
2011-07-21 00:40:49 GMT
2011-07-21 00:40:49 GMT
Hi all, at the moment i386 and amd64 force the FPU into IEEE double precision rounding mode by default. The assumption is that most float operations are using double and this gives consistent results independent of compiler optimisations. Whether this makes sense on i386 is outside the scope of this mail. I do question the use for AMD64 though, because normal float and double operations are done using the SSE units (at least for any compiler that cares about performance), with the primary exception being the transcendent. Since I need long double support to ease porting libc++, it would be nice to have it actually work properly out of the box -- with the full precision. Is it reasonable to alter the default rounding mode on AMD64 for 64bit processes to extended precision? The alternative would be to either accept that long double doesn't actually have the advertised mantissa length or require all programs dealing with long double values to change the float environment themselve. Neither seems very attractive. Joerg
21 Jul 2011 10:36
Re: i387 rounding mode and long double support
Martin Husemann <martin <at> duskware.de>
2011-07-21 08:36:16 GMT
2011-07-21 08:36:16 GMT
On Thu, Jul 21, 2011 at 02:40:49AM +0200, Joerg Sonnenberger wrote: > precision. Is it reasonable to alter the default rounding mode on AMD64 > for 64bit processes to extended precision? IMHO this is the way to go. Might cause minor fallout, but I don't expect much (if even noticable). Martin
21 Jul 2011 21:53
Re: i387 rounding mode and long double support
Matthias Drochner <M.Drochner <at> fz-juelich.de>
2011-07-21 19:53:20 GMT
2011-07-21 19:53:20 GMT
joerg <at> britannica.bec.de said: > i386 and amd64 force the FPU into IEEE double precision > rounding mode > [...] > I do question the use for AMD64 though, because > normal float and double operations are done using the SSE units I had thought about that too. If we can be sure that the compiler really does no "double" arithmetics in the x87 (except transcendent functions etc where we don't have exact promises about accuracy anyway), this would be feasible. You might have a look at the release notes of gcc-4.5 - the section about -std=c99 and floating point performance. The gcc developers have apparently realized that an x87 in long mode doesn't give standards conform rounding. Their workaround is to issue a store+load to a "double" memory variable after each operation. This kills performance, but not for us, with x87 in "double" mode. (needs some definition in gcc's config, didn't commit it yet) > The alternative would be to > either accept that long double doesn't actually have the advertised mantissa > length FreeBSD deals with that, see the TARGET_96_ROUND_53_LONG_DOUBLE definition in gcc. Anyway, this stays a tradeoff between "double" speed and accuracy on one side and "long double" mantissa length on the other.(Continue reading)
RSS Feed