[Kernel-packages] [Bug 1521123] Re: hvcs vterm driver doesn't cleanup it's tty kref allocation on close
** Tags added: cscc
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1521123
Title:
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
Status in linux package in Ubuntu:
Incomplete
Bug description:
== Comment: #0 - Amartey S. Pearson - 2015-04-08
16:07:04 ==
---Problem Description---
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
As a result, if the vterm device is used, closed, then hot-plug
removed, the original device (/dev/hvcsX) will never be re-used as the
.destruct method never gets called.
In the hvcs_close method, it should call tty_port_put. This in theory
would get handled by the _cleanup method, but the _close method nulls
the tty->driver_data, therefore making the _cleanup method a noop.
I made the following change which fixed the issue for me - allowed
.destruct to be called on DLPAR remove of the adapter.
*** hvcs.c2015-04-08 14:46:44.058208878 -0500
--- hvcs.c.old2015-04-08 14:45:33.726199732 -0500
***
*** 1240,1246
tty->driver_data = NULL;
free_irq(irq, hvcsd);
- tty_port_put(&hvcsd->port);
return;
} else if (hvcsd->port.count < 0) {
printk(KERN_ERR "HVCS: vty-server@%X open_count: %d"
--- 1240,1245
Contact Information = Amartey Pearson (apear...@us.ibm.com), Steven Royer
(sero...@us.ibm.com)
---uname output---
Linux ip9-114-251-60 3.19.0-10-generic #10-Ubuntu SMP Mon Mar 23 16:18:35 UTC
2015 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = 8247-22L
---Debugger---
A debugger is not configured
---Steps to Reproduce---
1) Create a virtual serial device from the HMC - dynamically (make sure you
have rsct etc. installed for DLPAR support). In the example below, we created
a device that provides a console to lpar 6.
chhwres -m --id -r virtualio --rsubtype serial -o
a -a adapter_type=client,remote_lpar_id=6,remote_slot_num=0
2) From your linux partition, you should now see a console device available.
You can use the handy '/sbin/hvcsadmin' tool to see the console.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
Here we can see that /dev/hvcs0 got used for lpar 6
3) Now open the device. We'll use 'socat' here, but you can use
pretty much anything (screen, etc). Once open, hit Ctl+] to exit
socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs0
4) Now check your hvcsadmin -console 6 again. the vterm-state will show 1.
Let's close it. and verify it got closed (per the vterm_state)
# hvcsadmin -close /dev/hvcs0
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
5) Now let's remove the device alltogether. Go back to the HMC to do
this. Here we will remove slot # 3 (because that's what we created
above - hence the 300<3> value).
chhwres -m --id -r virtualio --rsubtype serial -o
r -s 3
6) Verify you no longer have a console device on your linux lpar...this will
not print anything out.
# hvcsadmin -console 6
7) Now go ahead and re-add the device with the same command as you
ran in step #1
8) Now let's see what device it allocated. If this were behaving correctly,
it would re-allocate /dev/hvcs0, but as you'll see, it allocates /dev/hvcs1
instead.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs1 vterm-state:0
9) You can keep repeating these until you run out of hvcsX devices. Note
that if you skipped the 'open' step, and simply removed the device then
re-created it, the bug would not occur.
If things are working correctly, you should see the following dmesg output:
[ 5287.993312] HVCS: vty-server@3003 added to the vio bus.
[ 5287.993326] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
[ 5393.109677] HVCS: vty-server@3003 connection opened.
[ 5402.237382] HVCS: Closed vty-server@3003 and partner vty@3000:6
connection.
[ 5412.637292] HVCS: Destroyed hvcs_struct for vty-server@3003. <-
This is missing with the current driver
[ 5412.637298] HVCS: vty-server@3003 removed from the vio bus.
[ 5412.637355] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 removed
[ 5417.069910] HVCS: vty-server@3003 added to the vio bus.
[ 5417.069921] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
Stack trace output:
no
Oops output:
no
System Dump Info:
The system is not configured to capture a system dump.
*Additional Instructions for Amartey Pearson (apear...@us.ibm.com), Steven
Royer (sero...@us.ibm.com):
-Attach sysctl -a output output to the bug.
== Comment: #10 - Thierry Fauck -
2015-11-30 04:55:37 ==
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+so
[Kernel-packages] [Bug 1521123] Re: hvcs vterm driver doesn't cleanup it's tty kref allocation on close
** Tags removed: severity-high
** Tags added: severity-low
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1521123
Title:
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
Status in linux package in Ubuntu:
Incomplete
Bug description:
== Comment: #0 - Amartey S. Pearson - 2015-04-08
16:07:04 ==
---Problem Description---
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
As a result, if the vterm device is used, closed, then hot-plug
removed, the original device (/dev/hvcsX) will never be re-used as the
.destruct method never gets called.
In the hvcs_close method, it should call tty_port_put. This in theory
would get handled by the _cleanup method, but the _close method nulls
the tty->driver_data, therefore making the _cleanup method a noop.
I made the following change which fixed the issue for me - allowed
.destruct to be called on DLPAR remove of the adapter.
*** hvcs.c2015-04-08 14:46:44.058208878 -0500
--- hvcs.c.old2015-04-08 14:45:33.726199732 -0500
***
*** 1240,1246
tty->driver_data = NULL;
free_irq(irq, hvcsd);
- tty_port_put(&hvcsd->port);
return;
} else if (hvcsd->port.count < 0) {
printk(KERN_ERR "HVCS: vty-server@%X open_count: %d"
--- 1240,1245
Contact Information = Amartey Pearson (apear...@us.ibm.com), Steven Royer
(sero...@us.ibm.com)
---uname output---
Linux ip9-114-251-60 3.19.0-10-generic #10-Ubuntu SMP Mon Mar 23 16:18:35 UTC
2015 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = 8247-22L
---Debugger---
A debugger is not configured
---Steps to Reproduce---
1) Create a virtual serial device from the HMC - dynamically (make sure you
have rsct etc. installed for DLPAR support). In the example below, we created
a device that provides a console to lpar 6.
chhwres -m --id -r virtualio --rsubtype serial -o
a -a adapter_type=client,remote_lpar_id=6,remote_slot_num=0
2) From your linux partition, you should now see a console device available.
You can use the handy '/sbin/hvcsadmin' tool to see the console.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
Here we can see that /dev/hvcs0 got used for lpar 6
3) Now open the device. We'll use 'socat' here, but you can use
pretty much anything (screen, etc). Once open, hit Ctl+] to exit
socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs0
4) Now check your hvcsadmin -console 6 again. the vterm-state will show 1.
Let's close it. and verify it got closed (per the vterm_state)
# hvcsadmin -close /dev/hvcs0
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
5) Now let's remove the device alltogether. Go back to the HMC to do
this. Here we will remove slot # 3 (because that's what we created
above - hence the 300<3> value).
chhwres -m --id -r virtualio --rsubtype serial -o
r -s 3
6) Verify you no longer have a console device on your linux lpar...this will
not print anything out.
# hvcsadmin -console 6
7) Now go ahead and re-add the device with the same command as you
ran in step #1
8) Now let's see what device it allocated. If this were behaving correctly,
it would re-allocate /dev/hvcs0, but as you'll see, it allocates /dev/hvcs1
instead.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs1 vterm-state:0
9) You can keep repeating these until you run out of hvcsX devices. Note
that if you skipped the 'open' step, and simply removed the device then
re-created it, the bug would not occur.
If things are working correctly, you should see the following dmesg output:
[ 5287.993312] HVCS: vty-server@3003 added to the vio bus.
[ 5287.993326] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
[ 5393.109677] HVCS: vty-server@3003 connection opened.
[ 5402.237382] HVCS: Closed vty-server@3003 and partner vty@3000:6
connection.
[ 5412.637292] HVCS: Destroyed hvcs_struct for vty-server@3003. <-
This is missing with the current driver
[ 5412.637298] HVCS: vty-server@3003 removed from the vio bus.
[ 5412.637355] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 removed
[ 5417.069910] HVCS: vty-server@3003 added to the vio bus.
[ 5417.069921] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
Stack trace output:
no
Oops output:
no
System Dump Info:
The system is not configured to capture a system dump.
*Additional Instructions for Amartey Pearson (apear...@us.ibm.com), Steven
Royer (sero...@us.ibm.com):
-Attach sysctl -a output output to the bug.
== Comment: #10 - Thierry Fauck -
2015-11-30 04:55:37 ==
To manage notifications about this bug go to
[Kernel-packages] [Bug 1521123] Re: hvcs vterm driver doesn't cleanup it's tty kref allocation on close
** Tags removed: targetmilestone-inin1504
** Tags added: targetmilestone-inin1604
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1521123
Title:
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
Status in linux package in Ubuntu:
Incomplete
Bug description:
== Comment: #0 - Amartey S. Pearson - 2015-04-08
16:07:04 ==
---Problem Description---
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
As a result, if the vterm device is used, closed, then hot-plug
removed, the original device (/dev/hvcsX) will never be re-used as the
.destruct method never gets called.
In the hvcs_close method, it should call tty_port_put. This in theory
would get handled by the _cleanup method, but the _close method nulls
the tty->driver_data, therefore making the _cleanup method a noop.
I made the following change which fixed the issue for me - allowed
.destruct to be called on DLPAR remove of the adapter.
*** hvcs.c2015-04-08 14:46:44.058208878 -0500
--- hvcs.c.old2015-04-08 14:45:33.726199732 -0500
***
*** 1240,1246
tty->driver_data = NULL;
free_irq(irq, hvcsd);
- tty_port_put(&hvcsd->port);
return;
} else if (hvcsd->port.count < 0) {
printk(KERN_ERR "HVCS: vty-server@%X open_count: %d"
--- 1240,1245
Contact Information = Amartey Pearson (apear...@us.ibm.com), Steven Royer
(sero...@us.ibm.com)
---uname output---
Linux ip9-114-251-60 3.19.0-10-generic #10-Ubuntu SMP Mon Mar 23 16:18:35 UTC
2015 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = 8247-22L
---Debugger---
A debugger is not configured
---Steps to Reproduce---
1) Create a virtual serial device from the HMC - dynamically (make sure you
have rsct etc. installed for DLPAR support). In the example below, we created
a device that provides a console to lpar 6.
chhwres -m --id -r virtualio --rsubtype serial -o
a -a adapter_type=client,remote_lpar_id=6,remote_slot_num=0
2) From your linux partition, you should now see a console device available.
You can use the handy '/sbin/hvcsadmin' tool to see the console.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
Here we can see that /dev/hvcs0 got used for lpar 6
3) Now open the device. We'll use 'socat' here, but you can use
pretty much anything (screen, etc). Once open, hit Ctl+] to exit
socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs0
4) Now check your hvcsadmin -console 6 again. the vterm-state will show 1.
Let's close it. and verify it got closed (per the vterm_state)
# hvcsadmin -close /dev/hvcs0
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
5) Now let's remove the device alltogether. Go back to the HMC to do
this. Here we will remove slot # 3 (because that's what we created
above - hence the 300<3> value).
chhwres -m --id -r virtualio --rsubtype serial -o
r -s 3
6) Verify you no longer have a console device on your linux lpar...this will
not print anything out.
# hvcsadmin -console 6
7) Now go ahead and re-add the device with the same command as you
ran in step #1
8) Now let's see what device it allocated. If this were behaving correctly,
it would re-allocate /dev/hvcs0, but as you'll see, it allocates /dev/hvcs1
instead.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs1 vterm-state:0
9) You can keep repeating these until you run out of hvcsX devices. Note
that if you skipped the 'open' step, and simply removed the device then
re-created it, the bug would not occur.
If things are working correctly, you should see the following dmesg output:
[ 5287.993312] HVCS: vty-server@3003 added to the vio bus.
[ 5287.993326] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
[ 5393.109677] HVCS: vty-server@3003 connection opened.
[ 5402.237382] HVCS: Closed vty-server@3003 and partner vty@3000:6
connection.
[ 5412.637292] HVCS: Destroyed hvcs_struct for vty-server@3003. <-
This is missing with the current driver
[ 5412.637298] HVCS: vty-server@3003 removed from the vio bus.
[ 5412.637355] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 removed
[ 5417.069910] HVCS: vty-server@3003 added to the vio bus.
[ 5417.069921] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
Stack trace output:
no
Oops output:
no
System Dump Info:
The system is not configured to capture a system dump.
*Additional Instructions for Amartey Pearson (apear...@us.ibm.com), Steven
Royer (sero...@us.ibm.com):
-Attach sysctl -a output output to the bug.
== Comment: #10 - Thierry Fauck -
2015-11-30 04:55:37 ==
To manage notificatio
[Kernel-packages] [Bug 1521123] Re: hvcs vterm driver doesn't cleanup it's tty kref allocation on close
The attached patch in comment #1 does not look right with respect to
upstream.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1521123
Title:
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
Status in linux package in Ubuntu:
Incomplete
Bug description:
== Comment: #0 - Amartey S. Pearson - 2015-04-08
16:07:04 ==
---Problem Description---
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
As a result, if the vterm device is used, closed, then hot-plug
removed, the original device (/dev/hvcsX) will never be re-used as the
.destruct method never gets called.
In the hvcs_close method, it should call tty_port_put. This in theory
would get handled by the _cleanup method, but the _close method nulls
the tty->driver_data, therefore making the _cleanup method a noop.
I made the following change which fixed the issue for me - allowed
.destruct to be called on DLPAR remove of the adapter.
*** hvcs.c2015-04-08 14:46:44.058208878 -0500
--- hvcs.c.old2015-04-08 14:45:33.726199732 -0500
***
*** 1240,1246
tty->driver_data = NULL;
free_irq(irq, hvcsd);
- tty_port_put(&hvcsd->port);
return;
} else if (hvcsd->port.count < 0) {
printk(KERN_ERR "HVCS: vty-server@%X open_count: %d"
--- 1240,1245
Contact Information = Amartey Pearson (apear...@us.ibm.com), Steven Royer
(sero...@us.ibm.com)
---uname output---
Linux ip9-114-251-60 3.19.0-10-generic #10-Ubuntu SMP Mon Mar 23 16:18:35 UTC
2015 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = 8247-22L
---Debugger---
A debugger is not configured
---Steps to Reproduce---
1) Create a virtual serial device from the HMC - dynamically (make sure you
have rsct etc. installed for DLPAR support). In the example below, we created
a device that provides a console to lpar 6.
chhwres -m --id -r virtualio --rsubtype serial -o
a -a adapter_type=client,remote_lpar_id=6,remote_slot_num=0
2) From your linux partition, you should now see a console device available.
You can use the handy '/sbin/hvcsadmin' tool to see the console.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
Here we can see that /dev/hvcs0 got used for lpar 6
3) Now open the device. We'll use 'socat' here, but you can use
pretty much anything (screen, etc). Once open, hit Ctl+] to exit
socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs0
4) Now check your hvcsadmin -console 6 again. the vterm-state will show 1.
Let's close it. and verify it got closed (per the vterm_state)
# hvcsadmin -close /dev/hvcs0
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
5) Now let's remove the device alltogether. Go back to the HMC to do
this. Here we will remove slot # 3 (because that's what we created
above - hence the 300<3> value).
chhwres -m --id -r virtualio --rsubtype serial -o
r -s 3
6) Verify you no longer have a console device on your linux lpar...this will
not print anything out.
# hvcsadmin -console 6
7) Now go ahead and re-add the device with the same command as you
ran in step #1
8) Now let's see what device it allocated. If this were behaving correctly,
it would re-allocate /dev/hvcs0, but as you'll see, it allocates /dev/hvcs1
instead.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs1 vterm-state:0
9) You can keep repeating these until you run out of hvcsX devices. Note
that if you skipped the 'open' step, and simply removed the device then
re-created it, the bug would not occur.
If things are working correctly, you should see the following dmesg output:
[ 5287.993312] HVCS: vty-server@3003 added to the vio bus.
[ 5287.993326] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
[ 5393.109677] HVCS: vty-server@3003 connection opened.
[ 5402.237382] HVCS: Closed vty-server@3003 and partner vty@3000:6
connection.
[ 5412.637292] HVCS: Destroyed hvcs_struct for vty-server@3003. <-
This is missing with the current driver
[ 5412.637298] HVCS: vty-server@3003 removed from the vio bus.
[ 5412.637355] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 removed
[ 5417.069910] HVCS: vty-server@3003 added to the vio bus.
[ 5417.069921] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
Stack trace output:
no
Oops output:
no
System Dump Info:
The system is not configured to capture a system dump.
*Additional Instructions for Amartey Pearson (apear...@us.ibm.com), Steven
Royer (sero...@us.ibm.com):
-Attach sysctl -a output output to the bug.
== Comment: #10 - Thierry Fauck -
2015-11-30 04:55:37 ==
To manage notifications
[Kernel-packages] [Bug 1521123] Re: hvcs vterm driver doesn't cleanup it's tty kref allocation on close
** Changed in: linux (Ubuntu)
Status: Triaged => Incomplete
** Changed in: linux (Ubuntu)
Assignee: Taco Screen team (taco-screen-team) => Leann Ogasawara
(leannogasawara)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1521123
Title:
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
Status in linux package in Ubuntu:
Incomplete
Bug description:
== Comment: #0 - Amartey S. Pearson - 2015-04-08
16:07:04 ==
---Problem Description---
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
As a result, if the vterm device is used, closed, then hot-plug
removed, the original device (/dev/hvcsX) will never be re-used as the
.destruct method never gets called.
In the hvcs_close method, it should call tty_port_put. This in theory
would get handled by the _cleanup method, but the _close method nulls
the tty->driver_data, therefore making the _cleanup method a noop.
I made the following change which fixed the issue for me - allowed
.destruct to be called on DLPAR remove of the adapter.
*** hvcs.c2015-04-08 14:46:44.058208878 -0500
--- hvcs.c.old2015-04-08 14:45:33.726199732 -0500
***
*** 1240,1246
tty->driver_data = NULL;
free_irq(irq, hvcsd);
- tty_port_put(&hvcsd->port);
return;
} else if (hvcsd->port.count < 0) {
printk(KERN_ERR "HVCS: vty-server@%X open_count: %d"
--- 1240,1245
Contact Information = Amartey Pearson (apear...@us.ibm.com), Steven Royer
(sero...@us.ibm.com)
---uname output---
Linux ip9-114-251-60 3.19.0-10-generic #10-Ubuntu SMP Mon Mar 23 16:18:35 UTC
2015 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = 8247-22L
---Debugger---
A debugger is not configured
---Steps to Reproduce---
1) Create a virtual serial device from the HMC - dynamically (make sure you
have rsct etc. installed for DLPAR support). In the example below, we created
a device that provides a console to lpar 6.
chhwres -m --id -r virtualio --rsubtype serial -o
a -a adapter_type=client,remote_lpar_id=6,remote_slot_num=0
2) From your linux partition, you should now see a console device available.
You can use the handy '/sbin/hvcsadmin' tool to see the console.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
Here we can see that /dev/hvcs0 got used for lpar 6
3) Now open the device. We'll use 'socat' here, but you can use
pretty much anything (screen, etc). Once open, hit Ctl+] to exit
socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs0
4) Now check your hvcsadmin -console 6 again. the vterm-state will show 1.
Let's close it. and verify it got closed (per the vterm_state)
# hvcsadmin -close /dev/hvcs0
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
5) Now let's remove the device alltogether. Go back to the HMC to do
this. Here we will remove slot # 3 (because that's what we created
above - hence the 300<3> value).
chhwres -m --id -r virtualio --rsubtype serial -o
r -s 3
6) Verify you no longer have a console device on your linux lpar...this will
not print anything out.
# hvcsadmin -console 6
7) Now go ahead and re-add the device with the same command as you
ran in step #1
8) Now let's see what device it allocated. If this were behaving correctly,
it would re-allocate /dev/hvcs0, but as you'll see, it allocates /dev/hvcs1
instead.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs1 vterm-state:0
9) You can keep repeating these until you run out of hvcsX devices. Note
that if you skipped the 'open' step, and simply removed the device then
re-created it, the bug would not occur.
If things are working correctly, you should see the following dmesg output:
[ 5287.993312] HVCS: vty-server@3003 added to the vio bus.
[ 5287.993326] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
[ 5393.109677] HVCS: vty-server@3003 connection opened.
[ 5402.237382] HVCS: Closed vty-server@3003 and partner vty@3000:6
connection.
[ 5412.637292] HVCS: Destroyed hvcs_struct for vty-server@3003. <-
This is missing with the current driver
[ 5412.637298] HVCS: vty-server@3003 removed from the vio bus.
[ 5412.637355] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 removed
[ 5417.069910] HVCS: vty-server@3003 added to the vio bus.
[ 5417.069921] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
Stack trace output:
no
Oops output:
no
System Dump Info:
The system is not configured to capture a system dump.
*Additional Instructions for Amartey Pearson (apear...@us.ibm.com), Steven
Royer (sero...@us.ibm.com):
-Attach sysctl -a output
[Kernel-packages] [Bug 1521123] Re: hvcs vterm driver doesn't cleanup it's tty kref allocation on close
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1521123
Title:
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
Status in linux package in Ubuntu:
Triaged
Bug description:
== Comment: #0 - Amartey S. Pearson - 2015-04-08
16:07:04 ==
---Problem Description---
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
As a result, if the vterm device is used, closed, then hot-plug
removed, the original device (/dev/hvcsX) will never be re-used as the
.destruct method never gets called.
In the hvcs_close method, it should call tty_port_put. This in theory
would get handled by the _cleanup method, but the _close method nulls
the tty->driver_data, therefore making the _cleanup method a noop.
I made the following change which fixed the issue for me - allowed
.destruct to be called on DLPAR remove of the adapter.
*** hvcs.c2015-04-08 14:46:44.058208878 -0500
--- hvcs.c.old2015-04-08 14:45:33.726199732 -0500
***
*** 1240,1246
tty->driver_data = NULL;
free_irq(irq, hvcsd);
- tty_port_put(&hvcsd->port);
return;
} else if (hvcsd->port.count < 0) {
printk(KERN_ERR "HVCS: vty-server@%X open_count: %d"
--- 1240,1245
Contact Information = Amartey Pearson (apear...@us.ibm.com), Steven Royer
(sero...@us.ibm.com)
---uname output---
Linux ip9-114-251-60 3.19.0-10-generic #10-Ubuntu SMP Mon Mar 23 16:18:35 UTC
2015 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = 8247-22L
---Debugger---
A debugger is not configured
---Steps to Reproduce---
1) Create a virtual serial device from the HMC - dynamically (make sure you
have rsct etc. installed for DLPAR support). In the example below, we created
a device that provides a console to lpar 6.
chhwres -m --id -r virtualio --rsubtype serial -o
a -a adapter_type=client,remote_lpar_id=6,remote_slot_num=0
2) From your linux partition, you should now see a console device available.
You can use the handy '/sbin/hvcsadmin' tool to see the console.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
Here we can see that /dev/hvcs0 got used for lpar 6
3) Now open the device. We'll use 'socat' here, but you can use
pretty much anything (screen, etc). Once open, hit Ctl+] to exit
socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs0
4) Now check your hvcsadmin -console 6 again. the vterm-state will show 1.
Let's close it. and verify it got closed (per the vterm_state)
# hvcsadmin -close /dev/hvcs0
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
5) Now let's remove the device alltogether. Go back to the HMC to do
this. Here we will remove slot # 3 (because that's what we created
above - hence the 300<3> value).
chhwres -m --id -r virtualio --rsubtype serial -o
r -s 3
6) Verify you no longer have a console device on your linux lpar...this will
not print anything out.
# hvcsadmin -console 6
7) Now go ahead and re-add the device with the same command as you
ran in step #1
8) Now let's see what device it allocated. If this were behaving correctly,
it would re-allocate /dev/hvcs0, but as you'll see, it allocates /dev/hvcs1
instead.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs1 vterm-state:0
9) You can keep repeating these until you run out of hvcsX devices. Note
that if you skipped the 'open' step, and simply removed the device then
re-created it, the bug would not occur.
If things are working correctly, you should see the following dmesg output:
[ 5287.993312] HVCS: vty-server@3003 added to the vio bus.
[ 5287.993326] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
[ 5393.109677] HVCS: vty-server@3003 connection opened.
[ 5402.237382] HVCS: Closed vty-server@3003 and partner vty@3000:6
connection.
[ 5412.637292] HVCS: Destroyed hvcs_struct for vty-server@3003. <-
This is missing with the current driver
[ 5412.637298] HVCS: vty-server@3003 removed from the vio bus.
[ 5412.637355] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 removed
[ 5417.069910] HVCS: vty-server@3003 added to the vio bus.
[ 5417.069921] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
Stack trace output:
no
Oops output:
no
System Dump Info:
The system is not configured to capture a system dump.
*Additional Instructions for Amartey Pearson (apear...@us.ibm.com), Steven
Royer (sero...@us.ibm.com):
-Attach sysctl -a output output to the bug.
== Comment: #10 - Thierry Fauck -
2015
[Kernel-packages] [Bug 1521123] Re: hvcs vterm driver doesn't cleanup it's tty kref allocation on close
Is this patch being sent upstream? We'd also appreciate the patch to be
generated from `git format-patch` such that it contains the relevant
commit information/patch description as well as an official signed-off-
by from the author. Thanks.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1521123
Title:
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
Status in linux package in Ubuntu:
New
Bug description:
== Comment: #0 - Amartey S. Pearson - 2015-04-08
16:07:04 ==
---Problem Description---
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
As a result, if the vterm device is used, closed, then hot-plug
removed, the original device (/dev/hvcsX) will never be re-used as the
.destruct method never gets called.
In the hvcs_close method, it should call tty_port_put. This in theory
would get handled by the _cleanup method, but the _close method nulls
the tty->driver_data, therefore making the _cleanup method a noop.
I made the following change which fixed the issue for me - allowed
.destruct to be called on DLPAR remove of the adapter.
*** hvcs.c2015-04-08 14:46:44.058208878 -0500
--- hvcs.c.old2015-04-08 14:45:33.726199732 -0500
***
*** 1240,1246
tty->driver_data = NULL;
free_irq(irq, hvcsd);
- tty_port_put(&hvcsd->port);
return;
} else if (hvcsd->port.count < 0) {
printk(KERN_ERR "HVCS: vty-server@%X open_count: %d"
--- 1240,1245
Contact Information = Amartey Pearson (apear...@us.ibm.com), Steven Royer
(sero...@us.ibm.com)
---uname output---
Linux ip9-114-251-60 3.19.0-10-generic #10-Ubuntu SMP Mon Mar 23 16:18:35 UTC
2015 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = 8247-22L
---Debugger---
A debugger is not configured
---Steps to Reproduce---
1) Create a virtual serial device from the HMC - dynamically (make sure you
have rsct etc. installed for DLPAR support). In the example below, we created
a device that provides a console to lpar 6.
chhwres -m --id -r virtualio --rsubtype serial -o
a -a adapter_type=client,remote_lpar_id=6,remote_slot_num=0
2) From your linux partition, you should now see a console device available.
You can use the handy '/sbin/hvcsadmin' tool to see the console.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
Here we can see that /dev/hvcs0 got used for lpar 6
3) Now open the device. We'll use 'socat' here, but you can use
pretty much anything (screen, etc). Once open, hit Ctl+] to exit
socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs0
4) Now check your hvcsadmin -console 6 again. the vterm-state will show 1.
Let's close it. and verify it got closed (per the vterm_state)
# hvcsadmin -close /dev/hvcs0
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
5) Now let's remove the device alltogether. Go back to the HMC to do
this. Here we will remove slot # 3 (because that's what we created
above - hence the 300<3> value).
chhwres -m --id -r virtualio --rsubtype serial -o
r -s 3
6) Verify you no longer have a console device on your linux lpar...this will
not print anything out.
# hvcsadmin -console 6
7) Now go ahead and re-add the device with the same command as you
ran in step #1
8) Now let's see what device it allocated. If this were behaving correctly,
it would re-allocate /dev/hvcs0, but as you'll see, it allocates /dev/hvcs1
instead.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs1 vterm-state:0
9) You can keep repeating these until you run out of hvcsX devices. Note
that if you skipped the 'open' step, and simply removed the device then
re-created it, the bug would not occur.
If things are working correctly, you should see the following dmesg output:
[ 5287.993312] HVCS: vty-server@3003 added to the vio bus.
[ 5287.993326] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
[ 5393.109677] HVCS: vty-server@3003 connection opened.
[ 5402.237382] HVCS: Closed vty-server@3003 and partner vty@3000:6
connection.
[ 5412.637292] HVCS: Destroyed hvcs_struct for vty-server@3003. <-
This is missing with the current driver
[ 5412.637298] HVCS: vty-server@3003 removed from the vio bus.
[ 5412.637355] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 removed
[ 5417.069910] HVCS: vty-server@3003 added to the vio bus.
[ 5417.069921] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
Stack trace output:
no
Oops output:
no
System Dump Info:
The system is not configured to capture a system dump.
*Additional Instructions for Amartey Pearson (apear...@us.ibm.com), Steven
Royer
[Kernel-packages] [Bug 1521123] Re: hvcs vterm driver doesn't cleanup it's tty kref allocation on close
** Package changed: ubuntu => linux (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1521123
Title:
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
Status in linux package in Ubuntu:
New
Bug description:
== Comment: #0 - Amartey S. Pearson - 2015-04-08
16:07:04 ==
---Problem Description---
hvcs vterm driver doesn't cleanup it's tty kref allocation on close
As a result, if the vterm device is used, closed, then hot-plug
removed, the original device (/dev/hvcsX) will never be re-used as the
.destruct method never gets called.
In the hvcs_close method, it should call tty_port_put. This in theory
would get handled by the _cleanup method, but the _close method nulls
the tty->driver_data, therefore making the _cleanup method a noop.
I made the following change which fixed the issue for me - allowed
.destruct to be called on DLPAR remove of the adapter.
*** hvcs.c2015-04-08 14:46:44.058208878 -0500
--- hvcs.c.old2015-04-08 14:45:33.726199732 -0500
***
*** 1240,1246
tty->driver_data = NULL;
free_irq(irq, hvcsd);
- tty_port_put(&hvcsd->port);
return;
} else if (hvcsd->port.count < 0) {
printk(KERN_ERR "HVCS: vty-server@%X open_count: %d"
--- 1240,1245
Contact Information = Amartey Pearson (apear...@us.ibm.com), Steven Royer
(sero...@us.ibm.com)
---uname output---
Linux ip9-114-251-60 3.19.0-10-generic #10-Ubuntu SMP Mon Mar 23 16:18:35 UTC
2015 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = 8247-22L
---Debugger---
A debugger is not configured
---Steps to Reproduce---
1) Create a virtual serial device from the HMC - dynamically (make sure you
have rsct etc. installed for DLPAR support). In the example below, we created
a device that provides a console to lpar 6.
chhwres -m --id -r virtualio --rsubtype serial -o
a -a adapter_type=client,remote_lpar_id=6,remote_slot_num=0
2) From your linux partition, you should now see a console device available.
You can use the handy '/sbin/hvcsadmin' tool to see the console.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
Here we can see that /dev/hvcs0 got used for lpar 6
3) Now open the device. We'll use 'socat' here, but you can use
pretty much anything (screen, etc). Once open, hit Ctl+] to exit
socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs0
4) Now check your hvcsadmin -console 6 again. the vterm-state will show 1.
Let's close it. and verify it got closed (per the vterm_state)
# hvcsadmin -close /dev/hvcs0
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs0 vterm-state:0
5) Now let's remove the device alltogether. Go back to the HMC to do
this. Here we will remove slot # 3 (because that's what we created
above - hence the 300<3> value).
chhwres -m --id -r virtualio --rsubtype serial -o
r -s 3
6) Verify you no longer have a console device on your linux lpar...this will
not print anything out.
# hvcsadmin -console 6
7) Now go ahead and re-add the device with the same command as you
ran in step #1
8) Now let's see what device it allocated. If this were behaving correctly,
it would re-allocate /dev/hvcs0, but as you'll see, it allocates /dev/hvcs1
instead.
# hvcsadmin -console 6
vty-server@3003 partition:6 slot:0 /dev/hvcs1 vterm-state:0
9) You can keep repeating these until you run out of hvcsX devices. Note
that if you skipped the 'open' step, and simply removed the device then
re-created it, the bug would not occur.
If things are working correctly, you should see the following dmesg output:
[ 5287.993312] HVCS: vty-server@3003 added to the vio bus.
[ 5287.993326] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
[ 5393.109677] HVCS: vty-server@3003 connection opened.
[ 5402.237382] HVCS: Closed vty-server@3003 and partner vty@3000:6
connection.
[ 5412.637292] HVCS: Destroyed hvcs_struct for vty-server@3003. <-
This is missing with the current driver
[ 5412.637298] HVCS: vty-server@3003 removed from the vio bus.
[ 5412.637355] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 removed
[ 5417.069910] HVCS: vty-server@3003 added to the vio bus.
[ 5417.069921] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
Stack trace output:
no
Oops output:
no
System Dump Info:
The system is not configured to capture a system dump.
*Additional Instructions for Amartey Pearson (apear...@us.ibm.com), Steven
Royer (sero...@us.ibm.com):
-Attach sysctl -a output output to the bug.
== Comment: #10 - Thierry Fauck -
2015-11-30 04:55:37 ==
To manage notifications about this bug go to:
https://bugs.launch
