Well, best to tell kirk and jeffr.
Jeffr wrote the journaling stuff.
.. but I thought they knew there's still problems?
-adrian
On 9 July 2013 17:48, Benjamin Kaduk wrote:
> On Tue, 9 Jul 2013, Adrian Chadd wrote:
>
>> On 9 July 2013 09:24, Eric Camachat wrote:
>>&
On 9 July 2013 09:24, Eric Camachat wrote:
> On Mon, 2013-07-08 at 23:05 -0700, Adrian Chadd wrote:
>> Hi,
>>
>> Try doing a full, non-journal fsck.
>>
>> -adrian
>
> Thank you, it fixed the problem!
> Does it me
Hi all,
I'm doing some -10 i386/amd64 package builds on a 32-core build server running:
FreeBSD vm0.freebsd.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r252897:
Sat Jul 6 23:16:03 UTC 2013
sbr...@vm0.freebsd.org:/usr/obj/usr/src/sys/VM0 amd64
And I hit a deadlock:
Unread portion of the kernel me
Hi,
Try doing a full, non-journal fsck.
-adrian
On 8 July 2013 21:41, Eric Camachat wrote:
> I experienced kernel crashes while make world or ports.
> For example:
> # cd /usr/port/lang/mono
> # make
>
> Will cause the crash, from /var/crash/core.txt:
> eb8460p dumped core - see /var/crash/vm
Hi,
Can you try installing some 10-amd64 snapshots between then and now,
and see roughly when it was introduced?
There's been a lot of ACPI changes over the last 6 months. It wouldn't
surprise me to find one or more of those messed things up.
-adrian
On 5 July 2013 17:14, Erich Dollansky wro
Hi,
I've finally brought up wifi on the Carambola 2 board.
It's an AR9330 SoC with 10/100 ethernet, 64MB RAM, 16MB flash, 1x1
2GHz 11n wifi. It's perfect for embedding into projects to wifi enable
them. It should also make for an awesome cheap 802.11s device.
The details and instructions are her
Hi,
It's (transcribed):
kern.timecounter.hardware: TSC
kern.timecounter.choice: TSC(1000) ACPI-fast (900) HPET (950) i8254
(0) dummy(-1000)
kern.timecounter.tick: 1
kern.timecounter.fast_gettime: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.smp_tsc: 1
kern.timecounter.smp_tsc_adjust: 0
ke
On 20 June 2013 16:45, Adrian Chadd wrote:
> Hi,
>
> I'm having issues with HPET + C3 state on this Atom N450 based
> netbook. This is (shocking, I know!) running -HEAD (r251605.)
>
> If I use C2, HPET is fine.
>
> If I use RTC, i8254, LAPIC, C3 is also fine.
>
On 20 June 2013 16:56, Jeff Roberson wrote:
> Just to add some more information; On my machine with 16GB of ram the
> handful of recent UMA commits save about 20MB of kmem on boot. There are
> 30% fewer buckets allocated. And all of the malloc zones have similar
> amounts of cached space. Act
Hi,
I'm having issues with HPET + C3 state on this Atom N450 based
netbook. This is (shocking, I know!) running -HEAD (r251605.)
If I use C2, HPET is fine.
If I use RTC, i8254, LAPIC, C3 is also fine.
But C3 + HPET results in multi-second pauses where it should be 1 second.
I've disabled power
Please file a PR?
hopefully someone from the USB side of things can help you fix this.
Thanks!
adrian
On 5 June 2013 07:52, Miguel Clara wrote:
> Forgot to CC the list, sorry!
>
> In the meantime I upgrade from 9.1 using the base and kernel tarballs,
> I could boot and I have wireless suppor
Would you guys mind dumping it into a github repo or something, so the
community can test it out?
Adrian
On 30 May 2013 16:48, David Christensen wrote:
>> I'll be glad to test but I'd like to know :
>>
>> - do you require testing on -head or -stable ?
>
> Tested with 9.1 and 10.0-Current. Ope
Sorry, I committed it early this morning without running a make
universe on ref10-amd64.
I've fixed it.
Thanks,
Adrian
On 21 May 2013 05:18, David Wolfskill wrote:
> Got through buildworld; buildkernel stops a bit abruptly:
>
> ...
> --- ar5416_misc.o ---
> clang -c -O -pipe -std=c99 -g -Wa
2013 04:50, Steven Hartland wrote:
> Not sure if you noticed but in the mails I got, there was link to the full
> output
> right at the bottom, so it was fairly easy to find the issue.
>
> - Original Message - From: "Dimitry Andric"
> To: "Adrian Chadd&qu
That was quickly fixed.
Sorry!
adrian
On 19 May 2013 04:58, Konstantin Belousov wrote:
> On Sun, May 19, 2013 at 01:17:54PM +0200, Dimitry Andric wrote:
>> On May 19, 2013, at 04:31, Adrian Chadd wrote:
>> > On 18 May 2013 18:40, FreeBSD Tinderbox wrote:
>> >&
Has anyone noticed how these are not giving out useful info now?
adrian
On 18 May 2013 18:40, FreeBSD Tinderbox wrote:
> TB --- 2013-05-19 00:28:08 - tinderbox 2.10 running on
> freebsd-current.sentex.ca
> TB --- 2013-05-19 00:28:08 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
> FreeB
Hi,
I don't think I've posted this yet, but there's now support for these
NICs in -HEAD:
* AR9380
* AR9390
* AR9580
* AR9590
* AR9562
* QCA9565
The AR933x / AR934x SoC wifi is in -HEAD but it's not yet tidied up
enough to actually work on those SoCs. But it's there.
* What have I tested:
* hos
Yeah, the trouble is that people can/will believe this nonsense.
So, question. Where's the pro-BSD blog(s) to offset it? :)
adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, s
Do it this time without -j6, so we can see where it failed.
adrian
On 27 April 2013 19:27, Steven Hartland wrote:
>
> - Original Message - From: "AN"
> To: "Steven Hartland"
> Cc:
> Sent: Sunday, April 28, 2013 3:20 AM
> Subject: Re: buildkernel fails in zlib (all)
>
>
>
>>
>>
>> O
Hi,
This breaks the ability to compile this stuff on -9.
Like, you know, a bunch of vendors tend to do.
It would have been nice for a quick review cycle when you change
network APIs like this.
Also, since you've changed an API, have you bumped FREEBSD_VERSION ?
This is why I suggested you do i
On 25 April 2013 02:28, Andre Oppermann wrote:
> Again one has to be really careful drawing any firm conclusions from this
> as it was measured on a Pentium4 and UP kernel (GENERIC would add WITNESS
> and INVARIANT overhead as well).
>
> The Pentium4 is about the worst micro-architecture when it
CAn you trace down a rough subversion commit id window between when it
worked and didn't work?
On 22 April 2013 15:50, Shawn Webb wrote:
> Hey All,
>
> I'm on r249745 on amd64. For the past few weeks, my box hasn't been able to
> completely turn off or reboot. The box sits at the console at the
Think you could trace down which kernel commit introduced the
regression? It should be pretty easy if you know the window is only
two weeks long.
Thanks,
Adrian
On 20 April 2013 01:52, O. Hartmann wrote:
> Since a couple of weeks now, FreeBSD 10.0-CURRENT is really unresponsive
> when managin
Hi!
Ok, please update to -HEAD and retest!
adrian
On 19 April 2013 06:26, Adrian Chadd wrote:
> oo good to know! let me setup the chainmask info whether or not
> the 11n option is set.
>
> thanks!
>
>
> adrian
>
> On 19 April 2013 04:08, Artyom Mirgorodskiy
&
_11N - everything work.
>
>
>
>
>
> Artyom Mirgorodskiy
>
>
>
> On Friday 19 April 2013 13:27:21 wrote:
>
> Updated. However I did not see chainmask information.
>
> See attached
>
>
>
> On Friday 19 April 2013 00:57:12 Adrian Chadd wrote:
>
&g
Hi,
I've just committed some changes to -HEAD. Please update to the latest
-HEAD and paste me the ath0 dmesg output.
It will include the chainmask information.
Thanks,
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailma
ursday 18 April 2013 15:22:49 Adrian Chadd wrote:
> Hm! I wonder..
>
> Edit if_athvar.h - change sc_rxchainmask and sc_txchainmask in
> ath_softc to be uint32_t, rather than int.
>
> See if that helps.
>
>
>
> Adrian
>
> On 18 April 2013 15:20, Artyom Mirg
On 18 April 2013 15:54, Artyom Mirgorodskiy
wrote:
> Nothing :(
Ok, so I wonder now whether we're actually getting the right chainmask
at startup.
edit if_ath.c, look for 'ath_hal_getrxchainmask()'
After the rx/tx chainmask is fetched,a dd this:
device_printf(sc->sc_dev, "%s: RX chainmask=0x%x
Hm! I wonder..
Edit if_athvar.h - change sc_rxchainmask and sc_txchainmask in
ath_softc to be uint32_t, rather than int.
See if that helps.
Adrian
On 18 April 2013 15:20, Artyom Mirgorodskiy
wrote:
> See attached
>
>
>
> On Thursday 18 April 2013 15:08:36 Adrian Chadd wr
On 18 April 2013 15:07, Artyom Mirgorodskiy
wrote:
> See attached
>
What the hell? Those masks are really wrong.
Try adding this line after it:
ath_hal_printf(ah, "%s: pcap rx=0x%x, tx=0x%x; configured rx=0x%x,
tx=0x%x\n", __func__, pCap->halRxChainMask, pCap->halTxChainMask,
rx_chainmask, tx_c
On 18 April 2013 14:43, Artyom Mirgorodskiy
wrote:
> Did not work.
>
Hm. Ok.
Let's add some debugging:
inside of ar5416SetChainMasks(), let's add a printf() at the -end- of
the function:
ath_hal_printf(ah, "%s: txchainmask=0x%x, rxchainmask=0x%x\n",
__func__, AH5416(ah)->ah_tx_chainmask, AH541
On 18 April 2013 13:33, Artyom Mirgorodskiy
wrote:
> Yes. I tested 247287 and it breaks.
Hm.
Well, not much changed there.
Try going to 247287 (ie, the broken revision), but revert
head/sys/dev/ath/ath_hal/ar5416/ar5416_xmit.c to 247286.
See if that fixes it.
Adrian
On 18 April 2013 11:58, Artyom Mirgorodskiy
wrote:
> Yes, HEAD everything else except the wifi code (ath).
>
> Last working revision is 247286. So problem in revision 247287.
That's really odd. It behaves perfectly fine on my system.
You've tested 247287 and it breaks?
Adrian
_
Hm, so -HEAD everything else except the wifi code?
That's really odd. I updated to -HEAD this morning just to test the
AR9287 for you and it was peachy!
Adrian
On 18 April 2013 10:36, Artyom Mirgorodskiy
wrote:
> Yes
>
>
>
> On Thursday 18 April 2013 10:30:33 Adrian Chad
3 11:37:17 John Baldwin wrote:
> On Thursday, April 18, 2013 11:22:38 am Adrian Chadd wrote:
> > Ok, the relevant / interesting bit:s. John, any ideas?
>
> Only that this means absolutely nothing? These are the values the BIOS
wrote
> into the registers which we use as hin
... Why would it differ for the same machine, different kernel?
Adrian
Sent from my Palm Pre on AT&T
On Apr 18, 2013 8:40 AM, John Baldwin <j...@freebsd.org> wrote:
On Thursday, April 18, 2013 11:22:38 am Adrian Chadd wrote:
> Ok, the relevant / interesting bit:s. John, any i
Ok, the relevant / interesting bit:s. John, any ideas?
HEAD:
pcib2: irq 18 at device 28.2 on pci0
pcib0: allocated type 3 (0xe050-0xe05f) for rid 20 of pcib2
pcib2: domain0
pcib2: secondary bus 10
pcib2: subordinate bus 10
pcib2: memory decode 0xe050-0xe
gt;
> irq23: ehci0 1037 3
>
> irq256: hpet0:t0 8426 30
>
> irq257: hpet0:t1 1823 6
>
> irq258: hpet0:t2 1992 7
>
> irq259: hpet0:t3 2112 7
>
> irq264: hdac0 118 0
>
> irq265: ahci0 4026 14
>
> Total 20607 75
>
>
>
>
>
> On Thursday 18
Since people keep asking about this; maybe it's time we added a hint
to the bus code that allows for the unit to be set based on the pci
bus / slot / etc.
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
ACER WMI/ACPI? Sure, i'll mentor you if you're going to do _that_.
Adrian
On 15 April 2013 09:55, Cy Schubert wrote:
> I've been planning on taking on IP Filter for quite some time.
> Unfortunately I've left my src commit bit lapse (my ports commit bit is
> alive and well though) thus I'm look
On 9 April 2013 23:28, Lev Serebryakov wrote:
> Hello, John.
> You wrote 10 апреля 2013 г., 0:58:22:
>
>>> Problem is, that every uart device now is independent from each
>>> other in good "OOP" style, and it looks like interrupt sharing we
>>> need one interrupt handler per irq (not per dev
.. assuming you stay _on_ that CPU for the entirety of your runtime
and you don't yield and get rescheduled on another CPU.
Just saying.
adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To u
On 7 April 2013 13:15, Poul-Henning Kamp wrote:
> In message <1428566376.20130407234...@serebryakov.spb.ru>, Lev Serebryakov
> writ
> es:
>
>>It doesn't look so. And uart1 and uart3 doesn't have interrupt
>>according to `vmstat -i' (but share irq4 according to boot messages).
>
> Ohh, the
On 7 April 2013 10:35, Poul-Henning Kamp wrote:
>
> I think if you configure no irq at all, it will automatically
> go to polled mode.
>
> Not sure if uart(4) can actually do that, sio(4) could.
Yup, it does. No IRQ hint == polled mode. It'll say as much in the dmesg.
Adrian
__
On 3 April 2013 11:16, maksim yevmenkin wrote:
> Hi Adrian !
>
> Thank you for your work. I briefly looked at it and it seems fine to me. I'm
> not able to give it a proper review as I'm traveling internationally
> currently. Having said all that, I think it would be reasonable to commit it
>
Hi,
can you guys please ensure a PR is filed with all the information
you've just included?
the clang team would likely love to have this much information in a bug report.
Thanks!
adrian
On 3 April 2013 10:50, Waitman Gobble wrote:
> On Wed, 3 Apr 2013 10:35:47 +0100, "Thomas Sparrevohn"
Hi,
Here you go:
http://people.freebsd.org/~adrian/ath/20130401-ath-bluetooth.diff
The ath3k driver in linux does a fair bit more than ath3kfw:
* if it's a subset of chips that needs firmware, it squirts ath3k-1.fw onto it
* there's a subset of chips that get ROM/RAM patches; so if it's one
of
On 2 April 2013 10:21, Maksim Yevmenkin wrote:
> Hi Adrian,
>
>> Please find a patch which does two things:
>>
>
> patch was lost, apparently :)
Oh for gods sake. God damned mailing list setup.
I'll upload the patch soon.
adrian
___
freebsd-current@
Hi,
Please find a patch which does two things:
* it allows ath3kfw to be given a vendor/productid, in order to load
firmware into other NICs that only have a very basic firmware
(sflash);
* it blacklists all the NICs that have this particular behaviour
(sourced from linux-next btusb.c driver).
I
... damn, this kernel wasn't yet meant to be built. I'll fix that now.
Adrian
On 29 March 2013 12:57, FreeBSD Tinderbox wrote:
> TB --- 2013-03-29 18:54:33 - tinderbox 2.10 running on
> freebsd-current.sentex.ca
> TB --- 2013-03-29 18:54:33 - FreeBSD freebsd-current.sentex.ca8.3-PRERELEASE
... you guys should think about writing an aio_sendfile() function for FreeBSD.
Just saying.
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre
On 28 March 2013 10:26, Poul-Henning Kamp wrote:
> Isn't there some kernel compile-time option to eliminate the huge
> tables used for errormessages etc ?
Yup. It doesn't save all that much in the grand scheme of things.
Doubly so since my secondary size constraint is an 896k partition that
I lz
.. and before you ask - yes, there are embedded boards with limited
RAM that also have ATA ports. :-)
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freeb
On 28 March 2013 09:05, Lev Serebryakov wrote:
> Yes: USB UMASS. It uses CAM too, and useful for very small systems,
> like 4MiB FLASH and 16MiB RAM (yes, whole system image, kernel and
> all, should be packed to 4MiB).
>
> Please note, Adrian speaks about CAM, not only CAM + ATA.
And I
My main concern with the new stuff is that it requires CAM and that's
reasonably big compared to the standalone ATA code.
It'd be nice if we could slim down the CAM stack a bit first; it makes
embedding it on the smaller devices really freaking painful.
Thanks,
adrian
_
grr, another possible fallout from the unmapped io from kib?
Kib?
Adrian
On 21 March 2013 13:58, Joshua Isom wrote:
> I've been helping Adrian test the new ath improvements that support the
> chipset I have. The first kernel panic is on my system if I have the cd
> driver loaded into the ke
On 15 March 2013 11:11, Alfred Perlstein wrote:
> People in my org have been working with NFS and reporting issues for the
> past year. I'm quite certain that Doug White has reported issues due to
> missing certain caching features of the old code.
>
> This is not indicative that newNFS is bad,
On 15 March 2013 09:55, Alfred Perlstein wrote:
> Finally, I think it is really premature to declare a sunset for the oldnfs
> until the users are gushing with approval over the new system.
The flipside to this argument (and coming from you is kind of amusing
:-) is that without any kind of suns
if I break the build again before bsdcan, I promise I'll buy a nice
bottle of scotch and distribute small quantities to developers who
ask.
Adrian
On 9 March 2013 20:38, Adrian Chadd wrote:
> Author: adrian
> Date: Sun Mar 10 04:38:06 2013
> New Revision: 2481
This one was fixed.
Adrian
On 9 March 2013 09:56, FreeBSD Tinderbox wrote:
> TB --- 2013-03-09 16:50:38 - tinderbox 2.10 running on
> freebsd-current.sentex.ca
> TB --- 2013-03-09 16:50:38 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
> FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT
Fixed!
Adrian
On 8 March 2013 20:18, FreeBSD Tinderbox wrote:
> TB --- 2013-03-09 01:30:17 - tinderbox 2.10 running on
> freebsd-current.sentex.ca
> TB --- 2013-03-09 01:30:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
> FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
>
You need to provide much more information than that.
Like, starting with what kind of airport card it is, what the PCI ID is, etc.
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubsc
I'll email later, but I do have two PCI devices show up in pciconf
-lv; but acpi_video() only attaches to one.
I don't know why two PCI devices show up.. guess there's more digging to do.
ADrian
___
freebsd-current@freebsd.org mailing list
http://list
Does Linux run stable with this NIC?
Adrian
On 26 February 2013 02:16, Ian FREISLICH wrote:
> Hi
>
> I have one of these "Advanced" controlers in my laptop. It's up
> for grabs for an interested developer after this coming week-end.
> I need to de-solder the w.FL connectors to to put them on
[101232] acpi_video0: on vgapci0
found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0
And what do I do with acpi_get_handle ?
Adrian
On 25 February 2013 18:23, matt wrote:
> On 02/25/13 18:19, Adrian Chadd wrote:
>>
>> My T400 has:
>>
>
On 25 February 2013 17:53, matt wrote:
> No, just one. I think that the DSDT is very creative on recent Lenovos
> (read: broken). There are multiple video devices defined, with
> "functional" calls that nonetheless don't work to actually do anything.
> The acpi_get_handle() call in acpi_video ret
On 19 February 2013 10:54, Yasir hussan wrote:
> i can`t send u complete patch yet, i will send u main point where i think
> am getting failer, its not bug free code, plz to understand logic
Thanks.
What's the zrouter ar8316 switch driver do?
adrian
___
Do you have any example code that you've written that's failing?
Thanks,
adrian
On 19 February 2013 09:07, Yasir hussan wrote:
> hi,
>
> i am trying to build up vlan feature for chip ar8316 in freebsd, i am yet
> able to make a single defualt vlan which is working properly, where i am
> fail
Try top -HS .. to try and break down the kernel threads.
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On 14 February 2013 13:35, John Baldwin wrote:
> ISA bounces anything above 16GB. They are bouncing. I know it works for some
> people as I fixed a bug in the ISA bounce buffer code somewhat recentish:
You mean 16MB, right?
There's a secondary bounce buffer thing needed for 32 bit PCI devices
On 12 February 2013 04:49, Yasir hussan wrote:
> hi,
>
> is there anyone who knows how i can test vlan feature using *etherswitchcfg*,
> it tried to set and get vlan configuration for chip ar8316 it shows me
> right output like
Hi,
There's no switch support in the arswitch driver at the moment.
On 11 February 2013 09:45, Fabian Keil wrote:
>> You might also want to try MALLOC_PRODUCTION=1 in make.conf. This took
>> my buildworld/buildkernel times from 35/15 minutes to 8/5 minutes,
>> respectively.
>
> I've been using MALLOC_PRODUCTION since before I started collecting
> build times and
.. as long as we can attach/detach keyboards without there actually
_being_ a physical console keyboard at boot, sure.
adrian
On 11 February 2013 04:43, Hans Petter Selasky wrote:
> Hi,
>
> Does anyone need these lines in /etc/devd.conf ?
>
> === etc/devd.conf
> =
... I notice how people haven't quoted how much RAM they have, since
that may influence whether or not things get bounced, double bounced
or such.
Adrian
On 11 February 2013 03:28, C. P. Ghost wrote:
> On Sun, Feb 10, 2013 at 3:55 PM, Poul-Henning Kamp
> wrote:
>>>But I just did an experime
On 10 February 2013 08:44, Steve Kargl
wrote:
> Without it, the build infrastructure was selecting -march=i486,
> which produced even worse results. Several ports would not
> compile because llvm's integrated assembler was given invalid
> assembly constructs.
Have you submitted bugs? :)
Adr
Fixed.
Adrian
On 8 February 2013 02:25, FreeBSD Tinderbox wrote:
> TB --- 2013-02-08 09:22:13 - tinderbox 2.10 running on
> freebsd-current.sentex.ca
> TB --- 2013-02-08 09:22:13 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
> FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
ome.
>
> Thnx to Alexander, Bernhard, Rui and everyone on freebsd-git IRC channel!
> And a special thnx to Adrian Chadd for being my mentor and friend.
>
> Thnx everyone and keep up the great work on net80211!
>
> br,
>
> --
> Monthadar Al Jaberi
> __
You need to dig through the patch and the freebsd tree you're using
and try to figure out where that is defined and why it isn't being
found.
Luis' patch is against -HEAD from a couple years ago, and you're (I
think) trying to patch -9. There's likely some code drift since then..
Adrian
On 7
A switch framework made it into -HEAD.
Adrian
On 5 February 2013 22:44, Yasir hussan wrote:
> Hi,
>
> I saw a report that covers FreeBSD-related projects between October and
> December 2010 and I observe that it have new patch for Ethernet Switch
> Framework, I have also seen a little bit ins
Someone needs to pick that porting effort up, polish/finish it up, and
get it into FreeBSD.
I'm happy to commit whatever people agree to tidy up and maintain.
Thanks,
Adrian
On 1 February 2013 04:52, Thomas Mueller wrote:
> From Andrey Fesenko :
>
>> NDIS failed to raise working version. Win
Ah, the historical difference between shutdown -r and reboot
adrian
On 22 January 2013 09:59, Gleb Smirnoff wrote:
> On Tue, Jan 22, 2013 at 02:03:12PM +0100, Olivier Cochard-Labb? wrote:
> O> There are only 2 useable tools by "operator" group members:
> O> shutdown (and its child: poweroff
It wasn't listed anywhere in the documentation / wiki. I only found it
after I had posted that patch.
eg:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-gdb.html
I had to do a whole lot of searching to finally discover that particular option.
And yes, it
Also, I found 'set remotebaud' and 'set debug remote 1' to do this.
I'd like to add the code just to support the same -b flag as gdb (so
-r can also be used with a non-standard serial port.)
Thanks,
Adrian
On 15 January 2013 21:15, Adrian Chadd wrote:
> Hi,
&g
Hi,
There doesn't seem to be a blessed way to set the baudrate from inside
gdb/kgdb. It seems to be set from '-b' on the command line.
However kgdb doesn't have this support.
This patch adds -b support so kgdb so I can override the default speed
(9600 it seems) to speak kgdb over serial to a 115
Ok,
So everyone - what _could_ be brought into -HEAD right now, without
any actual change in code behaviour?
eg, what kind of refactoring could be done to reduce the amount of
diffs between the branch and -HEAD?
Adrian
___
freebsd-current@freebsd.org
... ath_ahb is only needed for MIPS platforms. Why are you building it for x86?
Also, do you have the 5416 support option in your kernel?
adrian
On 4 January 2013 20:37, Super Bisquit wrote:
> In sys/modules/svr4 needs machine/_align.h to read
> X86/include/_align.h, if that means anything.
>
.. I'm pretty damned sure we're going to need to enforce a "never
earlier than X" latency.
Is there a more detailed writeup of calloutng somewhere, besides
David's slides? The wiki page is rather empty.
Eg - I think this work does coalesce wakeups, right? Or it can? So
when in low-power scenarios
.. not that I mind old things being retired, but we really should
announce things like this.
Also - you disconnected libftpio too; is that intentional?
Just because libdisk/libftpio isn't used by anything in the base -HEAD
doesn't mean that:
* it's not used by third party programs in ports;
* it
odules/ath/../../dev/ath/ath_hal/ah.c:65:
>>warning:
>>>>dereferencing 'void *' pointer
>>>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: error:
>>>>request for member 'sc_ifp' in something not a structure or union
>>&
instructions whenever you can.
>>>
>>> Thank you very much!
>>>
>>>>
>>>>Hi,
>>>>
>>>>Ok. I'm travelling for a little bit; if I don't reply in a few
>>>>days,
>>>>please poke me again.
>>
>>Thanks,
>>
>>
>>Adrian
>>
>>>
>>> attached to this e-mail you find the output of dmesg. What I
>>guess the most relevant lines could be is:
>>>
>>> ath0: mem 0xfdee0000-0xfdee irq 16 at device
>>4.0 on pci2
>>&g
Personally, I'd rather see some consistently used units here..
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On 16 December 2012 23:57, Andriy Gapon wrote:
>
> Thank god that this feature was developed in a branch, it was developed for a
> long period of time and there were people who routinely reviewed and tested
> (and
> really used) it. And yeah, its design was announced and discussed well in
> adva
On 16 December 2012 18:31, Garrett Cooper wrote:
>> Would you mind approaching some of the cluster peeps and seeing if
>> they'll run this up on the ref10* boxes and VMs, just to get some
>> further exposure?
>
> And maybe tinderbox..?
Tinderbox is a great idea.
Maybe hit up the altq/pf using c
On 16 December 2012 15:37, Alexander Motin wrote:
> Hi.
>
> Here is one more version. Unless something new will be found/reported this
> may be the last one, because me and Davide are quite satisfied with the
> results. If everything will be fine, I think we could commit it to HEAD
> closer to the
ume working again.
>
>
> On Sat, 15 Dec 2012, Adrian Chadd wrote:
>
>> Hi,
>>
>> jkim - is there any negative side-effect from reverting r231797 ? Did
>> this fix a bug you saw on another platform?
>>
>> I have the same symptom on my T40
Hi,
jkim - is there any negative side-effect from reverting r231797 ? Did
this fix a bug you saw on another platform?
I have the same symptom on my T400, unfortunately it's in the office
and I can't get to it right now to test.
Thanks,
Adrian
___
fr
ghput) is.
802.11ac is adding "VHT" (very high throughput) rates, so expect
ifconfig to grow vht information shortly.
Adrian
On 15 December 2012 08:03, Fbsd8 wrote:
>
>> Adrian
>>
>> On 12 December 2012 17:39, Andrey Fesenko wrote:
>>>
>>> O
Hi,
Can you please test with MIPS? David has a MIPS board now.
Can you also test that various performance tests haven't been
affected? Eg, do iperf tests through that MIPS board, configured up as
an AP.
Please test with a bunch of disk IO activity too.
I know this is a lot to ask for, but I'd h
to make sure the values still are
> the same, which indeed they are.
>
> I hope this helps.
>
> Thanks!
>
> On Donnerstag, 13. Dezember 2012 at 10:18 PM, "Adrian Chadd"
> wrote:
>>
>>On 13 December 2012 13:11, wrote:
>>> Hello everyone,
701 - 800 of 1259 matches
Mail list logo