BUG? Oops: kernel NULL pointer dereference in drbd_connector_callback

[Robert Dahlem]

Hi,

I'm trying to install DRBD 0.8.3.4 on top of Linux 2.6.31.3.

# make KDIR=/usr/src/linux kernel-patch
# cd /usr/src/linux
# patch -p1 </xxx/drbd-8.3.4/patch-linux-drbd-8.3.4
# make menuconfig
        CONFIG_CONNECTOR=y
        CONFIG_PROC_EVENTS not set
        CONFIG_BLK_DEV_DRBD=m
        CONFIG_DRBD_TRACE not set
        CONFIG_CRYPTO_HMAC=m
        CONFIG_CRYPTO_SHA1=m

When trying to start DRBD I get an Oops:

=========================================================================
kernel: drbd: initialized. Version: 8.3.4 (api:88/proto:86-91)
kernel: drbd: GIT-hash: 70a645ae080411c87b4482a135847d69dc90a6a2 build
by dahlem@xxxxxx01, 2009-10-16 18:51:20
kernel: drbd: registered as block device major 147
kernel: drbd: minor_table @ 0xf770b540
kernel: klogd 1.4.1, ---------- state change ----------
kernel: BUG: unable to handle kernel NULL pointer dereference at 00000016
kernel: IP: [<f84d8bea>] drbd_connector_callback+0x3e/0x185 [drbd]
kernel: *pdpt = 0000000036808001 *pde = 0000000000000000
kernel: Oops: 0000 [#1] SMP
kernel: last sysfs file: /sys/module/drbd/parameters/cn_idx
kernel: Modules linked in: drbd crypto xt_pkttype xt_tcpudp xt_limit
xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack
nf_defrag_ipv4 iptable_filter ipt_REJECT ipt_LOG ip_tables x_tables loop
usbhid hid uhci_hcd usbcore sr_mod cdrom pcspkr nls_base 8250_pnp tg3
8250 libphy serial_core e1000e unix
kernel:
kernel: Pid: 8, comm: events/1 Not tainted (2.6.31.3 #1) PRIMERGY RX100S5
kernel: EIP: 0060:[<f84d8bea>] EFLAGS: 00010202 CPU: 1
kernel: EIP is at drbd_connector_callback+0x3e/0x185 [drbd]
kernel: EAX: c435e238 EBX: 00000000 ECX: 00000001 EDX: 00000098
kernel: ESI: f6945e10 EDI: f770ba48 EBP: c435c204 ESP: f7473f64
kernel:  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
kernel: Process events/1 (pid: 8, ti=f7472000 task=f743e040
task.ti=f7472000)
kernel: Stack:
kernel:  f74c1640 c11425d6 b6d19395 f770ba40 c11423df f770ba48 c435c204
c11423f8
kernel: <0> b6d19395 c435c200 c10380fd c435c20c 00000000 f743e040
c103b9f3 f7473fa0
kernel: <0> f7473fa0 b6d19395 f7441f4c c435c200 c103802e 00000000
c103b6a5 00000000
kernel: Call Trace:
kernel:  [<c11425d6>] ? cn_queue_create+0x0/0x60
kernel:  [<c11423df>] ? cn_queue_wrapper+0x0/0x41
kernel:  [<c11423f8>] ? cn_queue_wrapper+0x19/0x41
kernel:  [<c10380fd>] ? worker_thread+0xcf/0x159
kernel:  [<c103b9f3>] ? autoremove_wake_function+0x0/0x4f
kernel:  [<c103802e>] ? worker_thread+0x0/0x159
kernel:  [<c103b6a5>] ? kthread+0x7a/0x7f
kernel:  [<c103b62b>] ? kthread+0x0/0x7f
kernel:  [<c1003747>] ? kernel_thread_helper+0x7/0x10
kernel: Code: 24 08 31 c0 64 8b 0d 80 56 2e c1 83 3d 08 da 4e f8 02 0f
84 35 01 00 00 a1 20 db 4e f8 03 04 8d 1c cf 29 c1 ff 00 ba 98 00 00 00
<f6> 43 16 20 0f 84 f3 00 00 00 8d 6e 14 89 e8 e8 06 ff ff ff ba
kernel: EIP: [<f84d8bea>] drbd_connector_callback+0x3e/0x185 [drbd]
SS:ESP 0068:f7473f64
kernel: CR2: 0000000000000016
kernel: ---[ end trace aace275fd7626d33 ]---
=========================================================================

Anything I can do to localize this?

Thanks in advance for any help.

Regards,
        Robert
_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user

[Robert Dahlem]

Hi,

On 16.10.2009 19:54, Robert Dahlem wrote:

> I'm trying to install DRBD 0.8.3.4 on top of Linux 2.6.31.3.

> When trying to start DRBD I get an Oops:

Does also happen with Kernels 2.6.30.9 and 2.6.31.4 with the same symptoms.

I could try with DRBD 8.2.7 or 8.016 but I think this would force me to
Kernel 2.6.28.x. Is that correct?

Regards,
        Robert
_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user

[Lars Ellenberg]

On Sun, Oct 18, 2009 at 06:31:06PM +0200, Robert Dahlem wrote:
> Hi,
>
> On 16.10.2009 19:54, Robert Dahlem wrote:
>
> > I'm trying to install DRBD 0.8.3.4 on top of Linux 2.6.31.3.
>
> > When trying to start DRBD I get an Oops:
>
> Does also happen with Kernels 2.6.30.9 and 2.6.31.4 with the same symptoms.

Did it even occur to you that you could also try the "usual"
out-of tree module build? I really regret that I created that
"kernel-patch" make target in the first place.
You are not supposed to do that.


Did read the list archive?
I admit the Subject is misleading, but it is your problem:
 "oops on create-md", last week.

--
: Lars Ellenberg                
: LINBIT HA-Solutions GmbH
: DRBD®/HA support and consulting    http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list   --   I'm subscribed
_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user

[Florian Haas-3]

On 2009-10-19 11:51, Lars Ellenberg wrote:

> On Sun, Oct 18, 2009 at 06:31:06PM +0200, Robert Dahlem wrote:
>> Hi,
>>
>> On 16.10.2009 19:54, Robert Dahlem wrote:
>>
>>> I'm trying to install DRBD 0.8.3.4 on top of Linux 2.6.31.3.
>>> When trying to start DRBD I get an Oops:
>> Does also happen with Kernels 2.6.30.9 and 2.6.31.4 with the same symptoms.
>
> Did it even occur to you that you could also try the "usual"
> out-of tree module build? I really regret that I created that
> "kernel-patch" make target in the first place.
> You are not supposed to do that.

I have removed the relevant section from the User's Guide. Maybe this
will keep people from attempting this in the future. Please build the
module, don't patch the kernel.

http://www.drbd.org/users-guide/s-build-from-source.html#s-build-compile-kernel-module

Cheers,
Florian



_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user

[Stef Morrell]

> -----Original Message-----
> From: drbd-user-bounces@...
> [mailto:drbd-user-bounces@...] On Behalf Of Florian Haas
> Sent: 19 October 2009 11:28
> To: drbd-user@...
> Subject: Re: [DRBD-user] BUG? Oops: kernel NULL
> pointerdereference in drbd_connector_callback
>
> > Did it even occur to you that you could also try the "usual"
> > out-of tree module build? I really regret that I created that
> > "kernel-patch" make target in the first place.
> > You are not supposed to do that.
>
> I have removed the relevant section from the User's Guide.
> Maybe this will keep people from attempting this in the
> future. Please build the module, don't patch the kernel.
>
> http://www.drbd.org/users-guide/s-build-from-source.html#s-bui
> ld-compile-kernel-module

In fairness, this is why I have been using it, faithfully following
documentation. Probably indeed best to remove it.

To the OP, if you build the module against the running kernel ("Building
DRBD for the currently-running kernel") that should set up the necessary
changes in config for the source to match properly with your kernel
version. You can then skip installing the module and make a kernel patch
with the make KDIR=/blah/linux kernel-patch and it will likely work
properly.

Failing that, you will have to use drbd driver as a module, rather than
compiled in directly.

Regards

Stef
_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user

[Robert Dahlem]

On 19.10.2009 11:51, Lars Ellenberg wrote:

>>> I'm trying to install DRBD 0.8.3.4 on top of Linux 2.6.31.3.
>>> When trying to start DRBD I get an Oops:

> Did it even occur to you that you could also try the "usual"
> out-of tree module build?

Sorry, but no, that didn't occur to me. I used the kernel-patch method
since 0.7 and always preferred it, because there are two drawbacks with
the "usual" method:

1.) If you prepare your system for a new kernel version you need to
remember a special depmod command to prevent ending up with "modprobe:
FATAL: Module drbd not found" after a reboot:

        depmod -ae `cat /usr/src/linux/include/config/kernel.release`

That was not needed with the kernel-patch method.

2.) If you have a running system and recompile/reinstall your kernel,
after "make modules_install" the drbd module is gone. You always need to
remember to change to the drbd directory and do "make install" again.

Anyway. I guess these woes will be gone when DRBD is integrated into the
kernel. Will it get pulled into 2.6.32?

> I really regret that I created that "kernel-patch" make target in the
> first place. You are not supposed to do that.

Sorry again, but I did not read anything like "You are not supposed to
do 'kernel-patch'" or "deprecated" when checking the documentation.

Anyway: I did that and it worked now. Thank you.

> Did read the list archive?
> I admit the Subject is misleading, but it is your problem:
>  "oops on create-md", last week.

Sorry, I searched for "drbd oops drbd_connector_callback" and the "oops
on create-md" thread did not come up, because the dmesg output is hidden
in an attachement.

After I read the thread, I tried the method Stef came up with:
        make all
        make kernel-patch
and that works too.

Regards,
        Robert

P.S.: Sorry if I wrote something offensive. I'm not a native english
speaker. Beg your pardon!
_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user

[Lars Ellenberg]

On Mon, Oct 19, 2009 at 02:43:52PM +0200, Robert Dahlem wrote:

> On 19.10.2009 11:51, Lars Ellenberg wrote:
>
> >>> I'm trying to install DRBD 0.8.3.4 on top of Linux 2.6.31.3.
> >>> When trying to start DRBD I get an Oops:
>
> > Did it even occur to you that you could also try the "usual"
> > out-of tree module build?
>
> Sorry, but no, that didn't occur to me. I used the kernel-patch method
> since 0.7 and always preferred it, because there are two drawbacks with
> the "usual" method:
>
> 1.) If you prepare your system for a new kernel version you need to
> remember a special depmod command to prevent ending up with "modprobe:
> FATAL: Module drbd not found" after a reboot:
>
> depmod -ae `cat /usr/src/linux/include/config/kernel.release`
>
> That was not needed with the kernel-patch method.
>
> 2.) If you have a running system and recompile/reinstall your kernel,
> after "make modules_install" the drbd module is gone. You always need to
> remember to change to the drbd directory and do "make install" again.

