BUG: unable to handle kernel NULL pointer dereference at (null)
Hello, I am getting this message when running a patched kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Is there some kernel configuration item which enables getting , instead (null), the proper value (I assume it should be a method name) Regards, Kevin ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: BUG: unable to handle kernel NULL pointer dereference at (null)
On Thu, 2014-10-23 at 09:58 +0300, Kevin Wilson wrote: I am getting this message when running a patched kernel: BUG: unable to handle kernel NULL pointer dereference at (null) That is just what you get when the kernel dereferences NULL, isn't it? (If the kernel dereferences, say, something halfway some struct, you'll see a hex address instead of (null).) Assuming x86, see: arch/x86/mm/fault.c:show_fault_oops() and lib/vsprintf.c:pointer(). Is there some kernel configuration item which enables getting , instead (null), the proper value (I assume it should be a method name) Doesn't your BUG also print a backtrace that points at a (possible) culprit? Paul Bolle ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Non-maskable interrupt
On Thu, 2014-10-23 at 11:20 +0900, J.Hwan Kim wrote: In my kernel, there is no kernel paramter of nmi_watchdog Is CONFIG_HARDLOCKUP_DETECTOR not set in your .config? and I cannot find the /proc/sys/kernel/nmi_watchdog file in my system. Is CONFIG_LOCKUP_DETECTOR not set in your .config? Paul Bolle ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: i2c-dev
On Wed, 2014-10-22 at 13:27 -0400, John de la Garza wrote: On Wed, Oct 22, 2014 at 06:35:02PM +0200, Paul Bolle wrote: Having looked into this a bit, but failing to come up with something helpful, I decided to ask some additional info. On Tue, 2014-10-21 at 21:54 -0400, John de la Garza wrote: I have my kernel Which version (roughly)? Linux vega 3.18.0-rc1+ #71 SMP Wed Oct 22 00:49:21 EDT 2014 x86_64 GNU/Linux built with dev-i2c and i2c_i801 .config, please? see below but do not have a /dev entry. lspci shows this: 00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06) What are the PCI vendor and device codes? See lspci -nn. 00:1f.3 SMBus [0c05]: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller [8086:3b30] (rev 06) dmesg shows this: [1.566003] i801_smbus :00:1f.3: enabling device ( - 0003) I'm afraid I can't really help you here, sorry. That is, except for the obvious question whether this is a regression (ie, do releases v3.17 or earlier show something in /sys/bus/i2c/devices/?) or a configuration issue (perhaps a distribution provided kernel does show what you want). Hope this helps, Paul Bolle ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: /drivers/staging/TODO doc and kernel tasks question
Thanks Greg for your response. I just wanted to get an idea of where else to look for newbie projects, like helping with documentation, style and the sort for now. I ask because the bugzilla does happen to show some bugs stated as NEW that are already fixed on the latest release. I'll keep looking. I prepared a patch to get my feet wet on patch format and coding style, I'll send it again. Thanks again. Jaime A. On Wed, Oct 22, 2014 at 10:18 PM, Greg KH g...@kroah.com wrote: On Wed, Oct 22, 2014 at 10:05:30PM -0500, Jaime Arrocha wrote: Good day, The TODO document has the addresses of where to send a patch, but if you run get_maintainer.pl it gives me a different person to address it, gregkh for example. if you don't cc: me, the patch will not get merged, it's that simple :) I have sent a patch to the persons on the TODO list, should I still copy to the maintainer in charge too? CC maybe? Yes, and the mailing list as well please. Trust get_maintainer.pl, it works properly. Another question, apart from the /drivers/staging and bugtracker, is there some where else to look for bug info? The mailing list? I just want to get the complete picture. bugzilla.kernel.org doesn't show much of anything for staging drivers, what specifically are you looking for? Last question, I understand that if there is a bug, most of the time they tell you to try to reproduce it on the latest kernel. If it doesn't occur then everything is good and I should look for another one. But who is in charge of porting a bug fix like these to old kernels? How can I help? Or I, as a newbie, should focus more on the /drivers/staging and bugtracker? Read Documentation/stable_kernel_rules.txt for how patches get backported to older stable kernel releases. thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
sendmmsg() Expected Behavior?
Hi,
I am on CentOS 6.5 with kernel version kernel-2.6.32-431.el6.
I was trying to find the implementation of recvmmsg(), and hopefully, I am not
looking at the wrong source
~/rpmbuild/BUILD/kernel-2.6.32-431.el6/linux-2.6.32-431.el6.x86_64/net/socket.c.
If I am, please kindly point me to the right source.
int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int vlen,
unsigned int flags, struct timespec *timeout)
{
int fput_needed, err, datagrams;
struct socket *sock;
struct mmsghdr __user *entry;
struct compat_mmsghdr __user *compat_entry;
struct msghdr msg_sys;
struct timespec end_time;
if (timeout
poll_select_set_timeout(end_time, timeout-tv_sec,
timeout-tv_nsec))
return -EINVAL;
datagrams = 0;
sock = sockfd_lookup_light(fd, err, fput_needed);
if (!sock)
return err;
err = sock_error(sock-sk);
if (err)
goto out_put;
entry = mmsg;
compat_entry = (struct compat_mmsghdr __user *)mmsg;
while (datagrams vlen) {
/*
* No need to ask LSM for more than the first datagram.
*/
if (MSG_CMSG_COMPAT flags) {
err = __sys_recvmsg(sock, (struct msghdr __user
*)compat_entry,
msg_sys, flags, datagrams);
if (err 0)
break;
err = __put_user(err, compat_entry-msg_len);
++compat_entry;
} else {
err = __sys_recvmsg(sock, (struct msghdr __user *)entry,
msg_sys, flags, datagrams);
if (err 0)
break;
err = put_user(err, entry-msg_len);
++entry;
}
if (err)
break;
++datagrams;
if (timeout) {
ktime_get_ts(timeout);
*timeout = timespec_sub(end_time, *timeout);
if (timeout-tv_sec 0) {
timeout-tv_sec = timeout-tv_nsec = 0;
break;
}
/* Timeout, return less than vlen datagrams */
if (timeout-tv_nsec == 0 timeout-tv_sec == 0)
break;
}
/* Out of band data, return right away */
if (msg_sys.msg_flags MSG_OOB)
break;
}
out_put:
fput_light(sock-file, fput_needed);
if (err == 0)
return datagrams;
if (datagrams != 0) {
/*
* We may return less entries than requested (vlen) if the
* sock is non block and there aren't enough datagrams...
*/
if (err != -EAGAIN) {
/*
* ... or if recvmsg returns an error after we
* received some datagrams, where we record the
* error to return on the next call or if the
* app asks about it using getsockopt(SO_ERROR).
*/
sock-sk-sk_err = -err;
}
return datagrams;
}
return err;
}
Let's say there are 2 packets at the socket, and I try:
timespec t = {0, 0};
recvmmsg(fd, mmsg, vlen, 0, t);
Then, because of these lines:
if (timeout-tv_nsec == 0 timeout-tv_sec == 0)
break;
recvmmsg() will just return 1 packet instead of 2. Am I right?
It seems defecting the one of the main purposes of recvmmsg() -- trying to
reduce # of system calls when there are packet queued.
Maybe I miss something?
I created a small test case that it waits for epoll callback, sleeps for 2-5
seconds and then calls recvmmsg() with timeout=0 (not null; just like above).
Then, I found that recvmmsg() doesn't return all the packets that queued in 1
single call.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: sendmmsg() Expected Behavior?
On Thu, 23 Oct 2014 19:43:07 -0700, Hei Chan said: Then, I found that recvmmsg() doesn't return all the packets that queued in 1 single call. You want to receive *all* of them? Call recv() with a *buf and a len big enough to get a *lot* of msgs, and pass MSG_ALL in the flags. Why were you expecting recvmsg() to return more than one message? pgpImNQccMDXF.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: sendmmsg() Expected Behavior?
First of all, I apologize for the wrong subject. It should be recvmmsg() not sendmmsg(). Based on the source code (in my previous email), it doesn't seem like MSG_ALL has any effect (I don't know MSG_ALL exists either). Yes, I expect (or at least wish) recvmmsg() will return as many packet as possible before timeout, and if timeout is zero, it should keep trying to fill up the buffer until it is full or there is no more packet. The reason I expect or wish such behavior is that the main idea behind recvmmsg() is that application can reduce the number system call, and so the throughput will go up and latency will go down. Otherwise, the user could just simply use recvmsg() to mimic what recvmmsg() is doing. I don't expect recvmsg() returns more than 1 message but I do expect and wish recvmmsg() returns more than 1 message. On Friday, October 24, 2014 11:41 AM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: On Thu, 23 Oct 2014 19:43:07 -0700, Hei Chan said: Then, I found that recvmmsg() doesn't return all the packets that queued in 1 single call. You want to receive *all* of them? Call recv() with a *buf and a len big enough to get a *lot* of msgs, and pass MSG_ALL in the flags. Why were you expecting recvmsg() to return more than one message? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
