Re: Start networkadapter without reboot
On Fri, 2012-06-15 at 14:54 +, van Sleeuwen, Berry wrote: Hi Scott, Yes it is. I've found some more information when looking through the /sys/ directory. The state for this device is in HARDSETUP. nlzlx204:~ # cat /sys/devices/qeth/0.0.0f10/state HARDSETUP Searching for this I've found some information in patch reports, for instance at git390.marist.edu and kerneltrap.org. This status is a result of a boot without the actual device available. Indeed, what we have here now. When the cable is plugged (or the vswitch connected) the state should switch to SOFTSETUP or eventualy even to UP. But it doesn't. Would it be possible to get it to UP dynamically or is this a bug that can be resolved with a reboot or network restart only? (kernel level is at 2.6.32.12-0.7). Berry. Hi Berry, correct, state HARDSETUP should be a temporary state during online setting for a qeth device only. If the device stays in state HARDSETUP something unexpected occurred. To understand the reason, the trace file /sys/kernel/debugfs/qeth_setup/hex_ascii should be checked by a qeth expert. It's a wrap around buffer; thus it needs to be saved immediately after the problem shows up. Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Start networkadapter without reboot
Hi Ursula, Thank's for your update. I found the file at: nlzlx204:~ # ll /sys/kernel/debug/s390dbf/qdio_setup/ total 0 --w--- 1 root root 0 Apr 5 11:30 flush -r 1 root root 0 Apr 5 11:30 hex_ascii -rw--- 1 root root 0 Apr 5 11:30 level -rw--- 1 root root 0 Apr 5 11:30 pages nlzlx204:~ # Obviously it hadn't been saved at the time of this problem. Regards, Berry. correct, state HARDSETUP should be a temporary state during online setting for a qeth device only. If the device stays in state HARDSETUP something unexpected occurred. To understand the reason, the trace file /sys/kernel/debugfs/qeth_setup/hex_ascii should be checked by a qeth expert. It's a wrap around buffer; thus it needs to be saved immediately after the problem shows up. Dit bericht is vertrouwelijk en kan geheime informatie bevatten enkel bestemd voor de geadresseerde. Indien dit bericht niet voor u is bestemd, verzoeken wij u dit onmiddellijk aan ons te melden en het bericht te vernietigen. Aangezien de integriteit van het bericht niet veilig gesteld is middels verzending via internet, kan Atos Nederland B.V. niet aansprakelijk worden gehouden voor de inhoud daarvan. Hoewel wij ons inspannen een virusvrij netwerk te hanteren, geven wij geen enkele garantie dat dit bericht virusvrij is, noch aanvaarden wij enige aansprakelijkheid voor de mogelijke aanwezigheid van een virus in dit bericht. Op al onze rechtsverhoudingen, aanbiedingen en overeenkomsten waaronder Atos Nederland B.V. goederen en/of diensten levert zijn met uitsluiting van alle andere voorwaarden de Leveringsvoorwaarden van Atos Nederland B.V. van toepassing. Deze worden u op aanvraag direct kosteloos toegezonden. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Nederland B.V. group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. On all offers and agreements under which Atos Nederland B.V. supplies goods and/or services of whatever nature, the Terms of Delivery from Atos Nederland B.V. exclusively apply. The Terms of Delivery shall be promptly submitted to you on your request. Atos Nederland B.V. / Utrecht KvK Utrecht 30132762 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Start networkadapter without reboot
Ursula Braun writes: correct, state HARDSETUP should be a temporary state during online setting for a qeth device only. If the device stays in state HARDSETUP something unexpected occurred. To understand the reason, the trace file /sys/kernel/debugfs/qeth_setup/hex_ascii should be checked by a qeth expert. It's a wrap around buffer; thus it needs to be saved immediately after the problem shows up. I can reproduce this easily on SLES11SP1 kernel 2.6.32.12-0.7-default (not up to date on service at all). I'll send you a transcript. --Malcolm -- Malcolm Beattie Mainframe Systems and Software Business, Europe IBM UK -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Start networkadapter without reboot
On Mon, 2012-06-18 at 10:15 +0100, Malcolm Beattie wrote: Ursula Braun writes: correct, state HARDSETUP should be a temporary state during online setting for a qeth device only. If the device stays in state HARDSETUP something unexpected occurred. To understand the reason, the trace file /sys/kernel/debugfs/qeth_setup/hex_ascii should be checked by a qeth expert. It's a wrap around buffer; thus it needs to be saved immediately after the problem shows up. I can reproduce this easily on SLES11SP1 kernel 2.6.32.12-0.7-default (not up to date on service at all). I'll send you a transcript. Malcolm, looking through your transcript, I find the definition of the NIC (vmcp def nic 800 type qdio), but I do not see a vmcp couple command to bind the created NIC to a VSWITCH or GuestLAN. This would explain the failing STARTLAN command for this qeth device. Try to insert a vmcp couple command between vmcp def nic... and znetconf -a ... . Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Start networkadapter without reboot
Ursula Braun writes: looking through your transcript, I find the definition of the NIC (vmcp def nic 800 type qdio), but I do not see a vmcp couple command to bind the created NIC to a VSWITCH or GuestLAN. This would explain the failing STARTLAN command for this qeth device. I intentionally didn't bother with a COUPLE since I was trying to reproduce Berry's problem and also expecting the vNIC to act like a normal NIC and let me configure it and even ifconfig it up before plugging it into a switch. I'd thought that that used to work but maybe not. Would it be considered a bug or an unimplemented feature that it doesn't act that way? Actually, even when I then couple it to a VSWITCH, the state remains in HARDSETUP (even after I do an echo 1 recover too) and an ifup eth1 still fails. That makes it even more unlike a normal NIC and seems very inconvenient. I'll send you the trace for that too in case that part is unexpected. --Malcolm -- Malcolm Beattie Mainframe Systems and Software Business, Europe IBM UK -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Start networkadapter without reboot
On Mon, 2012-06-18 at 11:36 +0100, Malcolm Beattie wrote: I intentionally didn't bother with a COUPLE since I was trying to reproduce Berry's problem and also expecting the vNIC to act like a normal NIC and let me configure it and even ifconfig it up before plugging it into a switch. I'd thought that that used to work but maybe not. Would it be considered a bug or an unimplemented feature that it doesn't act that way? Actually, even when I then couple it to a VSWITCH, the state remains in HARDSETUP (even after I do an echo 1 recover too) and an ifup eth1 still fails. That makes it even more unlike a normal NIC and seems very inconvenient. I'll send you the trace for that too in case that part is unexpected. --Malcolm Malcolm, tried to recreate your problem with my available upstream kernel. But my qeth device stayed in state SOFTSETUP after znetconf. Further analysis showed that you need to upgrade to a kernel level of at least 2.6.32.29-0.3.1 (bugzilla 68725) to see this behavior. Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Missing lin_taped module
I installed the recommended and security patches from SUSE on Friday. The patches required that I do a reboot. When I reboot Linux cannot find the lin_taped module. This image is used to run TSM with a 7650G Virtual Tape System. On reboot I get the message... Starting lin_tape: FATAL: Module lin_tape not found. notice -- Jun 18 11:53:52.997789000 'lin_tape start' exits with status 1 Do I or Will I have to reinstall lin_taped every time I install patches?? Ruddy Melancon -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Missing lin_taped module
Ruddy, If I am not mistaken, you have to 'recompile' lin_tape everytime you upgrade to a newer Linux kernel. If your patches included a new kernel version to be installed, please do so. Best Regards, Pedro Principeza From: Melancon, Ruddy melanc...@dot.state.al.us To: LINUX-390@vm.marist.edu, Date: 18/06/2012 16:40 Subject:Missing lin_taped module Sent by:Linux on 390 Port LINUX-390@vm.marist.edu I installed the recommended and security patches from SUSE on Friday. The patches required that I do a reboot. When I reboot Linux cannot find the lin_taped module. This image is used to run TSM with a 7650G Virtual Tape System. On reboot I get the message... Starting lin_tape: FATAL: Module lin_tape not found. notice -- Jun 18 11:53:52.997789000 'lin_tape start' exits with status 1 Do I or Will I have to reinstall lin_taped every time I install patches?? Ruddy Melancon -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Missing lin_taped module
On 6/18/2012 at 03:38 PM, Melancon, Ruddy melanc...@dot.state.al.us wrote: Do I or Will I have to reinstall lin_taped every time I install patches?? If IBM didn't package it correctly, yes. If they did package it correctly, then you shouldn't have to do that. A PMR with IBM should help clarify if something is wrong, or something is wrong with their packaging. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
