Re: will openbsd run on this system?
You should be able to find a better system than this.. I bought a Shuttle SN25P that runs OpenBSD very nicely. There are only a few issues. The on-board sound (some Via Envy24 chipset) doesn't work. It doesn't really matter because I use a M-Audio MobilePre (for tracking guitar stuff) that is connected via USB. Firewire doesn't work, but that is to be expected. Also, the nfe0 interface times out every now and again, but I've been porting some fixes from NetBSD and I think the issue is fixed, I am just going to play around more with it to make sure the driver is in fact not timing out anymore. On 6/18/07, Juan Miscaro <[EMAIL PROTECTED]> wrote: I would like to buy this system but I am unsure whether OpenBSD (4.1) will recognize all the components. The chipset in particular. Comments welcome on an alternative. I am looking for at least 2 hard drives and the ability to have 2 network cards (ideally one being wireless). http://us.shuttle.com/T3100_3.aspx Thank you very much, Juan Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail at http://mrd.mail.yahoo.com/try_beta?.intl=ca
Re: nfe0 problem (obsd 4.1)
You might be interested in some unofficial patches I had created when
experiencing the same thing. I hadn't officially released these
because of the awful DELAY() timeout hack taken from the original nfe
code from DragonFly BSD. Most of the updates were taken from NetBSD.
Either way, what you would be interested in is the encap_delay stuff,
specifically the part in nfe.c where it actually assigns the variable:
case PCI_PRODUCT_NVIDIA_CK804_LAN1:
case PCI_PRODUCT_NVIDIA_CK804_LAN2:
+ sc->sc_encap_delay = 10;
+ break;
You would obviously have to locate where your interface matches and
assign it there. For me, my interface is a CK804. Not sure if it was
LAN1 or LAN2, but I assigned the delay to both anyway.
These patches seemed to work good for me, didn't experience any
timeouts, YMMV. Let me know if this works. These will apply cleanly
against 4.1-RELEASE.
http://lysergik.com/~tony/openbsd/
On 6/25/07, patrick keshishian <[EMAIL PROTECTED]> wrote:
On 6/24/07, Vijay Sankar <[EMAIL PROTECTED]> wrote:
> On Sunday 24 June 2007 13:50, patrick keshishian wrote:
> > Hi,
> >
> > I've been noticing some strange problems with the built-in nfe0
> > interface on my desktop. Actually I've seen it on two such
> > computers, but the description below is for my current desktop PC.
> >
> > The PC is running `cvs up -dP -rOPENBSD_4_1' built. I'm including
> > netstat, ifconfig output[1] and dmesg below[2].
> >
> > I've noticed that once in a while the nfe0 interface will stop
> > sending and receiving data. At this point I can not make it work
> > again. The only solution I have is to reboot the box. I have
> > installed a dc0 card in the box since. The problem seemed
> > intermittent and not reliably reproducible. But I think I found
> > a way to reproduce this problem on demand (at least for the time
> > being). I have an ssh session to another box, on which I run
> > '/usr/bin/nm somelib.so'. After a page or two of output the
> > terminal "hangs". At this point nfe0 becomes unresponsive.
> >
> > I switch to the dc0 interface and the terminal finishes the output.
> > Running the nm command while using the dc0 interface doesn't cause
> > any problems.
>
> I experienced similar problems last year and can empathize.
>
> The following items improved my situation somewhat:
>
> 1) BIOS upgrade
> 2) Removing dual boot (I had both OpenBSD and Windows 2003 on one
> machine. There were more errors if I did not power off after shutting
> down Windows 2003 and just did a restart from within Windows. If I did
> not unplug the machine after shutting down Windows, most of the time I
> saw watchdog timeouts but if I powered off the host, and then powered
> it back on, there were fewer errors)
Both boxes I have run solely OpenBSD.
One thing that I did notice was that after switching to the dc0
interface for a short while (5 min or so?), I could switch back
to the nfe0 and it would start responding again. Basically:
# /sbin/ifconfig dc0 delete
# /sbin/route delete default
# /sbin/ifconfig nfe0 inet netmask up
# /sbin/route add default
Therefore, a reboot isn't the only way to "fix" the problem ("reset"
the interface) as I had previously thought. I am not sure exactly
what causes the interface to "reset": idle time, "no carrier", or
something completely random?
Either way, thanks for all the replies!
> I experimented with different combinations and different switches
> (10/100/1000, 10/100, and 10-Base-T). When all the hosts connected to a
> 10/100 switch were running at 100 MB/s then changing nfe0 from
> autoselect to full-duplex using
>
> ifconfig nfe0 media 100baseTX mediaopt full-duplex
>
> seemed to eliminate nfe0 hangs as well as timeouts completely. I am not
> sure whether this has any rational basis or is specific to some weird
> situation in my network, but that has been my experience.
>
> Vijay
>
>
> >
> > Interestingly enough, if I redirect the output of nm to a file
> > and subsequently cat the file the nfe0 interface doesn't seem
> > to exhibit the same problem.
> >
> > I am not sure how to diagnose this problem further. I've enabled
> > debug on the nfe0 interface (/sbin/ifconfig nfe0 debug), but don't
> > see any output.
> >
> > Any and all suggestions are welcome.
> > --patrick
Re: nfe0 problem (obsd 4.1)
After applying the patches, you want to go into if_nfe.c, and after line 244 (PCI_PRODUCT_NVIDIA_MCP55_LAN2) you would want to put "sc->sc_encap_delay = 10;" On 6/27/07, Vijay Sankar <[EMAIL PROTECTED]> wrote: On Wednesday 27 June 2007 10:50, Tony Lambiris wrote: > You might be interested in some unofficial patches I had created when > experiencing the same thing. I hadn't officially released these > because of the awful DELAY() timeout hack taken from the original nfe > code from DragonFly BSD. Most of the updates were taken from NetBSD. > Either way, what you would be interested in is the encap_delay stuff, > specifically the part in nfe.c where it actually assigns the > variable: > > case PCI_PRODUCT_NVIDIA_CK804_LAN1: > case PCI_PRODUCT_NVIDIA_CK804_LAN2: > + sc->sc_encap_delay = 10; > + break; > > You would obviously have to locate where your interface matches and > assign it there. For me, my interface is a CK804. Not sure if it was > LAN1 or LAN2, but I assigned the delay to both anyway. > > These patches seemed to work good for me, didn't experience any > timeouts, YMMV. Let me know if this works. These will apply cleanly > against 4.1-RELEASE. I downloaded your patches and would like to try it out. Thanks very much. Because I don't know what I am doing here, I need a bit more help. How can I find out whether my interface is also a CK804? scanpci -v gave me the following: pci bus 0x cardnum 0x08 function 0x00: vendor 0x10de device 0x0373 nVidia Corporation MCP55 Ethernet CardVendor 0x1043 card 0x8239 (ASUSTeK Computer Inc., Card unknown) STATUS0x00b0 COMMAND 0x0007 CLASS 0x06 0x80 0x00 REVISION 0xa2 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xfe02a000 addr 0xfe02a000 MEM BASE1 0xb001 addr 0xb000 I/O BASE2 0xfe029000 addr 0xfe029000 MEM BASE3 0xfe028000 addr 0xfe028000 MEM MAX_LAT 0x14 MIN_GNT 0x01 INT_PIN 0x01 INT_LINE 0x0a BYTE_00x43 BYTE_1 0x10 BYTE_2 0x39 BYTE_3 0x82 pci bus 0x cardnum 0x09 function 0x00: vendor 0x10de device 0x0373 nVidia Corporation MCP55 Ethernet CardVendor 0x1043 card 0x8239 (ASUSTeK Computer Inc., Card unknown) STATUS0x00b0 COMMAND 0x0007 CLASS 0x06 0x80 0x00 REVISION 0xa2 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xfe027000 addr 0xfe027000 MEM BASE1 0xac01 addr 0xac00 I/O BASE2 0xfe026000 addr 0xfe026000 MEM BASE3 0xfe025000 addr 0xfe025000 MEM MAX_LAT 0x14 MIN_GNT 0x01 INT_PIN 0x01 INT_LINE 0x0a BYTE_00x43 BYTE_1 0x10 BYTE_2 0x39 BYTE_3 0x82 dmesg shows nfe0 at pci0 dev 8 function 0 "NVIDIA MCP55 LAN" rev 0xa2: irq 10, address 00:17:31:cb:ee:d1 eephy0 at nfe0 phy 1: Marvell 88E1116 Gigabit PHY, rev. 1 nfe1 at pci0 dev 9 function 0 "NVIDIA MCP55 LAN" rev 0xa2: irq 10, address 00:17:31:cb:dd:7a eephy1 at nfe1 phy 1: Marvell 88E1116 Gigabit PHY, rev. 1 > > http://lysergik.com/~tony/openbsd/ > > On 6/25/07, patrick keshishian <[EMAIL PROTECTED]> wrote: > > On 6/24/07, Vijay Sankar <[EMAIL PROTECTED]> wrote: > > > On Sunday 24 June 2007 13:50, patrick keshishian wrote: > > > > Hi, > > > > > > > > I've been noticing some strange problems with the built-in nfe0 > > > > interface on my desktop. Actually I've seen it on two such > > > > computers, but the description below is for my current desktop > > > > PC. > > > > > > > > The PC is running `cvs up -dP -rOPENBSD_4_1' built. I'm > > > > including netstat, ifconfig output[1] and dmesg below[2]. > > > > > > > > I've noticed that once in a while the nfe0 interface will stop > > > > sending and receiving data. At this point I can not make it > > > > work again. The only solution I have is to reboot the box. I > > > > have installed a dc0 card in the box since. The problem seemed > > > > intermittent and not reliably reproducible. But I think I > > > > found a way to reproduce this problem on demand (at least for > > > > the time being). I have an ssh session to another box, on > > > > which I run '/usr/bin/nm somelib.so'. After a page or two of > > > > output the terminal "hangs". At this point nfe0 becomes > > > > unresponsive. > > > > > > > > I switch to the dc0 interface and the terminal finishes the > > > > output. Running the nm command while using the dc0 interface > > > > doesn't cause any problems. > > > > > > I experienced similar problems last year and can empathize
AMD Releases 900+ Pages Of GPU Specs
http://www.phoronix.com/scan.php?page=news_item&px=NjA1Mw Thoughts?
Re: flashdist-20050601 for OpenBSD 3.7
Its a useful utility when you have to make tftpboot images. Henning Brauer wrote: * Stephen Marley <[EMAIL PROTECTED]> [2005-06-02 19:52]: Just my opinion: but these days, with large (250MB+) CFs so cheap, isn't it a better idea just to do an ordinary minimal install with a Generic kernel and mount the writeable parts of the system with mount_mfs -P? yes. -- Tony Lambiris [ [EMAIL PROTECTED] ] "End users are ruining computing."
Re: Booting off USB-stick emulated as floppy
Booting USB is no problem for me... here is a snippet of code I use to
automate this process:
(note, you might have to run this on a -current box)
#!/bin/sh
# read disk from command line
DISK=$1
# default values for Kingston 64M DataTraveler
CYLS=120
HEADS=16
SECTS=63
if [ $DISK ]; then
fdisk -i -c $CYLS -h $HEADS -s $SECTS $DISK
disklabel -f /tmp/fstab -E $DISK # interactive edit, can be automated
newfs -b 4096 ${DISK}a
else
echo "usage: $0 (ie: sd0)"
fi
Alexey E. Suslikov wrote:
some BIOSes unable to represent USB-stick as ordinary
hard disk with real geometry.
instead of it I see fd1 due "machine disk" with 1.44M
floppy geometry (80/2/18).
I have tried to copy over floppy??.fs (which is in
80/2/18 geometry) to USB-stick but it failed to boot.
does anybody achieve some success booting using USB-
stick emulated as floppy?
What kind of machine is this?
i386
http://www.tyan.com/products/html/tomcati845gl.html
BIOS 2.01
"copied over"..how?
(there's a lot of wrong ways. Few right ways)
"dd if=floppy??.fs of=/dev/rsd0c bs=512" on other box
"failed to boot"..how?
"Loading:."
--
Tony Lambiris [ [EMAIL PROTECTED] ]
"so if it is really hard for you then perhaps you are just
retarded and need treatment w/ electricity and if that does
not help then perhaps should not use computers..."
Re: Problem compiling wget from ports
Why not just: pkg_add ftp://ftp.openbsd.org/pub/OpenBSD/3.7/packages/`uname -m`/wget-1.8.2.tgz Federico Giannici wrote: Clint M. Sand wrote: On Sun, Jun 05, 2005 at 11:09:23PM +0200, Federico Giannici wrote: I have a problem compiling wget from the ports. Here is the final part of the "make" output: cc -O2 -pipe -DINET6 -o wget cmpt.o connect.o cookies.o fnmatch.o ftp.o ftp-basic.o ftp-ls.o ftp-opie.o hash.o headers.o host.o html-parse.o html-url.o http.o init.o log.o main.o gen-md5.o gnu-md5.o netrc.o progress.o rbuf.o recur.o res.o retr.o safe-ctype.o snprintf.o url.o utils.o version.o -L/usr/local/lib connect.o(.text+0x1dd): In function `connect_to_one': : undefined reference to `__errno' connect.o(.text+0x1eb): In function `connect_to_one': : undefined reference to `__errno' connect.o(.text+0x1f7): In function `connect_to_one': : undefined reference to `__errno' connect.o(.text+0x219): In function `connect_to_one': : undefined reference to `__errno' connect.o(.text+0x235): In function `connect_to_one': : undefined reference to `__errno' connect.o(.text+0x259): more undefined references to `__errno' follow collect2: ld returned 1 exit status gmake[1]: *** [wget] Error 1 gmake[1]: Leaving directory `/usr/ports/net/wget/w-wget-1.8.2/wget-1.8.2/src' gmake: *** [src] Error 2 *** Error code 2 Stop in /usr/ports/net/wget (line 1769 of /usr/ports/infrastructure/mk/bsd.port.mk). The system is an i386 installed with an almost final 3.7 (the kernel was the same of the release one) and then I made an Upgrade from the official 3.7 CD when arrived. A lot of other ports compiled without any problem. Any hints? Thanks. -- ___ __ |- [EMAIL PROTECTED] |ederico Giannici http://www.neomedia.it ___ You didn't mention if ou also upgraded your ports tree to 3.7-release or just the base binaries and Kernel. Yes, it is from 3.7 CD too. Bye. -- Tony Lambiris [ [EMAIL PROTECTED] ] "so if it is really hard for you then perhaps you are just retarded and need treatment w/ electricity and if that does not help then perhaps should not use computers..."
Re: NFS sometime stalls
The only NFS problems I've really ever had w/ OpenBSD, is if our NFS server goes down or is rebooted, the NFS mount never comes back and will essentially hang (especially if you try to unmount the stale link)... I've never tried a mount -u or a unmount -f tho... Federico Giannici wrote: I have an MX mail server that receives email messages and saves them to an email storage server via NFS. Both pc are OpenBSD i386, version 3.7 for the NFS client (MX server) and 3.4 for the NFS server (the storage server). From time to time the connections from the NFS clients seem to freeze (at least the new ones). I applied the famous NFS patch that disables write gathering for v3 (http://marc.theaimsgroup.com/?l=openbsd-misc&m=110676811107986&w=2), but the problem remains (perhaps a little less frequent). I have also raised the number of nfsd processes and "vfs.nfs.iothreads" to 20. The server uses a fxp interface and the client an sk one. From "netstat -i" I have seen that there are no errors or collisions. Here is the nfsstat output for the client and the server after almost a day of uptime: Client Info: Rpc Counts: Getattr SetattrLookup Readlink Read WriteCreate Remove 13640012429651 0 13653178549 25790 25819 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 5415 20016 016 0336388 0 1359316 MknodFsstatFsinfo PathConfCommit 0 27008 1 0 42530 Rpc Info: TimedOut Invalid X Replies Retries Requests 4 0 139 28889 2600564 Cache Info: Attr HitsMisses Lkup HitsMisses BioR HitsMisses BioW Hits Misses 1669083136400 1239823424253 67080 13653632860 178549 BioRLHitsMisses BioD HitsMisses DirE HitsMisses 0 0 0 0 26996 27954 Server Info: Getattr SetattrLookup Readlink Read WriteCreate Remove 90847 0269426 0 8882137000 16908 16947 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 3263 13427 0 0 0197032 0 872760 MknodFsstatFsinfo PathConfCommit 0 16594 0 0 28598 Server Ret-Failed 65447 Server Faults 0 Server Cache Stats: Inprog Idem Non-idemMisses 21 14256 920 1657428 Server Write Gathering: WriteOps WriteRPC Opsaved 136997137000 3 What make me worry is the hight value of the "Ret-Failed" field. Is it normal? I have no experience of NFS, is it normal that sometime ot stalls? What else I could do to prevent this to happen? Thanks. -- Tony Lambiris [ [EMAIL PROTECTED] ] "so if it is really hard for you then perhaps you are just retarded and need treatment w/ electricity and if that does not help then perhaps should not use computers..."
Re: moving to a bigger disk
its quite simple... boot into single user mode, foreach partition you have, mount the src under /src/X and /dst/X (where src is the old disk and dst is the new disk) and do a: cd /src/X; tar cf - . | (cd /dst/X; tar xpf - ) ive used this before, works great. after that just make sure you install your boot blocks. Mihai IACOB wrote: Hello! I need to move my OpenBSD 3.6 installation to a bigger disk, because the /usr partition is 92% full. And no, I cannot keep both disks. I searched google and found nothing similar to my situation. I think I can partition and label the new disk, dd the / partition, then copy /var and /usr with tar/pax/cpio, switch the disks and pray it works. Do you think the above steps might work or did anyone do this before? Thank you for your time. Mihai IACOB -- Tony Lambiris [ [EMAIL PROTECTED] ] "so if it is really hard for you then perhaps you are just retarded and need treatment w/ electricity and if that does not help then perhaps should not use computers..."
Re: GRUB's boot parameter
speaking of GRUB: "The most embarassing comment came from a developer of the GRUB project who went only by the name of 'Gord'. 'This function is truly horrid,' he wrote. 'We try opening the device, then severely abuse the GEOMETRY->flags field to pass a file descriptor to biosdisk. Thank God nobody's looking at this comment, or my reputation would be ruined.'" -- From the OpenSolaris code, h00h0h0h0h0 Bob Beck wrote: This is probably because OpenBSD != NetBSD, and I suspect grub is using whatever it's notion of a netbsd boot block is. You probably have to fix grub somehow to use a current OpenBSD boot block, as opposed to attempting to start a kernel boot as if it were NetBSD. Ask them for a --type=openbsd option would be a start. -Bob * ikesan <[EMAIL PROTECTED]> [2005-06-16 10:23]: Hellow. I'm gonna boot OpenBSD from GRUB in FD. The parameter is following. root (hd2,0,a) kernel --type=netbsd /bsd But unfortunately panic occured. Message is following. panic: /boot too old: upgrade! This is first time that I installed OpenBSD in my PC (Athron CPU). And this PC contains some kind of OSs. So I usualy boot any OS from GRUB in FD. If version of OpenBSD 3.7 's boot parameter changed or parameter I set was wrong, please let me know correct thing. -- [EMAIL PROTECTED] - -- Tony Lambiris [ [EMAIL PROTECTED] ] "so if it is really hard for you then perhaps you are just retarded and need treatment w/ electricity and if that does not help then perhaps should not use computers..."
Dell Inspiron 700m
I've got some good news.. I installed OpenBSD on my Dell Inspiron 700m... so far (with a snapshot of Jun 15th) I am able to get wireless to be functional, and I just finished porting over the the 855resolution hack for the VBIOS to get full widescreen 1280x800 support (broken Dell BIOS workaround). I still have yet to test sound and such (even though it is detected successfully), but once I straighten everything out with this laptop, I will post a dmesg and the code to fix the VBIOS. ROCKIN!! :) -- Tony Lambiris [ [EMAIL PROTECTED] ] "so if it is really hard for you then perhaps you are just retarded and need treatment w/ electricity and if that does not help then perhaps should not use computers..."
openbsd fdisk
is there a way to have fdisk re-inititalize the disk (fdisk -i ) without being prompted to go ahead with the init? thanks. -- Tony Lambiris [ [EMAIL PROTECTED] ] "so if it is really hard for you then perhaps you are just retarded and need treatment w/ electricity and if that does not help then perhaps should not use computers..."
vge0 on Abit Av8 (amd64)
64 DRAM Cfg" rev 0x00 pchb9 at pci0 dev 24 function 3 "AMD AMD64 Misc Cfg" rev 0x00 isa0 at mainbus0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pcppi0 at isa0 port 0x61 spkr0 at pcppi0 sysbeep0 at pcppi0 dkcsum: wd0 matches BIOS drive 0x80 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302 -- Tony Lambiris [ [EMAIL PROTECTED] ] "so if it is really hard for you then perhaps you are just retarded and need treatment w/ electricity and if that does not help then perhaps should not use computers..."
i386 binaries on amd64
Is there a way to compile something on i386 OpenBSD box to run on amd64? or is there a sysctl option I am missing? Thanks. -- Tony Lambiris [ [EMAIL PROTECTED] ] "so if it is really hard for you then perhaps you are just retarded and need treatment w/ electricity and if that does not help then perhaps should not use computers..."
Re: i386 binaries on amd64
In reading some mailing lists, I noticed some people pass in the -m32 flag when compiling to compile 32bit instead of 64bit... I added the flag to the Makefile and everything compiles except when I try to link all the objects into an executable, I get these errors: /usr/bin/ld: warning: i386 architecture of input file `some.o' is incompatible with i386:x86-64 output Is compiling this way possible at all? Ted Unangst wrote: On Mon, 29 Aug 2005, Stuart Henderson wrote: --On 29 August 2005 16:34 -0500, Tony Lambiris wrote: Is there a way to compile something on i386 OpenBSD box to run on amd64? or is there a sysctl option I am missing? Cross-compiling between architectures is not supported, see list archives for reasons why. that's not the question he was asking, but the answer is no anyway. -- Tony Lambiris [ [EMAIL PROTECTED] ] "so if it is really hard for you then perhaps you are just retarded and need treatment w/ electricity and if that does not help then perhaps should not use computers..."
Re: DELL Latitude D400 without X
I actually hacked an existing util for NetBSD to run flawlessly on
OpenBSD (I have a Dell inspiron 700m).
You can get it here:
http://lysergik.com/~tony/openbsd.phtml
Baldur Sigurpsson wrote:
hi
use this thing:
http://damien.bergamini.free.fr/i855vidctl/
just remember to put the command in /etc/rc.securelevel because on
openbsd you cannot access some devices you need to, in contrast to linux.
works on my dell inspiron 500m with the 855GM crap:)
Regards, Baldur
Uwe Dippel wrote:
... a continuation of around a year ago
('Warning: Possible Bug in BIOS DELL Latitude D400_A06 !')
It is still valid for 3.7.
In the meantime, the problem has turned out to be really a problem of
crappy DELL BIOSes; now at A08 it still does the same:
Any activation of X freezes the machine completely with a yellowish
screen.
855wrap on http://www.chzsoft.com.ar/855patch.html solves this. On Linux.
There you compile a binary and run it before starting X. On any machine.
Now I tried to do the same on OpenBSD with the expected result:'Abort
trap'.
Not quite so expected was, that the source didn't want to compile on
OpenBSD 3.7:
make: don't know how to make %.c.
Stop in ..
I bet quite a few newer DELL notebooks are affected; and I appreciate any
suggestion how to make it work on OpenBSD.
I read the archives here and googled. No result.
Uwe
--
Tony Lambiris [ [EMAIL PROTECTED] ]
"so if it is really hard for you then perhaps you are just
retarded and need treatment w/ electricity and if that does
not help then perhaps should not use computers..."
i386 branch on amd64
I know this will run fine, but will the dual-core and such be detected and setup correctly, or is this an amd64 specific thing? TIA. -- Tony Lambiris [ [EMAIL PROTECTED] ] "so if it is really hard for you then perhaps you are just retarded and need treatment w/ electricity and if that does not help then perhaps should not use computers..."
pciide: DMA vs. ATA133
We have some motherboards with (what we think) are the same chips and revisions with the same hard drives, but some drives are being detected as DMA and others as ATA133. Here is an example: pciide0 at pci0 dev 17 function 1 "VIA VT82C571 IDE" rev 0x06: ATA133, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0 at pci0 dev 15 function 0 "VIA VT82C571 IDE" rev 0x06: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 As you can see it's the same IDE chipset, same revision, same drives.. the only thing I can think of is it's an IDE ribbon issue, but the ribbons we used (which were mixed from the cases and the motherboard boxes), were brand new. Any suggestions? TIA. -- Tony Lambiris [ [EMAIL PROTECTED] ] "so if it is really hard for you then perhaps you are just retarded and need treatment w/ electricity and if that does not help then perhaps should not use computers..."
Re: pciide: DMA vs. ATA133
I (think I) found the problem... I will be posting a patch shortly if I confirm my suspicions. Thanks. Tony Lambiris wrote: We have some motherboards with (what we think) are the same chips and revisions with the same hard drives, but some drives are being detected as DMA and others as ATA133. Here is an example: pciide0 at pci0 dev 17 function 1 "VIA VT82C571 IDE" rev 0x06: ATA133, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0 at pci0 dev 15 function 0 "VIA VT82C571 IDE" rev 0x06: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 As you can see it's the same IDE chipset, same revision, same drives.. the only thing I can think of is it's an IDE ribbon issue, but the ribbons we used (which were mixed from the cases and the motherboard boxes), were brand new. Any suggestions? TIA. -- Tony Lambiris [ [EMAIL PROTECTED] ] "so if it is really hard for you then perhaps you are just retarded and need treatment w/ electricity and if that does not help then perhaps should not use computers..."
Re: pciide: DMA vs. ATA133
Well I thought I knew what the problem was (nope).. I found something interesting though... The motherboards that don't setup UDMA properly uses a "VIA VT8237 ISA" for pcib; the one's that setup UDMA properly uses a "VIA VT8235 ISA". I added some debugging in pciide.c in function apollo_chip_map on the switch statement, and the pcib_id it's switching on is 0x0571, which in pcidevs is "VT82C571 IDE". Does that mean somewhere the VT8237 chipset isn't being setup correctly or something? I'm a little confused at this juncture, any light that can be shed would be greatly appriciated. Thanks. Tony Lambiris wrote: I (think I) found the problem... I will be posting a patch shortly if I confirm my suspicions. Thanks. Tony Lambiris wrote: We have some motherboards with (what we think) are the same chips and revisions with the same hard drives, but some drives are being detected as DMA and others as ATA133. Here is an example: pciide0 at pci0 dev 17 function 1 "VIA VT82C571 IDE" rev 0x06: ATA133, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0 at pci0 dev 15 function 0 "VIA VT82C571 IDE" rev 0x06: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 As you can see it's the same IDE chipset, same revision, same drives.. the only thing I can think of is it's an IDE ribbon issue, but the ribbons we used (which were mixed from the cases and the motherboard boxes), were brand new. Any suggestions? TIA. -- Tony Lambiris [ [EMAIL PROTECTED] ] "so if it is really hard for you then perhaps you are just retarded and need treatment w/ electricity and if that does not help then perhaps should not use computers..."
Re: pciide: DMA vs. ATA133
I forgot to ask, would it be bad practice to just add PCI_PRODUCT_VIATECH_VT82C571 to one of the cases in the switch statement? It seems like this might go a little deeper Tony Lambiris wrote: Well I thought I knew what the problem was (nope).. I found something interesting though... The motherboards that don't setup UDMA properly uses a "VIA VT8237 ISA" for pcib; the one's that setup UDMA properly uses a "VIA VT8235 ISA". I added some debugging in pciide.c in function apollo_chip_map on the switch statement, and the pcib_id it's switching on is 0x0571, which in pcidevs is "VT82C571 IDE". Does that mean somewhere the VT8237 chipset isn't being setup correctly or something? I'm a little confused at this juncture, any light that can be shed would be greatly appriciated. Thanks. Tony Lambiris wrote: I (think I) found the problem... I will be posting a patch shortly if I confirm my suspicions. Thanks. Tony Lambiris wrote: We have some motherboards with (what we think) are the same chips and revisions with the same hard drives, but some drives are being detected as DMA and others as ATA133. Here is an example: pciide0 at pci0 dev 17 function 1 "VIA VT82C571 IDE" rev 0x06: ATA133, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0 at pci0 dev 15 function 0 "VIA VT82C571 IDE" rev 0x06: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 As you can see it's the same IDE chipset, same revision, same drives.. the only thing I can think of is it's an IDE ribbon issue, but the ribbons we used (which were mixed from the cases and the motherboard boxes), were brand new. Any suggestions? TIA. -- Tony Lambiris [ [EMAIL PROTECTED] ] "so if it is really hard for you then perhaps you are just retarded and need treatment w/ electricity and if that does not help then perhaps should not use computers..."
Re: pciide: DMA vs. ATA133
Sorry for all the noise, this seems to have fixed it (from NetBSD):
--- via82c586.c.origMon Sep 12 19:38:35 2005
+++ via82c586.c Mon Sep 12 20:27:28 2005
@@ -256,9 +256,10 @@
reg = pci_conf_read(ph->ph_pc, ph->ph_tag,
VP3_CFG_PIRQ_REG);
shift = vp3_cfg_trigger_shift[i];
- /* XXX we only upgrade the trigger here */
if (trigger == IST_LEVEL)
reg &= ~(VP3_CFG_TRIGGER_MASK << shift);
+ else
+ reg |= (VP3_CFG_TRIGGER_EDGE << shift);
pci_conf_write(ph->ph_pc, ph->ph_tag,
VP3_CFG_PIRQ_REG, reg);
break;
Tony Lambiris wrote:
I forgot to ask, would it be bad practice to just add
PCI_PRODUCT_VIATECH_VT82C571 to one of the cases in the switch
statement? It seems like this might go a little deeper
Tony Lambiris wrote:
Well I thought I knew what the problem was (nope).. I found something
interesting though...
The motherboards that don't setup UDMA properly uses a "VIA VT8237
ISA" for pcib; the one's that setup UDMA properly uses a "VIA VT8235
ISA". I added some debugging in pciide.c in function apollo_chip_map
on the switch statement, and the pcib_id it's switching on is 0x0571,
which in pcidevs is "VT82C571 IDE". Does that mean somewhere the
VT8237 chipset isn't being setup correctly or something?
I'm a little confused at this juncture, any light that can be shed
would be greatly appriciated.
Thanks.
Tony Lambiris wrote:
I (think I) found the problem... I will be posting a patch shortly if
I confirm my suspicions.
Thanks.
Tony Lambiris wrote:
We have some motherboards with (what we think) are the same chips
and revisions with the same hard drives, but some drives are being
detected as DMA and others as ATA133. Here is an example:
pciide0 at pci0 dev 17 function 1 "VIA VT82C571 IDE" rev 0x06:
ATA133, channel 0 configured to compatibility, channel 1 configured
to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
pciide0 at pci0 dev 15 function 0 "VIA VT82C571 IDE" rev 0x06: DMA,
channel 0 configured to compatibility, channel 1 configured to
compatibility
wd0 at pciide0 channel 0 drive 0:
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
As you can see it's the same IDE chipset, same revision, same
drives.. the only thing I can think of is it's an IDE ribbon issue,
but the ribbons we used (which were mixed from the cases and the
motherboard boxes), were brand new.
Any suggestions?
TIA.
--
Tony Lambiris [ [EMAIL PROTECTED] ]
"so if it is really hard for you then perhaps you are just
retarded and need treatment w/ electricity and if that does
not help then perhaps should not use computers..."
Re: pciide: DMA vs. ATA133
Man I must need sleep or something... this doesn't fix my problem, I
forgot I had the extra case in the switch statement still in pciide.c.
That did work, however, adding PCI_PRODUCT_VIATECH_VT82C571 as a case.
Like I said before I don't know if this is the right way to do this, but
it's a temporary fix for me.
Over and out, sorry again for the noise.
Tony Lambiris wrote:
Sorry for all the noise, this seems to have fixed it (from NetBSD):
--- via82c586.c.origMon Sep 12 19:38:35 2005
+++ via82c586.c Mon Sep 12 20:27:28 2005
@@ -256,9 +256,10 @@
reg = pci_conf_read(ph->ph_pc, ph->ph_tag,
VP3_CFG_PIRQ_REG);
shift = vp3_cfg_trigger_shift[i];
- /* XXX we only upgrade the trigger here */
if (trigger == IST_LEVEL)
reg &= ~(VP3_CFG_TRIGGER_MASK << shift);
+ else
+ reg |= (VP3_CFG_TRIGGER_EDGE << shift);
pci_conf_write(ph->ph_pc, ph->ph_tag,
VP3_CFG_PIRQ_REG, reg);
break;
Tony Lambiris wrote:
I forgot to ask, would it be bad practice to just add
PCI_PRODUCT_VIATECH_VT82C571 to one of the cases in the switch
statement? It seems like this might go a little deeper
Tony Lambiris wrote:
Well I thought I knew what the problem was (nope).. I found something
interesting though...
The motherboards that don't setup UDMA properly uses a "VIA VT8237
ISA" for pcib; the one's that setup UDMA properly uses a "VIA VT8235
ISA". I added some debugging in pciide.c in function apollo_chip_map
on the switch statement, and the pcib_id it's switching on is 0x0571,
which in pcidevs is "VT82C571 IDE". Does that mean somewhere the
VT8237 chipset isn't being setup correctly or something?
I'm a little confused at this juncture, any light that can be shed
would be greatly appriciated.
Thanks.
Tony Lambiris wrote:
I (think I) found the problem... I will be posting a patch shortly
if I confirm my suspicions.
Thanks.
Tony Lambiris wrote:
We have some motherboards with (what we think) are the same chips
and revisions with the same hard drives, but some drives are being
detected as DMA and others as ATA133. Here is an example:
pciide0 at pci0 dev 17 function 1 "VIA VT82C571 IDE" rev 0x06:
ATA133, channel 0 configured to compatibility, channel 1 configured
to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
pciide0 at pci0 dev 15 function 0 "VIA VT82C571 IDE" rev 0x06: DMA,
channel 0 configured to compatibility, channel 1 configured to
compatibility
wd0 at pciide0 channel 0 drive 0:
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
As you can see it's the same IDE chipset, same revision, same
drives.. the only thing I can think of is it's an IDE ribbon issue,
but the ribbons we used (which were mixed from the cases and the
motherboard boxes), were brand new.
Any suggestions?
TIA.
--
Tony Lambiris [ [EMAIL PROTECTED] ]
"so if it is really hard for you then perhaps you are just
retarded and need treatment w/ electricity and if that does
not help then perhaps should not use computers..."
Re: pciide: DMA vs. ATA133
It's due to chipset detection, so in the interm, I added this:
/usr/src/sys/dev/pci/pciide.c -- line 2650
case PCI_PRODUCT_VIATECH_VT82C571:
Or a diff:
--- pciide.c.orig Wed Nov 9 10:35:24 2005
+++ pciide.cWed Nov 9 10:35:43 2005
@@ -2648,6 +2648,7 @@
sc->sc_wdcdev.UDMA_cap = 6;
break;
case PCI_PRODUCT_VIATECH_VT8235_ISA:
+ case PCI_PRODUCT_VIATECH_VT82C571:
printf(": ATA133");
sc->sc_wdcdev.UDMA_cap = 6;
break;
You can copy/paste that in a file and run patch -p0 < file.diff
This isnt correct at all, but it works.
Sebastian Dehne wrote
Hi Tony,
It turns I'm having the same problem and saw you've done some research.
# dmesg| grep DMA
pciide0 at pci0 dev 15 function 0 "VIA VT82C571 IDE" rev 0x06: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
wd1(pciide0:0:1): using PIO mode 4, DMA mode 2
wd2(pciide0:1:1): using PIO mode 4, DMA mode 2
What exact changes did you make to pciide.c in order to enable
Ultra-DMA? I see the switch at around line 2610 in pciide.c, but cannot
work out how to add PCI_PRODUCT_VIATECH_VT82C571.
I'm running 3.8.
thanks,
Sebastian
Tony Lambiris wrote:
Man I must need sleep or something... this doesn't fix my problem, I
forgot I had the extra case in the switch statement still in pciide.c.
That did work, however, adding PCI_PRODUCT_VIATECH_VT82C571 as a case.
Like I said before I don't know if this is the right way to do this, but
it's a temporary fix for me.
Over and out, sorry again for the noise.
Tony Lambiris wrote:
Sorry for all the noise, this seems to have fixed it (from NetBSD):
--- via82c586.c.origMon Sep 12 19:38:35 2005
+++ via82c586.c Mon Sep 12 20:27:28 2005
@@ -256,9 +256,10 @@
reg = pci_conf_read(ph->ph_pc, ph->ph_tag,
VP3_CFG_PIRQ_REG);
shift = vp3_cfg_trigger_shift[i];
- /* XXX we only upgrade the trigger here */
if (trigger == IST_LEVEL)
reg &= ~(VP3_CFG_TRIGGER_MASK << shift);
+ else
+ reg |= (VP3_CFG_TRIGGER_EDGE << shift);
pci_conf_write(ph->ph_pc, ph->ph_tag,
VP3_CFG_PIRQ_REG, reg);
break;
Tony Lambiris wrote:
I forgot to ask, would it be bad practice to just add
PCI_PRODUCT_VIATECH_VT82C571 to one of the cases in the switch
statement? It seems like this might go a little deeper
Tony Lambiris wrote:
Well I thought I knew what the problem was (nope).. I found something
interesting though...
The motherboards that don't setup UDMA properly uses a "VIA VT8237
ISA" for pcib; the one's that setup UDMA properly uses a "VIA VT8235
ISA". I added some debugging in pciide.c in function apollo_chip_map
on the switch statement, and the pcib_id it's switching on is 0x0571,
which in pcidevs is "VT82C571 IDE". Does that mean somewhere the
VT8237 chipset isn't being setup correctly or something?
I'm a little confused at this juncture, any light that can be shed
would be greatly appriciated.
Thanks.
Tony Lambiris wrote:
I (think I) found the problem... I will be posting a patch shortly
if I confirm my suspicions.
Thanks.
Tony Lambiris wrote:
We have some motherboards with (what we think) are the same chips
and revisions with the same hard drives, but some drives are being
detected as DMA and others as ATA133. Here is an example:
pciide0 at pci0 dev 17 function 1 "VIA VT82C571 IDE" rev 0x06:
ATA133, channel 0 configured to compatibility, channel 1 configured
to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
pciide0 at pci0 dev 15 function 0 "VIA VT82C571 IDE" rev 0x06: DMA,
channel 0 configured to compatibility, channel 1 configured to
compatibility
wd0 at pciide0 channel 0 drive 0:
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
As you can see it's the same IDE chipset, same revision, same
drives.. the only thing I can think of is it's an IDE ribbon issue,
but the ribbons we used (which were mixed from the cases and the
motherboard boxes), were brand new.
Any suggestions?
TIA.
Re: Cannot boot version 3.8 on HP pavilion 422
Try: boot -c disable fdc Lionel Vidal wrote: I tried to boot the new 3.8 version on a (rather old) PC, a HP pavilion 422.fr. I tried both to boot from cdrom38.fs and floppy38.fs and the result is the same : OpenBSD i386 BOOT 2.10 boot> booting fd0a:/bsd: 3263620 Entry point at 0x100120 Lots of blue-background infos CD-Rom, DVD-Rom, nvidia cards OK ... Keyboard OK (a logitech wireless) after a while ... fdc0 at ISA port 0x3f0/6 Irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec ... And then nothing... I waited for some time but the PC is frozen, and the only thing to do is to unplug it. Note that the hardware works well : on the 80Go HD, I have an old Win89SE (10Go) and FreeBSD 5.4 (10Go) and I can boot both (my intend was to dedicate that PC to OpenBSD). Sorry to not give the whole log of messages, but I cannot copy them except by writing them fast on paper. I could get some specific part if required though. Any ideas? (Sorry if I did wrong something obvious :-)
Re: nsswitch
probably not -- but we use ldap here at work, and the auth_ldap in the ports tree works great. Aiko Barz wrote: I googled, but I couldn't figure out the current status. My problem: I tried to move my mailservers from Linux to OpenBSD. It's a qmail-ldap system with its users stored in OpenLDAP. Each of my users has its own UID. There is only one troublemaker: maildrop. It depends on getpwuid and getpwnam. But OpenBSD doesn't know anything about my LDAP-users. Solution: There are some solutions. maildrop could lookup the account data directly before invoking getpwuid and getpwnam. (I prefer not to write this patch. It ends up in courier-authlib and so on.) The dirty hack is to use the environment variables which are provided by qmail-local ($USER, $HOME). (This is safe for me because chuid gets called before executing maildrop. I'm not happy with this solution.) Another solution would be something like nsswitch. Are there any plans to implement something like this? Bye, Aiko
Re: upgrade from src, gcc exception model problem [was Re: undefined reference to __gxx_personality_sj0]
Actually, I was able to upgrade a few boxes from 3.6 to 3.7. Here is a sent message outline the steps, as much as I can recall of what I had to do: -- SNIP -- Okay, I think I figured out the intricacies of upgrading to 3.7 You need to get the source to 3.6 from an ftp server (src.tar.gz) in the 3.6/i386 directory. You need to update to the latest 3.6 source: cd /usr/src && cvs -d $CVSROOT -q up -rOPENBSD_3_6 -Pd Build gcc3 w/ 3.6 sources: http://openbsd.org/faq/faq5.html#NewCompiler (You need to build gcc with 3.6 sources, I already tried with 3.7 and it fails) Rebuild the entire system with the 3.6 sources (cd /usr/src && make build). rm -rf /usr/src/* and unpack the 3.7 source tree, and inside /usr/src run a `make includes` Once you have followed those outlined steps, you should be able to rebuild the 3.7 tree: cd /usr/src && make obj && make depend && make build ** Dont forget to build/install the GENERIC kernel as well before reboot. Once the system has finished building (and new kernel is in place), sync up the ports to 3.7 and install mergemaster: cd /usr/ports/sysutils/mergemaster && make install clean Run mergemaster, making sure to not overwrite important things. Once your /etc tree is synced up, reboot! Since the official upgrade from 3.6 to 3.7 document isn't out yet, this is the most current doc you can find on what changed: http://openbsd.org/faq/current.html If the outlined steps didn't work for you, please let me know. Henning Brauer wrote: * Benjamin A. Collins <[EMAIL PROTECTED]> [2005-05-06 08:22]: I installed 3.6 fresh from CD, no packages. 'make build' still fails. as others already pointed out a make build of 3.7 will not work on 3.6. -- Tony Lambiris [ [EMAIL PROTECTED] ] "End users are ruining computing."