So you alwasy roll your own kernel.  Ok.

I think "most" use a distro kernel, and most distros solve those
problems with package management, dependencies and trigger scripts,
maybe a system like dkms and possibly a lazy depmod during boot.

BTW, your drbd build is likely to have been broken for some reason or
other in the past as well, unless you always happened to use a kernel
version matching the "drbd_config.h" compatibility defines as shipped
in the tarball. Though, admittedly, until now it would probably not have
been breakage in such a spectacular way ;)

> Anyway. I guess these woes will be gone when DRBD is integrated into the
> kernel. Will it get pulled into 2.6.32?

No, that has been rejected.
It is very likely to be in 2.6.33, though:
http://lkml.org/lkml/2009/10/1/385

> > I really regret that I created that "kernel-patch" make target in the
> > first place. You are not supposed to do that.
>
> Sorry again, but I did not read anything like "You are not supposed to
> do 'kernel-patch'" or "deprecated" when checking the documentation.

I'm sorry that I came accross so rude.
I was just "people do actually use that
and expect it to work? wtf...".

Cheers,

--
: Lars Ellenberg                
: LINBIT HA-Solutions GmbH
: DRBD®/HA support and consulting    http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list   --   I'm subscribed
_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user

[Dimitrij Hilt-5]

Lars Ellenberg schrieb:

