Re: 2.6.24-git16 Oops @ sysfs_move_dir w/ btdelconn
On Feb 17, 2008 4:59 AM, Dave Young <[EMAIL PROTECTED]> wrote: > > On Feb 16, 2008 1:16 PM, Barnaby <[EMAIL PROTECTED]> wrote: > > > > On Fri, Feb 15, 2008 at 6:15 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > > > > > On Fri, Feb 15, 2008 at 8:04 AM, Barnaby <[EMAIL PROTECTED]> wrote: > > > > Answers at the bottom.. > > > > > > > > > > > > > > > > On 2/13/08, Dave Young <[EMAIL PROTECTED]> wrote: > > > > > On Feb 8, 2008 12:57 AM, Barnaby <[EMAIL PROTECTED]> wrote: > > > > > > Hello Dave, > > > > > > > > > > Add someone to cc-list > > > > > > > > > > > > > > > > > > > > > > Got your name and email from the 2.6.24-git16 changelog. > > > > > > > > > > > > I get these Oops when suspending or doing.. > > > > > > > > > > > > echo disable > /proc/acpi/ibm/bluetooth > > > > > > or > > > > > > echo 0 > /sys/devices/platform/thinkpad_acpi/bluetooth_enable > > > > > > > > > > > > # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > - - > > > > > > > > > > > > Feb 7 09:19:47 BUG: unable to handle kernel NULL pointer > > > dereference > > > > > > at 0008 > > > > > > Feb 7 09:19:47 IP: [] sysfs_move_dir+0x16/0x1ab > > > > > > Feb 7 09:19:47 *pde = > > > > > > Feb 7 09:19:47 Oops: [#1] PREEMPT > > > > > > Feb 7 09:19:47 Modules linked in: xt_tcpudp hidp l2cap snd_seq > > > > > > snd_seq_device snd_pcm_oss snd_mixer_oss sr_mod cdrom > > > iptable_filter > > > > > > iptable_nat nf_conntrack_ipv4 iptable_mangle ipt_LOG xt_state > > > ipt_ttl > > > > > > ipt_MASQUERADE nf_nat nf_conntrack xt_DSCP ip_tables x_tables > > > usbhid > > > > > > ipw2200 ieee80211 ieee80211_crypt thinkpad_acpi backlight > > > acpi_cpufreq > > > > > > radeon drm intel_agp agpgart snd_intel8x0 snd_ac97_codec ac97_bus > > > > > > snd_pcm snd_timer snd soundcore snd_page_alloc button > > > > > > thermal processor hci_usb bluetooth > > > > > > Feb 7 09:19:47 > > > > > > Feb 7 09:19:47 Pid: 1412, comm: btdelconn Not tainted > > > (2.6.24-git16 #1) > > > > > > Feb 7 09:19:47 EIP: 0060:[] EFLAGS: 00010246 CPU: 0 > > > > > > Feb 7 09:19:47 EIP is at sysfs_move_dir+0x16/0x1ab > > > > > > Feb 7 09:19:47 EAX: c039476c EBX: f7dd0480 ECX: f6da9f58 EDX: > > > f7dd0480 > > > > > > Feb 7 09:19:47 ESI: EDI: f5ea0c40 EBP: fff4 ESP: > > > f6da9f30 > > > > > > Feb 7 09:19:47 DS: 007b ES: 007b FS: GS: SS: 0068 > > > > > > Feb 7 09:19:47 Process btdelconn (pid: 1412, ti=f6da8000 > > > > > > task=f6fd1550 task.ti=f6da8000) > > > > > > Feb 7 09:19:47 Stack: f56f4ea4 f7dd0480 f5ea0c40 f56f4ea4 > > > f7dd0480 > > > > > > f5ea0c40 fff4 c01c71a0 > > > > > > Feb 7 09:19:47 f5ea0800 c034a793 f5ea0c40 f5ea0800 f5ea0800 > > > > > > > > > f56f4e3c > > > > > > Feb 7 09:19:47 f7dd0480 c0219d48 f56f4ea4 ffea > > > f56f4e3c > > > > > > f5fc7c88 f5fc7c00 > > > > > > Feb 7 09:19:47 Call Trace: > > > > > > Feb 7 09:19:47 [] kobject_move+0x9e/0xeb > > > > > > Feb 7 09:19:47 [] device_move+0x41/0xdf > > > > > > Feb 7 09:19:47 [] del_conn+0x0/0x43 [bluetooth] > > > > > > Feb 7 09:19:47 [] del_conn+0x11/0x43 [bluetooth] > > > > > > Feb 7 09:19:47 [] run_workqueue+0x83/0x10e > > > > > > Feb 7 09:19:47 [] worker_thread+0x0/0xb5 > > > > > > Feb 7 09:19:47 [] worker_thread+0xab/0xb5 > > > > > > Feb 7 09:19:47 [] autoremove_wake_function+0x0/0x2d > > > > > > Feb 7 09:19:47 [] kthread+0x36/0x5c > > > > > > Feb 7 09:19:47 [] kthread+0x0/0x5c > > > > > > Feb 7 09:19:47 [] kernel_thread_helper+0x7/0x10 > >
Re: 2.6.24-git16 Oops @ sysfs_move_dir w/ btdelconn
On Fri, Feb 15, 2008 at 6:15 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > On Fri, Feb 15, 2008 at 8:04 AM, Barnaby <[EMAIL PROTECTED]> wrote: > > Answers at the bottom.. > > > > > > > > On 2/13/08, Dave Young <[EMAIL PROTECTED]> wrote: > > > On Feb 8, 2008 12:57 AM, Barnaby <[EMAIL PROTECTED]> wrote: > > > > Hello Dave, > > > > > > Add someone to cc-list > > > > > > > > > > > > > > Got your name and email from the 2.6.24-git16 changelog. > > > > > > > > I get these Oops when suspending or doing.. > > > > > > > > echo disable > /proc/acpi/ibm/bluetooth > > > > or > > > > echo 0 > /sys/devices/platform/thinkpad_acpi/bluetooth_enable > > > > > > > > # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > > > > > > Feb 7 09:19:47 BUG: unable to handle kernel NULL pointer > dereference > > > > at 0008 > > > > Feb 7 09:19:47 IP: [] sysfs_move_dir+0x16/0x1ab > > > > Feb 7 09:19:47 *pde = > > > > Feb 7 09:19:47 Oops: [#1] PREEMPT > > > > Feb 7 09:19:47 Modules linked in: xt_tcpudp hidp l2cap snd_seq > > > > snd_seq_device snd_pcm_oss snd_mixer_oss sr_mod cdrom iptable_filter > > > > iptable_nat nf_conntrack_ipv4 iptable_mangle ipt_LOG xt_state ipt_ttl > > > > ipt_MASQUERADE nf_nat nf_conntrack xt_DSCP ip_tables x_tables > usbhid > > > > ipw2200 ieee80211 ieee80211_crypt thinkpad_acpi backlight > acpi_cpufreq > > > > radeon drm intel_agp agpgart snd_intel8x0 snd_ac97_codec ac97_bus > > > > snd_pcm snd_timer snd soundcore snd_page_alloc button > > > > thermal processor hci_usb bluetooth > > > > Feb 7 09:19:47 > > > > Feb 7 09:19:47 Pid: 1412, comm: btdelconn Not tainted > (2.6.24-git16 #1) > > > > Feb 7 09:19:47 EIP: 0060:[] EFLAGS: 00010246 CPU: 0 > > > > Feb 7 09:19:47 EIP is at sysfs_move_dir+0x16/0x1ab > > > > Feb 7 09:19:47 EAX: c039476c EBX: f7dd0480 ECX: f6da9f58 EDX: > f7dd0480 > > > > Feb 7 09:19:47 ESI: EDI: f5ea0c40 EBP: fff4 ESP: > f6da9f30 > > > > Feb 7 09:19:47 DS: 007b ES: 007b FS: GS: SS: 0068 > > > > Feb 7 09:19:47 Process btdelconn (pid: 1412, ti=f6da8000 > > > > task=f6fd1550 task.ti=f6da8000) > > > > Feb 7 09:19:47 Stack: f56f4ea4 f7dd0480 f5ea0c40 f56f4ea4 f7dd0480 > > > > f5ea0c40 fff4 c01c71a0 > > > > Feb 7 09:19:47 f5ea0800 c034a793 f5ea0c40 f5ea0800 f5ea0800 > > > > > f56f4e3c > > > > Feb 7 09:19:47 f7dd0480 c0219d48 f56f4ea4 ffea > f56f4e3c > > > > f5fc7c88 f5fc7c00 > > > > Feb 7 09:19:47 Call Trace: > > > > Feb 7 09:19:47 [] kobject_move+0x9e/0xeb > > > > Feb 7 09:19:47 [] device_move+0x41/0xdf > > > > Feb 7 09:19:47 [] del_conn+0x0/0x43 [bluetooth] > > > > Feb 7 09:19:47 [] del_conn+0x11/0x43 [bluetooth] > > > > Feb 7 09:19:47 [] run_workqueue+0x83/0x10e > > > > Feb 7 09:19:47 [] worker_thread+0x0/0xb5 > > > > Feb 7 09:19:47 [] worker_thread+0xab/0xb5 > > > > Feb 7 09:19:47 [] autoremove_wake_function+0x0/0x2d > > > > Feb 7 09:19:47 [] kthread+0x36/0x5c > > > > Feb 7 09:19:47 [] kthread+0x0/0x5c > > > > Feb 7 09:19:47 [] kernel_thread_helper+0x7/0x10 > > > > Feb 7 09:19:47 === > > > > Feb 7 09:19:47 Code: ff b8 6c 47 39 c0 e8 64 f1 15 00 89 f0 83 c4 > 10 > > > > 5b 5e 5f 5d c3 55 57 56 53 89 d3 83 ec 0c 8b 70 1c b8 6c 47 39 c0 e8 > > > > 3a f1 15 00 <8b> 56 08 85 d2 75 04 0f 0b eb fe 8b 5b 1c b8 a0 47 39 > c0 > > > > 85 db > > > > Feb 7 09:19:47 EIP: [] sysfs_move_dir+0x16/0x1ab SS:ESP > > > > 0068:f6da9f30 > > > > Feb 7 09:19:47 ---[ end trace e0c3df2b167f1367 ]--- > > > > Feb 7 09:27:44 usb 4-1: new full speed USB device using uhci_hcd > and address 4 > > > > Feb 7 09:27:44 usb 4-1: configuration #1 chosen from 1 choice > > > > Feb 7 09:28:06 BUG: unable to handle kernel NULL pointer > dereference > > > > at 0020 > > > > Feb 7 09:28:06 IP: [] sysf
Question on mmap(2) with kernel alocated memory
I am trying to mmap() into user space a kernel buffer and am having
problems.
I have a simple test example, can someone please tell me what I have got
wrong ?
In a driver I do:
uint*kva;
kva = (uint*)kmalloc(4096, GFP_KERNEL);
*kva = 0x11223344;
printk("Address: %p %lx %x\n", kva, virt_to_phys(kva), *kva);
Now in some simple user program I do:
#include
#include
#include
#include
#include
int main(int argc, char** argv){
int fm;
char* p;
uint* pi;
uint v;
uint add = 0x74b000;
if((fm = open("/dev/mem", O_RDWR)) < 0)
return 1;
p = mmap(0, 128 * 1024 * 1024, PROT_READ|PROT_WRITE, MAP_SHARED, fm,
0);
printf("Mapped: %p\n", p);
lseek(fm, add, SEEK_SET);
read(fm, &v, sizeof(v));
printf("V: %x\n", v);
pi = (uint*)(p + add);
printf("Vmmap: %p %x\n", pi, *pi);
close(fm);
return 0;
}
The value of add is hardcoded to the value printed for the physical
address in the drivers prink routine.
The lseek/read from the /dev/mem device yields the value 0x11223344.
However the mmap method also on /dev/mem yields the value 0.
Whats wrong with my mmap() or kalloc() ?
Terry
--
Dr Terry Barnaby BEAM Ltd
Phone: +44 1454 324512 Northavon Business Center, Dean Rd
Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK
Email: [EMAIL PROTECTED]Web: www.beam.demon.co.uk
BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software Dev
"Tandems are twice the fun !"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Problem with map_user_kiobuf() not mapping to physical memory
We are developing a Linux driver which allows a device to read/write directly into a processes virtual memory space. I have a question on using map_user_kiobuf() as we are having problems. I was under the impression that if I used map_user_kiobuf() this would map the users virtual address space into locked physical memory pages so that I/O could be performed. However, I note that if the user just mallocs memory and does not access it (No physical memory pages created) and then passes this virtual address space to the driver which performs a map_user_kiobuf() on it, the resulting kiobuf structure has all of the pagelist[] physical address entries set to the same value and the maplist[] entries set to 0. The devices access to this memory now causes system problems. Is map_user_kiobuf() working correctly ? Should I call some function to map the virtual address space into physical memory or at least pages before I call map_user_kiobuf() ? Cheers Terry -- Dr Terry Barnaby BEAM Ltd Phone: +44 1454 324512 Northavon Business Center, Dean Rd Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK Email: [EMAIL PROTECTED]Web: www.beam.demon.co.uk BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software Dev "Tandems are twice the fun !" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Process memory DMA access from devices, kiobuf ?
Hi, We are doing work with FPGA's and have a Linux driver for a particular board that has these devices. For performance reasons the driver has the ability to DMA directly to process (user) memory. We have made use of the kiobuf routines such as "map_user_kiobuf()" to map into physical memory the user address space. I note that the RedHat kernels have a patched kernel containing the kiobuf code but the standard linux source does not right up to 2.4.2. Is there a better recommended way to perform DMA access to user memory from a device using the Linux kernel ? Cheers Terry -- Dr Terry Barnaby BEAM Ltd Phone: +44 1454 324512 Northavon Business Center, Dean Rd Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK Email: [EMAIL PROTECTED]Web: www.beam.demon.co.uk BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software Dev "Tandems are twice the fun !" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
