Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 165536 - net-dialup/fritzcapi - workqueue changes in 2.6.20 causes build failures
Summary: net-dialup/fritzcapi - workqueue changes in 2.6.20 causes build failures
Status: RESOLVED DUPLICATE of bug 163366
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Dialup Developers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-05 23:56 UTC by Michael Biebl
Modified: 2007-07-13 08:49 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
workqueue changes kernel 2.6.20 (workqueue_2.6.20.patch,3.42 KB, patch)
2007-02-05 23:57 UTC, Michael Biebl
Details | Diff
There is log from patching of package, as described in output from emerge (2.6.43-linux-2.6.19-irq_handler.patch-10168.out,13.17 KB, text/plain)
2007-02-14 10:30 UTC, Miroslaw Mieszczak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Biebl 2007-02-05 23:56:04 UTC
fritzcapi does not compile anymore for kernels >= 2.6.20 because of 
http://lwn.net/Articles/213149/
The attached patch fixes that.
It should only be applied for kernels >= 2.6.20 though.

Reproducible: Always

Steps to Reproduce:
Comment 1 Michael Biebl 2007-02-05 23:57:10 UTC
Created attachment 109289 [details, diff]
workqueue changes kernel 2.6.20
Comment 2 Stefan Schweizer (RETIRED) gentoo-dev 2007-02-06 08:14:49 UTC
thanks, fixed!
Comment 3 Daniel Drake (RETIRED) gentoo-dev 2007-02-06 13:19:47 UTC
patch is wrong and will break. please drop it for now. i'll post further explanation later today.
Comment 4 Daniel Drake (RETIRED) gentoo-dev 2007-02-06 14:33:16 UTC
The work functions (e.g. closing_worker) currently take a void* pointer argument. On 2.6.19, this points to the user specified data element, passed in as the third argument to INIT_WORK.

On 2.6.20, the argument to the work function is always the work struct, i.e. a pointer to closing_work in the above example. As the old code has this as void*, the compiler doesn't complain, but infact the code is interpreting that work_struct as if it is the previous user data pointer (capi_card) which is an entirely different area of memory.

The solution is to make the work structs a member variable of the capi_card struct (the user data pointer), and then use an inverse lookup (container_of macro) inside the work function to find out which capi_card contains the pointer to that work item.
Comment 5 Miroslaw Mieszczak 2007-02-14 10:28:30 UTC
>>> Emerging (1 of 1) net-dialup/fritzcapi-2.6.43 to /
 * km_fritzcapi-2.6-43.x86_64.rpm MD5 ;-) ...                             [ ok ]
 * km_fritzcapi-2.6-43.x86_64.rpm RMD160 ;-) ...                          [ ok ]
 * km_fritzcapi-2.6-43.x86_64.rpm SHA1 ;-) ...                            [ ok ]
 * km_fritzcapi-2.6-43.x86_64.rpm SHA256 ;-) ...                          [ ok ]
 * km_fritzcapi-2.6-43.x86_64.rpm size ;-) ...                            [ ok ]
 * checking ebuild checksums ;-) ...                                      [ ok ]
 * checking auxfile checksums ;-) ...                                     [ ok ]
 * checking miscfile checksums ;-) ...                                    [ ok ]
 * checking km_fritzcapi-2.6-43.x86_64.rpm ;-) ...                        [ ok ]
 * Determining the location of the kernel source code
 * Found kernel source directory:
 *     /usr/src/linux
 * Found sources for kernel version:
 *     2.6.20-gentoo
 *
 * You can control the modules which are built with the variable
 * FRITZCAPI_CARDS which should contain a blank separated list
 * of a selection from the following cards:
 *    fcpci fcpcmcia fcusb2
 *
 * I give you the chance of hitting Ctrl-C and make the necessary
 * adjustments in /etc/make.conf.
 * Selected cards:  fcpci fcusb2
>>> Unpacking source...
 * Converting ./Makefile to use M= instead of SUBDIRS= ...                                                                              [ ok ]
 * Converting ./fritz.pci/Makefile to use M= instead of SUBDIRS= ...                                                                    [ ok ]
 * Converting ./fritz.pci/src/Makefile to use M= instead of SUBDIRS= ...                                                                [ ok ]
 * Converting ./fritz.pcmcia/Makefile to use M= instead of SUBDIRS= ...                                                                 [ ok ]
 * Converting ./fritz.pcmcia/src/Makefile to use M= instead of SUBDIRS= ...                                                             [ ok ]
 * Converting ./fritz.usb2/Makefile to use M= instead of SUBDIRS= ...                                                                   [ ok ]
 * Converting ./fritz.usb2/src/Makefile to use M= instead of SUBDIRS= ...                                                               [ ok ]
 * Applying fcusb2-2.6.19.patch ...                                                                                                     [ ok ]
 * Applying 2.6.43-linux-2.6.19-irq_handler.patch ...

 * Failed Patch: 2.6.43-linux-2.6.19-irq_handler.patch !
 *  ( /usr/portage/net-dialup/fritzcapi/files/2.6.43-linux-2.6.19-irq_handler.patch )
 *
 * Include in your bugreport the contents of:
 *
 *   /var/tmp/portage/net-dialup/fritzcapi-2.6.43/temp/2.6.43-linux-2.6.19-irq_handler.patch-10168.out


!!! ERROR: net-dialup/fritzcapi-2.6.43 failed.
Call stack:
  ebuild.sh, line 1614:   Called dyn_unpack
  ebuild.sh, line 751:   Called qa_call 'src_unpack'
  environment, line 4118:   Called src_unpack
  fritzcapi-2.6.43.ebuild, line 114:   Called epatch '/usr/portage/net-dialup/fritzcapi/files/2.6.43-linux-2.6.19-irq_handler.patch'
  eutils.eclass, line 341:   Called die

!!! Failed Patch: 2.6.43-linux-2.6.19-irq_handler.patch!
!!! If you need support, post the topmost build error, and the call stack if relevant.
!!! A complete build log is located at '/var/tmp/portage/net-dialup/fritzcapi-2.6.43/temp/build.log'.
Comment 6 Miroslaw Mieszczak 2007-02-14 10:30:03 UTC
Created attachment 110153 [details]
There is log from patching of package, as described in output from emerge
Comment 7 Miroslaw Mieszczak 2007-02-14 10:33:04 UTC
Comment on attachment 110153 [details]
There is log from patching of package, as described in output from emerge

Sorry, this should be applied to bug #163366
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2007-07-13 08:49:40 UTC

*** This bug has been marked as a duplicate of bug 163366 ***