[lkml]   [2004]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Oops in 2.6.10-rc1

    On Mon, 8 Nov 2004, Christian Kujau wrote:
    > > Anyway, now that the _other_ driver also oopses, and with a very similar
    > > oops too, so it looks like they both depended on some undocumented (or
    > > changed) detail in the PCI layer. Next step would be to see if the thing
    > > that breaks is this merge:
    > may i ask how you come to this conclusion? by technical knowledge or could
    > this be deduced by some bk magic too?

    No, just gut feel. If the pre-merge ALSA works, and the post-merge one
    doesn't, and the oops in both cases happen somewhere close to where it
    does "pci_enable_device()", there's not a lot left. There are interrupts,
    and there is the PCI layer...

    > > ChangeSet@1.2463, 2004-11-04 17:07:16-08:00,
    > > Merge bk://
    > > into
    > >
    > > which merges Greg's PCI/driver model changes.
    > >
    > > It's all the same steps you took with the ALSA merge, you're a
    > > professional by now ;)
    > i did "bk undo -a1.2463" from a current -BK tree and it oopses:

    Note that "bk undo -axxx" will _leave_ xxx in place, and undo everything

    So what you did still has the merge in the tree, and that it still oopses
    is thus to be expected. BUT, we're getting closer.

    > next i wanted to do "bk undo -r1.2463" now to see if it does *not* break
    > without this ChangeSet (because i already know it *breaks* with this
    > ChangeSet) but that would leave some parentless child deltas. i read in
    > the BK docs that "bk cset -x<version>" would help here. but "bk cset
    > - -x1.2463" aborts:

    "cset -x" only works on patches, not on complex operations. You still want
    "bk undo", but you want to use "bk revtool" to see what the merge point
    was, and tell _which_ of the merged top-of-trees you want to get to.

    In other words, you can't just undo a merge, you need to tell which _way_
    to undo it. See? It does actually make sense, and "bk revtool" will show
    you the relationships of merges (at least if the time range is big enough
    to show enough info).

    Anyway, if you have the top-of-tree-is-1.2463, then go to "bk revtool",
    and select that node in the graph by clicking on it. Notice how those
    edges turned white, and you can now easily see which children were

    In this case, the top-of-tree tree _without_ the PCI merge is 1.2642:

    ChangeSet@1.2462, 2004-11-04 17:06:13-08:00,
    Merge bk://

    (you won't see it in "bk changes", since it's a trivial merge: use "bk
    changes -a" to see it). So just before I merged Greg's PCI changes, I
    merged his USB changes.

    Now, that's fine - the USB merge is likely to be ok, so try doing

    bk undo -a1.2462

    and you will now have a tree that is exactly the same as before, except it
    does _not_ have the PCI merge from Greg.

    And if this one does not oops, you can now officially blame Greg.

    Now, if you want to get _really_ fancy, you can now look at each changeset
    that differed, with something like

    bk set -n -d -r1.2462 -r1.2463 | bk -R prs -h -d'<:P:@:HOST:>\n$each(:C:){\t(:C:)\n}\n' -

    which is black magic that does a set operation and shows all the changes
    in between the sets of "bk at 1.2462" and "bk at 1.2463".

    (This is _not_ the same as "bk changes -r1.2462..1.2463", because that one
    just shows the single merge change that is on the direct _path_ from one
    changeset to another. The black magic thing shows the set difference of
    changesets that comes from the full graph at two points).

    Then you can look at each change individually and see if they matter.

    And once you can do the set operations, you're officially a BK poweruser.
    Me, I just have a script, I'm a BK dabbler.

    Looking at the list (appended), I don't see anything obvious, but hey, if
    it was obvious it wouldn't have been merged in the first place.

    Thanks for your willingness to pursue this thing,


    [PATCH] sysfs: fix sysfs backing store error path confusion

    o sysfs_new_dirent to retrun 0 if kmalloc fails. Thanks to Milton Miller
    for spotting this.

    Signed-off-by: Maneesh Soni <>
    Signed-off-by: Greg Kroah-Hartman <>

    [PATCH] small sysfs cleanups

    The patch below does the following cleanups for the sysfs code:
    - remove the unused global function sysfs_mknod
    - make some structs and functions static

    Please check whether this patch is correct, or whether some of the
    things I made static should be used globally in the forseeable future.

    Signed-off-by: Adrian Bunk <>
    Signed-off-by: Greg Kroah-Hartman <>

    [PATCH] add the physical device and the bus to the hotplug environment

    Add the sysfs path of the physical device to the hotplug event of class
    and block devices. This should solve the userspace issue not to know if
    the device is a virtual one and the "device" symlink will never be created,
    but we sit there and wait for it to show up not knowing when we should
    give up.

    Also the bus name is added to the hotplug event, so we don't need to
    reverse lookup in the /sys/bus/* directory which bus our physical
    device belongs to. This is e.g. the value matched against the BUS= key,
    that may be used in an udev rule.

    This is a PCI network card:

    This is a IDE CDROM:

    This is an USB-stick partition:

    Signed-off-by: Kay Sievers <>
    Signed-off-by: Greg Kroah-Hartman <>

    [PATCH] driver-model: comment fix in bus.c


    bus_match() was renamed to driver_probe_device() but the comment for
    device_attach() wasn't updated. This patch updates it.

    Signed-off-by: Tejun Heo <>
    Signed-off-by: Greg Kroah-Hartman <>

    [PATCH] driver-model: bus_recan_devices() locking fix


    bus_rescan_devices() eventually calls device_attach() and thus
    requires write locking the corresponding bus. The original code just
    called bus_for_each_dev() which only read locks the bus. This patch
    separates __bus_for_each_dev() and __bus_for_each_drv(), which don't
    do locking themselves, out from the original functions and call them
    with read lock in the original functions and with write lock in

    Signed-off-by: Tejun Heo <>
    Signed-off-by: Greg Kroah-Hartman <>

    [PATCH] driver-model: sysfs_release() dangling pointer reference fix


    Some attributes are allocated dynamically (e.g. module and device
    parameters) and are usually deallocated when the assoicated kobject is
    released. So, it's not safe to access attr after putting the kobject.

    Signed-off-by: Tejun Heo <>
    Signed-off-by: Greg Kroah-Hartman <>

    [PATCH] driver-model: kobject_add() error path reference counting fix


    In kobject_add(), @kobj wasn't put'd properly on error path. This
    patch fixes it.

    Signed-off-by: Tejun Heo <>
    Signed-off-by: Greg Kroah-Hartman <>

    [PATCH] driver-model: device_add() error path reference counting fix


    In device_add(), @dev wan't put'd properly when it has zero length
    bus_id (error path). Fixed.

    Signed-off-by: Tejun Heo <>
    Signed-off-by: Greg Kroah-Hartman <>

    kevent: fix build error if CONFIG_KOBJECT_UEVENT is not selected.

    Thanks to Serge Hallyn <> for pointing this out.

    Signed-off-by: Greg Kroah-Hartman <>

    [PATCH] kobject_uevent: fix init ordering

    Looks like kobject_uevent_init is executed before netlink_proto_init and
    consequently always fails. Not cool.

    Attached patch switches the initialization over from core_initcall (init
    level 1) to postcore_initcall (init level 2). Netlink's initialization
    is done in core_initcall, so this should fix the problem. We should be
    fine waiting until postcore_initcall.

    Also a couple white space changes mixed in, because I am anal.

    Signed-Off-By: Robert Love <>
    Signed-off-by: Greg Kroah-Hartman <>

    [PATCH] kobject_uevent: add MAINTAINER entry

    Attached patch adds a MAINTAINER entry for the kernel event layer.

    Signed-Off-By: Robert Love <>
    Signed-off-by: Greg Kroah-Hartman <>


    [PATCH] fix kernel BUG at fs/sysfs/dir.c:20!

    On Thu, Nov 04, 2004 at 12:52:38PM -0800, Greg KH wrote:
    > Hi,
    > I get the following BUG in the sysfs code when I do:
    > - plug in a usb-serial device.
    > - open the port with 'cat /dev/ttyUSB0'
    > - unplug the device.
    > - stop the 'cat' process with control-C
    > This used to work just fine before your big sysfs changes.

    There is a similar problem reported by s390 people where we see parent
    kobject (directory) going away before child kobject (sub-directory). It
    seems kobject code is able to handle this, but not the sysfs. What could
    be happening that in sysfs_remove_dir() of parent directory, we try to
    remove its contents. It works well with the regular files as it is the
    final removal for sysfs_dirent corresponding to the files. But in case
    of sub-directory we are doing an extra sysfs_put(). Once while removing
    parent and the other one being the one from when sysfs_remove_dir() is
    called for the child.

    The following patch worked for the s390 people, I hope same will work in
    this case also.

    o Do not remove sysfs_dirents corresponding to the sub-directory in
    sysfs_remove_dir(). They will be removed in the sysfs_remove_dir() call
    for the specific sub-directory.

    Signed-off-by: Maneesh Soni <>
    Signed-off-by: Greg Kroah-Hartman <>

    Merge bk://

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-11-18 23:46    [W:0.037 / U:6.860 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site