3.11.0-rc4 wireless and networkmanager stopped working
Hello, Wireless networking on my opensuse 12.3 system has been changing in recent kernels. Initially, I used an ifup style setup. That stopped worked around 3.5 or 3.6. When that happened I switched to networkmanager and it worked... for a while. That stopped working as well at, I think, 3.8 (I did not use 3.7). At that point I reverted to the vendor kernel. At 3.11.0-rc3 I udpated my tree and built it again - same .config (modulo changes for new entries) and lo and behold wifi started working. Today I updated to 3.11.0-rc4 and again built with the same basic .config and it's back to where it was before. Something between rc3 and rc4 re-breaks networkmanager. Fwiw, the symptom is a failure to get an IP. It claims to find the base station and iwconfig output looks reasonable. The DHCP never completes. Fwiw it's an iwl3945. Just switching back and forth between rc3 and rc4 makes it work or not. No other changes. Thanks, Phil -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.11.0-rc4 wireless and networkmanager stopped working
Hello, Wireless networking on my opensuse 12.3 system has been changing in recent kernels. Initially, I used an ifup style setup. That stopped worked around 3.5 or 3.6. When that happened I switched to networkmanager and it worked... for a while. That stopped working as well at, I think, 3.8 (I did not use 3.7). At that point I reverted to the vendor kernel. At 3.11.0-rc3 I udpated my tree and built it again - same .config (modulo changes for new entries) and lo and behold wifi started working. Today I updated to 3.11.0-rc4 and again built with the same basic .config and it's back to where it was before. Something between rc3 and rc4 re-breaks networkmanager. Fwiw, the symptom is a failure to get an IP. It claims to find the base station and iwconfig output looks reasonable. The DHCP never completes. Fwiw it's an iwl3945. Just switching back and forth between rc3 and rc4 makes it work or not. No other changes. Thanks, Phil -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bio refcount problem
Hi, Rumor has it that on Fri, Feb 18, 2005 at 02:59:32PM +0100 Jens Axboe said: > On Fri, Feb 18 2005, Philip R Auld wrote: ... > > Or make all users of submit_bio take and release and extra reference > > like submit_bh. > > The queue lock is still held at that point, so the driver hasn't had a > chance to process the request yet. Interesting. This is not a theoretical problem though. I've got traces of the oops showing the bio getting freed before the bio_sync(bio) test. When you say driver here what level do you mean? scsi_request_fn at least drops the queue lock. What if it's merged instead of added directly? That could also get to the same place. The end_io callback _is_ getting called before __make_request does its "if(bio_sync(bio))" test. Cheers, Phil > > -- > Jens Axboe -- Philip R. Auld, Ph.D. Egenera, Inc. Software Architect165 Forest St. (508) 858-2628Marlboro, MA 01752 - 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/
bio refcount problem
Hi, I think there are some potential issues with the reference counting of bios as used in 2.6.10. The __make_request function which is the default block device routine accesses the bio structure after issuing the call to add_request. This means that the bio could have completed before __make_request uses it. The submit_bh path takes an extra reference with an explicit bio_get/put pair around the submit_bio, but many other users of submit_bio do not. Given that most of the end_io routines remove a reference and hence could free the bio this can lead at the least to __make_request mis-reading the sync flag. In more extreme cases it can cause an oops when run with CONFIG_DEBUG_PAGEALLOC. The question is what is the preferred fix? I think it may be to simply have submit_bio take its own reference (and remove the extra one from submit_bh). Alternatively __make_request could be adjusted so that it does not access the bio after calling add_request. All it is doing is checking the bi_rw field for the sync bit. Or make all users of submit_bio take and release and extra reference like submit_bh. Thoughts? Cheers, Phil -- Philip R. Auld, Ph.D. Egenera, Inc. Software Architect165 Forest St. (508) 858-2628Marlboro, MA 01752 - 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/
bio refcount problem
Hi, I think there are some potential issues with the reference counting of bios as used in 2.6.10. The __make_request function which is the default block device routine accesses the bio structure after issuing the call to add_request. This means that the bio could have completed before __make_request uses it. The submit_bh path takes an extra reference with an explicit bio_get/put pair around the submit_bio, but many other users of submit_bio do not. Given that most of the end_io routines remove a reference and hence could free the bio this can lead at the least to __make_request mis-reading the sync flag. In more extreme cases it can cause an oops when run with CONFIG_DEBUG_PAGEALLOC. The question is what is the preferred fix? I think it may be to simply have submit_bio take its own reference (and remove the extra one from submit_bh). Alternatively __make_request could be adjusted so that it does not access the bio after calling add_request. All it is doing is checking the bi_rw field for the sync bit. Or make all users of submit_bio take and release and extra reference like submit_bh. Thoughts? Cheers, Phil -- Philip R. Auld, Ph.D. Egenera, Inc. Software Architect165 Forest St. (508) 858-2628Marlboro, MA 01752 - 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/
Re: bio refcount problem
Hi, Rumor has it that on Fri, Feb 18, 2005 at 02:59:32PM +0100 Jens Axboe said: On Fri, Feb 18 2005, Philip R Auld wrote: ... Or make all users of submit_bio take and release and extra reference like submit_bh. The queue lock is still held at that point, so the driver hasn't had a chance to process the request yet. Interesting. This is not a theoretical problem though. I've got traces of the oops showing the bio getting freed before the bio_sync(bio) test. When you say driver here what level do you mean? scsi_request_fn at least drops the queue lock. What if it's merged instead of added directly? That could also get to the same place. The end_io callback _is_ getting called before __make_request does its if(bio_sync(bio)) test. Cheers, Phil -- Jens Axboe -- Philip R. Auld, Ph.D. Egenera, Inc. Software Architect165 Forest St. (508) 858-2628Marlboro, MA 01752 - 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/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
>10. To Do But Non Showstopper > > * Go through as 2.4pre kicks in and figure what we should mark > obsolete for the final 2.4 (i.e. XT hard disk support?) > * Union mount (Al Viro) ^^^ Anyone know the status of this? I have seen postings saying it's likely a 2.5 thingy, but it's continually on the 2.4 TODO lists. I am willing to help if it's needed/wanted. Thanks, Phil Philip Auld Dept. of Computer Science College of William and Mary - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
10. To Do But Non Showstopper * Go through as 2.4pre kicks in and figure what we should mark obsolete for the final 2.4 (i.e. XT hard disk support?) * Union mount (Al Viro) ^^^ Anyone know the status of this? I have seen postings saying it's likely a 2.5 thingy, but it's continually on the 2.4 TODO lists. I am willing to help if it's needed/wanted. Thanks, Phil Philip Auld Dept. of Computer Science College of William and Mary - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
