http://bugzilla.suse.com/show_bug.cgi?id=1091526http://bugzilla.suse.com/show_bug.cgi?id=1091526#c1
Fabian Vogt <fvogt(a)suse.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fvogt(a)suse.com,
| |vourlo(a)gmail.com
Flags| |needinfo?(vourlo(a)gmail.com)
--- Comment #1 from Fabian Vogt <fvogt(a)suse.com> ---
Please upload all system logs.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1091629
Bug ID: 1091629
Summary: Both Wicked and Network Manager start together
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.0
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Network
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: st-malcolm.moore(a)whsg.info
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
If you set the IP in Yast as static using Wicked, as all our machines are,
Network Manager also starts by default so you get a static IP set in Yast
and then a dhcp address by Network manager. In our environment dhcp address are
severely restricted and the browsers tend to use that one which means
smoothwall blocks practically everything. disabling NetworkManager manually
works but having
two thing providing IP adresses doesn't seem right.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1088304http://bugzilla.opensuse.org/show_bug.cgi?id=1088304#c2
Thorsten Kukuk <kukuk(a)suse.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Thorsten Kukuk <kukuk(a)suse.com> ---
Fixed.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1075876http://bugzilla.suse.com/show_bug.cgi?id=1075876#c17
--- Comment #17 from Benjamin Poirier <bpoirier(a)suse.com> ---
https://www.mail-archive.com/netdev@vger.kernel.org/msg231452.html
No update from Intel... probably time to send a patch.
The simplest approach would be to remove the problematic TSYNCRXCTL read in
e1000e_get_base_timinca() and set the clock parameters unconditionally, like
for the 82574 case just below. I've prepared a patch which does that and also
adds some logging (for debugging only, not submission). It would also be
important to know if the ptp hardware clock (PHC) still works at that point,
for that I think we can use phc_ctl which leads to a call of
e1000e_phc_gettime().
Please install the updated kernel package from the
home:benjamin_poirier:bsc1075876 project once it has finished building (link
in comment 15, version should contain "g5227f0d") and install the linuxptp
package. Upon a reboot when you see the "No SYSCFI in TSYNCRXCTL [...]" in
dmesg, run
phc_ctl /dev/ptp0 cmp && sleep 60 && phc_ctl /dev/ptp0 cmp
Please provide the dmesg line with the values after "No SYSCFI in TSYNCRXCTL"
and the output of the phc_ctl command.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1074242http://bugzilla.suse.com/show_bug.cgi?id=1074242#c3
--- Comment #3 from Johannes Meixner <jsmeix(a)suse.com> ---
I did read but it seems you do not understand,
perhaps because I did not explain it (see below).
It seems you do not understand how free software development
versus fee software distribution works and therefore
it seems you have wrong expectations what we (at openSUSE)
can do to fix your particular issue in this particular case.
Explanation:
Because we (at openSUSE) do not develop sane-backends,
we cannot bildly "just revert" a SANE upstream commit
because we do not understand what other consequences
at whatever other places such a change may have.
"Just reverting" a SANE upstream commit can make things
work for your particular case but on the other hand
there is a reason why SANE upstream did that commit
(but I do not understand what the commit message means).
If you want a change of the SANE upstream code
you must get in direct contact with SANE upstream
and work together with the SANE upstream authors
to get your particular case fixed at SANE upstream.
This is the only way how issues can get solved properly.
It cannot work well when each Linux distribution maintains
its own distribution-specific different set of patches.
Only when issues get solved at the upstream projects
things will "just work" for all Linux distributions.
In this case the SANE upstream authors need to get
a better understanding of this issue to find a solution
for their intent behind why they did that commit but
without the bad consequences of the current implementation.
Simply put:
Continue to be helpful and continue to contribute to the
SANE upstream bug report to get this issue solved properly
for you and for all users of those scanner models.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1091097http://bugzilla.suse.com/show_bug.cgi?id=1091097#c12
--- Comment #12 from Fabian Vogt <fvogt(a)suse.com> ---
(In reply to Michal Kubeček from comment #11)
> (In reply to Fabian Vogt from comment #10)
> > IMO kernel-default-base should be the same as kernel-default but just exclude
> > support for physical hardware. Anything else is just asking for trouble.
> > I can definitely see use-cases for 9pfs in production.
>
> Sounds like you are still assuming kernel-*-base subpackage was designed for
> use in general purpose VMs. AFAIK this is not true, even package description
> says something very different. What you want is rather closer to -ec2 flavor
> we have had earlier or kvmsmall config recently introduced in newer branches
> (it is meant for developer use but it's probably closer to your idea what
> -base subpackage should be than actual -base). Therefore my suggestions from
> comment 7.
Yes, the best option is IMO to have a hand-pickable kernel with modules sorted
into independent groups. That would allow arbitrary combination of flavors.
It also makes it possible to install some additional modules when needed
instead of including them in every image just in case.
However, we can't do that now, so my suggestion for the near future is to make
kernel-default-base complete enough to allow its use in all situations on
virtual hardware.
Both options avoid having to open a bug with the same discussion for every
module ;-)
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1091097http://bugzilla.suse.com/show_bug.cgi?id=1091097#c11
Michal Kubeček <mkubecek(a)suse.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Comment #7 is|1 |0
private| |
--- Comment #11 from Michal Kubeček <mkubecek(a)suse.com> ---
(In reply to Fabian Vogt from comment #10)
> IMO kernel-default-base should be the same as kernel-default but just exclude
> support for physical hardware. Anything else is just asking for trouble.
> I can definitely see use-cases for 9pfs in production.
Sounds like you are still assuming kernel-*-base subpackage was designed for
use in general purpose VMs. AFAIK this is not true, even package description
says something very different. What you want is rather closer to -ec2 flavor
we have had earlier or kvmsmall config recently introduced in newer branches
(it is meant for developer use but it's probably closer to your idea what
-base subpackage should be than actual -base). Therefore my suggestions from
comment 7.
--
You are receiving this mail because:
You are on the CC list for the bug.