chzdev behaviour change in bionic

Bug #1772461 reported by Andrew McLeod
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
Invalid
Undecided
Dimitri John Ledkov
s390-tools (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

This may be less of a bug, and more of a change of usage:

Using preseeds for xenial I was successfully able to configure bridge_role=primary on a qeth device, using this command:

chzdev --no-root-update -pVe ${NIC_ID} layer2=1 bridge_role=primary

However, this no longer works - upon reboot, bridge_role is set to none.

Running this command manually, on the built lpar, without --no-root-update, returns:

QETH device 0.0.c003:0.0.c004:0.0.c005 already configured

Running sudo chzdev -Ve 0.0.c003 layer2=1 bridge_role=primary

returns

Error: Cannot set layer2='1' while online='1' (*)

Running with --force still complains about being online, so first i take the dev offline, and rerun the command, but get this:

Error: Settings bridge_role and vnicc/rx_bcast are in conflict (*)

ubuntu@s4lp5:/sys/devices/qeth/0.0.c003$ cat vnicc/rx_bcast
n/a
ubuntu@s4lp5:/sys/devices/qeth/0.0.c003$

The only combination that seems to work is:

ubuntu@s4lp5:/sys/devices/qeth/0.0.c003$ sudo chzdev -Ve 0.0.c003 layer2=1 bridge_role=primary online=0 --force
Scanning for devices in all configurations:
  ECKD DASD : 268
Loading required kernel module: dasd_fba_mod
Failed to load kernel module: dasd_fba_mod
  FBA DASD : 0
  FCP device : 20
  zFCP LUN : 0
  QETH device : 42
Loading required kernel module: ctcm
Failed to load kernel module: ctcm
  CTC device : 0
Loading required kernel module: lcs
Failed to load kernel module: lcs
  LCS device : 0
  Generic CCW device : 1
  Total : 331
QETH device 0.0.c003:0.0.c004:0.0.c005 configured
    Changes: online=0 bridge_role=primary
    Network interface: encc003
    Warning: Settings bridge_role and vnicc/rx_bcast are in conflict

ubuntu@s4lp5:/sys/devices/qeth/0.0.c003$ cat bridge_role
primary
ubuntu@s4lp5:/sys/devices/qeth/0.0.c003$ sudo chzdev -Ve 0.0.c003 online=1
Scanning for devices in all configurations:
  ECKD DASD : 268
Loading required kernel module: dasd_fba_mod
Failed to load kernel module: dasd_fba_mod
  FBA DASD : 0
  FCP device : 20
  zFCP LUN : 0
  QETH device : 42
Loading required kernel module: ctcm
Failed to load kernel module: ctcm
  CTC device : 0
Loading required kernel module: lcs
Failed to load kernel module: lcs
  LCS device : 0
  Generic CCW device : 1
  Total : 331
QETH device 0.0.c003:0.0.c004:0.0.c005 configured
    Changes: online=1
    Network interface: encc003
ubuntu@s4lp5:/sys/devices/qeth/0.0.c003$ cat bridge_role
none
ubuntu@s4lp5:/sys/devices/qeth/0.0.c003$

Tags: s390x
Revision history for this message
Andrew McLeod (admcleod) wrote :

Also, after a reboot:

ubuntu@s4lp5:~$ lszdev --configure --info c003
DEVICE qeth 0.0.c003:0.0.c004:0.0.c005
  Names : encc003
  Network interfaces : encc003
  Modules : qeth
  Online : yes
  Exists : yes
  Persistent : yes

  ATTRIBUTE ACTIVE PERSISTENT
  bridge_hostnotify "0" -
  bridge_reflect_promisc "none" -
  bridge_role "none" "primary"
  buffer_count "64" -
  hw_trap "disarm" -
  isolation "none" -
  layer2 "1" "1"
  online "1" "1"
  performance_stats "0" -
  portname "" -
  portno "0" -
  priority_queueing "always queue 0" -
  vnicc/bridge_invisible "n/a" -
  vnicc/flooding "n/a" -
  vnicc/learning "n/a" -
  vnicc/learning_timeout "n/a" -
  vnicc/mcast_flooding "n/a" -
  vnicc/rx_bcast "n/a" -
  vnicc/takeover_learning "n/a" -
  vnicc/takeover_setvmac "n/a" -

....

It appears that the error from the tool is just misleading, as I have just found this in dmesg:

[ 14.218702] qeth.8c5944: 0.0.c003: The LAN already has a primary Bridge Port

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi,
you should have got a file created that does this on start, what is the content of your:
  /etc/udev/rules.d/41-qeth-0.0.c003.rules

Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
assignee: nobody → Dimitri John Ledkov (xnox)
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in s390-tools (Ubuntu):
status: New → Confirmed
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: New → Confirmed
Revision history for this message
Frank Heimes (fheimes) wrote :

It turned out that the following situation happened:
A single OSA adapter is shared by multiple LPARs (in this case two) and in such a situation only one LPAR can bring it's (shared) OSA adapter into primary role.

"Bridge port roles
Linux can assign a primary or secondary role to a logical port of an OSA or a HiperSockets adapter. Only one logical port of such an adapter can be assigned the primary role, but multiple other logical ports can be assigned secondary role. When one or more logical ports of an adapter are assigned primary or secondary role, the hardware ensures that exactly one of these ports is active. The active port receives frames with unknown destination. When a port with primary role is present, it always becomes active.
When only ports with secondary role are present, the hardware decides which one becomes active.
Changes in the ports' state are reported to Linux user space through udev events."
'Linux on Z and LinuxONE Device Drivers, Features, and Commands on Ubuntu Server 18.04 LTS'
http://public.dhe.ibm.com/software/dw/linux390/docu/lub0dd01.pdf p.217
Hence closing that ticket by marking it as Invalid.

Changed in s390-tools (Ubuntu):
status: Confirmed → Invalid
Changed in ubuntu-z-systems:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.