Re: ATAng still problematic
Le 2003-09-19, Dan Naumov écrivait : Disabling atapicam in the kernel or detaching the drive from the system works around the problem. Please try the patch I posted a few moments ago under ATAng no good for me/REQUEST_SENSE recovered from missing interrupt. Thomas. -- [EMAIL PROTECTED] ___ [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: 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]
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]
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]
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]
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 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: 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: 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]
ATAng still problematic
Hello there, I still have problems with ATAng, with kernel from 15th of September. First of all, the drive still does not get detected properly. Funny thing is that after some playing with atacontrol attach/detach, it finally gets detected. And later on, it is normally detected, before. Same scenario happened like 3 times with ATAng and newer and newer kernels. I don't know whether some device hints or anything are just updated; yet, I didn't have _any_ drive detection problems with ATAold. The problem is with the second drive. There's still some randomness in it, as it gets undetected from time to time. Another thing is with atapicam. First of all, I am not able to do any CD audio ripping, getting the following: [15:29] stronghold:/usr/tmp(569)# dagrab -d /dev/acd1 -a dagrab: error retrieving cddb data Dumping all tracks Dumping track 1: lba 0 to lba 42800 (needs 96 MB) Output file is: track01.wav dagrab: read raw ioctl failed at lba 0 length 12: Inappropriate ioctl for device I get the same error with cdda2wav. I've recompiled them both after upgrading, to no avail. The second thing is that I get a panic when trying to burn a CD with atapicam mode. panic: vm_fault_copy_wired: page missing I have recent cdrtools, recompiled after system upgrade. I will try to debug that with a freshly cvsupped kernel. I have my dmesg attached. -- -- 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 -- 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.1-CURRENT #11: Tue Sep 16 00:53:17 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MOONDANCE Preloaded elf kernel /boot/kernel/kernel at 0xc04db000. Preloaded elf module /boot/kernel/if_rl.ko at 0xc04db1f4. Preloaded elf module /boot/kernel/miibus.ko at 0xc04db2a0. Preloaded elf module /boot/kernel/snd_via82c686.ko at 0xc04db34c. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04db400. Preloaded elf module /boot/kernel/mga.ko at 0xc04db4ac. Preloaded elf module /boot/kernel/acpi.ko at 0xc04db554. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Duron(tm) Processor (600.03-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x630 Stepping = 0 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044RSVD,AMIE,DSP,3DNow! real memory = 536805376 (511 MB) avail memory = 515842048 (491 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: VIA694 AWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00fdd00 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 7 INTC is routed to irq 11 pcib0: slot 9 INTA is routed to irq 5 pcib0: slot 10 INTA is routed to irq 11 agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem 0xd500-0xd5ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib0: slot 1 INTA is routed to irq 10 pcib1: slot 0 INTA is routed to irq 10 drm0: Matrox G400/G450 (AGP) mem 0xd300-0xd37f,0xd200-0xd2003fff,0xd000-0xd1ff irq 10 at device 0.0 on pci1 info: [drm] AGP at 0xd500 16MB info: [drm] Initialized mga 3.1.0 20021029 on minor 0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686A UDMA66 controller port 0xd000-0xd00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pcm0: VIA VT82C686A port 0xe400-0xe403,0xe000-0xe003,0xdc00-0xdcff irq 11 at device 7.5 on pci0 pcm0: ICEnsemble ICE1232 AC97 Codec pci0: multimedia, audio at device 9.0 (no driver attached) rl0: RealTek 8139 10/100BaseTX port 0xec00-0xecff mem 0xd600-0xd6ff irq 11 at device 10.0 on pci0 rl0: Ethernet address: 00:e0:7d:b4:33:16 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at
Re: ATAng still problematic
It seems Jan Srzednicki wrote:
First of all, the drive still does not get detected properly. Funny
thing is that after some playing with atacontrol attach/detach, it
finally gets detected. And later on, it is normally detected, before.
Same scenario happened like 3 times with ATAng and newer and newer
kernels. I don't know whether some device hints or anything are just
updated; yet, I didn't have _any_ drive detection problems with ATAold.
The problem is with the second drive. There's still some randomness in
it, as it gets undetected from time to time.
Try the below patch and let me know if that changes anything..
Index: ata-lowlevel.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-lowlevel.c,v
retrieving revision 1.13
diff -u -r1.13 ata-lowlevel.c
--- ata-lowlevel.c 16 Sep 2003 15:21:37 - 1.13
+++ ata-lowlevel.c 18 Sep 2003 07:55:10 -
@@ -551,11 +551,8 @@
ch-devices |= ATA_ATA_MASTER;
}
}
- else if (err == lsb err == msb) {
- ATA_IDX_OUTB(ch, ATA_ERROR, 0xff);
- DELAY(10);
- if (stat0 == ATA_IDX_INB(ch, ATA_STATUS))
- stat0 |= ATA_S_BUSY;
+ else if ((stat0 0x4f) err == lsb err == msb) {
+ stat0 |= ATA_S_BUSY;
}
}
}
@@ -579,11 +576,8 @@
ch-devices |= ATA_ATA_SLAVE;
}
}
- else if (err == lsb err == msb) {
- ATA_IDX_OUTB(ch, ATA_ERROR, 0xff);
- DELAY(10);
- if (stat1 == ATA_IDX_INB(ch, ATA_STATUS))
- stat1 |= ATA_S_BUSY;
+ else if ((stat1 0x4f) err == lsb err == msb) {
+ stat1 |= ATA_S_BUSY;
}
}
}
-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
On Thu, Sep 18, 2003 at 03:54:36PM +0200, Soren Schmidt wrote: It seems Jan Srzednicki wrote: First of all, the drive still does not get detected properly. Funny thing is that after some playing with atacontrol attach/detach, it finally gets detected. And later on, it is normally detected, before. Same scenario happened like 3 times with ATAng and newer and newer kernels. I don't know whether some device hints or anything are just updated; yet, I didn't have _any_ drive detection problems with ATAold. The problem is with the second drive. There's still some randomness in it, as it gets undetected from time to time. Try the below patch and let me know if that changes anything.. It seems that things have changed a bit (the drive gets detected more often), but still, it's not perfect. Anyway, here's backtrace for atapicam panic I've mentioned. It's triggered by: cdrecord dev=1,1,0 /some/track greetings, -- -- 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 -- Script started on Thu Sep 18 17:43:10 2003 [m[27m[24m[J[17:43] stronghold:/usr/tmp/crash(608)# [Kggdb -k kernel.debug0 .0 vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: vm_fault_copy_wired: page missing panic messages: --- panic: vm_fault_copy_wired: page missing syncing disks, buffers remaining... 3428 3428 3426 3426 3426 3426 3426 3426 3426 3426 3426 3426 3426 3426 3426 3426 3426 3426 3426 3426 3426 3426 giving up on 2440 buffers Uptime: 4m54s Dumping 511 MB [CTRL-C to abort] [CTRL-C to abort] 16 32 48 64 80 96 112 128 144 160 176 192 208 224[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 240 256 272 288 304 320 336 352 368 384 400 416 432 448Copyright (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.1-CURRENT #12: Thu Sep 18 16:36:35 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MOONDANCE Preloaded elf kernel /boot/kernel/kernel at 0xc04e7000. Preloaded elf module /boot/kernel/if_rl.ko at 0xc04e71f4. Preloaded elf module /boot/kernel/miibus.ko at 0xc04e72a0. Preloaded elf module /boot/kernel/snd_via82c686.ko at 0xc04e734c. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04e7400. Preloaded elf module /boot/kernel/mga.ko at 0xc04e74ac. Preloaded elf module /boot/kernel/acpi.ko at 0xc04e7554. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Duron(tm) Processor (600.03-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x630 Stepping = 0 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044RSVD,AMIE,DSP,3DNow! real memory = 536805376 (511 MB) avail memory = 515792896 (491 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: VIA694 AWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00fdd00 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 7 INTC is routed to irq 11 pcib0: slot 9 INTA is routed to irq 5 pcib0: slot 10 INTA is routed to irq 11 agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem 0xd500-0xd5ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib0: slot 1 INTA is routed to irq 10 pcib1: slot 0 INTA is routed to irq 10 drm0: Matrox G400/G450 (AGP) mem 0xd300-0xd37f,0xd200-0xd2003fff,0xd000-0xd1ff irq 10 at device 0.0 on pci1 info: [drm] AGP at 0xd500 16MB info: [drm] Initialized mga 3.1.0 20021029 on minor 0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686A UDMA66 controller port 0xd000-0xd00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pcm0: VIA VT82C686A port 0xe400-0xe403,0xe000-0xe003,0xdc00-0xdcff irq 11 at device 7.5 on pci0 pcm0: ICEnsemble ICE1232 AC97 Codec pci0: multimedia, audio at device 9.0 (no driver attached) rl0: RealTek 8139 10/100BaseTX
Re: ATAng still problematic
Soren, I've noticed the same thing with the last two builds. After detaching and then re-attaching the second channel, both my slave dvdrom and my truant master cdrw show up and appear to work ok. I just tried your patch (didn't apply cleanly so I edited the file myself). No apparent change. Attached is my dmesg -a output for this bootup (includes results of atacontrol detach 1 ; atacontrol attach 1) Andrew Lankford 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.1-CURRENT #7: Thu Sep 18 11:34:01 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARL5KERNEL Preloaded elf kernel /boot/kernel/kernel at 0xc04de000. Preloaded elf module /boot/kernel/vesa.ko at 0xc04de21c. Preloaded elf module /boot/kernel/if_sis.ko at 0xc04de2c8. Preloaded elf module /boot/kernel/miibus.ko at 0xc04de374. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04de420. Preloaded elf module /boot/kernel/snd_es137x.ko at 0xc04de4cc. Preloaded elf module /boot/kernel/usb.ko at 0xc04de57c. Preloaded elf module /boot/kernel/ums.ko at 0xc04de624. Preloaded elf module /boot/kernel/agp.ko at 0xc04de6cc. Preloaded elf module /boot/kernel/acpi.ko at 0xc04de774. Calibrating clock(s) ... i8254 clock: 1193296 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 737021995 Hz CPU: Intel Pentium III (737.02-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 535736320 (510 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00505000 - 0x1f5c9fff, 520900608 bytes (127173 pages) avail memory = 515051520 (491 MB) bios32: Found BIOS32 Service Directory header at 0xc00f1430 bios32: Entry = 0xf0bf0 (c00f0bf0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdf0 pnpbios: Found PnP BIOS data at 0xc00fc070 pnpbios: Entry = f:c0a0 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: random: entropy source mem: memory I/O Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 00 01 10 00 53 25 2e 01 00 01 40 01 00 01 63 01 00 01 1c 01 09 01 0a 01 0b 01 0c 01 1d 01 0e 01 00 01 27 01 28 01 01 01 10 01 11 01 12 01 02 01 VESA: 20 mode(s) found VESA: v3.0, 1024k memory, flags:0x1, mode table:0xc0403c62 (122) VESA: Intel(R) 810, Intel(R) 815 Chipset Video BIOS VESA: Intel Corporation Intel(R) 810, Intel(R) 815 Chipset Hardware Version 0.0 null: null device, zero device npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS CUSL2on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=11308086) pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00f1360 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 72540A 0x60 3 4 5 7 9 10 11 12 slot 72540B 0x61 3 4 5 7 9 10 11 12 embedded02A 0x60 3 4 5 7 9 10 11 12 embedded0 31A 0x60 3 4 5 7 9 10 11 12 embedded0 31B 0x61 3 4 5 7 9 10 11 12 embedded0 31C 0x6b 3 4 5 7 9 10 11 12 embedded0 31D 0x63 3 4 5 7 9 10 11 12 slot 1 19A 0x69 3 4 5 7 9 10 11 12 slot 1 19B 0x6a 3 4 5 7 9 10 11 12 slot 1 19C 0x6b 3 4 5 7 9 10 11 12 slot 1 19D 0x68 3 4 5 7 9 10 11 12 slot 2 1 10A 0x6a 3 4 5 7 9 10 11 12 slot 2 1 10B 0x6b 3 4 5 7 9 10 11 12 slot 2 1 10C 0x68 3 4 5 7 9 10 11 12 slot 2 1 10D 0x69 3 4 5 7 9 10 11 12 slot 3 1 11A 0x6b 3 4 5 7 9 10 11 12 slot 3 1 11B 0x68 3 4 5 7 9 10 11 12 slot 3 1 11C 0x69 3 4 5 7 9 10 11 12 slot 3 1 11D 0x6a 3 4 5 7 9 10 11 12 slot 4 1 12A 0x68 3 4 5 7 9 10 11 12 slot 4 1 12B 0x69 3 4 5 7 9 10 11 12 slot 4 1 12C 0x6a 3 4 5 7 9 10 11 12 slot 4 1 12D 0x6b 3 4 5 7 9 10 11 12 slot 5 1 13A 0x69 3 4 5 7 9 10 11 12 slot 5 1 13B 0x6a 3 4 5 7 9 10 11 12 slot 5 1 13C 0x6b 3 4 5 7 9 10 11 12 slot 5 1 13D 0x68 3 4 5 7 9 10 11 12 slot 6 1 14A 0x62 3 4 5 7 9 10 11 12 slot 6 1 14B 0x63 3 4 5 7 9 10 11 12 slot 6 1 14C 0x60 3 4 5 7 9 10 11 12 slot 6 1 14D 0x61 3 4 5 7 9 10 11 12 embedded18A 0x68 3 4 5 7 9 10 11 12 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: Power Button (fixed) ACPI timer looks
Re: ATAng still problematic
It seems Jan Srzednicki wrote: First of all, the drive still does not get detected properly. Funny thing is that after some playing with atacontrol attach/detach, it finally gets detected. And later on, it is normally detected, before. Same scenario happened like 3 times with ATAng and newer and newer kernels. I don't know whether some device hints or anything are just updated; yet, I didn't have _any_ drive detection problems with ATAold. The problem is with the second drive. There's still some randomness in it, as it gets undetected from time to time. Try the below patch and let me know if that changes anything.. It seems that things have changed a bit (the drive gets detected more often), but still, it's not perfect. Perfect ? hmm - I'd settle for works :) Anyhow, what I need to be able to tell what may be going on, is that you boot verbose and get me the output from dmesg from a boot that found all device, and from a boot that missed. Anyway, here's backtrace for atapicam panic I've mentioned. It's triggered by: No idea, atapicam is not my area, maybe thomas@ can help... -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
On Thu, Sep 18, 2003 at 06:38:25PM +0200, Soren Schmidt wrote: Anyhow, what I need to be able to tell what may be going on, is that you boot verbose and get me the output from dmesg from a boot that found all device, and from a boot that missed. Anyone know how to make the message buffer larger? I don't have a serial console hooked up currently and a boot verbose is way over the 32K default buffer size so only get the last 32K once the system is booted up. -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 Thu, Sep 18, 2003 at 11:46:35AM -0500, Steve Ames wrote: On Thu, Sep 18, 2003 at 06:38:25PM +0200, Soren Schmidt wrote: Anyhow, what I need to be able to tell what may be going on, is that you boot verbose and get me the output from dmesg from a boot that found all device, and from a boot that missed. Anyone know how to make the message buffer larger? I don't have a serial console hooked up currently and a boot verbose is way over the 32K default buffer size so only get the last 32K once the system is booted up. How about /var/run/dmesg.boot? ;) -- -- 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
On Thu, 18 Sep 2003, Steve Ames wrote: On Thu, Sep 18, 2003 at 06:38:25PM +0200, Soren Schmidt wrote: Anyhow, what I need to be able to tell what may be going on, is that you boot verbose and get me the output from dmesg from a boot that found all device, and from a boot that missed. Anyone know how to make the message buffer larger? I don't have a serial console hooked up currently and a boot verbose is way over the 32K default buffer size so only get the last 32K once the system is booted up. From /sys/conf/NOTES: # Size of the kernel message buffer. Should be N * pagesize. options MSGBUF_SIZE=40960 ___ [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 06:55:07PM +0200, Jan Srzednicki wrote: On Thu, Sep 18, 2003 at 11:46:35AM -0500, Steve Ames wrote: On Thu, Sep 18, 2003 at 06:38:25PM +0200, Soren Schmidt wrote: Anyhow, what I need to be able to tell what may be going on, is that you boot verbose and get me the output from dmesg from a boot that found all device, and from a boot that missed. Anyone know how to make the message buffer larger? I don't have a serial console hooked up currently and a boot verbose is way over the 32K default buffer size so only get the last 32K once the system is booted up. How about /var/run/dmesg.boot? ;) That file only contains what can be held in the buffer until the file system is up (I think). It also only contains the last 32K or so of boot up messages.. I still lose all of the first messages: [EMAIL PROTECTED]:/home/steve head /var/run/dmesg.boot 0x30 ata1-master: stat=0x20 err=0x20 lsb=0x20 msb=0x20 ata1-slave: stat=0x30 err=0x30 lsb=0x30 msb=0x30 ata1-master: stat=0x20 err=0x20 lsb=0x20 msb=0x20 ata1-slave: stat=0x30 err=0x30 lsb=0x30 msb=0x30 See what I mean? -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 Thu, Sep 18, 2003 at 11:00:56AM -0600, Scott Long wrote: Anyone know how to make the message buffer larger? I don't have a serial console hooked up currently and a boot verbose is way over the 32K default buffer size so only get the last 32K once the system is booted up. From /sys/conf/NOTES: # Size of the kernel message buffer. Should be N * pagesize. options MSGBUF_SIZE=40960 Ah. I had looked over /sys/i386/conf/NOTES completely forgetting that they were architecture dependant. *sigh* Thank you. I'm building a new kernel right now with that number bumped up. -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
Le 2003-09-18, Jan Srzednicki écrivait : Anyway, here's backtrace for atapicam panic I've mentioned. It's triggered by: cdrecord dev=1,1,0 /some/track Um. Do you see the same crash if both drives contain CDs at boot time? If not, this could be a consequence of the error condition corruption problem others have been reporting. Thomas. -- [EMAIL PROTECTED] ___ [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 Thomas Quinot wrote: Le 2003-09-18, Jan Srzednicki écrivait : Anyway, here's backtrace for atapicam panic I've mentioned. It's triggered by: cdrecord dev=1,1,0 /some/track Um. Do you see the same crash if both drives contain CDs at boot time? If not, this could be a consequence of the error condition corruption problem others have been reporting. On that note I committed a fix to ata-queue.c earlier today... -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
On Thu, 18 Sep 2003, Thomas Quinot wrote: Le 2003-09-18, Jan Srzednicki ?crivait : Anyway, here's backtrace for atapicam panic I've mentioned. It's triggered by: cdrecord dev=1,1,0 /some/track Um. Do you see the same crash if both drives contain CDs at boot time? If not, this could be a consequence of the error condition corruption problem others have been reporting. Thomas. These crashes started before ATAng commit, some time between 10 and 15 August, and with precisely the same symptoms. 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) Regards, Vladimir ___ [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 01:32:45AM +0300, Vladimir Kushnir wrote: Um. Do you see the same crash if both drives contain CDs at boot time? If not, this could be a consequence of the error condition corruption problem others have been reporting. Thomas. These crashes started before ATAng commit, some time between 10 and 15 August, and with precisely the same symptoms. I wasn't following -CURRENT that time, I can't confirm it. 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. -- -- 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]