> On Mon, Oct 19, 2009 at 02:43:52PM +0200, Robert Dahlem wrote:
>  
>> On 19.10.2009 11:51, Lars Ellenberg wrote:
>>
>>    
>>>>> I'm trying to install DRBD 0.8.3.4 on top of Linux 2.6.31.3.
>>>>> When trying to start DRBD I get an Oops:
>>>>>          
>>> Did it even occur to you that you could also try the "usual"
>>> out-of tree module build?
>>>      
>> Sorry, but no, that didn't occur to me. I used the kernel-patch method
>> since 0.7 and always preferred it, because there are two drawbacks with
>> the "usual" method:
>>
>> 1.) If you prepare your system for a new kernel version you need to
>> remember a special depmod command to prevent ending up with "modprobe:
>> FATAL: Module drbd not found" after a reboot:
>>
>> depmod -ae `cat /usr/src/linux/include/config/kernel.release`
>>
>> That was not needed with the kernel-patch method.
>>
>> 2.) If you have a running system and recompile/reinstall your kernel,
>> after "make modules_install" the drbd module is gone. You always need to
>> remember to change to the drbd directory and do "make install" again.
>>    
>
> So you alwasy roll your own kernel.  Ok.
>
> I think "most" use a distro kernel, and most distros solve those
> problems with package management, dependencies and trigger scripts,
> maybe a system like dkms and possibly a lazy depmod during boot.
>  

