1 Mar 2007 03:13
1 Mar 2007 16:15
Gigabyte 965P, JMicron IDE/SATA Controller
Frank Naumann <fnaumann <at> boerde.de>
2007-03-01 15:15:20 GMT
2007-03-01 15:15:20 GMT
Hello! I have a Gigabyte GA-965P-DS4 which have a JMicron JMB363 IDE/SATA controller on board that is not yet supported by NetBSD 4. Any chance that the IDE part is supported with bus-master DMA? Without bus-master DMA any access to the DVD drive slow down the system significantly (PIO mode). ahcisata0 at pci4 dev 0 function 0: unknown vendor 0x197b product 0x2363 ahcisata0: AHCI revision 1.0, 2 ports, 32 command slots, features 0xc722e000 ahcisata0: interrupting at ioapic0 pin 17 (irq 10) atabus0 at ahcisata0 channel 0 atabus1 at ahcisata0 channel 1 pciide0 at pci4 dev 0 function 1 pciide0: unknown vendor 0x197b product 0x2363 (rev. 0x02) pciide0: bus-master DMA support present, but unused (no driver support) pciide0: primary channel wired to native-PCI mode pciide0: using ioapic0 pin 18 (irq 15) for native-PCI interrupt atabus2 at pciide0 channel 0 pciide0: secondary channel wired to native-PCI mode atabus3 at pciide0 channel 1 Regards, Frank
1 Mar 2007 16:28
Re: imac i386.
Matthias Scheler <tron <at> zhadum.org.uk>
2007-03-01 15:28:56 GMT
2007-03-01 15:28:56 GMT
On Thu, Mar 01, 2007 at 02:13:52AM +0000, andy wrote: > I am trying to create a bootCD for an iMac i386. NetBSD release include ISO images. The NetBSD-i386 3.1 ISO is available here: ftp://ftp.uk.netbsd.org/pub/NetBSD/iso/3.1/i386cd-3.1.iso The prefered method for downloading is however via BitTorrent. The ".torrent" file is available here: ftp://ftp.uk.netbsd.org/pub/NetBSD/iso/3.1/i386cd-3.1.iso.torrent If you want to great a NetBSD 4.0_BETA2 ISO image you can do it like this (under NetBSD, Linux or Mac OS X after installing "wget" and "mkisofs"): mkdir netbsd cd netbsd wget -r ftp://ftp.netbsd.org/pub/NetBSD-daily/netbsd-4/200702270002Z/i386/ wget -r ftp://ftp.netbsd.org/pub/NetBSD-daily/netbsd-4/200702270002Z/source/ cd .. mkisofs -J -r -V "NetBSD 4.0_BETA2" -b i386/installation/floppy/boot-big.fs -o netbsd.iso netbsd You can after create a CD-ROM with "cdrecord netbsd.iso" (NetBSD or Linux) or "hdiutil burn netbsd.iso" (Mac OS X). Kind regards -- -- Matthias Scheler http://zhadum.org.uk/(Continue reading)
1 Mar 2007 20:50
Re: Sysinst won't install onto ld0 on NetBSD 4.0 Beta 2
Jeff Rizzo <riz <at> NetBSD.org>
2007-03-01 19:50:45 GMT
2007-03-01 19:50:45 GMT
David W. Rankin Jr. wrote: > I'm installing NetBSD 4.0 Beta 2 onto a new-to-me Dell PowerEdge 2450. > It's got the RAID card (PERC 3/Si, aac0) installed, and I have confirmed that > the install media can read and write to ld0 from the install media > (fdisk, disklabel, and newfs all work). However, the installer won't > see ld0 as a valid install disk. sysinst says "no valid disks". > > I wasn't able to capture the dmesg yet, since the system booted over > VGA, but I will do that if someone needs the output. > > Is NetBSD 4.0 unable to boot off of the ld0 given by the PERC 3/Si, > or can anyone suggest a way to fix this? > > Thanks, > David > > I have a 3ware 9550SX that I've used sysinst to install onto ld0; it's odd that yours doesn't. How large is the volume? Is there any way you can post the output of dmesg and fdisk ld0? +j
2 Mar 2007 03:02
Re: Sysinst won't install onto ld0 on NetBSD 4.0 Beta 2
David W. Rankin Jr. <drankin <at> bohemians.lexington.ky.us>
2007-03-02 02:02:00 GMT
2007-03-02 02:02:00 GMT
On Thu, Mar 01, 2007 at 11:50:45AM -0800, Jeff Rizzo wrote:
> I have a 3ware 9550SX that I've used sysinst to install onto ld0; it's
> odd that yours doesn't. How large is the volume? Is there any way you
> can post the output of dmesg and fdisk ld0?
Thanks to some of Matthias' help earlier, I think I have the problem
isolated. Somewhere between NetBSD 3.1 and 4.0 Beta 2, the ld0
driver has quit responding to the DIOCGDEFLABEL ioctl. When trying
to run "fdisk ld0d" from a 4.0 Beta 2 disk, I get the error message
fdisk: DIOCGDEFLABEL: Inappropriate ioctl for device
but fdisk will still let me update the disk and make a partition.
3.1 distribution will install just fine, with no fuss at all.
I've attached the last dmesg from 4.0 Beta below.
Is anyone who's familiar with ld0 know what might have changed for
ld0 between 3.1 and 4.0 that could cause this?
Thanks,
David
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 4.0_BETA2 (INSTALL) #1: Tue Feb 27 10:26:58 EST 2007
root <at> hilda:/files1/netbsd-4-branch/obj/sys/arch/i386/compile/INSTALL
total memory = 511 MB
(Continue reading)
2 Mar 2007 03:12
aac(4) vs. Dell PERC 3/Di _and_ HP NetRAID-4M in same host
Greg A. Woods <woods <at> planix.com>
2007-03-02 02:12:02 GMT
2007-03-02 02:12:02 GMT
I've got a Dell PowerEdge 2650 here with that I've added an HP NetRAID-4M card to for additional external storage. Has anyone here successfully used a similar configuration with NetBSD (or FreeBSD or OpenBSD, or even GNU/Linux)? Any kind of system with both Dell PERC and HP NetRAID in the same box? This one boots up with netbsd-4 saying, in part, the following: aac0 at pci2 dev 8 function 1: Dell PERC 3/Di aac0: interrupting at ioapic1 pin 14 (irq 11) aac0: i960RX at 100MHz, 128MB mem (118MB cache), optional battery present ld0 at aac0 unit 0: RAID 5 ld0: 135 GB, 17700 cyl, 255 head, 63 sec, 512 bytes/sect x 284365824 sectors aac1 at pci4 dev 6 function 0: HP NetRAID-4M aac1: interrupting at ioapic1 pin 0 (irq 7) aac1: StrongARM SA110 at 233MHz, 144MB mem (128MB cache), required battery present ld1 at aac1 unit 0: RAID 5 ld1: 95450 MB, 12168 cyl, 255 head, 63 sec, 512 bytes/sect x 195482496 sectors ld0 works just fine. I was able to install onto it from sysinst, and I've done a full source build on it right to the binary sets without trouble, albiet a bit slower than it could be, apparently. However ld1 behaves very bizarrely. I can write to it at what seems to be full blast. I can read from it too, but slower than it should be, I think (a lot slower than it writes!), and all I ever get back are zero value bytes. There are no errors, not a peep from anything, just lots of blocks of zeros, no matter what's been "written" previously.(Continue reading)
2 Mar 2007 03:47
Re: Sysinst won't install onto ld0 on NetBSD 4.0 Beta 2
Greg A. Woods <woods <at> weird.com>
2007-03-02 02:47:43 GMT
2007-03-02 02:47:43 GMT
At Thu, 1 Mar 2007 21:02:00 -0500, David W. Rankin Jr. wrote: > > Thanks to some of Matthias' help earlier, I think I have the problem > isolated. Somewhere between NetBSD 3.1 and 4.0 Beta 2, the ld0 > driver has quit responding to the DIOCGDEFLABEL ioctl. When trying > to run "fdisk ld0d" from a 4.0 Beta 2 disk, I get the error message > fdisk: DIOCGDEFLABEL: Inappropriate ioctl for device > but fdisk will still let me update the disk and make a partition. That doesn't sound right, though I don't know that I paid such close attention to any "warning" messages during the install. In any case I didn't have any trouble doing an install on my PE2650 to an "ld0" device, and that was with sysinst, from a full from-scratch build of a normal bootable installation CD, using the netbsd-4 branch sometime in the first or second week of February (the CD with the actual date on it is downstairs and I'm too lazy to run down and look) -- -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods <at> robohack.ca> Planix, Inc. <woods <at> planix.com> Secrets of the Weird <woods <at> weird.com>
2 Mar 2007 04:29
Re: acpi SCI interrupt override bug
Cherry G. Mathew <cherry.g.mathew <at> gmail.com>
2007-03-02 03:29:12 GMT
2007-03-02 03:29:12 GMT
On 2/27/07, Paul Goyette <paul <at> whooppee.com> wrote: > On Tue, 27 Feb 2007, Cherry G. Mathew wrote: > > > It isn't a fix, its just a really ugly special case hack. > > Hack or not, it also seems to have made my Acer laptop much more happy > in dealing with the embedded controllers. envstat now actually reports > several things it never used to find. > > Patch below is commit-worthy, IMHO. rtk0 works for me now. Cheers, -- -- ~Cherry *** acpi_machdep.c.~1.13.~ Fri Mar 2 05:46:26 2007 --- acpi_machdep.c Fri Mar 2 05:48:28 2007 *************** *** 152,157 **** --- 152,161 ---- for (i = 0; i < mp_nbus; i++) { for (mip = mp_busses[i].mb_intrs; mip != NULL; mip = mip->next) { + /* Check for MADT Override. */ + if ((mip->sflags & MPI_OVR) && + (mip->bus_pin == InterruptNumber)) + InterruptNumber = mip->global_int;(Continue reading)
2 Mar 2007 10:27
Re: acpi SCI interrupt override bug
Frank van der Linden <fvdl <at> netbsd.org>
2007-03-02 09:27:54 GMT
2007-03-02 09:27:54 GMT
Cherry G. Mathew wrote: > Patch below is commit-worthy, IMHO. rtk0 works for me now. That does look better. However, I think we need to look at one more thing: if the override should basically be ignored, as this patch effectively does, then we might have an ACPI implementation where the override is bad, and should already be ignored (marked with a quirk) earlier. I know that other OSs do have suck quirks in their tables, and I think this might be the same scenario. Maybe you can verify that (I don't have much time right now). - Frank
2 Mar 2007 11:28
Re: acpi SCI interrupt override bug
Cherry G. Mathew <cherry.g.mathew <at> gmail.com>
2007-03-02 10:28:05 GMT
2007-03-02 10:28:05 GMT
On 3/2/07, Frank van der Linden <fvdl <at> netbsd.org> wrote: > Cherry G. Mathew wrote: > > Patch below is commit-worthy, IMHO. rtk0 works for me now. > That does look better. However, I think we need to look at one more > thing: if the override should basically be ignored, as this patch > effectively does, then we might have an ACPI implementation where the > override is bad, and should already be ignored (marked with a quirk) > earlier. I know that other OSs do have suck quirks in their tables, and > I think this might be the same scenario. Maybe you can verify that (I > don't have much time right now). I'm not sure I understand. What's happening here is that the intel acpica code is (incorrectly ?) calling acpi_md_OsInstallInterruptHandler() with the initially probed FADT interrupt value. What I'm doing is to match up the old FADT value which has been saved in mip->bus_pin ( mpacpi.c:mpacpi_nonpci_intr():254 ) and if they match-up, then patch the requested Interrupt to the MADT global_int value ( which has already been parsed and saved. ). Are you suggesting that the MADT overrides themselves may be wrong ? If so how would the OS know and what would be the canonical setting ? -- -- ~Cherry
RSS Feed