Bug 34306
| Summary: | 4.5-RC panics on boot with half-supported Advansys SCSI card | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Scott Mitchell <scott> |
| Component: | kern | Assignee: | Scott Mitchell <rsm> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Scott Mitchell
2002-01-26 15:40:00 UTC
On Sat, 26 Jan 2002 15:29:37 GMT, Scott Mitchell wrote:
> >Number: 34306
> >Category: kern
> >Synopsis: 4.5-RC panics on boot with half-supported Advansys SCSI card
Hi Justin & Nick,
The panic for which a backtrace is provided in this PR suggests a
horrible nasty in bus resource allocation. Although the panic comes
from the advansys driver, the work-around provided in the PR is to avoid
preloading usb.ko, so I'm not sure which of you two gentlemen wants this
PR.
Any takers? :-)
Ciao,
Sheldon.
The problem is most probably the fact that the adw0 driver does not handle reprobing very well. Note that it fails to attach properly the first time round because it is not able to upload the firmware. Looking at the driver, the problem is that it does not release resources on failure (or at any other time). Why bus_alloc_resource panics I do not understand. I would expect it to return an error. The reason why the USB driver causes havoc is that it invokes a reattach on every load of a driver for every driver in the system. As the device that the adw0 driver did not attach to has no driver, the adw0 driver tries to attach to it and somehow makes a mess of things. Bottom line: The advansys driver needs to slightly rewritten to release resources when attach fails. See sys/pci/uhci.c for an example. Hope this helps. Nick Responsible Changed From-To: freebsd-bugs->gibbs Over to the adw maintainer. > > >On Sat, 26 Jan 2002 15:29:37 GMT, Scott Mitchell wrote: > >> >Number: 34306 >> >Category: kern >> >Synopsis: 4.5-RC panics on boot with half-supported Advansys SCSI car >d > >Hi Justin & Nick, > >The panic for which a backtrace is provided in this PR suggests a >horrible nasty in bus resource allocation. Although the panic comes >from the advansys driver, the work-around provided in the PR is to avoid >preloading usb.ko, so I'm not sure which of you two gentlemen wants this >PR. > A quick guess is that the adw driver doesn't deal properly with a failure during resource allocation and ends up freeing an unallocated resource. I'll try to take a look at it later today. -- Justin On Tue, 29 Jan 2002 16:01:07 +0100, "Nick Hibma" wrote:
> The reason why the USB driver causes havoc is that it invokes a reattach on
> every load of a driver for every driver in the system. As the device that
> the adw0 driver did not attach to has no driver, the adw0 driver tries to
> attach to it and somehow makes a mess of things.
Thanks for the feedback, Nick!
Ciao,
Sheldon.
> > >On Sat, 26 Jan 2002 15:29:37 GMT, Scott Mitchell wrote: > >> >Number: 34306 >> >Category: kern >> >Synopsis: 4.5-RC panics on boot with half-supported Advansys SCSI car >d > >Hi Justin & Nick, > >The panic for which a backtrace is provided in this PR suggests a >horrible nasty in bus resource allocation. Although the panic comes >from the advansys driver, the work-around provided in the PR is to avoid >preloading usb.ko, so I'm not sure which of you two gentlemen wants this >PR. > >Any takers? :-) > >Ciao, >Sheldon. These are completely untested. They do not correct the root cause of the failed probe, but should make repeated probes less fatal. -- Justin Index: adwcam.c =================================================================== RCS file: /usr/cvs/src/sys/dev/advansys/adwcam.c,v retrieving revision 1.7.2.2 diff -u -r1.7.2.2 adwcam.c --- adwcam.c 2001/03/05 13:08:55 1.7.2.2 +++ adwcam.c 2002/01/29 22:49:05 @@ -891,6 +891,26 @@ case 0: break; } + + if (adw->regs != NULL) + bus_release_resource(adw->device, + adw->regs_res_type, + adw->regs_res_id, + adw->regs); + + if (adw->irq != NULL) + bus_release_resource(adw->device, + adw->irq_res_type, + 0, adw->irq); + + if (adw->sim != NULL) { + if (adw->path != NULL) { + xpt_async(AC_LOST_DEVICE, adw->path, NULL); + xpt_free_path(adw->path); + } + xpt_bus_deregister(cam_sim_path(adw->sim)); + cam_sim_free(adw->sim, /*free_devq*/TRUE); + } free(adw->name, M_DEVBUF); free(adw, M_DEVBUF); } State Changed From-To: open->feedback Justin has supplied a patch for the originator to test. Justin's patch appears to work perfectly. I removed the usb_load="YES" line from loader.conf and booted with the patched kernel. No crash, and usb.ko was successfully demand-loaded when usbd started. Many thanks! Now I can start figuring out how make the card actually *work* :-) Scott Justin, Sheldon, Not sure if you both got this the first time, since I managed to send it to myself but not to either of you... FYI, no problems with the patch at all sice then. As soon as I have a free weekend I plan to take a look at getting this card to work properly -- it seems to be halfway there, plus it came with Linux drivers that appear to be tweaked versions of (non-GPL) code from Advansys themselves, so it (hopefully) won't be a huge job. Thanks again, Scott ----- Forwarded message from Scott Mitchell <scott.mitchell@mail.com> ----- Date: Thu, 31 Jan 2002 00:18:01 +0000 From: Scott Mitchell <scott.mitchell@mail.com> Subject: Re: kern/34306: 4.5-RC panics on boot with half-supported Advansys SCSI card To: freebsd-gnats-submit@FreeBSD.org, scott@uk.freebsd.org X-Mailer: KMail [version 1.3.2] Justin's patch appears to work perfectly. I removed the usb_load="YES" line from loader.conf and booted with the patched kernel. No crash, and usb.ko was successfully demand-loaded when usbd started. Many thanks! Now I can start figuring out how make the card actually *work* :-) Scott ----- End forwarded message ----- -- =========================================================================== Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" scott.mitchell@mail.com | 0xAA775B8B | -- Anon Hi Justin, Doing some cleanup on my 4-stable tree and noticed that I still have your patch for this PR in there. It still seems to be necessary when you've got adw devices that fail to attach - I can still reproduce the original panic if I go back to a stock adwcam.c. I don't believe this patch causes anything bad to happen if you *do* have working adw devices. Any objections to committing this before 4.11? I have a commit bit now so I'm quite happy to do this (and close the PR) if you like. Cheers, Scott -- =========================================================================== Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" scott at fishballoon.org | 0xAA775B8B | -- Anon > Any objections to committing this before 4.11? I have a commit bit now so
> I'm quite happy to do this (and close the PR) if you like.
The patch likely applies to 6.x, 5.x, and 4.x. Feel free to commit
it to any/all branches necessary.
--
Justin
On Sun, Dec 05, 2004 at 11:29:40AM -0700, Justin T. Gibbs wrote:
> > Any objections to committing this before 4.11? I have a commit bit now so
> > I'm quite happy to do this (and close the PR) if you like.
>
> The patch likely applies to 6.x, 5.x, and 4.x. Feel free to commit
> it to any/all branches necessary.
Committed to all three branches. Shall I close this PR? Not sure I
can/should do that while it's assigned to you...
Many thanks,
Scott
--
===========================================================================
Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels
Cambridge, England | 0x54B171B9 | don't get sucked into jet engines"
scott at fishballoon.org | 0xAA775B8B | -- Anon
> Committed to all three branches. Shall I close this PR? Not sure I
> can/should do that while it's assigned to you...
Feel free to take the bug and close it. I can't verify the fix, so
having you close it seems more appropriate.
--
Justin
State Changed From-To: feedback->closed Fix has been working locally for ~3 years without any problems. Committed to 4.x, 5.x and 6.x branches. Responsible Changed From-To: gibbs->rsm Assign to rsm - he has suitable hardware to test this. |
