Happy birthday.
Just saw it and have seen nothing yet, and having reread GDBE paper from BSDCON 2003 today: happy birthday FreeBSD! You seem to have reached the age of Janis Joplin, Jim Morrison and Jimmi (Hendrix)! That makes optimistical. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r259072 is not a happy camper...
On Wednesday, December 18, 2013 5:45:57 pm Poul-Henning Kamp wrote: > In message <201312181458.20649@freebsd.org>, John Baldwin writes: > > >> >Does it get a crashdump if you try? > >> > >> No :-( > >> > >> There may be a connection to unclean UFS filesystems (SU + TRIM, no J). > > > >Is this reproducible? > > Not really. > > It seems to happen at random, usually shortly after boot and as I > mentioned, there is some indications of it being related to munged > filesystems. > > Amongst these indications: > > Booting single-user and running fsck (without -p) almost always > prevents it from happening until after next crash, and I think all > the backtraces I've see have been UFS or maybe even WITNESS+UFS > related. > > If it is WITNESS related, the serial console is obviously a > prime suspect... > > But all that said, I havn't seen it for a couple of days... Humm. I'm kind of out of ideas then. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r259072 is not a happy camper...
In message <201312181458.20649@freebsd.org>, John Baldwin writes: >> >Does it get a crashdump if you try? >> >> No :-( >> >> There may be a connection to unclean UFS filesystems (SU + TRIM, no J). > >Is this reproducible? Not really. It seems to happen at random, usually shortly after boot and as I mentioned, there is some indications of it being related to munged filesystems. Amongst these indications: Booting single-user and running fsck (without -p) almost always prevents it from happening until after next crash, and I think all the backtraces I've see have been UFS or maybe even WITNESS+UFS related. If it is WITNESS related, the serial console is obviously a prime suspect... But all that said, I havn't seen it for a couple of days... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r259072 is not a happy camper...
On Saturday, December 14, 2013 3:44:39 am Poul-Henning Kamp wrote: > In message <201312131620.25107@freebsd.org>, John Baldwin writes: > > >> >Hmmm. Maybe do 'show lapic' and 'show apic' in ddb and paste that here? > >> > >> sorry about the delay... > >> > >> db> show lapic > >> lapic ID = 2 > >> version = 1.0 > >> max LVT = 5 > >> SVR = ff (enabled) > >> TPR = 00 > >> In-service Interrupts: > > > >Hmm, this is empty. It should not be empty. :( > > > >Never the less, the panic is further down than I thought it was. The system > >thinks it had a valid IRQ that required an ithread to be scheduled, but when > >it went to schedule the ithread, there was no thread to schedule: > > >Does it get a crashdump if you try? > > No :-( > > There may be a connection to unclean UFS filesystems (SU + TRIM, no J). Is this reproducible? If so, build with KTR enabled and KTR_INTR set in KTR_COMPILE and KTR_MASK. That should at least let us see which interrupt it thinks it is triggering. 'show irqs' from DDB combined with 'show ktr' would then be useful. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r259072 is not a happy camper...
In message <201312131620.25107@freebsd.org>, John Baldwin writes: >> >Hmmm. Maybe do 'show lapic' and 'show apic' in ddb and paste that here? >> >> sorry about the delay... >> >> db> show lapic >> lapic ID = 2 >> version = 1.0 >> max LVT = 5 >> SVR = ff (enabled) >> TPR = 00 >> In-service Interrupts: > >Hmm, this is empty. It should not be empty. :( > >Never the less, the panic is further down than I thought it was. The system >thinks it had a valid IRQ that required an ithread to be scheduled, but when >it went to schedule the ithread, there was no thread to schedule: >Does it get a crashdump if you try? No :-( There may be a connection to unclean UFS filesystems (SU + TRIM, no J). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r259072 is not a happy camper...
On Friday, December 13, 2013 3:36:37 pm Poul-Henning Kamp wrote:
> In message <201312091216.04052@freebsd.org>, John Baldwin writes:
> >On Saturday, December 07, 2013 2:32:56 pm Poul-Henning Kamp wrote:
> >>
> >> kdb_backtrace() at kdb_backtrace+0x39/frampanic: bad stray interrupt
> >> cpuid = 2
> >> KDB: stack backtrace:
> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe011120e9e0
> >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe011120ea90
> >> vpanic() at vpanic+0x126/frame 0xfe011120ead0
> >> kassert_panic() at kassert_panic+0x136/frame 0xfe011120eb40
> >> intr_event_handle() at intr_event_handle+0x11d/frame 0xfe011120eb90
> >> intr_execute_handlers() at intr_execute_handlers+0x48/frame
0xfe011120ebc0
> >> lapic_handle_intr() at lapic_handle_intr+0x73/frame 0xfe011120ebf0
> >> Xapic_isr1() at Xapic_isr1+0xa4/frame 0xfe011120ebf0
> >> --- interrupt, rip = 0x11f7b11, rsp = 0x7fff8b50, rbp =
0x7fff8b80 ---
> >> KDB: enter: panic
> >> [ thread pid 72149 tid 100102 ]
> >> Stopped at kdb_enter+0x3e: movq$0,kdb_why
> >> db>
> >
> >Hmmm. Maybe do 'show lapic' and 'show apic' in ddb and paste that here?
>
> sorry about the delay...
>
> db> show lapic
> lapic ID = 2
> version = 1.0
> max LVT = 5
> SVR = ff (enabled)
> TPR = 00
> In-service Interrupts:
Hmm, this is empty. It should not be empty. :(
Never the less, the panic is further down than I thought it was. The system
thinks it had a valid IRQ that required an ithread to be scheduled, but when
it went to schedule the ithread, there was no thread to schedule:
static int
intr_event_schedule_thread(struct intr_event *ie)
{
struct intr_entropy entropy;
struct intr_thread *it;
struct thread *td;
struct thread *ctd;
struct proc *p;
/*
* If no ithread or no handlers, then we have a stray interrupt.
*/
if (ie == NULL || TAILQ_EMPTY(&ie->ie_handlers) ||
ie->ie_thread == NULL)
return (EINVAL);
Does it get a crashdump if you try?
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r259072 is not a happy camper...
In message <201312091216.04052@freebsd.org>, John Baldwin writes: >On Saturday, December 07, 2013 2:32:56 pm Poul-Henning Kamp wrote: >> >> kdb_backtrace() at kdb_backtrace+0x39/frampanic: bad stray interrupt >> cpuid = 2 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfe011120e9e0 >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe011120ea90 >> vpanic() at vpanic+0x126/frame 0xfe011120ead0 >> kassert_panic() at kassert_panic+0x136/frame 0xfe011120eb40 >> intr_event_handle() at intr_event_handle+0x11d/frame 0xfe011120eb90 >> intr_execute_handlers() at intr_execute_handlers+0x48/frame >> 0xfe011120ebc0 >> lapic_handle_intr() at lapic_handle_intr+0x73/frame 0xfe011120ebf0 >> Xapic_isr1() at Xapic_isr1+0xa4/frame 0xfe011120ebf0 >> --- interrupt, rip = 0x11f7b11, rsp = 0x7fff8b50, rbp = 0x7fff8b80 >> --- >> KDB: enter: panic >> [ thread pid 72149 tid 100102 ] >> Stopped at kdb_enter+0x3e: movq$0,kdb_why >> db> > >Hmmm. Maybe do 'show lapic' and 'show apic' in ddb and paste that here? sorry about the delay... db> show lapic lapic ID = 2 version = 1.0 max LVT = 5 SVR = ff (enabled) TPR = 00 In-service Interrupts: TMR Interrupts: IRR Interrupts: irr1: 30 irr7: f9 db> show apic Interrupts bound to lapic 0 vec 0x31 -> IRQ 0 vec 0x32 -> IRQ 8 vec 0x33 -> IRQ 256 vec 0x34 -> IRQ 257 vec 0x35 -> IRQ 258 vec 0x36 -> IRQ 259 vec 0x3b -> IRQ 264 vec 0x40 -> IRQ 269 vec 0x42 -> IRQ 16 vec 0x48 -> IRQ 21 vec 0x4a -> IRQ 7 vec 0xef -> lapic timer Interrupts bound to lapic 1 vec 0x30 -> IRQ 1 vec 0x31 -> IRQ 9 vec 0x32 -> IRQ 17 vec 0x33 -> IRQ 22 vec 0x34 -> IRQ 260 vec 0x35 -> IRQ 265 vec 0xef -> lapic timer Interrupts bound to lapic 2 vec 0x30 -> IRQ 4 vec 0x31 -> IRQ 14 vec 0x32 -> IRQ 18 vec 0x33 -> IRQ 261 vec 0x34 -> IRQ 263 vec 0x35 -> IRQ 266 vec 0xef -> lapic timer Interrupts bound to lapic 3 vec 0x30 -> IRQ 6 vec 0x31 -> IRQ 15 vec 0x32 -> IRQ 19 vec 0x33 -> IRQ 262 vec 0x34 -> IRQ 267 vec 0x35 -> IRQ 268 vec 0xef -> lapic timer -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r259072 is not a happy camper...
On Saturday, December 07, 2013 2:32:56 pm Poul-Henning Kamp wrote: > > I updated my "canary" machine to -current today and it's not a happy > camper. Trying to run a buildworld on it I get the follwing reproducible > panic: > > FreeBSD/amd64 (ni.freebsd.dk) (cuau0) > > login: lock order reversal: > 1st 0xf8011641a9a0 ufs (ufs) @ /freebsd/head/sys/kern/vfs_lookup.c:518 > 2nd 0xfe00e7858790 bufwait (bufwait) @ > /freebsd/head/sys/ufs/ffs/ffs_vnops > .c:262 > 3rd 0xf800b40ad5f0 ufs (ufs) @ /freebsd/head/sys/kern/vfs_subr.c:2101 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0111361da0 > kdb_backtrace() at kdb_backtrace+0x39/frampanic: bad stray interrupt > cpuid = 2 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe011120e9e0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe011120ea90 > vpanic() at vpanic+0x126/frame 0xfe011120ead0 > kassert_panic() at kassert_panic+0x136/frame 0xfe011120eb40 > intr_event_handle() at intr_event_handle+0x11d/frame 0xfe011120eb90 > intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfe011120ebc0 > lapic_handle_intr() at lapic_handle_intr+0x73/frame 0xfe011120ebf0 > Xapic_isr1() at Xapic_isr1+0xa4/frame 0xfe011120ebf0 > --- interrupt, rip = 0x11f7b11, rsp = 0x7fff8b50, rbp = 0x7fff8b80 --- > KDB: enter: panic > [ thread pid 72149 tid 100102 ] > Stopped at kdb_enter+0x3e: movq$0,kdb_why > db> Hmmm. Maybe do 'show lapic' and 'show apic' in ddb and paste that here? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r259072 is not a happy camper...
I updated my "canary" machine to -current today and it's not a happy camper. Trying to run a buildworld on it I get the follwing reproducible panic: FreeBSD/amd64 (ni.freebsd.dk) (cuau0) login: lock order reversal: 1st 0xf8011641a9a0 ufs (ufs) @ /freebsd/head/sys/kern/vfs_lookup.c:518 2nd 0xfe00e7858790 bufwait (bufwait) @ /freebsd/head/sys/ufs/ffs/ffs_vnops .c:262 3rd 0xf800b40ad5f0 ufs (ufs) @ /freebsd/head/sys/kern/vfs_subr.c:2101 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0111361da0 kdb_backtrace() at kdb_backtrace+0x39/frampanic: bad stray interrupt cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe011120e9e0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe011120ea90 vpanic() at vpanic+0x126/frame 0xfe011120ead0 kassert_panic() at kassert_panic+0x136/frame 0xfe011120eb40 intr_event_handle() at intr_event_handle+0x11d/frame 0xfe011120eb90 intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfe011120ebc0 lapic_handle_intr() at lapic_handle_intr+0x73/frame 0xfe011120ebf0 Xapic_isr1() at Xapic_isr1+0xa4/frame 0xfe011120ebf0 --- interrupt, rip = 0x11f7b11, rsp = 0x7fff8b50, rbp = 0x7fff8b80 --- KDB: enter: panic [ thread pid 72149 tid 100102 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why db> -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: amd64/SMP(/ata-raid ?) not happy...
On Sun, 30 Nov 2003, Poul-Henning Kamp wrote:
>
> Timecounters tick every 10.000 msec
> GEOM: create disk ad0 dp=0xff00eebfaca0
> ad0: 35772MB [72680/16/63] at ata0-master UDMA66
> GEOM: create disk ad4 dp=0xff00eebfa4a0
> ad4: 35304MB [71730/16/63] at ata2-master UDMA133
> GEOM: create disk ad6 dp=0xff00eebfa0a0
> ad6: 35304MB [71730/16/63] at ata3-master UDMA133
> GEOM: create disk ad8 dp=0xff00014c4ea0
> ad8: 35304MB [71730/16/63] at ata4-master UDMA133
> GEOM: create disk ar0 dp=0xff00f04a3270
> ar0: 105913MB [13502/255/63] status: READY subdisks:
> disk0 READY on ad4 at ata2-master
> disk1 READY on ad6 at ata3-master
> disk2 READY on ad8 at ata4-master
> SMP: AP CPU #1 Launched!
> panic: mtx_lock() of spin mutex (null) @ ../../../vm/uma_core.c:1716
I mailed re about this. There has been some disagreement over how
mp_maxid is implemented on all architectures. Until this gets resolved
and stamped as approved by re, please as mp_maxid++; at line 187 of
amd64/amd64/mp_machdep.c
Thanks,
Jeff
> cpuid = 1;
> Stack backtrace:
> backtrace() at backtrace+0x17
> panic() at panic+0x1d2
> _mtx_lock_flags() at _mtx_lock_flags+0x4f
> uma_zfree_arg() at uma_zfree_arg+0x7e
> g_destroy_bio() at g_destroy_bio+0x1b
> g_disk_done() at g_disk_done+0x85
> biodone() at biodone+0x66
> ad_done() at ad_done+0x31
> ata_completed() at ata_completed+0x237
> taskqueue_run() at taskqueue_run+0x88
> taskqueue_swi_run() at taskqueue_swi_run+0x10
> ithread_loop() at ithread_loop+0x189
> fork_exit() at fork_exit+0xbd
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xad5b0d30, rbp = 0 ---
> Debugger("panic")
> Stopped at Debugger+0x4c: xchgl %ebx,0x2caefe
> db>
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
amd64/SMP(/ata-raid ?) not happy...
Timecounters tick every 10.000 msec
GEOM: create disk ad0 dp=0xff00eebfaca0
ad0: 35772MB [72680/16/63] at ata0-master UDMA66
GEOM: create disk ad4 dp=0xff00eebfa4a0
ad4: 35304MB [71730/16/63] at ata2-master UDMA133
GEOM: create disk ad6 dp=0xff00eebfa0a0
ad6: 35304MB [71730/16/63] at ata3-master UDMA133
GEOM: create disk ad8 dp=0xff00014c4ea0
ad8: 35304MB [71730/16/63] at ata4-master UDMA133
GEOM: create disk ar0 dp=0xff00f04a3270
ar0: 105913MB [13502/255/63] status: READY subdisks:
disk0 READY on ad4 at ata2-master
disk1 READY on ad6 at ata3-master
disk2 READY on ad8 at ata4-master
SMP: AP CPU #1 Launched!
panic: mtx_lock() of spin mutex (null) @ ../../../vm/uma_core.c:1716
cpuid = 1;
Stack backtrace:
backtrace() at backtrace+0x17
panic() at panic+0x1d2
_mtx_lock_flags() at _mtx_lock_flags+0x4f
uma_zfree_arg() at uma_zfree_arg+0x7e
g_destroy_bio() at g_destroy_bio+0x1b
g_disk_done() at g_disk_done+0x85
biodone() at biodone+0x66
ad_done() at ad_done+0x31
ata_completed() at ata_completed+0x237
taskqueue_run() at taskqueue_run+0x88
taskqueue_swi_run() at taskqueue_swi_run+0x10
ithread_loop() at ithread_loop+0x189
fork_exit() at fork_exit+0xbd
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xad5b0d30, rbp = 0 ---
Debugger("panic")
Stopped at Debugger+0x4c: xchgl %ebx,0x2caefe
db>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Current::LINT not happy about Ipfilter
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -W missing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -an si -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica - I../../../contrib/ipfilter -I../../../../include -DGPROF -DGPROF4 -DGUPROF -D_KE RNEL -ffreestanding -include opt_global.h -fno-common -elf -malign-functions=4 - fno-builtin -mpreferred-stack-boundary=2 -Werror -pg -mprofiler-epilogue ../../. ./contrib/ipfilter/netinet/ip_fil.c ../../../contrib/ipfilter/netinet/ip_fil.c: In function `iplattach': ../../../contrib/ipfilter/netinet/ip_fil.c:412: `inet6sw' undeclared (first use in this function) ../../../contrib/ipfilter/netinet/ip_fil.c:412: (Each undeclared identifier is r eported only once ../../../contrib/ipfilter/netinet/ip_fil.c:412: for each function it appears in. ) ../../../contrib/ipfilter/netinet/ip_fil.c:412: `ip6_protox' undeclared (first u se in this function) ../../../contrib/ipfilter/netinet/ip_fil.c: In function `ipldetach': ../../../contrib/ipfilter/netinet/ip_fil.c:562: `inet6sw' undeclared (first use in this function) ../../../contrib/ipfilter/netinet/ip_fil.c:562: `ip6_protox' undeclared (first u se in this function) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Merry Christmas and Happy New Year
Hi, I know, this is not the right place, but my best wishes to the whole freebsd community for doing such a great job. To all of you *** merry christmas and happy new year *** regards, -- Jean Louis Ntakpe Texas Instruments - Freising <[EMAIL PROTECTED]> Wafer Fab Automation Group <[EMAIL PROTECTED]> Haggerty Str. 1 85350 Freising Telefon +49 (8161) 80-3816 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
happy!!
[NX}XI ¢ë`ñÈíÞÌGb`ªWª¯³êÄA ³¿Å©êéæB http://216.101.214.74/omankoheaven/ ·²[¢¾©çÉÈÉÅà©ÄÝÄËB ½Ü± To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
happy!!
[NX}XI ¢ë`ñÈíÞÌGb`ªWª¯³êÄA ³¿Å©êéæB http://216.101.214.74/omankoheaven/ ·²[¢¾©çÉÈÉÅà©ÄÝÄËB ½Ü± To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIC SD-11 not happy with ata
It seems Russell L. Carter wrote: > > Yah... as before ok I fixed this by swapping in an ASUS K7M (forget the audio, > I can't figure that one out) Working on it :) > For all of the bitching on Soren's ata driver, I'd like to > make this observation on a 500MHz/256MB ASUS K7 systemm, bonnie -s 500: > > ad1: 19574MB [39770/16/63] at ata1-master using UDMA66 > > Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... > ---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 %CU > 500 20650 84.1 20805 30.8 5644 14.8 22111 86.2 21253 21.1 148.9 1.4 > > Um, that ad1 drive cost me $224US, direct from the IBM mothership. Yup, those new IBM drives (the DPTA series) are pretty cool -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIC SD-11 not happy with ata
%> %It seems Russell L. Carter wrote: %> %> %It seems Russell L. Carter wrote: %> %> %> %> %> %> I swapped out my motherboard and am seeing this now: %... % %> %> )(*&$#%$# stupid magazine benchmarkers never actually test %> things like IO... gr % %We in the computer hardware business have a better name for ``FIC'', %Fix It Continuously. They are not known for their quality, or should %I say they are known for their lack of quality :-). Yah... as before ok I fixed this by swapping in an ASUS K7M (forget the audio, I can't figure that one out) For all of the bitching on Soren's ata driver, I'd like to make this observation on a 500MHz/256MB ASUS K7 systemm, bonnie -s 500: ad0: 13783MB [28005/16/63] at ata0-master using UDMA33 Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... ---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 500 8273 27.7 7734 8.4 3009 7.6 8549 31.8 8828 7.2 134.6 1.3 ad1: 19574MB [39770/16/63] at ata1-master using UDMA66 Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... ---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 500 20650 84.1 20805 30.8 5644 14.8 22111 86.2 21253 21.1 148.9 1.4 Um, that ad1 drive cost me $224US, direct from the IBM mothership. Best regards, Russell %-- %Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] % % %To Unsubscribe: send mail to [EMAIL PROTECTED] %with "unsubscribe freebsd-current" in the body of the message % To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIC SD-11 not happy with ata
> %> %It seems Russell L. Carter wrote: > %> %> %It seems Russell L. Carter wrote: > %> %> %> > %> %> %> I swapped out my motherboard and am seeing this now: > %... > % > %> > %> )(*&$#%$# stupid magazine benchmarkers never actually test > %> things like IO... gr > % > %We in the computer hardware business have a better name for ``FIC'', > %Fix It Continuously. They are not known for their quality, or should > %I say they are known for their lack of quality :-). > > How about FIO: Fix it Once. I swapped in an ASUS K7 and now everything > is back to normal: I thought we had protected our tradesecret on how to fix the FIC problem, seems someone else figured it out too :-) -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIC SD-11 not happy with ata
%> %It seems Russell L. Carter wrote: %> %> %It seems Russell L. Carter wrote: %> %> %> %> %> %> I swapped out my motherboard and am seeing this now: %... % %> %> )(*&$#%$# stupid magazine benchmarkers never actually test %> things like IO... gr % %We in the computer hardware business have a better name for ``FIC'', %Fix It Continuously. They are not known for their quality, or should %I say they are known for their lack of quality :-). How about FIO: Fix it Once. I swapped in an ASUS K7 and now everything is back to normal: ata-pci0: port 0xffa0-0xffaf at device 4.1 on pci 0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 [...] ad0: ATA-4 disk at ata0 as master ad0: 13783MB (28229040 sectors), 28005 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 32 depth queue, UDMA33 ad1: ATA-4 disk at ata1 as master ad1: 19574MB (40088160 sectors), 39770 cyls, 16 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 32 depth queue, UDMA66 I've been hammering the drives and so far no fallback. Still to go is a bonnie check. Regards, Russell % %-- %Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] % % %To Unsubscribe: send mail to [EMAIL PROTECTED] %with "unsubscribe freebsd-current" in the body of the message % To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIC SD-11 not happy with ata
It seems Russell L. Carter wrote: > > Hi Soren, > > I am beginning to believe that the FIC mb is the problem. My > IBM-DPTA-372050 is only half as fast (500MB bonnie) > as on the P2B (~10MB/s vs. ~19MB/s). A Jan 11 kernel > doesn't downgrade to PIO on the > IBM-DTTA-371440 as fast as this evenings -current with your > latest bits does, but eventually it gets there. Hmm, that endeed sound strange, the ICRC errors do point at HW trouble, you dont have the cables running near anything that generates a magnetic field or anything (like near the coils to the voltage regs etc), that is known to make trouble... > )(*&$#%$# stupid magazine benchmarkers never actually test > things like IO... gr I wouldn't belive those mags, most of what they write are just rubbish, and often tainted by who bought most advertizing space that month :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIC SD-11 not happy with ata
> %It seems Russell L. Carter wrote: > %> %It seems Russell L. Carter wrote: > %> %> > %> %> I swapped out my motherboard and am seeing this now: ... > > )(*&$#%$# stupid magazine benchmarkers never actually test > things like IO... gr We in the computer hardware business have a better name for ``FIC'', Fix It Continuously. They are not known for their quality, or should I say they are known for their lack of quality :-). -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIC SD-11 not happy with ata
%It seems Russell L. Carter wrote: %> %It seems Russell L. Carter wrote: %> %> %> %> I swapped out my motherboard and am seeing this now: %> %> %> %> ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying %> %> ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying %> %> ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying %> %> ad0: UDMA CRC WRITE ERROR blk# 1140495WARNING: WAIT_READY active=ATA_ACTIVE_ATA %> %> falling back to PIO mode %> % %> %This for the most part means cable and/or power problems, does this %> %appear immediately or under moderate/high load ?? %> %Remember the K7 is a power hog, how big is you PSU, especially how %> %much power (amps) can it deliver on the 3.3V 5V and 12V rails ?? %> %> All good points. Swapping the cable for an 80 pin ATA/66 %> cable had no effect. The PSU claims it can deliver %> 14A @ 3.3V, 25A @ 5V, and 10A @ 12V for this 250W unit. % %That should be enough... Hi Soren, I am beginning to believe that the FIC mb is the problem. My IBM-DPTA-372050 is only half as fast (500MB bonnie) as on the P2B (~10MB/s vs. ~19MB/s). A Jan 11 kernel doesn't downgrade to PIO on the IBM-DTTA-371440 as fast as this evenings -current with your latest bits does, but eventually it gets there. )(*&$#%$# stupid magazine benchmarkers never actually test things like IO... gr Regards, Russell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIC SD-11 not happy with ata
It seems Russell L. Carter wrote: > > I swapped out my motherboard and am seeing this now: > > ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying > ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying > ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying > ad0: UDMA CRC WRITE ERROR blk# 1140495WARNING: WAIT_READY active=ATA_ACTIVE_ATA > falling back to PIO mode This for the most part means cable and/or power problems, does this appear immediately or under moderate/high load ?? Remember the K7 is a power hog, how big is you PSU, especially how much power (amps) can it deliver on the 3.3V 5V and 12V rails ?? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FIC SD-11 not happy with ata
I swapped out my motherboard and am seeing this now: ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying ad0: UDMA CRC WRITE ERROR blk# 1140495WARNING: WAIT_READY active=ATA_ACTIVE_ATA falling back to PIO mode That doesn't sound good... This drive ran just fine with an ASUS P2B and seems to run fine on the FIC too. This is on a farm fresh -current. I've appended the dmesg. Cheers, Russell Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #14: Tue Jan 18 10:44:46 MST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/CURRENT Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 499034055 Hz CPU: AMD-K7(tm) Processor (499.03-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x612 Stepping = 2 Features=0x81f9ff AMD Features=0xc040 real memory = 268369920 (262080K bytes) avail memory = 257212416 (251184K bytes) Preloaded elf kernel "kernel" at 0xc02f3000. Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga-pci0: port 0xd800-0xd8ff mem 0xeefff000-0xeeff,0xef00-0xefff at device 3.0 on pci0 pci0: unknown card (vendor=0x12eb, dev=0x0001) at 6.0 irq 10 isab0: at device 7.0 on pci0 isa0: on isab0 ata-pci0: port 0xffa0-0xffaf at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 chip1: at device 7.4 on pci0 de0: port 0xc800-0xc87f mem 0xeeffef80-0xeeffefff irq 11 at device 9.0 on pci0 de0: 21143 [10-100Mb/s] pass 3.0 de0: address 00:80:c8:63:47:84 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 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 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 5 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: PCL,PostScript lpt0: on ppbus0 lpt0: Interrupt-driven port ad0: ATA-4 disk at ata0 as master ad0: 13783MB (28229040 sectors), 28005 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 32 depth queue, UDMA33 ad1: ATA-4 disk at ata1 as master ad1: 19574MB (40088160 sectors), 39770 cyls, 16 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 32 depth queue, UDMA66 Mounting root from ufs:/dev/ad0s1a de0: enabling 100baseTX port ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying ad0: UDMA CRC WRITE ERROR blk# 1140495WARNING: WAIT_READY active=ATA_ACTIVE_ATA falling back to PIO mode To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
