|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
I've got a 2TiB Ext3-FS on a SAN via Qlogic cards. Upon mounting, the kernel spewed out the following:
EXT3-fs error (device lvm(58,0)): ext3_check_descriptors: \ Inode bitmap for group 0 not in group (block 178114594)! EXT3-fs: group descriptors corrupted ! EXT3-fs: Magic mismatch, very weird !
It's currently fscking, and I've gone through thousands of errors similar to the following:
Inode 131881105 is in use, but has dtime set. Fix<y>? yes Inode 131881106 was part of the orphaned inode list. FIXED. Inode 131881107 was part of the orphaned inode list. FIXED. Inode 131881109 was part of the orphaned inode list. FIXED. Deleted inode 131881110 has zero dtime. Fix<y>? yes Inode 131881111 is in use, but has dtime set. Fix<y>? yes Inode 131881111 has imagic flag set. Clear<y>? yes Inode 131881112 is in use, but has dtime set. Fix<y>? yes Inode 131881113 was part of the orphaned inode list. FIXED. Inode 131881114 was part of the orphaned inode list. FIXED. Inode 131881115 was part of the orphaned inode list. FIXED. Inode 131881116 was part of the orphaned inode list. FIXED. Deleted inode 131881117 has zero dtime. Fix<y>? yes Inode 131881118 is in use, but has dtime set. Fix<y>? yes Inode 131881118 has imagic flag set. Clear<y>? yes Inode 131881119 is in use, but has dtime set. Fix<y>? yes Inode 131881120 was part of the orphaned inode list. FIXED. Inode 131881091, i_blocks is 66, should be 0. Fix<y>? yes Inode 131881098, i_blocks is 66, should be 0. Fix<y>? yes Inode 131881105, i_blocks is 66, should be 0. Fix<y>? yes Inode 131881112 has compression flag set on filesystem without compression support. \ Clear<y>? yes Inode 131881112, i_blocks is 13, should be 0. Fix<y>? yes Inode 131881119 has compression flag set on filesystem without compression support. \ Clear<y>? yes Inode 131881119, i_blocks is 15, should be 0. Fix<y>? yes Inode 131881115 has compression flag set on filesystem without compression support. \ Clear<y>? yes Inode 131881115 has INDEX_FL flag set but is not a directory. Clear HTree index<y>? yes /dev/vg/lv: |========================== / 53.9%
Think it'll make it? Only time (and lots of it) will tell, but I'm thinking no.
Looks like draft-jeong-dnsop-ipv6-dns-discovery-12.txt recently turned into RFC 5006:
This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts.
Overall, I think it's a good idea.
Without this, RA's can only give end hosts a prefix and router address; it's up to the host itself to deal with DNS resolution. This isn't enough for most small deployments, and I can see many folks turning to DHCPv6 solely for DNS server addresses, which is wasteful, and potentially opens security holes. (I don't care if it's a hybrid deployment or a full-blown DHCPv6 environment)
This, on the other hand, allows small networks to operate entirely on RA's, and not worry about configuring an additional DHCPv6 services. If things like NTP, WINS, etc. are needed, then DHCPv6 can be leveraged. I suppose this opens the door for some of those options being added to RAs, too, which may not necessarily be the best path.
There's already a patch for Linux 2.6.22 out there based on the IETF draft…
I stumbled upon IPv6 World while researching RH0 problems this evening. It's a visualization of Scapy's (with IPv6 patches) tcptraceroute, and generates some very neat graphs:
It's fully interactive, too. I took some more screenshots when playing around.
As I was heading out this morning, I noticed some sort of Ferrari show taking place at the Ballantyne Village, so I decided to take a peek.
I took some photos, but all I got was a lousy (and overpriced) t-shirt.
Last weekend it was a smart USA show. I wonder what's in store for next weekend…
Here's a good one.
ARIN sets up an IPv6 Wiki at http://www.getipv6.info/, but hardly anyone can get to it via IPv6 due to MTU issues and ICMPv6 blackholing.
Welcome to the wonderful world of "MTU issues" ;)
It's really neat! I haven't even tried the web frontend, yet…
Most of my channels are still unknown and won't lock, though. I suppose they're encrypted. At least I get all the boadcast channels.
(see my previous post)
*yawn*
Why would HD temperatures decrease during a period of increased I/O activity?
em0 interface on dax:
HD sensors on dax (in celsius):
Maybe it's just too early in the morning.
After some talk at work last week, I figured I should put the coax jack in my den to some good use, and started looking around for some HDTV tuner cards. I'll whet your appetite with some (NBC 1080i) screenshots:
I realized I would need (at the bare minimum) an ATSC card with a QAM tuner to view the channels provided by my Time Warner Cable digital cable service here in Charlotte. Initially, the use of the term DVB in many LinuxTV articles confused me, but I soon found out that the Linux DVB subsystem works with ATSC cards, too. It's somewhat of a misnomer, since DVB used on its own refers to the digital TV standard in Europe.
After consulting the list of supported cards, I picked up (impulse buy, of course) a DViCO FusionHDTV5 RT Gold PCI card, which seemed to sport a complete featureset. It uses the Conexant cx2388x chipset, which is supported on the somewhat jacked-up 2.6.22-gentoo-r5 (x86_64) kernel I've been running as of late.
I was lazy, and modularized the kitchen and sink. CONFIG_KITCHEN and CONFIG_SINK are required, and will increase your kernel size +32MiB.
No, really, in Multimedia devices, I modularized everything under Video capture adapters, and DVB/ATSC adapters. Thankfully, udev autoloaded it all for me upon bootup, so I didn't really have to do a thing. Here's a short list of relevant modules:
Module Size Used by btcx_risc 4808 4 budget 12868 0 budget_av 20160 0 budget_ci 18116 0 budget_core 10180 3 cx8800 32044 0 cx8802 16452 1 cx88_alsa 12808 0 cx88_dvb 15428 4 cx88_vp3054_i2c 4352 1 cx88xx 64484 4 dvb_core 76144 7 dvb_pll 14404 3 dvb_ttpci 94848 0 ir_common 32260 2 lgdt330x 9092 1 saa7146 16264 6 saa7146_vv 45312 2 ttpci_eeprom 2944 2 tuner 61480 0 tveeprom 17232 1 v4l1_compat 11972 2 v4l2_common 18304 6 ves1820 6596 0 video_buf 21828 7 video_buf_dvb 5764 1 videodev 26304 3
The ir_common is for the IR port, that I failed to hook up (lack of interest), on the card. And, that's about it…
From the start, it looked like dvbscan, azap, Kaffeine, and MPlayer were going to be my friends. In fact, MPlayer is already my friend, since I ditched Xine awhile back.
I emerged the following:
(I'd link to packages.gentoo.org, but that site's been dead for several weeks, now)
After reading some documentation, I realized I would need to create a channels.conf file, which is read by a number of DVB applications, and is composed of the (colon-delimited) channel name, frequency (in Hz), modulation type (QAM_256, 8VSB), video PID, audio PID, and program PID. The easiest way of creating this channels.conf is to run scan or dvbscan (former is for ATSC, but the latter works, too) by giving it an initial tuning data file. I saw a couple candidates (us-NY-TWC-NYC, us-Cable-Standard-center-frequencies-QAM256, us-ATSC-center-frequencies-8VSB) but eventually just catted them all together and launched dvbscan with the verbose flag.
This is about where I started pulling my hair out. Ok, that's an exaggeration.
dvbscan wasn't finding ANY channels. I was just seeing stuff like this for every frequency:
>>> tune to: 75000000:QAM_256 (tuning failed) >>> tuning status == 0x02 >>> tuning status == 0x02 >>> tuning status == 0x02 >>> tuning status == 0x02 >>> tuning status == 0x02 >>> tuning status == 0x02 >>> tuning status == 0x02 >>> tuning status == 0x02 >>> tuning status == 0x02 >>> tuning status == 0x02 WARNING: >>> tuning failed!!!
I unplugged the coax cable, and the tuning status changed to 0x00 for every frequency. Sounded like I had a signal, but maybe it was just too weak? I brought my old 20" clunker TV into the room, and plugged it in. Seemed fine, but was a bad test since it's analog. I checked out the cable splitters in the laundry room "telecom box" and removed the one feeding the bedrooms, plugging the den port directly into the feed coming from the junction box on the other side of the building. Voila, tuning success! Purchasing a 2GHz splitter did little good, as too much of the signal was degraded, so I eventually just closed it up and kept the two other bedrooms disconnected (who cares, they don't have TVs anyway).
Back to the channels.conf. The us-Cable-Standard-center-frequencies-QAM256 seemed to produce the best results, so I stuck its dvbscan output in channels.conf, and renamed some of the channels. The weird thing is, the initial channel names were [xxxx], where xxxx is some hex ID value, but they were repeated on different frequencies. However, if I changed the channel names appropriately, and tuned both frequencies, I got the same program content. I'm no cable whiz, (skipped cable 101, due to scheduling conflicts) but I assume it's being broadcasted this way for a reason.
Anyhow, here are some channels (channels.conf style) I was able to tune that are relevant to Time Warner Cable in Charlotte:
NBCHD:651000000:QAM_256:2045:2044:164 ABCHD:579000000:QAM_256:2033:2032:6 WCNC:651000000:QAM_256:2045:2044:164 FOX:579000000:QAM_256:0:0:8 CW:579000000:QAM_256:1632:1631:9 WTVI:585000000:QAM_256:141:143:2 WTVI2:585000000:QAM_256:147:148:3
The quickest way of tuning and viewing the MPEG stream is to first select the channel with azap -r [channel name], and then playing /dev/dvb/adapter0/dvr0 with mplayer. azap should show you something like this:
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 579000000 Hz video pid 0x0664, audio pid 0x0663 status 00 | signal 4b11 | snr 0a43 | ber 00000000 | unc 0000ffff | status 1f | signal d7a9 | snr 1d7c | ber 00000000 | unc 0000ffff | FE_HAS_LOCK status 1f | signal d6e6 | snr 1d61 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
The FE_HAS_LOCK indicates that the card has locked the frequency and is getting a clear signal. If you don't see that, then either the signal is too faint, or something else is wrong.
MPlayer then will start streaming the TS packets from /dev/dvb/adapter0/dvr0 and decode them to the screen, excellent! You can also cat /dev/dvb/adapter0/dvr0 to a .ts file, and save the raw MPEG packet data to disk. Neat, huh?
I also tried Kaffeine, which took a little hacking to get working. Apparently the DVB support doesn't include ATSC scanning, so the $HOME/.kde/share/apps/kaffeine/channels.dvb must be converted from an existing channels.conf. Check out this thread. Downloading and building the atsc-converter utility worked fine. Kaffeine was then able to see a list of channels. Viewing them is just a click away.
I haven't discovered all the channels, yet.. this will take some time. I also need to mess with mencoder, and encode the TS data into something smaller. MythTV is also on my list of things to try.
Displaying page 51 of 121 of 965 results
     |
This HTML for this page was generated in 0.009 seconds. |