Created attachment 354871 [details] Screenshot out of VMWare Infrastructure Client of kernel panic As requested in bz465143: https://bugzilla.redhat.com/show_bug.cgi?id=465143#c29 See screenshot attached with the kernel panic when using jlayton's test-kernel. Don't know how to give more/better information on this issue.
Is there any way you can get more of the oops? Maybe boot with a parameter to use a smaller screen font or use an emaulated serial console? Alternately, if you can explain a way for me to reproduce this, that would be fine too.
I can try with vga= boot param, not sure if that works within vmware (normally only access those systems over ssh). Anything else I don't know how to do it. I'll probably find time to do this tomorrow (CEST). Well, the reproduction here is easy - if you could access our server which you can't: - Install RHEL 5.3 - Install your kernel - Mount DFS-Share - Type in the password for the share - Get an instant oops My mount cmd looks like: mount -t cifs -o "user=foobar" \\\\d.server.ch\\dfs\\users\\all\\foobar /mnt/
Created attachment 354875 [details] Screenshot out of VMWare Infrastructure Client of kernel panic (with vga=791)
I lied :) I was able to do this right now and all of the kernel panic is on the new screenshot.
Thanks for the info, that was more helpful... I believe I'm able to reproduce the panic. You need either a malformed DFS referral or a hostname in a DFS referral that can't be resolved. I've sent a patch upstream (and cc'ed you on it) that should fix this there. Once I get some feedback on it, I'll incorporate the patch into my RHEL5 test kernels.
Always happy to help :) I guess you know our DFS servers better than I do by now ;) Just get back to this bug if you have a new kernel that fixes this so I can try to test this.
The test kernels on my people.redhat.com page now have the patch I've pushed upstream. Please test when you have the chance and let me know whether they still crash.
No more crash, but a strange error: # mount -t cifs -o "user=foobar" \\\\d.ethz.ch\\dfs\\users\\all\\foobar /mnt/ Password: mount error 11 = Resource temporarily unavailable Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) btw, also tried it with / instead of \\ for the share (/ is preferred by mount.cifs), which brings a very different error: # mount -t cifs -o "user=foobar" //d.ethz.ch/dfs/users/all/foobar /mnt/ Password: retrying with upper case share name mount error 6 = No such device or address Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
I'm not so sure that error is wrong. The cifs client wasn't able to resolve the hostname that the referral gave back. Do you have /etc/request-key.conf configured? dmesg should have the hostname that it's trying to resolve.
Right, there's a resolve-problem I don't quite understand. # dmsg (snip...snap) CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: nas-dfs-1.d.ethz.ch CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of \\nas-dfs-1.d.ethz.ch\users to IP: -11 CIFS VFS: cifs_mount failed w/return code = -11 # ping nas-dfs-1.d.ethz.ch PING nas-dfs-1.d.ethz.ch (129.132.19.136) 56(84) bytes of data. 64 bytes from nas-dfs-1.ethz.ch (129.132.19.136): icmp_seq=1 ttl=124 time=1.15 ms 64 bytes from nas-dfs-1.ethz.ch (129.132.19.136): icmp_seq=2 ttl=124 time=1.01 ms 64 bytes from nas-dfs-1.ethz.ch (129.132.19.136): icmp_seq=3 ttl=124 time=1.05 ms 64 bytes from nas-dfs-1.ethz.ch (129.132.19.136): icmp_seq=4 ttl=124 time=1.04 ms --- nas-dfs-1.d.ethz.ch ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3098ms rtt min/avg/max/mdev = 1.015/1.069/1.158/0.058 ms # cat /etc/request-key.conf create cifs.spnego * * /usr/sbin/cifs.upcall -c %k create dns_resolver * * /usr/sbin/cifs.upcall %k
Do you have the "keyutils" RPM installed? Is cifs.upcall in /usr/sbin ?
No, keyutils were missing, I installed them now. cifs.upcall exists. CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: nas-dfs-1.d.ethz.ch CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of \\nas-dfs-1.d.ethz.ch\users to IP: -11 CIFS VFS: cifs_mount failed w/return code = -11 and still, sometimes it also seems to fail with: CIFS VFS: cifs_mount failed w/return code = -6
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
(In reply to comment #5) > Thanks for the info, that was more helpful... > > I believe I'm able to reproduce the panic. You need either a malformed DFS > referral or a hostname in a DFS referral that can't be resolved. I've sent a > patch upstream (and cc'ed you on it) that should fix this there. Once I get > some feedback on it, I'll incorporate the patch into my RHEL5 test kernels. Jeff could you give more specific steps on how to reproducet that? Can I just use unresolvable hostname in mount -t cifs?
No, you'll need to set up DFS on a server, and set up a DFS symlink to point to a UNC that contains an unresolvable hostname. There's a RHTS test for DFS, so that's probably the best place to look for an example of how to set up DFS. Let me know if you have Q's.
in kernel-2.6.18-177.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5 Please do NOT transition this bugzilla state to VERIFIED until our QE team has sent specific instructions indicating when to do so. However feel free to provide a comment indicating that this fix has been verified.
$ uname -a Linux id-lnx-vcl-x32.ethz.ch. 2.6.18-177.el5PAE #1 SMP Thu Dec 3 21:48:22 EST 2009 i686 athlon i386 GNU/Linux $ cat /etc/request-key.conf create cifs.spnego * * /usr/sbin/cifs.upcall -c %k create dns_resolver * * /usr/sbin/cifs.upcall %k $ sudo mount -o user=sandroma -t cifs //d.ethz.ch/dfs/users/all/sandroma /mnt/ Password: <ctrl-c after nothing happens for a while> $ sudo tail -n2 /var/log/messages Dec 8 16:53:42 id-lnx-vcl-x32 kernel: CIFS VFS: Error connecting to socket. Aborting operation Dec 8 16:53:42 id-lnx-vcl-x32 kernel: CIFS VFS: cifs_mount failed w/return code = -512 $ rpm -qa keyutils samba-client keyutils-1.2-1.el5 samba-client-3.0.33-3.15.el5_4
Sandro, I suspect that the DFS referral being provided by your server is bad or the ultimate target of the referral is blocking your client from connecting. Sniffing traffic may help you to determine the actual cause.
Jeff, you are completely right. I forgot that iptables was up again after the reboot after installing the test-kernel. DFS is working with this version of the kernel, great! Btw, should "mount.cifs -o sec=krb5" work by now in RHEL 5.4? Because it doesn't seem to... :)
Yes, it should assuming that your credcache is in the default location. If it's not then you'll need the patch for bug 517195, which I believe should make 5.5.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0178.html