Same problem here with Debian, Kernel 2.6.30-bpo.1-amd64 from
backports.org and DRBD-8.3.5. DRBD was build as modules source an
compiled as Module for this kernel. Server was running 8.3.0 a long time
without any problems. After update if drbd starts we get anytime a
kernel Oops:
[   17.027785] drbd: initialized. Version: 8.3.5 (api:88/proto:86-91)
[   17.040206] drbd: GIT-hash: ded8cdf09b0efa1460e8ce7a72327c60ff2210fb
build by
 root@buildd-amd64-lenny, 2009-10-29 09:14:30
[   17.062360] drbd: registered as block device major 147
[   17.072698] drbd: minor_table @ 0xffff88082a189c80
[   17.095344] BUG: unable to handle kernel NULL pointer dereference at
00000000
00000298
[   17.099325] IP: [<ffffffffa0317276>]
drbd_connector_callback+0x38/0x18b [drbd
]
[   17.099325] PGD 828497067 PUD 8284fc067 PMD 0
[   17.099325] Oops: 0000 [#1] SMP
[   17.099325] last sysfs file: /sys/module/drbd/parameters/cn_idx
[   17.099325] CPU 0
[   17.099325] Modules linked in: drbd cn bond0 xfs exportfs bnx2
snd_pcm snd_ti
mer snd soundcore parport_pc snd_page_alloc parport rng_core evdev
serio_raw i50
00_edac i2c_i801 i2c_core edac_core pcspkr i5k_amb container button
shpchp pci_h
otplug processor ext2 mbcache dm_mirror dm_region_hash dm_log
dm_snapshot dm_mod
 ide_cd_mod cdrom ata_generic libata sg sd_mod crc_t10dif arcmsr piix
ide_pci_ge
neric ehci_hcd ide_core uhci_hcd scsi_mod e1000 e1000e floppy thermal
fan therma
l_sys [last unloaded: ipmi_msghandler]
[   17.099325] Pid: 27, comm: events/0 Not tainted 2.6.30-bpo.1-amd64 #1
X7DB8
[   17.099325] RIP: 0010:[<ffffffffa0317276>]  [<ffffffffa0317276>]
drbd_connect
or_callback+0x38/0x18b [drbd]
[   17.099325] RSP: 0018:ffff88082ce3fe70  EFLAGS: 00010202
[   17.099325] RAX: ffff88002811add8 RBX: ffff8808295fa440 RCX:
0000000000000282
[   17.099325] RDX: 0000000000000000 RSI: 0000000000000282 RDI:
ffff880828cfa010
[   17.099325] RBP: ffff88002811ca40 R08: 0000000000000000 R09:
0000000000000c31
[   17.099325] R10: 0000000000000000 R11: 0000000000000c31 R12:
ffff880828cfa010
[   17.099325] R13: ffff8808295fa458 R14: ffff88082ce18fa0 R15:
ffffffffa01ed203
[   17.099325] FS:  0000000000000000(0000) GS:ffff880028108000(0000)
knlGS:00000
00000000000
[   17.099325] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[   17.099325] CR2: 0000000000000298 CR3: 000000082850d000 CR4:
00000000000006e0
[   17.099325] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[   17.099325] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[   17.099325] Process events/0 (pid: 27, threadinfo ffff88082ce3e000,
task ffff
88082ce18fa0)
[   17.099325] Stack:
[   17.099325]  ffff8808295fa440 ffff88002811ca40 ffff8808295fa450
ffff8808295fa
458
[   17.099325]  ffff88082ce18fa0 ffffffffa01ed20f ffff88002811ca40
ffffffff80250
fe5
[   17.099325]  ffff88002811ca58 ffff88002811ca48 0000000000000000
ffff88082ce18
fa0
[   17.099325] Call Trace:
[   17.099325]  [<ffffffffa01ed20f>] ? cn_queue_wrapper+0xc/0x28 [cn]
[   17.099325]  [<ffffffff80250fe5>] ? worker_thread+0x174/0x211
[   17.099325]  [<ffffffff80254742>] ? autoremove_wake_function+0x0/0x2e
[   17.099325]  [<ffffffff80250e71>] ? worker_thread+0x0/0x211
[   17.099325]  [<ffffffff80250e71>] ? worker_thread+0x0/0x211
[   17.099325]  [<ffffffff80254386>] ? kthread+0x54/0x80
[   17.099325]  [<ffffffff80210aca>] ? child_rip+0xa/0x20
[   17.099325]  [<ffffffff80254332>] ? kthread+0x0/0x80
[   17.099325]  [<ffffffff80210ac0>] ? child_rip+0x0/0x20
[   17.099325] Code: 41 55 83 3d ec 88 01 00 02 41 54 49 89 fc 55 53 0f
84 52 01
 00 00 48 63 d0 48 8b 05 ed 8a 01 00 48 03 04 d5 d0 8b 61 80 48 ff 00
<f6> 41 16
 20 be 98 00 00 00 0f 84 12 01 00 00 4c 8d 6f 14 4c 89
[   17.099325] RIP  [<ffffffffa0317276>]
drbd_connector_callback+0x38/0x18b [drb
d]
[   17.099325]  RSP <ffff88082ce3fe70>
[   17.099325] CR2: 0000000000000298
[   17.687303] ---[ end trace 66ba0a38e9e11bb3 ]---

Is anythink wrong with drbd-8.3.5?

Regards,

Dimitrij

--
Dimitrij Hilt

_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user

[Philipp Reisner]

On Thursday 29 October 2009 14:30:34 Dimitrij Hilt wrote:

> Lars Ellenberg schrieb:
> > On Mon, Oct 19, 2009 at 02:43:52PM +0200, Robert Dahlem wrote:
> >> On 19.10.2009 11:51, Lars Ellenberg wrote:
> >>>>> I'm trying to install DRBD 0.8.3.4 on top of Linux 2.6.31.3.
> >>>>> When trying to start DRBD I get an Oops:
> >>>
> >>> Did it even occur to you that you could also try the "usual"
> >>> out-of tree module build?
> >>
> >> Sorry, but no, that didn't occur to me. I used the kernel-patch method
> >> since 0.7 and always preferred it, because there are two drawbacks with
> >> the "usual" method:
> >>
> >> 1.) If you prepare your system for a new kernel version you need to
> >> remember a special depmod command to prevent ending up with "modprobe:
> >> FATAL: Module drbd not found" after a reboot:
> >>
> >> depmod -ae `cat /usr/src/linux/include/config/kernel.release`
> >>
> >> That was not needed with the kernel-patch method.
> >>
> >> 2.) If you have a running system and recompile/reinstall your kernel,
> >> after "make modules_install" the drbd module is gone. You always need to
> >> remember to change to the drbd directory and do "make install" again.
> >
> > So you alwasy roll your own kernel.  Ok.
> >
> > I think "most" use a distro kernel, and most distros solve those
> > problems with package management, dependencies and trigger scripts,
> > maybe a system like dkms and possibly a lazy depmod during boot.
>
> Same problem here with Debian, Kernel 2.6.30-bpo.1-amd64 from
> backports.org and DRBD-8.3.5. DRBD was build as modules source an
> compiled as Module for this kernel. Server was running 8.3.0 a long time
> without any problems. After update if drbd starts we get anytime a
> kernel Oops:

