Re: broken ppp
On Wed, 29 Dec 1999, Werner Griessl wrote: <> <>current's new ppp discards the "#0001"-part from my <>german telekom account and makes it impossible to <>connect to my provider. <> While we are on the subject, ppp no longer runs an external chat script. This used to work: set login "\"!chat -f /etc/ppp/login -r /var/log/connect.log\"" -Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA CD-R problems, still...
On Sat, 8 Jan 2000, Brian Fundakowski Feldman wrote: >Well, I don't know about anyone else out there having the problems I'm >having, but I might as well ask. I'm using the ATA driver with the >following bugfix applied, otherwise the same. > At the risk of sounding like an AOLer, me too. Prior to the most recent changes incorporating burncd, I was able to write to my HP 8250i using wormcontrol. Never burned a coaster, it was very reliable. Now when I use burncd, I get WRITE_BIG errors, and then the driver tries endlessly to reset. The only way out is to hit the big red reset button. -Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATAPI broken, but why?
On Mon, 10 Jan 2000, Brian Fundakowski Feldman wrote: >I'm sure everyone's seen my e-mail and others' e-mail about ATAPI in the >ATA driver, at least, being broken (WRT CD-Rs). The question is, does >anyone have any idea at all why? I tried reverting to just before the >CDRIOC* changes, and that didn't help (using wormcontrol to test that). >If any of you have any hints at all, please let me know. I just wanted to add for all to see that prior to the CDRIOC* changes, all was OK with my HP 8250i CD-RW unit, reading and writing both worked fine. After the changes, writing no longer works. All I get is WRITE_BIG errors from burncd (the write light never turns on) then the driver endlessly tries to reset the CD-R drive and I have to hit the reset button to reboot. My HP Colorado 8G ATAPI tape never probed/worked at all with the new ATA driver. Anyone out there have one that's working? The wd* drivers, although obselete now, handled all of my ATA-ATAPI stuff without any problems. I find it hard to believe that 4.0 will get released with less hardware support than 3.x. -Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA CD-R problems, still...
On Sun, 16 Jan 2000, Brian Fundakowski Feldman wrote: >Can you try this patch to src/usr.sbin/burncd, and see if things work >after that? Thanks! (BTW, there's also an extra feature in there, hope >you don't mind :) > Yes, I burned a full 650MB onto a CD-R disk. No problems at all. And I see just changing the definition of BLOCKS from 32 to 16 did the trick. I thought there was going to be a lot of digging into the ATAPI driver to get this fixed. Thanks! Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA CD-R problems, still...
On Mon, 17 Jan 2000, Soren Schmidt wrote: >There really wasn't any functional changes to the driver, but there was >to the util :) >It is sad though that there still are so many crappy drives be made :( > >However I've committed the fix... > > >-Søren > Now if we can only get my crappy tape drive to probe... :) Are future commits going to address that? Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 8 Feb current install failures
On Thu, 10 Feb 2000, Reinier Bezuidenhout wrote: >Hi ... > >I checked out a -current of about midnight 8 Feb ... > >After doing a "make buildworld" (which finished ok) ... did >a "make installworld" which failed because my /usr/bin/install >was not updated and thus dit not support the -fschg option. > >I copied the newly build install to /usr/bin and the "make installworld" >completed without errors so I thought .. ok ... now it works. > >I compiled a new kernel and rebooted. > >But now everything which uses libstdc++.so.3 failes because of ... > > >/usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol "_vt$9exception" You have to recompile all programs that use libstdc++.so.3, and you'll be fine. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Big ATA problems
On Sat, 19 Feb 2000, Philipp Mergenthaler wrote: >On Sat, Feb 19, 2000 at 10:39:42AM -0500, Bryan Liesner wrote: >> Jose, the problem seems to be resolved by rebuilding the boot >> loader. Or bypass the loader altogether. >> >> cd /usr/src/sys/boot >> make obj >> make all install >> >> and you'll be able to boot the kernel with the latest ata stuff. > >Do you use KLMs? Yes, I do! I was loading a screen saver with the boot loader. And now I see I am wrong about rebuilding the loader! When I had success loading the kernel directly, I moved loading the screensaver into rc.conf instead. Then I thought that something may be wrong with the loader, rebuilt it, and booted successfully. I broke the rule - never change more than one thing at a time :) I put the screen saver back in loader.conf and the boot failed again, so it is a loader/kernel issue, but I didn't have to rebuild loader. -Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Big ATA problems
On Sat, 19 Feb 2000, Soren Schmidt wrote: >Have you rebuild your modules lately ?? > >-Søren > Yes. My world is current as of a few hours ago. I did a make world right after finding out about the loader problem to rule that possibility out. The disk probes still fail when loading today's modules with the loader. -Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Big ATA problems
The latest ata commits left my system completely unbootable. No disks were probed. I have on the motherboard's Alladin controller: HP 4x4x24 CD burner as master primary channel 40x CD as slave primary channel HP Colorado 8 Gig ATAPI tape as master secondary channel On a Promise Ultra66: WDC AC29100D WDC AC32500H each on thier own channel. Here are the boot messages (I had to write them down) ata0-slave: WARNING: WAIT_INTR active=ATA_WAIT_READY ata0-slave: timeout waiting for intr ata0-slave: identify failed these were repeated once and when attempting to mount / no devsw(msgdev=0 bootdev=0xa20) no such device 'ad' Prior the the commit, the motherboard ide controllers were numbered ata0,1 and the Promise was ata2,3. After the commit it is switched around. Now the controllers probe as Promise ata0,1 and the motherboard as ata2,3. Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Big ATA problems
On Sat, 19 Feb 2000, Soren Schmidt wrote: >It seems Bryan Liesner wrote: >> >> The latest ata commits left my system completely unbootable. No disks >> were probed. > >He, you always seem to be lucky when I change something :) I always hold my breath when I cvsup and see changes to ata*:) >Hmm, yes you have one of those motherboards that screw the order >of the controllers, it is an ASUS aliddin right ?? It's a PCChips motherboard... > >You could try to not use the ATA_STATIC_ID option, that way your >disks should be numbered 0 and 1 and at least make it boot... Never used that option before. -Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Big ATA problems
On Sat, 19 Feb 2000, Jose Gabriel Marcelino wrote: > >hi Soren, > >The latest ata commits left me unbootable too, the patch you provided >below didn't help this too. I have a very different configuration from >Bryan's (much simpler too): > Jose, the problem seems to be resolved by rebuilding the boot loader. Or bypass the loader altogether. cd /usr/src/sys/boot make obj make all install and you'll be able to boot the kernel with the latest ata stuff. Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors
On Sat, 19 Feb 2000, Kenneth Wayne Culver wrote: >I cvsupped this morning and I just had a chance to build a new kernel, and >now I get a "cannot mount root" and it drops into some kind of commandline >where I can enter a root for it to mount. This is the error it gives me >now: > >ata0-slave: WARNING: WAIT_INTR active=ATA_WAIT_READY >ata0-slave: ata_command: timeout waiting for intr >ata0-slave: identify failed I went through this this morning. If you are loading modules from the boot loader, load them later, like from rc.conf. I'm not sure what broke there, but it's a good workaround. -Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crashing netscape?
On Mon, 21 Feb 2000, Alex Le Heux wrote: >Hi, > >Am I the only one who's experiencing an amzing amount of crashes on >Netscape? > >It's been going on for quite some time now (months), upgrading Netscape or >switching from the Linux to the FreeBSD to the BSDI version doesn't help. >The most stable version seems to be the Linux version, but that even >crashes 5-10 times per day. It will *always* crash when a page uses java, >but I've not been able to find a non-java page that will always crash it. Netscape would always crash on me when loading a java applet - I found that if you define both the scaled and unscaled fonts in XF86Config as below that all the java related crashes go away. It still crashes occasionally on complex pages that load up a million different frames, though. Section "Files" RgbPath"/usr/X11R6/lib/X11/rgb" FontPath "/usr/X11R6/lib/X11/fonts/75dpi" FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/misc" FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled" ModulePath "/usr/X11R6/lib/modules" EndSection Hope this helps. -Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Network problems
I recently set up a network at home to share an internet connection with a win98 box. Currently it's ppp/nat with a modem, in a few days ADSL. It works just fine for a while, but I'm experiencing unexplained outages where I have to do an ifconfig dc1 down/up to wake it up again. No error messages on the console. I also installed Samba on the box which works great (as long as the network is up). I'm using a 3COM Home Connect hub. Here's the output from ifconfig: dc1: flags=8847 mtu 1500 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 ether 00:80:c6:f9:70:ec media: autoselect (100baseTX) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX none dmesg: dc0: port 0xe800-0xe8ff mem 0xebfbfe00-0xebfbfeff irq 9 at device 4.0 on pci0 dc0: Ethernet address: 00:80:c6:f9:5b:0d miibus0: on dc0 dcphy0: on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: port 0xec00-0xecff mem 0xebfbff00-0xebfb irq 10 at device 5.0 on pci0 dc1: Ethernet address: 00:80:c6:f9:70:ec miibus1: on dc1 dcphy1: on miibus1 dcphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto I understand that this driver is new to 4.0, so I'm taking a shot here. Any ideas? Thanks, Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0: TX underrun -- resetting
On Sun, 12 Mar 2000, Michael L. Imamura wrote: > >I've had this occur also; usually I get the message twice at startup, then >at seemingly random times while online. So far, my connection has only >been dropped once -- I got a flurry of "dc0: TX underrun -- >resetting" messages, then my connection died. I was able to bring it back >up with "ifconfig dc0 up", but it was a little unsettling. I'm using >4.0-RC2 with the following chipset: I get the same messages on my dc1 on my "lan" - just a win98 box connected to the freebsd box. dc0 is connected to the internet with a DSL modem and I've yet to see this on dc0. I swapped interfaces also, but it only seems to happen on the local network. My local network also goes down, it could be five minutes or two hours and I have to do an ifconfig dc1 down/up to make it right again. As a workaround, I found that running tcpdump on the dc1 interface keeps things alive, so far indefinitely. -Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Unexplained network outages
I have a win98 box connected to a 4.0-current box via an ethernet connection. The connection will go dead after about 20 minutes. I'm unable to ping the win98 box and cannot ping the FreeBSD box from the win98 box. No error/console messages. I can bring it back to life by doing an ifconfig dc1 down/up, then pinging the win98 box. Has anyone experienced this behavior? The strange thing is that the network never goes down if I run tcpdump in promiscuous mode on the interface - it's a workaround, but I don't like it. Any ideas would be greatly appreciated. Here's the output from ifconfig and dmesg: dc1: flags=8943 mtu 1500 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 ether 00:80:c6:f9:70:ec media: autoselect (100baseTX) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX none dc1: port 0xec00-0xecff mem 0xebfbff00-0xebfb irq 10 at device 5.0 on pci0 dc1: Ethernet address: 00:80:c6:f9:70:ec miibus1: on dc1 dcphy1: on miibus1 dcphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED] Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Promise Ultra66 IDE adapter
Is the Promise Ultra66 IDE adapter supported? I cannot get 3.3 or 4.0 kernels to see the card at all. The mailing list archive details are sketchy at best. The pci_ide source seems to only do support for the Ultra33. Thanks, Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ata driver and mounting CDROMs, missing tape drives
I've been having trouble mounting my ATAPI CDROM using the new ATA drivers When I do a: %mount /cdrom, the system complains: cd9660: Block device required This is my fstab entry: /dev/acd0a /cdrom cd9660 ro,noauto 0 0 And here is the relevant part of my kernel config: controller ata0 device atadisk0 device atapicd0 device atapist0 And here are my /dev entries: brw-r- 1 root operator 19, 0 Oct 22 01:34 /dev/acd0a brw-r- 1 root operator 19, 2 Oct 22 01:34 /dev/acd0c brw-r- 1 root operator 19, 8 Oct 22 01:34 /dev/acd1a brw-r- 1 root operator 19, 10 Oct 22 01:34 /dev/acd1c They look like block devices to me! I have the CDROM configured as master, and a HP Travan 8G tape drive as slave. The dmesg shows only the CDROM, and the kernel doesn't see the tape drive at all, although the dmesg says there are two devices on the channel. Here is the last dmesg: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Fri Oct 22 00:01:27 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/GRAVY Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 249414302 Hz CPU: Cyrix 6x86MX (249.41-MHz 686-class CPU) Origin = "CyrixInstead" Id = 0x601 Stepping = 1 DIR=0x1353 Features=0x80a135 real memory = 134217728 (131072K bytes) avail memory = 127672320 (124680K bytes) Preloaded elf kernel "kernel" at 0xc0274000. Preloaded elf module "linux.ko" at 0xc027409c. Preloaded elf module "warp_saver.ko" at 0xc027413c. npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 isab0: at device 2.0 on pci0 isa0: on isab0 ata-pci0: irq 11 at device 5.0 on pci0 ata-pci0: Busmastering DMA supported ata2 at 0xeff0 irq 11 on ata-pci0 vga-pci0: irq 0 at device 6.0 on pci0 ata-pci1: irq 0 at device 11.0 on pci0 ata-pci1: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci1 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 pcm0: at irq 5 drq 1 flags 0x15 on isa0 vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: on ppbus 0 lpt0: Interrupt-driven port fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio2: at port 0x3e8-0x3ef irq 10 on isa0 sio2: type 16550A ad0: ATA-4 disk at ata2 as master ad0: 8693MB (17803440 sectors), 17662 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 31 depth queue, UDMA33 Creating DISK ad0 Creating DISK wd0 ad1: ATA-? disk at ata2 as slave ad1: 2441MB (4999680 sectors), 4960 cyls, 16 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 0 depth queue, DMA Creating DISK ad1 Creating DISK wd1 ata0: Aladdin: two atapi devices on this channel, DMA disabled atapi: MODE_SENSE_BIG - UNIT ATTENTION skey=6 asc=29 ascq=00 error=00 acd0: CDROM drive at ata0 as master acd0: read 2062KB/s (6875KB/s), 128KB buffer, PIO acd0: supported read types: CD-R, CD-RW, CD-DA, packet acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked changing root device to wd0s1a WARNING: driver snd should register devices with make_dev() (dev_t = "#snd/4") To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Missing HP Colorado 8G ATAPI drive
I've had an ATAPI CDROM as master and an HP Colorado tape as slave set up on my system for quite some time now. I recently migrated to 4.0 and I'm using the new ATA drivers. Below is a snip from my kernel config: controller ata0 device atadisk0 device atapicd0 device atapist0 At boot time, the messages show that there are two devices on the channel, but only the CDROM is configured. Any ideas? ata0: Aladdin: two atapi devices on this channel, DMA disabled atapi: MODE_SENSE_BIG - UNIT ATTENTION skey=6 asc=29 ascq=00 error=00 acd0: CDROM drive at ata0 as master acd0: read 687KB/s (6875KB/s), 128KB buffer, PIO acd0: supported read types: CD-R, CD-RW, CD-DA, packet acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED] Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ATAPI tape drive not probed
I've had an ATAPI CDROM as master and an HP Colorado tape as slave set up on my system for quite some time now. I recently migrated to 4.0 and I'm using the new ATA drivers. Below is a snip from my kernel config: controller ata0 device atadisk0 device atapicd0 device atapist0 At boot time, the messages show that there are two devices on the channel, but only the CDROM is configured. Any ideas? ata0: Aladdin: two atapi devices on this channel, DMA disabled atapi: MODE_SENSE_BIG - UNIT ATTENTION skey=6 asc=29 ascq=00 error=00 acd0: CDROM drive at ata0 as master acd0: read 687KB/s (6875KB/s), 128KB buffer, PIO acd0: supported read types: CD-R, CD-RW, CD-DA, packet acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED] Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: observations with the ata-driver (hd and zip drive)
On Fri, 26 Nov 1999, Soren Schmidt wrote: <>It seems F. Heinrichmeyer wrote: <>> more observations to the zip-drive problem: <>> First the relevant dmesg-line: I'm also still having a small problem with the ata driver and my HP Colorado 8G. I have it hanging off an ATAPI CDROM as a slave. The dmesg says: ata-pci1: irq 0 at device 11.0 on pci0 ata-pci1: Busmastering DMA supported ata0: iobase=0x01f0 altiobase=0x03f6 ata0: mask=03 status0=00 status1=00 ata0: mask=03 status0=00 status1=00 ata0: devices = 0xc ata0 at 0x01f0 irq 14 on ata-pci1 This indicates that it sees two ATAPI devices. But when the system starts up, all I get is: ata0-master: piomode=4 dmamode=2 udmamode=2 dmaflag=1 atapi: MODE_SENSE_BIG - UNIT ATTENTION skey=6 asc=29 ascq=00 error=00 acd0: CDROM drive at ata0 as master acd0: read 687KB/s (6875KB/s), 128KB buffer, PIO acd0: supported read types: CD-R, CD-RW, CD-DA, packet acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked No tape drive is found. All worked well with the old drivers. == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED] Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Broken sound on an Avance Asound 110
In a kernel built from sources current as of 21:00 EST, I no longer have sound. dmesg from yesterday: pcm0: at port 0x220-0x22f irq 5 drq 1,0 on isa0 unknown0: at port 0x388-0x38f on isa0 joy0: at port 0x200-0x207 on isa0 unknown1: at port 0x330-0x331 irq 9 on isa0 The above worked without using sbc0 in my kernel conf, only pcm0 dmesg now: unknown0: at port 0x220-0x22f irq 5 drq 1,0 on isa0 sbc0: at port 0x388-0x38f on isa0 device_probe_and_attach: sbc0 attach returned 6 joy0: at port 0x200-0x207 on isa0 unknown1: at port 0x330-0x331 irq 9 on isa0 The above is using both sbc0 and pcm0 I know this probably isn't enough info, what can I do to help? -Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Avance Asound 110 patch for sbc.c
A few days back my Avance Asound stopped working. The probe would
fail (sorry, this is from memory):
sbc0: probe_and_attach returned 6
I found a slight error in sbc.c and here's a working patch:
--- /sys/dev/sound/isa/sbc.cSat Dec 11 21:30:19 1999
+++ sbc.c Thu Dec 16 23:42:43 1999
@@ -184,7 +184,7 @@
{0x45008c0e, "Creative SB AWE64"}, /* CTL0045 */
{0x0100, "Avance Asound 100"},
- {0x0111, "Avance Asound 110"},
+ {0x0110, "Avance Asound 110"},
{0x0121, "Avance Logic ALS120"},
{0x68187316, "ESS ES1868"}, /* ESS1868 */
I was happy to hear that nice "pop" when I rebooted.
-Bryan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: pcm/sbc and Avance Logic ALS-120
On Fri, 24 Dec 1999 [EMAIL PROTECTED] wrote:
<>unknown0: at port 0x220-0x22f irq 5 drq 1,0 on isa0
<>sbc0: at port 0x388-0x38f on isa0
<>sbc0: alloc_resource
<>device_probe_and_attach: sbc0 attach returned 6
<>unknown1: at port 0x208-0x20f on isa0
<>unknown2: at port 0x330-0x331 irq 9 on isa0
Try this patch. I had the exact problem with my ALS 110, and I
submitted a patch fixing an error in the device number. I suspect
that all of the ALS devices end with 0, not 1. I didn't want to
submit it with the ALS 120 fix because I couldn't test it.
--- /usr/src/sys/dev/sound/isa/sbc.cTue Dec 21 20:38:03 1999
+++ sbc.c Fri Dec 24 12:24:59 1999
@@ -200,13 +200,13 @@
{0x42008c0e, "Creative SB AWE64"}, /* CTL0042 */
{0x43008c0e, "Creative ViBRA16X"}, /* CTL0043 */
{0x44008c0e, "Creative SB AWE64 Gold"}, /* CTL0044 */
{0x45008c0e, "Creative SB AWE64"}, /* CTL0045 */
{0x0110, "Avance Asound 110"}, /* @@@1001 */
- {0x0121, "Avance Logic ALS120"},/* @@@2001 */
+ {0x0120, "Avance Logic ALS120"},/* @@@2001 */
{0x68187316, "ESS ES1868"}, /* ESS1868 */
{0x69187316, "ESS ES1869"}, /* ESS1869 */
{0xacb0110e, "ESS ES1869 (Compaq OEM)"},/* CPQb0ac */
{0x79187316, "ESS ES1879"}, /* ESS1879 */
{0x88187316, "ESS ES1888"}, /* ESS1888 */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
acpi problem ???
I just upgraded my 4.7 system to 5.0-current via sources. Everything went smoothly, and I was up and running quickly, but with an acpi related problem. When booting, the kernel loads, detects the devices, then hangs right here: Mounting root from ufs:/dev/ad0s1a pid 84 (fsck_ufs), uid 0: exited on signal 8 No panic, just a hang. Disabling acpi takes the hang away. The system is up to date as of the 22nd, running on an ASUS A7V266. The rest of the details are attached in an acpi-less dmesg. Also included is the output from fdisk. -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=116336 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=116336 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 117266625 (57259 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 130/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: 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 5.0-CURRENT #0: Thu Jan 23 18:58:33 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GRAVY Preloaded elf kernel "/boot/kernel/kernel" at 0xc0495000. Preloaded elf module "/boot/kernel/radeon.ko" at 0xc04950b4. Calibrating clock(s) ... TSC clock: 1544533484 Hz, i8254 clock: 1193206 Hz Timecounter "i8254" frequency 1193206 Hz TSC initialization skipped: APM enabled. CPU: AMD Athlon(TM) XP1800+ (1544.53-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383f9ff AMD Features=0xc048 Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 536788992 (511 MB) Physical memory chunk(s): 0x1000 - 0x0009dfff, 643072 bytes (157 pages) 0x004bc000 - 0x1ffe3fff, 531791872 bytes (129832 pages) avail memory = 516505600 (492 MB) bios32: Found BIOS32 Service Directory header at 0xc00f1470 bios32: Entry = 0xf0bf0 (c00f0bf0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdf0 pnpbios: Found PnP BIOS data at 0xc00fbd80 pnpbios: Entry = f:bdb0 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: Initializing GEOMetry subsystem netsmb_dev: loaded null: mem: Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00 00 01 00 04 00 01 0e 01 00 01 24 01 00 01 29 01 00 01 6a 00 02 01 04 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 94 01 95 01 96 01 a2 01 a3 01 VESA: 56 mode(s) found VESA: v2.0, 65536k memory, flags:0x1, mode table:0xc03fb2c2 (122) VESA: ATI RADEON VE VESA: ATI Technologies Inc. R100 01.00 random: npx0: on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x80010014 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=30991106) Using $PIR table, 10 entries at 0xc00f13a0 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded05A 0x02 3 4 5 7 9 10 11 12 embedded05B 0x03 3 4 5 7 9 10 11 12 embedded06A 0x05 3 4 5 7 9 10 11 12 slot 1 0 12A 0x05 3 4 5 7 9 10 11 12 slot 1 0 12B 0x01 3 4 5 7 9 10 11 12 slot 1 0 12C 0x02 3 4 5 7 9 10 11 12 slot 1 0 12D 0x03 3 4 5 7 9 10 11 12 slot 2 0 13A 0x01 3 4 5 7 9 10 11 12 slot 2 0 13B 0x02 3 4 5 7 9 10 11 12 slot 2 0 13C 0x03 3 4 5 7 9 10 11 12 slot 2 0 13D 0x05 3 4 5 7 9 10 11 12 slot 3 0 14A 0x02 3 4 5 7 9 10 11 12 slot 3 0 14B 0x03 3 4 5 7 9 10 11 12 slot 3 0 14C 0x05 3 4 5 7 9 10 11 12 slot 3 0 14D 0x01 3 4 5 7 9 10 11 12 slot 4 0 15A 0x03 3 4 5 7 9 10 11 12 slot 4 0 15B 0x05 3 4 5 7 9 10 11 12 slot 4 0 15C 0x01 3 4 5 7 9 10 11 12 slot 4 0 15D 0x02 3 4 5 7 9 10 11 12 slot 5 0 16
Re: acpi problem ???
On Thu, 23 Jan 2003, Nate Lawson wrote: > On Thu, 23 Jan 2003, Bryan Liesner wrote: > > I just upgraded my 4.7 system to 5.0-current via sources. Everything > > went smoothly, and I was up and running quickly, but with an acpi related > > problem. > > > > When booting, the kernel loads, detects the devices, then hangs right > > here: > > > > Mounting root from ufs:/dev/ad0s1a > > pid 84 (fsck_ufs), uid 0: exited on signal 8 > > > > No panic, just a hang. > > One thing you have wrong is that you have both acpi and apm enabled. Nix > apm and try again. > > Also, try without the usb drive plugged in. > I took out the apm and the usb drive, same issue. Thanks... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acpi problem ???
On Fri, 24 Jan 2003, Nate Lawson wrote: > On Thu, 23 Jan 2003, Bryan Liesner wrote: > > On Thu, 23 Jan 2003, Nate Lawson wrote: > > > > > On Thu, 23 Jan 2003, Bryan Liesner wrote: > > > > I just upgraded my 4.7 system to 5.0-current via sources. Everything > > > > went smoothly, and I was up and running quickly, but with an acpi related > > > > problem. > > > > > > > > When booting, the kernel loads, detects the devices, then hangs right > > > > here: > > > > > > > > Mounting root from ufs:/dev/ad0s1a > > > > pid 84 (fsck_ufs), uid 0: exited on signal 8 > > > > > > > > No panic, just a hang. > > > > > > One thing you have wrong is that you have both acpi and apm enabled. Nix > > > apm and try again. > > > > > > Also, try without the usb drive plugged in. > > > > I took out the apm and the usb drive, same issue. > > Thanks... > > Boot single user, run fsck manually on each partition, then go multiuser. > No dice. I'm still getting the FPE on fsck_ufs. I'm kind of puzzled here. One possible clue - I forgot to unset the acpi_load, booted single user, and got the same hang when mounting root. The difference was that I didn't see fsck_ufs exit, the machine just sat there. The system isn't locked up in either case. I can hit ctrl-alt-delete and the system will reboot properly... -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: follow up on acpi issue
On Mon, 27 Jan 2003, Nate Lawson wrote: > On Sat, 25 Jan 2003, Bryan Liesner wrote: > > Thanks, Nate. When you suggested that I remove the apm stuff fron the > > kernel, you meant ALL of the apm stuff, didn't you :) . I took a > > second look and found I still had viapm and its requirements still in > > the config file. The system boots fine now with acpi. > > > > By the way, the system didn't hang as I claimed in my earlier mail. I > > was able to telnet in... Having acpi and viapm had the side effect of > > making the console go away. > > viapm is VIA power management, not an apm system. It's interesting that > it made your console go away. I'm sending this back to -current to see if > anyone has ideas what might be wrong with viapm. I had viapm and its requirements (iicbus, iicsmb) compiled in to my 4.7 kernel so that I could use mbmon to monitor temperatures, etc. Mbmon works just fine without it on 5.0 (a benefit of acpi??). -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -O2 considered harmful
On Wed, 26 Feb 2003, Dag-Erling Smorgrav wrote: > It seems that with -O2 on ia32 (-march=k6-2 in my case), gcc will in > some cases generate short jumps to targets too far away for the offset > to fit in a single byte. A surefire way to reproduce this is to build > Mesa (or XFree86-4-libraries, which includes parts of Mesa). > > Has anybody else run into this? > > DES > I have seen this as well, using -O2 -march=athlon-xp. The generated assembler tried to stuff -129 into a single byte. -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -O2 considered harmful
On Fri, 28 Feb 2003, David O'Brien wrote: > On Wed, Feb 26, 2003 at 05:31:20PM -0500, Bryan Liesner wrote: > > I have seen this as well, using -O2 -march=athlon-xp. > > The generated assembler tried to stuff -129 into a single byte. > > What about just trying -march=athlon? The only difference is the SSE > support, which is quite new and may have latent bugs anyway. I didn't try that, but i did not get that error using: -O2 -march=athlon-xp -mmmx -msse -m3dnow -mfpmath=sse to compile the xc/ tree I know that some of the flags above are redundant, but this worked and X is running without any crashes or wierdness. (so far). I also applied all of the above compile flags when building xscreensaver and saw a very noticeable speed improvement in some of the hacks. -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB crappiness?
On Sat, 19 Jul 2003, Juli Mallett wrote: > Hi, > > I tried to upgrade my workstation to current recently, and I have to > use a lot of USB, and while using some USB mass storage device, with > a UFS filesystem on it, and doing a large operation to it (tar c|tar x) > everything deadlocked on ufs, the USB stack blew up, and upon causing > an interrupt to it, it panicked, and panic pagefaulted. > > Anyone else seeing these sorts of cohesive fallovers? > > Thanx, > juli. > Yes, I can confirm that. I do an nightly dump to a file on my USB hard disk (ehci). I woke up to find a screen full of read errors, and at first I thought the disk went belly up. I reverted back and it was working fine. I/O speed has _seriously_ degraded as well. Prior to the bus dma patches, I was getting a little better than 8 MB/s writes to the disk, afterwards, less than 2 MB/s. The "performance hit" discussed prior to the commit is a bit of an understatement. -Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PANIC shutting down inetd
I get the following panic while shutting down the system or simply issuing a kill to inetd. This happens each and every time, but locks the system, so a dump isn't available. The kernel is compiled without WITNESS and without INVARIANTS. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8108810 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02e02d stack pointer = 0x10:0xdcdfaa50 frame pointer = 0x10:0xdcdfaa50 code segment = base 0x0 limit 0x, type 0x1b = DPL 0, pres 1, def32 1,gran 1 processor eflags= interrupt enabled, resume, IOPL=0 current process = 381 (inetd) trap number = 12 panic page fault DDB says: Stopped at in_pcbremlists+0x8d stack trace: in_pcbremlists() in_pcbdetach() tcp_close() tcp_disconnect() tcp_usr_detach() soclose() soo_close() fdrop_locked() fdrop() ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic at in_pcbremlists()
A couple of days ago I posted a message about panicing whenever shutting down inetd. The panic persists, but now it seems to happen at any time, always stopping at in_pcbremlists(). The kernel is up-to-date, a kernel built on July 30th runs stable as a rock. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10001 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02e044a stack pointer = 0x10:0xd68d9c08 frame pointer = 0x10:0xd68d9c14 code segment = base 0x0 limit 0x, type 0x1b = DPL 0, pres 1, def32 1,gran 1 processor eflags= interrupt enabled, resume, IOPL=0 current process = 11 (swi7: tty:sio clock) trap number = 12 panic page fault DDB says: Stopped at in_pcbremlists+0x8d stack trace: in_pcbremlists() in_pcbdetach() tcp_twclose() tcp_timer tcp_slowtimeo() pfslowtimeo() softclock() ithread_loop() fork_exit() fork_trampoline() ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic, then trashed IDE drive - from kernel dump?
The last known good state of my system was a world and kernel from Sunday, Aug 24 at approx 12:00 EDT. This problem is from a kernel built from sources current as of Aug 26th at approx 22:00 EDT Here's the sequence - I booted the system, had a panic while running sysctl from etc/rc.d/devd. It completed a core dump, and rebooted. (Good, I thought, this time I'll have a dump for a backtrace). The system rebooted and found no bootable disks. I had to repartition the disk and restore from backup. I suspect the dump scribbled all over the drive... This is repeatable, and I found out, I have good backups :) Anything I can do to help, please let me know. I'll try to get some sort of a backtrace, but I think doing it from a core dump will be futile... Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic, then trashed IDE drive - from kernel dump?
Just a follow up to this - cannot get it to panic with DDB compiled in. hmmm... On Mon, 25 Aug 2003, Bryan Liesner wrote: > > The last known good state of my system was a world and kernel from > Sunday, Aug 24 at approx 12:00 EDT. > > This problem is from a kernel built from sources current as of > Aug 26th at approx 22:00 EDT > > Here's the sequence - I booted the system, had a panic while running > sysctl from etc/rc.d/devd. It completed a core dump, and rebooted. > (Good, I thought, this time I'll have a dump for a backtrace). > > The system rebooted and found no bootable disks. I had to repartition > the disk and restore from backup. I suspect the dump scribbled all > over the drive... > > This is repeatable, and I found out, I have good backups :) > > Anything I can do to help, please let me know. I'll try to get some > sort of a backtrace, but I think doing it from a core dump will be > futile... > > Thanks. > > > > > > > > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- = = 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]"
Question: should I even bother?
Over the past few weeks, I have posted messages about panics that I've been having. No answers at all. Yesterday, I posted about a repeatable problem where dumps just destroy my IDE drive. No answers. Pretty serious problem. No, my swap partition doesn't start at sector 0. Have I offended some or all of you somehow? I'd like to contribute in some way... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ifconfig -a blows up if /etc/mac.conf isn't installed
On Fri, 29 Aug 2003, Kenneth D. Merry wrote: > > I've figured out that after some recent posix1e upgrades (mac stuff?), > ifconfig -a will blow up if mac.conf isn't there: > > # mv /etc/mac.conf /etc/mac.conf.backup > # ifconfig -a > fxp0: flags=8843 mtu 1500 > inet 10.0.0.6 netmask 0xff00 broadcast 10.0.0.255 > ether 00:30:48:21:bb:74 > media: Ethernet autoselect (100baseTX ) > status: active > Memory fault (core dumped) Same here. I took a look, and found that line 62 of /usr/src/sbin/ifconfig/ifmac.c returns ENOENT, but the docs say this should return a -1. So this code looks correct. from ifmac.c: if (mac_prepare_ifnet_label(&label) == -1) I think the correct fix is in /usr/src/lib/libc/posix1e/mac.c Try this patch, rebuild libc, then rebuild ifconfig. --- lib/libc/posix1e/mac.c.orig Fri Aug 29 22:42:44 2003 +++ lib/libc/posix1e/mac.c Fri Aug 29 22:43:19 2003 @@ -365,7 +365,7 @@ return (mac_prepare(mac, ld->ld_labels)); } - return (ENOENT);/* XXXMAC: ENOLABEL */ + return (-1);/* XXXMAC: ENOLABEL */ } int ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
more hints
If I remove "device pmtimer" from my config, I get a consistent panic, or variation of: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0135b0a7 stack pointer = 0x10:0xd68f2c48 frame pointer = 0x10:0xd68f2c64 code segment = base 0x0 limit 0x, type 0x1b processor eflags= interrupt enabled, resume, IOPL=0 current process = 12 (swi7: tty:sio clock) trap number = 12 panic page fault ... This is with leaving my USB 2.0 drive turned on during boot time. If I use the same kernel (sans pmtimer) , but boot with my USB drive turned off, all is well. Or, I can put pmtimer back in the kernel and boot with the drive turned on, but sooner or later I'll get some type of panic. Some kind of timimg issue?. I think all of these panics have something to do with leaving the USB drive on at boot time. It seems like I don't have any issues if it stays turned off. That's probably why we're not seeing any reports, I doubt a lot of folks are using a USB 2.0 HD along with ehci... Again, all this started shortly after July 14th. The USB DMA changes may have something to do with this... -- = = 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 - copying atapi CD
I have a perl script that dd's each audio track from an audio cd. The tracks are copied just fine until it gets about 75% into a 70 minute cd. dd then gets slower and slower until it seems to grind to a halt. eventually, I'll set TIMEOUT messages and won't be able to kill the current dd process. Same results with DMA or PIO modes. Shorter (40 minute) CDs make it through the process OK. Soren's crdao 1.1.7 for ATAng also grinds to a halt when copying a cd. -- = = 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]"
Re: ATAng - copying atapi CD
On Wed, 3 Sep 2003, Martin wrote: > Am Di, 2003-09-02 um 18.56 schrieb Bryan Liesner: > > dd then gets slower and slower until it seems to grind to a halt. > > I have this problems everywhere (not only ATAng), if I'm trying to > read some of my really old CD-Rs. You should know that they are aging. > > Check the surface of the CD-R (the surface is actually the label!). > On few CD-Rs which have been in my car the label begins to break > in the outter areas. This can have several reasons: > - too much UV light (sun) > - too high humidity > - and also touching the CD-R on the outter area while holding it > > If you notice that your CD-R label looks strange and if you need > the data, you should backup it fast. No, we're talking about brand new, factory pressed, audio CDs. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng - copying atapi CD
On Wed, 3 Sep 2003, Soren Schmidt wrote: > > > No, we're talking about brand new, factory pressed, audio CDs. > > > > And on top of that, my Windows XP machine's DVD-ROM was able to raed my > > *commercial audio CDs* perfectly while the CD-RW in the FreeBSD machine was > > only able to read about 95% of the discs before it just got stuck. > > Can you play those discs in your cd-rw drive ? > I can play the discs, but, I didn't play one from start to finish. I'll give it a try later. -Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng - copying atapi CD
On Wed, 3 Sep 2003, Terry Lambert wrote: > Bryan Liesner wrote: > > On Wed, 3 Sep 2003, Martin wrote: > > > If you notice that your CD-R label looks strange and if you need > > > the data, you should backup it fast. > > > > No, we're talking about brand new, factory pressed, audio CDs. > > Are they copy protected? > > The way you can tell is if you try to do what you are trying to > do, and it fails the way that it's failing, then they are likely > copy protected. > Possible, but if they are protected, wouldn't I be prevented from copying any track, or do they pick a random track or two just to piss me off? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ATAng - delay probing for non-existent drive
The last change to ata-lowlevel (rev 1.11) causes a 10-15 second delay probing for a drive that's not there: atapci0: port 0xa000-0xa00f,0xa400-0xa403, 0xa800-0xa807,0xb000-0xb003,0xb400-0xb407 mem 0xed00-0xed003fff irq 5 at device 15.0 on pci0 atapci0: [MPSAFE] ata2: at 0xb400 on atapci0 ata2: [MPSAFE] hangs here for about 15 seconds ata3: at 0xa800 on atapci0 ata3: [MPSAFE] I have a single drive on ata2. Reverting back to 1.10 stops the delay. -Bryan ___ [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)
On Wed, 17 Sep 2003, Thomas Quinot wrote: > Le 2003-09-17, Guillaume écrivait : > > > > + if (atapi_dma && atp->channel->dma && > > > + (atp->param->config & ATA_DRQ_MASK) != ATA_DRQ_INTR) > > > + atp->setmode(atadev, ATA_DMA_MAX); > > > + else > > > + atp->setmode(atadev, ATA_PIO_MAX); > > Ahem. Replace atadev with atp on both lines... > > Thomas. The patch seems to work, my cd0 and cd1 lines in the dmesg now report 33.000 MB/s insetad of 3.300 MB/s. -Bryan ___ [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)
On Thu, 18 Sep 2003, Thomas Quinot wrote: > Le 2003-09-18, Guillaume écrivait : > > > The patch does nothing for me. Same results... and cd0 is still slow. > > OK, then please try to apply the patch below in addition to the previous > one: > Sorry, I hadn't really noticed or checked for speed issues before the first patch that you issued, only that I noticed the reported speed went from 3.3MB/s to 33.3MB/s. There is a new issue, though. Soren commited a change to ata-queue.c this morning. This change together with atapicam, causes the system to hang indefinitely after detecting ad0. Had to hit the reset button and boot from the previous kernel. Without atapicam, the system boots normally. -Bryan ___ [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 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]"
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 Sat, 20 Sep 2003, Lars Eggert wrote: > Daniel Eischen wrote: > > On Sat, 20 Sep 2003, Soren Schmidt wrote: > >>It seems Daniel Eischen wrote: > >> > >>>On a kernel built just a few hours ago, it hangs on boot > >>>right after: > >>> > >>>acd0: CDROM at ata0-master PIO4 > >> > >>Get atapicam out and see if that helps.. > > > > No, using latest sources, with or without atapicam, does > > not solve the problem. It still hangs. > > As a datapoint, I experienced the hang with atapicam, too. Removing it > helped in my case. I experienced the hang with atapicam, and removing it helps. These symptoms happened immediately after the commit of ata-queue.c v1.5. Reverting back to 1.4 removed the issue altogether. I tried to get a verbose boot message using ata-queue 1.5 and 1.6, but got way, way too many spurious interrupt messages to have anything useful to share... -Bryan ___ [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/REQUEST_SENSE recovered from missing interrupt
On Sat, 20 Sep 2003, Thomas Quinot wrote: > Le 2003-09-20, Daniel Eischen écrivait : > > > No, using latest sources, with or without atapicam, does > > not solve the problem. It still hangs. > > Please try the patch below, it should at least work around the problem. > > > http://people.freebsd.org/~deischen/ata_hang.091903 > > Interesting, the last 2 lines are : > > ata0: spurious interrupt - status=0x50 error=0x00 > acd0: WARNING - REQUEST_SENSE recovered from missing interrupt > > so I'd suspect there is some race condition between the interrupt > and the REQUEST_SENSE command. Søren, shouldn't ata_interrupt lock the > channel before copying ch->running? > > Thomas. > > Index: atapi-cam.c > === The patch doesn't take care of the hang for me. Did anyone read _any_ of my previous posts? Bryan ___ [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/REQUEST_SENSE recovered from missing interrupt
On Sun, 21 Sep 2003, Thomas Quinot wrote: > Le 2003-09-21, Bryan Liesner écrivait : > > > The patch doesn't take care of the hang for me. > > Does it change anything, or do you still see the 'REQUEST_SENSE > recovered from missing interrupt'? Is your source tree up-to-date? > Several fixes have been committed to both the ATA and the CAM subsystems > recently, that address problems uncovered by the transition to ATAng. > > > Did anyone read _any_ of my previous posts? > > Certainly so, since you already received answers to some of them. Thanks, the hang problems are fixed now. In an earlier post, I pointed out the commit that seemed to break things. Immediately after a commit to ata-queue.c, the hangs started. I was incorrectly thinking that this commit caused the problem, instead of uncovering a problem that was hiding somewhere else. No one told me that I was barking up the wrong tree... -Bryan ___ [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)
On Wed, 24 Sep 2003, Thomas Quinot wrote: > Le 2003-09-19, Guillaume écrivait : > > > Thanks for the patch. cd0 is faster now and ATAPICAM works great. > > Are you going to commit the patch? > > DMA is now enabled for ATAPI/CAM i/o, as of atapi-cam.c rev. 1.26. > Thanks to all who tested and reviewed the change. > No, thank you! dd'ing a full data CD before this fix had top showing at least 50% of the CPU time in interrupt - it's now down to the usual 5% or less. -Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem w/ ACPI in -CURRENT: Update
Now I'm having an issue with ACPI. I used to hit the power button and that would initiate a proper shutdown. Now it seems to do nothing, but when I reboot the system goes into a suspended state before completing the shutdown. The motherboard beeps three times, the screen goes blank, and will complete the shutdown after I hit the any key. The strange thing is that in the past, a user initiated suspend while the system is running would never blank the screen, but this suspend-before-shutdown does... What do you need from me to help resolve this? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI shutdown problem
On Wed, 1 Oct 2003, Nate Lawson wrote: > > Now I'm having an issue with ACPI. I used to hit the power button and > > that would initiate a proper shutdown. Now it seems to do nothing, > > but when I reboot the system goes into a suspended state before > > sysctl hw.acpi should show you what the power button event generates. It > should be set to S5. What does yours say? > > -Nate I had a look at that. I have: hw.acpi.power_button_state: S5 Thanks, Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: savecore: first and last dump headers disagree on /dev/ad0b
On Tue, 7 Oct 2003, Kris Kennaway wrote: > I also had problems dumping onto a UDMA66 disk on a promise PDC20267 > controller - it seemed to dump OK (dump was readable after I recovered > the disk), but it (or maybe the crash itself) trashed the partition > table. > > Kris I mentioned the very same problem last June in a few posts here. I guess no one else experienced this issue, or there would have been some kind of response. In fact, I haven't been able to recover a crashdump since I switched over to current at the beginning of the year. I have a promise PDC20269 UDMA133 and a Maxtor 60G. More recently, though, sometime in mid September, a panic and crash dump trash my partition table as well. And it's repeatable, but I'm not going to try again to see if it was fixed :) -Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: pmap_zero_page: CMAP3 busy
On Sat, 11 Oct 2003, Don Lewis wrote: > On 11 Oct, Steve Kargl wrote: > > Upgrade tonight (7pm PST) and received the following > > on rebooting > > > > panic: pmap_zero_page: CMAP3 busy > > > > Unfortunately, this system does not have a serial > > console and the panic locked it up tight. Only > > a hard reset brought the system back. > > I was just about to type "make installworld" when I got this message > > I checked the commit logs and didn't see any recent commits that looked > suspicious, and since I do have a serial console I decided to throw > caution to the wind and give the new kernel a try. > I had this very same panic which happened right after commits to locore.s and machdep.c. Reverting back to the previous versions (with everything else up-to-date) let it boot without panicking. -Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Still getting panic on boot. (fwd)
oops, didn't cc this to the list -- Forwarded message -- Date: Wed, 12 Mar 2003 15:50:01 -0500 (EST) From: Bryan Liesner <[EMAIL PROTECTED]> To: Shizuka Kudo <[EMAIL PROTECTED]> Subject: Re: Still getting panic on boot. On Wed, 12 Mar 2003, Shizuka Kudo wrote: > > --- walt <[EMAIL PROTECTED]> wrote: > > 04:00 GMT Mar 12: > > > > Just cvsup'd and rebuilt with same result as 12 hours ago -- > > I see a kernel panic "page fault while in kernel mode" just > > after attempting to mount the root filesystem. > > > > The kernel from yesterday works fine and when I reboot the > > filesystems come up clean, so the new kernel nevers writes > > to disk, apparently. > > > > Am I the only one seeing this? > > I saw the same here. However, after reboot with the same faulty kernel, it may not > panic but > doesn't have the /dev/null entry which makes the bootup process failed. In > addition, my -current > was cvsup'd about four hours ago. > I'm seeing the same thing - /dev/null disappeared. I also saw in my nightly scripts that 'tee /dev/stderr' failed as well. It seems fairly random. X wouldn't start, complaining that /dev/vga doesn't exist. I did a cvsup by date/time: *default release=cvs date=2003.03.10.12.00.00 tag=. That seems to put things right. There were some kern commits shortly after that time that caused this weirdness. I've been really busy at work fixing a billion bugs for c client rollout - no time for a backtrace... ( the bugs aren't mine - I write perfect code every time :) ) -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panics with GnuPG
On Wed, 12 Mar 2003, Brent Jones wrote: > Wow. That's quite a trick. I've CVSup'ed, buildworld/kernel and > freshly installed gpg, within the last two hours. > > [EMAIL PROTECTED]:/home/brent $ gpg --keyserver pgp.mit.edu --recv-key > BB6BC940 > and then it dies... > > Brent > > On Wednesday, Mar 12, 2003, at 14:45 America/Denver, Damian Gerow wrote: > > > Thus spake Brent Jones ([EMAIL PROTECTED]) [03.03.12 16:41]: > >> Can you tell me the keyserver you're using? > > In ~/.gnupg/gpg.conf: > > keyserver x-hkp://pgp.mit.edu > > > > When I type: > > > > % gpg --recv-key BB6BC940 > > > > I panic. > > > > I'd *really* like to try other keyservers, but I've already lost about > > three > > hours today (my own fault, I know, I'm not complaining about FBSD > > whatsoever) in panics, and I'm feeling a little behind. > > > With the latest code, panics happen when running almost anything. I triggered a panic typing in man acpi... -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: latest working snapshot?
David O'Brien wrote: On Wed, Mar 12, 2003 at 10:32:02PM +0200, Ruslan Ermilov wrote: On Wed, Mar 12, 2003 at 02:14:25PM -0500, Andrew Gallatin wrote: I need to install current on a new box that just arrived. What's the latest working snapshot? 20030312-JPSNAP get about 40% of the way through the base install and sysinstall complains about a bad realloc, and lets me hit a key to reboot ;-( You're just lucky. Mine just panics. I wonder how long this has been happening -- 12-Feb-2003 also panics for me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message Commits shortly after 3/10 are causing weirdness. Looks like this has been happening (at least for me) after 3/10. Last night, I came home from work, touched my keyboard, and it panic'd. I thought it was strange, the machine was on all day and I was logging in and out at various times from work. After a few reboots, I noticed that it wasn't panicking in the same place. Sometimes before mounting. Sometimes while running init. Sometimes while starting sendmail. Sometimes not at all. Once, I thought it was up, but with the console was hosed, so I tried to telnet in from my wife's system. That succeeded, caused it to panic, and the message was: remaking ttyp0 don't do that panic... I have seen disappearing devices like /dev/null and stderr missing at boot time or just going away while the system is up. -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
disappearing devices
Todays sources as of about 22:00 est I built a kernel, rebooted, and built another, which failed with: NM=nm sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s /usr/src/sys/kern/genassym.sh: cannot create /dev/stdout: Operation not supported *** Error code 2 Stop in /usr/obj/usr/src/sys/GRAVY. *** Error code 1 One more reboot and another random? panic... -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic on boot (devfs_find)
I made posts here recently describing some panics which are somehow related to disappearing/never created device nodes. I am unable to produce a core dump at all, as it panics before / is mounted. The documented kern.dumpdev (unknown oid) doesn't exist and setting dumpdev=ad0s1b in loader.conf doesn't help either. I compiled the faulty kernel with ddb and found that the failure was in devfs_find(). I'm trying to gather more information. Any tips on how to get a proper core dump would be appreciated. As described in my earlier posts, this started happening sometime shortly after commits done after 3/10/2003. Now, really, am I the only one experiencing this? -Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic on boot (devfs_find)
On Fri, 14 Mar 2003, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bryan Liesner writes: > > > > > >I made posts here recently describing some panics which are somehow > >related to disappearing/never created device nodes. I am unable to > >produce a core dump at all, as it panics before / is mounted. > >The documented kern.dumpdev (unknown oid) doesn't exist and > >setting dumpdev=ad0s1b in loader.conf doesn't help either. > > Do you have any indication which device may be causing this ? I suspect /dev/null. On 3/11, I had a kernel compiled that was acting strangely. It would appear to run just fine, but when I went to compile, the build process complained that /dev/null doesn't exist. I checked, and it didn't. I also lost /dev/stderr when I looked at the nightly maintenance output. stdout and others just disappeared. X wouldn't start, complaining that vga didn't exist. (this happend shortly after I successfully ran X, exited, and restarted.) I was able to get a kernel up and running (strangely) on 3/12, but commits after that cause an immediate panic as soon as init starts. If I build a kernel from sources cut off at 3/10/2003 at 12:00, everything works fine. -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic on boot (devfs_find)
On Fri, 14 Mar 2003, Conrad Sabatier wrote: > > Now, really, am I the only one experiencing this? > > No, you're not. I've been unable to get a bootable kernel running for the last > few days also. > > Booting in verbose mode, I see the last thing that occurs just before the panic > is mounting root and then starting (or trying to start) /sbin/init. After an > initial "hang", it drops into ddb. Did it panic on devfs_find()? And, if you've seen my earlier posts, have you experienced that stuff too? -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic on boot (devfs_find)
On Sat, 15 Mar 2003, Shizuka Kudo wrote: > > --- Bryan Liesner <[EMAIL PROTECTED]> wrote: > > > > I was able to get a kernel up and running (strangely) on 3/12, but > > commits after that cause an immediate panic as soon as init starts. > > > > If I build a kernel from sources cut off at 3/10/2003 at 12:00, > > everything works fine. > > > > It is related to the sys/geom/geom_event.c commit on 3/11/2003: > > > Revision 1.20 / (download) - annotate - [select for diffs], Mon Mar 10 23:41:41 > > 2003 UTC (5 > days, 5 hours ago) by phk > > Branch: MAIN > > CVS Tags: HEAD > > Changes since 1.19: +5 -0 lines > > Diff to previous 1.19 (colored) > > > > If we run out of consumers while orphaning them, and the provider's geom > > is withering, destroy the provider when done. > > > > This was exposed by the recent change to geom_dev's orphaning logic > > If I reverted it back to a previous version (1.19) then the machine booted OK. > > BTW, I also found that adding INVARIANTS options into the kernel can prevent this > problem as well. > > Regards, I have reverted back to rev 1.19 and all seems to be running OK. I have /dev/null, /dev/stderr, /dev/apm, and /dev/mixer back. When the faulty kernel _did_ boot (after about a million retries to coax a core dump), these devices were missing at boot, or would disappear shortly after. Thanks. I think Poul-Henning will have enough information to go with now... -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic on boot (devfs_find)
On Sun, 16 Mar 2003, Poul-Henning Kamp wrote: > >I think Poul-Henning will have enough information to go with now... > > You guys _way_ overestimate my abilities here. > > Right now I have a hard time imagining what geom's eventhandling > for "withering" geoms can possibly have to do with any non-geom > device node being present in /dev or not, and even more so how > INVARIANTS could affect that. > > The only influence I can imagine is one of timing... > > I don't think I'll stand a chance on this one until I can reproduce it > on one of my machines :-( > > One thing I'd like you to try is to remove any trace of USB from your > systems. USB does some ugly VOP_REVOKES which I am not happy about, and > I would like to exclude them from the list of suspects. > I'll try removing USB and report the results back to you. It's 3:30am here and I'm going to try to get some sleep. I'll do it sometime later today. Thanks. -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic on boot (devfs_find)
On Sun, 16 Mar 2003, Poul-Henning Kamp wrote: > > One thing I'd like you to try is to remove any trace of USB from your > systems. USB does some ugly VOP_REVOKES which I am not happy about, and > I would like to exclude them from the list of suspects. > You can remove USB from your list, I tried building without USB in the kernel, and the panic remains... If you need any more info from me, don't hesitate to ask. Thanks. -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic on boot (devfs_find)
walt wrote: Bryan Liesner wrote: On Sun, 16 Mar 2003, Poul-Henning Kamp wrote: One thing I'd like you to try is to remove any trace of USB from your systems. USB does some ugly VOP_REVOKES which I am not happy about, and I would like to exclude them from the list of suspects. You can remove USB from your list, I tried building without USB in the kernel, and the panic remains... Which of these flags have you been using?: #cpuI486_CPU #cpuI586_CPU cpu I686_CPU I normally use only the 686 flag, but when I included the 586 my panic-on-boot changed to a panic-on-starting-X. I'm using I686. I also reverted from -march=athlon-xp for building to the default with the same results. -- == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED]Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: umtx/libthr SMP fixes.
On Thu, 5 Jun 2003, Terry Lambert wrote: > As I said: I still think there is a lost serialization here > that's at the root of the problem. I can't really dedicate > the equipment I have here to reproducing the issue at this > time, or I'd track down the race I think may be happening. > > -- Terry The original panic in kern/52718 is no longer reproduceable for me at this time. After Jeff's latest changes, the panic moved from boot time to panicking when I did an init 6. I could _not_ reproduce the new panic if I built a kernel with DDB, but a DDBless kernel would panic every time after init 6. Needles to say, that makes things really tough to track down... After shit-canning the acpi module, it doesn't panic at all. I'm sure the race conditions are still lying in wait, but due to a lack of interest and the incredulous attitude of most on the mailing list, I'm going to forget about it for the time being. ACPI has always worked fine on my system, and I'm probably masking problems by not loading the module. Since I'm running a desktop system here, acpi doesn't really buy me anything, so apm is back in my kernel. -Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: umtx/libthr SMP fixes.
On Thu, 5 Jun 2003, Terry Lambert wrote: > I hesistate to suggest this because everyone always gives me > crap about me not disclosing the bug, but unless you are ready > to grovel around in locore, and figure out what the root cause > is for the difference in behaviour, I'm going to say that > the most likely cause is that a DDB kernel uses more memory. > > Given that, I'm going to suggest you try again without DDB, > but with: > > options DISABLE_PSE > options DISABLE_PG_G > > If it doesn't fix the problem, then you haven't really lost > anything but the time it takes to compile, reboot, rename, > and reboot again. A non disclosure agreement is a non disclosure agreement, so no crap from me. I'll give that a try and see if it makes a difference. I don't remember off of the top of my head from the previous posts on this subject, but does this bug apply to an Athlon XP as well? -Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: kern/52718
Is anyone going to look at this before the next release? Of course, if more info is needed, I'll send it along. No dump is available - it panics during boot. http://www.freebsd.org/cgi/query-pr.cgi?pr=52718 Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: kern/52718
On Thu, 29 May 2003, Julian Elischer wrote:
> without the correct keywords in your mail, it's unlikely either
> the CAM or Mutex people would see it before then
>
Here's a copy of my original mail, which was pretty much ignored, with
the exception of Terry Lambert. I feel that the subject was pretty
clear. If it wasn't clear enough, then I stand corrected.
Date: Mon, 26 May 2003 12:11:35 -0400 (EDT)
From: Bryan Liesner <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: panic since changes to kern_umtx.c
The change from kern_umtx.c rev 1.2 to 1.3 brought out the following
panic on my system. The panic does not occur if I revert back to 1.2
or if I turn off my USB hard drive (uses EHCI) and run with rev 1.3
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0135b0a7
stack pointer = 0x10:0xd68f2c48
frame pointer = 0x10:0xd68f2c64
code segment = base 0x0 limit 0x, type 0x1b
processor eflags= interrupt enabled, resume, IOPL=0
current process = 12 (swi7: tty:sio clock)
trap number = 12
panic page fault
DDB says it was in heap_up+0x27
...
(kgdb) l *heap_up+0x27
0xc0136be7 is in heap_up (../../../cam/cam_queue.c:345).
340 * equal too, or greater than j respectively.
341 */
342 static __inline int
343 queue_cmp(cam_pinfo **queue_array, int i, int j)
344 {
345 if (queue_array[i]->priority == queue_array[j]->priority)
346 return ( queue_array[i]->generation
347 - queue_array[j]->generation );
348 else
349 return ( queue_array[i]->priority
(kgdb)
350 - queue_array[j]->priority );
351 }
352
353 /*
354 * swap: Given an array of cam_pinfo* elements and indexes i and j,
355 * exchange elements i and j.
356 */
357 static __inline void
358 swap(cam_pinfo **queue_array, int i, int j)
359 {
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: kern/52718
On Thu, 29 May 2003, Nick H. wrote: > Just out of curosity... I had this same error a while back on one of my > boxes. I ended up booting to a recovery cd and running an fsck_ffs on it > and it fixed the problem. Mine would get to a login and *WHAM* it's dead. > Worth a shot to see if that fixes your problem or not > Tried that, and it still panics. Way before we get to a login, at the point where it starts to set up the disks... Thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: umtx/libthr SMP fixes.
On Mon, 2 Jun 2003, Jeff Roberson wrote: > If you have had issues with libthr on SMP or umtx panics, the following > patch may solve these issues. > > http://www.chesapeake.net/~jroberson/umtxlocks.diff > > This patch fixes several race conditions and other issues with umtx. Actually, no it doesn't. I was able to use kern_umtx v 1.3 only if I removed atapicam from my kernel config. These patches (now committed?) panic the system whether I use atapicam or not. With kern_umtx v1.2 there is no panic at all, with or without atapicam. Actually, I think it's cam in general that's causing the panic with these changes. Please see kern/52718 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: umtx/libthr SMP fixes.
On Tue, 3 Jun 2003, Scott Long wrote: > > Actually, I think it's cam in general that's causing the panic with > > these changes. > > > > Please see kern/52718 > > I didn't see a backtrace in the PR. Is there one that you can share > with us? > It panics during boot and, unfortunately, no dump is produced. The best I could do is what's already there in the PR. If there is anything more I can do, just let me know. I have (using cam) 2 atapi cdroms, a 100M zip disk, and a 40G USB hard disk. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: umtx/libthr SMP fixes.
On Tue, 3 Jun 2003, Scott Long wrote: > It's very hard to imagine Jeff's patches causing a problem at the point > that the PR mentions. Have you confirmed the problem in a kernel that > was build in a totally clean environment? > > Scott If you mean a kernel build with standard optimizations, yes I have seen it. No local patches: cc -O -pipe -mcpu=pentiumpro The panic happens before running init. Sometimes I'm "lucky" and the kernel doesn't panic during boot, but it will panic shortly before or after login. It locks up tight afterwards, and doesn't do a dump. All this happened after kern_umtx.c v1.2 When I revert back, no panic... It won't panic if I turn off the USB drive, or compile a kernel without atapicam. Possible problem with EHCI? The driver finds an OHCI device, calls it umass0, detaches it, finds an EHCI device and calls it umass1. I'm sure it's not Jeffs patches that are the problem, but other potential problems are exacerbated by them. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: umtx/libthr SMP fixes.
On Tue, 3 Jun 2003, Robert Watson wrote: > > On Tue, 3 Jun 2003, Bryan Liesner wrote: > > > Actually, no it doesn't. I was able to use kern_umtx v 1.3 only if I > > removed atapicam from my kernel config. These patches (now committed?) > > panic the system whether I use atapicam or not. With kern_umtx v1.2 > > there is no panic at all, with or without atapicam. > > > > Actually, I think it's cam in general that's causing the panic with > > these changes. > > Bizarre. Sounds like an errant pointer in some other code, and it's just > a matter of the memory layout as to what gets stepped on. Alternatively, > it might be affected by the insertion of the MTX sysinit event. Perhaps > that revision rearranges memory a bit. Even more bizarre. I have cvsupped to the latest source, built a kernel with DDB and it won't panic. Without DDB, it panics. But the behavior has changed a bit. I now panics _without_ atapicam in the build, at boot time. With atapicam, it panics and dumps core if I do an init 6. Savecore refuses to grab the dump: gravy savecore: first and last dump headers disagree on /dev/ad0s1b gravy savecore: unsaved dumps found but not saved I cleared the dump and tried again with the same results. If I reboot with the USB drive mounted, it will panic on the init 6, unmounted, it reboots without trouble. Any hints on grabbing a dump without savecore complaining, please let me know. I don't have anything specific to report yet, when I have time tomorrow I'll try to get more information out. > > Anyhow, here are some things you might consider, since this whole thing is > so odd. Try merging the addition of the struct mtx declaration from 1.3 > into 1.2 and see if you get the same panic. If you don't, try merging the > MTX_SYSINIT line and see if that triggers the panic. The other changes > probably wouldn't cause disruptive memory rearrangement, so see what > happens. If the panics appear with the addition of the variable, it > probably is a memory stepping thing and a bug in some other piece of code > (unfortunately, probably hard to track down). If it's the addition of the > initializer, it's a different class of problem. Right now I'm at rev 1.4 of kern_umtx... I'll try reverting back and trying this time permitting... > I have to admit that I'm also fairly baffled: my current reading of the > change suggests there won't be a specific bug in umtx, rather, the > triggering of symptoms from another bug, but I guess we can only find out > with a bit of experimentation. You might also find the problem > "disappears" if you remove INVARIANTS, although given that you can > reproduce this nicely, I'm reluctant to have you do that for fear the bug > will get away and not get fixed. INVARIANTS wasn't in the picture to begin with. If I put it in, it will probably disappear, as with using DDB. The code has changed sufficiently now that I can't reproduce the original panic that's in the PR, but it's still panicking... -- = = 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]"
