Hi, when using a freshly built -CURRENT kernel (acpi enabled) the transfer mode of my hard disk is set to PIO4 during system init (ad0: 38154MB <IC25N040ATMR04-0> [77520/16/63] at ata0-master PIO4), whereas with a kernel from 28th of May (acpi enabled) it is recognized corretly and set to UDMA100 (ad0: 38154MB <IC25N040ATMR04-0> [77520/16/63] at ata0-master UDMA100). My system's performance is very poor when the disk works in PIO mode, so I'm using my older kernel for now. My ata controller: atapci0_at_pci0:16:0: class=0x0101b0 card=0x0024103c chip=0x522910b9 rev=0xc4 hdr=0x00 vendor = 'Acer Labs Incorporated (ALi)' device = 'M1543 Southbridge EIDE Controller' class = mass storage subclass = ATA I haven't changed anything in my kernel config file since this last working kernel. Also, when I boot my recent kernel with acpi disabled, the transfer rate is being correctly set to UDMA100. When I boot with acpi enabled and try to change the transfer mode manually: # atacontrol mode 0 udma100 xxx Master = UDMA100 Slave = BIOSPIO the transfer mode is changed, but I get a kernel panic (fatal trap 12) immediately after that. I wanted to capture a core dump to later on use it with gdb, but I'm unable to produce one. I did everything according to developer's handbook but it's not working: # grep dump /etc/rc.conf dumpdev="/dev/ad0s1b" dumpdir="/usr/crash" # swapctl -l Device: 1024-blocks Used: /dev/ad0s1b 1048576 0 # sysctl kern | grep dump kern.sugid_coredump: 0 kern.coredump: 1 One interesting thing is that there's no such oid as kern.dumpdev (sysctl: unknown oid 'kern.dumpdev') and according to man sysctl there should be one. I'll probably take a photo of the output of the trace command in ddb when I get home if I can't get a crash dump. Should I provide more info about my system? Thanks for any help. -RadekReceived on Fri Jun 18 2004 - 16:46:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:57 UTC