Please see here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552439

The issue is, that DRBD has to work on a high number of distribution kernels,
and all these kernels differ in various ways. You can configure the compile
process in drbd_config.h. Actually we deliver a script
(scripts/adjust_drbd_config_h.sh) which looks at the kernel source on your
machine and sets all those little defines in drbd_config.h in a way that
the compilation process works.

Unfortunately, the way the debian packaging works, they never call that
script. For many years no user became aware of that fact, because the
drbd_config.h we ship is the way it should be for the vanilla upstream
kernel. Debian's distribution kernels are usually much closer to the
vanilla kernel than the kernels of the other distributions are.

But now, there is a setting in drbd_config.h (KERNEL_HAS_CN_SKB_PARMS)
that does not break the compilation process, you only get a warning,
but later on the module will OOPS!

Your way out:
Unpack the plain .tar.gz distribution from oss.linbit.com and simply
call make in there. Either use the drbd/drbd.ko from that build,
or copy the correcter drbd_config.h over to your debian packaging
stuff... and redo the module assistant thing...

Also following the user's guild way to produce a .deb should produce
a correct module:

http://www.drbd.org/users-guide/s-build-deb.html

To my knowledge, only the vanilla debian packaging is broken.

>
> Is anythink wrong with drbd-8.3.5?
>

