https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219901
Mark Linimon changed:
What|Removed |Added
Flags|mfc-stable12? |
--- Comment #6 from Mark Linimon
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=75407
Ed Maste changed:
What|Removed |Added
Resolution|--- |Overcome By Events
CC|
On Thu, Jan 13, 2022 at 09:06:50PM +0100, Michael Tuexen wrote:
M> > I'm talking about statistics that I recently committed to CURRENT only:
M> >
M> > # netstat -sp tcp | grep TIME-WAIT
M> > 3 times connection in TIME-WAIT responded with ACK
M> >
On Thu, Jan 13, 2022 at 09:11:09PM +0100, Michael Tuexen wrote:
M> > On Thu, Jan 13, 2022 at 10:30:10AM -0800, Gleb Smirnoff wrote:
M> > T> Sorry, the stats I was talking about are present in CURRENT only:
M> > T>
M> > T> netstat -sp tcp | grep TIME-WAIT
M> >
Gleb Smirnoff wrote:
> On Thu, Jan 13, 2022 at 10:30:10AM -0800, Gleb Smirnoff wrote:
> T> Sorry, the stats I was talking about are present in CURRENT only:
Yeah, sorry, I saw your other post about that after posting mine.
> Sorry, I actually can't merge it to stable, as it changes size of tcps
On Thu, Jan 13, 2022 at 10:30:10AM -0800, Gleb Smirnoff wrote:
T> Sorry, the stats I was talking about are present in CURRENT only:
T>
T> netstat -sp tcp | grep TIME-WAIT
T> 3 times connection in TIME-WAIT responded with ACK
T> 0 times connection in TIME-WAIT was ac
On Thu, Jan 13, 2022 at 06:25:06PM +, Jamie Landeg-Jones wrote:
J> > modern HTTP server can be lowered 3 times more. Feel free to lower
J> > net.inet.tcp.msl and do your own measurements with
J> > 'netstat -sp tcp | grep TIME-WAIT'. I'd be glad to
Gleb Smirnoff wrote:
> modern HTTP server can be lowered 3 times more. Feel free to lower
> net.inet.tcp.msl and do your own measurements with
> 'netstat -sp tcp | grep TIME-WAIT'. I'd be glad to see your results.
Without changing net.inet.tcp.msl I get:
On Wed, Jan 12, 2022 at 11:16:09PM -0800, Chris wrote:
C> > * Who told that 2*MSL (60 seconds) is adequate time to keep TIME-WAIT?
C> > In 71d2d5adfe1 I added some stats on usage of tcptw and experimented a
bit
C> > with lowering net.inet.tcp.msl. It appeared that loweri
On Wed, Jan 12, 2022 at 05:01:51PM -0500, George Neville-Neil wrote:
G> > * Who told that 2*MSL (60 seconds) is adequate time to keep TIME-WAIT?
G> > In 71d2d5adfe1 I added some stats on usage of tcptw and experimented a
bit
G> > with lowering net.inet.tcp.msl. It appeare
g for wider discussion.
TLDR: struct tcptw shall be decomissioned
Longer version covers three topics: why does tcptw exist? why is it no
longer necessary? what would we get removing it?
Why does struct tcptw exist?
When TCP connection goes to TIME-WAIT state, it can only retransmit
the very las
Now posting for wider discussion.
>
> TLDR: struct tcptw shall be decomissioned
>
> Longer version covers three topics: why does tcptw exist? why is it no
> longer necessary? what would we get removing it?
>
> Why does struct tcptw exist?
>
> When TCP connection goes to
Apache
T> for persistent connections were short. So, the ratio of connections
T> in TIME-WAIT compared to live connections was much bigger than today.
T> Here is sample data from 2008 provided to me by Igor Sysoev:
T>
T> ITEM SIZE LIMIT USED FREE REQUE
does tcptw exist? why is it no
longer necessary? what would we get removing it?
Why does struct tcptw exist?
When TCP connection goes to TIME-WAIT state, it can only retransmit
the very last ACK, thus doesn't need all of the control data in the kernel.
However, we are required to keep it in
Hi everybody,
instead of adding some people, who will already do a lot of cooperative work
for others, to each of the reviews, I'd ask with a single message to the
list for some of your valuable time.
The whole project is about a better performance in natting (libalias).
Because there
I believe if you remove the work-around "exec.poststop = "jib destroy
${name}”;” this panic happens
Peter
> On 3 May 2020, at 18:42, bugzilla-nore...@freebsd.org wrote:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219901
>
> --- Comment #5 from Kristof Provost ---
> I'm not immediat
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219901
--- Comment #5 from Kristof Provost ---
I'm not immediately able to reproduce this. Can you provide more details about
what your setup is, and what you do when you start and stop jails?
The ideal would be a test script which can trigger th
|12.1-RELEASE
Summary|[Panic] [if_bridge] panic |if_bridge(4): Panic when
|when destroying interface |destroying interface on
|on bridge over time |bridge over time
CC||n...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219901
Kubilay Kocak changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219901
O. Hartmann changed:
What|Removed |Added
CC||ohartm...@walstatt.org
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219901
--- Comment #2 from Reshad Patuck ---
(In reply to Bjoern A. Zeeb from comment #1)
Hi,
I know it has been long, but I recently have seen similar failure on 12.1 (and
I think on one of my 12.0 systems too).
I do have the crash dump vmcore
SINGLE RELEASE | FOR YOUR CONSIDERATION Gutterprose Records Presents ‘PRIME
TIME’ BY PRIME SINISTER Hi! I found your email and thought this single would be
of interest to you. I would love to start a conversation and hopefully work
with you. ‘Prime Time’ is the first single from ‘Patient Zero
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240400
Rodney W. Grimes changed:
What|Removed |Added
CC||n...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240400
Cy Schubert changed:
What|Removed |Added
Assignee|n...@freebsd.org |c...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240400
Cy Schubert changed:
What|Removed |Added
Severity|Affects Many People |Affects Only Me
--
You are receivin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240400
--- Comment #2 from Cy Schubert ---
11.2-RELEASE does not have r338047, the bucket index fix. Update to 11.3-STABLE
first, please. Or see PR/208566 for the fix.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240400
--- Comment #1 from Cy Schubert ---
ipnat -lv output, please.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.fre
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240400
DYM changed:
What|Removed |Added
Severity|Affects Some People |Affects Many People
--
You are receiving th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240400
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
|[if_bridge] panic when |when destroying interface
|destroying interface on |on bridge over time
|bridge over time|
Keywords||vimage
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219901
--- Comment #1 from Bjoern A. Zeeb ---
Hi,
is this still a problem in recent HEAD or stable/12?
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=75407
Eitan Adler changed:
What|Removed |Added
Status|In Progress |Open
--- Comment #4 from Eitan Adler
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189404
Eitan Adler changed:
What|Removed |Added
Status|In Progress |Open
--- Comment #4 from Eitan Adler
Hi,
I have filed a bug for this issue and cc'd both of you in it.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227100
Best,
Reshad
On 29 March 2018 6:39:13 PM IST, Kristof Provost wrote:
>On 29 Mar 2018, at 14:48, Reshad Patuck wrote:
>> pulling the 'net.link.epair.netisr_maxqlen' down d
On 29 Mar 2018, at 14:48, Reshad Patuck wrote:
pulling the 'net.link.epair.netisr_maxqlen' down does seem to make
this occur faster.
Good, I think my hypothesis about where the issue lies is correct then.
You should be able to avoid (or at least reduce the frequency of) the
issue by increasi
Hi,
pulling the 'net.link.epair.netisr_maxqlen' down does seem to make this occur
faster.
When I dropped it to 2 like Kristof did and I have the same symptoms on a box
which was not exhibiting the problems manually began to have the same symptoms.
Bumping it back up to 2100 did not restore t
Excellent, will give it a try on a box that I never have this problem on.
Will let you know of the symptoms are the same when I trigger it.
Best,
Reshad
On 28 March 2018 12:32:44 AM IST, Kristof Provost wrote:
>On 27 Mar 2018, at 20:59, Reshad Patuck wrote:
>> The current value of 'net.link.ep
On 27 Mar 2018, at 20:59, Reshad Patuck wrote:
The current value of 'net.link.epair.netisr_maxqlen' is 2100, I will
make it 210.
Will this require a reboot? or can I just change the sysctl and reload
the epair module?
You shouldn’t need to reboot or reload the epair module. When I set it
to
code
>>> with the added dtrace sdt providers.
>>>
>>> Running the same command as last time, 'dtrace -n ::epair\*:'
>returns
>>> the following:
>>> ```
>>> CPU IDFUNCTION:NAME
>> …
>>> 0 66499
sdt providers.
Running the same command as last time, 'dtrace -n ::epair\*:'
returns the following:
```
CPU IDFUNCTION:NAME
…
0 66499 epair_transmit_locked:enqueued
```
Looks like its filled up a queue somewhere and is dropping
connections post th
time, 'dtrace -n ::epair\*:' returns
the following:
```
CPU IDFUNCTION:NAME
…
0 66499 epair_transmit_locked:enqueued
```
Looks like its filled up a queue somewhere and is dropping
connections post that.
The value of the 'error' is 55 I can se
On 27 Mar 2018, at 16:40, Kristof Provost wrote:
> It’s probably worth trying to play with ‘net.route.netisr_maxqlen’.
I probably mean ‘net.link.epair.netisr_maxqlen’ here.
Regards,
Kristof
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.o
(Re-cc freebsd-net, because this is useful information)
On 27 Mar 2018, at 13:07, Reshad Patuck wrote:
The epair crash occurred again today running the epair module code
with the added dtrace sdt providers.
Running the same command as last time, 'dtrace -n ::epair\*:' returns
the
Hi,
I attempted to unload the pf module, but this did not cause any changes.
I am not creating/destroying any VNET jails at the time epais stop to function.
Multiple VNET jails are started when I start the box, but no further activity
(starts or stops of vnet jails, creation deletion of epair
On 5 Jan 2018, at 20:54, Reshad Patuck wrote:
I have done the following on both servers to test what happens:
- Created a new epair interface epair3a and epair3b
- upped both interfaces
- given epair3a IP address 10.20.30.40/24 (I don't have this subnet
anywhere in my network)
- attempted to ping
Hey,
I am having a strange issue with one of my servers.
I have a couple of VNET jails FreeBSD 12 r321619 set up using if_bridge and
epairs.
Each VNET jail (and the host too) has a pf firewall limiting inbound
traffic.
Everything works as intended for some time (1-5 days), services inside the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199096
Eugene Grosbein changed:
What|Removed |Added
Resolution|--- |Feedback Timeout
Sta
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219901
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199096
Eugene Grosbein changed:
What|Removed |Added
Status|New |Open
CC|
FreeBSD 11 and prior, dprintf in stdio.h had to be specifically called
by setting particular defines.
These were removed in -CURRENT, which caused dprintf from
/usr/include/stdio.h to coflict with the declarations in netmap-fwd.
Commenting out the #define and the int dprintf statements in
netmap-f
Hi,
The DPRINTF macro in netmap-fwd is defined as #define *DPRINTF*(_fmt,
args...) if (verbose) dprintf(_fmt, ## args)
while dprintf is defined as dprintf(int fd, const char * restrict format,
...); in stdio.h
You could try, simplistically, to change DPRINTF macro to #define
*DPRINTF*(_fmt,
arg
Hello,
I am trying to compile netmap-fwd from git
(https://github.com/Netgate/netmap-fwd) on a Dell PE 530 with -CURRENT
updated from today (03/24/17). With the dependencies installed ( # pkg
install libucl libevent2 ) I run make and get the following error
followed by 8 warnings:
cc -O2 -fPIC -g
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #10 from Alexandre martins ---
Created attachment 180814
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180814&action=edit
Scapy client
I made a scapy script that produce the bug. This client ignore the RST, but
don'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #9 from Michael Tuexen ---
Great. Let me try to reproduce the issue with packetdrill. If that works, we
have a simple way of debugging the problem.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
Alexandre martins changed:
What|Removed |Added
Version|10.3-STABLE |CURRENT
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #8 from Alexandre martins ---
I made the test on the fresh compiled FreeBSD:
root@FreeBSD-head:~ # uname -a
FreeBSD FreeBSD-head 12.0-CURRENT FreeBSD 12.0-CURRENT #0
r315233+87dae13e7e9(master): Tue Mar 14 10:04:57 CET 2017
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #7 from Alexandre martins ---
The server run FreeBSD 10.3. The client (originally) was a Android smartphone.
In the capture, I use a Ubuntu 16.10 up-to-date.
I cut the capture to avoid to have a big file, but in reality, the fi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #6 from Michael Tuexen ---
Which OSes are used on the client and on the server side? Both FreeBSD 10.3?
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
Hiren Panchasara changed:
What|Removed |Added
CC||tue...@freebsd.org
--- Comment
time.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #3 from Alexandre martins ---
Created attachment 180692
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180692&action=edit
Client side view
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #2 from Alexandre martins ---
Created attachment 180691
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180691&action=edit
Server side view capture
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #1 from Hiren Panchasara ---
If possible, it'd be useful to look at real pcaps (and not text excerpts) from
both ends.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138046
Hiren Panchasara changed:
What|Removed |Added
Status|In Progress |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138046
Michael Tuexen changed:
What|Removed |Added
CC||tue...@freebsd.org
--- Comment #4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138046
Hiren Panchasara changed:
What|Removed |Added
CC||hi...@freebsd.org
Ass
l C files which used
BPF_FILTER macro.
Thanks,
Krishna.
-Original Message-
From: Navdeep Parhar [mailto:npar...@gmail.com] On Behalf Of Navdeep Parhar
Sent: Tuesday, September 20, 2016 12:04 PM
To: KrishnamRaju ErapaRaju
Cc: Bjoern A. Zeeb ; freebsd-net@freebsd.org
Subject: Re: unable to
z.net]
Sent: Tuesday, September 20, 2016 2:48 AM
To: KrishnamRaju ErapaRaju
Cc: freebsd-net@freebsd.org
Subject: Re: unable to use BPF Just-In-Time compiler
On 19 Sep 2016, at 16:04, Jung-uk Kim wrote:
> On 09/17/2016 17:11, Bjoern A. Zeeb wrote:
>> On 15 Sep 2016, at 5:32, KrishnamRaju Era
> Sent: Sunday, September 18, 2016 2:41 AM
> To: KrishnamRaju ErapaRaju
> Cc: freebsd-net@freebsd.org
> Subject: Re: unable to use BPF Just-In-Time compiler
>
> On 15 Sep 2016, at 5:32, KrishnamRaju ErapaRaju wrote:
>
> > Hi,
> >
> > I want to use
o:bzeeb-li...@lists.zabbadoz.net]
Sent: Sunday, September 18, 2016 2:41 AM
To: KrishnamRaju ErapaRaju
Cc: freebsd-net@freebsd.org
Subject: Re: unable to use BPF Just-In-Time compiler
On 15 Sep 2016, at 5:32, KrishnamRaju ErapaRaju wrote:
> Hi,
>
> I want to use BPF JIT Kernel APIs in FreeBSD(like: b
On 19 Sep 2016, at 16:04, Jung-uk Kim wrote:
On 09/17/2016 17:11, Bjoern A. Zeeb wrote:
On 15 Sep 2016, at 5:32, KrishnamRaju ErapaRaju wrote:
Hi,
I want to use BPF JIT Kernel APIs in FreeBSD(like: bpf_jitter(),
etc..), for implementing TCP connection packet filtering.
I have followed below
On 09/17/2016 17:11, Bjoern A. Zeeb wrote:
> On 15 Sep 2016, at 5:32, KrishnamRaju ErapaRaju wrote:
>
>> Hi,
>>
>> I want to use BPF JIT Kernel APIs in FreeBSD(like: bpf_jitter(),
>> etc..), for implementing TCP connection packet filtering.
>>
>> I have followed below instructions as specified in:
On 15 Sep 2016, at 5:32, KrishnamRaju ErapaRaju wrote:
Hi,
I want to use BPF JIT Kernel APIs in FreeBSD(like: bpf_jitter(),
etc..), for implementing TCP connection packet filtering.
I have followed below instructions as specified in:
https://lists.freebsd.org/pipermail/freebsd-current/2005-
Hi,
I want to use BPF JIT Kernel APIs in FreeBSD(like: bpf_jitter(), etc..), for
implementing TCP connection packet filtering.
I have followed below instructions as specified in:
https://lists.freebsd.org/pipermail/freebsd-current/2005-December/058603.html
STEPS followed:
-
after some time using mpd (netgraph) and ipfw
Bug 176401 [netgraph] page fault in netgraph
Bug 154286 [netgraph] [panic] 8.2-PRERELEASE panic in netgraph
Bug 154091 - [netgraph] [panic] netgraph, unaligned mbuf?
Bug 153497 - [netgraph] netgraph panic due to race conditions
I don't want to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210340
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org
--
You are
Hi Brett;
I looked at it briefly but it's not evident where to get the missing
support or any licensing information at all.
If you can put together a review in phabricator or bugzilla and add me
to it I will be glad to take a look.
Pedro.
___
freebs
even though the HiFn patent has longÂ
> since expired and there's no reason not to include the files in theÂ
> FreeBSD code base. Could a committer with access to that part ofÂ
> the tree please import the files mppc.h, mppcc.c, and mppcd.c intoÂ
> /sys/net so there's no need t
01.06.2016 22:08, Brett Glass пишет:
At 02:22 AM 6/1/2016, you wrote:
This manual page information is stale.
FreeBSD has stock MPPC support for long time and I use it extensively since
FreeBSD 8 with mpd5 and netgraph.
If this is true, I have not seen it in any release version of FreeBSD. I
red and there's no reason not to include the files in the
> FreeBSD code base. Could a committer with access to that part of
> the tree please import the files mppc.h, mppcc.c, and mppcd.c into
> /sys/net so there's no need to find and fetch them every time?
This manual page informa
since expired and there's no reason not to include the files in the
> FreeBSD code base. Could a committer with access to that part of
> the tree please import the files mppc.h, mppcc.c, and mppcd.c into
> /sys/net so there's no need to find and fetch them every time?
No commit
code base. Could a committer with access to that part of
the tree please import the files mppc.h, mppcc.c, and mppcd.c into
/sys/net so there's no need to find and fetch them every time?
--Brett Glass
___
freebsd-net@freebsd.org mailing
On Fri, May 13, 2016 at 02:17:09AM -0700, Yuri wrote:
> On 05/11/2016 22:58, YongHyeon PYUN wrote:
> >hw.msk.msi_disable is a loader tunable so you can't check it with
> >sysctl(8). Add the tunable to boot/loader.conf to take it effect.
> >See loader.conf(5) for more information.
>
>
> Adding hw
On 05/11/2016 22:58, YongHyeon PYUN wrote:
hw.msk.msi_disable is a loader tunable so you can't check it with
sysctl(8). Add the tunable to boot/loader.conf to take it effect.
See loader.conf(5) for more information.
Adding hw.msk.msi_disable="1" reduced the mouse problem, but Marvell
Yukon c
On Wed, May 11, 2016 at 10:46:01PM -0700, Yuri wrote:
> On 05/08/2016 02:33, YongHyeon PYUN wrote:
> >msk(4) will try to use MSI unless not configured to do so the IRQ
> >wouldn't be shared with other devices. If msk(4) is using MSI you
> >should see a high irq number greater than or equal to 256
On 05/08/2016 02:33, YongHyeon PYUN wrote:
msk(4) will try to use MSI unless not configured to do so the IRQ
wouldn't be shared with other devices. If msk(4) is using MSI you
should see a high irq number greater than or equal to 256 in vmstat
output. Given that you're seeing issues with MSI, tr
On Sat, May 07, 2016 at 09:33:39AM -0700, Yuri wrote:
> On 05/07/2016 08:34, Eugene Grosbein wrote:
> >
> >Verify if your mouse (USB one?) is using IRQ 18 too.
> >"vmstat -ai" command would be helpful.
> Yes, I have a USB mouse, and my USB uses IRQ 18:
>
> irq18: ehci0 uhci5503154
07.05.2016 23:33, Yuri wrote:
Verify if your mouse (USB one?) is using IRQ 18 too.
"vmstat -ai" command would be helpful.
Yes, I have a USB mouse, and my USB uses IRQ 18:
irq18: ehci0 uhci5503154 9
stray irq180 0
That must be the
On 05/07/2016 08:34, Eugene Grosbein wrote:
Verify if your mouse (USB one?) is using IRQ 18 too.
"vmstat -ai" command would be helpful.
Yes, I have a USB mouse, and my USB uses IRQ 18:
irq18: ehci0 uhci5503154 9
stray irq180 0
Yuri
06.05.2016 23:29, Yuri пишет:
When Marvell Yukon card is active on the desktop system, mouse periodically
stops, sometimes for seconds. I think this also makes the system impaired in
some other ways.
The offending device:
mskc0: port 0xd800-0xd8ff mem
0xfbdfc000-0xfbdf irq 18 at device 0
When Marvell Yukon card is active on the desktop system, mouse
periodically stops, sometimes for seconds. I think this also makes the
system impaired in some other ways.
The offending device:
mskc0: port 0xd800-0xd8ff mem
0xfbdfc000-0xfbdf irq 18 at device 0.0 on pci6
msk0: on
mskc0
W
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi folks,
On 04/06/16 15:12, Harald Dunkel wrote:
> Hi folks,
>
> the nfe driver of FreeBSD 4.3 does some kind of up-down pingpong at boot
> time. DHCP is stuck in an endless loop. No login, unless I disconnect the
> ethernet cab
Hi folks,
the nfe driver of FreeBSD 4.3 does some kind of up-down pingpong
at boot time. DHCP is stuck in an endless loop. No login, unless
I disconnect the ethernet cable :-(. See the attached snapshot.
Hardware is MCP79. Booting without ACPI fails; the kernel
panics very early at boot time
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206876
Kristof Provost changed:
What|Removed |Added
Flags|mfc-stable10? |mfc-stable10+
Resolution
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206876
--- Comment #5 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kp
Date: Sun Mar 6 08:52:04 UTC 2016
New revision: 296425
URL: https://svnweb.freebsd.org/changeset/base/296425
Log:
MFC r295836:
ifconfig(8): can't
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206876
Kubilay Kocak changed:
What|Removed |Added
Keywords|needs-qa|
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206876
--- Comment #3 from Marie Helene Kvello-Aune ---
Fixed in base r295836.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https:/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206876
Kubilay Kocak changed:
What|Removed |Added
Keywords|needs-patch |patch
Status|New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206876
--- Comment #2 from Marie Helene Kvello-Aune ---
I've submitted a patch, review D5341
This patch solves the bugs described in this PR.
--
You are receiving this mail because:
You are the assignee for the bug.
1 - 100 of 287 matches
Mail list logo
