Date: Sat, 10 Sep 2005 17:36:36 -0600 From: Scott Long <scottl@samsco.org> To: joao.barros@gmail.com Cc: freebsd-current@freebsd.org, Warner Losh <imp@freebsd.org>, Mike Tancsa <mike@sentex.net> Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) Message-ID: <43236E04.4020208@samsco.org> In-Reply-To: <70e8236f05091016251510408c@mail.gmail.com> References: <70e8236f05070208212e36c375@mail.gmail.com> <200507291318.24428.jhb@FreeBSD.org> <70e8236f050807192628b0405e@mail.gmail.com> <200508081311.51857.jhb@FreeBSD.org> <70e8236f05090321007f621845@mail.gmail.com> <70e8236f05090513381584dda0@mail.gmail.com> <70e8236f0509051350e020f76@mail.gmail.com> <70e8236f05091016251510408c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Joao Barros wrote: > On 9/5/05, Joao Barros <joao.barros@gmail.com> wrote: > >>On 9/5/05, Joao Barros <joao.barros@gmail.com> wrote: >> >>>On 9/4/05, Joao Barros <joao.barros@gmail.com> wrote: >>> >>>>On 8/8/05, John Baldwin <jhb@freebsd.org> wrote: >>>> >>>>>Ok, so I'm assuming that 5.4 works but RELENG_6 does not? Do you have verbose >>>>>dmesg's from both cases so that I can compare them? >>>> >>>>Ok, review: >>>>FreeBSD5.4: kernel boots with amr installed >>>>FreeBSD6.0: kernel doesn't boot with amr installed >>>>As I think some commit in time between 5.4 and CURRENT(6.0) changed >>>>something that prevents the kernel to boot with an amr installed, I'm >>>>trying to pinpoint that change. >>>>So far I've tested 5.4-STABLE-SNAP006-i386 which boots and back till >>>>6.0-CURRENT-SNAP001 which does not boot. >>>>My next step will be to cvsup to specific times and start testing kernels :) >>>>More feedback to come! >>> >>>And after some(many) hours of compiling I narrowed the gap to a >>>working kernel from September 1, 2004 to a non working kernel from >>>November 1, 2004. >> >>Correction: November -> December >> >> >>>And yes, more feeback to come. >> > > Eureka! > > I managed to narrow the gap to the commit responsible for the symptoms > I've reported: > > imp 2004-11-10 00:41:39 UTC > > FreeBSD src repository > > Modified files: > sys/dev/pci pci.c > Log: > Make pci_do_powerstate default to 1 now that we've done the release to > get more testing. This should help things a little. > > Revision Changes Path > 1.268 +2 -2 src/sys/dev/pci/pci.c > > Diff: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pci/pci.c.diff?r1=1.267&r2=1.268&f=h > > In pci.c one can read: > enable these bits correctly. We'd like to do this all the time, but > there are some peripherals that this causes problems with."); > Well, I guess it's the case with this controller ;) > > I tried setting this ( hw.pci.do_powerstate ) tunable to 0 and voilá, > 6.0 BETA 4 #2 booted with the amr installed. > > Still on pci.c one can also read: > "Power down devices into D3 state when no driver attaches to them. > Otherwise, leave the device in D0 state when no driver attaches." > This controller just so happens to have a device that FreeBSD doesn't > have support: > kernel: pci2: <mass storage, SCSI> at device 1.0 (no driver attached) > Looking at pciconf -l -v : > pcib3@pci2:0:0: class=0x060400 card=0x000000dc chip=0xb1548086 rev=0x00 hdr=0x01 > vendor = 'Intel Corporation' > device = 'S21152BA,S21154AE/BE PCI to PCI Bridge' > class = bridge > subclass = PCI-PCI > none1@pci2:1:0: class=0x010000 card=0x8493101e chip=0x12161077 rev=0x06 hdr=0x00 > vendor = 'QLogic Corporation' > device = 'ISP12160 Dual Channel Ultra3 SCSI Processor' > class = mass storage > subclass = SCSI > amr0@pci3:0:0: class=0x010400 card=0x04931028 chip=0x1960101e rev=0x20 hdr=0x00 > vendor = 'American Megatrends Inc.' > device = '80960RP i960RP Microprocessor' > class = mass storage > subclass = RAID > So, by not attaching a driver to pci2:1:0, the pci2:0:0 is disabled. > Although the 'real' amr is assigned to pci3, the pci bridge on > pci2:0:0 gets disabled thus killing the amr. > > I believe a workaround for this issue would be verifying before > disabling the device, that no more that one device shares that > particular pci slot. > > Comments? > Thanks for the invesitgative work. I strenously objected to this change when it went in, and this kind of problem is precisely the reason why. Turning off device power on the PCI bus willy-nilly is such an incredibly bad idea, even if the hope with it is to get a few extra minutes of battery life on a laptop. I worked around this problem with the AAC devices, but I don't know if the AMR devices can be worked around the same way. I've asked Warner in private to back out the change. If he refuses, then I'm afraid that you'll need to remember an undocumented workaround, or find another OS. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43236E04.4020208>