No, it is just a wrong drbd_config.h

-phil
--
: Dipl-Ing Philipp Reisner
: LINBIT | Your Way to High Availability
: Tel: [phone], Fax: [phone]
: http://www.linbit.com

DRBD(R) and LINBIT(R) are registered trademarks of LINBIT, Austria.

_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user

[Norbert Tretkowski-3]

Am Donnerstag, den 29.10.2009, 15:43 +0100 schrieb Philipp Reisner:
> Unfortunately, the way the debian packaging works, they never call that
> script.

I'm aware of this issue, it was the way the Debian package worked when I
took it over.

Unfortunately last time I tried to modify the package so it runs this
script during the build process, I realized that it requires a complete
kernel source tree.

Currently we only depend on the linux-headers package to build DRBD,
looks like we need to change this. I'll take another look at it next
weekend.

        Norbert

_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user

[Lars Ellenberg]

On Thu, Oct 29, 2009 at 04:08:01PM +0100, Norbert Tretkowski wrote:

> Am Donnerstag, den 29.10.2009, 15:43 +0100 schrieb Philipp Reisner:
> > Unfortunately, the way the debian packaging works, they never call that
> > script.
>
> I'm aware of this issue, it was the way the Debian package worked when I
> took it over.
>
> Unfortunately last time I tried to modify the package so it runs this
> script during the build process, I realized that it requires a complete
> kernel source tree.
>
> Currently we only depend on the linux-headers package to build DRBD,
> looks like we need to change this. I'll take another look at it next
> weekend.
>

Nonsense.

We build against kernel header packages all along.
So that is expected to work.

In fact, I just counted in our build environment for the last build run
of 8.3.5, it does work just fine for currently 125 different kernel
versions/releases, including debian etch, lenny, bpo, ubuntu, sles,
rhel...  generating 746 kernel version/release/flavour modules total.
I don't think any of those has complete kernel-sources installed.

If you can't get it to work, how about complaining?

Talk with upstream.
We are here.
We often listen.
We sometimes even answer ;)

That would certainly be better than silently ignoring the "configure",
hoping for the best, and "sometimes" work.

> Norbert

Cheers.

--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list   --   I'm subscribed
_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user

[Norbert Tretkowski-3]

Am Donnerstag, den 29.10.2009, 17:11 +0100 schrieb Lars Ellenberg:
> If you can't get it to work, how about complaining?

Because I decided to completely revert the switch from m-a to dkms,
which was the reason why I took a look at running
scripts/adjust_drbd_config_h.sh during build.

> Talk with upstream.
> We are here.
> We often listen.
> We sometimes even answer ;)

I know.

> That would certainly be better than silently ignoring the "configure",
> hoping for the best, and "sometimes" work.

I'm not aware of problems in Debian before 2.6.31 which resulted from
not running adjust_drbd_config_h.sh.

We have a problem now, so we need to take care of it. But we did not
just "hoping for the best" in the past.

        Norbert

_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user

[Lars Ellenberg]

On Thu, Oct 29, 2009 at 06:05:42PM +0100, Norbert Tretkowski wrote:
> Am Donnerstag, den 29.10.2009, 17:11 +0100 schrieb Lars Ellenberg:
> > If you can't get it to work, how about complaining?
>
> Because I decided to completely revert the switch from m-a to dkms,

 :(

> which was the reason why I took a look at running
> scripts/adjust_drbd_config_h.sh during build.

 :)

> > That would certainly be better than silently ignoring the "configure",
> > hoping for the best, and "sometimes" work.
>
> I'm not aware of problems in Debian before 2.6.31 which resulted from
> not running adjust_drbd_config_h.sh.
>
> We have a problem now, so we need to take care of it. But we did not
> just "hoping for the best" in the past.

Sorry, no offense meant.
Thank you for your time and work.

It seems to have "just worked" for the released debian kernels.
Someone rolling his own kernel may have had a different experience,
when trying to build his modules from there.
But then, she was probably not doing it the debian way ;)

And: Yes. We will try to add some compile time check to actually throw a
compile time _error_ in case this function pointer incompatibility hits.

Thanks,

--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list   --   I'm subscribed
_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user

[Dimitrij Hilt-5]

Philipp Reisner schrieb:

