On Wed, Feb 25, 2009 at 11:06:45PM -0600, Matthew D. Fuller wrote:
> On Wed, Feb 25, 2009 at 10:47:07PM -0500 I heard the voice of
> Steve Wills, and lo! it spake thus:
> >
> > re0: > Gigabit Ethernet> port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3f,
> > 0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 o
On Thursday 26 February 2009 16:29:18 Ian Smith wrote:
> > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
> > sio1: type 16550A
> > sio1: [FILTER]
> >
> > However the ports do work fine.
>
> The last 3 lines of each show success, despite earlier prevarication.
Yes, but the
On Thu, 26 Feb 2009, Daniel O'Connor wrote:
> I have an amd64 7.1 install on a SuperMicro C2SBA+ and I see the following
> in
> dmesg..
>
> sio0: configured irq 4 not in bitmap of probed irqs 0
> sio0: port may not be enabled
> sio0: configured irq 4 not in bitmap of probed irqs 0
> sio0
On Feb 25, 2009, at 11:27 PM, Pyun YongHyeon wrote:
On Wed, Feb 25, 2009 at 11:15:38PM -0500, Steve Wills wrote:
[...]
I guess re(4) thinks it lost established link. How about unplug and
then replug UTP cable? Would you show me "devinfo -rv | grep phy"?
rgephy0 pnpinfo oui=0x732 model=0x11 r
On Wed, Feb 25, 2009 at 10:47:07PM -0500 I heard the voice of
Steve Wills, and lo! it spake thus:
>
> re0: Gigabit Ethernet> port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3f,
> 0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8
> re0: Chip rev. 0x2800
> re0: MAC rev. 0x0010
For a data point
On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote:
> I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor.
> It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1
>
> Typically, It works for a while until eventually it stalls data
> transfers completely. It always seem
I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor.
It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1
Typically, It works for a while until eventually it stalls data
transfers completely. It always seems to do this after an unspecified
amount of time.
I know the hardware isn
On Wed, Feb 25, 2009 at 11:15:38PM -0500, Steve Wills wrote:
[...]
> >I guess re(4) thinks it lost established link. How about unplug and
> >then replug UTP cable? Would you show me "devinfo -rv | grep phy"?
>
> rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1
>
And unpluging/repluging d
On Feb 25, 2009, at 11:10 PM, Pyun YongHyeon wrote:
I get 3 link state DOWN/UP notices when DHCP client starts. It works
That's normal(Technically this is not correct behavior but it's the
way how it was implemented in driver).
Ok. Not a huge deal, but would be nice to fix, of course.
for e
On Wed, Feb 25, 2009 at 10:47:07PM -0500, Steve Wills wrote:
> On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote:
> >I need more information for your hardware revision.
> >Would you show me dmesg output and revision number of if_re.c?
>
> I assume you only need the re0 related output. If you need
On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote:
I need more information for your hardware revision.
Would you show me dmesg output and revision number of if_re.c?
I assume you only need the re0 related output. If you need the full
dmesg, let me know.
re0: Gigabit Ethernet> port 0x7e00-0x
I have an amd64 7.1 install on a SuperMicro C2SBA+ and I see the following in
dmesg..
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3
On Wed, 25 Feb 2009, Robert Watson wrote:
Just a minor heads up: I've merged both Kip Macy's lock order fixes to the
kernel routing code, and the route locking and reference counting fixes from
kern/130652 to stable/7. These fixes should correct a number of reported
network-related hangs. We
On Mon, Feb 23, 2009 at 12:54:12PM +0100, Oliver Brandmueller wrote:
> Hi,
>
> On Fri, Feb 13, 2009 at 08:39:55PM +0900, Pyun YongHyeon wrote:
> > Ok, try attached patch.
>
> > Index: sys/dev/re/if_re.c
> > ===
> > --- sys/dev/re/if_
On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote:
> Hi,
>
> I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after
> booting, re0 works for only a short time, then gives "re0: PHY read
> failed" over and over. Does anyone have a suggestion on how to debug?
>
I need more
On Tuesday 24 February 2009 6:11:15 pm John Baldwin wrote:
> Author: jhb
> Date: Tue Feb 24 23:11:15 2009
> New Revision: 189017
> URL: http://svn.freebsd.org/changeset/base/189017
>
> Log:
> Fix some more issues with the real mode BTX.
>
> The old BTX passed the general purpose registers f
On Wed, Feb 25, 2009 at 11:04:29AM +, Robert Watson wrote:
> On Wed, 25 Feb 2009, Pete French wrote:
>
> >> FYI, I'm currently awaiting testing results from Pete on the MFC of a
> >> number of routing table locking fixes, and once that's merged (hopefully
> >> tomorrow?) I'll start on the pa
Chris Rees wrote:
2009/2/25 Paul B. Mahol :
On 2/24/09, SDH Support wrote:
I tried using my ath based D-Link DWL G650, which still seems to have
some issues in regard to interrupt handling:
I've been able to get /most/ wireless cards working with ndiswrapper.
*BSD doe
John Baldwin wrote:
On Tuesday 24 February 2009 4:46:28 pm Guy Helmer wrote:
I think I may have found a clue regarding some of the hangs I'm seeing
on FreeBSD 7.1.
I have a program (kvoop), compiled under FreeBSD 6 and using
compatibility libraries under FreeBSD 7, that seems to be consisten
On Tuesday 24 February 2009 4:46:28 pm Guy Helmer wrote:
> I think I may have found a clue regarding some of the hangs I'm seeing
> on FreeBSD 7.1.
> I have a program (kvoop), compiled under FreeBSD 6 and using
> compatibility libraries under FreeBSD 7, that seems to be consistently
> involved d
> On 2/24/09, SDH Support wrote:
>>
>>> I tried using my ath based D-Link DWL G650, which still seems to have
>>> some issues in regard to interrupt handling:
>>
>>
>> I've been able to get /most/ wireless cards working with ndiswrapper.
>
> *BSD doesnt have ndiswrapper.
There is the ndis driver
2009/2/25 Christian Walther :
> 2009/2/24 SDH Support :
>>
>>> I tried using my ath based D-Link DWL G650, which still seems to have
>>> some issues in regard to interrupt handling:
>>
>>
>> I've been able to get /most/ wireless cards working with ndiswrapper.
>>
> This is just my personal opinion,
2009/2/25 Paul B. Mahol :
> On 2/24/09, SDH Support wrote:
>>
>>> I tried using my ath based D-Link DWL G650, which still seems to have
>>> some issues in regard to interrupt handling:
>>
>>
>> I've been able to get /most/ wireless cards working with ndiswrapper.
>
> *BSD doesnt have ndiswrapper.
2009/2/24 SDH Support :
>
>> I tried using my ath based D-Link DWL G650, which still seems to have
>> some issues in regard to interrupt handling:
>
>
> I've been able to get /most/ wireless cards working with ndiswrapper.
>
This is just my personal opinion, and I tend to make scarce use of the
wor
On Wed, Feb 25, 2009 at 8:26 AM, Paul B. Mahol wrote:
> On 2/24/09, SDH Support wrote:
>>
>>> I tried using my ath based D-Link DWL G650, which still seems to have
>>> some issues in regard to interrupt handling:
>>
>>
>> I've been able to get /most/ wireless cards working with ndiswrapper.
>
> *
On Thu, 2009-01-29 at 12:13 +0900, David Adam wrote:
> I upgraded my 7.0 system to 7.1-RELEASE with freebsd-update only to find
> that it no longer boots correctly, instead crashing with a BTX backtrace.
> If I break to the loader prompt and use 'ls /boot', I also get a
> backtrace.
>
> A new i
On 2/24/09, SDH Support wrote:
>
>> I tried using my ath based D-Link DWL G650, which still seems to have
>> some issues in regard to interrupt handling:
>
>
> I've been able to get /most/ wireless cards working with ndiswrapper.
*BSD doesnt have ndiswrapper.
--
Paul
__
Just a minor heads up: I've merged both Kip Macy's lock order fixes to the
kernel routing code, and the route locking and reference counting fixes from
kern/130652 to stable/7. These fixes should correct a number of reported
network-related hangs. We might want to release a subset of these a
On Wed, 25 Feb 2009, Pete French wrote:
FYI, I'm currently awaiting testing results from Pete on the MFC of a
number of routing table locking fixes, and once that's merged (hopefully
tomorrow?) I'll start on the patches in the above PR. I've taken a
crash-course in routing table locking in th
> FYI, I'm currently awaiting testing results from Pete on the MFC of a number
> of routing table locking fixes, and once that's merged (hopefully tomorrow?)
> I'll start on the patches in the above PR. I've taken a crash-course in
> routing table locking in the last few days... :-)
Just to le
Hi,
On Wed, Feb 25, 2009 at 09:22:39AM +0100, Oliver Brandmueller wrote:
> On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote:
> > I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after
> > booting, re0 works for only a short time, then gives "re0: PHY read
> > failed" over
Hi,
On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote:
> I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after
> booting, re0 works for only a short time, then gives "re0: PHY read
> failed" over and over. Does anyone have a suggestion on how to debug?
The Patch from <200
32 matches
Mail list logo
