ATA problems on Promise controller
With a -current kernel ( cvsupped today ) I can no longer boot. It hangs on the drives connected to the promis controller built into my MSI KT266 mobo. The messages are like ad2: READ command timeout tag=0 serv=0 - resetting Same for ad3. It tries falling back to pio mode but after that it hangs completely. I have tried putting hw.at.tags=0 in /boot/loader.conf as suggested in some older messages on this list but that dit not help. dmesg of a working kernel built 19-1-2003 is attached 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 #1: Sun Jan 19 15:50:33 MET 2003 [EMAIL PROTECTED]:/raid/bsd/obj/raid/bsd/freebsd/src/sys/trantor Preloaded elf kernel /boot/kernel.ok/kernel at 0xc04b1000. Preloaded elf module /boot/kernel.ok/acpi.ko at 0xc04b10ac. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1405012013 Hz CPU: AMD Athlon(tm) XP 1600+ (1405.01-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! real memory = 536805376 (511 MB) avail memory = 516407296 (492 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: flags 0x7 npx0: INT 16 interface acpi0: AMIINT on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 10 entries at 0xc00f7d80 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci0: display, VGA at device 6.0 (no driver attached) pci0: network, ethernet at device 7.0 (no driver attached) sym0: 810a port 0xd800-0xd8ff mem 0xdbfeff00-0xdbfe irq 10 at device 8.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking atapci0: Promise ATA100 controller port 0xc400-0xc43f,0xc800-0xc803,0xcc00-0xcc07,0xd000-0xd003,0xd400-0xd407 mem 0xdbfc-0xdbfd irq 11 at device 12.0 on pci0 ata2: at 0xd400 on atapci0 ata3: at 0xcc00 on atapci0 isab0: PCI-ISA bridge at device 17.0 on pci0 isa0: ISA bus on isab0 atapci1: VIA 8233 ATA100 controller port 0xff00-0xff0f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata1: at 0x170 irq 15 on atapci1 uhci0: VIA 83C572 USB controller port 0xb800-0xb81f irq 10 at device 17.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 uhub0: port error, restarting port 2 uhci1: VIA 83C572 USB controller port 0xbc00-0xbc1f irq 10 at device 17.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub1: port error, restarting port 1 ugen0: Genesys Logic USB Host To Host Bridge, rev 1.00/1.80, addr 2 uhci2: VIA 83C572 USB controller port 0xc000-0xc01f irq 10 at device 17.4 on pci0 usb2: VIA 83C572 USB controller on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhub2: port error, restarting port 2 uhub2: port error, giving up port 2 acpi_button1: Sleep Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 fdc0: cmd 3 failed at out byte 1 of 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: Printer on ppbus0 lpt0: Interrupt-driven port fdc0: cmd 3 failed at out byte 1 of 3 orm0: Option ROMs at iomem 0xd1000-0xd3fff,0xc9000-0xd0fff,0xc8000-0xc8fff,0xc-0xc7fff on isa0 fdc0: cannot reserve I/O port range (6 ports) sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec IPsec: Initialized Security Association Processing. acpi_cpu: CPU throttling available, 16 steps from 100% to 6.2% ad0: 28629MB ST330621A [58168/16/63] at ata0-master UDMA100 ad1: 29312MB Maxtor 33073H3 [59556/16/63] at ata0-slave UDMA100 acd0: CD-RW PLEXTOR CD-R PX-W8432T at ata1-master PIO4 ar0: 78533MB ATA RAID0 array [10011/255/63] status: READY subdisks: 0 READY ad2: 39266MB IC35L040AVER07-0 [79780/16/63] at
Re: USB detach crashes possibly fixed
Fcc: outbox Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii and I got a small tune on attach but nothing on detach. Now I am unable to play notes on /dev/speaker. Any hint? As Terry notes, shouldn't possibly be related. I have no crashes but the detach action is never executed when I switch off my Sony camera ( it has never worked as far as I know) Attach actions are executed fine.. Have you tried compiling in all available USB debugging support or seeing if anyone else is using one like yours? No, but if I run usbd in the foreground and with some -v flags it never reports seeing a detach event even though the device driver reports it. It looks like usbd just doesn't get it... This is what the kernel logs when switching the camera on and off. Feb 17 11:57:44 kern.crit trantor kernel: umass0: Sony Sony DSC, rev 1.00/2.10, addr 2 Feb 17 11:57:44 kern.crit trantor kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Feb 17 11:57:44 kern.crit trantor kernel: da0: Sony Sony DSC 2.10 Removable Direct Access SCSI-0 device Feb 17 11:57:44 kern.crit trantor kernel: da0: 150KB/s transfers Feb 17 11:57:44 kern.crit trantor kernel: da0: 61MB (126848 512 byte sectors: 0H 0S/T 0C) Feb 17 11:58:04 kern.crit trantor kernel: umass0: at uhub0 port 1 (addr 2) disconnected Feb 17 11:58:04 kern.crit trantor kernel: (da0:umass-sim0:0:0:0): lost device Feb 17 11:58:04 kern.crit trantor kernel: umass0: detached Looks OK to me. And this is what usbd prints $ sudo usbd -d -v -v -v -v usbd: opened /dev/usb0 usbd: opened /dev/usb1 usbd: opened /dev/usb2 usbd: reading configuration file /etc/usbd.conf usbd: action 1: Sony DSC S70 Camera vndr=0x054c prdct=0x0010 attach='sleep 5 ;mount /sony' detach='umount -f /sony' usbd: action 2: USB device usbd: 2 actions usbd: opened /dev/usb usbd: device-attach event at 1013898654.50584, Sony DSC, Sony: vndr=0x054c prdct=0x0010 rlse=0x0210 clss=0x subclss=0x prtcl=0x device names: umass0 usbd: Found action 'Sony DSC S70 Camera' for Sony DSC, Sony at umass0 usbd: action 0: Sony DSC S70 Camera vndr=0x054c prdct=0x0010 attach='sleep 5 ;mount /sony' detach='umount -f /sony' usbd: Setting DEVNAME='umass0' usbd: Executing 'sleep 5 ;mount /sony' msdosfs: /dev/da0s1: No such file or directory usbd: 'sleep 5 ;mount /sony' returned 71 usbd: doing timeout discovery on /dev/usb0 usbd: doing timeout discovery on /dev/usb1 usbd: doing timeout discovery on /dev/usb2 usbd: processing event queue due to timeout on /dev/usb usbd: doing timeout discovery on /dev/usb0 usbd: doing timeout discovery on /dev/usb1 usbd: doing timeout discovery on /dev/usb2 usbd: processing event queue due to timeout on /dev/usb usbd: processing event queue on /dev/usb usbd: device-attach event at 1013943463.949946000, Sony DSC, Sony: vndr=0x054c prdct=0x0010 rlse=0x0210 clss=0x subclss=0x prtcl=0x device names: umass0 usbd: Found action 'Sony DSC S70 Camera' for Sony DSC, Sony at umass0 usbd: action 0: Sony DSC S70 Camera vndr=0x054c prdct=0x0010 attach='sleep 5 ;mount /sony' detach='umount -f /sony' usbd: Setting DEVNAME='umass0' usbd: Executing 'sleep 5 ;mount /sony' usbd: 'sleep 5 ;mount /sony' is ok usbd: doing timeout discovery on /dev/usb0 usbd: doing timeout discovery on /dev/usb1 usbd: doing timeout discovery on /dev/usb2 usbd: processing event queue due to timeout on /dev/usb usbd: doing timeout discovery on /dev/usb0 usbd: doing timeout discovery on /dev/usb1 usbd: doing timeout discovery on /dev/usb2 usbd: processing event queue due to timeout on /dev/usb usbd: doing timeout discovery on /dev/usb0 usbd: doing timeout discovery on /dev/usb1 usbd: doing timeout discovery on /dev/usb2 usbd: processing event queue due to timeout on /dev/usb ^C It looks like the driver works fine as far as I can tell, but usbd just doesn't see the detach event. -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB detach crashes possibly fixed
On 14-Feb-2002 (08:29:50/GMT) Brian Fundakowski Feldman wrote:
Please try this change (already committed to -CURRENT) and let me
know if crashes due to detaching USB devices specifically have been
eliminated.
I cvsupped on Feb 14, 20:21 CET (GMT+1, Italian time), recompiled
both world kernel (yes, runned mergemaster also :-) and messages
show that device attach and detach (before I got only attach)
...kernel: uscanner0: EPSON Perfection1240, rev 1.00/1.14, addr 2
...kernel: uscanner0: at uhub0 port 1 (addr 2) disconnected
...kernel: uscanner0: detached
_BUT_
I lost /dev/speaker. I don't know if this is related to patch but
with my previous installed build (a bit old, of December 11, 2001)
I have those lines on /etc/usbd.conf:
attach /bin/chmod 666 /dev/${DEVNAME} echo L16cce /dev/speaker
detach echo L16eec /dev/speaker
and I got a small tune on attach but nothing on detach.
Now I am unable to play notes on /dev/speaker. Any hint?
I have no crashes but the detach action is never executed when I switch off
my Sony camera ( it has never worked as far as I know)
Attach actions are executed fine..
Paul
--
Paul van der Zwan paulz @ trantor.xs4all.nl
I think I'll move to theory, everything works in theory...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
usdb missing detaches ???
I'm experimenting with my Sony DSC S70 and USB. I can get -current to mount the stick in the camera but it won't umount the filesystem on detach. When I run usbd with -d -v it looks like usbd not even receives the detach event. It give the following output: usbd: opened /dev/usb0 usbd: opened /dev/usb1 usbd: opened /dev/usb2 usbd: reading configuration file /etc/usbd.conf usbd: opened /dev/usb usbd: device-attach event at 1012737567.535227000, Sony DSC, Sony: vndr=0x054c prdct=0x0010 rlse=0x0210 clss=0x subclss=0x prtcl=0x device names: umass0 usbd: Found action 'Sony DSC S70 Camera' for Sony DSC, Sony at umass0 usbd: Executing 'sleep 5 ;mount /sony' usbd: device-attach event at 1012737599.54987, Sony DSC, Sony: vndr=0x054c prdct=0x0010 rlse=0x0210 clss=0x subclss=0x prtcl=0x device names: umass0 usbd: Found action 'Sony DSC S70 Camera' for Sony DSC, Sony at umass0 usbd: Executing 'sleep 5 ;mount /sony' msdosfs: /dev/da0s1: Device busy usbd: 'sleep 5 ;mount /sony' returned 71 The second attach happend when I switched the camera off and on again. Syslog shows the following: Feb 3 12:59:27 kern.crit trantor kernel: umass0: Sony Sony DSC, rev 1.00/2.10, addr 2 Feb 3 12:59:27 kern.crit trantor kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Feb 3 12:59:27 kern.crit trantor kernel: da0: Sony Sony DSC 2.10 Removable Direct Access SCSI-0 device Feb 3 12:59:27 kern.crit trantor kernel: da0: 150KB/s transfers Feb 3 12:59:27 kern.crit trantor kernel: da0: 61MB (126848 512 byte sectors: 0H 0S/T 0C) Feb 3 12:59:42 kern.crit trantor kernel: umass0: at uhub2 port 2 (addr 2) disconnected Feb 3 12:59:42 kern.crit trantor kernel: (da0:umass-sim0:0:0:0): lost device Feb 3 12:59:42 kern.crit trantor kernel: umass0: detached Feb 3 12:59:59 kern.crit trantor kernel: umass0: Sony Sony DSC, rev 1.00/2.10, addr 2 So it looks like the kernel sees the detach but usbd does not. /etc/usbd.conf has the following entry for the camera: device Sony DSC S70 Camera vendor 0x054c product 0x0010 attach sleep 5 ;mount /sony detach umount -f /sony BTW This is on -current compiled and installed yesterday. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df -l broken
Paul van der Zwan wrote: I noticed the -l option of the df command is broken. It is supposed to print df for local filesystems but on my system it prints nothing at all. I had a quick look at the code , as far as I can tell it uses sysctl to figure out the mounted filesystems but thinks all of them are non-local and ignores them. Using sysctl -a I could not find any entries which looked vaguely like describing a mount.. Paul Could you please test the attached patch ? I did it in a hurry but it may fix the problem. It looks ok to me, just the local mounts show up.. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
nfsclient and amd
It looks like using amd to mount remote hosts on /net will not cause the nfsclient.ko module to be loaded. This causes the mounts to fail. Maybe rc.network kan be changed to kldload the nfsclient.ko module if it is not built into the kernel, just like it does for the server module ?? Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
df -l broken
I noticed the -l option of the df command is broken. It is supposed to print df for local filesystems but on my system it prints nothing at all. I had a quick look at the code , as far as I can tell it uses sysctl to figure out the mounted filesystems but thinks all of them are non-local and ignores them. Using sysctl -a I could not find any entries which looked vaguely like describing a mount.. Paul -- I have discovered the art of deceiving diplomats. I tell them the truth and they never believe me. -- Camillo Di Cavour To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Multiple NFS server problems with Solaris 8 clients
In message [EMAIL PROTECTED], BSD User wrote: Actually, upon instrumenting some code, it looks like RELEASE-4.4 gets it mostly right. It ejects a PROG_UNAVAIL call which causes the Solaris 8 client to back off. The correct message would seem to be PROC_UNAVAIL, but I would take PROG_UNAVAIL if I could get -current to eject it. In this case ( the NFS_ACL one) it seems PROG_UNAVAIL is the right thing. It has a different program number from NFS and it is not just a not implemented procedure that is part of NFS. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Multiple NFS server problems with Solaris 8 clients
In message [EMAIL PROTECTED], Thomas Quinot wrote: Le 2001-10-14, Paul van der Zwan écrivait : I am using -current box as a homedir server for my Solaris clients and have noticed a wierd problem. Other problems here, with Solaris 2.[68] as clients, and -CURRENT of yesterday as server. ls works, but ls -l issues a 'NFS getacl failed' message *and* waits for a timeout once for each file in the directory. The server is not multi-homed, and a packet capture shows no trace of address mismatch problems. One interesting thing is that the client first does GETATTR on the file (and apparently gets a reply), and then sends some other RPC, to which the server never replies. Could this be the getacl request mentioned in the client error message? I see no mention of getacl whatsoever in the -CURRENT server code. If no such function is implemented, shouldn't we reject the request? A packet capture is available at http://www.infres.enst.fr/~quinot/nfs.cap Client is 137.194.192.1, server is 137.194.162.11. The test consists in first performing an 'ls' on one file, then an 'ls -l' on the same file. Result: ls photos-ta; ls -l photos-ta photos-ta NFS getacl failed for server shalmaneser.enst.fr: error 5 (RPC: Timed out) -rw--- 1 quinot astre474 Oct 18 14:17 photos-ta I have looked at a trace I made using snoop and it shows an NFS_ACL call which is not supported by FreeBSD. It should have sent a reply that it does not know the NFS_ACL protocol but apparently it does not. The only return traffic I see is an empty packet with the tcp ACK. It looks like an implementation error in the -current NFS server. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Multiple NFS server problems with Solaris 8 clients
I am using -current box as a homedir server for my Solaris clients and have noticed a wierd problem. When I login my homedir gets mounted ok but when I type ls -l it just waits until I ^C it. If I run snoop on Solaris I see a getattr request being sent and an answer being received but apparently it gets ignored by Solaris. This happens on both Sol x86 and Sparc ( both with MU5 installed) Another problem I see is that rebooting the client causes the server to ignore request afterwards. I see SYNS sent to the server but no respons at all... One more problem is in nfsd, if I set it to use udp only it starts eating all cpu cycles it can get,but only the master process. Trussing the proces shows no system calls whatsoever being performed. BTW This is -current built yesterday ( oct 13). Paul PS Snoop logs or tcpdump logs are avialable for those who know what to look for... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Parallel port back
My parallel port is back. Switching the it from 3BC to 378 made the probe recognize it again. Apparently the new code doesn't like the 3BC address as much as the old code.. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl "I think I'll move to theory, everything works in theory..." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Par. gone missing
I just notice my par. port is no longer detected. A kernel built on Jan 21st fails to detect my par. port which has worked fine so far. In /var/log/messages I get the following: Jan 27 22:29:53 kern.crit trantor /kernel: ppc0: parallel port found at 0x3bc Jan 27 22:29:53 kern.crit trantor /kernel: ppc0: cannot reserve I/O port range When doing a boot -v. An older kernel booted Jan 13th showed the following : Jan 13 21:08:47 kern.crit trantor /kernel: ppc0 at port 0x3bc-0x3c3 irq 7 on isa0 Jan 13 21:08:47 kern.crit trantor /kernel: isa_compat: didn't get ports for ppc Jan 13 21:08:47 kern.crit trantor /kernel: ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode Jan 13 21:08:47 kern.crit trantor /kernel: lpt0: generic printer on ppbus 0 Jan 13 21:08:47 kern.crit trantor /kernel: lpt0: Interrupt-driven port Rebooting the older kernel brings back my port so I doubt it's a hardware problem. Any hints on tracing the reason for it not being detected ?? Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl "I think I'll move to theory, everything works in theory..." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Parallel port gone missing (extra info)
In message [EMAIL PROTECTED], Paul van der Zwan wrote: I just notice my par. port is no longer detected. A kernel built on Jan 21st fails to detect my par. port which has worked fine so far. In /var/log/messages I get the following: Jan 27 22:29:53 kern.crit trantor /kernel: ppc0: parallel port found at 0x3bc Jan 27 22:29:53 kern.crit trantor /kernel: ppc0: cannot reserve I/O port range When doing a boot -v. An older kernel booted Jan 13th showed the following : Jan 13 21:08:47 kern.crit trantor /kernel: ppc0 at port 0x3bc-0x3c3 irq 7 on isa0 Jan 13 21:08:47 kern.crit trantor /kernel: isa_compat: didn't get ports for ppc Jan 13 21:08:47 kern.crit trantor /kernel: ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode Jan 13 21:08:47 kern.crit trantor /kernel: lpt0: generic printer on ppbus0 Jan 13 21:08:47 kern.crit trantor /kernel: lpt0: Interrupt-driven port Rebooting the older kernel brings back my port so I doubt it's a hardware problem. Any hints on tracing the reason for it not being detected ?? Some extra info , the MB is a Chaintech 5TDM2, changing biossettings from EPP to ECP/EPP does not help. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl "I think I'll move to theory, everything works in theory..." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ATAPI CD errors
I switched to the 'new' atapi driver and I am having trouble with my cdrom which worked fine using the old wd driver. I have the following in my config file : controller ata0 device atadisk0 device atapicd0 The device exists: $ ls -l /dev/acd0* brw-r- 1 root operator 31, 0 Oct 31 11:06 /dev/acd0a brw-r- 1 root operator 31, 2 Oct 31 11:06 /dev/acd0c Booting gives the following : ad0: QUANTUM FIREBALL SE4.3A/API.0C00 ATA-3 disk at ata0 as master ad0: 4110MB (8418816 sectors), 14848 cyls, 9 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 0 depth queue, UDMA33 Creating DISK ad0 Creating DISK wd0 atapi: MODE_SENSE_BIG - UNIT ATTENTION skey=6 asc=29 ascq=00 error=00 acd0: BCD 24XM CD-ROM/VER 2.2 CDROM drive at ata0 as slave acd0: read 171KB/s (4125KB/s), 128KB buffer, UDMA33 acd0: supported read types: CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked But when I try to mount the CD I get the following error : atapi: TEST_UNIT_READY - NOT READY skey=2 asc=3a ascq=00 error=00 atapi: READ_TOC - NOT READY skey=2 asc=3a ascq=00 error=00 Anybody any idea or hint ?? TIA Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl "I think I'll move to theory, everything works in theory..." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATAPI CD errors
In message [EMAIL PROTECTED], Paul van der Zwan wrote: I switched to the 'new' atapi driver and I am having trouble with my cdrom which worked fine using the old wd driver. I have the following in my config file : controller ata0 device atadisk0 device atapicd0 The device exists: $ ls -l /dev/acd0* brw-r- 1 root operator 31, 0 Oct 31 11:06 /dev/acd0a brw-r- 1 root operator 31, 2 Oct 31 11:06 /dev/acd0c Booting gives the following : ad0: QUANTUM FIREBALL SE4.3A/API.0C00 ATA-3 disk at ata0 as master ad0: 4110MB (8418816 sectors), 14848 cyls, 9 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 0 depth queue, UDMA33 Creating DISK ad0 Creating DISK wd0 atapi: MODE_SENSE_BIG - UNIT ATTENTION skey=6 asc=29 ascq=00 error=00 acd0: BCD 24XM CD-ROM/VER 2.2 CDROM drive at ata0 as slave acd0: read 171KB/s (4125KB/s), 128KB buffer, UDMA33 acd0: supported read types: CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked But when I try to mount the CD I get the following error : atapi: TEST_UNIT_READY - NOT READY skey=2 asc=3a ascq=00 error=00 atapi: READ_TOC - NOT READY skey=2 asc=3a ascq=00 error=00 Anybody any idea or hint ?? I hate to followup on my own messages , but I made a 'small' error. The message above was cause by an empty drive ( wrong PC ;-() The real message I get is : $ sudo mount /cdrom cd9660: Operation not permitted And dmesg gives the following: atapi: PREVENT_ALLOW - UNIT ATTENTION skey=6 asc=28 ascq=00 error=08 atapi: READ_BIG - NO SENSE skey=0 asc=00 ascq=00 error=01 atapi: READ_BIG - NO SENSE skey=0 asc=00 ascq=00 error=01 atapi: READ_BIG - NO SENSE skey=0 asc=00 ascq=00 error=01 atapi: READ_BIG - NO SENSE skey=0 asc=00 ascq=00 error=01 BTW this is on a -current cvsupped and built last night. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl "I think I'll move to theory, everything works in theory..." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATAPI CD errors
In message [EMAIL PROTECTED], Brian Fun dakowski Feldman wrote: Have you either tried disabling DMA on the drive? This is easily achieved by the following (whitespace mangled): --- atapi-all.c 1999/10/10 18:08:38 1.19 +++ atapi-all.c 1999/10/23 16:51:12 @@ -135,7 +135,8 @@ udmamode(atp-atapi_parm), atp-atapi_parm-dmaflag); - if (!(atp-atapi_parm-drqtype == ATAPI_DRQT_INTR) + if (atp-atapi_parm-device_type != ATAPI_TYPE_CDROM + !(atp-atapi_parm-drqtype == ATAPI_DRQT_INTR) !ata_dmainit(atp-controller, atp-unit, (apiomode(atp-atapi_parm) 0) ? (atp-atapi_parm-dmaflag ? 4 : 0) : This patch allows me to mount the cdrom... The probes show PIO mode i.s.o. DMA. So it looks like DMA is broken for this drive.. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl "I think I'll move to theory, everything works in theory..." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sio.c breaks kernel ( even GENERIC)
I haven't been able to get a kernel built because of some undefined references in sio.o. Even GENERIC is broken. (cvsupped just a few minutes ago ) loading kernel sio.o: In function `siocnprobe': sio.o(.text+0x286e): undefined reference to `gdbdev' sio.o(.text+0x2874): undefined reference to `gdb_getc' sio.o(.text+0x287e): undefined reference to `gdb_putc' sio.o(.text+0x2895): undefined reference to `gdbdev' sio.o(.text+0x28c9): undefined reference to `gdbdev' sio.o(.text+0x28cf): undefined reference to `gdb_getc' sio.o(.text+0x28d9): undefined reference to `gdb_putc' *** Error code 1 Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
CPP broken on egcs current
A make buildworld fails on an freshly rebuilt system. The following error is shown: -- Rebuilding /usr/include -- cd /usr/source/src; SHARED=copies PATH=/usr/obj/usr/source/src/tmp/sbin:/usr/obj /usr/source/src/tmp/usr/sbin:/usr/obj/usr/source/src/tmp/bin:/usr/obj/usr/source /src/tmp/usr/bin:/home/paulz/bin:/home/paulz/bin/trantor.xs4all.nl:/usr/local/bi n:/usr/local/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/games:/sbin:/bin:/usr/l ocal/jdk1.1.7/bin:/usr/local/pilot/bin:/usr/local/pgsql/bin BISON_SIMPLE=/usr/ob j/usr/source/src/tmp/usr/share/misc/bison.simple COMPILER_PATH=/usr/obj/usr/sou rce/src/tmp/usr/libexec:/usr/obj/usr/source/src/tmp/usr/bin GCC_EXEC_PREFIX=/us r/obj/usr/source/src/tmp/usr/lib:/usr/obj/usr/source/src/tmp/usr/lib/ LD_LIBRAR Y_PATH=/usr/obj/usr/source/src/tmp/usr/lib LIBRARY_PATH=/usr/obj/usr/source/src /tmp/usr/lib:/usr/obj/usr/source/src/tmp/usr/lib NOEXTRADEPEND=t OBJFORMAT_PATH =/usr/obj/usr/source/src/tmp/usr/libexec:/usr/libexec /usr/obj/usr/source/src/tm p/usr/bin/make DESTDIR=/usr/obj/usr/source/src/tmp -f Makefile.inc1 includes cd /usr/source/src/include; /usr/obj/usr/source/src/tmp/usr/ bin/make -B all install creating osreldate.h from newvers.sh setvar PARAMFILE /usr/source/src/include/../sys/sys/param.h; . /usr/source/src/ include/../sys/conf/newvers.sh; echo $COPYRIGHT osreldate.h ;echo \#'undef __FreeBSD_version' osreldate.h; echo \#'define __FreeBSD_version' $RELDATE osreldate.h === rpcsvc rpcgen -C -h -DWANT_NFS3 /usr/source/src/include/rpcsvc/key_prot.x -o key_prot.h /usr/source/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:1882: Int ernal compiler error in function main *** Error code 33 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. I get the same internal error when xrdb tries to run my .Xresources file thru CPP so does xdm trying the run Xresources thru cpp.. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
cpp breakage on egcs -current
I just found that just calling /usr/libexec/cpp -traditional causes it to abort with the following error: /usr/source/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:1882: Internal compiler error in function main This breaks rpcgen thus breaking make buildworld in my box . In addition xdm and xdrb also suffer .. This is on a system on which I ran a succesfull make world last night. The kernel is also built using egcs. This is the only problem I have found so far. The CFLAGS for make world were -O2 -pipe, for the kernel -O -pipe. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CPP broken on egcs current
In article 199904051112.naa22...@trantor.xs4all.nl, Paul van der Zwan pa...@trantor.xs4all.nl wrote: A make buildworld fails on an freshly rebuilt system. The following error is shown: ... /usr/source/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:1882: Int ernal compiler error in function main *** Error code 33 Your installed cpp was built from slightly old sources. Make sure your source tree is up-to-date. Then manually make cleandir; make cleandir; make obj; make depend; make all install in src/gnu/usr.bin/cc. It will be OK after that. That seems to fix it.. Thanks. BTW why the double make cleandir ?? a typo ? or is there some magic. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Slow seq. write on Seagate ST36530N
Paul van der Zwan wrote... I am having some performance problems on my -current ( update last weekend) I hooked up a new Seagate ST36530N yesterday ( connected to an Adaptec 2940U) Andreas Klemm has had similar trouble, as he pointed out. Can you check and see whether or not you have write caching turned on for your disk? I have seen problems with sequential writes that appear to be caused by conflicts between FreeBSD's caching policy and disk caching policies. These problems often go away when you disable write caching on a disk. The Write Cache Enable (WCE) bit is in mode page 8. To check it: camcontrol modepage -n da -u 1 -v -m 8 To edit the mode page: camcontrol modepage -n da -u 1 -v -m 8 -e Let me know whether that affects the problem at all. This did not improve anything , but I think I have found the couse. In that modepage there is a DISC value which was 0 on the IBM and 1 on the Seagate. I remembered a ' Enable disconnect' option in the Adaptec 2940 bios, setting this to 'off' for both harddisks led to a huge performance increase on the Seagate. If I also enable Ultra mode iozone write goes from 1.5 MB/s to 12 MB/s ( a factor of 8 !!!). Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Slow seq. write on Seagate ST36530N
This did not improve anything , but I think I have found the couse. In that modepage there is a DISC value which was 0 on the IBM and 1 on the Seagate. I remembered a ' Enable disconnect' option in the Adaptec 2940 bios, setting this to 'off' for both harddisks led to a huge performance increase on the Seagate. If I also enable Ultra mode iozone write goes from 1.5 MB/s to 12 MB/s ( a factor of 8 !!!). The 'DISC' bit in mode page 8 has nothing to do with disconnection. Here's the description of it from the SCSI-3 spec: The discontinuity (DISC) bit, when one, requests that the device server continue the pre-fetch across time discontinuities, such as across cylinders (or tracks in an embedded servo device), up to the limits of the buffer, or segment, space available for the pre-fetch. When zero, the DISC requests that pre-fetches be truncated (or wrapped) at time discontinuities. I did not change it but it triggered me to have a look at the Adaptec BIOS settings. I have done some testing and reenabled disconnection, preformance dropped to less than 2MB/s writing. After searching the freebsd-scsi archives I found out it might be related to tagging, so I edited /usr/src/sys/cam/cam_xpt.c and added an entry to disallow tagging for this drive. Back to 12 MB/s. So it looks like there is at least an acceptable ( to me ) workaround. Maybe the CAM maintainer can put an entry in cam_xpt.c for this drive ??? dmgs shows is as : da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST36530N 1444 Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (20.000MHz, offset 15) da1: 6208MB (12715920 512 byte sectors: 255H 63S/T 791C) Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Slow seq. write on Seagate ST36530N
I am having some performance problems on my -current ( update last weekend) I hooked up a new Seagate ST36530N yesterday ( connected to an Adaptec 2940U) and sequential write is very slow. Compared to an IBM DORS-32160 connected to the same controller ( even the same cable) it is half as fast. Iozone auto shows the following : Seagate IOZONE: Performance Test of Sequential File I/O -- V2.01 (10/21/94) By Bill Norcott Operating System: FreeBSD 2.x -- using fsync() IOZONE: auto-test mode MB reclen bytes/sec written bytes/sec read 1 512 5835553 22369621 1 10243627506 33554432 1 20483441480 44739242 1 40964329604 44739242 1 81923121342 67108864 2 512 3627506 22369621 2 10244260880 44739242 2 20483273603 38347922 2 40964067203 67108864 2 81924067203 67108864 4 512 4161790 21474836 4 10242354696 35791394 4 20482418337 38347922 4 40962418337 59652323 4 81921988410 53687091 8 512 2863311 20259279 8 10241565221 37025580 8 20481470879 31580641 8 40961514445 48806446 8 81921337162 56512727 16 512 2041334 14412641 16 10241536111 27531841 16 20481476948 43826196 16 40961410961 48806446 16 81921432610 52377649 IBM MB reclen bytes/sec written bytes/sec read 1 512 3728270 22369621 1 10244067203 26843545 1 20483947580 67108864 1 40963728270 44739242 1 81923834792 67108864 2 512 4549753 13421772 2 10244194304 44739242 2 20483890368 53687091 2 40964400581 67108864 2 81923677198 67108864 4 512 4129776 21474836 4 10243532045 44739242 4 20482451465 53687091 4 40963016128 59652323 4 81922870967 53687091 8 512 2396745 21053761 8 10242894182 37025580 8 20482587329 42949672 8 40962526451 51130563 8 81922520520 56512727 16 512 3067833 20069940 16 10242701237 34087042 16 20483591109 43826196 16 40962306641 42949672 16 81923121342 52377649 Bonnie shows the following: Seagate ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 3251 44.0 1307 4.0 2285 11.5 5006 69.0 8644 23.0 115.1 4.2 IBM 100 45.0 2533 8.8 1878 10.1 4244 58.2 5140 19.7 76.4 3.3 If I interpret it correctly the Seagate is faster in everything but sequential writes. dmesg shows the following : da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST36530N 1444 Fixed Direct Access SCSI-2 device da1: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled da1: 6208MB (12715920 512 byte sectors: 255H 63S/T 791C) da0 at ahc0 bus 0 target 0 lun 0 da0: IBM DORS-32160 S82C Fixed Direct Access SCSI-2 device da0: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) Anybody an idea ?? Paul -- Paul van der Zwan paulz