> On Thursday 29 October 2009 14:30:34 Dimitrij Hilt wrote:
>  
>> Lars Ellenberg schrieb:
>>    
>>> On Mon, Oct 19, 2009 at 02:43:52PM +0200, Robert Dahlem wrote:
>>>      
>>>> On 19.10.2009 11:51, Lars Ellenberg wrote:
>>>>        
>>>>>>> I'm trying to install DRBD 0.8.3.4 on top of Linux 2.6.31.3.
>>>>>>> When trying to start DRBD I get an Oops:
>>>>>>>              
>>>>> Did it even occur to you that you could also try the "usual"
>>>>> out-of tree module build?
>>>>>          
>>>> Sorry, but no, that didn't occur to me. I used the kernel-patch method
>>>> since 0.7 and always preferred it, because there are two drawbacks with
>>>> the "usual" method:
>>>>
>>>> 1.) If you prepare your system for a new kernel version you need to
>>>> remember a special depmod command to prevent ending up with "modprobe:
>>>> FATAL: Module drbd not found" after a reboot:
>>>>
>>>> depmod -ae `cat /usr/src/linux/include/config/kernel.release`
>>>>
>>>> That was not needed with the kernel-patch method.
>>>>
>>>> 2.) If you have a running system and recompile/reinstall your kernel,
>>>> after "make modules_install" the drbd module is gone. You always need to
>>>> remember to change to the drbd directory and do "make install" again.
>>>>        
>>> So you alwasy roll your own kernel.  Ok.
>>>
>>> I think "most" use a distro kernel, and most distros solve those
>>> problems with package management, dependencies and trigger scripts,
>>> maybe a system like dkms and possibly a lazy depmod during boot.
>>>      
>> Same problem here with Debian, Kernel 2.6.30-bpo.1-amd64 from
>> backports.org and DRBD-8.3.5. DRBD was build as modules source an
>> compiled as Module for this kernel. Server was running 8.3.0 a long time
>> without any problems. After update if drbd starts we get anytime a
>> kernel Oops:
>>    
>
> Please see here:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552439
>
> The issue is, that DRBD has to work on a high number of distribution kernels,
> and all these kernels differ in various ways. You can configure the compile
> process in drbd_config.h. Actually we deliver a script
> (scripts/adjust_drbd_config_h.sh) which looks at the kernel source on your
> machine and sets all those little defines in drbd_config.h in a way that
> the compilation process works.
>
> Unfortunately, the way the debian packaging works, they never call that
> script. For many years no user became aware of that fact, because the
> drbd_config.h we ship is the way it should be for the vanilla upstream
> kernel. Debian's distribution kernels are usually much closer to the
> vanilla kernel than the kernels of the other distributions are.
>
> But now, there is a setting in drbd_config.h (KERNEL_HAS_CN_SKB_PARMS)
> that does not break the compilation process, you only get a warning,
> but later on the module will OOPS!
>
> Your way out:
> Unpack the plain .tar.gz distribution from oss.linbit.com and simply
> call make in there. Either use the drbd/drbd.ko from that build,
> or copy the correcter drbd_config.h over to your debian packaging
> stuff... and redo the module assistant thing...
>
> Also following the user's guild way to produce a .deb should produce
> a correct module:
>
> http://www.drbd.org/users-guide/s-build-deb.html
>
> To my knowledge, only the vanilla debian packaging is broken.
>  

