Problem Description ==================== During the installation of Fedora11 beta on power6 Host Ethernet Adapters are not detected. giving a message as below. As network could not be detected it was a blocker for all kinds of network installation on P6. ================== boot: f11 Using 01366ae7 bytes for initrd buffer Please wait, loading kernel... Allocated 01a00000 bytes for kernel @ 02300000 Elf64 kernel loaded... Loading ramdisk... ramdisk loaded 01366ae7 @ 03d00000 OF stdout device is: /vdevice/vty@30000000 Hypertas detected, assuming LPAR ! command line: root=/dev/sdb3 memory layout at init: alloc_bottom : 0000000005067000 alloc_top : 0000000008000000 alloc_top_hi : 0000000008000000 rmo_top : 0000000008000000 ram_top : 0000000008000000 Looking for displays instantiating rtas at 0x00000000074e2000 ... done boot cpu hw idx 0000000000000000 copying OF device tree ... Building dt strings... Building dt structure... Device tree strings 0x0000000005068000 -> 0x00000000050695aa Device tree struct 0x000000000506a000 -> 0x0000000005082000 Calling quiesce ... returning from prom_init Phyp-dump disabled at boot time Using pSeries machine description Using 1TB segments Found initrd at 0xc000000003d00000:0xc000000005066ae7 console [udbg0] enabled Partition configured for 12 cpus. CPU maps initialized for 4 threads per core Starting Linux PPC64 #1 SMP Thu Jan 29 14:47:36 EST 2009 ----------------------------------------------------- ppc64_pft_size = 0x1a physicalMemorySize = 0x80000000 htab_hash_mask = 0x7ffff ----------------------------------------------------- Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.29-0.66.rc3.fc11.ppc64 (mockbuild.phx.redhat.com) (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) ) #1 SMP Thu Jan 29 14:47:36 EST 2009 [boot]0012 Setup Arch EEH: No capable adapters found PPC64 nvram contains 15360 bytes Zone PFN ranges: DMA 0x00000000 -> 0x00080000 Normal 0x00080000 -> 0x00080000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00080000 [boot]0015 Setup Done Built 1 zonelists in Node order, mobility grouping on. Total pages: 510976 Policy zone: DMA Kernel command line: root=/dev/sdb3 [boot]0020 XICS Init [boot]0021 XICS Done PID hash table entries: 4096 (order: 12, 32768 bytes) clocksource: timebase mult[7d0000] shift[22] registered Console: colour dummy device 80x25 console handover: boot [udbg0] -> real [hvc0] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS: 8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 4351 kB per task-struct memory footprint: 2688 bytes Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) allocated 20971520 bytes of page_cgroup please try cgroup_disable=memory option if you don't want freeing bootmem node 0 Memory: 1928712k/2097152k available (14596k kernel code, 168440k reserved, 1080k data, 8874k bss, 6480k init) SLUB: Genslabs=13, HWalign=128, Order=0-3, MinObjects=0, CPUs=12, Nodes=16 Calibrating delay loop... 1021.95 BogoMIPS (lpj=510976) Security Framework initialized SELinux: Initializing. Mount-cache hash table entries: 256 Initializing cgroup subsys ns Initializing cgroup subsys cpuacct Initializing cgroup subsys memory Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys net_cls Processor 1 found. Processor 2 found. Processor 3 found. Brought up 4 CPUs khelper used greatest stack depth: 10944 bytes left khelper used greatest stack depth: 10496 bytes left net_namespace: 2232 bytes regulator: core version 0.5 NET: Registered protocol family 16 IBM eBus Device Driver PCI: Probing PCI hardware bio: create slab <bio-0> at 0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default NET: Registered protocol family 2 IP route cache hash table entries: 65536 (order: 7, 524288 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 10, 4718592 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP reno registered NET: Registered protocol family 1 checking if image is initramfs... it is Freeing initrd memory: 19866k freed IOMMU table initialized, virtual merging enabled audit: initializing netlink socket (disabled) type=2000 audit(1238829565.657:1): initialized HugeTLB registered 16 MB page size, pre-allocated 0 pages HugeTLB registered 16 GB page size, pre-allocated 0 pages VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) msgmni has been set to 3805 alg: No test for stdrng (krng) Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) io scheduler noop registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 pciehp: PCI Express Hot Plug Controller Driver version: 0.4 Linux agpgart interface v0.103 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled TX39/49 Serial driver version 1.11 khelper used greatest stack depth: 10128 bytes left brd: module loaded loop: module loaded Fixed MDIO Bus: probed input: Macintosh mouse button emulation as /devices/virtual/input/input0 Uniform Multi-Platform E-IDE driver Driver 'sd' needs updating - please use bus_type methods Driver 'sr' needs updating - please use bus_type methods ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver uhci_hcd: USB Universal Host Controller Interface driver mice: PS/2 mouse device common for all mice platform ppc-rtc.0: rtc core: registered ppc_md as rtc0 device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid usbhid: v2.6:USB HID core driver nf_conntrack version 0.5.0 (16384 buckets, 65536 max) CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or sysctl net.netfilter.nf_conntrack_acct=1 to enable it. ip_tables: (C) 2000-2006 Netfilter Core Team TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 17 registered taskstats version 1 Freeing unused kernel memory: 6480k freed [9;0][8] Greetings. anaconda installer init version 11.5.0.12 starting mounting /proc filesystem... done creating /dev filesystem... done starting udev...done mounting /dev/pts (unix98 pty) filesystem... done mounting /sys filesystem... done anaconda installer init version 11.5.0.12 using /dev/hvc0 as console trying to remount root filesystem read write... done mounting /tmp as ramfs... done khelper used greatest stack depth: 10048 bytes left running install... running /sbin/loader detecting hardware... waiting for hardware to initialize... Welcome to Fedora for ppc +--------+ Network Error +---------+ | | | There was an error configuring | | your network interface. | | | | +-------+ | | | Retry | | | +-------+ | | | | | +----------------------------------+ ======================== Rescue mode shows ehea module is loaded sh-4.0# lsmod | grep ehea ehea 94072 0 sh-4.0# Machine type : JS22 Cpu type (Power4, Power5, IA-64, etc.): Power 6 =Comment: #2================================================= Thomas Klein <TKLEIN.com> - The ehea module is load but there's an issue configuring the interface. From the output provided so far I can't tell for sure but this smells a bit like an issue with yaboot we have seen earlier. Please check the dmesg output for messages indicating the hcalls done by the ehea driver fail. If this is the case I would assume we're dealing with the same issue here. =Comment: #8================================================= Pavan Naregundi <pavan.naregundi.com> - I could not see any dmesg errors related to ehea #dmesg | grep ehea ehea: eth0: Jumbo frames are enabled ehea: eth0 -> logical port id #7 ehea: eth1: Jumbo frames are enabled ehea: eth1 -> logical port id #8 =Comment: #9================================================= Pavan Naregundi <pavan.naregundi.com> - We can also reproduce this issue even with direct booting with netboot image(ppc64.img) without the yaboot. or while booting through cd give following parameters in boot prompt and when it comes to configure the network, it fails boot: linux vnc=1 boot: linux rescue=1 boot:linux ssh=1 =Comment: #14================================================= Thomas Klein <TKLEIN.com> - comment #8 indicates that the ehea interfaces are setup properly by the driver. So it's obviously _not_ the yaboot issue I suspected earlier. If the interface is setup but the installer has problems configuring it it looks more like a problem of the installer itself. We saw this kind of problem in nearly all distributions earlier. I guess we need someone who is familiar with the Fedora installer and who knows how to get logs from the installer and howto interpret them. =Comment: #17================================================= Tony Breeds <tonyb.com> - Things have changed in the Fedora world quite a bit recently can we retest with the current rawhide Yaboot: ftp://software.linux.ibm.com/pub/mirrors/fedora.redhat.com/development/ppc/os/ppc/chrp/yaboot Kernel, Initrd and yaboot.conf: http://software.linux.ibm.com/pub/mirrors/fedora.redhat.com/development/ppc/os/ppc/ppc64/ =Comment: #18================================================= Pavan Naregundi <pavan.naregundi.com> - Tested rawhide build. Still I could reproduce the problem. ============================================================== Redhat, For your awareness and support. Thanks!
Could you please attach whatever messages you are seeing on tty3 and tty4? If that is not available, you'll need to grab /tmp/anaconda.log and /tmp/syslog and attach them to this bug. Without those files, it's going to be very hard to tell what's going on here. Thanks. Also please do make sure you are testing with rawhide. Lots of things are changing very quickly with anaconda.
Created attachment 340689 [details] analonda.log in rescue mode ------- Comment on attachment From pavan.naregundi.com 2009-04-22 04:42 EDT------- Booted with 'linux rescue' option and ehea adapters fail to configure. Then collected anaconda log and syslog.
Created attachment 340690 [details] syslog ------- Comment (attachment only) From pavan.naregundi.com 2009-04-22 04:43 EDT-------
------- Comment From pavan.naregundi.com 2009-04-29 08:57 EDT------- Still seeing this issue in Fedora11 Preview. Thanks Pavan
------- Comment From arobert.com 2009-05-01 09:26 EDT------- Hi Red Hat team - is there anything else you need from the IBM team? Since the ehea adapter is the on-board ethernet adapter on all Power 6 and follow on systems this is an important bug to get to root cause on.
Network devices are handled by NetworkManager for the most part these days, and there are some suspicious error messages in your syslog that indicates it could be NM at fault here.
This bug has been triaged -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Dan: Any thoughts on this bug? Looks like NetworkManager is not properly activating devices on an IBM Power6 system. Is there additional information do you need to isolate this issue? IBM: Given the rapid development nature of Fedora, if you can confirm this issue still exists on rawhide (see https://fedoraproject.org/wiki/Releases/Rawhide#Direct_Rawhide_install).
------- Comment From pavan.naregundi.com 2009-05-18 02:07 EDT------- (In reply to comment #33) > IBM: Given the rapid development nature of Fedora, if you can confirm this > issue still exists on rawhide (see > https://fedoraproject.org/wiki/Releases/Rawhide#Direct_Rawhide_install). > Issue still exists in latest Rawhide. Thanks Pavan
------- Comment From hellerda.com 2009-05-18 07:48 EDT------- This does look like a problem in NetworkManager. The syslog output shows a number of errors from NM, some of which are normal on bring-up, but in the end it does not recognize the interfaces associated with ehea, which are eth0 and eth1. To troubleshoot it further would require debugging of Networkmanager or perhaps D-bus monitoring. It would be helpful to have a better understanding of how NM recognizes new devices. It may not be a problem with ehea driver per se, but the way it presents itself on d-bus.
For the record: Bugzappers and QA group discussed whether this issue should be a blocker for F11 release, but decided against on the grounds it's come to our attention quite late (sorry) and affects a fairly small class of hardware.
Are you able to do a non-network installation (DVD or CD) ... does the post-install system exhibit the same issues? Dan: Any other debugging suggestions IBM can do to help diagnose the root cause of this issue?
------- Comment From pavan.naregundi.com 2009-05-20 01:49 EDT------- (In reply to comment #38) > Are you able to do a non-network installation (DVD or CD) ... does the > post-install system exhibit the same issues? > Yes. We could do a DVD install. However, I have faced related to ehea ethernets, i.e. everytime when I reboot the machine I need to do a ifup even though ONBOOT=yes as shown below. # cat /etc/sysconfig/network-scripts/ifcfg-eth0 # Computer DEVICE=eth0 HWADDR=00:1a:64:45:88:fe BOOTPROTO=none NETMASK=255.255.255.0 GATEWAY=9.126.89.1 TYPE=Ethernet IPADDR=9.126.89.199 ONBOOT=yes USERCTL=no IPV6INIT=no NM_CONTROLLED=no PEERDNS=yes result does not differ if NM_CONTROLLED=no or yes > Dan: Any other debugging suggestions IBM can do to help diagnose the root cause > of this issue? >
I suspect that might be the root cause of the issue. Can you continue diagnosing the failure on a DVD installed system. Why does the network not start during boot? Anything interesting in /var/log/messages, /var/log/dmesg etc... ?
Created attachment 344917 [details] /var/log/messages with NM_CONTROLLED=yes ------- Comment (attachment only) From pavan.naregundi.com 2009-05-21 02:44 EDT-------
Created attachment 345382 [details] syslog from x86 system with e1000 on PCI ------- Comment (attachment only) From hellerda.com 2009-05-25 23:27 EDT-------
Created attachment 345383 [details] lshal output from x86 system with e1000 on PCI ------- Comment (attachment only) From hellerda.com 2009-05-25 23:28 EDT-------
Created attachment 345384 [details] lshal output from JS22 with ehea on ibmebus ------- Comment (attachment only) From hellerda.com 2009-05-25 23:29 EDT-------
------- Comment From hellerda.com 2009-05-25 23:37 EDT------- This problem is easily reproducible on a JS22 blade, and so would seem to affect all systems with ehea Ethernet. Also, per some testing by Pavan, the behavior seems to be the same pre-install or post-install: NetworkManager does recognize the interfaces associated with ehea. In the syslog output, the errors are consistently seen: "nm_device_ethernet_new: assertion `driver != NULL' failed" when NM is trying to detect ehea interfaces. And there is never a message of the form "new Ethernet device (driver: 'xxxxxx')" for ehea, as (it would seem) there should be. I have attached (good) syslog output from an x86 box with "e1000" interfaces, for comparison. I think the problem may be the way the ehea interfaces are recognized by HAL. HAL can detect the interfaces but not the ehea adapter itself. On an e1000 system with PCI, the adapter is recognized (with info.linux.driver = 'e1000') and the "net_xx_xx_xx_xx_xx_xx" object appears as a child of that. On an ehea system with ibmebus, the "net_xx_xx_xx_xx_xx_xx" object appears directly under the parent of "/org/freedesktop/Hal/devices/computer", and the adapter is not recognized at all. There is no device with info.linux.driver = 'ehea' on the P6 system. See attached lshal output for comparison. I think this bug is related to: https://bugzilla.redhat.com/show_bug.cgi?id=238626. The patch allows HAL to recognize devices on ibmebus. It was apparently integrated into hal-0.5.8 for RHEL5, but as far as I can tell it has not been brought forward to hal-0.5.12 for FC11. (There are no references to ibmebus in hal-0.5.12-26.20090226git.fc11.src.rpm). The patch would have be applied to "device.c", with some minor syntax changes. I believe this would allow HAL to recognize the ehea adapter, and that would fix NetworkManager. I think this could be tested by patching hald in FC11 Anaconda, but I have not had a chance to do that yet.
davidz: IBM has identified that the hal patch in rh bug#238626 may not have been applied to Fedora. See previous comment#19 for a detailed history of this issue. Do you have any input around this hal issue? Thanks!
Ideally for F12 we're going to convert the HAL usage to straight udev, which means we need to get driver data from somewhere in sysfs. But in the end, *any* network device (whether its backed by physical hardware or not) must have a kernel module associated with it, and that kernel module is what the 'driver' should be here.
Created attachment 345875 [details] lshal output ------- Comment (attachment only) From pavan.naregundi.com 2009-05-29 05:23 EDT-------
------- Comment From markwiz.com 2009-05-29 09:37 EDT------- From Sachin: Pavan, could you test the hal patch as pointed out by David ? Please post the test results in this bug. ------- From Pavan: Created an attachment (id=45630) [details] Modifed the patch mentioned in comment#50 Modified hal patch to fit in to device.c file. Installed the hal package to with this package on the F11 system. Rebooted the machine and here are the changes seem by me, 1. lshal --tree shows the ehea drivers in a sub tree under ibmebus(attaching the lshal output's in next comment) 2. Still Network manager could not start the ehea adapters at the bootup. Thanks Pavan
I need full lshal here to ensure the device tree looks correct and that the 'driver' bits are where they need to be. NM itself may need to be updated to account for the different s390 bus type, but I also need the full lshal output for that.
------- Comment From hellerda.com 2009-05-29 19:26 EDT------- We will provide further output ASAP, thanks for your patience. Hopefully the HAL patch will lead to the fix for NetworkManager. But the patch would seem to have been required in any event, since HAL was clearly not recognizing devices on the ibmebus without it.
Created attachment 346049 [details] lshal --long output ------- Comment (attachment only) From pavan.naregundi.com 2009-06-01 01:16 EDT-------
*** Bug 463933 has been marked as a duplicate of this bug. ***
Thanks, fixes that should work committed upstream: b9bdc5da4b968ff24b12d8b37f05605153bfbd8a (master) 4c36f7c0b607813753072acf1bec14414494948c (0.7.x) Obviously I have no way to test. This still will show up soon in rawhide and an F11 update.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
http://koji.fedoraproject.org/koji/taskinfo?taskID=1421445 Please try that build (rebuild the SRPM as appropriate for s390) and test. THanks!
------- Comment From pavan.naregundi.com 2009-06-19 08:20 EDT------- (In reply to comment #67) > http://koji.fedoraproject.org/koji/taskinfo?taskID=1421445 > > Please try that build (rebuild the SRPM as appropriate for s390) and test. > THanks! > Tested this build on a installed machine and now ehea adapters are UP after rebooting the machine. I tested on the system having the hal patch.
wpa_supplicant-0.6.8-4.fc11, NetworkManager-0.7.1-5.git20090617.fc11, mobile-broadband-provider-info-0.20090602-2.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update wpa_supplicant NetworkManager mobile-broadband-provider-info'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-6769
Thanks Pavan From Sachin: Pavan, could you test the hal patch as pointed out by David ? Please post the test results in this bug. ------- From Pavan: Created an attachment (id=45630) [details] Modifed the patch mentioned in comment#50 Modified hal patch to fit in to device.c file. Installed the hal package to with this package on the F11 system. Rebooted the machine and here are the changes seem by me, 1. lshal --tree shows the ehea drivers in a sub tree under ibmebus(attaching the lshal output's in next comment) 2. Still Network manager could not start the ehea adapters at the bootup. From Sachin: Pavan, could you test the hal patch as pointed out by David ? Please post the test results in this bug. ------- From Pavan: Created an attachment (id=45630) [details] Modifed the patch mentioned in comment#50 Modified hal patch to fit in to device.c file. Installed the hal package to with this package on the F11 system. Rebooted the machine and here are the changes seem by me, 1. lshal --tree shows the ehea drivers in a sub tree under ibmebus(attaching the lshal output's in next comment) 2. Still Network manager could not start the ehea adapters at the bootup.
------- Comment From pavan.naregundi.com 2009-06-22 01:44 EDT------- RedHat, Tested by updating the wpa_supplicant, NetworkManager and mobile-broadband-provider-info packages. But these updates alone does not seem to work for this bug. hal(0.5.12-26.20090226git.fc11) package still has not included the patch mentioned in comment #23. Please update the hal package with that patch. Thanks Pavan
------- Comment From arobert.com 2009-06-25 14:40 EDT------- Just following up on Pavan's comment from 6/22 on his question about whether the hal patch will be included. Any update?
Created attachment 349523 [details] hal patch ------- Comment on attachment From pavan.naregundi.com 2009-06-26 04:50 EDT------- Redhat, Please add this patch to hal to solve this bug. Thanks Pavan
(In reply to comment #36) > Created an attachment (id=349523) [details] > hal patch > > > ------- Comment on attachment From pavan.naregundi.com 2009-06-26 04:50 > EDT------- > > > Redhat, Please add this patch to hal to solve this bug. > > Thanks > Pavan Richard, can you please take a look at the above hal patch? It seams the only way to get rid of the non working ehea devices on power6 systems. Thank you.
(In reply to comment #37) > can you please take a look at the above hal patch? It seams the only way to get > rid of the non working ehea devices on power6 systems. Thank you. I'm hesitant to accept a patch that won't go upstream. Surely this just needs to be patched in NetworkManager to accept an interface not backed by a device?
wpa_supplicant-0.6.8-4.fc11, mobile-broadband-provider-info-0.20090602-2.fc11, NetworkManager-0.7.1-6.git20090617.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update wpa_supplicant mobile-broadband-provider-info NetworkManager'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-6769
------- Comment From pavan.naregundi.com 2009-07-13 08:06 EDT------- (In reply to comment #77) > (In reply to comment #37) > > can you please take a look at the above hal patch? It seams the only way to get > > rid of the non working ehea devices on power6 systems. Thank you. > > I'm hesitant to accept a patch that won't go upstream. Surely this just needs > to be patched in NetworkManager to accept an interface not backed by a device? > Redhat, HAL patch has been accepted upstream. Here is the commit id, http://cgit.freedesktop.org/hal/commit/?id=f710e0fda727d102291a44d1ce153ea22eac6c3e Please update the F11 hal package with this patch. Thanks Pavan
NetworkManager-0.7.1-8.git20090708.fc11, mobile-broadband-provider-info-1.20090707-1.fc11, wpa_supplicant-0.6.8-4.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update NetworkManager mobile-broadband-provider-info wpa_supplicant'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-6769
NetworkManager-0.7.1-8.git20090708.fc11, mobile-broadband-provider-info-1.20090707-1.fc11, wpa_supplicant-0.6.8-4.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
Redhat, This bug wont be fixed until the HAL patch mentioned in comment 41 is picked. Reopening ..
Change the Severity to 'urgent' to shows up for the F12 blocker bug meeting at Friday. The bugs blocks actually RHEL 6 (511304). Therefore I'm not able to add them to F12Blocker. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #44) > Redhat, This bug wont be fixed until the HAL patch mentioned in comment 41 is > picked. Reopening .. I've pulled in 0.5.13 into fedora rawhide, which means that it will be fixed for fedora 12, and if RHEL 6 happens to be based on something similar to f12, it'll be fixed for that too. It's now up to me (or someone else) to cherry pick this but for Fedora 11.
Clearing RHEL6 blocker as it's incorrect and misleading. (In reply to comment #45) > Change the Severity to 'urgent' to shows up for the F12 blocker bug meeting at > Friday. As far as F12 is concerned, this bug is fixed as a package is already built with this patch for rawhide. Just in case anyone was wondering, RHEL != Fedora. Thanks.
New F11 build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1562748
------- Comment From pavan.naregundi.com 2009-08-03 05:43 EDT------- (In reply to comment #90) > New F11 build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1562748 Still there is something wrong in applying the patch in the I executed the rpmbuild for hal-0.5.12-27.20090226git.fc11.src.rpm, where we can see rpmbuild/SOURCES/hal-0.5.12-fix-imebus-devices.patch is not applied to the build in prep stage. Redhat, please resolve this issue. # rpmbuild -bp SPECS/hal.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.nn6Wa8 + umask 022 + cd /root/rpmbuild/BUILD + cd /root/rpmbuild/BUILD + rm -rf hal-0.5.12 + /usr/bin/gzip -dc /root/rpmbuild/SOURCES/hal-0.5.12-20090226git.tar.gz + /bin/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd hal-0.5.12 + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #1 (hal-0.5.10-set-property-direct.patch):' Patch #1 (hal-0.5.10-set-property-direct.patch): + /bin/cat /root/rpmbuild/SOURCES/hal-0.5.10-set-property-direct.patch + /usr/bin/patch -s -p1 -b --suffix .direct --fuzz=0 + echo 'Patch #2 (hal-change-priority.patch):' Patch #2 (hal-change-priority.patch): + /bin/cat /root/rpmbuild/SOURCES/hal-change-priority.patch + /usr/bin/patch -s -p1 -b --suffix .priority --fuzz=0 + echo 'Patch #3 (hal-add-keys-to-buttons.patch):' Patch #3 (hal-add-keys-to-buttons.patch): + /bin/cat /root/rpmbuild/SOURCES/hal-add-keys-to-buttons.patch + /usr/bin/patch -s -p1 -b --suffix .keys --fuzz=0 + echo 'Patch #4 (hal-remove-dell-killswitch.patch):' Patch #4 (hal-remove-dell-killswitch.patch): + /bin/cat /root/rpmbuild/SOURCES/hal-remove-dell-killswitch.patch + /usr/bin/patch -s -p1 -b --suffix .dell-killswitch --fuzz=0 + echo 'Patch #7 (hal-tablet-evdev.patch):' Patch #7 (hal-tablet-evdev.patch): + /bin/cat /root/rpmbuild/SOURCES/hal-tablet-evdev.patch + /usr/bin/patch -s -p1 -b --suffix .tablet-evdev --fuzz=0 + echo 'Patch #8 (hal-fix-udev-dir.patch):' Patch #8 (hal-fix-udev-dir.patch): + /bin/cat /root/rpmbuild/SOURCES/hal-fix-udev-dir.patch + /usr/bin/patch -s -p1 -b --suffix .fix-udev --fuzz=0 + echo 'Patch #9 (hal-KVM-evdev.patch):' Patch #9 (hal-KVM-evdev.patch): + /bin/cat /root/rpmbuild/SOURCES/hal-KVM-evdev.patch + /usr/bin/patch -s -p1 -b --suffix .kvm-evdev --fuzz=0 + exit 0 ================
hal-0.5.12-28.20090226git.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/hal-0.5.12-28.20090226git.fc11
(In reply to comment #49) > I executed the rpmbuild for hal-0.5.12-27.20090226git.fc11.src.rpm, where we > can see rpmbuild/SOURCES/hal-0.5.12-fix-imebus-devices.patch is not applied to > the build in prep stage. Ahh yes, cvs helpfully didn't apply that hunk of the patch in the spec file. I've fixed this up now: * Mon Aug 03 2009 Richard Hughes <rhughes> - 0.5.12-28.20090226git - Actually apply the patch from the last commit. - Fixes #496820 > Redhat, please resolve this issue. My name is Richard, and I work for the company called Red Hat. The build is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1576148 I've also created a bohdi update here: https://admin.fedoraproject.org/updates/hal-0.5.12-28.20090226git.fc11
------- Comment From pavan.naregundi.com 2009-08-04 03:01 EDT------- Tested on a fedora11 installed system with NetworkManager-0.7.1-8.git20090708.fc11.ppc and above mentioned hal-0.5.12-28.20090226git.fc11. EHEA network adapters could come up after the reboot.
hal-0.5.12-28.20090226git.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8296
hal-0.5.12-29.20090226git.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/hal-0.5.12-29.20090226git.fc11
hal-0.5.12-29.20090226git.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8505
hal-0.5.12-29.20090226git.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
------- Comment From pavan.naregundi.com 2009-08-21 00:58 EDT------- Closing this bug as this issue is fixed in F11 with hal-0.5.12-28.20090226git.fc11 and further hal versions. Thanks