Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
On Tue, Mar 31, 2009 at 12:42:29PM +0900, Weongyo Jeong wrote:
> On Mon, Mar 30, 2009 at 08:53:34PM +0400, Chagin Dmitry wrote:
> > On Mon, Mar 30, 2009 at 05:05:32PM +0900, Weongyo Jeong wrote:
> > > On Sat, Mar 28, 2009 at 10:11:43PM +0300, Chagin Dmitry wrote:
> > > > On Wed, Mar 25, 2009 at 09:52:43PM +, John wrote:
> > > > > Hi list
> > > > >
> > [skiped]
> >
> > > >
> > > > Weongyo, please, look at line #166 - 169.
> > >
> > > Oops. I got it. :-) I'll commit a patch into CURRENT as soon as
> > > possible. Thanks!
> > >
> >
> > yeah, does not fall any more. But, unfortunately, does not work :(
> >
> > Mar 30 20:45:13 dchagin kernel: malo0: > Wireless Adapter> mem 0xd013-0xd013,0xd012-0xd012 irq 22 at
> > device 4.0 on pci4
> > Mar 30 20:45:13 dchagin kernel: malo0: [FILTER]
> > Mar 30 20:45:13 dchagin kernel: malo0: unable to allocate memory for cmd
> > tag,
> > error 12
> > Mar 30 20:45:13 dchagin kernel: malo0: unable to attach HAL
> > Mar 30 20:45:13 dchagin kernel: device_attach: malo0 attach returned 5
> >
> > is this expected behaviour for such device?
>
> No. It's one of the unexpected for amd64. Could you please test with
> attached patch?
>
> regards,
> Weongyo Jeong
>
> Index: if_malo_pci.c
> ===
> --- if_malo_pci.c (revision 190544)
> +++ if_malo_pci.c (working copy)
> @@ -245,7 +245,7 @@
> BUS_SPACE_MAXADDR, /* maxsize */
> 0, /* nsegments */
> BUS_SPACE_MAXADDR, /* maxsegsize */
> -BUS_DMA_ALLOCNOW,/* flags */
> +0, /* flags */
> NULL,/* lockfunc */
> NULL,/* lockarg */
> &sc->malo_dmat)) {
dchagin# ifconfig malo0
malo0: flags=8802 metric 0 mtu 2290
ether 00:18:4d:ec:61:89
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
dchagin# ifconfig malo0 scan
ifconfig: unable to get scan results
In the evening I will more in detail look... anyway, many thanks :)
--
Have fun!
chd
pgpDzFzPV7LQK.pgp
Description: PGP signature
Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
On Tue, Mar 31, 2009 at 11:03:25AM +0400, Chagin Dmitry wrote: > On Tue, Mar 31, 2009 at 12:42:29PM +0900, Weongyo Jeong wrote: > > On Mon, Mar 30, 2009 at 08:53:34PM +0400, Chagin Dmitry wrote: > > > On Mon, Mar 30, 2009 at 05:05:32PM +0900, Weongyo Jeong wrote: > > > > On Sat, Mar 28, 2009 at 10:11:43PM +0300, Chagin Dmitry wrote: > > > > > On Wed, Mar 25, 2009 at 09:52:43PM +, John wrote: > > > > > > Hi list > > > > > > > > > [skiped] > > > > > > > > > > > > > Weongyo, please, look at line #166 - 169. > > > > > > > > Oops. I got it. :-) I'll commit a patch into CURRENT as soon as > > > > possible. Thanks! > > > > > > > > > > yeah, does not fall any more. But, unfortunately, does not work :( > > > > > > Mar 30 20:45:13 dchagin kernel: malo0: > > Wireless Adapter> mem 0xd013-0xd013,0xd012-0xd012 irq 22 > > > at > > > device 4.0 on pci4 > > > Mar 30 20:45:13 dchagin kernel: malo0: [FILTER] > > > Mar 30 20:45:13 dchagin kernel: malo0: unable to allocate memory for cmd > > > tag, > > > error 12 > > > Mar 30 20:45:13 dchagin kernel: malo0: unable to attach HAL > > > Mar 30 20:45:13 dchagin kernel: device_attach: malo0 attach returned 5 > > > > > > is this expected behaviour for such device? > > > > No. It's one of the unexpected for amd64. Could you please test with > > attached patch? > > > > regards, > > Weongyo Jeong > > dchagin# ifconfig malo0 > malo0: flags=8802 metric 0 mtu 2290 > ether 00:18:4d:ec:61:89 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > > dchagin# ifconfig malo0 scan > ifconfig: unable to get scan results > > In the evening I will more in detail look... anyway, many thanks :) FWIW the following commands would be useful for CURRENT: # ifconfig wlan0 create wlandev malo0 # ifconfig wlan0 ssid up Please see malo(4) for details. Thanks for testing :-) regards, Weongyo Jeong ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Off-by-one error in ngets() causing panic in loader(8)?
On 2009-03-30 23:23, Bruce Cran wrote: > I've noticed that if I fill the input buffer at the loader prompt on > 7-STABLE I get panic with a guard page failure. From what I can see > the loader uses the ngets function in src/lib/libstand/gets.c with a > buffer of size of 256. If I print out the value of strlen(input) in > interp.c I get 256. Shouldn't line 77 of gets.c be comparing (lp-buf) > against (n-1) instead of n? Yes, either that, or change all callers to use "sizeof buf - 1" or similar. However, the latter is not how the normal fgets(3) works, so it is probably better to fix it in ngets() itself. :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RELENG_7 ata panic on atacontrol attach
Hi there colleagues, atapci3: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem 0xefcb3000-0xefcb3fff irq 23 at device 5.2 on pci0 atacontrol detach ata7 - insert ATA disk (ad14) atacontrol attach ata7 pinics with Fatal trap 12: page fault while in kernel mode (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc0533227 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0533535 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc06cfca3 in trap_fatal (frame=0xfcb0aa7c, eva=40) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc06cff00 in trap_pfault (frame=0xfcb0aa7c, usermode=0, eva=40) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc06d08a6 in trap (frame=0xfcb0aa7c) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc06b5b1b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc055b69c in device_attach (dev=0xcc58e480) at /usr/src/sys/kern/subr_bus.c:279 #8 0xc055c96d in device_probe_and_attach (dev=0xcc58e480) at /usr/src/sys/kern/subr_bus.c:2366 #9 0xc055ca59 in bus_generic_attach (dev=0xc5167100) at /usr/src/sys/kern/subr_bus.c:2905 #10 0xc04796f0 in ata_identify (dev=0xc5167100) at /usr/src/sys/dev/ata/ata-all.c:723 #11 0xc0479fe4 in ata_attach (dev=0xc5167100) at /usr/src/sys/dev/ata/ata-all.c:150 #12 0xc047a93a in ata_ioctl (dev=0xc510e200, cmd=2147770627, data=0xd2f6cb80 "\a", flag=3, td=0xcd32c690) at /usr/src/sys/dev/ata/ata-all.c:387 #13 0xc04f6497 in giant_ioctl (dev=0xc510e200, cmd=2147770627, data=0xd2f6cb80 "\a", fflag=3, td=0xcd32c690) at /usr/src/sys/kern/kern_conf.c:398 #14 0xc04d5f87 in devfs_ioctl_f (fp=0xcce31e8c, com=2147770627, data=0xd2f6cb80, cred=0xc6897700, td=0xcd32c690) at /usr/src/sys/fs/devfs/devfs_vnops.c:602 #15 0xc056d4e5 in kern_ioctl (td=0xcd32c690, fd=3, com=2147770627, data=0xd2f6cb80 "\a") at file.h:269 #16 0xc056d63f in ioctl (td=0xcd32c690, uap=0xfcb0acfc) at /usr/src/sys/kern/sys_generic.c:570 #17 0xc06d0248 in syscall (frame=0xfcb0ad38) at /usr/src/sys/i386/i386/trap.c:1090 #18 0xc06b5b80 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #19 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) up 7 #7 0xc055b69c in device_attach (dev=0xcc58e480) at /usr/src/sys/kern/subr_bus.c:279 279 if (dev->sysctl_tree != NULL) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.1 stable panics
> Nathanael Jean-Francois wrote: >> Hello all, >> >> I've been getting some panics with a 7.1 stable machine from March 14th. >> I've not been able to determine the cause nor reproduce them at will. >> Here's a backtrace from the latest panic on March 23rd. Let me know if >> any >> more information is needed. Thanks. >> >> Unread portion of the kernel message buffer: >> panic: lock (sleep mutex) Giant not locked @ >> /usr/src/sys/kern/kern_ntptime.c:965 > > This is strange because the corresponding mtx_lock is only a few lines > above. Can you provide your kernel config? > > Kris Sure. Also, for what it's worth I had hyperthreading enabled in the box's bios. I disabled hyperthreading and since then there hasn't been a panic. # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.484.2.18 2009/03/12 03:09:11 bms Exp $ cpu HAMMER ident BACKUPS # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY# BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI# Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing #optionsKDTRACE_FRAME # Ensure frames are compiled in #optionsKDTRACE_HOOKS # Kernel DTrace hooks #ADDED OPTIONS options INCLUDE_CONFIG_FILE options WITNESS options INVARIANT_SUPPORT options INVARIANTS # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # ou
Re: 32bit filesystem limitations
Andrei Kolu wrote: > Ivan Voras wrote: >> 2009/3/25 Barry Pederson : >> >> >>> Is there any reason not to skip labeling/partitioning and use da1 >>> directly? >>> Just newfs it and mount it. I've done this with a couple large Areca >>> arrays with no ill effect so far. >>> >> >> Nope, no practical reason. Skip the partitioning if you don't need it. >> >> > Finally: # newfs /dev/da1 (note: no soft-updates here) > a# df -H > Filesystem SizeUsed Avail Capacity Mounted on > . > /dev/da1 3.4T4.1k3.1T 0%/data > . > > Mission accomplished. But why sysinstall plays such an ugly game? This > problem should be announced as a bug. Because sysinstall only knows about fdisk and bsdlabel partition types, and those have a fixed format defined in the old days. You get the same problem with basically all operating systems today except latest versions of Windows Server which uses GPT by default. (but simply always using GPT by default isn't a good option because it will interfere with people wanting to multi-boot other operating systems). signature.asc Description: OpenPGP digital signature
Re: Off-by-one error in ngets() causing panic in loader(8)?
On Monday 30 March 2009 5:23:07 pm Bruce Cran wrote: > I've noticed that if I fill the input buffer at the loader prompt on > 7-STABLE I get panic with a guard page failure. From what I can see > the loader uses the ngets function in src/lib/libstand/gets.c with a > buffer of size of 256. If I print out the value of strlen(input) in > interp.c I get 256. Shouldn't line 77 of gets.c be comparing (lp-buf) > against (n-1) instead of n? Yep. I've committed the fix. The libstand(3) manpage states that ngets() puts in at most n - 1 characters followed by a NULL, so n - 1 is the correct fix. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
On Tue, Mar 31, 2009 at 04:36:08PM +0900, Weongyo Jeong wrote: > On Tue, Mar 31, 2009 at 11:03:25AM +0400, Chagin Dmitry wrote: > > On Tue, Mar 31, 2009 at 12:42:29PM +0900, Weongyo Jeong wrote: > > > On Mon, Mar 30, 2009 at 08:53:34PM +0400, Chagin Dmitry wrote: > > > > On Mon, Mar 30, 2009 at 05:05:32PM +0900, Weongyo Jeong wrote: > > > > > On Sat, Mar 28, 2009 at 10:11:43PM +0300, Chagin Dmitry wrote: > > > > > > On Wed, Mar 25, 2009 at 09:52:43PM +, John wrote: > > > > > > > Hi list > > > > > > > > > > > [skiped] > > > > > > > > > > > > > > > > Weongyo, please, look at line #166 - 169. > > > > > > > > > > Oops. I got it. :-) I'll commit a patch into CURRENT as soon as > > > > > possible. Thanks! > > > > > > > > > > > > > yeah, does not fall any more. But, unfortunately, does not work :( > > > > > > > > Mar 30 20:45:13 dchagin kernel: malo0: > > > Wireless Adapter> mem 0xd013-0xd013,0xd012-0xd012 irq > > > > 22 at > > > > device 4.0 on pci4 > > > > Mar 30 20:45:13 dchagin kernel: malo0: [FILTER] > > > > Mar 30 20:45:13 dchagin kernel: malo0: unable to allocate memory for > > > > cmd tag, > > > > error 12 > > > > Mar 30 20:45:13 dchagin kernel: malo0: unable to attach HAL > > > > Mar 30 20:45:13 dchagin kernel: device_attach: malo0 attach returned 5 > > > > > > > > is this expected behaviour for such device? > > > > > > No. It's one of the unexpected for amd64. Could you please test with > > > attached patch? > > > > > > regards, > > > Weongyo Jeong > > > > dchagin# ifconfig malo0 > > malo0: flags=8802 metric 0 mtu 2290 > > ether 00:18:4d:ec:61:89 > > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > > status: no carrier > > > > dchagin# ifconfig malo0 scan > > ifconfig: unable to get scan results > > > > In the evening I will more in detail look... anyway, many thanks :) > > FWIW the following commands would be useful for CURRENT: > > # ifconfig wlan0 create wlandev malo0 > # ifconfig wlan0 ssid up > > Please see malo(4) for details. Thanks for testing :-) > yes, it works. thnx! -- Have fun! chd pgpNhIfKJQFnU.pgp Description: PGP signature
incorrect port value in tcpdump output
Hi there. [I don't know if it was discussed already.] tcpdump'ed from RELENG_7, kernel and modules as of Mar 22 are in sync, world as of Mar 18. I caught this while building kernel via NFS. The subj host is an NFS server. 23:22:03.056098 IP (tos 0x0, ttl 64, id 26932, offset 0, flags [DF], proto TCP (6), length 160) 172.17.5.168.2355868444 > 172.17.5.167.2049: 108 getattr [|nfs] 0x: 4500 00a0 6934 4000 4006 6db2 ac11 05a8 0x0010: ac11 05a7 0396 0801 7631 7eb4 37c6 db06 0x0020: 8018 40cc 54c6 0101 080a 00a5 d95b 0x0030: da0f fa92 8000 0068 8c6b b31c 0x0040: 0002 0001 86a3 0003 0001 0x0050: 23:22:03.056180 IP (tos 0x0, ttl 128, id 10841, offset 0, flags [DF], proto TCP (6), length 168) 172.17.5.167.2049 > 172.17.5.168.2355868444: reply ok 116 getattr [|nfs] ^^^ 0x: 4500 00a8 2a59 4000 8006 6c85 ac11 05a7 0x0010: ac11 05a8 0801 0396 37c6 db06 7631 7f20 0x0020: 8018 71c7 7a07 0101 080a da0f fa93 0x0030: 00a5 d95b 8000 0070 8c6b b31c 0001 0x0040: 0x0050: If you'd look in tcp header then 2355868444 value should be 918 actually (as htons(918) returns expected 9603 in hex (0396 in net order)). -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Samsung SCX-4200 printer
On Thu, Jan 08, 2009 at 03:06:42PM +0200, Alexander Shikoff wrote: > That's all. If you have any issues/question feel free to ask. Have a nice day! Thank you again on-list, Alexander, for your comprehensive instructions which would have worked immediately if I had read /usr/ports/UPDATING before switching linux_base. My own fault. Sorry to all others for the long silence, I was very busy elsewhere, but I guess nobody was waiting for me :-) The printer works like a charm. But I had no success with the scanner for which I employed Alexander's philosophy in order to download the required libraries. Now all libraries are there, but: Running smfpscan yields: WARNING: configuration file not found sane_init - QApplication::postEvent: Unexpected null receiver Running mfp yields: direct mfp:/dev/mfp/4 "Unknown" "MFP USB Port #0" direct mfp:/dev/mfp/5 "Unknown" "MFP USB Port #1" Seems hopeless under FreeBSD. I suppose the solution to my problem is called "HP Laserjet M1120 MFP". Harald ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: incorrect port value in tcpdump output
In the last episode (Apr 01), pluknet said: > tcpdump'ed from RELENG_7, kernel and modules as of Mar 22 are in sync, > world as of Mar 18. > > I caught this while building kernel via NFS. The subj host is an NFS server. > > 23:22:03.056098 IP (tos 0x0, ttl 64, id 26932, offset 0, flags [DF], proto > TCP (6), length 160) 172.17.5.168.2355868444 > 172.17.5.167.2049: 108 getattr > [|nfs] > 0x: 4500 00a0 6934 4000 4006 6db2 ac11 05a8 > 0x0010: ac11 05a7 0396 0801 7631 7eb4 37c6 db06 > 0x0020: 8018 40cc 54c6 0101 080a 00a5 d95b > 0x0030: da0f fa92 8000 0068 8c6b b31c > 0x0040: 0002 0001 86a3 0003 0001 > 0x0050: > 23:22:03.056180 IP (tos 0x0, ttl 128, id 10841, offset 0, flags [DF], proto > TCP (6), length 168) 172.17.5.167.2049 > 172.17.5.168.2355868444: reply ok > 116 getattr [|nfs] > 0x: 4500 00a8 2a59 4000 8006 6c85 ac11 05a7 > 0x0010: ac11 05a8 0801 0396 37c6 db06 7631 7f20 > 0x0020: 8018 71c7 7a07 0101 080a da0f fa93 > 0x0030: 00a5 d95b 8000 0070 8c6b b31c 0001 > 0x0040: > 0x0050: > > If you'd look in tcp header then 2355868444 value should be 918 actually > (as htons(918) returns expected 9603 in hex (0396 in net order)). That's not the port number; that's the NFS transaction id. See the tcpdump manpage, under the section "NFS Requests and Replies". -- Dan Nelson dnel...@allantgroup.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: RELENG_7 ata panic on atacontrol attach
Dmitry Morozovsky wrote: Hi there colleagues, atapci3: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem 0xefcb3000-0xefcb3fff irq 23 at device 5.2 on pci0 atacontrol detach ata7 - insert ATA disk (ad14) atacontrol attach ata7 pinics with Fatal trap 12: page fault while in kernel mode Any kernel verbose messages before it? -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: RELENG_7 ata panic on atacontrol attach
On Wed, 1 Apr 2009, Alexander Motin wrote: AM> Dmitry Morozovsky wrote: AM> > Hi there colleagues, AM> > AM> > atapci3: port AM> > 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem AM> > 0xefcb3000-0xefcb3fff irq 23 at device 5.2 on pci0 AM> > AM> > AM> > atacontrol detach ata7 AM> > - insert ATA disk (ad14) AM> > atacontrol attach ata7 AM> > AM> > pinics with Fatal trap 12: page fault while in kernel mode AM> AM> Any kernel verbose messages before it? Nope. Just ata7: [ITHREAD]^M ^M ^M Fatal trap 12: page fault while in kernel mode^M cpuid = 0; apic id = 00^M fault virtual address = 0x28^M fault code = supervisor read, page not present^M instruction pointer = 0x20:0xc055b69c^M stack pointer = 0x28:0xfcb0aabc^M frame pointer = 0x28:0xfcb0aaf8^M code segment= base 0x0, limit 0xf, type 0x1b^M = DPL 0, pres 1, def32 1, gran 1^M processor eflags= interrupt enabled, resume, IOPL = 0^M current process = 3725 (atacontrol)^M trap number = 12^M panic: page fault^M and approx 15 seconds of wait between ata channel detection and the panic. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: RELENG_7 ata panic on atacontrol attach
On Wed, 1 Apr 2009, Dmitry Morozovsky wrote: DM> AM> > atapci3: port DM> AM> > 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem DM> AM> > 0xefcb3000-0xefcb3fff irq 23 at device 5.2 on pci0 DM> AM> > DM> AM> > DM> AM> > atacontrol detach ata7 DM> AM> > - insert ATA disk (ad14) DM> AM> > atacontrol attach ata7 DM> AM> > DM> AM> > pinics with Fatal trap 12: page fault while in kernel mode DM> AM> DM> AM> Any kernel verbose messages before it? DM> DM> Nope. Just DM> DM> ata7: [ITHREAD]^M DM> ^M DM> ^M DM> Fatal trap 12: page fault while in kernel mode^M DM> cpuid = 0; apic id = 00^M DM> fault virtual address = 0x28^M DM> fault code = supervisor read, page not present^M DM> instruction pointer = 0x20:0xc055b69c^M DM> stack pointer = 0x28:0xfcb0aabc^M DM> frame pointer = 0x28:0xfcb0aaf8^M DM> code segment= base 0x0, limit 0xf, type 0x1b^M DM> = DPL 0, pres 1, def32 1, gran 1^M DM> processor eflags= interrupt enabled, resume, IOPL = 0^M DM> current process = 3725 (atacontrol)^M DM> trap number = 12^M DM> panic: page fault^M DM> DM> and approx 15 seconds of wait between ata channel detection and the panic. What I possibly missed is that it is not guaranteed panic, and seems to be dependent on parameters of disk inserted: e.g. I usually have this particular machine panicked with WD320, and no panics with Seagate 7200.11/750G -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Intel Integrated Raid (iir) relevance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (It would be probably good idea to redirect this discussion to -stable@, redirected) Hi, Danny, Danny Braniss wrote: > It's no longer working (for me) under 7.2, and so far > I am not getting any feedback, so since it seems that > this particular hardware has reached EOL, I was wondering > if, > a) it's true, > b) drop it, and replace it. > c) should time be spent in getting it to work again. I'm not very sure about your problem with iir(4). A diff against RELENG_7_1 does not reveal any change on the driver itself. Are you sure that 7.1-R can have the device working? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknSy7AACgkQi+vbBBjt66AUoQCgtFiu6Bsg0LygJ7gAnKLdBBMN JKIAoKNioqTEQSA8vX621jqTpBKTaO1C =RmFa -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 32bit filesystem limitations
Ivan Voras wrote: Andrei Kolu wrote: Ivan Voras wrote: 2009/3/25 Barry Pederson : Is there any reason not to skip labeling/partitioning and use da1 directly? Just newfs it and mount it. I've done this with a couple large Areca arrays with no ill effect so far. Nope, no practical reason. Skip the partitioning if you don't need it. Finally: # newfs /dev/da1 (note: no soft-updates here) Oops. OK, I can enable it next boot from rc.local: tunefs -n enable /data a# df -H Filesystem SizeUsed Avail Capacity Mounted on . /dev/da1 3.4T4.1k3.1T 0%/data . Mission accomplished. But why sysinstall plays such an ugly game? This problem should be announced as a bug. Because sysinstall only knows about fdisk and bsdlabel partition types, and those have a fixed format defined in the old days. You get the same problem with basically all operating systems today except latest versions of Windows Server which uses GPT by default. (but simply always using GPT by default isn't a good option because it will interfere with people wanting to multi-boot other operating systems). I forgot to try ZFS on that particular server- maybe that one would be better alternative? I have experience with ZFS on terabyte sized volumes and had no ill effects so far- what about really large filesystems? I know that ZFS is considered experimental. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: incorrect port value in tcpdump output
2009/4/1 Dan Nelson : > In the last episode (Apr 01), pluknet said: >> tcpdump'ed from RELENG_7, kernel and modules as of Mar 22 are in sync, >> world as of Mar 18. >> >> I caught this while building kernel via NFS. The subj host is an NFS server. >> >> 23:22:03.056098 IP (tos 0x0, ttl 64, id 26932, offset 0, flags [DF], proto >> TCP (6), length 160) 172.17.5.168.2355868444 > 172.17.5.167.2049: 108 >> getattr [|nfs] >> 0x: 4500 00a0 6934 4000 4006 6db2 ac11 05a8 >> 0x0010: ac11 05a7 0396 0801 7631 7eb4 37c6 db06 >> 0x0020: 8018 40cc 54c6 0101 080a 00a5 d95b >> 0x0030: da0f fa92 8000 0068 8c6b b31c >> 0x0040: 0002 0001 86a3 0003 0001 >> 0x0050: >> 23:22:03.056180 IP (tos 0x0, ttl 128, id 10841, offset 0, flags [DF], proto >> TCP (6), length 168) 172.17.5.167.2049 > 172.17.5.168.2355868444: reply ok >> 116 getattr [|nfs] >> 0x: 4500 00a8 2a59 4000 8006 6c85 ac11 05a7 >> 0x0010: ac11 05a8 0801 0396 37c6 db06 7631 7f20 >> 0x0020: 8018 71c7 7a07 0101 080a da0f fa93 >> 0x0030: 00a5 d95b 8000 0070 8c6b b31c 0001 >> 0x0040: >> 0x0050: >> >> If you'd look in tcp header then 2355868444 value should be 918 actually >> (as htons(918) returns expected 9603 in hex (0396 in net order)). > > That's not the port number; that's the NFS transaction id. See the tcpdump > manpage, under the section "NFS Requests and Replies". > Gah.. thank you, I was too dumb to read the man page. -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 32bit filesystem limitations
On Wed, Apr 1, 2009 at 1:03 AM, Andrei Kolu wrote: > I forgot to try ZFS on that particular server- maybe that one would be > better alternative? I have experience with ZFS on terabyte sized volumes and > had no ill effects so far- what about really large filesystems? I know that > ZFS is considered experimental. I've got 1.5T disks in my ZFS server. I don't boot from them and I havn't labelled them (added "ad6" and so on to the zfs array). After hearing that various fdisk things couldn't see beyond 1.2T, I got to wondering if the whole disks were being used. It appears that they are. Now ZFS on solaris seems to insist that you initialize (ie: use their fdisk) the disks before adding them to ZFS. I've also recently added a bunch of 1.5T disks to a Solaris install ... and it seems happy to use the whole disk, too. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