Does not works for me:
make[1]: Entering directory `/usr/local/src/DRBD/8.3.5/drbd-8.3/drbd'

    Calling toplevel makefile of kernel source tree, which I believe is in
    KDIR=/usr/src/linux-headers-2.6.30-bpo.1-amd64

test -f ../scripts/adjust_drbd_config_h.sh && \
     KDIR=/usr/src/linux-headers-2.6.30-bpo.1-amd64 O= /bin/bash
../scripts/adjust_drbd_config_h.sh
/usr/src/linux-headers-2.6.30-bpo.1-amd64
/usr/local/src/DRBD/8.3.5/drbd-8.3/drbd
ls: cannot access
/usr/src/linux-headers-2.6.30-bpo.1-amd64/include/linux/gfp.h: No such
file or directory
ls: cannot access
/usr/src/linux-headers-2.6.30-bpo.1-amd64/include/linux/types.h: No such
file or directory
ls: cannot access
/usr/src/linux-headers-2.6.30-bpo.1-amd64/include/linux/slab.h: No such
file or directory
ls: cannot access
/usr/src/linux-headers-2.6.30-bpo.1-amd64/include/linux/net.h: No such
file or directory
    Sorry, automagic adjustment of drbd_config.h failed.
    For well known 2.6. kernels, no adjustment to the shipped
drbd_config is necessary.
    You need to verify it yourself.
make[1]: [kbuild] Error 2 (ignored)
make -C /usr/src/linux-headers-2.6.30-bpo.1-amd64  
SUBDIRS=/usr/local/src/DRBD/8.3.5/drbd-8.3/drbd  modules
make[2]: Entering directory `/data/src/linux-headers-2.6.30-bpo.1-amd64'
  CC [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_buildtag.o
  CC [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_bitmap.o
  CC [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_proc.o
  CC [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_worker.o
  CC [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_receiver.o
  CC [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_req.o
  CC [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_actlog.o
  CC [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/lru_cache.o
  CC [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_main.o
  CC [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_strings.o
  CC [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_nl.o
/usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_nl.c: In function
'drbd_nl_init':
/usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_nl.c:2384: warning: passing
argument 3 of 'cn_add_callback' from incompatible pointer type
  CC [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_tracing.o
  LD [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd.o
  LD [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_trace.o
  Building modules, stage 2.
  MODPOST 2 modules
  CC      /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd.mod.o
  LD [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd.ko
  CC      /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_trace.mod.o
  LD [M]  /usr/local/src/DRBD/8.3.5/drbd-8.3/drbd/drbd_trace.ko
make[2]: Leaving directory `/data/src/linux-headers-2.6.30-bpo.1-amd64'
mv .drbd_kernelrelease.new .drbd_kernelrelease
Memorizing module configuration ... done.
make[1]: Leaving directory `/usr/local/src/DRBD/8.3.5/drbd-8.3/drbd'

    Module build was successful.


Any proposal how i can build clean module for backported Kernel?
linux-headers are installed.

Thanks,

Dimitrij

_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user

[Dimitrij Hilt-5]

Philipp Reisner schrieb:

> On Thursday 29 October 2009 14:30:34 Dimitrij Hilt wrote:
>  
>> Lars Ellenberg schrieb:
>>    
>>> On Mon, Oct 19, 2009 at 02:43:52PM +0200, Robert Dahlem wrote:
>>>      
>>>> On 19.10.2009 11:51, Lars Ellenberg wrote:
>>>>        
>>>>>>> I'm trying to install DRBD 0.8.3.4 on top of Linux 2.6.31.3.
>>>>>>> When trying to start DRBD I get an Oops:
>>>>>>>              
>>>>> Did it even occur to you that you could also try the "usual"
>>>>> out-of tree module build?
>>>>>          
>>>> Sorry, but no, that didn't occur to me. I used the kernel-patch method
>>>> since 0.7 and always preferred it, because there are two drawbacks with
>>>> the "usual" method:
>>>>
>>>> 1.) If you prepare your system for a new kernel version you need to
>>>> remember a special depmod command to prevent ending up with "modprobe:
>>>> FATAL: Module drbd not found" after a reboot:
>>>>
>>>> depmod -ae `cat /usr/src/linux/include/config/kernel.release`
>>>>
>>>> That was not needed with the kernel-patch method.
>>>>
>>>> 2.) If you have a running system and recompile/reinstall your kernel,
>>>> after "make modules_install" the drbd module is gone. You always need to
>>>> remember to change to the drbd directory and do "make install" again.
>>>>        
>>> So you alwasy roll your own kernel.  Ok.
>>>
>>> I think "most" use a distro kernel, and most distros solve those
>>> problems with package management, dependencies and trigger scripts,
>>> maybe a system like dkms and possibly a lazy depmod during boot.
>>>      
>> Same problem here with Debian, Kernel 2.6.30-bpo.1-amd64 from
>> backports.org and DRBD-8.3.5. DRBD was build as modules source an
>> compiled as Module for this kernel. Server was running 8.3.0 a long time
>> without any problems. After update if drbd starts we get anytime a
>> kernel Oops:
>>    
>
> Please see here:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552439
>  

Patch from this bug does not works for me. But after i'v removed

#define KERNEL_HAS_CN_SKB_PARMS

i'v compiled DBRD and installed it. No problems more with drbd_connector_callback.

Many thanks for quick response!

Dimitrij


_______________________________________________
drbd-user mailing list
drbd-user@...
http://lists.linbit.com/mailman/listinfo/drbd-user