Re: ATA: UDMA66, 33 ICRC
It seems =?koi8-r?Q?=22?=Ayrton Senna=?koi8-r?Q?=22=20?= wrote: This became quite tricky, but the main (and the worst problem) was with ATAng. I have Acer's motherboard and IBM's DTLA. Old driver were saying 'Non-ATA 66 cable or device' and perfectly worked in UDMA-33 mode. New driver didn't said a word, but when it tried to read something, everything was ending up with 'ICRC error'. I was already going to hack ata-chipsets to force UDMA-33, but I came upon hw.ata.ata_dma. I need more info to be able to tell what going on... A dmesg from a verbose booted system is mandatory here.. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng still problematic
It seems Jan Srzednicki wrote: As far as problems with dagrab and cdda2wav are conserned - this is because of removal of CDIOCREADAUDIO ioctl in ATAng (see recent thread What's happened to CDIOCREADAUDIO friends) I've seen it (after posting the original mail, though;). Is there going to be any audio reading utility avalaible? When atapicam is broken, I can still use burncd and it works fine. But I don't have any tool to read audio. dd if=/dev/acdXtY of=trackY bs=2352 -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
It seems Vladimir Kushnir wrote: The right way of doing audio graps has been to set the wanted blocksize with CDRIOCSETBLOCKSIZE (not needed if all tracks on the CD is of the same size), then just read from the device. Ioctl's was newer meant to be used to read/write data, its also faster to use the R/W path... Ok, perhaps, but ioctls seem to be more usual way and it's a bit simpler... Still, I'm just user... Rather unhappy now :-( I disagree, but that another matter.. How about just doing: dd if=/dev/acdXtY of=trackY bs=2352 Now that cant be simpler and is already present... Together with sys/cdio.h, where both ioc_read_audio and CDIOCREADAUDIO are declared I'll get rid of those... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault:
Jeff Roberson wrote: On Wed, 17 Sep 2003, Florian C. Smeets wrote: Hi. I get this panic on a system with kernel/world from 03 September. Usually i only run X and xawtv on that system but when i wanted to make world today i got the panic: This was fixed recently. Can you cvsup and rebuild? It doesn't occur anymore. Seems to be fixed. Thanks! Kris Kennaway reported something IMHO similar on 07/31/03 panic: vm_fault: fault on nofault entry, addr: deadc000 Debugger(panic) Stopped at Debugger+0x4d: xchgl %ebx,in_Debugger.0 db trace Debugger(c03c1cf1,c043fd00,c03d3c82,e929f9e4,100) at Debugger+0x4d panic(c03d3c82,deadc000,1,e929fa80,e929fa70) at panic+0xcc vm_fault(c082f000,deadc000,1,0,c5db65f0) at vm_fault+0x1187 trap_pfault(e929fb48,0,deadc1e6,c03d958f,deadc1e6) at trap_pfault+0x163 trap(18,10,10,0,d222036c) at trap+0x2ca calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc0328512, esp = 0xe929fb88, ebp = 0xe929fbb0 --- getdirtybuf(c5ebc8bc,0,1,1,e929fbe8) at getdirtybuf+0x22 flush_deplist(c5ebccc4,1,e929fbe8,e929fbec,0) at flush_deplist+0x32 flush_inodedep_deps(c5c63000,28c4,c040d6ac,c5eefb68,124) at flush_inodedep_deps+0x89 softdep_sync_metadata(e929fca8,0,c03d2cc0,124,0) at softdep_sync_metadata+0x7e ffs_fsync(e929fca8,0,c03c9837,ad8,0) at ffs_fsync+0x3a9 fsync(c5db65f0,e929fd14,c03d958f,3eb,1) at fsync+0x166 syscall(2f,2f,2f,80a1000,0) at syscall+0x253 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (95, FreeBSD ELF32, fsync), eip = 0x2814ca0f, esp = 0xbfbff90c, ebp = 0xbfbff928 --- db ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [current tinderbox] failure on alpha/alpha
Scott Long [EMAIL PROTECTED] writes: Sam is pretty sure that he already fixed this. Is it possible that the tinderbox machine is no longer getting cvs updates? It would seem so. Revision 1.69 of src/sys/net/bridge.c (which fixes this particular problem) is not in the repo on the RTP cluster. John, is something wrong with cvsup on the RTP cluster? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HFS+ driver kernel options?
On Thu, Sep 18, 2003 at 11:22:37PM -0500, David Leimbach wrote: Hey... just looking to see what option I need to enable to get HFS+ support... All you need should be here: http://people.freebsd.org/~yar/hfs/ - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: ATAng still problematic
On Fri, Sep 19, 2003 at 08:02:31AM +0200, Soren Schmidt wrote: It seems Jan Srzednicki wrote: As far as problems with dagrab and cdda2wav are conserned - this is because of removal of CDIOCREADAUDIO ioctl in ATAng (see recent thread What's happened to CDIOCREADAUDIO friends) I've seen it (after posting the original mail, though;). Is there going to be any audio reading utility avalaible? When atapicam is broken, I can still use burncd and it works fine. But I don't have any tool to read audio. dd if=/dev/acdXtY of=trackY bs=2352 Cool. ;) Could you give me a hint what to put in devd.conf to get acdXtY files created automatically when a CD is inserted? -- -- wrzask --= v =-- Winfried --===-- GG# 3838383 --- -- [EMAIL PROTECTED] --- [EMAIL PROTECTED] --===-- http://violent.dream.vg/ --- --= Ride the wild wind - push the envelope, don't sit on the fence, --- -- Ride the wild wind - live life on the razor's edge! =-- Queen -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng still problematic
It seems Jan Srzednicki wrote: dd if=/dev/acdXtY of=trackY bs=2352 Cool. ;) Yes, and that has worked for ages... Could you give me a hint what to put in devd.conf to get acdXtY files created automatically when a CD is inserted? You just need something to open the acdX device (so the drive reads the TOC), I oftyen use cdcontrol -f acdX info, that will also tell how many tracks there are... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
illegal instruction (core dumped) during make cleandir in rescue
Strange, very strange. SOeren, you know my hardware, it is the same MB (ASUS P4S8X or the like - off memory). I built a couple of worlds during the past months. But with the recent cvsups I don't get through. make world or make buildworld both fail nearly exactly at the same place during the cleandir phase. I can repeat the problem when I cd /usr/src/rescue/rescue MAKEOBJDIRPREFIX=/usr/src/rescue/rescue make cleandir cd /usr/src/rescue/rescue/../../usr.bin/vi MAKEOBJDIRPREFIX=/usr/obj/usr/src /rescue/rescue/usr/src/rescue/rescue make cleandepend rm -f .depend GPATH GRTAGS GSYMS GTAGS cd /usr/src/rescue/rescue/../../gnu/usr.bin/gzip MAKEOBJDIRPREFIX=/usr/obj/u sr/src/rescue/rescue/usr/src/rescue/rescue make cleandepend rm -f .depend GPATH GRTAGS GSYMS GTAGS cd /usr/src/rescue/rescue/../../gnu/usr.bin/tar MAKEOBJDIRPREFIX=/usr/obj/us r/src/rescue/rescue/usr/src/rescue/rescue make cleandepend rm -f .depend GPATH GRTAGS GSYMS GTAGS === doc Illegal instruction (core dumped) # Doing it another time: rm -f .depend GPATH GRTAGS GSYMS GTAGS cd /usr/src/rescue/rescue/../../bin/test MAKEOBJDIRPREFIX=/usr/obj/usr/src/r escue/rescue/usr/src/rescue/rescue make cleandir rm -f test test.o test.1.gz test.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS cd /usr/src/rescue/rescue/../../bin/rcp MAKEOBJDIRPREFIX=/usr/obj/usr/src/re scue/rescue/usr/src/rescue/rescue make cleandir rm -f rcp rcp.o util.o rcp.1.gz rcp.1.cat.gz Segmentation fault (core dumped) rm -f .depend GPATH GRTAGS GSYMS GTAGS *** Error code 139 Stop in /usr/src/rescue/rescue. # Should I swap memory? It's a 1.8 GHz P4. -- Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.9 stability update
On Thu, Sep 18, 2003 at 11:21:20PM -0600, Scott Long wrote: We'd like to get a new poll on the stability and readiness of 4.9. Last night I upgraded my laptop and it hung partway thru the boot (immediately after the pcm0: line in the dmesg below). Powering it off and back on made it boot normally. It's not done this before and I don't know whether to blame this on a glitch or the new kernel. Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.9-PRERELEASE #0: Thu Sep 18 20:46:38 EST 2003 [EMAIL PROTECTED]:/home/obj/i586/usr/src/sys/pj1592 Timecounter i8254 frequency 1193182 Hz CPU: Pentium/P55C (quarter-micron) (233.86-MHz 586-class CPU) Origin = GenuineIntel Id = 0x581 Stepping = 1 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 100663296 (98304K bytes) avail memory = 94388224 (92176K bytes) Preloaded elf kernel kernel at 0xc036e000. Intel Pentium detected, installing workaround for F00F bug Using $PIR table, 5 entries at 0xc00f5c00 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 isab0: PCI to ISA bridge (vendor=1045 device=c700) at device 1.0 on pci0 isa0: ISA bus on isab0 ohci0: OHCI (generic) USB controller mem 0x4100-0x41000fff irq 11 at device 16.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: (0x0e11) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pcic0: TI PCI-1131 PCI-CardBus Bridge mem 0x7fffe000-0x7fffefff irq 15 at device 17.0 on pci0 pcic0: TI113X PCI Config Reg: [ring enable][speaker enable][CSC serial isa irq] pccard0: PC Card 16-bit bus (classic) on pcic0 pcic1: TI PCI-1131 PCI-CardBus Bridge mem 0x7000-0x7fff irq 11 at device 17.1 on pci0 pcic1: TI113X PCI Config Reg: [ring enable][speaker enable][CSC serial isa irq] pccard1: PC Card 16-bit bus (classic) on pcic1 pci0: Chips Technologies 68554 SVGA controller at 18.0 atapci0: Generic PCI ATA controller port 0x1000-0x100f at device 20.0 on pci0 atapci0: Busmastering DMA not supported ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 orm0: Option ROM at iomem 0xc-0xc9fff on isa0 pmtimer0 on isa0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 12 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A pca0 at port 0x40 on isa0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 unknown: PNP can't assign resources pca1: AT-style speaker sound at port 0x61 on isa0 unknown: PNP0303 can't assign resources unknown: CPQae3d can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0511 can't assign resources unknown: PNP0700 can't assign resources sbc0: ESS ES1878 at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,5 on isa0 pcm0: ESS 18xx DSP on sbc0 ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default DUMMYNET initialized (011031) pccard: card inserted, slot 0 pccard: card inserted, slot 1 pccard: card removed, slot 0 pccard: card removed, slot 1 ad0: 3102MB IBM-DYKA-23240 [6304/16/63] at ata0-master BIOSPIO acd0: CDROM UJDA120 at ata0-slave BIOSPIO Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acd0 vs cd0 (ATAPICAM)
Le 2003-09-19, Guillaume écrivait : Thanks for the patch. cd0 is faster now and ATAPICAM works great. That's good news! Are you going to commit the patch? Yes, the patch is currently being reviewed. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Base packaging
On Fri, 2003-09-19 at 02:02, M. Warner Losh wrote: Why would you want to package sbin? Where do you see this work going? What problems do you think this will solve? Doing things a top level directory at a time isn't very interesting, but since it looks like a demo, perhaps you could sketch out what the polishing you'd envision. Well, as I mentioned in a followup. I'm actually doing this work so that I can use the system mk files for our product development, but I also wanted to be able to registered all the installed files from our products in the pkg db too. Having tried parallel trees, and hacking the ports mk files to get our code directly out of CVS and various other attempts eventually I found out that it's quite easy to link the two together, so that's what I did. So that's the problem it solves :-) I only chose sbin as a demo, you can put the PORTNAME entry in any Makefile and the granularity of the package it creates is going to be based on the content of the pkg-plist and not where in the tree the Makefile is. I'll reply to your other mail with specific points. Paul. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Base packaging
On Fri, 2003-09-19 at 02:10, M. Warner Losh wrote:
P.S. How do you handle the packlist generation? The ports system
doesn't automatically generate these things, as far as I can tell, and
I didn't see anything that you've added to do this.
My agenda, if you will, on this is to deal with:
upgrades: portupgrade can grok packages. If you had a good way to
generate the package list, then we could make it a lot easier to do
binary upgrades. Thie would let me have a big meta-port that
covers all the 'standard' things on the machine, including the os.
Chances are good that some care would need to be taken in
portupgrade to make sure that it doesn't use binaries in place that
will be replaced.
It should be able to do this. Anything you can do with ports I hope
you'll be able to do in the standard tree, i.e. have dependencies and
meta ports etc.
subsetting: with the proper set of subsetting, one could easily
create packages such that they could install just what they
needed. It might be good to have a few like minimal to boot with
rc.d and the like.
This will probably work already. There's no real magic to what I did,
you can convert any makefile to understand ports just by adding PORTNAME
to it, but it doesn't hook into all the ports targets, just fake-pkg. So
basically if you do make install with one of these modified Makefiles
then it will register a package based on the pkg-plist in that
directory. That plist could contain anything you want.
So, you can create a Makefile in the main tree to build a package with
any files you want, you just have to craft the plist e.g. you could have
/usr/src/dists/{minimal,full, sources} etc and in each dir you'd have a
skelton port, with a Makefile, pkg-descr, pkg-plist etc. The pkg-plist
would determine the list of files in each dist. You could of course
break this down to be much more fine grained in the makefiles that
actually build the code to create lots of small packages and then have a
meta package at the dist level to pull them all together.
nopriv: it should be possible to build a release w/o any privs at
all. NetBSD does this with hacks to install and pax to journal
installation stuff in a certain mode and a new mkfs program to take
that info and create a file system image that can be used in the
target environment.
I haven't done any work on this, but it's on my todo list for different
reasons. I'd like to be able to run a dummy install to generate a plist
i.e., if I wanted to package sbin then in /usr/src/sbin I could run make
plist to create the pkg-plist for me based on everything under
/usr/src/sbin, just to save the effort of it being done manually.
To achieve that I'll do something similar to NetBSD and have an option
to install that registers the installation in a file rather than
actually doing it, so you could run this dummyinstall step and then make
package and you'll end up with a load of package files that can be
installed later as root.
Paul.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HFS+ driver kernel options?
David Leimbach wrote: Hey... just looking to see what option I need to enable to get HFS+ support... I am going to try experimenting with building a ppc cross-build environment and try to install FreeBSD on my iPod and boot from it :) (1) iPod's default to MSDOSFS for compatability with PC's. (2) iPod's do not have a PPC, they have two ARM chips. There's a Linux that runs on iPod's that you might want to look at, if you are truly interested in doing a port of FreeBSD, but it would be an ARM port. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on ia64/ia64
TB --- 2003-09-19 09:33:15 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-09-19 09:33:15 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-09-19 09:36:34 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-09-19 10:39:56 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri Sep 19 10:39:56 GMT 2003 Kernel build for GENERIC completed on Fri Sep 19 10:55:42 GMT 2003 TB --- 2003-09-19 10:55:42 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-19 10:55:42 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Sep 19 10:55:42 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/libkern/strtoul.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/libkern/strtouq.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/libkern/strvalid.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13
Re: HFS+ driver kernel options?
On Sep 19, 2003, at 5:45 AM, Terry Lambert wrote: David Leimbach wrote: Hey... just looking to see what option I need to enable to get HFS+ support... I am going to try experimenting with building a ppc cross-build environment and try to install FreeBSD on my iPod and boot from it :) (1) iPod's default to MSDOSFS for compatability with PC's. (2) iPod's do not have a PPC, they have two ARM chips. There's a Linux that runs on iPod's that you might want to look at, if you are truly interested in doing a port of FreeBSD, but it would be an ARM port. You've misunderstood me. I want to build FreeBSD-PPC and install it on an iPod [filesystem wise] then use the iPod to boot my Mac. It doesn't really matter to me what CPU is in the iPod... just that its a handy firewire disk. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HFS+ driver kernel options?
On Sep 19, 2003, at 1:55 AM, Christian Brueffer wrote: On Thu, Sep 18, 2003 at 11:22:37PM -0500, David Leimbach wrote: Hey... just looking to see what option I need to enable to get HFS+ support... All you need should be here: http://people.freebsd.org/~yar/hfs/ Doesn't compile under CURRENT it seems. I can give more details later but right now I have to drive for a few hours so see ya later! - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [current tinderbox] failure on ia64/ia64
Tinderbox [EMAIL PROTECTED] writes: /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/net/bridge.c: In function `bridge_in': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/net/bridge.c:857: warning: cast from pointer to integer of different size *** Error code 1 Please ignore. It seems the RTP cluster's CVS repo is no longer being updated; I've disabled the tinderbox until this is resolved. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Random lockups and reboots on FreeBSD 5.1-RELEASE
Hello I am having some very annoying problems with a FreeBSD 5.1 install. Every 4-6 hours, it either reboots by itself or locks up hard, with the HD led being constantly lit. I've tried looking into the logs, but nothing is written to them before the lockup/reboot, even if I choose boot FreeBSD with verbose logging from the boot-up menu. I have also tried booting up with ACPI disabled and it didn't help either. As of this moment, I cvsupped my sources to today's -CURRENT and am building world. I hope that since -CURRENT has had many changes since 5.1-RELEASE, chances are my problem could've been fixed. However in case it has not, where should I start to look into in order to find the source of my problem? I have no previous experince in debugging and would appreciate to have some pointers Hardware: AMD T-Bird 1400 Mhz GigaByte GA-7DXR motherboard (AMD761 chipset) Creative NVIDIA GeForce4 Ti4200 (I tried both avaible driver sets) Creative SB128 PCI Lite-On DVD/CDRW Combo Drive LTC-48161H Maxtor 40 GB HD Seagate 16 GB HD Thanks in advance. Sincerely, Dan Naumov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-09-19 11:05:40 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-09-19 11:05:40 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-09-19 11:07:39 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-09-19 12:01:15 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri Sep 19 12:01:15 GMT 2003 Kernel build for GENERIC completed on Fri Sep 19 12:10:20 GMT 2003 TB --- 2003-09-19 12:10:20 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-19 12:10:20 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Sep 19 12:10:20 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/libkern/strtoul.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/libkern/strtouq.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/libkern/strvalid.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/net/bpf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
Re: Random lockups and reboots on FreeBSD 5.1-RELEASE
I forgot to add that excessive heat and faulty ram are ruled out, I've checked system temp and it seems to be OK, memtest has also passed all tests completely without giving any errors. It *COULD* theoretically be the HD going bad, but how could I possibly check this? Sincerely, Dan Naumov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath(4) driver problems with WEP...
Hmm. One other thing I'm seeing is that when I configure a 128 bit key with ifconfig or wicontrol (wicontrol shows all 28 characters -- 0x plus 26 hex characters), ifconfig still thinks it is a 104 bit key. This is because ireq.i_len is 13. You must not have the up to date ifconfig. This was the behaviour from before. I believe the mechanism that wicontrol uses to fetch keys does not handle 104-bit keys so you see the zero-padded key string. In a separate issue, the ath(4) driver can't see the 802.11a side of the wireless router at all when it is running in 108Mbps turbo mode. If I drop it down to 54Mbps, it sees it. (Works fine in Windows.) Is the ath(4) driver supposed to support the 108Mbps turbo mode? I was able to associate with an Atheros AP with turbo mode enabled but didn't get any higher throughput. I'm investigating this. FWIW I enabled turbo mode with: ifconfig ath0 mediaopt turbo I had to also set the mode to 11a before it wanted to accept the turbo option. Otherwise I got: ifconfig: SIOCSIFMEDIA (mediaopt): Device not configured Ah, yes. Turbo mode is orthogonal to 11a/b/g. You can use it with 11g too so you need to specifiy 11a or 11g. I was already locked in 11a mode. (But note that 11g+turbo is not yet supported by the driver.) Then I typed: # ifconfig ath0 mode 11a mediaopt turbo atalk 0.0 range 0-0 phase 2 Does it think I'm doing appletalk or something? Hmm, didn't see this, will have to check. It seems to see the base station in turbo mode now, but I'm still getting the authentication failed (reason 13) errors. Are you using WEP? As I explained WEP doesn't work right now. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath(4) driver problems with WEP...
On Fri, Sep 19, 2003 at 08:22:13 -0700, Sam Leffler wrote: Hmm. One other thing I'm seeing is that when I configure a 128 bit key with ifconfig or wicontrol (wicontrol shows all 28 characters -- 0x plus 26 hex characters), ifconfig still thinks it is a 104 bit key. This is because ireq.i_len is 13. You must not have the up to date ifconfig. This was the behaviour from before. I believe the mechanism that wicontrol uses to fetch keys does not handle 104-bit keys so you see the zero-padded key string. I rebuilt ifconfig from the sources you checked in, although I didn't do a full buildworld. Does it depend on a library change somewhere? The key I got from wicontrol wasn't zero-padded. It showed all 26 hex characters. In a separate issue, the ath(4) driver can't see the 802.11a side of the wireless router at all when it is running in 108Mbps turbo mode. If I drop it down to 54Mbps, it sees it. (Works fine in Windows.) Is the ath(4) driver supposed to support the 108Mbps turbo mode? I was able to associate with an Atheros AP with turbo mode enabled but didn't get any higher throughput. I'm investigating this. FWIW I enabled turbo mode with: ifconfig ath0 mediaopt turbo I had to also set the mode to 11a before it wanted to accept the turbo option. Otherwise I got: ifconfig: SIOCSIFMEDIA (mediaopt): Device not configured Ah, yes. Turbo mode is orthogonal to 11a/b/g. You can use it with 11g too so you need to specifiy 11a or 11g. I was already locked in 11a mode. (But note that 11g+turbo is not yet supported by the driver.) Ahh. I take it there's no way for the driver/card to autodetect that there's a turbo network around and attach to it? (The Windows driver seems to find it..) Then I typed: # ifconfig ath0 mode 11a mediaopt turbo atalk 0.0 range 0-0 phase 2 Does it think I'm doing appletalk or something? Hmm, didn't see this, will have to check. It seems to see the base station in turbo mode now, but I'm still getting the authentication failed (reason 13) errors. Are you using WEP? As I explained WEP doesn't work right now. Yeah, I know. I need to see if I can get an IPSec tunnel running to the router. My guess is that it will probably only want to talk IPSec over its internet port. Ken -- Kenneth Merry [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.9 stability update
On Thu, 18 Sep 2003, Scott Long wrote: We'd like to get a new poll on the stability and readiness of 4.9. I hope you posted this to -stable :-) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng still problematic
On Thu, Sep 18, 2003 at 05:51:25PM +0200, Jan Srzednicki wrote:
Anyway, here's backtrace for atapicam panic I've mentioned. It's
triggered by:
cdrecord dev=1,1,0 /some/track
This panic isn't ATAPICAM related. Could you try the patch below? It's
against the cdrtools-devel port but should also work with the cdrtools
port.
Index: files/patch-conf::configure
===
RCS file: files/patch-conf::configure
diff -N files/patch-conf::configure
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/patch-conf::configure 19 Sep 2003 16:03:35 -
@@ -0,0 +1,10 @@
+--- conf/configure.origFri Sep 19 16:47:37 2003
conf/configure Fri Sep 19 16:49:26 2003
+@@ -5567,6 +5567,7 @@
+ int
+ main()
+ {
++ exit(1);
+ if (mlockall(MCL_CURRENT|MCL_FUTURE) 0) {
+ if (errno == EINVAL || errno == ENOMEM ||
+ errno == EPERM || errno == EACCES)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Resolved: ATAng problems
With the latest updates from Soren my server was always finding the master drive but not the slave. This morning I decided to move the slave drive to secondary master and see if that worked. As I was doing that I noticed the slave was jumpered as Cable Select. I've never had good luck with CS and was suprised to see that. I changed it to Slave and Bang! Everything worked perfectly. Master and Slave detected and detected without the long wait that ATAng seemed to have. So... with haing fixed my error the ATAng code seems to be working great for me again! Thanks to all for helping me. -Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng still problematic
On Fri, 2003-09-19 at 19:21, Marius Strobl wrote: On Thu, Sep 18, 2003 at 05:51:25PM +0200, Jan Srzednicki wrote: Anyway, here's backtrace for atapicam panic I've mentioned. It's triggered by: cdrecord dev=1,1,0 /some/track This panic isn't ATAPICAM related. Could you try the patch below? It's against the cdrtools-devel port but should also work with the cdrtools port. Hello. I am sorry for breaking into this conversation, but I thought it's worthy to report that if I have ATAPICAM enabled in my kernel and have my Lite-On DVD/CDRW Combo Drive attached to the system, today's -CURRENT fails to boot (both single- and multiuser). It gets stuck right after: acd0: CDRW LITE-ON COMBO LTC-48161H at ata1-master PIO4 Disabling atapicam in the kernel or detaching the drive from the system works around the problem. Sincerely, Dan Naumov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem with StarOffice 6.0
FreeBSD bart 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Sep 15 23:44:16 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BART i386 I am currently having a very unusual problem with installing StarOffice 6.0 under -CURRENT. Installation in root works fine. When in normal user install all that happens is: %./setup Abort My question is has anyone experienced this at all? Is it infact a -CURRENT problem or is there something else ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
SATA drive lock-up
I have a single SATA drive on an Adaptec 1210SA card. The drive will give a write error warning a few times, then will repeatedly give: ad4: timeout sending command=ca The only recovery is the reset switch, reboot single-user fsck, and then come back up in multiuser. These errors occur with disk access, but not with a predictable nature (not on large files, or small files, etc.) If more information is needed, let me know. -Derek [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
On Fri, 19 Sep 2003, Soren Schmidt wrote: I disagree, but that another matter.. How about just doing: dd if=/dev/acdXtY of=trackY bs=2352 Now that cant be simpler and is already present... In XMMS/XINE/cdda2wav/cdparanoia/...? Lots of programs depend on this interface, and not just ports (== patches), but programs. I'd thought the right way would be to _first_ announce this greakage and give at least maintainers time to write down patches, and _then_ break all those ports. How about POLA? Together with sys/cdio.h, where both ioc_read_audio and CDIOCREADAUDIO are declared I'll get rid of those... Again, a pity. What benefits do we gain here? Speed? CDDA extraction never required all that much of it, and to be honest the difference will hardly be measurable. The only thing it will give is (once again) an interface completely different from other OSs (== some extra pain for developers == fewer applications). Regards, Vladimir ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI and a Toshiba Tecra 8000
On Wed, 17 Sep 2003, Andrew Thompson wrote: Nate Lawson wrote: On Wed, 17 Sep 2003, Andrew Thompson wrote: 111 sc_cur_scr = sc-cur_scp-index; For a temporary workaround, try changing line 111 to: if (sc-cur_scp == NULL) return (0); This may not help things though. It has helped and the laptop is able to suspend with the serial cable attached (further than before). It now panics on the first resume with the following (gdb output at bottom). I think the serial cable is masking the problem as without it I can suspend/resume once and it only panics on the second resume. I guess I need the serail working to see that panic anyway. You should do a quick grep through sys/dev/syscons for = sc-cur_scp-index and replace them all with the above NULL check. I'm interested if this will fix things. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng still problematic
On Fri, 19 Sep 2003, Dan Naumov wrote: On Fri, 2003-09-19 at 19:21, Marius Strobl wrote: On Thu, Sep 18, 2003 at 05:51:25PM +0200, Jan Srzednicki wrote: Anyway, here's backtrace for atapicam panic I've mentioned. It's triggered by: cdrecord dev=1,1,0 /some/track This panic isn't ATAPICAM related. Could you try the patch below? It's against the cdrtools-devel port but should also work with the cdrtools port. Hello. I am sorry for breaking into this conversation, but I thought it's worthy to report that if I have ATAPICAM enabled in my kernel and have my Lite-On DVD/CDRW Combo Drive attached to the system, today's -CURRENT fails to boot (both single- and multiuser). It gets stuck right after: acd0: CDRW LITE-ON COMBO LTC-48161H at ata1-master PIO4 Disabling atapicam in the kernel or detaching the drive from the system works around the problem. I'm seeing this too. it happened right after the commit of ata-queue.c rev 1.5. Revert back to version 1.4 and see if boots again. -- = = Bryan D. LiesnerLeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED] Home of the Gipper= = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATAng no good for me
ATA (atapicam also in kernel) doesn't seem to work after the changes in the last 24 hours or so. I have a SCSI system with one ATAPI CD-ROM drive, which gets probed on a good kernel as: ata0-slave: timeout waiting for interrupt ata0-slave: ATAPI identify failed acd0: CDROM CD-532E-B at ata0-master PIO4 Waiting 5 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0 lun 0 da0: S7Z0 Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) cd0 at ata0 bus 0 target 0 lun 0 cd0: TEAC CD-532E-B 1.0B Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present On a kernel built just a few hours ago, it hangs on boot right after: acd0: CDROM CD-532E-B at ata0-master PIO4 -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng still problematic
On Fri, 19 Sep 2003, Marius Strobl wrote: On Thu, Sep 18, 2003 at 05:51:25PM +0200, Jan Srzednicki wrote: Anyway, here's backtrace for atapicam panic I've mentioned. It's triggered by: cdrecord dev=1,1,0 /some/track This panic isn't ATAPICAM related. Could you try the patch below? It's against the cdrtools-devel port but should also work with the cdrtools port. I applied your patch, and cdrecord works! Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me
On Fri, Sep 19, 2003 at 07:09:03PM -0400, Daniel Eischen wrote: ATA (atapicam also in kernel) doesn't seem to work after the changes in the last 24 hours or so. I have a SCSI system with one ATAPI CD-ROM drive, which gets probed on a good kernel as: sos will probably ask for boot -v output. Kris pgp0.pgp Description: PGP signature
Re: ATAng still problematic
On Fri, Sep 19, 2003 at 06:21:52PM +0200, Marius Strobl wrote: On Thu, Sep 18, 2003 at 05:51:25PM +0200, Jan Srzednicki wrote: Anyway, here's backtrace for atapicam panic I've mentioned. It's triggered by: cdrecord dev=1,1,0 /some/track This panic isn't ATAPICAM related. Could you try the patch below? It's against the cdrtools-devel port but should also work with the cdrtools port. Isn't it still a kernel bug if a user process can trigger a panic? Kris pgp0.pgp Description: PGP signature
Re: ATAng still problematic
Who-hoo, it works!!! Thanks a bunch!!!
On Fri, 19 Sep 2003, Marius Strobl wrote:
On Thu, Sep 18, 2003 at 05:51:25PM +0200, Jan Srzednicki wrote:
Anyway, here's backtrace for atapicam panic I've mentioned. It's
triggered by:
cdrecord dev=1,1,0 /some/track
This panic isn't ATAPICAM related. Could you try the patch below? It's
against the cdrtools-devel port but should also work with the cdrtools
port.
Index: files/patch-conf::configure
===
RCS file: files/patch-conf::configure
diff -N files/patch-conf::configure
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/patch-conf::configure 19 Sep 2003 16:03:35 -
@@ -0,0 +1,10 @@
+--- conf/configure.orig Fri Sep 19 16:47:37 2003
conf/configure Fri Sep 19 16:49:26 2003
+@@ -5567,6 +5567,7 @@
+ int
+ main()
+ {
++exit(1);
+ if (mlockall(MCL_CURRENT|MCL_FUTURE) 0) {
+ if (errno == EINVAL || errno == ENOMEM ||
+ errno == EPERM || errno == EACCES)
And thanks again,
Vladimir
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re:
Nevermind, I switched from slave to master of CD-RW; it boots just fine and function fine too. No more weird busy signal at all the time. Time to use my own kernel config.. Cheers, Mezz On Wed, 17 Sep 2003 11:59:46 -0500, Jeremy Messenger [EMAIL PROTECTED] wrote: Last night, I CVSup'ed and did the buildworld/kernel stuff. Then, I reboot and I get the busy signal like forever, it looks like the HD is spinning forever for no reason. Also, the ATAng can't find my Teac CD-RW.. Here are three attaches.. dmesg-ataog.txt is old kernel sometime before ATAng went in the 5.1-CURRENT tree. FreeBSD mezz.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sat Aug 23 01:09:03 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSDRULZ i386 dmesg-atang.txt and pciconf.txt are from last night 5.1-CURRENT. Please, let me know if there is something else I can do.. Soon, I am going to boot into the yesterday -CURRENT, I think I saw more error with SCSI stuff and I will try to collect them. If I get them and I will reply in here with the more info. Cheers, Mezz -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng still problematic
On Fri, Sep 19, 2003 at 04:36:32PM -0700, Kris Kennaway wrote: On Fri, Sep 19, 2003 at 06:21:52PM +0200, Marius Strobl wrote: On Thu, Sep 18, 2003 at 05:51:25PM +0200, Jan Srzednicki wrote: Anyway, here's backtrace for atapicam panic I've mentioned. It's triggered by: cdrecord dev=1,1,0 /some/track This panic isn't ATAPICAM related. Could you try the patch below? It's against the cdrtools-devel port but should also work with the cdrtools port. Isn't it still a kernel bug if a user process can trigger a panic? Yes, it seems to be a bug in the mlockall(2) implementation. Backing it out or hindering cdrecord to use it avoids the panic. I already wrote an email to bms@ who commited the mlockall(2) and munlockall(2) support regarding this issue. The patch for the cdrtools ports is only a workaround until the real cause is fixed. I also was not sure if it would work for Bryan as I originally didn't get the same panic as he did. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng still problematic
On Sat, Sep 20, 2003 at 02:17:21AM +0200, Marius Strobl wrote: Isn't it still a kernel bug if a user process can trigger a panic? Yes, it seems to be a bug in the mlockall(2) implementation. Backing it out or hindering cdrecord to use it avoids the panic. I already wrote an email to bms@ who commited the mlockall(2) and munlockall(2) support regarding this issue. I don't think that's been conclusively established yet, so statements of the form above are a bit unhelpful. The problem may well lie elsewhere in the system, as a parameter in vm_map_copy_entry() is being unexpectedly set to NULL in the backtrace which you provided me with. If more people can exercise the same codepath as you appear to be exercising with different configurations, then I will have more to go on. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: ATA: UDMA66, 33 ICRC
This became quite tricky, but the main (and the worst problem) was with ATAng. I have Acer's motherboard and IBM's DTLA. Old driver were saying 'Non-ATA 66 cable or device' and perfectly worked in UDMA-33 mode. New driver didn't said a word, but when it tried to read something, everything was ending up with 'ICRC error'. I was already going to hack ata-chipsets to force UDMA-33, but I came upon hw.ata.ata_dma. I need more info to be able to tell what going on... A dmesg from a verbose booted system is mandatory here.. The problem is, I can't boot system with DMA, it wouldn't read anything with that error. System doesn't even mount root. There are boot log with ata_dma=0. By the way, I had a chance today to put my HDD into another machine and boot it.DMA works perfectly, so as PIO does, but PIO is EXTREMELY slow. I had old Samsung once, I guess it worked in PIO, but it was not that slow. Something's strange out there. boot log: Calibrating clock(s) ... i8254 clock: 1193240 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Calibrating TSC clock ... TSC clock: 400912010 Hz Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Write Allocate Enable Limit: 192M bytes Write Allocate 15-16M bytes: Enable Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x00564000 - 0x0bc69fff, 191913984 bytes (46854 pages) bios32: Found BIOS32 Service Directory header at 0xc00fadd0 bios32: Entry = 0xfb250 (c00fb250) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb280 pnpbios: Found PnP BIOS data at 0xc00fbf10 pnpbios: Entry = f:bf38 Rev = 1.0 Other BIOS signatures found: random: entropy source null: null device, zero device mem: memory I/O pci_open(1): mode 1 addr port (0x0cf8) is 0x8058 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=154110b9) PCI-Only Interrupts: 10 11 Location Bus Device Pin Link IRQs slot 1 0 10A 0x01 3 4 5 7 9 10 11 12 14 15 slot 1 0 10B 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 10C 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 10D 0x04 3 4 5 7 9 10 11 12 14 15 slot 2 0 11A 0x02 3 4 5 7 9 10 11 12 14 15 slot 2 0 11B 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 11C 0x04 3 4 5 7 9 10 11 12 14 15 slot 2 0 11D 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 12A 0x03 3 4 5 7 9 10 11 12 14 15 slot 3 0 12B 0x04 3 4 5 7 9 10 11 12 14 15 slot 3 0 12C 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 12D 0x02 3 4 5 7 9 10 11 12 14 15 embedded0 15A 0x05 3 4 5 7 9 10 11 12 14 15 embedded0 15B 0x06 3 4 5 7 9 10 11 12 14 15 embedded01A 0x01 3 4 5 7 9 10 11 12 14 15 embedded01B 0x02 3 4 5 7 9 10 11 12 14 15 embedded01C 0x03 3 4 5 7 9 10 11 12 14 15 embedded01D 0x04 3 4 5 7 9 10 11 12 14 15 embedded02A 0x59 3 4 5 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 ACPI timer looks BAD min = 0, max = 16777211, width = 16777211 ACPI timer looks BAD min = 1, max = 4, width = 3 ACPI timer looks BAD min = 1, max = 16777211, width = 16777210 ACPI timer looks BAD min = 0, max = 5, width = 5 ACPI timer looks BAD min = 1, max = 16777215, width = 16777214 ACPI timer looks BAD min = 1, max = 16777215, width = 16777214 ACPI timer looks BAD min = 1, max = 4, width = 3 ACPI timer looks BAD min = 1, max = 4, width = 3 ACPI timer looks BAD min = 1, max = 16777211, width = 16777210 ACPI timer looks BAD min = 1, max = 16777215, width = 16777214 mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) initial configuration \\_SB_.PCI0.ISA0.LNKA irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.10.0 \\_SB_.PCI0.ISA0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.10.1 \\_SB_.PCI0.ISA0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.10.2 \\_SB_.PCI0.ISA0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.10.3 \\_SB_.PCI0.ISA0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.11.0 \\_SB_.PCI0.ISA0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.11.1 \\_SB_.PCI0.ISA0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.11.2 \\_SB_.PCI0.ISA0.LNKA irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.11.3
Re: ATAng still problematic
On Sat, Sep 20, 2003 at 01:47:44AM +0100, Bruce M Simpson wrote: On Sat, Sep 20, 2003 at 02:17:21AM +0200, Marius Strobl wrote: Isn't it still a kernel bug if a user process can trigger a panic? Yes, it seems to be a bug in the mlockall(2) implementation. Backing it out or hindering cdrecord to use it avoids the panic. I already wrote an email to bms@ who commited the mlockall(2) and munlockall(2) support regarding this issue. I don't think that's been conclusively established yet, so statements of the form above are a bit unhelpful. Ok, sorry. The problem may well lie elsewhere in the system, as a parameter in vm_map_copy_entry() is being unexpectedly set to NULL in the backtrace which you provided me with. It's just certainly not ATAng or ATAPICAM as I get this panic on a SCSI-only box, too. If more people can exercise the same codepath as you appear to be exercising with different configurations, then I will have more to go on. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me
On Fri, 19 Sep 2003, Kris Kennaway wrote: On Fri, Sep 19, 2003 at 07:09:03PM -0400, Daniel Eischen wrote: ATA (atapicam also in kernel) doesn't seem to work after the changes in the last 24 hours or so. I have a SCSI system with one ATAPI CD-ROM drive, which gets probed on a good kernel as: sos will probably ask for boot -v output. http://people.freebsd.org/~deischen/ata_hang.091903 -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 09/18 -CURRENT does not boot off SATA
On Thu, Sep 18, 2003 at 08:48:57PM -0700, Will Andrews wrote:
My -CURRENT workstation won't boot off the WD Raptor 36GB disk,
which is on a SiI 3112A SATA-150 controller. This was working
with a kernel in early July. {build,install}{world,kernel}
completed. Fortunately, it seems I can still boot with the
older kernel. I guess ATAng problems still haven't been fleshed
out or I'm missing something?
Anyway, the disk is probed but is not correctly identified. It
says something like:
ad4: 32MB * * * * * * * * * * * * * * * * * * * * [65537/1/1] at ata2-master WDMA0
where * appears to be a smiley face. Strange.
Anyone seen anything like this? Thanks in advance.
So, having received no response to this, I decided to bootstrap
the machine using a PATA disk. Funny that, the machine won't
boot off the PATA disk directly. Hilarity ensues. For details,
see: http://csociety.org/~will/dmesg.badATAng
which is the output of dmesg -a where I booted -v.
Regards,
--
wca
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
