Date: Tue, 16 May 2006 18:51:38 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@deepcore.dk> To: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> Cc: Maxim Sobolev <sobomax@FreeBSD.ORG>, "current@freebsd.org" <current@FreeBSD.ORG>, sos@FreeBSD.ORG Subject: Re: Support for ICH7 controller in PowerBook Pro Message-ID: <446A031A.5060503@deepcore.dk> In-Reply-To: <1147791948.27776.26.camel@buffy.york.ac.uk> References: <444DD7DF.6010402@FreeBSD.org> <1145956219.2968.31.camel@sos.deepcore.dk> <44681E94.9000702@FreeBSD.org> <1147686547.23488.6.camel@buffy.york.ac.uk> <446935C6.6020900@FreeBSD.org> <1147791948.27776.26.camel@buffy.york.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Gavin Atkinson wrote: > On Mon, 2006-05-15 at 19:15 -0700, Maxim Sobolev wrote: >> Gavin Atkinson wrote: >>> On Sun, 2006-05-14 at 23:24 -0700, Maxim Sobolev wrote: >>>> Søren Schmidt wrote: >>>>> On Tir, 2006-04-25 at 01:03 -0700, Maxim Sobolev wrote: >>>>>> Hi Søren, >>>>>> >>>>>> Attached please find small patch which adds support for 82801GBM/GHM >>>>>> SATA controller found in intel-based Macs, particularly in MacBook Pro. >>>>>> >>>>>> Please review & approve. >>>>> I'll look into it, I think Intel has a few other new chips I should add >>>>> in the same go, give me a few days... >>>> Any progress with this? Few days have turned into few weeks, and I don't >>>> want them turn into few months. :) >>> Be aware that I believe your patch is slightly wrong. As far as I can >>> tell the chip ID you've added is the non-AHCI version. I have the same >>> chip in my new Toshiba laptop, and submitted a more complete PR >>> (kern/97228) over the weekend. >> MacBook doesn't work with your patch - FreeBSD detects controller but >> doesn't see any disks attached to it. :( Putting AHCI back solves the >> problem. >> >> I wonder if Intel has shipped two different controllers with the same >> pci ids. > > Seems unlikely to me, Intel seem to love burning product IDs. I wonder > if it has anything to do with which disks are attached. My laptop > actually works with that set either to "AHCI" or "0", but I assumed that > was more of a by-product of the minimal AHCI support currently. AHCI support is fully working in 6.1/-current. >> Just in the case, attached is appropriate entry from pciconf -lv output: >> >> atapci1@pci0:31:2: class=0x01018f card=0x72708086 chip=0x27c48086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller' >> class = mass storage >> subclass = ATA >> >> And dmesg: >> >> atapci1: <Intel ICH7 SATA300 controller> port >> 0x40d8-0x40df,0x40f4-0x40f7,0x40d0-0x40d7,0x40f0-0x40f3,0x4020-0x402f >> mem 0x98405000-0x984053ff irq 19 at device 31.2 on pci0 >> ata2: <ATA channel 0> on atapci1 >> ata3: <ATA channel 1> on atapci1 >> ad5: 95396MB <Seagate ST910021AS 3.07> at ata2-slave SATA150 > > Mine looks like: > > atapci0@pci0:31:2: class=0x010180 card=0x00011179 chip=0x27c48086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller' > class = mass storage > subclass = ATA > > Note that the class is different. > > dmesg with the cfg1 flag set to 0: > atapci0: <Intel ICH7 SATA300 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x9f10-0x9f1f irq 19 at device 31.2 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x9f10 > ata0: <ATA channel 0> on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=01 ostat0=80 ostat1=00 > ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > ata0: reset tp2 stat0=50 stat1=00 devices=0x1<ATA_MASTER> > ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55 > ata0: [MPSAFE] > ata1: <ATA channel 1> on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 > atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 > ata1: reset tp1 mask=01 ostat0=50 ostat1=00 > ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: reset tp2 stat0=00 stat1=00 devices=0x4<ATAPI_MASTER> > ioapic0: routing intpin 15 (ISA IRQ 15) to vector 56 > ata1: [MPSAFE] > [...] > ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire > ad0: 76319MB <HTS541080G9SA00 MB4OC60D> at ata0-master SATA150 > ad0: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue > ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire > acd0: <DVD/CDRW UJDA770/1.00> CDRW drive at ata1 as master > > dmesg with the cfg1 flag set to AHCI: > atapci0: <Intel ICH7 SATA300 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x9f10-0x9f1f irq 19 at device 31.2 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x9f10 > atapci0: failed to enable memory mapping! > ata0: <ATA channel 0> on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=03 ostat0=50 ostat1=00 > ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 > ata0: reset tp2 stat0=50 stat1=00 devices=0x1<ATA_MASTER> > ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55 > ata0: [MPSAFE] > ata1: <ATA channel 1> on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 > atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 > ata1: reset tp1 mask=03 ostat0=50 ostat1=00 > ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 > ata1: reset tp2 stat0=00 stat1=00 devices=0x4<ATAPI_MASTER> > ioapic0: routing intpin 15 (ISA IRQ 15) to vector 56 > ata1: [MPSAFE] > [...] > ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire > ad0: 76319MB <HTS541080G9SA00 MB4OC60D> at ata0-master SATA150 > ad0: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue > ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire > acd0: <DVD/CDRW UJDA770/1.00> CDRW drive at ata1 as master > > As far as I can tell, the only difference is the "atapci0: failed to > enable memory mapping!" line when I'm using the chipset as an AHCI > chipset. You are *not* using it in AHCI mode in any of the examples above, you need a memory resource which it states cannot be enabled... > So, as far as I'm concerned, AHCI works for my laptop, I'm just a little > wary (not really understanding AHCI) as to if this is safe or will > continue to work in the future, especially given the Intel docs seem to > suggest it is a non-AHCI PCI ID. AHCI mode is fully supported, hotplug and all and will continue to be that... -Søren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?446A031A.5060503>